Async callback support in nrf connect i2c drivers

I'm working on porting an existing product based on NRF5 which uses the nrf_twi_mngr with asynchronous calls in its drivers.  The drivers takes advantage of the non-blocking queue-based operation with callbacks to link operations together within ISR's.  By sizing the queue appropriately the drivers could avoid blocking when submitting operations.

Has anyone ported the nrf_twi_mngr to Zephyr?  

Is there any equivalent mechanism within Zephyr?

I want to avoid re-writing the driver since its working well in the existing product, any gotchas I should look out for if I try to port or implement a similar queueing mechanism?

a*

Parents
  • Hi there,

    We have not ported the twi_manager lib to Zephyr. But if the only feature that you want is to do non-blocking read/writes then you can use the Zephyr I2C lib, as it supports async read/writes,

    regards

    Jared 

  • The zephyr i2c.h provides an API template for async (callback) operations, however Nordic's drivers do not implement the API function for the async/callback operation.

    Also Zephyr's API for async/callback does not easily support flexible queueing like work queues since the parameters are passed as distinct arguments instead of in a static/persistent data structure which could include space for an slist node or a worker.

    Without the queueing yes the operations may be non-blocking (depending on the implementation), but they will fail with an error if the driver is busy with another operation, and then the driver itself would need to implement a retry through some other queuing mechanism such as a work queue.

Reply
  • The zephyr i2c.h provides an API template for async (callback) operations, however Nordic's drivers do not implement the API function for the async/callback operation.

    Also Zephyr's API for async/callback does not easily support flexible queueing like work queues since the parameters are passed as distinct arguments instead of in a static/persistent data structure which could include space for an slist node or a worker.

    Without the queueing yes the operations may be non-blocking (depending on the implementation), but they will fail with an error if the driver is busy with another operation, and then the driver itself would need to implement a retry through some other queuing mechanism such as a work queue.

Children
No Data
Related