Author Topic: Is ST Cube IDE a piece of buggy crap?  (Read 158354 times)

xrunner, 8goran8 and 5 Guests are viewing this topic.

Online paulca

  • Super Contributor
  • ***
  • Posts: 3994
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #850 on: March 27, 2023, 08:52:12 pm »
Setting up basic hardware.... yawn.

I want to innovate.  F you.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17729
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #851 on: March 27, 2023, 09:19:58 pm »
From what I saw of the STM configurator setting up hardware was as much work as just doing it. Yes sure, you get to use drop down lists, how cute, but if you don't know what the terms mean you are screwed, so you have to consult the datasheet, oh and watch random youtube videos because they created a system with no documentation, sweet. i spent half an hour setting up a PWM output from scratch (versus 4 hours with ST configurator) I've spent a week using that small bit of code as the final stage of pages of code for motor speed control loops, why do I even care if it took me 4 seconds, 4 minutes or 20 minutes, never mind 4 hours.

There is a class of electronics engineers that miss the whole point of their profession, they think that the solution to their project is always on google and they just need to set up some code in a configurator.

that is how the last subcontractor that my employer used made such a mess of a design that tens of thousands of pounds later I declared unworkable when i started and was asked to fix it. All because someone played engineer, could not even lay a PCB out that involved power and signals and after having it explained at least three times to them still do not understand what ground bounce is and keep talking about using thicker copper. They spent months trying to program around the issues they made and charged a fortune for their own mistake.

On the other hand I produced a basic working example of a more powerful machine using the same type of equipment with no problems. But I don't do code configurators so I can't possibly innovate, like design a machine that works, translating physics problems into software and appropriate hardware, no that's not me, you need a code configurator for that because it allows you to quickly try as many coding solutions as chat GPT could come up with to try and find the magical combination to a problem i made for myself.
 

Online paulca

  • Super Contributor
  • ***
  • Posts: 3994
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #852 on: March 28, 2023, 08:23:33 am »
The point is electronics people insist on building everything from scratch.  I can't understand how you innovate if you have to do everything from the smallest possible blocks every, god damn time.

Software Engineering is about NOT doing that.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: br
    • CADT Homepage
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #853 on: March 28, 2023, 08:42:58 am »
My first encounter with Arm Cortex was Kinetis. They did not provide the entry level tools, so one spent some two months to carefully implement the startup sequence including the necessary transitions from one clock generator to the other one, plus the NVIC stuff and so on. For someone infamiliar with ARM it was kind of an adventure. I remember testing for instruction cache efficiency and details of DSP support. When Kinetis disappeared we started using STM32. I also had an encounter with ATSAMC. There were small examples for each peripheral (like ADC, CAN, DAC, I2C, SPI) and one could combine them into an application, rapidly getting results.
In comparison the STM32 CubeMX tools and their libraries aren't bad. If somebody thinks he can do better, why not. No reason to rant about others.
Probably the rant is about something else. Maybe the pressure to use predefined libraries of unknown quality. Also it's a nasty situation for an embedded person if the ARM family one learned disappears, like it happened to us.

Regards, Dieter
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #854 on: March 28, 2023, 08:52:50 am »
The point is electronics people insist on building everything from scratch.  I can't understand how you innovate if you have to do everything from the smallest possible blocks every, god damn time.

Software Engineering is about NOT doing that.
The problem is that you need to have a good framework / library to start with. ST's HAL is not that. I have tried to use it myself as well but it is horribly inefficient, non consistent, poorly documented and cumbersome to use so I understand Simon's position 100%. Fortunately I have my own libraries that are easely adapted to different hardware.
« Last Edit: March 28, 2023, 08:54:31 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: br
    • CADT Homepage
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #855 on: March 28, 2023, 09:58:25 am »
STM32HAL is a good framework / library to start with. Everybody can use it do derive their private version.
Others will use it all the time, only with minor changes. Many entry points in the HAL are defined as weak, so they are meant to be modified for each application.

