upgrading FreeRTOS in CubeMXIDE

[Harvey White]

FreeRTOS is currently at 11.0.  The version in CubeMXIDE is 10.3.1.  There are some good features in 11.0 I'd like to use, so the following questions:

• 11.0 is supposed to be a drop in replacement for 10.6.1  I'd do a download, unzip the files, and just replace the project directories, except that:
  • I think any changes to the IOC file will regenerate FreeRTOS from the repository, which ruins the idea.  IOC settings are not set in stone and are likely to change during project development
• Is there a good way to upgrade 10.3.1 to 11.0?  I'm using an L562 CPU.
• Is there any way to upgrade FreeRTOS?
• Do I have to:
  • arrange a project with FreeRTOS
  • update the directory manually
  • somehow remove the FreeRTOS selection from the IOC file
  • somehow hope that the configuration software will not remove all the FreeRTOS files (It does).
  • regenerate everything, and put the FreeRTOS calls in the user sections.....

Any suggestions?

[Pavel A.]

Basically, yes, this can work. When you first choose FreeRTOS, make sure to choose a timer for HAL tick. Test it works. Then act as you've described.

[Oskar_H]

Hello Harvey,

please have a look at my answer to another post about FreeRTOS versions in ST packs.

https://community.st.com/t5/stm32cubemx-mcus/is-there-a-way-to-disable-the-automatic-default-task-creation-in/m-p/625650/highlight/true#M26903

Unfortunately you are using an STM32 L5 MCU, therefore ST packs will not help you if you search for the most recent version of FreeRTOS...

If you really want to stick to L5 series the only solution is to try to do the port by yourself to this series but it might be a tricky task.

Last possibility: if possible, migrate your project from L5 to U5 series and use X-CUBE-FREERTOS pack.

[Harvey White]

So overwrite the heck out of the basic files, move all the RTOS code to user defined sections, and then eliminate the FreeRTOS selection from middlewares, provide the system tick.

Not the most graceful of options.  I may have to, though.

What I'd like to do is find out where CubeMXIDE has the source files, then overwrite *them*.

[AScha.3]

>What I'd like to do is find out where CubeMXIDE has the source files

Look here :  ...Repository/STM32Cubexxx(your series) /...

STM32Cube/Repository/STM32Cube_FW_H7_V1.11.1/Middlewares/Third_Party/FreeRTOS/

[Harvey White]

I picked the L5 series during the Great Processor Shortage. 

I'd just as soon not redesign a number of working boards, although I do have a U5 project where the board is already made.

Regarding the "discontinuance" of FreeRTOS and the universal appeal of Azure, as you know, FreeRTOS is still being developed.

Regarding Azure, for my purposes, it is useless.  The queue mechanism has been redesigned for one, which is, in the minimum, annoying.  I do C++ over C (HAL and the like, as well as other drivers).  I've found several instances where Azure simply does not work when called from C++, or cannot understand C++ structures (it is, after all, C).  Yes, I did rewrite the entire project to replace the calls to FreeRTOS to calls to Azure.  I gave it a chance.  We Were Not Amused.

I may try replacing the source files for FreeRTOS with newer files, but on a fork of my existing project.

I suspect that part of the solution is to work around a few things. 

One workaround is not to generate main AFTER it has been generated once.  (or be ready to replace the middleware files).  For times where the IOC file needs to be changed, do so on a dummy copy of the project, and copy the setups as needed back into the main.c program.  Clunky, but perhaps workable.

I'll have to keep working on this. 

An option is to go to emDOS, yet another rewrite, but there's a bug that keeps compilations from working on even a basic emDOS project.  It's been reported.

Thanks

[Harvey White]

Thanks.  I may try that with copious backups.