> On Jun 6, 2016, at 1:09 PM, Sterling Hughes <[email protected]> wrote: > > :) > >>> * 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.
+1 as well. Simpler is better here. > 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
