I would be ok having the extra flag instead of calls to begin/end.
> On Oct 18, 2016, at 2:58 PM, Kevin Townsend <ke...@adafruit.com> wrote:
>
> I agree designing HALs that play well across vendors is difficult since the
> peripherals have all kinds of limitations and edge cases, sometimes even in
> device families from the same silicon vendor. :(
>
> STOP is the main thing you need full control over though, yes (based on my
> own experience anyway). You can have repeated starts, but some sensors will
> expect: START - READ - STOP - START - WRITE - STOP ... and some will expect:
> START - READ - START - WRITE - STOP, and they often won't work as expected
> using the wrong pattern.
>
> The two gotchas I consistently come across are needing control over when the
> STOP bit is inserted (i.e. having that in the right place in the drivers),
> and more rarely on sensors that use clock stretching making sure that the
> master handles that properly. There are several 'I2C' peripheral blocks out
> there that don't handle clock stretching properly, though this isn't an API
> level issue, rather it's a HW problem (unless you are bit-banging I2C of
> course).
>
> K.
>
>
> On 18/10/16 23:50, will sanfilippo wrote:
>> Well, I do agree that this new API I am proposing is not as clean as the old
>> API; just dont know what else to do. I guess this is part of the problem
>> trying to make generic HALs.
>>
>> At least you will be able to control when the STOP occurs which is the most
>> important thing I think.
>>
>>
>>> On Oct 18, 2016, at 1:24 PM, Kevin Townsend <ke...@adafruit.com> wrote:
>>>
>>> Hi Will,
>>>
>>> Having control over when the STOP happens is important since different
>>> devices will behave differently, especially if you are performing a series
>>> of events like read/write/read or something similar. Some devices expect
>>> the STOP to happen in different places in a command sequence.
>>>
>>> My vote would be a less attractive AP where the stop is a flag. Since we
>>> apparently aren't using _begin to set the START we may as well drop the
>>> STOP being handled in _end, but I'm obviously curious what other people
>>> think here.
>>>
>>> Sending multiple STARTS is perfectly valid BTW:
>>> http://www.i2c-bus.org/repeated-start-condition/
>>>
>>> K.
>>>
>>> On 18/10/16 21:58, will sanfilippo wrote:
>>>> Hello:
>>>>
>>>> I am new to i2c so please bear with me. Hopefully this makes sense to the
>>>> i2c experts out there.
>>>>
>>>> In adding i2c to the nordic platforms I ran across an issue that I am not
>>>> sure how to solve. Well, I know one way to solve it but it would require
>>>> changes to the API. Here is the issue:
>>>>
>>>> In order to get the nordic HW to generate a NACK bit (well, the opposite
>>>> of an ACK) on the 9th bit after a read, you need to do something special
>>>> to the HW prior to reading the last received character. When you do this,
>>>> the HW will generate the correct 9th bit and will also put a STOP
>>>> condition on the line. While it is possible to get the HW to generate a
>>>> STOP independently, I dont see how I can get it to generate the correct
>>>> 9th bit unless you know it is the last character you want to read.
>>>>
>>>> Another issue that is bothersome is the nordic SDK itself: when you are
>>>> done with the read it automatically generates the STOP. That is fine in
>>>> and of itself; the SDK could be modified, but the issue is that dang 9th
>>>> bit.
>>>>
>>>> Our API has the following functions:
>>>> hal_i2c_master_begin(): Not exactly sure what this does on all platforms
>>>> but currently is a NOOP on the nordic platforms.
>>>> hal_i2c_master_write(): generates a start but no stop.
>>>> hal_i2c_master_read(): generates a start but no stop.
>>>> hal_i2c_master_end(): generates a stop
>>>>
>>>> At first glance, this seems to be a fine API and is easy to see a
>>>> “transaction”: a begin, writes and/or reads chained together, and an end.
>>>> Unfortunately, I could not see how to do this on the nordic platforms.
>>>>
>>>> One way to do this would be to get rid of begin/end and have a flag in the
>>>> read/write API. The flag would be “generate stop”. This way users can
>>>> chain reads/writes together and end them with a STOP whenever they want.
>>>> The only con to this is that it is not so easy to look at the code to see
>>>> that transactions have a stop.
>>>>
>>>> Given that I dont have alot of experience wth many i2c devices, I dont
>>>> know if having the ability to skip START and/or address when the
>>>> read/write APIs are called is useful. So far in my limited experience the
>>>> start/address condition between the read/writes is not an issue.
>>>>
>>>> So to summarize, here is what I suggest:
>>>> * Remove the begin/end API.
>>>> * Add a flag to write/read that will cause a STOP to be generated at the
>>>> end of the read write.
>>>>
>>>> Thanks! Comments greatly appreciated.
>>>>
>>>>
>
