STM32F4 HAL Driver Callbacks

[matthewgkerr]

Posted on December 11, 2016 at 03:15

Hi.

I am developing for an STM32F4. I'm using STM32CubeMX and System Workbench for STM32. I'm using FreeRTOS. I would like to know how I should, and should not, be using the STM32F4 HAL Driver callbacks. 

As an example, I'm using HAL_CAN_RxCpltCallback. Within this call back, I decode and validate the CAN frame, and then generate a number of different events (i.e. using xQueueSendFromISR). Or in some cases, I populate a CAN frame in response, and send it within the callback. Currently I have 300 lines of code in this specific callback.

Ideally, I would make the callback easier to read, by calling out to additional functions; i.e. if the CAN frame/message is a request for date, then call handleRequestForData(), and so on.

However, I can see that 

HAL_CAN_RxCpltCallback is called from HAL_CAN_IRQHandler. So I take it that HAL_CAN_RxCpltCallback is also an IRQ. And its my understanding that I should keep all IRQ's short, and not to call out to other functions (due to stack size limitations).

So my question is, should I minimize the amount of code in my callbacks. And in this case, simply push the CAN frame into another queue for another task to handle it?

Thanks, Matt.

[Oliver Beirne]

Posted on December 11, 2016 at 03:19

Hi Matt

I have moved your query to the

https://community.st.com/s/topic/0TO0X000000BSqSWAW/

‌ where the right people will see your question. If you have any questions around using STM products in the future please select the correct option from the Forums menu at the top of thios page.

Thanks and welcome to the community

Oli

[valentin]

Posted on December 12, 2016 at 03:53

What you can do - as you are using FreeRTOS - is create threads to handle whatever you want to do with your CAN frames.

If you tell your thread to suspend right afer the start of the loop you can use FreeRTOS' xResumeFromISR to execute the thread only once. This execution will then happen outside of the ISR and instead use the normal thread priorities. It basically becomes a regular function that is callable from within an ISR.

I don't have any example code at hand right now but I hope this came across understandably.

I am actually facing a similar problem right now - so I'll keep an eye on this, because I also need timely processing of the CAN data.