SPI asynchronoues usage

RE: SPI asynchronoues usage

jfpastrana — Fri, 07 May 2021 08:10:33 GMT

Hello Amanda,

Many thanks for your explanation, now I understand better how to manage the interrupts. Moreover, I did not know this:

The GPIOTE handler will still run in interrupt context and will wake the chip from sleep and jump to the handler before executing the rest of the code in the main-loop. The rest of the code in main-loop will be executed before going back to sleep (unless they have multiple sleep statements in the loop.

Also, I think that I have to implement some scheduling mechanism as you said, in order to be sure that I am not missing CAN frames.

Thanks again for the support, I think that we can tick as close this topic.

Best regards,

Javier

RE: SPI asynchronoues usage

Amanda Hsieh — Thu, 06 May 2021 08:27:10 GMT

Hi Javier,

In general, it is best to not spend long periods of time inside the interrupt handler, as you will be blocking other events with same or lower priority from being handled. Blocking transfer will most likely take the same time or longer than non-blocking, so no difference there. If they should do it inside the handler or outside depends on what else is running in their application, and how long time the transfer will take.

Not sure I understand the concern about missing CAN frames due to sleep in the loop. The GPIOTE handler will still run in interrupt context and will wake the chip from sleep and jump to the handler before executing the rest of the code in the main-loop. The rest of the code in main-loop will be executed before going back to sleep (unless they have multiple sleep statements in the loop.

If they expect more than one CAN frame to arrive before they are able to read out the frames over SPI, they may need some scheduling mechanism that indicate how many frames should be read.

Another option is to use the Advanced usage features in the SPI driver to trigger the SPI transfer directly over PPI from the GPIOTE event. This only works if the transfer can be completed and processed before the next CAN frame arrives, as PPI does not have any ways to check if a transfer is already ongoing.

-Amanda H.

RE: SPI asynchronoues usage

jfpastrana — Wed, 05 May 2021 13:28:12 GMT

Hello Amanda,

First, thanks for your support. Regarding the first question, now it is clearer.

Considering the second question, I have just changed the priorities, giving to SPI priority 3 and GPIOTE keep in 6. If I keep the SPI transfer function inside of GPIO handler it now works, but I am not sure if I am missing received CAN frames.

Now I want to ask you for your opinion /recommendation for one of the following solutions:

Blocking SPI transfer function inside of GPIO handler.
Non-blocking SPI transfer function inside of GPIO handler.
Non-blocking SPI transfer outside GPIO handler, using a flag in main-loop.

Which one is better in terms of robustness??

I have also performed a test using a flag and checking it inside main-loop, but it exits also the possibility to lose some CAN frame due to I have a sleep inside the loop. Any ideas to solve this?

Many thanks and best regards,

Javier

RE: SPI asynchronoues usage

Amanda Hsieh — Wed, 05 May 2021 12:38:31 GMT

Hi Javier,

[quote user=""]I am using SPI Master Driver, even if it is based on legacy driver “SPI/SPIM peripheral driver”. Therefore, is it better to use SPI HAL?? [/quote]

The Hardware Abstraction Layer (HAL) ensures safe register access to a peripheral but is often limited in features. A driver sits atop the HAL and expands on its feature set. Whether you want to use the HAL or driver depends on your specific use-case, many drivers ensure reliable operation of the peripherals that might otherwise be tricky to do by writing a driver from scratch.

[quote user=""]My other doubt begin now, I have configured a GPIO HW interrupt in order to know when I receive a new CAN frame, and afterwards read using SPI library to get that frame. If I use a non-blocking transfer inside of a GPIO handler, my program breaks due to a handler inside of another handler… It is normal. [/quote]

You can do the transfers outside of the GPIOTE handler, by setting a flag and start the transfer in main-loop if the flag is set. Alternatively, you can run SPI at a higher priority than the GPIOTE, to allow the SPI handler to preempt the current interrupt context, to handle the events and set the trasnfer-done flag.

-Amanda H.