How to merge a FatFS Project with a second project ?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to merge a FatFS Project with a second project ?

Jump to solution
2,666 Views
jameswhitney
Contributor II

Hello, to All,

With the help of Kerry Zhou I was able to get some SD Card code from a previous 'Community project going. This question is somewhat of a follow on. I have an application very similar to the 'periph_i2s_dmic' example in MCUXpresso. What is the most efficient method to merge these two projects, or, in general, to add the sd card project to another project ? For the current time prefer *not* to use an RTOS (that said, for future, what is a suggested suitable RTOS ?)

I am using the the LPCXpresso54114 board and the latest version of MCUXpresso.

Regards,

Jim

Labels (3)
0 Kudos
1 Solution
2,318 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Jim,

    1.About the lib

       lpcopen code and the SDK code are two different type library, lpcopen is the old library, it is not updated in the future. But SDK for LPC54114 is the new code driver, it is supported in the future.

     Your fatfs code is just based on the new SDK code, it is correct.

     If you want to use the DMIC, you can use this code:

SDK_2.4.1_LPCXpresso54114\boards\lpcxpresso54114\driver_examples\dmic

    About the SDK, you can download it from this link:

Welcome | MCUXpresso SDK Builder 

   Choose the LPC54114, then generate the code, and download it.

    Please refer to Getting Started with MCUXpresso SDK.pdf in folder: SDK_2.4.1_LPCXpresso54114\docs to use the SDK MCUXpresso project.

    Now you can port your sd project to the dmic project, or port the dmic project to the sd project, both method is OK.

    But your attached project you can't use it, because you mix the lpcopen and the sdk together, these two lib is conflict.

    When you port one project to the other, you need to add the other code's header file path.

2 - Is this actually the quickest way to go about this ????

   Yes, use the official code, will make you get start quickly.

    3. midlleware dropdown my FatFS option does not appear.

     When you generate the SDK code, you need to select the fatfs, otherwise, your SDK don't have it.

pastedImage_132.png

Please generate the SDK again.

Wish it helps you!
Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

View solution in original post

0 Kudos
19 Replies
2,318 Views
jameswhitney
Contributor II

Kerry,

Thank you for all of your help - I think I am in good position at the current time.

As a summary to date that can hopefully help others:

* The microSD card project that we worked on was the 'base' project.

* The source code from a second project from the SDK was chosen to merge *with/into* the microSD card project.

* To start the merge I *only* added in the 'includes' from the second source file into the microSD project; my logic being anything beyond the (missing) '#includes' would be a syntax, or, a logical error.

* I tried very hard to modify the compiler paths to pick up the additional resource locations of the second project which were needed by the modified microSD card project. I tried several different path modifications under 'Project' ----> 'Properties', then 'C/C++ Build' and 'C/C++ General'. Just *could not* get any of the path modifications to work. I eventually just added the needed/missing resources to the 'Utilities' folder in the  microSD card project *IF* they were missing from the 'drivers' folder.

* While I have not yet modified the section of source code from the second project which was added into the microSD card project, the code with the second set of 'includes', and some of the subroutines from the second project completely builds.

Thanks.

J.

0 Kudos
2,318 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi James,

   Thanks a lot for your experience sharing.

If you still have question about it, please kindly let me know!
Have a great day,
Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
2,318 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi James Whitney,

    Sorry for my later reply.

    Today I have checked your project.

    At first, it have the SysTick_IRQn problem, then I comment the code in the lpc_chip_5411x, after that I meet a lot of problems:

pastedImage_18.png

After the detail checking about your periph_i2s_dmic project, I find you even put the lpcopen lib and the SDK driver together, these two types code can't compatible.

You can use lpcopen lib or the SDK driver, you can't merge it together. Just choose one lib style, then try it again.

Have a great day,
Kerry

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
2,318 Views
jameswhitney
Contributor II

Kerry,

While I have programmed a bit with/for Texas Instruments products, I am quite new to NXP/MCUXpresso tool chain. So a few questions:

1 - You stated - "....You can use lpcopen lib or the SDK driver, you can't merge it together. Just choose one lib style, then try it again...." 

My question is, how do I do this - do I just need to change some compiler switches, or, are there some other steps that I need to take ??? I.e., whether I go FatFS project-into-DMIC project, *or* DMIC project-into-FatFS project, seems changes are going to be necessary to the build path.

2 - Is this actually the quickest way to go about this ????