Regards, Dieter
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #856 on: March 28, 2023, 10:41:00 am »
Only total experts would suggest going to an ST ARM32 just by reading the 2000 page RM.

I did read every word of the DS (300 pages?) when designing the PCB, and that worked 1st time, but doing the software by reading the RM would be horrible. A lot of the time the required information is just not there. Try interfacing LWIP to ETH on a 32F4, by reading the RM. It would take you years. Actually ST do provide some code for that but it needs fixes.

The Cube MX code generator does work well enough to get yourself started. I cut out the crap out of that code and it is then fine. Nowadays I write new code from the RM. But I am not revisiting the ETH and USB stuff; I don't want to go back to that in the rest of my life! That was originally done by someone else, working half a day a week, but he is no longer involved.

Nobody is suggesting that Cube should disappear, but it could be bug-fixed and more robust. Why exactly this is not happening, I don't know. Not a priority for ST, evidently.
« Last Edit: March 28, 2023, 10:56:45 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Online paulca

  • Super Contributor
  • ***
  • Posts: 3994
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #857 on: March 28, 2023, 10:42:00 am »
The point is electronics people insist on building everything from scratch.  I can't understand how you innovate if you have to do everything from the smallest possible blocks every, god damn time.

Software Engineering is about NOT doing that.
The problem is that you need to have a good framework / library to start with. ST's HAL is not that. I have tried to use it myself as well but it is horribly inefficient, non consistent, poorly documented and cumbersome to use so I understand Simon's position 100%. Fortunately I have my own libraries that are easely adapted to different hardware.

Yes.  It's just that that is not what I see "out there".  Maybe the content I am reading on here and on several other forums is unrepresentative, but all I see is people struggling with the same code as MCU engineers where in the 1990s.  It's the same shit, the same routines the same problems over and over and over again. 

When I start a new project on an MCU I get annoyed almost immediately because I have to rewrite the debug UART routines.  Even with HAL this takes time.  I get annoyed because it's completely against my grain.  Yes, of course I can wrap my own library up and package it for re-use in my projects, but the fact this isn't just an off the shelf component for every MCU project baffles me.

Each and everytime you rewrite it you always introduce new and unique bugs.  Because nothing is encapsulated it's all sitting on jelly and when one thing changes everything else falls over.  It's just so ... eugh.  Wasteful.

Write a UART debug library.  Write it once.  Test the wazoo out of it.  Package it.  Reuse it.

Add a bit of functionality to allow adding timestamps to debug UART output, write it once, test it, package it, reuse it.

Can you not see how exponentially faster development becomes?  Yes, it becomes less efficient, especially if it's done badly.  Yes space and power is limited on MCUs.  Yes we in big iron waste vast amounts of hardware.  The thing is.  Hardware is cheap.  Engineers aren't.  Easy adaptable, flexible, scalable, reusable code scales exponentially with effort.  The software I take to a week to write, includes other works from other engineers where the total amount of effort require to get from the low level MCU style code in the bottom end of the OS up to the business logic code in the application... you are taking about many, many life times of effort.

If you are rewriting that each and every project.  It is of exactly zero surprise that MCU projects are so often riddled with bugs and miss-features.  To be honest I don't think I have ever used an MCU based device that wasn't full of undocumented "features".

Even when you give an electronics hardware team a 32bit ARM core with 512Mb of RAM and 32Gb of Flash....  they still produce 1990s "VCR menu like" junk.  The same stuff that infuriates the users the application is intended for.  Case in point.  Every single network appliance's built in web interface.  That is what happens when you give a low-level C engineer the task of writing a UI.  I can bet it's almost entirely based on "printf" templates and string subs with hardcoded HTML and Javascript in the C code.  It probably took their team of engineers over a year to complete that UI which an experienced front end developer would have for demo the next morning... and theirs would adhere to the user interface best practices, accessibility, internationalisation, localisation, security and use of use.... all pre-canned because he didn't write it, he re-used it.  He reused code that has been used in millions of projects around the world and has been extensively tested by researchers far beyond you and I.

