I2C Read with length in the first byte of the transaction

[Andrew P. Lentvorski]

I'm trying to communicate with an I2C chip which returns the length of the bytes to be read in the first byte of the transaction.  This is fairly straightforward on most primitive microcontrollers.

But for the life of me, I cannot figure out how to do this on Linux.  A "read" always wants to put a stop bit after the transaction.  I see "I2C_M_NOSTART" which is probably what I need for the data bytes, but I don't see a corresponding I2C_M_NOSTOP which is what I need for the first byte.

Any help would be appreciated.  Thanks.

What I need is this transaction sequence:

<START> <len byte:0x02><ACK>(PROBLEM HERE--master processes length byte)<data byte:0x00><ACK><data_byte:0x01><NACK><STOP>

[evilwulfie]

what part

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/2e7ae77f-21b3-46c2-9aff-4a32201bed55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew P. Lentvorski]

Under NDA.  So, not in linux database.

[Andrew P. Lentvorski]

Erm, unless you mean board.  I'm using a Beaglebone Black Rev C running debian.

uname -a

Linux beaglebone 4.9.36-ti-r46 #1 SMP PREEMPT Tue Jul 11 21:05:08 UTC 2017 armv7l GNU/Linux

On Monday, February 12, 2018 at 5:07:37 PM UTC-8, Wulf Man wrote:

[Andrew P. Lentvorski]

Looking at the driver at: https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-davinci.c

It looks like i2c_davinci_isr() only terminates a read via terminate_read() which doesn't seem to have an exit path for completion without STOP.

It would be nice if somebody with more experience than me could verify this, as I'm going to have to go to a bit-banged driver otherwise.

[Graham]

Sounds like another goofy TI I2C (USB-C part?) slave interface.

Two thoughts ...

Is the part smart enough to send a "STOP"  after it has transferred the (variable) length read? Or does it just keep going?

If the part is smart enough to send a stop when it is done, wrap an error handler around a [equal to maximum} byte read transfer, and let it exit gracefully on the error condition when the part sends a "premature" stop.

Then process what it gave you.

Worst case, you always read the full maximum length buffer and process according to the initial byte length given.

Reference:    https://www.kernel.org/doc/Documentation/i2c/dev-interface

--- Graham

==

[Andrew P. Lentvorski]

Well, if the SMBus Specification Version 2.0 Section "5.5.7 Block write/read" is goofy then, um, okaaaaay ...

However, since this appears to be a standard part of SMBus, now I really do wish to ask "How do I do this with the Linux I2C drivers?"

[Graham]

As I read the Linux SMBus drivers spec, AND the SMBus Specification Version 2.0 Section "5.5.7 Block write/read"

The block write contains the length of the block to write.

The Read block DOES NOT contain the length of the block to read.

The only parts I have ever seen that implement a length on the Block Read are some goofy TI USB-C devices.

See my previous email regarding what I suspect your options are.

--- Graham

==

On Thu, Feb 15, 2018 at 8:05 PM, Andrew P. Lentvorski <bsd...@gmail.com> wrote:

Well, if the SMBus Specification Version 2.0 Section "5.5.7 Block write/read" is goofy then, um, okaaaaay ...

However, since this appears to be a standard part of SMBus, now I really do wish to ask "How do I do this with the Linux I2C drivers?"

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/IRYoS2ORwWI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a7b322ee-3e44-45b7-a8cd-1477824d6473%40googlegroups.com.

[Graham]

I will correct myself.

The Linux SMBus drivers do not include the bytle length in the read function call.

The SMBus spec does describe a block read transaction byte length.

Have you tried to use the Linux drivers to see if they handle the length byte internal to the function call?

Or ...

Otherwise try a maximum length read, and see what happens.

--- Graham

==

On Friday, February 16, 2018 at 7:17:52 AM UTC-6, Graham wrote:

As I read the Linux SMBus drivers spec, AND the SMBus Specification Version 2.0 Section "5.5.7 Block write/read"

The block write contains the length of the block to write.

The Read block DOES NOT contain the length of the block to read.

The only parts I have ever seen that implement a length on the Block Read are some goofy TI USB-C devices.

See my previous email regarding what I suspect your options are.

--- Graham

==

On Thu, Feb 15, 2018 at 8:05 PM, Andrew P. Lentvorski <bsd...@gmail.com> wrote:

Well, if the SMBus Specification Version 2.0 Section "5.5.7 Block write/read" is goofy then, um, okaaaaay ...

However, since this appears to be a standard part of SMBus, now I really do wish to ask "How do I do this with the Linux I2C drivers?"

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/IRYoS2ORwWI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.