Building a generic driver (INA219/INA3221) across ESP + other hals

[ewrogers]

I have a project that is essential a power/watt monitor using a ESP32-C3 with INA219 (single-channel) or INA3221 (triple-channel) via I2C. It will also display the metrics on an OLED screen driven with the SSD1309 over SPI.

The question I have is how to architect my INA219/3221 implementations in a manner that it can be used by both the esp-hal in my own device as well as useful for other non-ESP developers. I am familiar with embedded-hal a little bit as I was using Rust with the AVR platform until I discovered the C3 is RISC-V and decided to make the switch.

I have no issue writing the driver code itself for the INA219 family but right now it's hal-specific to ESP platform. I have been looking at the ssd1309 library and how it uses the display-interface crates to make it agnostic but I am having a hard time wrapping my head around doing similar for this chip.

I am thinking, something like the following steps:

1. Write a generic "interface" crate such as powermon-interface that has traits that can be implemented such as get_shunt_voltage(), get_bus_voltage(), etc.
2. Write both ina219 and ina3221 libraries using the above generic interface (similar to ssd1309).
3. Somehow integrate this on my project with ESP I2C (does the esp-hal already implement embedded-hal traits for peripherals?)

I am fairly new to embedded and Rust so pardon my ignorance. I just figure that there will invariably be people using these common ICs and having a pre-made agnostic driver would be much better than everyone re-implementing it.

I did see there is an existing ina219 crate but I don't think it is agnostic (nor accurate). My end-goal is to use the INA3221 triple-channel since my project will have three power channels to monitor, I was just doing the INA219 first as my own "start small" and get experience.

Any tips in the right direction would be appreciated!

[chvllad]

Well, embedded_hal is the way to write platform agnostic drivers. But note, currently there are a lot of variants of embedded_hal, including:

1. Stable 0.2 blocking version.
2. Stable async version via nb crate (but seems like i2c is not supported in this variant).
3. Unstable 1.0 blocking version.
4. Unstable async version using rust's native async.

In my new projects (like max31855 driver) I use only 3 and 4 variants (because all platforms I have already support 1.0 version of embedded_hal). But using 0.2 and 1.0 blocking traits probably will be the most universal way to support most of the platforms.

For your driver you could use I2C trait (blocking 0.2, blocking 1.0, unstable async). esp-hal already implements first two and has plans to implement new async version too.

[ewrogers]

Thank you so much for this! Between your explanation and repo I think I can piece together what to do. I'd rather "future proof" in a sense and support v1 stuff like you mentioned.

I think that provides a good enough compromise of code-reuse without burdening myself as a library maintainer full-time, when in reality I just wanted to make it as part of a larger project.

[bjoernQ]

Answer by @chvllad is really great and complete

Only thing to add might be: EH1.0 is currently still alpha and there might be changes - so until it's finished there will be some maintenance needed - especially not every HAL will adopt every new alpha version immediately

But besides that, EH1.0 is probably the way to go long-term

Looking forward to your driver implementation

[ewrogers]

It's a work in progress, but is functional at the moment. INA3221