What does a cpp main file should look like for embedded systems

[jcsb1994]

Write your question here.

Hi, I am puzzled as to what should be left in the main.cpp file in a well designed embedded program. For example, as of now, I have a lot of global class instances that are accessed by the ISRs all declared in the main file as such (I know, it is not a minimal usable code snippet, but I share this more as of an example of what it could look like, and which parts you would remove from main to place in more specific files maybe):

#include "ESP32TimerInterrupt.h" // for the attach interrupt fct
#include "Buzzer.h"
#include "tact.h"

Buzzer buzzer;
tact button1;
tact button2;

void BuzzerTimerHandler()
{
  buzzer.step();
}

void buttonsHandler()
{
  button1.readInput()
  button2.readInput()
}


int main() {
  buzzer.init();
  button1.init();
  button2.init();
  InterruptTimer0_buzzer.attachInterruptInterval(50000, BuzzerTimerHandler);
  InterruptTimer1_tof.attachInterruptInterval(20000, buttonsHandler);

for(;;) {
  // blink led, whatever..
  }
}

I am wondering if any of you have been professionally designing embedded c++

1. what would a reasonable clean main file would look like? is it ok to have global buttons as such, and set all their initialization code in main?
2. for the ISRs, would it be better to move them all in another file, or even put each of them in a file with the module that uses it (i.e. a button file would have the button declarations, the button ISR, ...), a friend told me this could be a good option but he doesnt work a lot with embedded so I am not convinced..

Thanks a lot!

[jonnin]

it depends on the system. Some systems make it very hard not to have globals, due to stack space or various limitations, but just like on a bigger machine, you should avoid them if you have a choice.

depending on the OOP and tools, they should initialize when constructed (normally inside main) and be passed off to functions.

The ISR is just a function call. It belongs where it belongs. A tiny embedded program can be all in main, its OK. Splitting it out costs things you may not be able to afford. If you split off functions, then main should call functions only, not do work, much like a bigger program.

[jcsb1994]

The ISR is just a function call. It belongs where it belongs.

so say you have a class that acts as an interface to an eeprom chip. If you need to implement it with a specific mcu architecture, and you need an ISR for writing to the eeprom, you would add the header files to manage ISRs in that eeprom header file, and then add it in main, which would also probably have included the ISR headers?

Or you would create an intermediary class/file that creates a custom implementation of the eeprom chip in the specific mcu you are using, and the ISR would be in there before being included in main?

ex using FooMcu:
eepromChip.h (low level fcts, interfaces with the chip)
FooMcu_ISR.h (a file with low level ISRs to operate on the FooMcu)
eepromManager.h: includes eepromChip.h and FooMcu_ISR.h
main: includes eepromManager

is that a reasonable tree?

thanks!

[jonnin]

Probably the first way. But the thing is, I think both methods will work fine, so if there is any reason to pick one over the other, that comes into play. The second idea would only make sense to me if you had some sort of reusable template maybe.. to get something from the extra class.
Including the same file twice is not an issue for #1. Though main probably inherited the include from the other part, so you may not need the copy in main.

Do you have some reason to pick either approach? That can be technical, or just style and code organization.

[kbw]

If you're writing for a tiny device, like an Arduino with a 2k stack, you're forced to make most things global. As there isn't much space anyway, you're unlikely to run into the problems of using globals in desktop/server apps.

This style allows you to have minimal stack use, and in your context, I'd say it's (likely) correct.