ST's (STM32Cube) software ecosystem is terrible - how can we fix it?

[dannyf]

"i prefer the ST stdperipheral lib and think that is good enough for any reasonably experienced embedded software engineer to get goin"

I agree.

I think their mistake is not understanding how people use such libraries. Akin to the mistake that Microsoft made in mobile, in its frequent change overs from since to Windows phone too win 10 mobile, etc., with the hope to enhance its Apple penetration.

Well,, who the hell is going to constantly po4ing the same app over each time Ms abandons the previous OS?

Thee same thing with stm. As long as they keep changing libraries with thee hope of making then better, no one is going to invest in those libraries until the stabluze at some point.

STD periph is far from being perfect. But it works. Rather than abandoning it, they should have refined it.

[jnz]

• First off, I just started a new project and have to use Cube/HAL. The actual app, is actually pretty awesome! Setting pins, the clock, initial IRQ and settings per peripheral, and the power management all actually work really well. The clock section specifically saves a TON of time. The code generation actually works well too, minus the issues I have with some aspects of HAL, but...
   
  "SPL isn't perfect but it works"... I hate to tell you this, but HAL works too.
  
  
  
• You know... It's actually not that bad. Yes, HAL does some things that look really goofy. Most of them aren't as bad as they look at first, most things resolve down to addresses fairly quickly. I think most of the fear from this is the look and style it was coded in (I'll call it Abstract-C). It's not efficient, aside from some long ways to just end up poking a single register. It does weird things like all IRQs for some peripheral all end up calling that peripheral's handler which then has a some of code to sort through just do what you already know needs to happen. For example, UART_TX and UART_RX ISR both call the same Uart_Handler() which then checks to see what interrupts are enabled and flagged / need handling, but you already knew what had to happen because you WERE inside that specific interrupt before you left only to consult a confusing looking map of where you just were.
   
   
  
• The love affair with SPL is funny because it also did some dumb things... But... FWIW, the new LL / Low Layer line are almost exactly like SPL. The HAL is for all devices, the LL is SPL that uses the same conventions. So it's SPL with HAL-compatiblity. There are also CodeSnippets which seem to be specific examples of how you would most efficiently do one thing, like check the UART fifo or start the ADC, these are supposed to be even lower level and more chip specific than LL Libs/Drivers. I haven't peeked at these yet but my guess is it's calling registers directly from C/asm without defining headers... So, I think STM does get it, they're showing three options. Some people may be fine with HAL, some fine with LL, and then also the Snippets.
   
   
  
• I have almost no issue with using the HAL to start a project, get up and running, and work towards efficiency when it's working. For this project I have to use HAL, I'll try it. I'll let it configure everything and even run the Inits(), then when I need to do simple things like pull a buffer or start/stop a PWM or ADC, I'll do that quickly with a few register pokes. I have preciously little time. Yes, the HAL will add a little bloat like this, but the alternative is staying on the SPL which has its own issues and bugs that will never be corrected and won't work with new middlewares, write my own which is all duplication of work I don't have time for - putting my project further behind, or stomp my feet and complain on the Internet... Sometimes you just need to get shit done.
   
   
  
• If LL was available for my chip, I'd use it. STM appears to be behind on all things all the time. Their roadmap for LL releases is already a month, almost two off. But here is the thing; LL (new SPL) has HAL compatibility, like it or not, the HAL isn't going away. It's like CMSIS. How many people threw fits about that, and it's largely fine now. Just some perspective. If you really don't like HAL... Best to get on board and submit fixes and efficiencies to it, because it doesn't seem to be going away.
   
   
  

EDIT: I should note that LL is not nearly complete even on the device it's been released for. In fact, the F4 has some weird peripherals initially supported by LL (USB, SDMMC)... I have to figure that they're going to support the more basic peripherals later.

[markone]

• First off, I just started a new project and have to use Cube/HAL. The actual app, is actually pretty awesome! Setting pins, the clock, initial IRQ and settings per peripheral, and the power management all actually work really well. The clock section specifically saves a TON of time. The code generation actually works well too, minus the issues I have with some aspects of HAL, but...
   
  "SPL isn't perfect but it works"... I hate to tell you this, but HAL works too.
  
  -snip
  

Similar experience here, i agree with all your statements

Time ago, when i first faced the STM32 platform i was initially scared by the complexity of the configuration registers structure, quite far from what i was used to (devices like DSPIC33), but thanks to the stm32cubemx / AC6 i was able to build a working setup with running freertos and some code managing communication on uart port within the first day of work, from scratch, almost impossible otherwise.

Sure i'm not a lover of code abstraction, but i think that the ST tools are a great aid to take confidence with the platform and build the initial development "scheleton" on new boards.

I'm now wondering if other players in ARM Cortex arena are now offering, for free, a similar toolset with all the features of above mentioned tools. 

[Jeroen3]

I'm really happy with the HAL. It prevents the magic numbers:

Code: (random example of magic number initialization) [Select]

// Timer 2 for adc
TMR2L = 0x3F;
TMR2H = 0xA2;
TMR2CN = 0x04;
It just is really big and contains a lot of files. Which scares the new people, because it requires more knowledge about your toolchain and C.

On the downside is that you inherit the bugs.
If only it came as GIT repo so you could perform easy upgrades and make pull-requests.

[Sal Ammoniac]

I'm really happy with the HAL. It prevents the magic numbers:

Code: (random example of magic number initialization) [Select]

// Timer 2 for adc
TMR2L = 0x3F;
TMR2H = 0xA2;
TMR2CN = 0x04;


There's no reason why you have to use the "magic numbers" approach when writing your own bare metal peripheral drivers! I certainly don't.

[MT]

Nor do i, nothing particular wrongly with the smallest number expressible as the sum of two cubes in two different ways:

Code: [Select]

TIM2->PSC = 1729;  //Tim2 prescaler ratio.

[dannyf]

That has now been removed as that bug has since been fixed

The best way to remove bugs: remove the bug tracker.

If you don't know you have bugs, you have no stinky bugs.

[jnz]

The best way to remove bugs: remove the bug tracker.

Better than removing bugs is to prevent them from occurring in the first place.
1. Design them out
2. Use a reliable development system
3. Perform thorough pre-release functional and regression testing.

Seriously... Please get out of this thread. Start a new thread about your language and tools if you like, but unless you have something on topic about STM's HAL... Best to keep moving.

The tolerance for people pushing their own stuff is very high here, so let's not push the boundaries... Yea?

[Chris Mr]

Back to the point

When you have to program peripherals to do things you need to know what order things have to be done in, what to expect, what the errors are etc.

What the st libraries do is hide all that lovely information in lots of different files and under many layers.

So what I do is get the top level code and insert all the lower layers by copying the code (that includes all the defines and macros too) from the other files into one file and then start pruning it until you end up with very few lines of code.  You can then read it to see what the order of programming is and so on.

That sounds like a lot of work, and it is, but without it your code is very hard to maintain and to me that's precious (being able to maintain it).


How to fix it?

You could start with a document that explains your methodology so that someone reading the code 'gets it' from that document.

[dannyf]

That sounds like a lot of work,

It does and is totally unnecessary with a modern ide.

[Chris Mr]

That sounds like a lot of work,

It does and is totally unnecessary with a modern ide.

Not if you want to _understand_ it quickly the next time you come to look at it.

A 'moodern ide' does not provide understanding, it shows you what's underneath but if that hides the understanding too then its no help.  In this I am referring to the lack of _understanding_ the st libraries provide.

To put it another way, if the st libraries provided _understanding_ this thread wouldn't be here and certainly not 10 pages long 

[dannyf]

"Not if you want to _understand_ it quickly the next time you come to look at it."

A modern library certainly doesn't get you to understand the code, nor does manually merging tthee code into one file and then trimming it.

A modern idde doees provide conscience so you can navigate through the code att ease, thus facilitate your understanding of the code.

[Kjelt]

Not if you want to _understand_ it quickly the next time you come to look at it.

So comment or doxygen your own calling code extensively and explain what you found out, next time you know in little time what you know now.
Changing/replacing the code means you will have a very hard time to update to new releases because then you have to do the same exercise again.
Anyway give a programming asignment to 5 sw engineers and you get 5 different working implementations, give one of the implementations to another sw engineer to review and you get a lot of comments.

[obiwanjacobi]

"If a method is more than 5 lines, you need to extract some code into a new method"

This guideline will make you write code that almost reads like pseudo code, drastically cutting down on the amount of comments you need to write.
When you do write comments, think of what you would like to know if you would see this code for the first time...

Write code that is easy to read - not only when you're neck deep into it, but also when you see it for the first time. Code is written once, but read (by humans) many times.

[Chris Mr]

Sorry, I don't understand what you mean by "conscience" dannyf

The st code we are referring to is for their (st) peripherals, its nothing more.  The data sheet doesn't explain how they work properly and the code doesn't either.

So you are left with working it out for yourself.

For example, have you written an interrupt based I2C routine for STM32? there is no example (or at least wasn't last time I looked which was quite a while ago) and the data sheet doesn't tell you the vital things you need to know in order to do so; but there is a way to do it.

I agree Kjelt, but this is not a programming assignment, it's a data sheet which is complete that's lacking 

[Kjelt]

I2C is one of the problem peripherals of ST, well noted for years, there is some strange statemachine driven "working" code lib called Cpal.
All the other peripherals and dma etc. just work fine, they don't sell hundred of millions of CPU's to fortune 500 companies that put them in their hot selling connected products if the CPU or datasheets or code would not be able to make working.
They would be bankrupt.
As said earlier, ARM32 can be a time consuming hill to climb for a one (wo)man hobbieist wanting to upgrade from 8 bit to 32 bits and gets thousands of pages of datasheets to cope with.
Don't blame the product or show/give me another manufacturer that has hassle free 32 bits ARM CPU's with libraries that work straight out of the box, you never have problems or errata sheets:
NXP fail
TI fail
Atmel fail
?
All have their issues and problems AFAIK and all can be made to work after some workaround. Why ST gets so much bashing is really a big question for me, their CPUs have been used in the millions for over 5 years in our company and we keep on using them, but then we have 50 software engineers working on the platform.

[Chris Mr]

Ah, why ST get so much bashing is because they were the first to do it - years ago!

[mark03]

A modern library certainly doesn't get you to understand the code, nor does manually merging tthee code into one file and then trimming it.

Au contraire, this is precisely the method I must often resort to in order to understand the code.  When the reference documentation is insufficient, how else are you going to understand the peripheral except to start with the multi-layered ST spaghetti and, step-by-step, distill it into its essence?  Testing as you go to make sure you haven't removed something essential.

[Sal Ammoniac]

For example, have you written an interrupt based I2C routine for STM32? there is no example (or at least wasn't last time I looked which was quite a while ago) and the data sheet doesn't tell you the vital things you need to know in order to do so; but there is a way to do it.

I have, and using only the user's guide. I've done this for the STM32F3, F4, and now F7 and I haven't had any problems getting it working. I'll agree that the datasheet/user manual is sometimes vague, but all the info is there--you just have to put all the scattered little pieces together.

[dannyf]

"Changing/replacing the code means you will have a very hard time to update to new releases because then you have to do the same exercise again."

Depending on how the code is structured. I have code that were originally written forr SPL 1 and now runs on SPL 3.5, with minimal changes.

The complaints about SPL is driven by a few factors, in no particular order.

1. The quality isn't that great and the documentation is poor. Sometimes the errors are rudimentary, like the defines on HSE_VALUE for both stm32 and stm8.

I remember someone who boasted to be a St software engineer here and had trouble getting a wireless modules to work. If that's representative of St software engineers, what we see in their products isn't surprising.

2. Chip complexity and peripheral complexity. Those are complex chips and tht takee inordunary amount of effort to get going. For people coming from the 8bit world, that can be a shock.

3. User mentality: I rarely hear people talking about layering in work places or conferences because that's expected in most places. Layering is your friend.

4. Different clientele. In terms of complexity,  those luminary chips are far more complex than the stm32 chips, and stellarisware is worse in terms of documentation. Yet you rarely hear people complaining about those chups, because amaturers rarely had a chance to use those people. Stm32, given it s low prices, is popular with amaturers who tend to have the requisite experience dealing with those chips.

[Chris Mr]

"Changing/replacing the code means you will have a very hard time to update to new releases because then you have to do the same exercise again."

If ST change the peripheral then you would have to go through the process again anyway.  If they don't change the peripheral then the code would stay the same.  ST don't go around changing the peripheral as it is very expensive.

There are other examples of how, by going through methodically / rigorously, you find other ways - you can use bit-banding to alter a pin state in a single instruction; no calls to routines etc so if timing is important there's a way of doing it.  Same thing for checking busy flags - without reading status registers.

None of this would be apparent to someone who simply uses the st library.

[Kjelt]

This was my reaction on someone who rewrote the entire library himself stripping it of loose ends and extra's he did not need.
The reaction was you have to do that every time again per processor which is still valid.
ST has changed the peripherpal lib interface once from if I recall correctly from the F1 to the F2. It took a couple of manweeks work to adjust the platform.
Still if you then again have to do this exercise of stripping of the "useless code-fat" that someone did , he had to do that all over again.

[Chris Mr]

You do not have to do that on a per processor basis, just when an individual peripheral changes; and then its just that peripheral - all the common stuff stays the same.

Sometimes the base addresses of the peripheral change on a different processor but that's all.  I have the base addresses in a separate file (that's all that's in there, the base addresses) so no problem using a different processor.  Go to the memory map in the data sheet and type in the new base addresses to a file (using an old file as a template) - 10 minutes work maybe.

If you stop looking at the st code as a complete solution (which it isn't, and isn't intended to be) and start looking at the issue of being able to use the peripherals, things change.

The OP (which I can just see in the far distance using my high power binoculars) asked how to fix it.  If you think the st library is fine then why comment?

I don't quake in fear thinking about using a new ST processor, I just use it.  Alter a few addresses and away I go.

[Kjelt]

The OP (which I can just see in the far distance using my high power binoculars) asked how to fix it.  If you think the st library is fine then why comment?

yes if you look at it on a module per peripheral basis and keep the config , init of the clocks and power in a seperate module initing the peripheral modules , so actually layering a bit more , you could make a nice workable solution for yourself.

[Chris Mr]

Clock and power are also peripherals, sometimes they change with processors, most often not