Need a path through the TWI/I2C configuration maze.

[Mike Wirth]

Sorry, folks, for asking a newbie question.  Well, maybe it isn't such a newbie question after all, but some gaps in the SDK documentation and examples.  Specifically, I'm:

• Using SDK 15.2.0 with an nRF52832 target, building with SES 4.12.
• Trying to do TWI access to a typical register-based device, i.e., first byte of the transfer is a write of the starting register address in the device, followed by a series of reads or writes.
• Nothing else needs to go on in the app while the TWI transfer is being completed, so might as well use blocking I/O.
• Decided to use the high-level TWIM support to keep the code as simple as possible.

Here's where things get interesting:

• There's no clear description of the difference between nrf and nrfx versions, at least at the top level of the docs.  (Do I have to have read all the release notes for prior SDK versions to get this all straight?). Thought I had it straight, but then I keep getting confused.
• EasyDMA or not?  Where is this described? 
• Totally lacking from the examples is any discussion of the proper sdk_config.h settings and why they are the way they are.  And there are lots of them (especially TWI settings). Any attempt to merge two example apps can be fraught with difficulty trying to reconcile these settings, whether done with the wizard or by hand.

About the most useful info I've found is in a discussion here in DevZone, in this exchange:

https://devzone.nordicsemi.com/f/nordic-q-a/36416/twi-i2c-rx-buffer-doesn-t-contain-the-data-received

I seem to have stumbled on a working set of sdk_config.h settings that allow me to merge the TWIM example into one of the BLE peripheral apps.  So I could make headway if:

• Someone could tell me how to modify the example in the posting above for nrf instead of nrfx, and
• If TWIM doesn't allow blocking access, include changes for the interrupt handler as well.

For others who aren't full time developers with the nRF52 series, it would be useful if there were more documentation in the examples, discussing why things are being done the way they are and what variations are possible.  And, of course, document the sdk_config.h settings.

Mike

PS: In spite of my complaints above, I sincerely appreciate the increased effort Nordic has put into supporting a broader developer community.  Hope the suggestions are taken in the positive  way they are intended.

[Mike Wirth]

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) 

[Andy]

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.

[Mike Wirth]

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

[Andy]

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.