Too many conditional compilations

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

Too many conditional compilations

631 Views
kai_liu
Senior Contributor I

FSL has many MCU to support. I found many conditional compilation in source code, such as USB stack and bootloaders.

Conditional compilation macros are useful in simple build time customization.

However it becomes more and more confusion as more and more custom code are added, because of MCU families, peripherals, application customization, compilers. The developers will find these conditions are mess up and hard to read.

I would like to suggest FSL team to use seperate folder to replace conditional compilation macros.

For example,

Conditional compilation:

#if defined(MCU_KL25Z)

#elif defined(MCU_K20D50M)

#elif defined(MCU_MK70F12)

...

#endif

#endif

#endif

folder

clock\MCU_KL25Z\mcg.c

clock\MCU_K20D50M\mcg.c

clock\MCU_MK70F12\mcg.c

Tags (1)
3 Replies

420 Views
mjbcswitzerland
Specialist V

Kai

The problems with having a large number of different source files are:

- Maintenance - if there is a change made in a common part it becomes necessary to make it in multiple files with an increased risk of the change being made in correctly in one of them (or forgotten).

- When supporting multiple IDEs (eg. Codewarrior, IAR, Keil, Rowley, Atollic, GCC standalone) the targets of each project have to be configured and entered correctly in each case (and modified in each case when general changes are made). This can cause a single change to have to be performed in multiple projects, multiple targets and multiple IDEs. For example, if I add a single general file to the uTasker project (supporting 7 IDEs, each contains 4 shared projects and having around 10 tested targets for each) it requires about 250 individual actions, which takes several hours of work to check that the all still build and no mistake was made.

Therefore I find (as probably Freescale does) that having too many conditional files to maintain causes massively larger problems than conditional code.

However I would suggest that the use of the conditional code may not be the root cause of the difficulty but rather the actual software design may be. Although conditional defines are very useful, to use then inappropriately would detract from their advantages.

When I check the uTasker USB stack (for example) which works across the Kinetis processor range I find just two lines of code in the lowest level driver that are dependent on the processor (or board) used [ignoring devices that require high speed driver code]. These control the MPU setting to allow concurent accesses to take place (needed on certain devices) and the setup of the USB clock source (some do this in the SIM_SOPT2 register and some in the SIM_CLKDIV2 register). The generic stack code itself needs to know nothing about the board/processor.

Therefore there should be no reason for needing many such board/processor conditional code segments in general, questioning rather the fact that they may be used inappropriately rather than them not being the most suitable method. Maybe this needs to be addressed rather than using other workarounds (?)

Regards

Mark

0 Kudos

420 Views
kai_liu
Senior Contributor I

Hi, Mark,

You are right. Conditional files are very easy to be forgotten, or leave it as is. And testing task is huge as well, even with the existing conditional macros. That is why some users always complain that FSL released untested firmware to public.

0 Kudos

420 Views
DavidS
NXP Employee
NXP Employee

Thank you for the suggestion Kai.
.
Regards,

David

0 Kudos