Is ST Cube IDE a piece of buggy crap?

[dietert1]

HAL is a great attempt.  It is just badly done. ..
HAL tries to handle the hundreds of permutations of hardware combinations... and mostly fails.  However ..

On the contrary, it serves its purpose very well. Most software developers understand very well that it is meant as learning support, something like a tutorial. If you can't use it, that's fine with everybody.
You can ask Santa Claus for a present - libraries written to your specs. All these rants because he didn't respond?

Regards, Dieter

[Simon]

(Arduino has the opposite problem - the abstractions are pretty good, but they only cover a tiny portion of the features offered by the HW.)

"Abstraction" means using only the common mutual denominator; so, by definition, only a fraction of what's possible with all the variants of the hardware.

Also, any "library", even if not trying to "abstract", inevitably covers only a miniscule fraction of what's possible with the hardware. You have dozens of features in each peripheral, times dozens of peripherals per mcu, times dozens of usage modes; and just that many time/energy/money to write any "library", which - if has to be of any worth  - then has to be tested in dozens of instances.

"Abstraction" proponents cite the success in realm of "big computers"; but those are almost stupidly simple compared to mcus, when considering the fundamental working principles. This is hard to explain to "pure programmers" (especially the variety occuring in academia).

JW

This is utter bollox unfortunately.  "big computers" are stupidly simple compared to MCUs?  In which fantasy are you living?  Have you ever even looked at low level Unix or Windows?  They are a 100 times more complex, no 1000s of times more complex.  The average off PC today has 8 async cores, async memory, async hardware buses.

You go and try some "bare metal programming" on big iron and come back and re-read your post.

Also, before we had all thus abstractions when you wrote code, you wrote it for the CPU and configuration of the device at hand.  It did not work on any other device without a rewrite.

Yet today I can write code which will run on anything including MCUs.  How?  Abstraction.  This is the true meaning of it.  Not "simplifying to an interface" which is actually called "Facading" not abstraction.

I think you missed the point. MCU's are quite complex if you expect to just run any code on any one. Just look at the arduino libraries, I dunno, take analogueRead, Ahh what a pile of poo, why? it totally dumbs down the whole thing and ignores lots of the ADC's functionality. Micro controllers do have a lot of hidden little features that can be very powerful, but most programmers think they are still programming PC's, and so you get the sort of mess that all of these HAL systems are. Actually writing code that can be separated from the hardware comes with penalties and is one hell of a job to do.

[paulca]

I think you missed the point. MCU's are quite complex if you expect to just run any code on any one. Just look at the arduino libraries, I dunno, take analogueRead, Ahh what a pile of poo, why? it totally dumbs down the whole thing and ignores lots of the ADC's functionality. Micro controllers do have a lot of hidden little features that can be very powerful, but most programmers think they are still programming PC's, and so you get the sort of mess that all of these HAL systems are. Actually writing code that can be separated from the hardware comes with penalties and is one hell of a job to do.

If you take a random modern (<1 year old) PC and a similar MCU, or just pick the most complex MCU you can find.  Layout the FULL specification of all the hardware components....

Consider that the PC contains several dozen MCUs, ASICs, DSPs before we even begin.  So you would need to start with the hardware and bus specs for all of those.

By the time you were done, the documentation pile for your MCU would be about 2 inches high.  The documentation for the PC would be 6 feet high.

Now consider that the PC is one of about a billion and the largest single instance count would cover less than 10% of them (probably a Dell Optixplex).  So there over half a billion different hardware combinations.  Different cards, different memory types, different CPUs, different bus controllers... etc. etc. etc.

So, to write a baremetal application for a modern PC platform is going to involve a LOT of sleepless nights. 

Don't get me wrong it can be done.  I have personally got it (bare metal code) to boot all the way up into 64bit mode, establish MMU TLBs etc.  Yada Yada and was about to start with initing the bus master to access the UART, just like an MCU (well not quite).  However.  Alas.  I ran out of time and motivation.

While it is honestly a reach to compare MCU software and "big iron" software they do collide everywhere.  In big iron land we call the part which interfaces with the hardware the "Driver" which is usually a "plugin" component within a layer of the "HAL" in the OS.  "Drivers" basically take what the HAL passes them and translates that into the specifics of the hardware.  The premise that this layer must be a "facade" or simplification of what that driver (and thus hardware supports) is false for almost any modern OS there are provided ways to pass "extension" data or calls to support.  All of the various datastructures have extensibility in mind.  Nobody likes drivers that fail with each and every hardware micro update or every OS micro-update.  They are designed to be tolerant, but strict and failsafe, ie, not throwing crap back at the hardware or the OS when IT screws up.

