STM32F4 library issues fixed?

[Dave Nadler]

Several years ago we started a project using an F429 main and 8 F413 slaves, communicating over an SPI bus. In 2020 we stopped the project because of too many problems with ST-provided drivers/stacks, especially Ethernet/lwip and USB, and very poor FreeRTOS support. Lots of Ethernet driver problems, and the USB CDC stack had a nasty habit of losing packets. Fixing all the bugs was going to cost us more than building our application - way too much expense, time, and aggravation.

A couple of things have progressed since then:

1) I know a lot of work has gone into improving the Ethernet drivers. On the lwip mailing list, the number of painful pleas for help from suffering STM32 users has gone down a bit (maybe not for the H7).

2) tinyUSB has progressed considerably; we're using for another project and so far, so good. It still doesn't support OTG, but there's a workable patch.

I'm asking the community if folks are successfully using STMF4, in FreeRTOS applications, including:

a) lwip with STM drivers, including HTTPS using 429 encryption hardware (maybe with mbed TLS)? @Pavel A.​ ? @Piranha​ ?

b) USB CDC with tinyUSB?

We have to decide whether its worth continuing what we already built,

or if we should restart with different parts. Maher Mastouri, any comments?

Thanks in advance for any feedback,

Best Regards, Dave

[waclawek.jan]

ST now works with Microsoft on the Azure stuff, so you may want to check it out. I can't comment, I don't use (but I refrain from using RTOS anyway, and tend to write/fix code myself).

JW

[MWB_CHa]

Hi @Dave Nadler​ ,

Your question is too generic so I will try to answer with some facts and let you decide what's best for your dev:

1. LwIP/ETH: major rework has been done on ETH driver and multiple updates done on low layer interface to enhance the performance. Based on customers feedback multiple issues have been solved but there are still some issues (new or old) to fix as well. You might refer to this post for more details: link.
2. USB CDC: USB Device V2.11.1 is the latest tag and, as far as I know, CDC performance issues were already fixed few versions ago. Might be worth checking.
3. LwIP+FreeRTOS+HW Encryption+TLS on STM32F429: sorry, no such specific example available right now from our library. You might find something similar on GitHub or the community. We noticed there is an increasing demand for this topic, so we'll plan an example in the future.
4. We introduced Azure RTOS solution integrating ThreadX RTOS with NetXDuo TCP/IP stack with multiple features added, so it might be worth checking that solution as well for your dev. For example, here's the package for X-CUBE-AZRTOS-F4

I hope this helps...

And of course, if you face issues, please report it in this community and we'll try our best to help you.

Kind Regards,

[Piranha]

ST reworked just the HAL ETH driver for H7, but everything else is still the same. The lwIP driver and integration code, application examples, CubeMX generated code and even the code in knowledge base articles are all broken. In addition they ported the reworked driver to F4 and F7 and introduced a bunch of new bugs.

My network issue list is still relevant and up to date. You can see that I edited it this month. Also I turned the first comment into a list of fixed issues and you can see there is not much of those. On the contrary the list of issues is still increasing. Actually the topic has hit a 10'000 character limit, which of course is another stupidity caused by the genius managers at ST, who chose the SalesForce FailForce parody of forum. Apparently the same level of geniuses attract each other.

ST's USB stack is of the same level of "quality" because it is designed by the same geniuses. All of the stack is running in interrupt context, but at the same time an API is not even callable from interrupts with different priorities or non-interrupt code. Again - not just the implementation is a broken bloatware, but even the design is stupid!

Another spectacular example is the broken HAL lock. First Maher came and presented a half baked improvement, which would fix the interrupt safety, but would not fix the flawed architecture. Of course it was reviewed and criticized. Then 3 years later he returned with a "solution", which just removes the broken HAL lock and leaves the state management, which is broken in exactly the same way. In addition they introduced an almost completely useless atomic access macros for individual register accesses. Therefore effectively nothing changed, except for increased code bloat. Also, if you are using LL driver, then with a single move they f***ed up performance of your code completely. And doing this nothing with some damage took those geniuses 3 years.

“Problems cannot be solved with the same mind set that created them.�?

― Albert Einstein

Post link edited to adhere community guidelines.

[waclawek.jan]

I see many RTOS-related issues and rants (including Dave's own printf() rant).

My stance is, that RTOS-s - and, for the very same reasons, "hardware-layer libraries" - are to be simply avoided in microcontrollers.

The reason is, that they simply exchange one source of complexity (perceived or real) with a different - and less obvious - one. In doing so, they consume resources, introduce limitiations (inevitably crippling down innate capabilities of hardware to the least common denominator of all covered cases, often defended by "good enough"), and, being relatively complex, they simply contain bugs. Their usage also requires to align one's mindset to their creators', which is a learning process, and, as such, requires significant effort and simply lots of time (yes, years). Nobody talks about this publicly - on one hand it's a dirty secret for the knowledgeable, and those who are in opposition are publicly intimidated by being told to be unable to recognize the benefits and straight stupid to learn new things. (I try to fight back by publicly acknowlidging, that yes, I am too stupid to learn these new things :) ) There's also significant monetary incentive to those who propose these tools.

Often, the appeal of these tools is enhanced by providing plenty ready-made templates for many use cases (and, in case of Cube/HAL, a shiny clicky interface), and impressive examples. The limitations involved in using those templates in one's work are not obvious at all.

What makes users of these methods confused is the lightness with which certain - arguably, the most common - cases can be solved. These tools are designed so that the initial threshold is low, efforts initially appear to be reasonable, results are instant and impressive. The real learning curve is delayed to the point of no return.

There's of course also the argument, that this is what made the "big" computers what they are today. Sure, except that microcontrollers are a different world. "Big" computers are in comparison to mcus in principle incredibly simplistic, requirements put on them are very extensive but relatively trivial (megabytes (okay, tera these days), megahertzs, megapixels solved themselves thanks to Gordon Moore, RIP - whereas microseconds, single bits and single pin/analog are the really hard stuff) - and by unification the economy of scale starts to show. Remember, how long it took a multi-billion company to produce a half-decent multitasking operating system.

What's your budget?

2 eurocents.

JW

PS. My strong impression is, that Adam Dunkels's early work, not just lwip, was in line with these lines, i.e. the point of his works was to help avoiding RTOSes in microcontrollers. Eventually, he too gave in, as there's no money in proposing blood, toil, tears and sweat.