3 - I'm a little confused about the SDK that I built (earlier). I included 'FatFS' and a few other items as options. When I look in the lower right corner of the MCUXpresso main panel I see 'SDK Details', 'Selected SDK Content'. However, when I then start a new project and look in the 'middleware' dropdown my FatFS option does not appear.

There has got to be an easier way....maybe.

Thanks, again,

Jim

0 Kudos
2,319 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Jim,

    1.About the lib

       lpcopen code and the SDK code are two different type library, lpcopen is the old library, it is not updated in the future. But SDK for LPC54114 is the new code driver, it is supported in the future.

     Your fatfs code is just based on the new SDK code, it is correct.

     If you want to use the DMIC, you can use this code:

SDK_2.4.1_LPCXpresso54114\boards\lpcxpresso54114\driver_examples\dmic

    About the SDK, you can download it from this link:

Welcome | MCUXpresso SDK Builder 

   Choose the LPC54114, then generate the code, and download it.

    Please refer to Getting Started with MCUXpresso SDK.pdf in folder: SDK_2.4.1_LPCXpresso54114\docs to use the SDK MCUXpresso project.

    Now you can port your sd project to the dmic project, or port the dmic project to the sd project, both method is OK.

    But your attached project you can't use it, because you mix the lpcopen and the sdk together, these two lib is conflict.

    When you port one project to the other, you need to add the other code's header file path.

2 - Is this actually the quickest way to go about this ????

   Yes, use the official code, will make you get start quickly.

    3. midlleware dropdown my FatFS option does not appear.

     When you generate the SDK code, you need to select the fatfs, otherwise, your SDK don't have it.

pastedImage_132.png

Please generate the SDK again.

Wish it helps you!
Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
2,318 Views
jameswhitney
Contributor II

Kerry,

Thank you.

Just had a quick comment for today about the SDK.

When I generated the SDK I *did* include FatFS. The situation is this - when I look in the actual SDK folder in the Windows file system I can see all of the middleware that I added when building the SDK - Amazon-FreeRTOS Kernel, FatFS, multicore, USB stack. The 'problem' is when I start 'New Project' then get to the 'Configure the Project' panel; the FatFS component *does not* appear under 'Middleware'. The RTOS and USB components *do* appear. I have attached two (2) images. I will try all that you mention.

Thanks, again,

Jim20190304_101629.jpg

20190304_102023.jpg

0 Kudos
2,318 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi jim,

    Thank you for your updated information.

     Yes, in the create the new project, the middleware don't have the fatfs item, but I think it is not very important, you totally can import the according file in the project after you create it.

    You can try it on your side.

 

If you still have question about it, please kindly let me know!
Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
2,318 Views
jameswhitney
Contributor II

Kerry,

Thank you for all of your help - I think I am in good position at the current time.

As a summary to date that can hopefully help others:

* The microSD card project that we worked on was the 'base' project.

* The source code from a second project from the SDK was chosen to merge *with/into* the microSD card project.

* To start the merge I *only* added in the 'includes' from the second source file into the microSD project; my logic being anything beyond the (missing) '#includes' would be a syntax, or, a logical error.

* I tried very hard to modify the compiler paths to pick up the additional resource locations of the second project which were needed by the modified microSD card project. I tried several different path modifications under 'Project' ----> 'Properties', then 'C/C++ Build' and 'C/C++ General'. Just *could not* get any of the path modifications to work. I eventually just added the needed/missing resources to the 'Utilities' folder in the  microSD card project *IF* they were missing from the 'drivers' folder.

* While I have not yet modified the section of source code from the second project which was added into the microSD card project, the code with the second set of 'includes', and some of the subroutines from the second project completely builds.

Thanks.

J.

0 Kudos
2,318 Views
jameswhitney
Contributor II

Over the past week I had tried working in the opposite direction, i.e., adding the FatFS file system to the DMIC project. There were too many dependencies/that I didn't understand and couldn't resolve so I put this approach aside.

Is there a more streamlined method to this problem than the current approach - i.e., not starting with two *separate* projects, but building all of the routines and other dependencies into one project ? As I don't fully understand the current flow just seems like there are a lot of routines (associated with LPCOpen ?) in the 'Luxcel Eval Board Demo' project which are not needed.

For the current time I would be happy with any sort of merge, but I'm just curious if there isn't a more streamlined, direct, approach to implementing this filesystem into a project.

Best regards,

Jim