Just try and go on github and find yourself some re-usable MCU code.  Try and find yourself some 'testable' code.  You will struggle.  Why?
« Last Edit: March 28, 2023, 10:49:34 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #858 on: March 28, 2023, 10:58:33 am »
An example is the ESP32.

Rumour has it that Espressif hired some guy from some forum, who "knew everything" :) and they paid him to integrate it all properly.

So you got a good package which works out of the box...

Whereas ST is providing a "90% working" package which everybody has to independently fix. The same wheels have to be re-invented many times, because most people who have fixed code are not publishing it, due to laziness, having done it in company time, the company banning social media participation, etc.
« Last Edit: March 28, 2023, 11:00:15 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Online paulca

  • Super Contributor
  • ***
  • Posts: 3994
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #859 on: March 28, 2023, 10:59:04 am »
Trying to pre-counter the "straw man" appealing to extremes replies...

I agree just because someone makes a fully automated CNC based wall drilling machine, does not mean you should use it, even if it's "free", to drill 2 holes in the wall to put a shelf up.

However it would seem in MCU world, you don't even have a basic masonry hammer drill.  What you get is a collection of parts, a motor, a weight, a selection of gearboxes you take a week to configure after reading the manual.

You can go and look for other people's "drill code", but your mileage will vary because, that person will have used the collection of parts to make HIS drill for HIS project and HIS project alone and you will find it's not a perfect fit.  His code is not configurable, flexible or dynamic enough to reuse, so you have to rewrite it.

Why would that person want to write code for other people anyway?  This right here is where we get into professional ethics, disipline, future proofing, building relationships and understanding that if it takes more than one person to build, then a lot of the problems you will need to tackle are not at all technical, but they are still part of the engineering.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Online paulca

  • Super Contributor
  • ***
  • Posts: 3994
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #860 on: March 28, 2023, 11:01:26 am »
An example is the ESP32.

Rumour has it that Espressif hired some guy from some forum, who "knew everything" :) and they paid him to integrate it all properly.

So you got a good package which works out of the box...

Have you used it?  The IDF?  It's got it's own issues.  It's monolithic for a start.

Also, that story about the forum guy was not about the IDF at all.  It was the a subset of the bluetooth interface for the ADF.  He already had an opensource implementation that surpassed Espressif's.  So they re-used his.

That's perfectly normal in the software world.  We like to help each other because we will receive in kind.  You reap what you sow.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #861 on: March 28, 2023, 01:30:26 pm »
Not used the ESP32. It became popular during the covid madness when ST etc were not shipping (to distribution) but the chinese stuff was available. Last I heard was somebody having loads of fun integrating tinyUSB on the ESP32, and finding some quite subtle bugs.

I would never use a key part from china. The political risk is way too high. This guy acks that but says they got nice orders whereas with ST they would have shipped minus zero.

It's funny... my project was being developed when ST weren't shipping; I got 500 32F417 chips just before the world went mad, and it is approaching finishing just as the world recovers :)

Nothing is perfect, which is why I prefer to get good with one thing and stick to that. The investment in a CPU, dev tools, PCB design, etc, is massive.
« Last Edit: March 28, 2023, 01:33:12 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Online paulca

  • Super Contributor
  • ***
  • Posts: 3994
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #862 on: March 28, 2023, 02:09:51 pm »
The ESP32 however is not even in the same class of MCU as the STM range.  It's a sooped up wireless module that happens to have more core power than it really needs and someone figured out if you strap 2Mb of flash to it, makes a great little Wifi/Bluetooth MCU platform.  Once you start to try and use it you find it rather limited.  The 8266 far more so.  I believe the ESP32 has only 2 simplex I2S.  Two hardware UARTs.  One hardware SPI. One I2C and very little else.  It is not highly featured.

I found it's IDF a bit like importing the entire STM32 firmware for not just your particular micro, but the whole range all at once, wrap it in at least 3 layers of C++ ObfuscationOritentedProgramming and then release at least 2 or 3 different incompatible versions and a matrix of compatibility with other IDF add-ons.  Getting anything detailed work with external hardware simply doesn't work and forces you into those layers of OOP to try and work out WTF is happening.

