Ah yes. Sorry, I forgot that every transaction starts with an address. Not just after start condition.
Yes, I think the API is OK as is. > On Apr 19, 2016, at 12:46 PM, [email protected] wrote: > > Thanks Marko. > > Regarding the address, that is what I was originally thinking, but the > protocol sends the address in every read or write, so I would have to > ³store² it in the driver state. Its just another byte, but I suspect the > application is already storing it anyway. If you don¹t mind the extra > byte of storage I could move it to the start command. > > OhŠ It may be a bit confusing, but take the i2c serial eeprom example > where this is a device address and a memory address. > > To do a random access read, you write the memory address into the chip, > then read back the number of bytes (auto-increment). > Both the write and the read commands take the device address. This is > because the low bit of the address field in the protocol specifies the > direction of the command (R/W). > > If the device is not there there is a timeout as there are rules about the > ack speed (next clock). > If the device is misfired, you typically cannot issue a start condition, > so the read/writes fail. I only tested this condition when there are no > suitable pull-ups on the bus. > > > > > On 4/19/16, 12:13 PM, "marko kiiskila" <[email protected] > <mailto:[email protected]>> wrote: > >> Hi Paul, >> >>> On Apr 19, 2016, at 11:42 AM, [email protected] wrote: >>> >>> All, >>> >>> Please take a look at the i2c HAL api in >>> >>> https://github.com/apache/incubator-mynewt-core/pull/44 >>> >>> I chose a simple blocking API for now to get some I2C functionality >>> fast. Its mostly just read/write, with a few other functions. >>> >>> >>> 1. probe - I found that immediately after writing this I need some >>> way to discovery what was on the bus. I wrote this simple function to >>> look for a single address. >>> 2. Start/stop - Many devices are just read/write registers so there >>> is no need to control transactions on the bus. However, for serial >>> eeprom random access, its more efficient to write an address then read >>> the data. In this case you would issue start,write,read,stop. >> >> >> What¹s a bit confusing about the API is that the i2c address is present >> in argument for both read and write operation. To me it would make >> sense to include the i2c address in the call to start(), but not to >> read()/write(). >> >> Let¹s say I have device with i2c address X. And what I need to do >> is write 2 bytes of address to it, followed by read of 1024 bytes. >> So the transaction would look like : start - send address - write 2 bytes >> - read 1024 bytes - stop. >> >> Also, if i2c bus is busy/miswired is there a way to time-out during start? >> I think I also want a timeout when sending i2c address; in case the >> device is >> not there. >> >> Hope this helps, >> M
