STM32F37xx migrating standard peripheral driver to HAL/LL, and FreeRTOS default task question

[Dazai]

I am working on updating a relatively old Atollic TrueSTUDIO FreeRTOS project for an STM32F37xx microcontroller to STM32CubeIDE.  I have successfully ported and built the project in STM32CubeIDE using the Atollic project import tool.

I have a few questions:

1. The project uses standard peripheral drivers developed by ST (copyright 2012), and the source files were copied into the project rather than being added as references. I'd like to update the project so the drivers reference either the current HAL or LL libraries, is one of them a more suitable replacement for the standard peripheral drivers (i.e. does one of them supersede the standard peripheral drivers)?

2. I also started building a new project completely in CubeIDE to update both the drivers and FreeRTOS source, and plan to add/update the custom source files from the old project to the new one. The old project calls FreeRTOS functions directly, without the middleware abstraction provided by ST, e.g. xTaskCreate() instead of osThreadCreate(), and I'd like to use that approach rather than the middleware abstraction. Is there a way to instruct the device configurator not to generate the middleware abstraction functions and use the FreeRTOS functions instead, or do I need to do that on my own?

Additionally, it appears an additional "Default Task" is needed by the middleware abstraction, which seems problematic since it's adding an additional task to the scheduler that was not in the old project.  It's not very clear from the description in the configurator (below) when this task is actually needed; can it be safely removed if the middleware abstraction is not used?

[Pavel A.]

> I'd like to update the project so the drivers reference either the current HAL or LL libraries, is one of them a more suitable replacement for the standard peripheral drivers 

If not sure (and have enough free memory) start with HAL, as majority of new examples are in HAL. Optimize later.

>  The old project calls FreeRTOS functions directly, without the middleware abstraction provided by ST, e.g. xTaskCreate() instead of osThreadCreate(), and I'd like to use that approach rather than the middleware abstraction. 

A very good approach IMHO. I'm with you 100%. Away with useless layer of сrap, it is like wearing a mask ))

>  Is there a way to instruct the device configurator not to generate the middleware abstraction functions and use the FreeRTOS functions instead, or do I need to do that on my own?

Short answer, no. You'll do on your own.

> it appears an additional "Default Task" is needed by the middleware abstraction, which seems problematic since it's adding an additional task to the scheduler that was not in the old project.

Extra task means extra memory for its stack and more overhead. Again if there's enough memory, just accept it, get your project running, optimize later.  But note that some things should be initialized in context of a task rather than before the RTOS starts, mainly because of interrupt handling in the RTOS. Probably you already know about this.

Do not take the Cube generator too seriously, it is only crutches to help you start. Later you push it away and move by yourself. Good luck.