After 3 evenings trying to get a codec to work with I2S with with 3 "working" examples, I failed.  One of those working examples probably did have the correct config, but it was too confusing to tell what config was what through the whole "kernel style" project configurator and the build config, output platform settings and flash partitions.

I still intend to return to the ESP32 and learn it a bit better, but I prefer using CubeMX and keeping my code separate from HAL, or warpping HAL up into little boxes where it can't intervene unintentionally.    If I am to create a new project today that requires Wifi or bluetooth I will use my dual MCU board and just use the ESP32 with it's default factory AT firmware as a wireless module.

STM32 HAL isn't perfect.  In some places it's a step in the right direction.  In others it's a mess.  I think it tries to do to much within the limited facade it presents.  This makes the layer between high level config and low level details too thin and usually requires the inner workings be understood to diagnose the problem.  A clear sign the "library" is not ready to be a library.  The fact they provide the code should just be a reference bonus and debug assistence, it should not be required to understand how to use it.

On a more grander scale.  If I ask myself how I would fix the issues in MCU world and what I would suggest for reusability?  I don't know.  Not an easy task.  How do you encourage code reuse and sharing in a mostly proprietary drivin industry?

Take STM32-HAL for example.   Let's get that bad boy out of STM32's malpracticing paws and get it on a proper open source eco-system and start encouraging feedback and pull requests for people who contribute bug fixes, facades, features and big prizes for those who contrib documentation.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline dkonigs

  • Regular Contributor
  • *
  • Posts: 107
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #863 on: March 28, 2023, 03:12:49 pm »
Take STM32-HAL for example.   Let's get that bad boy out of STM32's malpracticing paws and get it on a proper open source eco-system and start encouraging feedback and pull requests for people who contribute bug fixes, facades, features and big prizes for those who contrib documentation.

But then how would every single engineer take pride in writing their own HAL, brag about how it makes them superior on forums, and then never share the fruits of their labor with anyone?

In a more specific example this, there is the "opencm3" project, but I don't think it covers very much of the ecosystem or necessary feature range.  And its general to the ARM Cortex series.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #864 on: March 28, 2023, 03:16:17 pm »
Take STM32-HAL for example.   Let's get that bad boy out of STM32's malpracticing paws and get it on a proper open source eco-system and start encouraging feedback and pull requests for people who contribute bug fixes, facades, features and big prizes for those who contrib documentation.
Isn't that what libopencm3 was supposed to be ?
Besides now you preach another song, first it was re-use what is there and HW engineers re-invent and build everything from scratch,
and now you say lets again invent another HAL   ;)
BTW: from my own experience, at least embedded SW engineers are just as bad as HW engineers when it comes to : not invented by me so lets start over again.
I think it is not HW or SW related, it is everywhere, from authors of novels to artists to managers.
Every person is unique and that unique way of looking at things makes another persons unique creation not as it should be.
 

Offline dkonigs

  • Regular Contributor
  • *
  • Posts: 107
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #865 on: March 28, 2023, 03:19:08 pm »
Yes.  It's just that that is not what I see "out there".  Maybe the content I am reading on here and on several other forums is unrepresentative, but all I see is people struggling with the same code as MCU engineers where in the 1990s.  It's the same shit, the same routines the same problems over and over and over again. 

When I start a new project on an MCU I get annoyed almost immediately because I have to rewrite the debug UART routines.  Even with HAL this takes time.  I get annoyed because it's completely against my grain.  Yes, of course I can wrap my own library up and package it for re-use in my projects, but the fact this isn't just an off the shelf component for every MCU project baffles me.

Each and everytime you rewrite it you always introduce new and unique bugs.  Because nothing is encapsulated it's all sitting on jelly and when one thing changes everything else falls over.  It's just so ... eugh.  Wasteful.

Write a UART debug library.  Write it once.  Test the wazoo out of it.  Package it.  Reuse it.

