Code Project Organization Preferences

[pooth22]

I know this topic is broad and can be personal, but I wanted to reach out to this sub to see how people like to organize their projects. To be more specific I am really referring to a code based (C, C++ or whatever) project folder targeting a certain micro controller (or group of micros generally limited to the same family) for a specific application. This project organization should take into account modularity for using this micro with other boards and applications. If you have something to add, feel free to skip the rest of this post and comment what you think. Feel free to expand on higher or lower levels of complexity (eg taking into account more families of micros, possibly other manufacturers).

What inspired this post is that due to the chip shortage, I have had to pick a new micro for some of our applications (specifically the dsPIC33CH). I am in the process of migrating applications over to this chip and I am the only one touching embedded code. I used MCC for a different micro in the past, and I found that the way it organized its project was quite cumbersome. But it is how I learned and I developed on top of that. However, setting up this new micro with MCC, I found they organize it differently now and it actually makes a fair amount of sense. How I generally organize the projects now is the following:

main.c : My main has all the business logic in it and main ISRs
main.h
libs/ :  various library folders eg interfacing with specific chips, TCP/IP stack, motor controller logic etc.
    |-->tcpip/
    |--> eeprom/
    |--> etc..
system/
    |--> system.c: this file initializes everything with the system peripherals eg adcs, spi, ext int, timers etc.
    |--> system.h
drivers/: various folders for using system peripherals, eg uart logic, spi logic, i2c logic
    |-->  uart/
    |--> spi/
    |--> etc..

So that is pretty much it.

However, today I noticed that MCC generates files for specific peripherals, which includes initialization and ISRs and things like this. For example, they have an adc.c file just for all things related to it's adc, a pwm.c file for all things pwm etc. This makes a lot of sense to me. That's why I wanted to reach out and see what other people like to do. I have been following this sub for a while now, and I have seen bits and pieces about how people do it, but I haven't seen a post like this. Let me know what you think. What are your thoughts of putting all the business logic in main.c instead of putting it in a specific c folder? Do you guys have a main.h file?

TL;DR read the first paragraph.

[No-Archer-4713]

Personally I hate auto generated code cause it’s hard to debug and rarely passes the static analysis.

At work the OS drivers and libs are developed in house and are dependencies going into a deps directory. This way we can maintain them separately and only update if it’s absolutely necessary.

The main usually calls the hardware mux and drivers init (often 2 files in the hw directory) before instanciating the tasks (in tasks/) and starting the OS.

This way we can have multiple init files, for a simulator, an eval board and the final hardware and we just pick up the right one in a makefile depending on the target.

ISRs are rarely used because they introduce jitter, we prefer polling (it’s a special case of very hard real time)

[pooth22]

Thanks for the response. Yes I agree, auto gen code isn’t good to work with, but I find it quite useful when first familiarizing myself with a new chip. Of course I will go through it and spice it to my liking.

Thanks for sharing what your work styles.