On 6 Jun 2016, at 12:56, marko kiiskila wrote:
On Jun 2, 2016, at 5:07 PM, Sterling Hughes <[email protected]>
wrote:
...
:)
Right now, we don’t have a drivers interface, and the HAL is
dual-purposing both. The ADC is a good example of this, so I’ll
focus in on that API.
…
:)
* The hal_adc_read() function blocks on read. This is for user
convenience, but does not represent how the underlying hardware
implements an ADC read.
Should we have non-blocking implementation available as well?
IMHO, it’s easy to use non-blocking implementation in a blocking
fashion, but doing it the other way around is not as easy.
This is especially important with HALs which go over a bus (I2C, SPI).
I admit, I don’t have much experience with use of ADC peripherals
themselves.
My view: we should remove blocking, have a non-blocking only version and
remove sysid mappings.
* hal_adc_start(adc0, mode, my_callback_func); // see desc below
* hal_adc_rdy(adc0); // is there a reading (doesn’t block)
* hal_adc_read(adc0); // read the value of the adc, doesn’t block
* hal_adc_stop(adc0); // stop in free running mode.
Where my_callback_func is the callback that’s called when a reading is
available. this is called from the interrupt context. Mode is either
free running, or one-shot.
We should also have functions that map to approximation and sampling,
gain & offset, as that is common across most peripheral implementations
that I have seen.
Sterling
