> On Aug 25, 2016, at 1:36 PM, Sterling Hughes <[email protected]> wrote: > > Hi Kevin, > > On 25 Aug 2016, at 9:49, Kevin Townsend wrote: > >> Although, this will also depend on how things are implemented in the .c code >> ... I only see the header at present. But from experience some sensors >> require the stop to be handled differently between multiple read or writes, >> so it's worth considering how to keep the STOP condition flexible and under >> user control since there isn't a one size fits all approach for every I2C >> sensor out there. >> >> > > Yeah, most of the vendor APIs I see have the stop bit as an option (or by > default) after a write() command, whereas our HAL APIs use begin() and end() > to generate stop conditions. Frankly, I think it might make more sense to > label these start() and stop(), because a lot of the I2C protocols can have > multiple start conditions and multiple stop conditions. Or maybe a control() > command that takes either START or STOP, to make it clear that it’s not > modifying transaction state in anyway. > > Sterling
+1 on calling them start() and stop(). dg -- 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
