Best way to write modular 'C' code for microcontrollers

[langwadt]

https://xkcd.com/1205/

[mikeselectricstuff]

3. But what about fixed resources that the module uses like a fixed external interrupt pin like INT0 or INT1 how do I ensure that no one else uses that resource.

Comments in the section of your code that does peripheral initialisation, ideally ordered by resource to reduce the chances of duplication.
e.g.
// timer 1 - used for comms timeout
T1CON=.....
// timer 2 - used to send heartbeat messages
T2CON=.....
//SPI1 - used for interface to turbo-encabulator
SPI1CON=.....

 

[SHristov]

The best approach (at least for me) is to have couple layers of abstraction and separation in components.
Each component could have header,source and configuration header (for example with defines). 

You could separate at-least 3 layers:
 
- complex rivers - that are interacting directly with the HW (ex. SPIdrv, I2Cdrv, WDG and so on).
- applications - running on the highest level (they don't care about the HW) - just process the input and writing on the output)
-Run-time environment - through that componet are exchanging information

https://www.google.com/search?q=embedded+software+layers&newwindow=1&client=firefox-b&biw=1200&bih=1503&source=lnms&tbm=isch&sa=X&ved=0ahUKEwinlsCvzbLQAhWKIsAKHWmTDxAQ_AUIBigB#newwindow=1&tbm=isch&q=embedded+software+layers+complex+driver&imgrc=ZLmRXZ-D_a6WyM%3A

[nctnico]

3. But what about fixed resources that the module uses like a fixed external interrupt pin like INT0 or INT1 how do I ensure that no one else uses that resource.

IMHO that is sorted by the hardware. An external interrupt pin will have a meaning to a certain part of the software only so it is unlikely to be shared.

[obiwanjacobi]

If you have reusable (high-level) code (known good and unit tested) that uses fixed interfaces to access device-specific resources, the overhead is minimal and it all gets compiled into very efficient code (C++ templates). You only have to implement those fixed interface methods for the resources you actually use when porting to a new device.
Your libraries are split into generic code (using fixed interfaces) and device specific reusable code (implementing these fixed interfaces) - per device. You harvest the generic code from existing projects and you write the device-specific code as needed - and/or reuse what you already have.

I guess you could also make this work in C, just a little messier and less optimal IMO.

[ZeroResistance]

Some random hints:
 - Avoid global variables, make as many variables/functions static as possible
 - Use enums. Although enums aren't type safe in C, they still help to communicate the design intent
 - Follow a strict naming convention. Since C doesn't give you anything like namespaces and classes, it's up to you to name things sensible.

1. When you say make as may variables / functions static as possible is it similar in a way to private variable in oop languages only in this case its private to that file in which the variable is declared?
2. Are there any drawbacks of static variables?
3. I like your idea of enums never used them as much I should have...

[obiwanjacobi]

1) Yes in a way. Static vars are only accessible by the module - or function if you declare it inside the function.
Other modules cannot see that var.
2) Using statics makes your code harder/impossible to unit test because it will be harder to control (stub).
3) Use a naming convention to make sure the options are unique across modules.