Add a bit of functionality to allow adding timestamps to debug UART output, write it once, test it, package it, reuse it.
And this is a common enough use case, that you really shouldn't have to write that code... at all.  You should just be able to take some off-the-shelf logging package, write a few support functions unique to your platform's UART peripheral and/or other requirements, and go with it.

In the world of normal software engineering, logging libraries like this are extremely common. There are many to choose from, both built into frameworks and standalone.  So I was flabbergasted at the response I got on these very forums when I tried to ask for suggestions about one for embedded.  Most of the replies were from people who simply had no clue what a logging library was, and simply thought I needed help figuring out how to write a UART function (or suggestions for an alternative that runs over SWD, of which there are several).  The rest were of that "why do you need this, just DIY" nature.

Among the mess, I did finally find something.  But it very much had the feel of one guy's side-project, and is likely not that well known, but it got the job done.
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17729
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #866 on: March 28, 2023, 05:39:53 pm »
The point is electronics people insist on building everything from scratch.  I can't understand how you innovate if you have to do everything from the smallest possible blocks every, god damn time.

Software Engineering is about NOT doing that.

within my line of work as with most people you do the same things over and over with the same chip or same series and you reuse your code. That is the point. If you write code that works for you you will reuse it over and over, which beats the hell out of having to sort out the next little gotcha in some system that has no documentation.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #867 on: March 28, 2023, 05:49:01 pm »
Among the mess, I did finally find something.  But it very much had the feel of one guy's side-project, and is likely not that well known, but it got the job done.
Well, there is always the tradeoff between debugging somebody else's code / adapting it to make it fit or writing your own. In the end it depends on what is the least amount of work.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 17729
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #868 on: March 28, 2023, 05:57:17 pm »

Probably the rant is about something else. Maybe the pressure to use predefined libraries of unknown quality. Also it's a nasty situation for an embedded person if the ARM family one learned disappears, like it happened to us.

Regards, Dieter

My rant is about the dumbing down of the industry. Every kid now that can use a code configurator thinks he is an electronics engineer. My junior colleague sneers at the idea of setting a register up, he uses the ESP32 and expects to never have to deal with the hardware. Until I tell him that the serial port must reject unwanted bytes but not reject every message just because the message start byte is not at the start of the ring buffer he gets dumped by the serial driver.

I use what I like, I don't feel pressured to use what someone else thinks is best. But if the time that these kids young and old spent watching endless tutorials that contain tiny pieces of information or trying to copy "examples" on actually learning something meaningful the industry would not be full of amateurs.

I'll explain again if you can distract yourself for 5 seconds from the configurator. You cannot properly develop a complex project without reading the datasheets even with a configurator. For example, often counters share a clock source. So you make look at a chip and see how many counters it has and then want to set each one up to do something different. Oh but the configurator will warn you of this - yes sure dick head, you want to get that far into your project before you get the chips constraints forced on you by reality as the configurator tries to hold you little hand. Just grow the hell up, take the little time it takes to learn about what you are using and what it does rather than stumble on how it works by accident.

If I have to read the datasheet anyway what is the point of the configurator. Interrupts in ST world are nuts. So the uart has an interrupt, each port has an interrupt line, so do you write code for this? no of course not that would be too efficient. You instead write code to handle the specific event, this code gets called by the interrupt, you know an event linked specifically to that port, whereupon the first thing you do is figure out which port is having the interrupt for the type of event - totally backwards. I don't know if this is all just optimized out in compilation but I am not comfortable with it at all.

There is single application programming and there are operating systems, lets not confuse them. Because no pure computer programmer is going to make a good electronics engineer unless he learns about electronics instead of treating everything like a PC.
 

Online paulca

  • Super Contributor
  • ***
  • Posts: 3994
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #869 on: March 28, 2023, 06:07:25 pm »
There is single application programming and there are operating systems, lets not confuse them. Because no pure computer programmer is going to make a good electronics engineer unless he learns about electronics instead of treating everything like a PC.

That statement highlights it works both ways.

In your example, in your way you need to know the interrupt exists and the code it calls... in advance.  In an HAL it cannot know that and must provide functionality to all cases.

