> On Jun 6, 2016, at 4: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.

+1 much simpler.

> 
> * 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

--
David G. Simmons
(919) 534-5099
Web • Blog • Linkedin • Twitter • GitHub
/** Message digitally signed for security and authenticity.
* If you cannot read the PGP.sig attachment, please go to
 * http://www.gnupg.com/ Secure your email!!!
 * Public key available at keyserver.pgp.com
**/
♺ This email uses 100% recycled electrons. Don't blow it by printing!

There are only 2 hard things in computer science: Cache invalidation, naming 
things, and off-by-one errors.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to