See here for context. Basically, in the HID-I2C service, we want to not split our writes into multiple calls into the HAL, because that introduces multiple await points, which leads to clock stretching / hogging the bus. However, right now, the only way to instruct the I2C HAL trait to talk over the bus is to pass it a single slice, which means we'd need to memcpy the input report into a buffer that also contains its header. This is also not great for perf, so we're stuck between a rock and a hard place.
We think the solution is to extend the I2C HAL trait so have a respond_to_read variant that accepts a slice of slices rather than a single slice. This would let us pass disjoint memory to the HAL trait implementation, i.e. the header in one slice and the message in a second slice. This task tracks extending the HAL trait and leveraging the new method in the HID-I2C service.
See here for context. Basically, in the HID-I2C service, we want to not split our writes into multiple calls into the HAL, because that introduces multiple await points, which leads to clock stretching / hogging the bus. However, right now, the only way to instruct the I2C HAL trait to talk over the bus is to pass it a single slice, which means we'd need to memcpy the input report into a buffer that also contains its header. This is also not great for perf, so we're stuck between a rock and a hard place.
We think the solution is to extend the I2C HAL trait so have a
respond_to_readvariant that accepts a slice of slices rather than a single slice. This would let us pass disjoint memory to the HAL trait implementation, i.e. the header in one slice and the message in a second slice. This task tracks extending the HAL trait and leveraging the new method in the HID-I2C service.