I want to do I2C communications based on interrupts (and potentially DMA) rather than polling. Looking over the docs, it looks like the transfer() method is involved. Are there any code samples showing how to use transfer()?
I’d expect this project to run on the bare metal profile if that matters to the answer.
P.S. It looks like I2CSlave lacks a transfer() method, is that right?
May be a really seldom use case, if you want to transfer a lot of data without response.
The biggest continuous stream I had to send up to now was 128bytes and this is done in far less than 1ms.
Clearly, whoever designed Mbed thought the async I/O scenarios important enough to support in the I2C API and HAL.
What seems to lack priority is documentation; e.g.
ASYNC API usage/documentation · Issue #3261 · : closed due to inactivity.
This post makes it look like five years ago there was at least one example available, but the example apparently been removed from the web site.
I don’t understand how project governance works for mbed, but it looks this needs some program management attention.
If you know the I²C protocol and DMA, you may have seen, that with every 8 bits you send, an additional ACK bit must be transmitted. This bit must be part of your DMA buffer. So you need a function which inserts just this one bit between every byte, so a lot of shifting is required to prepare the buffer before it can be sent.
This knowledge is not part of the documentation and if you prepared your buffer correctly, the async IIC transfer should work like with SPi or any other DMA(don’t know whether the documentation is better there). So if this docu really is not understandable, check it somewhere else.
rneg973: Not sure what your reply has to do with my question, but you can’t store the 9th (ACK) bit in the DMA buffer.
The ACK is part of the protocol (not the data) and its value has to be determined dynamically based on the I2C state machine. The ACK bit flows in the opposite direction from the data bits being transmitted.
So for example, if an I2C master is writing to an I2C slave, the master provides the data, and the slave provides the ACKs. There would be no point in storing the individual ACKs anyway, they only matter if missing, (e.g. a NACK) and if/when that happens the transfer would be stopped or restarted, per the I2C spec section 3.1.6.