Re: i2c_burst_write API


Erwan Gouriou
 



On 3 April 2017 at 12:35, Jon Medhurst (Tixy) <tixy@...> wrote:
On Mon, 2017-04-03 at 11:55 +0200, Erwan Gouriou wrote:
[...]
> As you described, for burst write operation, only one message has to be
> S Addr Wr [A] subAddr [A] Data [A] Data [A] ... [A] Data [A] P
> (unlike for burst read where 2 messages are expected).
>
> If we keep the burst write API as is, we define an incorrect sequence of 2
> messages:
>     msg[0].buf = &start_addr;
>     msg[0].len = 1;
>     msg[0].flags = I2C_MSG_WRITE;
>
>     msg[1].buf = buf;
>     msg[1].len = num_bytes;
>     msg[1].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

In what way is that incorrect? msg[0] doesn't have I2C_MSG_STOP and
msg[1] doesn't have I2C_MSG_START or I2C_MSG_RESTART, so that is a
correct way of specifying the single write message you want to appear on
the i2c bus.

My view (but this could be an error from my part), is that defining a message
involves having a header byte (Slave Address | Write) being issued before payload.
Payload being:
*subaddress (or start address) in the first msg[0]
*data in msg[1]

Hence, when we define 2 messages, we get, if we set RESTART correctly
msg[0]: S Addr Wr [A] subAddr [A] RS
msg[1]: Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P

Serialized, this gets:
S Addr Wr [A] subAddr [A] RS Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P

While, as explained by Piotr, expected single message (for a burst write) is:
S Addr Wr [A] subAddr [A] Data [A] Data [A] ... [A] Data [A] P

My only issue/question is the message header of the second message that
does not seem to fit the expected sequence (detailed here for instance:
 §5.1.1 in https://goo.gl/sfflM6). And even if we set the correct RESTART
flag, it is not expected by slave (unlike a burst read sequence)
Or there are other possible sequences that I am not aware of.

> and then expect the driver to generate a correct single message.
> I mean this is doable, but adds unneeded complexity and would require to
> explicit the contact in the API.

If the driver inserts stop/start/restart bits between msg[0] and msg[1]
then it isn't implementing the API correctly and should be fixed.

I agree driver should insert START/STOP/RESTART as defined by API and
specification or be fixed otherwise.


--
Tixy

Join devel@lists.zephyrproject.org to automatically receive all group messages.