Originally published at: Abstract hardware interfaces in Zephyr - Golioth
In this post, we’ll walk through a couple methods for defining abstract hardware interfaces in Zephyr using the devicetree. You’ve probably seen abstract hardware interfaces implemented on popular development boards. Many boards provide a standardized connector interface like mikroBUS, Feather, MicroMod, Arduino UNO, etc. A defining characteristic of these interfaces is the ability to plug in a range of peripheral boards that do different things, but still all use the same signals. For example, a MikroE Weather Click board that implements the mikroBUS standard can be plugged into a LPCXpresso55S28 dev board or a STM32 M4 Clicker dev board without requiring any hardware changes to the Weather Click boards. The signals are always in the same place on the ClickBus form factor (even if each Click board doesn’t use all of them). Using abstract interfaces can enable writing more portable devicetree definitions that can be reused across multiple boards. Same app, multiple boards We’ve been updating our collection of Golioth reference designs to support our Follow-Along Hardware boards. These are designs you can build yourself using off-the-shelf development boards. Zephyr’s Devicetree support enables us to decouple the hardware definition for each board from the application source code. By using devicetree interfaces to the underlying hardware, we can target completely different boards (or different revisions of the same board) without any changes to the application code. For example, the images below show two supported boards that run the same Air Quality Monitor reference design firmware: Golioth Aludel Mini board nRF9160 DK FAH board Why use abstract hardware interfaces? Look closely at the images above. You’ll notice that both platforms are hosting the exact same MikroE Click sensor modules. These Click modules…