C to C++ How do I make h/w initialization look neat?
I more or less agree with Vicente that if you use objects, then the constructors of those objects are the places to do such hardware initialisation.

But I very much dislike names like "IOManager", because it doesn't convey what the thing does (managers generally don't do anything usefull, right?) and it probably bundles the actions in the wrong way, which gives rise to the classic comment from the C caps that they can't see what is done when an IOManager object is constructed. That isn't the fault of OO, it is the consequence of bad naming and/or partitioning. It is not initialization code that should be grouped thogether but the use of a peripheral (initialization and operational use).

Let's assume that you use an SPI bus, or an LCD, or an analog current sensor. IMO the object you initialize should be named after its use, hence (for instance) an HD44780 LCD that is used as logging output. The object creation should look something like

HD44780 logger( ... );


What is at the ... depends on how flexible the HD44780 object is. If the pins and the size (lines x columns) and other details are totaly fixed (could be the case for a project, but it is a bad idea for a (re-usable) library) this knowledge might be inside the HD44780 class. If not, pass this info as parameters. If you have the resources, pass objects that represent the pins. In that case the initialization of the pins is done in the pin constructors (maybe you want a port (= a bundle of pins) for the d4-d7).

gpio lcd_e( 12 );
...
HD44780( lcd_e, ... );


This puts pin initialization in the one place it realy should be: the pin library class.

If you can't afford the overhead of objects for pins, consider passing pin numbers, and have the HD44780 call the pin library to do the initialization. If you use macros or inline functions for accessing the pins this can be as efficient as using the pins directly (somewhat like the Arduino Wiring library).

An OO abstraction offers flexibility and reusability and good code structure (and it looks familiar to an OO programmer), but it doesn't come free: those objects take up RAM, and calling virtual functions takes time and blocks optimizations (but link-time optimization gets better and better at removing such overhead). Hence I prefer a static-class / template-based apparoach which avoids this overhead for compile-time known hierargies. This has a cost too: it looks a bit weird, even to seasoned C++ programmers. But is can be as efficient as dedicated C code. Check Objects? No Thanks! for more explanation.

Odin Holmes advocates an approach that is even more radical, where each module specifies its initialization requirements, which are then (at compile time!) combined. Multiple writes to different bitfields of the same register are thus merged into one assignment.