0 Kudos
2,318 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi James Whitney,

      I am glad to see you again!

      If you want to merge the FatFs project to another project, actually it is very simple.

      At first, you should make sure your other project works, then you can add your another project's code to this FatFs project, in the main code, you also can call your other project's code. You can try to merge it together, when you meet the detail question, let's talk it together again.

   About the RTOS, you can try to use the freertos.

Wish it helps you!

If you still have question about it, please kindly let me know.

BTW,  from tommorrow, I will on our Chinese Spring Festival, I will back on February 11th.
So, if you still have question, I will reply you on 2019 February 11th. If you are in hurry, you can create the new case, then my other colleague also will help you!
Thanks a lot for your understanding.


Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,318 Views
jameswhitney
Contributor II

Hello, Kerry (or, anyone else who wants to weigh in)

This merge process is coming along and I think I have a very good chance of having something work.

As mentioned, I really wanted to merge the SD Card code/project *into* the 'other' project.

Currently I have all of the SD Card project '#includes' added into the Periph_i2s_dmic project. I commented all of them out, then uncommented them one-by-one, until the project built for that particular 'include' and all its dependencies. Then, I moved on to the next one. When there was a contention between, i.e., a file/folder I copied from the project and a file/folder that was part of the SDK, i.e., 'lpc_chip_5411x', I deleted,or, modified the copied file/folder.

At this point there are three (3) '#includes' which keep returning an error: 1 - #include "fsl_device_registers.h", 2 - #include "fsl_debug_console.h", and, 3 - #include "spi.h"

There error is exactly the same:

'SysTick_IRQn' undeclared (first use in this function); did you mean 'SysTick_Type'? core_cm4.h /lpc_chip_5411x/inc line 1682 C/C++ Problem

The path to 'lpc_chip_5411x/inc' is included in the Build path. Also, SysTick_IRQn = -1, /*!< 15 System Tick Timer */ exists in the build path (file is cmsis_5411x.h). I know the compiler is getting there because I put a redundant definition below that line and it caught the re-declaration.

Could really use some eyes on this and/or some suggestions.

Thanks,

Jim

0 Kudos
2,318 Views
lfchaves_gm
Contributor I

Hi James, I had a similar linking (redundant definition) problem and I guess that FreeRTOS already defines an interface to access sd card (and File System too). I had these problems creating a new project from scratch using SDK project wizard.  So far, I have been solving this linking problem selecting as middleware only "apter_freertos" and "sd".

pastedImage_1.png

Regards,

Luciano

2,318 Views
jameswhitney
Contributor II

Good morning, Luciano,

Based on Kerry's last comments I am going to have to make some modifications to my original approach.

I wanted to re-check the details of the comments that I sent to you yesterday. When I originally built the SDK with optional components awhile back I included 'FatFS', .... So, today I went back to MCUXpresso 'New Project', filled in 'Board Type' (processor), ....

What I was describing yesterday is that I *do not* see FatFS as an option under 'Middleware'. However, if I look 'SDK Details'/'Selected SDK Content' (Main panel of MCUXpresso, lower right hand corner, *before* we start building 'New Project') I *can* see FatFS in this list, but again, does not appear in the 'Middleware' panel when putting together a new project.

Do you have any questions/comments/suggestions ?

Have you been able to build  a project with FatFS support ??

Thanks,

Jim

0 Kudos
2,318 Views
jameswhitney
Contributor II

Hello, Luciano,

Thanks, for your input.

Maybe I'll fork the project, as if I can get the current hiccup to work I'll see how close I am to a 'universal' template. I was trying to stay away from any RTOS's for the current effort. I will, however, try to put a bit of time in on what you mention as sooner, or, later, we will be going to bare-board and a lot of what is contained in the dmic part of the 'merge' will be going away.

Operating from (my) memory I think I took a quick look/poke at beginning from scratch with the wizard about a week ago, or, so, as I wanted to see if that might be an easier way (SURELY, the MUST be an easier way). I think I saw FatFS listed as an available resource but when I started selecting things to go in the SDK FatFS did not appear. Again, I am operating from memory and it was just a very quick exercise.

Again, thanks,

Jim

0 Kudos
2,318 Views
jameswhitney
Contributor II

Kerry,

Seems the addition of the 'CMSIS' file I copied from the Luxcel board project to the i2s project had a lot of redundancy with definitions and redundancies with some files which were already part of the i2s project. Latest changes are:

 - I removed the 'CMSIS' file (that was originally part of the Luxcel board project) from the i2s dmic project.

 - I added explicit processor definitions to the C compiler preprocessor i.e.,

                   CPU_LPC54114J256BD64_cm4
                   CPU_LPC54114J256BD64

