Clarification on nrf_drv_twi_rx being blocking

RE: Clarification on nrf_drv_twi_rx being blocking

Einar Thorsrud — Wed, 15 Sep 2021 09:17:13 GMT

Do you still see the unknown interrupts if you comment out the TWI code so there are no TWI interrupts? 1 ms could match a typical tick rate for FreeRTOS, for instance.

RE: Clarification on nrf_drv_twi_rx being blocking

morpho — Wed, 15 Sep 2021 06:33:45 GMT

twi interrupt is the only interrupt configured in my application and I was curious if you could see if the interrupt info in the screenshot actually relates to twi interrupt handler (doesn't make sense since the interrupt doesn't fire that fast in an application itself) but do you see why could be causing this?

RE: Clarification on nrf_drv_twi_rx being blocking

Einar Thorsrud — Tue, 14 Sep 2021 06:40:15 GMT

Hi,

I did not see a clear link between the image and the question about TWI to be honest. I do not see anything there, other than as you say you have a interrupt that looks like it happens every 1 ms and that runs for 11.5 us. I cannot say from this what i tis though.

RE: Clarification on nrf_drv_twi_rx being blocking

morpho — Tue, 14 Sep 2021 06:22:50 GMT

RIght on. Using task notifications sounds like a better approach which seems to be a lightweight version of semaphores in FreeRTOS. After the read call, `ulTaskNotifyTake() to take a semaphore, which supposedly puts the thread into sleep until it's woken up within an twi_handler() via vTaskNotifyGiveFromISR()

Do you have any idea about the image I shared?

RE: Clarification on nrf_drv_twi_rx being blocking

Einar Thorsrud — Mon, 13 Sep 2021 12:22:33 GMT

Hi,

[quote user=""]nrf_drv_twi_rx and nrf_drv_twi_tx are non blocking calls? [/quote]

The driver supports both blocking and non-blocking (asynchronous) mode, depending on how you initialize it. If you provide an event handler, calls will be non-blocking. See driver documentation for details.

[quote user=""]Is this how the driver call is typically used...to avoid invoking it before the current read is done?[/quote]

You typically do not want to busy wait like this as it prevents other (same or lower priority) tasks from running, and it wastes CPU cycles and thus power. In a real application you instead typically want to be in idle while waiting for the interrupt you get when the operation has completed. In other words, both busy waiting (waiting loops) and blocking mode are primarily suitable for as simple as possible demo code and experimentation, but not something you normally want to use in production code.