nrf_twi_mngr_perform blocking

[Jason Hendrix]

I've been using the nrf_twi_mngr_perform() function assuming that my transaction was complete when the function returned.  Because of this, I felt safe keeping my descriptors on the stack.  However, it appears to me that if there are other transactions pending (placed via nrf_twi_mngr_schedule), the transaction you want to block on will be queued, and you will instead block on whatever the oldest transaction in the queue is.  Unfortunately for me, my function exits, my descriptors go out of scope, and then my transaction is executed sometime later.   It would be nice if the queue was double-ended and you could "pop from the back (or front)" when a "perform" was called vs a "schedule".

At this point, it seems to me that one shouldn't mix the use of "schedule" and "perform".  Is that correct?  Or am I mis-using the library?  Thanks.

I'm working on a custom board based on the nRF52832. I'm developing on Win 8.1 using SES and a J-Link Plus. SDK version 14.1.

[Rune Holmgren]

I am not 100% sure I understand what your problem is, the description of what you are doing seems like a correct way queue and perform blocking and non-blocking TWI operations. Let me know if I misunderstood you.

It is perfectly fine to mix "schedule" and "perform" calls to the nrf_twi_mngr. Schedule calls will not block but return immediately. Scheduled operations will be performed when the bus is available. Perform calls can queue one or more operations and will block until the operation is done. Perform calls should not return early, so you shouldn't be able to end up out of scope.

Take care to check all return values from these API calls. Error codes have to be handled, or you may experience packets never being sent.

Best regards,
Rune Holmgren

[Jason Hendrix]

HI Rune,

  I've been delayed slightly - will get back to this in about a week.