Need a path through the TWI/I2C configuration maze.

RE: Need a path through the TWI/I2C configuration maze.

Andy — Thu, 04 Apr 2019 17:49:11 GMT

Yes, you can pass NULL to the user_function parameter if you don't need that feature. Just read the documentation for those two functions (schedule and perform) and you should be able to understand. It's pretty self-explanatory.

RE: Need a path through the TWI/I2C configuration maze.

Mike Wirth — Thu, 04 Apr 2019 17:15:04 GMT

Got it (all but the last sentence anyway; will check that out). Will look at the example code again.

BTW, I'm presuming that I can put NULL in for the callback argument to the transaction if I don't need a callback (e.g., if I'm using perform) and that'll work OK.

Thanks

Mike

RE: Need a path through the TWI/I2C configuration maze.

Andy — Thu, 04 Apr 2019 15:04:33 GMT

Are you looking at the twi_master_using_nrf_twi_mngr example project?

That one uses blocking calls, that's why there's no callback. With the manager you have two ways of using the module: nrf_twi_mngr_schedule() and nrf_twi_mngr_perform(). Schedule is non-blocking and Perform is blocking.

When you use schedule you can specify a function to be called when the scheduled transaction is finished (callback).

When you use perform you can specify a function that will be called while the transfer is in progress.

RE: Need a path through the TWI/I2C configuration maze.

Mike Wirth — Thu, 04 Apr 2019 14:45:38 GMT

Thanks, Andy, for the quick reply.

Attempting to forge ahead by adapting the "nrfx" example in Ayden's post (linked in the middle of my original post above). In his case, he defines an interrupt handler. All well and good. But in the TWIM example app, I don't see a handler being defined, i.e., the nrf_twi_mngr_callback_t type is never used.

Does this mean that the TWIM library supplies its own, internal handler?
And the user can override(?)/supplement(?) its behavior by defying a new function of type nrf_twi_mngr_callback_t?
How would this function be registered with the TWIM Mngr instance?

Without my own interrupt handler, does this mean that I have two possible ways of executing transactions:

BLOCKING MODE: Zero or more nrf_twi_mngr_schedule calls to queue up some transactions, followed by a nrf_twi_mngr_perform call to queue the last one and wait for completion of the full sequence, or
NON-BLOCKING MODE: Schedule all transactions with nrf_twi_mngr_schedule calls and use nrf_twi_mngr_is_idle to check on the state of their completion?

Or do I have this all wrong, and a handler is specified for each transaction within the nrf_twi_mngr_transaction_t struct?

Mike (searching through the SDK docs and TWIM sample code for enlightenment)

RE: Need a path through the TWI/I2C configuration maze.

Andy — Thu, 04 Apr 2019 12:05:59 GMT

I would recommend you to take a look at the nrf_twi_mngr library. That's what I'm using and it's pretty straight forward. You would have to write a similar wrapper to work with the nrf_drv_twim library anyway, otherwise it's quite clumsy to use those functions directly.

Regarding your questions: I think not even the guys at Nordic know exactly the differences between the nrf_drv_xxx and the nrfx_xxx libraries. I've seen several threads where they recommend using one instead of the other.

The sdk_config.h thing is also a bit of a mess, especially if you don't use the wizard thingy. It became even worse now when they split and duplicated NRF_ and NRFX_ definitions. There's a "glue" header file that redefines all the NRFX_ macros with the legacy ones (I learned that the hard way).