I am an OO programmer, and since some time I'm spending time (as a hobby) with an STM32.
For a hobby project I'm using a shift register (74HC595), and LCD. For both I wrote a class to easily construct and use it.
Both are based without interrupts/DMA, so the methods are very simple (actually for the shift register there is only one method: ShiftOut(uint16_t data)).
But I can imagine later when I want to use the shift register in a more challenging program, that I want it to use interrupts or even DMA.
Since I don't have much experience with embedded libraries, and also cannot remember seeing it before, would it be better to split a library in 3 classes (one for without-interrupts, one using interrupts, and one using DMA) or an 'all in one' solution?
The advantages for combining:
- Just one class
- No repeating code (most 'business logic' will be equal)
The advantages for splitting:
- Better performance (no need to check what manner (none, interrupt, DMA) is used)
- Less code (no checks which communication method is used)
Or I could make an abstract base class and create classes for non-interrupt, interrupt or DMA deriving from it (but that will be a performance hit for every function).
Since I mostly don't see the 'split' solution (but sometimes see different classes made by different people) I wonder if it would be useful.
Also as a side question, I'm intending to pass everything what is needed (so e.g. needed I2C or SPI port, GPIO pins). I'm not sure if I can pass easily callbacks for interrupts/DMA settings, as this is set by CubeIDE and doing that manually without CubeIDE seems a bit overwhelming right now. Can I expect problems passing interrupts/DMA functions?
#define
's to identify how the library works, for example the user of the api would declare#define SHIFTOUT_USEDMA
and you would use those #defines in the library to conditionally compile code. This is different though if you are distributing the library as a compiled assembly. \$\endgroup\$ – Ron Beyer Jan 31 '20 at 16:22