Re: C++ hardware library for (small) 32-bit micro-controllers
Hi,
Wouter van Ooijen wrote:
I am working on a portable C++ hardware library for real-time
applications on small (but still 32-bit) micro-controllers. My typical
(and current only) target is the Cortex M0 LPC1114FN28 (4k RAM, 32K
Flash) using GCC. Efficiency is very important, in run-time, RAM use,
and ROM use. The typical restrictions for small microcontrollers apply:
no RTTI, no exceptions, and no heap (or at most just an allocate-only
heap).
I've been using an implementation using classes with virtual functions
for that, in programs from bootloaders to application programs (well,
actually I did a little template magic to implement vtbls "by hand", so
I can control when and how things are constructed). But effectively, I
have classes
class InputPin { virtual int get() = 0; };
class OutputPin { virtual void set(int) = 0; };
and their descendants.
Your fully template-based approach looks neat and appropriate for things
with as little "meat" as an I/O pin, but for more complicated things
like "SPI transaction", "parallel NOR flash", "NAND flash" I'd like to
know where in the object files my code ends up.
Plus, an I/O pin may end up to be more than just read-bit-from-register:
for applications that occasionally read a pin, I've got an
implementation of the InputPin interface that performs a remote
procedure call into the driver, saving the application from having to
map physical memory.
If this is all too abstract, I have a more concrete question, mainly for
C++ architects. For I/O pins and ports I use class templates with (only)
static functions. This matches well with reality (the hardware circuit
is generally fixed), and is much more efficient than using inheritance
and virtual functions.
"The hardware circuit is generally fixed" is one of the biggest lies of
embedded software development :-)
At least I didn't yet encounter a project where hardware assignments
didn't change over time. Pins get moved, get inverted, new flash chip,
etc. So it's good I'm able to adapt by changing a (runtime) initialisation.
I'm paying one virtual dispatch per access. So, I wouldn't want do to
bit-banged SPI or IIC with my drivers. Thank god I don't have to :-)
It's probably not appropriate for 8-bitters, but it's efficient enough
to be useful in production bootloaders with a few k code.
Stefan