kurtjd
commented
3 months ago @Dirbaio @eldruin
I have crates for embedded-sensors and embedded-fans (generic traits for interfacing with Sensors and Fans respectively) in a good state though still deciding where they best fit in the community.
I'm guessing such abstractions are beyond the scope of embedded-hal which seems to focus on more low-level peripherals, though if the community thinks they belong here I can see about trying to integrate them. If not, I may decide to look into transferring the crates over to rust-embedded-community.
Any input would be appreciated, thanks!
Hi everyone, a while back a discussion was started about the inclusion of traits for interfacing with sensors (#32) but unfortunately it did not gain much traction. I was hoping to revisit this as I currently have a use-case requiring generic sensor interfacing and would like to get a feel from the community as to whether these traits would fit the goals of
embedded-halor if they are best left to a separate, standalone crate.Regardless, I feel feedback and input from the community regarding the design of such traits would be highly valuable so I would like to open discussion toward that as well (with some topics worth considering below).
Scope
As sensors can vary widely in their functionality and supported features, some thought needs to be put into what functionality should actually be captured by generic traits.
At its simplest, we could have traits which only provide methods for reading data from the sensor. E.g. a TemperatureSensor trait might only provide a read_temperature method, and perhaps additional wrapper types (such as Celsius, Fahrenheit, and Kelvin) as well as associated conversion methods. Any other behavior and configuration would then be behind a purely implementation-defined interface.
At its broadest, in addition to traits for reading values from specific types of sensors, we could provide traits for configuring triggers/alerts, power management, calibration, etc. which can apply to a wide variety of sensors. However, even, say, an AlertTypeSensor trait may need to be split into multiple other traits to adequately capture all the ways a sensor could be configured to trigger alerts if we are aiming to be as generic as possible while not requiring implementers to think of sane ways to implement methods which are not supported by their specific sensor.
Sensor reading type
While different types of sensors may want to wrap the measured reading in unit-appropriate types (such as Celsius, Fahrenheit, and Kelvin for a TemperatureSensor trait as mentioned above) some thought will need to go into what the actual underlying type should be.
If the type is left purely as an associated type to the trait to be decided by the implementer, we run into the difficulties that unconstrained associated types make for writing generic code (hence a large reason for some traits being removed as mentioned in #357). However, if the type is simply defined as f32 for example, this may be problematic for users who wish to avoid floating-point operations. Likely some combination of associated types/generics with appropriate trait bounds will be necessary.