nrf_drv_twi dynamically adjust receiving length

RE: nrf_drv_twi dynamically adjust receiving length

Jørgen Holmefjord — Mon, 05 Feb 2018 16:23:20 GMT

The point of the DMA is that the transfers should be able to operate without CPU interaction. If you need to check the received bytes, you can always use the legacy TWI module that is still available in the nRF52832 and nRF52840 ICs. Which specific device are you interfacing?

RE: nrf_drv_twi dynamically adjust receiving length

Phil Young — Fri, 02 Feb 2018 10:04:47 GMT

The system is using I2C in a completely normal manner, but the question is how to know when 1 or 3 bytes have been read in order to determine from the response whether to continue with the read operation. With the interrupt driven device it is possible, but not when using DMA.

In this application the slave always responds with 3 bytes of data but can respond with between 3 and 64 bytes, with the length being encoded in the first bytes. Once an I2C transaction has started the slave cannot terminate it in any other way than stretching the clock long enough to cause a timeout which then wastes time in a recovery process and severely limits the throughout, so a solution to allow the master to detect when 3 bytes have been received ( or even 1 byte ) and use that to determine the length of the read transaction is required for efficiency. In the SW (interrupt driven ) case it is trivial, but with the DMA driven architecture currently implemented it appears impossible).

With the current implementation of the DMA the length of an I2C read transaction must be determined before the read is initiated which is inadequate for this application, hence the request for a way to generate an event after the 3rd byte has been received without terminating the I2C transaction so that SW can interrogate the length and set the actual remaining transaction length before allowing the DMA driven operation to continue.

RE: nrf_drv_twi dynamically adjust receiving length

Phil Young — Thu, 09 Nov 2017 10:16:40 GMT

I have to say Nordic is not alone in this respect, but it is frustrating the amount of time I have wasted with manufacturers datasheets, often finding the information is incorrect. As a developer developing a product with huge market potential and expecting to ship potentially millions of units I feel justified in expecting better documentation, I am the CTO of a company using the product in a volume application, not a hobbyist, and the time wasted with poor documentation from all manufacturers is a serious concern to me.

RE: nrf_drv_twi dynamically adjust receiving length

endnode — Thu, 09 Nov 2017 09:33:36 GMT

(not mentioning that Nordic has large documentation base to both HW and SW and while it's hardly perfect some could be offended by your stupid claim about poor documentation "as usual"... can you name any competitor with better documentation to set some benchmark?)

RE: nrf_drv_twi dynamically adjust receiving length

endnode — Thu, 09 Nov 2017 09:30:25 GMT

Btw. how this relates to the original question where the problem was "how to find out that I2C transfer ended with less bytes received then buffer length"?

RE: nrf_drv_twi dynamically adjust receiving length

endnode — Thu, 09 Nov 2017 09:29:08 GMT

Then this is not how normal I2C works, there should be no time-out if you use clock stretching (or there could be some sort of watch-dog but then both sides need to be ready for certain recovery procedure to set I2C to proper initial state = all HIGH and continue with address sending/reception again).

RE: nrf_drv_twi dynamically adjust receiving length

Phil Young — Thu, 09 Nov 2017 09:21:16 GMT

It appears that it is possible to run the TWI in the legacy ( deprecated ) mode on the NRF52 so it should be OK using the original NRF51 code. For some reason Nordic now appears to have 3 separate I2C interface options, 2 using EZDMA ( 1 master and 1 slave ), and 1 like the NRF51 using interrupts, in reality they are 1 peripheral with 3 modes but Nordic could not even bother to keep them together in the datasheet so it's easy to not notice this point. As usual, the Nordic HW is good but let down by the poor documentation.

RE: nrf_drv_twi dynamically adjust receiving length

Phil Young — Thu, 09 Nov 2017 09:18:09 GMT

If the slave has no data available to send it sends nothing resulting in clock extension by the slave until the I2C times out and the master aborts the transaction, so this would not work.

RE: nrf_drv_twi dynamically adjust receiving length

endnode — Wed, 12 Apr 2017 17:00:39 GMT

Hi, isn't TWI (I2C) read managed by slave ACK/NACK so by putting maximum buffer size (and pointer;) you will read all bytes available up to Slave's NACK (or buffer overflow) and you will then read actual number of bytes read upon NRF_DRV_TWI_EVT_DONE event from nrf_drv_twi_evt_t structure (including data stream itself)?