colin wrote:But I do have concerns with the generality of the API and its flexibility. In particular, it looks like the current implementation requires that any message received by the slave from the master, or send as a reply to the master, must fit entirely in a RAM buffer.
Is there a way to allow for reads and writes of indefinite size? The slave should also be able to NAK any received byte as well, e.g. if an invalid command code is received.
My own usage of I2C over the years has rarely needed message lengths of more than 150 bytes or so, and in my particular applications any size constraint has been fairly straightforward to work around. I can see there might be applications where longer messages are needed, but mostly I would expect shorter messages (<256 bytes) to be more usual, and perhaps more in the spirit of I2C. Certainly the existing ChibiOS master I2C driver only supports message lengths up to 255 bytes, and I haven't come across any suggestion that it should be increased. (Possibly message length is platform-dependent? I found the size_t limit of 255 on 32F051).
Transfer time is potentially an issue with larger messages, certainly at 100kHz or 400kHz.
colin wrote:Is there a way to allow for reads and writes of indefinite size?
Initial reaction is that, as Giovanni says, handling large reads and writes would make things much more complicated. And the 'new' driver is already relatively complicated, IMO - partly down to the implementation on the 32F4.
The ability to NAK any received byte mandates interrupt-driven transfers (rather than DMA) with all the overhead that entails. I have got this partially working (on the original 'master' driver) with a callback on every byte - in my case because I wanted to stop transfers on receipt of a specific character, but could also be used to fill a buffer with data, handle variable length messages, or process received messages on the fly. This might be a more practical way of handling large messages than chaining DMA buffers.colin wrote:The slave should also be able to NAK any received byte as well, e.g. if an invalid command code is received.