That's a good point! Also, it may be challenging to take something implementing AdcChannel in a library if there's no way to tell what the voltage 'could' be.

However, how do you ask every implementation to know the voltage range of an arbitrary device? Would having an Option<Voltage> suffice? (i.e., we 'ask' the implementation to tell us if it knows)

My apologies if I've missed your point, though! 😄

I have changed the API here now to measure voltage instead of the raw value.

the voltage range of an arbitrary device

I think you may have indeed missed my point. 😄 I am talking about the voltage range of the ADC itself. So it's not an arbitrary device's voltage, but the voltage the ADC is actually measuring. For example, with a 16-bit ADC with a range of ±5V, this means i16::MIN corresponds to -5V and i16::MAX to +5V.

Then you can swap out ADCs, as long as they support the range you need. And the rest of the code only depends on the measured voltage. As a simple example, I have a water depth sensor with a range of 0-5V corresponding to 0-5m, which would be a 1:1 mapping from mV to mm. So as long as I have any ADC that can measure between 0 and 5V, I can implement e.g. a WaterDepthSensor using the trait.

Got it - I thought I was missing something! Thanks for the clarification ☺️

Given ADCs measure either voltage or current, I have now split the AdcChannel trait into Voltmeter and Ammeter traits.

I would be interested in seeing this gain more traction. My particular use case is for developing generic drivers for analog temperature sensors. Would be nice for the drivers to not have to depend on any particular ADC implementation.

I personally have two problems with this approach:

• There are no unit types for returned values, so it's C-style remember the unit of your integer approach
• These traits assumes the driver implementing can know actual voltage/current of the reference in the design, but that might be a board specific or even calibration specific; in result that looks far reaching w/o some intermediate layer

I may be plain wrong, but I raise this based on my past experience.

There are no unit types for returned values, so it's C-style remember the unit of your integer approach

Currently it's mV with measure_mv and mA with measure_ma. It follows the API design for Delay with e.g. delay_ms, which also doesn't have unit types.

These traits assumes the driver implementing can know actual voltage/current of the reference in the design, but that might be a board specific or even calibration specific; in result that looks far reaching w/o some intermediate layer

I think it comes back to what I wrote in the first comment:

Is it even practical to have this trait without having a corresponding unit and a lower/upper bound for converting the raw value?

How would a trait look like without voltage/current? You cannot implement a driver against a raw value without unit. If the voltage is board-specific or calibration-specific, you will need to write a specific Voltmeter implementation for getting the voltage in any case.

How would a trait look like without voltage/current? You cannot implement a driver against a raw value without unit. If the voltage is board-specific or calibration-specific, you will need to write a specific Voltmeter implementation for getting the voltage in any case.

How about sound samples then? PCM writes a word per sample, but it's not voltage. Consumer grade equipment uses nominal level of 0.316V (-10 dBV) while professional uses 1.228V (+4 dBu). Peak amplitude (saturated sample) are 0.894V and 3.472V respectively.

If the driver converts directly to voltage first, then application back to PCM sample, that's inefficient.

But I may be wrong.