nrf_drv_twi dynamically adjust receiving length

[joe.ker]

Hi,

I am porting a NCI (Nfc Controller Interface) driver to the nRF52. One of the things I am struggling with is that, when reading from the device, the amount of data to be read is part of the first 3 bytes. Is it possible to set up a transfer of 250 bytes and the, after reading the first 3 bytes, downsizing to the right amount of bytes (which is part of these first 3 bytes) without interrupting the transfer?

Thanks and regards, Josef

[Phil Young]

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.

[endnode]

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"?

[endnode]

(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?)

[Phil Young]

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.