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.

Reply via email to