Whenever I start another microcontroller project, I find myself writing the same code all over again – setting up peripherals, looking up pin mapping, etc. Everybody does, probably. I then try to reuse the code from my older projects or saved snippets and typically find something wrong with it and end up writing the code from scratch anyway. It’s often not written well enough to be easily reused, has too many design issues, or I’ve actually deleted it a long time ago.

My usual reaction is to write a library for such code, quickly followed by abandoning the idea due to the amount required. The actual solution is to use an existing framework or library, assuming one exists. The only one vaguely applicable in this case is Arduino, but it doesn’t quite fit what I’m looking for. Why?

• While possible, it is cumbersome to build outside of the IDE.
• The support for accessing on-board peripherals like timers/counters is limited. There are 3rd party libraries that can help with that, but they often provide limited configuration options or board support.
• The simplified API doesn’t take full advantage of features available in modern C++.
• I prefer having the option of porting the code to platforms not supported by Arduino.

And with that, I find myself starting my own library. Project Liquid is an attempt to create a C++ interface for microcontroller functions, such as GPIO, Timers, or ADC, that I use in my projects. It is not meant to be comprehensive – I plan to add features and platforms as needed for other projects. And to be perfectly honest, I want to use it as a testing ground for practicing C++ embedded design and experimenting with new programming techniques.

I’m aiming at the middle ground between cross-platform flexibility and efficiency. I will attempt to take advantage of the available hardware wherever possible, but I will accept some runtime overhead if it makes the code more readable and flexible. This part is giving me a headache. I keep changing my mind about how to best represent the differences between API implementations on different platforms or even different components on the same board (Runtime polymorphism, PIMPL, build time source selection, etc.). But this is why I’m attempting to write the library. I will have the chance to try the different options and see how they work in my projects. For that reason, I expect the API will change often. This is not ideal for actual code reuse, but I value the opportunity for experimentation and learning more.