Legacy HAL TIM interrupt callbacks?

[martincho]

In studying "stm32f0xx_hal_tim.c" I came across this:

 case HAL_TIM_PERIOD_ELAPSED_CB_ID :
 htim->PeriodElapsedCallback = HAL_TIM_PeriodElapsedCallback; /* Legacy weak Period Elapsed Callback */
 break;

It says "legacy". This implies there's a new-and-improved way. Where do I find this information?

Thanks.

[KnarfB]

In STM32CubeMX under Project Manager Advanced Settings there is a Register Callback pane where you can choose between the "legacy" callbacks (based on the weak linking feature of functions with a predefined name) and a different, C function pointer based callback scheme. The legacy scheme is more compiler/linker dependent and does more global namespace "pollution", but I see no drawbacks otherwise.

hth

KnarfB

[martincho]

Is it the "Generated Function Calls" section?

In other words, if you opt not have have MX generate a callback you are responsible for pointing to your ISR through the appropriate entry in the NVIC vector table. Is this correct?

This seems cleaner and, if I dare use the term, more traditional. In looking through some of the HAL code it seems that there might be opportunities to trim fat. Not because the code isn't good, it's a simple reality of code that is written to cover every possible configuration rather than a potential narrow use of the hardware. As a generic statement, if I am only using one mode for a peripheral I can check for that one mode and everything else is an error. The more general approach is to check and provide an implementation path for every single mode.

[KnarfB]

You can do it your way, but that is not the choice between the two HAL implementations I ment. Look at stm32f0xx_hal_tim.c line 3801 for example:

#if (USE_HAL_TIM_REGISTER_CALLBACKS == 1)
 htim->IC_CaptureCallback(htim);
#else
 HAL_TIM_IC_CaptureCallback(htim);
#endif /* USE_HAL_TIM_REGISTER_CALLBACKS */

The "legacy" callback is a function which must be named HAL_TIM_IC_CaptureCallback and implemented in your code. It is then called from HAL in line 4 above.

The opposite HAL way is that you register any function with HAL_TIM_RegisterCallback as HAL_TIM_IC_CAPTURE_CB_ID function. HAL stores a pointer to that function and then calls it in line 2 above.

HAL helped me alot to familiarize with the peripherals in many simple standard scenarios. When things get more complex or performance must be improved, you might have to dig deeper.

[martincho]

Thanks for the guidance. I'll study HAL code for details.

Yes, HAL is fantastic. I am in the process of learning STM32 architecture for a project and it is definitely a great starting point. Also, I was planning on porting over my own RTOS I wrote many years ago and have been using successfully for other architectures but I think in this case I am going to make the jump and use FreeRTOS for this project. The key for me is that there seems to be a great deal of support from ST and others, something that did not exist at this scale twenty years ago (well, without spending tons of money) when I wrote my own RTOS.