Of course the "other end" of that driver communications channel, the way it talks to hardware usually requires other OS functionality to "facilitate and mediate" given there are possibly hundreds of other threads/processes competing.  But, ultimately it will end up leaving some from of bus interface IC on the PCB card, or whatever, and become SPI, UART, I2C or whatever.  It might even involve an MCU and it will have firmware written for it.   Most likely forming a "Driver Version<->Firmware Version" compatibility matrix.  Which becomes complex when you want to support multiple "platform".

Here we collide.

For everyones sanity, we keep those people, the driver, os and firmware folks, in a separate room... ideally a separate building.

On terminology there are actually specific academic definitions for a lot of terms people just throw around as proxy of each other.

Quiz:  Arduino.  Is it a library?  A platform?  A framework?  A pattern? A facade?  An abstraction?  An eco-system?

BTW.  IMHO the only "software engineering" I have ever seen in MCU land has been Arduino **** and STM32 LL and HAL components.  Coding != software engineering.

[peter-h]

LWIP is not totally off topic, because ST bundle LWIP with the other stuff.

LWIP is now about 17 years old so "obviously works" and is license-free. Due to its age, the devs moved on years ago and never produced decent integration documentation, which is a real problem. The config file lwipopts.h has key stuff but is poorly documented. There are many interactions between different things e.g. if you make some buffer less than 3k then you can never transmit a packet bigger than 3k (IOW, the splitting it up to MTUs won't work). I spent months on this... And it is harder to make it work with "limited" RAM, say 20k.

It's obvious (from posts) that many devs out there have worked it out themselves but we still don't have a decent config manual for it.

But it does work. Yes it needs an RTOS to work properly but it is bloody hard to design a nontrivial product without an RTOS. One ends up with a ridiculous state machine which gets completely unmanageable if you have multiple comms etc features e.g. ETH, USB, FLASH filesystem via USB (MSC) and a USB VCP (CDC). I would suggest that for manufacturing reasons anything with ETH will probably have USB also.

I am certain it is impossible to develop any complex product entirely using Cube MX. It gets you so far...

It is very hard to do any realtime project with a PC, due to so much going on which disables interrupts.

[paulca]

It is very hard to do any realtime project with a PC, due to so much going on which disables interrupts.

This is mostly true.  It's not that things disable interrupts it's that there are a LOT of interrupts, cascaded, nested etc.  Also the CPU timer resolution (on amd64) is only 1000Hz.

It depends on the OS, but if you have got realtime requirements, you will usually have to have support for it in the OS.  Linux, for example, can be compiled for more "realitime" abilities.  Kernel pre-emption, re-entrant kernel and "realtime priority scheduler".  Some of the audio focused distros use this flavour of kernel.  It provides as close to real time hardware access as you can get across so many async buses.

Most "realtime" processing for PCs is done in ASIC hardware.  Like the tight timnig for HDMI.. done in hardware.  Audio, done in hardware.  So most hardware is, similar to MCUs (STMs anyway), in that you can "start" the device with DMA enabled and leave it alone to do it's thing and raise an interrupt when it's done.  The vast majority of the hardware complexity is solved this way, buses and bus coordinators.  But even the like of floating point units often work that way.

Anyway.  If the point is that it's easier to write "application" code for PCs/BigIron because it has nice layered abstractions.  Well, yes.  That was my point.  MCU land is far simplier, but yet never seems to have left the 1980s and done any form of software engineering to make "routine" run of the mill stuff work.

Someone mentioned "facades" or over abstraction.  Here is the thing about software.  You need to common stuff 1000 times more often than you need the rare stuff.  Therefore a good platform/framework will have those as the "pre-canned" fully automagic defaults.  The more weird, wonderful and bespoke your application, the more code and faffing around you will need to do.

This is basically what Arduino framework addresses with it's approach.  Basically "convention over configuration".  Rather than 3 pages of HAL routines to enable a debug UART (I exagerate) it should just be in that default mode anyway, out of the box on power up.  What is the MOST likely use of the device and init it in that state.  STOP making work for future you.  Start making future you's just easier.  Serial.begin(baud).

[dietert1]

I just looked through some of the LwIP option files (opt.h, lwipopts.h and http_opts.h) and find it well commented. I guess one could roughly understand what is going on, except there are lots of options..
Maybe i should turn on LWIP_STATS in lwipopts.h to get some understanding what is going on. Also there are LWIP_DEBUG, LWIP_STATS_DISPLAY and LWIP_STATS_LARGE. Appears to be pretty decent. I hope LwIP error handling is better than HAL (=non existent).
Until now i used Wireshark to monitor what is going on. Some days ago i ordered a Netgear DS104 hub at ebay to use it as a tap - for € 9.12  + postage.

Regards, Dieter

[NorthGuy]

Computers are designed to run software. The software must do whatever it is designed to do, and it must execute somewhere. PC is just a tool to execute software. Drivers provide an abstraction layer, so the software uses a common interface and doesn't need to worry about the specifics. The software I wrote 25 years ago works just fine today in modern Windows, using LCD, SSD cards and 10Gbit network even though these things didn't exist at the time when I wrote the software. Hence the utility of OS and drivers.

None of this is needed with MCU. MCU are subservient to hardware. Say, you have built a buck converter 25 years ago which used some software. It may still work now. If you want to build a new buck converter now, you take new parts - new inductors, new FETs, new MCU. You do it all anew. You don't care how the 25-year old buck converter worked, or what its software did. You can do much better now. Once youy're done, your product is not software, but the buck converter - people will use your buck converter now, or may be for another 25 or 50 years with the same software, who cares. Or they can use an old 25-year old buck converter if it's still functional. In 25 years, you will be able to build a new buck with everything new, and you won't care how the software for today's buck converter worked.

[elektryk]

Just use the damn ST account you already have, you must login to download the IDE anyways 

You don't need account, only email is necessary.

To use latest v1.3.0 in IDE 1.12.1:
 - If present, delete C:\user_profile\STM32Cube\Repository\STM32Cube_FW_H5_V1.0.0.
 - Download FW package v1.3.0.
 - Extract to C:\user_profile\STM32Cube\Repository\STM32Cube_FW_H5_V1.0.0.
 - Edit package.xml, change <PackDescription Release="FW.H5.1.3.0"> to <PackDescription Release="FW.H5.1.0.0">.
 - Choose FW v1.0.0 CubeMX (Project Manager -> Firmware package).
 - Done.

- You can check the current HAL version in Drivers/STM32H5xx_HAL_Driver/Src/stm32h5xx_hal.c:

Code: [Select]

@brief STM32H5xx HAL Driver version number 1.3.0

Clever solution, thanks.

[peter-h]

Most "realtime" processing for PCs is done in ASIC hardware.

Indeed, and I used to manufacture such products, many years ago. Actually, they had MCUs on them, 80x86, usually the 186. 20 years ago, huge FPGAs were all the rage like here



and those cards sold for 4 digits.

I just looked through some of the LwIP option files (opt.h, lwipopts.h and http_opts.h) and find it well commented

Yes, until you get to subtle interactions of buffer sizes and "things hanging" if some buffer is too small. This is not explained anywhere AFAICT.

Until now i used Wireshark to monitor what is going on.

Yes but that needs quite a lot of understanding, and writing lots of test code so you can identify the packets.

Or they can use an old 25-year old buck converter if it's still functional.

You may also want to modify that 25 year old project, and with Cube IDE you can provided that you can still get a windows PC running That looks highly likely especially if you archived the whole thing in a VM.

Can't do that with any commercial IDE I know of. They will all stop running when the license server dies.

[dietert1]

One big problem i find with HAL as well as LwIP is missing/incomplete error propagation.
The worst error handling in HAL is a halt, that is "disable interrupts and infinite loop". Sometimes they use a function named Error_Handler(), but there is no Error_Handler(int) and the infinite loop can be anywhere. There is no hard fault handler. Probably there is no simple resolution for all this.
LwIP defines 17 error numbers yet there are hundreds of error exits. A big problem to find the cause when something went wrong. At least each LwIP component including netconn, http, telnet etc. could save the original error code somewhere, maybe in a queue or TLS.

Regards, Dieter

[NorthGuy]

... That looks highly likely especially if you archived the whole thing in a VM.

Right. Just about 20-25 years ago I bought Connectix VM software which worked great, but then Microsoft bought Connectix and made sure that their VMs don't work on newer versions of Windows.

[DavidAlfa]

CubeIDE removed that few years back, but you can revert it back to error_handler(char*, int) with some macros,  so you can use GCC's __BASE_FILE__ and __LINE__ arguments, easily spotting the problem.

https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/03fa323cccb24dd3ad324c0f08d154a3df311006/Core/Inc/main.h#L56-L64

After this, you can do:

Code: [Select]

void Error_Handler(void)
{
  printf("Error in %s : %u\r\n", file, line);
}


[peter-h]

The worst error handling in HAL is a halt, that is "disable interrupts and infinite loop". Sometimes they use a function named Error_Handler(), but there is no Error_Handler(int) and the infinite loop can be anywhere. There is no hard fault handler. Probably there is no simple resolution for all this.

Yes; there is a lot of stupidity like that. They also have timeouts on things which can never time out unless the silicon is defective.

and made sure that their VMs don't work on newer versions of Windows.

That happens anyway; a lot of say winXP apps don't work under win7, so I use an XP VM. If the VM player itself no longer works, you could build a PC and install XP on it, which is pretty easy. I have some ancient software which for weird reasons (probably timing issues) needs win2000. Written by an ex M$ guy in VisBas I built a win2000 PC for it... Later I plan to move it into a win2k VM. One has to retain the original installer, of course.

[DavidAlfa]

They also have timeouts on things which can never time out unless the silicon is defective.

Or the programmer screws something up elsewhere, like interrupts or whatever, so not that stupid.

If you don't like HAL use LL or make your own, what are you  achieving with so much ranting?
Also lots of what I see here seems from users who haven't gone deeply into it, it's great for a lot of things.

[peter-h]

This was discussed before. One example was:
- check UART tx reg has space in it
- put in 1 byte
That byte must go in unless the silicon is faulty.

I don't think it was me who was "ranting" I think the Cube MX generated "HAL" code is useful, because it saves a lot of time reading the RM and then experimenting, but you should read it and strip out the obvious crap.

[DavidAlfa]

Sure, what if you mistakenly disable the peripheral clock or whatever. Few more instructions making sure nothing happens won't hurt, HAL must be made to work or keep control for everyone under any conditions.

[elektryk]

This was discussed before. One example was:
- check UART tx reg has space in it
- put in 1 byte
That byte must go in unless the silicon is faulty.

I wrote a custom function for it because if I made two consecutive HAL_UART_Transmit() calls, only the first one worked or both with a delay between them.

I also tested Cube IDE 1.16.0, it works fine without logging in and with manually extracting the software into the repository directory.
Unfortunatelly it still opens some files during FW download, but its mainly startup_xxx.s.

[peter-h]

without logging in

What logging in?

Posts on the ST forum say that the random file opening issue is still there.

[elektryk]

What logging in?

They added that silly feature which may enforce you to create an account.

[peter-h]

I always downloaded as a Guest. They email you a link.

Still stupid but less stupid.

They are collecting email addresses.

[paulca]

None of this is needed with MCU. MCU are subservient to hardware. Say, you have built a buck converter 25 years ago which used some software. It may still work now. If you want to build a new buck converter now, you take new parts - new inductors, new FETs, new MCU. You do it all anew. You don't care how the 25-year old buck converter worked, or what its software did. You can do much better now. Once youy're done, your product is not software, but the buck converter - people will use your buck converter now, or may be for another 25 or 50 years with the same software, who cares. Or they can use an old 25-year old buck converter if it's still functional. In 25 years, you will be able to build a new buck with everything new, and you won't care how the software for today's buck converter worked.

The problem is this is EXACTLY the way early programmers felt about computers.  It ended up in the mess of the 1980s which nobody wants to go back and fix, get some of it still exists.

There are many, many avenues for reusable code in the MCU world.  It's just that the industry hasn't really burnt itself hard enough yet to realise it.  That is because, generally, when put side by side, the scales of code and project are very diffierent.  MCU firmware is like a mouse stood beside the elephant of any serious enterprise system.

[SiliconWizard]

Start working on making your own code reusable (as much as possible) before waiting for others to do it for you. Just my 2 cents.

Making low-level code reusable is a trap, which often leads to monsters - or just to nowhere. But making higher-level code reusable is definitely doable, and often too much related to the application/domain that it makes little sense to have very generic solutions made by others either. Exceptions can include things like TCP/IP stacks. But that should be seen as exceptions rather than the norm IMHO.

[dietert1]

We got an implementation of GPIB for STM32 MCUs and when it began it was based on their HAL libraries. It used 16 MCU pins of a bluepill module without bus buffers. Later it was modified to use 32 MCU pins. With separate input and output one can drive and sense bus signals at the same time, e.g. for the SRQ interrupt line or for debugging.
Later for performance reasons some places got direct peripheral register access.
Now i found that we got inverting bus transceivers. In order to reuse the code i need a compile time option for inverted data. Probably it can be done with macros. A macro can invoke a HAL function as well as direct peripheral register access and at the same time implement the data inversion, without performance penalty.
Before one can call some code a library one needs feedback from several reuse cases. Each test case can reduce integration effort for future cases. If there is feedback!
The current project is on a STM32H743 and as they propose it uses LwIP with FreeRTOS as ethernet stack and it has been easy to replace the PHY by a different one that works with a fiber transceiver.
Yet it took some days to instrument HAL (the parts used), LwIP and FreeRTOS with consistent error spotting. Lucky enough there are very few errors. Some days ago i found how to enable promiscuous mode in the MAC.

Regards, Dieter

[paulca]

Start working on making your own code reusable (as much as possible) before waiting for others to do it for you. Just my 2 cents.

That gets us to about the 1990s. 

Making low-level code reusable is a trap, which often leads to monsters - or just to nowhere.

[/quote]

Agreed.  However, proper layering, which need not be runtime expensive, will limit the amount of low level code required while maximising it's flexibility and utility to the layer above.  "Separation of responsibility." is the term.

Consider the age old "Debug UART" or as we would call it in big iron world, "boot serial console". 

* A "debug" layer/component which has functions and data structs which deal with text messages, token replacement, formatting from the user code.  The only bit the application programmer needs to touch.

* A "console" component which handles the abstraction of "what" is being used as a console.  So it may have functions as simple as "wirteToStream", "readFromStream".  If you must then implement a full unix terminal protocol.

* A UART protocol implementation.  It will have all the UART specific flags, state and be in terms of the UART specification/protocol.

* A driver for the hardware UART controller to make it do the bidding of the UART abstraction, but in specific hardware terms.
^ this could also be a gfx output driver for an LCD or a LwIP socket.

In a heavish application you might find this layer stack above wrapped in a "Logger" component which formats in the date/time stamps, code file and line-number origin.

I think the trickiest part is in getting the right granulatity of "code in scope" to maintain a small footprint.  HAL struggles there too.

[paulca]

A lot of arguments about reusable "canned code" libs and frameworks like Arduino will straw man something like this.

while(1){
  DigitalWrite( D1, UP );
  DigitalWrite( D1, DOWN );
}

We produce a square wave on a given MCU of, say, 500kHz.

If you do it with the registor macros directly it gives you 10MHz.

"Therefore frameworks, libraries and reusable code are stupid."

Sometimes, usually not, but sometimes people will go and look to see why it takes so long.  They find that it is doing sanity checks, so it can provide sensible errors and error handling, it is also trying to translate between multiple different types of port identification and multiple enum/bare int forms of port state.  It also supports many different boards with quirks to needs to address.

In the instance above, where the programmer knows his platform, knows his MCU and determine the direct integer port number for the correct register and the correct polarity of it, then they don't need to be calling DigitalWrite.  They can go straight to registers.

However, should a migration to another MCU be required there will be no support for compatibility with hard register calls.  If you set one incorrectly in a function and it causes a bug it could just lock up the device, the code or reset it, with no error handling and no error prevention or messaging.

Life is full of devices and mechanisms which take an existing manual process and break out common components for reuse.  We have dishwashers.  I know many an old lady who will complain that the dishwasher takes too long.  Why does it take 2 hours to wash dishes?  I can do then in 15 minutes!

My response is usually,   It takes 2 minutes to fill it, 20 seconds to start it and those 2 hours are time you can spend with your feet up or doing something else.

If... if I needed something washed a specific way or if I needed to wash something quickly.  I still have  sink, tap and scrubber.