AZURE vs FreeRTOS

[Harvey White]

On the newer chips, such as the U5 series, FreeRTOS support is underwhelming in CubeMXIDE.

I have, and did, use FreeRTOS. I tried AZURE in a C++ programming environment and found several problems, one to do with systick, another to do with tasks, ownership, and whether or not a task would even work when owned by a class. We won't get into the rewrite of how queues work, which is an extreme limitation when compared to FreeRTOS.

So I've tried AZURE, and while there are some nice features, I'm concluding that the ideal AZURE environment is plain C, and very limited queue size.

Try programming in C++ (a graphics display system, classes for I/O, communications and the like) where classes and inheritance actually work well, and AZURE comes up wanting.

FreeRTOS is not perfect, but after developing enough of an infrastructure using it, it's workable.

So I'd propose the following questions:

1) when are we going to get FreeRTOS support in CubeMXIDE for the U5 series? Even limited support would be useful. (There are problems with just adding FreeRTOS involving what the code generator thinks is needed).

2) Would it be reasonable to modify CubeMXIDE to have a few more options on code? (the interrupts get added badly) Options to allow bolting on other operating systems, for instance.

3) Is ST going to drop FreeRTOS completely?

Comments welcome.

Harvey

[MWB_CHa]

Hi @Harvey White​ 

Your feedback is much appreciated and we can understand the pain for you to switch your project on a new environment.

FreeRTOS support will not be reintegrated inside STM32CubeMX in native mode.

But the good news, for you, is that FreeRTOS will be released beginning of March on U5 and new series in the format of X-CUBE.

This will allow you to configure and use FreeRTOS through STM32CubeMX in a very similar way than you used to do in the past in native mode.

We try our best to make this step as smooth and seamless for you. So, don't hesitate to provide your feedbacks/proposals once you try it out.

I hope it answers your 3 questions ? let me know if you need more info/details.

Kind Regards,

[Harvey White]

Thank you for your reply:

To answer the questions in light of your comments

1) If you do not support FreeRTOS for new processors, then the choices are obviously to use AZURE (comment later), or simply not buy the new processors. Having support for FreeRTOS is quite necessary. Even being added in the traditional manner will be useful. HOWEVER: you must (design wise), keep the IDE from stubbing in functions that are duplicated in the FreeRTOS assembly code.

specifically:

void PendSV_Handler(void);

and

void SVC_Handler(void);

and that's just so far in stm32u5xxx_it.c

2) comment is directed at the situation above, we don't seem to have the option to disable specific generation of interrupts in the software structure. We can disable them for the hardware subsystems.

3) You've answered question 3 quite well, so thank you.

Now for comments on AZURE, so you are perhaps a bit more aware that you might otherwise be.

I program in C++. I have a lot of graphics classes starting with a basic object that depend on C++ class structure. I have wrapped your HAL functions so that the interface is protected by a semaphore. The HAL functions I have are somewhat composite in nature. For an SPI display, you might need to assert CS, send a command code, Change the state of the A0 (data/command) line, and continue with data, then release CS. You can't be interrupted, so the use of the semaphore. Hardware CS cannot be used because your hardware releases CS after a multibyte transmission, and that's not what the chip needs.

The bottom line is that C++ is not going away for me. AZURE does not deal well with C++. FreeRTOS has its problems, but I at least can work around them. The second problem is the queue element size, which is somewhat of a disaster when dealing with larger packets. I understand why that was picked (fast fast! fast!!! but then inconvenient inconvenient!! inconvenient!!!!)

Now I actually did go through and rewrite all the code that called FreeRTOS and switched to AZURE (conditional compilation, so nothing was thrown away). The problems I mention were found during system testing.

So FreeRTOS is needed.

Oh, and for the record, I tried TouchGFX, and after I figured out how to make it work (do NOT use the IDE to run), I found that the range of primitives lacked a lot of what I could do already. Not sure that you have child objects and polyobjects for drawing.

Thanks, I'm happy that February is a short month.