This got rid of most of the build error.

I then got the following error:
fatal error: fsl_device_registers.h: No such file or directory fsl_common.h /periph_i2s_dmic/drivers line 43 C/C++ Problem.


When I put a copy of 'fsl_device_registers.h' in the path it got rid of the above error but gave me another related error.

Getting late. Leaving off for the day.

Regards,

Jim

0 Kudos
2,318 Views
jameswhitney
Contributor II

Kerry,

I have attached the latest version of the 'merged code'. If at all possible, this is the version I would like to get going.

Actions I've taken:

- I imported the following routines from the 'Luxcel Eval Board Demo' folder to the 'periph_i2s_dmic' folder

     'CMSIS', 'board', 'drivers', 'source', 'startup', 'utilities', and libs'

- I examined the way the 'Project Properties' were set up for both of the two projects and was able to understand these much better. The results are in the modified 'periph_i2s_dmic' project.

I think this is a better attempt than before, however there are still some things not quite correct. There are a bunch of errors related to the 'fsl_clock.h' routine and a few other 'fsl' errors.

Please let me know if we are going to be able to get to the end from this point.

By the way, *BOTH* projects compile AND run correctly individually. Currently I just have the '#includes' and the 'GPIO_configuration' routine from the Luxcel project added to the dmic project code (though, I think the compiler is hanging at trying to resolve the Luxcel 'include' statements and their various routines.

Best,

Jim

0 Kudos
2,318 Views
jameswhitney
Contributor II

Kerry,

PLEASE *DO NOT* spend too much time on the current merge effort, i.e., adding the dmic code into the sdcard code. I feel that in terms of having a 'repeatable' template I will concentrate on copying the SD CARD code into the DMIC code.

To start this effort I copied all of the 'includes', static void GPIO_Configuration(void), void SPI_CS_Low(), void SPI_CS_High(), from the Luxcel project into 'main' in the 'periph_i2s_dmic' project. I also copied the 'CMSIS', 'drivers', 'utilities', and 'lib' folders from 'Luxcel Eval Board Demo' path to 'periph_i2s_dmic' project path. I did not copy the 'startup', or, 'release' folders from Luxcel.

Of course, when I tried to build the i2s dmic project I ended up with innumerable errors. But examining  the errors it seems most of them are path problems.

As a general question, given that the path errors can be straightened out, have I added/subtracted enough from the i2s project to get the sdcard additions to work ??

Thanks,

Jim

0 Kudos
2,318 Views
jameswhitney
Contributor II

Over the past week I had tried working in the opposite direction, i.e., adding the FatFS file system to the DMIC project. There were too many dependencies/that I didn't understand and couldn't resolve so I put this approach aside.

Is there a more streamlined method to this problem than the current approach - i.e., not starting with two *separate* projects, but building all of the routines and other dependencies into one project ? As I don't fully understand the current flow just seems like there are a lot of routines (associated with LPCOpen ?) in the 'Luxcel Eval Board Demo' project which are not needed.

For the current time I would be happy with any sort of merge, but I'm just curious if there isn't a more streamlined, direct, approach to implementing this filesystem into a project.

Best regards,

Jim

0 Kudos
2,318 Views
jameswhitney
Contributor II

Hello (Kerry),

I think I have a good start on merging the two projects, i.e., the SD Card Project and the peripheral i2s DMIC project.

Things were going OK, however I am a little weak on modifying the compiler settings, i.e., what settings and paths to modify in the 'Project' - - - - -> 'Properties'. I have attached the project and a log of *most* of the modifications I tried. I may have left out a few when I started thrashing on the project. I removed most of the code associated with 'Statistics' and references in 'main', along with some of the references in the respective .h files.

I have not yet determined where to put the file 'write' statements, they will probably go in the subroutine code just before data is sent to the CODEC (i.e., instead of sending the code to the CODEC I want to send the data to a file. So, eventually, all of the initialization & functional code for the CODEC will also go away). So, for the  present time no worries for the file write code hanging around at the bottom of the 'main' (commented out).

Thanks,

Jim

P.S. For some reason, even though I commented out the following line I still received a compile error:

- Deleted the following line from ‘dmic_if.h’ (line 38)

/*void dmic_get_chan_statistics(DMIC_STATISTICS_T* s, uint16_t chan);*/

0 Kudos