If HAL was done right the answer to your question on how it work would be "None of your business", you don't need to know.

As you do need to know, it's not done right.

Also, to throw confusion, if you studied computing you'd find that a HAL IS a component of an OS.  You could argue that the STM32HAL is a partial OS.  Certainly moving up to RTOS and Embed it gets closer to such.

The whole point of an operating system is to provide a basic layer of functionality for managing hardware and resources, usually between multiple programs.  Mostly well overkill for MCU simplicity, but the notion is there.

Take a look at how the Unix specification is constructed for ideas.  In particular look at the basic GNU pallete of shell commands.  Do you see how each does a tiny little job.  Just that job.  No other job.  They are absolutely fucking useless for anything (really) in isolation.  However, armed with pipes and redirects there are very little basic applications you can't fabricate on a single line.  THAT is software engineering.  Take small units of software, make them work to do a small part of the other all job, then build a bigger more useful application out of those components.  In enterprise you end up on top of hundreds of layers.  A few layers really will help MC dev.

However, I'm sticking to my guns the issue to partly that electrical engineers are just trained to repeat everything.  If they have 14 products to create and each differs every slightly, they will create 14 different designs with 14 different sets of components and write the MCU code bespoke for each... BECAUSE they differ in the n'th degree.  Learning how to abstract the common and concrete the variable at each level and encapsulate it such that only the differences need catered for in each of the 14 projects, makes 1 very hard project to write and 14 configs.

The other large part is proprietary lock ins.  Hardware companies just don't share software it's not in their nature.
« Last Edit: March 28, 2023, 06:15:13 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Online paulca

  • Super Contributor
  • ***
  • Posts: 3994
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #870 on: March 28, 2023, 06:22:49 pm »
There are some parts of HAL which look like they started down a good route, but then promptly stopped when the electrically engineers started whining about change.

The callback and handlers system.  You will spot efforts to decouple that across the board.  However most of the upper layer functions are IFDEFed to disable it.

It allows things like "laymans" dependency injection.  Basically, if they continue that endeavour it will lead to a uncoupled code with multiple "hook points" to hang your own code in.

It's reversion of control pattern.  You use a big generic function call to do all the wonderful things.  When that big generic function call gets to the bits and bobs of your actual application it hands that single part over to your "deligate" or "handler".  Done to the extreme, all components used within the larger framework can be swapped out and replaced with custom overrides.

That leads to another pattern.  "Convention over configuration".  You make the frame work, out of the box default to something sane and useful in terms of "boiler plate code" such that nobody need to write boiler plate code and only need to touch it if they want to over-ride the convention.

I can see the sparks the later would introduce to an electrical engineering team.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #871 on: March 28, 2023, 07:29:49 pm »
It cannot be cost effective to embark on a project where the CPU has a 2000 page RM, without having working code examples.

Some people here say so but they are super clever and already know it all.

The proper way would be for ST to spend a totally miniscule % of their $14BN revenue, say $80k, on a "social media specialist" who is also a really good hardware and software dev.

The truth is that they are scared. I have seen this fear all the way back to early 1990s, with Compu$erve forums. These companies never learnt how to manage social media.

A part of my day job is a forum admin and I see the same there now. Companies which dominate that industry, and companies which could and want to compete with them, are too scared. They have (basically) told me so.

And the ones that do participate mess it up by employing stupid people who offer input which is banal, over-simplified, arrogant, downright rude... And then they complain that it didn't work for them!

As a data point, take my project.

32F417
FreeRTOS
LWIP
TLS
FatFS
ETH
USB (MSC & CDC)
A ton of stuff which I mostly wrote e.g. boot loader, loads of essential functionality. Factory test code...

A guy who is more clever than I am spent about 3 years worth of Monday afternoons on all but the last one. He used mostly Cube MX to generate code snippets and then googled all over the place to find patches to make it all work. This is despite e.g. LWIP was an ST port of the generic open source LWIP! He would not post questions on forums, which probably doubled his time spent.

