Currently, the I2C service interface always passes around a FixedVec of bytes for input/output buffers. We have a mode where the same buffer is reused across multiple I2C transactions in order to reduce malloc/free overhead, which is good.
But, a vast majority of I2C transactions are either:
1-8 byte writes,
writing to a register address on the target (1-8 byte address write + 1-8 byte data write)
reading a register address on the target (1-8 byte address write followed by a 1-8 byte read)
It would be nice if these common I2C transactions could be performed without needing a FixedVec at all, using little arrays.
On the D1, the I2C peripherals (TWIs) support a mode ("TWI driver") where the I2C state machine is offloaded from the CPU to the peripheral. This mode only supports performing register accesses with addresses (the second two bullet points above). In order to support all possible I2C operations, which may not follow a register-based protocol, our driver for the TWI hardware currently only uses the lower-level non-offloaded "TWI engine" mode of operation. But, if we special-case register read/write transactions, we could use the TWI driver offload in the cases where the I2C transaction being performed matches the type of transactions it supports.
Currently, the I2C service interface always passes around a
FixedVec
of bytes for input/output buffers. We have a mode where the same buffer is reused across multiple I2C transactions in order to reduce malloc/free overhead, which is good.But, a vast majority of I2C transactions are either:
It would be nice if these common I2C transactions could be performed without needing a
FixedVec
at all, using little arrays.On the D1, the I2C peripherals (TWIs) support a mode ("TWI driver") where the I2C state machine is offloaded from the CPU to the peripheral. This mode only supports performing register accesses with addresses (the second two bullet points above). In order to support all possible I2C operations, which may not follow a register-based protocol, our driver for the TWI hardware currently only uses the lower-level non-offloaded "TWI engine" mode of operation. But, if we special-case register read/write transactions, we could use the TWI driver offload in the cases where the I2C transaction being performed matches the type of transactions it supports.