Building project code to support more than one MCU

[joshuadonaldson]

Hi, I have a code base which currently is written to support just one type of MCU. Going forward, how would I go about using the same code base (with minimal changes depending on the MCU under use) to support more than the one MCU?

[nxf58904]

Hi,

You can add some #define to your project . When you change MCU , The #define will help you choose the corresponding code.

Just like the follow picture shows.

Jianyu: 

Have a great day,
TIC

-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

[joshuadonaldson]

There is also the selection of MCU under project properties > C/C++ Build > MCU settings. Is it possible for this to update with preprocessor symbols depending on the build configuration?

[joshuadonaldson]

Keeping in mind we are opting for the use of the mcuxpresso ide.

[joshuadonaldson]

Sure.

I guess the next question would be, what is the best way to manage the SDKs for each microcontroller to be used? Is there some tool to manage this? Or is this up to me to decide upon a structure etc. ?

[myke_predko]

Hey @joshuadonaldson ,

You asked: "what is the best way to manage the SDKs for each microcontroller to be used?"

That's the basic issue that I've been struggling with for almost a year now and have never gotten an acceptable answer from NXP.  The best solution would be to have the same level of SDK for all devices so that multi MCU code can be created that is portable with a minimum of fuss.  I'm very disappointed that there isn't any kind of strategy to bring up all the Kinetis SDKs to a minimum that provides all devices with the SDK features of the featured/promoted Freedom and Tower boards.   

To deal with this (I'm writing code for MCUs which have SDKs 2.7.0/2.8.0, 2.3.1 and 2.2.0) I'm structuring my code so that APIs and their functionality are called from MCU (SDK) specfic files which are unique to each project.  Depending on the requirements and functionality, I use an inline method for the code rather than using a traditional subroutine/function.

@nxf58904 has a good suggestion to #ifdef check of the processor which should be put in the start of the MCU specific file so that an error is thrown if somehow the wrong MCU specific file was copied into the project.  I'll add that to my MCU specific files over time to ensure I'm not bringing in anything I don't want to accidentally (although that's somewhat unlikely because I start my MCU specific files with "SDK2_7_0..." and if I have accidentally copied in and using the wrong file, it stands out in the file list).  

Good luck - I feel your pain.

myke

[joshuadonaldson]

Hi @myke_predko , 

Thanks for sharing, really appreciate your thoughts and input.

I think I have come up with a workable and fairly maintainable solution for now going forward but that's not to say that it could be made alot more efficient.

I shouldn't need to worry about maintaining various SDK versions.. *touch wood* but will keep this in mind.

My only concern is the clunkiness of the structure I have setup where a set of drivers(etc.) shall belong to a specific MCU for building residing in their own libs folder. But again it does make for easy maintenance and updating the SDKs should just be a matter of overwriting files for the most-part. 

I'm currently doing something similar to @nxf58904 's suggestion, using the CPU_<MCU_PART_NUMBER> which is already used throughout and defined under preprocessor symbols.

[mjbcswitzerland]

Hi

It is probably too late if you have already invested considerable time in developing a project with the NXP SDK but for people starting developments the uTasker project's SDK (15 years of maturity on Coldfire, Kinetis and also now including i.MX RT) allows a project to run on almost any Kinetis (and other) parts with a single define (also with MCUXpresso).

Rather than an SDK for each individual part its SDK and drivers adapt themselves to the part instead so the exact same (for example) UART driver code is used by all Kinetis parts (UARTs or LPUARTs) and also by all i.MX RT parts. The big advantage is that maintenance is restricted to one file rather than having a file for each processor and even projects written for old Coldfire parts in 2005 can still be built for almost any Kinetis or i.MX RT part today with no SDK compatibility issues or great development/learning effort.

Features: https://www.utasker.com/index.html
Kinetis boards that share a single project: https://www.utasker.com/kinetis.html
i.MX RT boards that share the same single project: https://www.utasker.com/iMX.html

For general techniques, I have found "Build Variables" in MCUXpresso (most other IDEs have something equivalent too) useful for simplifying managing target control for a project and there is a video showing building with MCUXpresso and controlling targets using such user definable Build Variables at: https://youtu.be/p_eUGo6GypY
A document based version is at https://www.utasker.com/docs/iMX/MCUXpresso.pdf
whereby these variables (which can be added and defined to suit) are found in the Project properties, eg.

Regards

Mark
uTasker project developer for Kinetis and i.MX RT]