So he spent ~100 full time days (I have allowed a bit for half a day a week being pretty unproductive) making stuff work which should have worked.

Why was he part-time? Because I could not afford someone full time. A very small business, etc. Also it was to some extent a technology demo project, to see what could be done, and the final form defined afterwards.

That amount of work is totally unacceptable.

I spent about 2 years, about a 50% duty cycle but actually many hours and days working at home, doing the last item. Learning C, learning Cube (of which I know about 1%). That's would also be unacceptable in a normal job but it's because it is my company, I am not young, not that clever, and I am extremely careful in writing and testing code (did 30 years of assembler, and hardware, on simpler chips).

There is no easy way. These chips are immensely complex and the above "open source" software varies from great (e.g. FatFS) to not good (LWIP or TLS). And all of it is totally unsupported - partly because it is old (LWIP goes back > 15 years) and the coders sorted out girlfriends years ago and moved on, and partly because the whole open source scene is like that. In some cases people make money integrating OS software but not in this case. I have not seen a "Magento-like" ecosystem in embedded.

As a lone operator, some things you just can't do. A product like this will take a few years to do, if you start with no experience. In the Z80 days, it would be a few months. Today it is 5x longer even for basic code, and much longer if integrating modules (like above) which nobody supports, almost nobody understands, almost nobody can test if you did it right...
« Last Edit: March 28, 2023, 08:23:47 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #872 on: March 28, 2023, 08:51:19 pm »
It cannot be cost effective to embark on a project where the CPU has a 2000 page RM, without having working code examples.
Some people here say so but they are super clever and already know it all.
The proper way would be for ST to spend a totally miniscule % of their $14BN revenue, say $80k, on a "social media specialist" who is also a really good hardware and software dev
The truth is that they are scared.

The ugly untold truth is that they are not interested in small businesses that buy 1 reel stm32 per year. Peanuts.
They are interested in the big numbers. My previous company negotiated about a few million microcontrollers a year!
As a software dev you get a personal registration at ST where you can ask your question, you can sent code snippets , you get a personal answer within 24 hours. Not that they directly solve it but they will help you as much as they can.
My experience with ST as a sw dev eight years ago for a major company was excellent.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #873 on: March 28, 2023, 09:04:00 pm »
The ugly untold truth is that they are not interested in small businesses that buy 1 reel stm32 per year. Peanuts.
They are interested in the big numbers. My previous company negotiated about a few million microcontrollers a year!

That makes sense, and it's not particularly "ugly". A company needs to make profits. Profits for a big MCU vendor is not with hobbyists and 1-person companies.
Good thing is that it's still doable with some effort. While it wasn't like this 20 years ago (which Microchip at the time completely changed, and then ATMEL.)

This is why the RPi initiative with the RP2040 is an interesting alternative, but unfortunately it's only 1 chip so far (and relatively entry-level performance) and only 1 vendor. A bit restrictive.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #874 on: March 28, 2023, 09:19:48 pm »
That makes sense, and it's not particularly "ugly". A company needs to make profits. Profits for a big MCU vendor is not with hobbyists and 1-person companies.
Good thing is that it's still doable with some effort. While it wasn't like this 20 years ago (which Microchip at the time completely changed, and then ATMEL.)

Totally agree.
Remember embedded microcontroller development late eighties/90s.
For hobbieists small firms impossible to do anything:
- Datasheets unobtainable.
- samples ? How many boxes were you planning to order ?
- debugging? You have to buy a Lauterbach ICE for $4000
Etc. Etc.

But I do understand peter frustration but to be honest it is pretty naive to think that 12 year old example code of LWIP is still relevant these days. There a specialized firms that will sell you IP+TLS packages and most important they will update them with the latest security vulnerabilities. Unfortunately also there yet again is that steep price you have to pay. I don't know the current market of these I left that field six years ago, it was an unwinnable fight. Every month there came more hacks and vulnerabilities, my point of view never ever do this yourself, you just can't update. You need the specialist firms.
Look at big company NAS makers from all the brands havingbthousands of employees only Synology was not affected.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf