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]> 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
