SPI HAL

Hello: Since we are on the subject of HALs and blocking/non-blocking interfaces… 1) Looking at the SPI HAL for the slave I am thinking that the API is a bit off. Here are the changes I am considering: a) The per-byte interface is not really practical and can be implemented using the txrx API

Re: HAL & I2C redux

On 25 Aug 2016, at 14:00, Sterling Hughes wrote: Hi, On 25 Aug 2016, at 9:48, Stéphane D'Alu wrote: Hi, You could want to take a look at others. ChibiOS has a nice and clean API. I have taken a look at quite a few (Zephyr, mbed-hal). I just took a look at ChibiOS: I’ll refer to

Re: HAL & I2C redux

Hi, On 25 Aug 2016, at 9:48, Stéphane D'Alu wrote: Hi, You could want to take a look at others. ChibiOS has a nice and clean API. I have taken a look at quite a few (Zephyr, mbed-hal). I just took a look at ChibiOS: I’ll refer to them more in the past. I haven’t paid much attention

Re: HAL & I2C redux

> On Aug 25, 2016, at 1:36 PM, Sterling Hughes 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

Re: HAL & I2C redux

I'd have to look at all the datasheets for the support MCUs, but some MCUs definitely don't play well with clock stretching, I just wish I could remember some examples quickly. We've run into problems with popular SoCs or ICs like the BNO055, which use CS. See this for example for the ESP

Re: HAL & I2C redux

I was wondering about clock stretching as well, and if it all targets do it properly. If not, maybe there should be a way of controlling the data clocking speed. At the moment I read the API such that the MCU would try to clock out data as fast as it can? > On Aug 25, 2016, at 10:45 AM, Kevin

Re: HAL & I2C redux

Hi Sterling (et al), start() and stop() and probably clearer to anyone familiar with I2C, and it removes any ambiguity about if cached data is also being sent. Or the single control() command with a parameter seems fine as well, though that's just my opinion. Something concerning blocking

Re: HAL & I2C redux

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

Re: HAL & I2C redux

Hi, I’d like to have an option to timeout the blocking operations. > On Aug 25, 2016, at 9:38 AM, will sanfilippo wrote: > > Hello: > > Comments: > > +1 on no non-blocking interface. Adding a non-blocking interface later (for > those desiring one) should not be terribly

Re: HAL & I2C redux

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

Re: HAL & I2C redux

Hi, You could want to take a look at others. ChibiOS has a nice and clean API. On 25 August 2016 01:37:05 CEST, Sterling Hughes wrote: >Hi, > >While we’re doing the HAL changes, I’d like folks to check out the >I2C APIs, and provide any comments they have: >

Re: HAL & I2C redux

You might want to consider how to handle the STOP condition ... some sensors have different behaviour about when the stop condition should or shouldn't be set. See the Arduino Wire library for example, who make the stop condition optional when you end the transaction: