Specify units for ADC HIL #1032
Conversation
Add functions for learning about the ADC resolution and voltage reference. Also change the samples to be left-justified to make it easier to use the result.
kernel/src/hil/adc.rs
Outdated
| /// samples. This allows the user of this interface to calculate an actual | ||
| /// voltage from the ADC reading. | ||
| /// | ||
| /// The returned reference voltage is in millivolts. |
There was a problem hiding this comment.
is in millivolts, or 0 if unknown.
There was a problem hiding this comment.
Would it be more "rust"-y to return an Option<usize> and None if unknown?
There was a problem hiding this comment.
Either of these seems fine to me. get_resolution_bits should work the same way though.
There was a problem hiding this comment.
Is it possible that an ADC wouldn't know the resolution of the sample it is taking?
There was a problem hiding this comment.
Hmm, why should the reference voltage be optional then? If the suggestion is that the reference could be an external pin that the ADC doesn't know, that could be passed into the driver at init time by the board main.rs configuration.
There was a problem hiding this comment.
- That value could instead be passed to whatever would be using
get_reference_voltage(). - If the HW doesn't know, then conceptually it makes sense that it should return that it doesn't know.
- The reference voltage could change at runtime.
|
I changed the title of the PR to be more descriptive, but I'd also greatly appreciate a more verbose description of what this PR actually does for posterity. A reference is nice, but I actually had to look at the code to figure out what change this PR decided to actually make. |
|
@phil-levis I think this is what you'd been advocating for, right? Does this seem good? |
|
Blocked on #1078 |
Pull in NumCell fix from master
|
Almost there. But I need more than 48 hours (including a holiday) to be able to respond to something like this. This should not have been merged.
fn sample_ready(&self, sample: u16);
This needs to have a ReturnCode parameter, in case the sample is bad in some way. This could happen, for example, if you call stop_sampling() when you are in the midst of an I2C operation to an off-board I2C. It might be much simpler for the implementation to wait for the I2C operation to complete but not issue a command to read a value, and signal an event with bad data. Otherwise, if you stop then try to sample again, the sample again might fail because the I2C operation is outstanding.
I.e., stop_sampling can return EBUSY but have sample_ready give you no data. It’s important to be able to do this so you can correctly synchronize the two state machines (caller and callee).
Phil
… On Jul 4, 2018, at 2:36 PM, Amit Levy ***@***.***> wrote:
@phil-levis I think this is what you'd been advocating for, right? Does this seem good?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
The addition of the CHANGELOG documenting the change came in 48 hours ago, but that's just a bit of descriptive text. All of the HIL changes have been here for 9 days with no comments but approvals. That's past the one-week "no comment = approval" period we have for significant PRs, which is why I merged. |
I think you probably mean an off-chip ADC, in which case a |
|
Should there be separate HILs for on-chip vs. off-chip ADCs? That seems not very hardware independent. I think the one place we agreed this was the right decision was GPIO, because forcing every GPIO operation to be asynchronous would be extremely onerous. Examples of errors that the callback might want to give you:
|
I don't know what ADCs look like well enough, but if there is enough of a difference in how the MCU interacts with them, then absolutely YES
It's not. HIL stands for Hardware Interface Layer (not Independence). It's a set of interfaces to very similar hardware.
OK, totally! This is an overrun basically, because the client ask for too many values or something? I don't know ADCs well enough, but if this isn't an error that can be caught earlier, it seems totally reasonably to put it in the callback.
Wouldn't either the client know it turned it off or the start function be able to immediately return that the ADC is off? Maybe I'm misunderstanding the scenario.
Same. The client should know it cancelled the acquisition. |
|
Hardware Interface Layer (not Independence). It's a set of interfaces to very similar hardware. Oh! OK. I guess the general point is that the asynchrony caused by a bus is very similar to that caused by virtualization. In purely asynchronous I/O systems, this means that an error returned in initiation can deferred to the callback. Wouldn't either the client know it turned it off or the start function be able to immediately return that the ADC is off? Maybe I'm misunderstanding the scenario. What if more than one capsule has access to this trait? Or what if there is a bug in the client, such that it incorrectly turns off the ADC during a sample? Just as a read/write in POSIX file I/O will return with an error code, you should get a callback with an error code. You don't want to block forever. |
Pull Request Overview
This pull request updates the ADC HIL. See #1008 for more details.
Testing Strategy
This pull request was tested by compiling.
TODO or Help Wanted
n/a
Documentation Updated
/docs, or no updates are required.Formatting
make formatall.