Is ST Cube IDE a piece of buggy crap?

[Bassman59]

Now do some code for transmitting data.

The interrupt may be generated only when the TX becomes empty. So you have to put a byte into it "manually" to get things started.

It gets a bit more involved.

The old trick is to put the stuff to transmit into a FIFO, and then check to see if a transfer is already in process by checking a status flag. If not, then the transmit is kicked off by setting the transmit-complete bit to trigger its associated interrupt. In the ISR, you check to see if the transmit FIFO has something to send, and if so, pop the FIFO and write the byte to the transmitter.

Which I suppose is "a bit involved."

[cv007]

I have some basic code for an stm32 in C++. Getting something up and running on your own is a good way to get a feel for a particular mcu. It usually starts with getting some gpio code working, then continues from there as far as you want to take it.

https://github.com/cv007/NUCLEO_G031K8
https://github.com/cv007/NUCLEO32_G031K8_B

At some point you have to decide whether to keep going or decide to learn some other provided code/hal. I have a hard time wading through manufacturers code, so I normally stick to what I can produce myself.  For something like an nrf52, I will create both my own code where I want and also create code using existing manufacturer code but will still have my own 'interface' (the app code does not have to deal with manufacturer code, as it is tucked away in my own functions). In some cases its easier to start with existing code, and after some investigation you discover there is really not that much there and can then simply replace it all with your own.

You can over time build up a library of your own that can be reused, and with C++ that becomes a little easier to do. One example is the Format class I have in the second linked example- I can use that for any mcu (I also use it for the nrf52, and can test in an online compiler and compare results to normal cout results via x86 compile). In that case I was trying to find a better way to deal with printf as newlib is a bit bloated in this area and there doesn't seem to be a good/easy way to 'hook' a put function into the FILE struct (which is huge). I originally used sprintf to do this work (for 32bit mcu), and the stack was used for the buffer since these are blocking functions but you have to know what kind of stack space you will require in advance. A printf replacement would also be somewhat easy to create, but the cout style is actually easier code to create and I am already in C++, so... The downside is the cout style, but can get used to it, and not really any other downsides as code size stays on par (similar size to the sprintf version for a 32k nrf52 project). The upside is you get an easy way to have formatted print to any device you want (lcd, uart, buffer, etc.) and can look at all the code in one page of a header.

Now do some code for transmitting data.

The interrupt may be generated only when the TX becomes empty. So you have to put a byte into it "manually" to get things started.

It gets a bit more involved.

From the above linked example basic tx uart code which is blocking, to a buffered/interrupt powered tx with just a few changes (its a little bit quick and dirty, but can be polished up with a little more effort)-

Code: [Select]

//inside Uart.hpp
static constexpr auto BUFSIZE{ 64 };
u8 buf_[BUFSIZE];
u8 bufIdxIn_;
u8 bufIdxOut_;
volatile u8 bufCount_;

public: //allow access to hook up isr to vector table
                auto
isr             ()
                {
                //not checking ISR.TXE bit (should be 1) as we only use TXEIE so only one way to get here
                if( bufCount_ == 0 ) { reg_.CR1 and_eq compl (1<<7); return; } //TXEIE=0, done
                reg_.TDR = buf_[bufIdxOut_];
                if( ++bufIdxOut_ >= BUFSIZE ) bufIdxOut_ = 0;
                bufCount_--;
                }
private:

                virtual bool
put             (const char c)
                {
                while( bufCount_ >= BUFSIZE ){} //if buffer full, wait for txe isr to make room in buffer (read of bufCount_ needs no irq protection)
                buf_[bufIdxIn_] = c;
                if( ++bufIdxIn_ >= BUFSIZE ) bufIdxIn_ = 0;
                //protect increment (needs write protection as var also written in isr)
                { InterruptLock lock; bufCount_++;  }
                reg_.CR1 or_eq (1<<7);  //TXEIE=1
                return true;
                }
And resulting use (also quick/dirty as we need to 'manually' connect the isr function up)-

Code: [Select]

#include "MyStm32.hpp"
                int
main            ()
                {
                irqFunction( board.uart.irqN, []{ uart.isr(); } );
                u32 n = 0;
                while( true ) {
                    uart << "Hello World [" << setwf(10, '0') << n++ << "]" << endl;
                    delayMS( 500 );
                    board.led.toggle();
                    }

                }

                }

[westfw]

The concensus of SW engineers is that re-using proven and tested code modules is far superior than rewriting from scratch.

Um, that's the current consensus of non-embedded SW engineers writing relatively complex code on systems with essentially infinite resources in several dimensions.

I'm not sure it applies to deeply embedded systems, where your resources are more constrained.
...or when the "proven and tested code module" is harder to understand than what you need to accomplish.
... or when "proven and tested" is ... not so much.
...  or when the existing modules are a poor match to what you actually want to do.

And about half of those "SW Engineers" will also complain bitterly about how modern Python/Arduino/whatever programmers "don't actually program, they just search for existing code and libraries to do everything they want.")

I'm unlikely to write a network or usb stack from scratch.  But ... some subset of a UART, GPIO, or Timer?  It hardly seems worth figuring out a library (and it surely doesn't help that the library isn't "portable" to other vendors.)

[Kjelt]

The concensus of SW engineers is that re-using proven and tested code modules is far superior than rewriting from scratch.

Um, that's the current consensus of non-embedded SW engineers writing relatively complex code on systems with essentially infinite resources in several dimensions.

Look around most industrial embedded systems be it for industrial machines, robots, IoT devices or cars are getting relatively complex and MBytes of ROM are standard with GBs of flash card storage on the side.
I am not talking about an 8b uC with 1kB here, those were the good ol' days.
Also touchscreen lcds with GUI libraries, sure you can write them yourself but why?

I'm unlikely to write a network or usb stack from scratch.  But ... some subset of a UART, GPIO, or Timer? 

That is my point and what if those vendor ready libraries require the vendors ready codestack ? How much time to port that to a selfmade optimized stack?

But as I said before, the persons that still do this made a conscious choice , often in the past, are used to their choices and have the experience, so all fine.

But I had trainees that have to make a PoC with ethernet and BT interconnectivity, they join for six months and with a standard stack they have something up and running in 4 to 5 months. They feel great they have done and finished something. No it is not perfect and product ready code but good enough for the stakeholders to decide to make a real project for it. Now try that from scratch for someone without much experience.

[Siwastaja]

Kjelt, you are really hitting the nail!

You have all the key findings in place better than I ever could have said it. Trainees can make proof-of-concepts for investors!

And don't get me wrong, I'm not belittling this use case, it's necessary to do so. It's just that I can't do it, for psychological reasons, it feels wrong to me, so I let others do it. In fact, I would encourage to even drop the bar lower. Paper images of UIs, Arduino mockups of control circuits wired up in a mess of wires... Six months is already quite  a long time to prove the concept.

Just that I feel a little bit frustrated because often this feels like wasted effort. If we just could communicate the investors about the importance of the projects without spending 6 months to create a proof-of-concept that then needs to be redone, we could go "straight into" the product phase.

But do you see the huge contrast here? In essence, you are saying these practices are used by trainees to make proof-of-concepts after which becomes the "real project". I completely agree with you. However, many others have given the impression that really high-quality, tested and safe (MISRA and all!) software comes out of this same process. I don't agree with them, and don't think it really works that way.

In any case, I think I see where the problem lies. It's in the poor interfaces and poor documentation of those more complex libraries. In optimum case, you would do simple things yourself, and then when in need of USB stack or LCD graphics library, you would just read clearly laid out documentation with examples, #include a .h, and link against the library. There is no place in this for code generation or any special tools, IMHO.

This is how it works classically. If I need zlib, I do sudo apt-get install libz-dev, #include <zlib.h>, and add -lz to linker, and read the documentation which exposes the very small and simple interface to it. And then there's a small tutorial.

And I don't have to follow any "framework" in the rest of my program, it's utterly irrelevant how it is partitioned.

[dietert1]

As was mentioned before: Nowadays there a business models (e.g. this forum), where elaboration and optimization of scripted prototypes never happens, as nobody wants to pay that work. Commerce does not automatically bring out the best solution but one that is good enough.

Hobby or academic environments are different. People can/will put arbitrary amounts of effort into realizing their idea of something "nice".

Regards, Dieter

[westfw]

Look around most industrial embedded systems be it for industrial machines, robots, IoT devices or cars are getting relatively complex and MBytes of ROM are standard with GBs of flash card storage on the side.
I am not talking about an 8b uC with 1kB here, those were the good ol' days.
Also touchscreen lcds with GUI libraries, sure you can write them yourself but why?

I thought we were talking about the sort of software implemented by the ST Cube environment.  Isn't that mostly low-level drivers?
I hope so.  The higher-level you get, the more I dislike the idea of being tied to a particular vendor's library, unless it implements some widely accepted APIs.  (For example, TI offers what is probably a pretty reasonable RTOS for its ARM chips, but I am not at all enthusiastic about using a TI-specific RTOS...)

[Kjelt]

Look around most industrial embedded systems be it for industrial machines, robots, IoT devices or cars are getting relatively complex and MBytes of ROM are standard with GBs of flash card storage on the side.
I am not talking about an 8b uC with 1kB here, those were the good ol' days.
Also touchscreen lcds with GUI libraries, sure you can write them yourself but why?

I thought we were talking about the sort of software implemented by the ST Cube environment.  Isn't that mostly low-level drivers?

Depends what you need and what you configure, but no, it can be much more than just low-level. Just a quick google example an Ethernet LwIP stack and RTOS.
https://community.st.com/s/article/How-to-create-project-for-STM32H7-with-Ethernet-and-LwIP-stack-working

[NorthGuy]

But I had trainees that have to make a PoC with ethernet and BT interconnectivity, they join for six months and with a standard stack they have something up and running in 4 to 5 months. They feel great they have done and finished something.

I don't advocate rewriting lwIP, zlib, or GUI libraries. If you were to write your own, this wouldn't be a rewrite, but rather something different. Otherwise, there's no reason to write your own, right? Without any doubts, using the ready-made lwIP is much better that writing your own TCP/IP stack in the wast majority of cases.

Although your estimates on how long it would take to implement TCP/IP + Arpa on your own are hugely exaggerated. I've never had to do this, but I know the underlying protocols and I guess it is probably a work for a couple of weeks, if not less. Definitely not for many months or years. And if your trainees did this, I don't see why wouldn't they feel good about their work.

[Siwastaja]

I have participated in making UDP/IP and ARP implementations from scratch - on FPGA in VHDL - and these are just utterly trivial - even simpler on CPU than on hardware FSM.

OTOH, TCP is somewhat moving target because doing a general purpose, optimized TCP that performs well with most modern workloads, is more complicated than the simple UDP. But I can totally see how in special case a simple TCP implementation would be rather easy to do. It would not be suitable for watching cat videos from Youtube, necessarily.

[Bassman59]

It would not be suitable for watching cat videos from Youtube, necessarily.

... but but but Tim Berners-Lee invented the WWW specifically to optimize the sharing of cat photos and videos! Using gopher and archie searches were wholly inadequate for this very important task.

[Kjelt]

Although your estimates on how long it would take to implement TCP/IP + Arpa on your own are hugely exaggerated. I've never had to do this, but I know the underlying protocols and I guess it is probably a work for a couple of weeks, if not less.

Guess again. In my previous company we bought an commercial IP stack for ipv4 and ipv6.
Getting that correct (many bugs in the ipv6 stack) including fixing security took a team of four people over a year. So that is only getting a commercial stack product ready. You have to deal with all kinds of rainy day scenarios, exceptions, etc. Not just transferring and receiving some testpackets. Your product should be mature enough to be connected to a corporate network and be approved by the companies it department.

[peter-h]

The old trick is to put the stuff to transmit into a FIFO, and then check to see if a transfer is already in process by checking a status flag. If not, then the transmit is kicked off by setting the transmit-complete bit to trigger its associated interrupt.

OK, yes, but to kick off the tx you will probably be using an RTOS thread (1kHz tick) or, in the old days, a timer ISR (1kHz tick). So if you are hoping to transmit at say 115.2k, you are gonna end up with very large gaps in transmitted data, each time the ex queue goes empty. It will work allright but not at the throughput you expected.

A better way timing-wise is to insert the code into fputc(), or whatever function you are outputting the data from.

In my previous company we bought an commercial IP stack for ipv4 and ipv6.
Getting that correct (many bugs in the ipv6 stack) including fixing security took a team of four people over a year.

I am not surprised. Most software is lifted from Stack Exchange at some point And a lot of it could have never worked at all.

But just because it is crap doesn't mean that what you can write in a few months will be lesser crap

I have participated in making UDP/IP and ARP implementations from scratch - on FPGA in VHDL - and these are just utterly trivial - even simpler on CPU than on hardware FSM.

Maybe 1% of good coders could do that. I used to do FPGA work too...

[NorthGuy]

In my previous company we bought an commercial IP stack for ipv4 and ipv6. Getting that correct (many bugs in the ipv6 stack) including fixing security took a team of four people over a year. So that is only getting a commercial stack product ready. You have to deal with all kinds of rainy day scenarios, exceptions, etc. Not just transferring and receiving some testpackets.

Just read what you have written. You bought a library which was

- expensive
- not secure
- buggy
- written so badly that four people couldn't fix it for over a year

Assuming this stack included just TCP/IP + Arpa, you hardly could do any worse than that. You example doesn't compare favourably to the "write from scratch" variant. Besides, rather than digging somebody else's shit for a year, it's much more rewarding to spend few weeks writing your own code.

It is hard to find an example that would demonstrate my point better: people hugely exaggerate the usefulness of the existing code, and equally exaggerate the efforts necessarily to create your own code.

Surely, there are many cases when re-using the existing code is well warranted, as they are many cases when writing new code is better. All I want to say is that the "consensus" on that matter is shifted enormously away from where the reality is.

Your product should be mature enough to be connected to a corporate network and be approved by the companies it department.

If they require that you use one of the approved stacks, then you certainly don't have much choice. This is bureaucracy, not engineering. There are many companies who specialize on compliance - a mediocre product may cost good money if it gives you regulatory approval. If you buy such a product, that's what you pay for - the compliance. Don't expect any technical merit.

[nctnico]

In my previous company we bought an commercial IP stack for ipv4 and ipv6.
Getting that correct (many bugs in the ipv6 stack) including fixing security took a team of four people over a year.

I am not surprised. Most software is lifted from Stack Exchange at some point And a lot of it could have never worked at all.

But just because it is crap doesn't mean that what you can write in a few months will be lesser crap

Indeed. Look at the long list of bug fixes in Lwip for example. Many of them are easy to overlook in the first pass; it is hard to write a good protocol stack. In the past I have written an ISDN2/ISDN30 protocol stack from scratch (mainly because these didn't exist as available IP). Getting something basic going took a few weeks but I think I have spend a year fulltime on it (off and on) before it was bulletproof.

[Kjelt]

You example doesn't compare favourably to the "write from scratch" variant. Besides, rather than digging somebody else's shit for a year, it's much more rewarding to spend few weeks writing your own code.

I don't want to repeat myself but you can not write a decent IPv4+6 stack in weeks.
Perhaps if you are already experienced and built it once and kept the design, notes etc. or took LwIP as example.
We are talking >30-40kB compiled code.
In a few months you would probably have bare minimum 75% sunny day coverage.
But then I guess you have to do it to believe it. Try it and we talk again perhaps you are a genius wizzard and myself and the programmers from my previous team are morons 

[westfw]

You bought a library which was
 - not secure, - buggy, - written so badly that four people couldn't [make it work in reasonable time].

Well, that's the question, isn't it?
Is STM Cube "buggy, insecure, and badly written", or is it "proven, tested, and useful"?
You might not be "paying" in any sense other than that you're reducing your vendor choices and spending your time figuring it out, but that can still be "expensive."

[westfw]

you can not write a decent IPv4+6 stack in weeks.

I wrote networking code for 30-odd years (starting before IP!), and I'm pretty sure I couldn't write a good networking stack in "reasonable" time. :-(

In my retirement, I've pretty much avoided working on networking stuff.  If writing a stack is difficult, using someone else's stack is TERRIFYING.  Especially if they're not open to bug fixes, don't have the extensive debugging I'm used to, or if they don't have visible source.  (like most BT stacks?  Shudder.)

[Bassman59]

The old trick is to put the stuff to transmit into a FIFO, and then check to see if a transfer is already in process by checking a status flag. If not, then the transmit is kicked off by setting the transmit-complete bit to trigger its associated interrupt.

OK, yes, but to kick off the tx you will probably be using an RTOS thread (1kHz tick) or, in the old days, a timer ISR (1kHz tick). So if you are hoping to transmit at say 115.2k, you are gonna end up with very large gaps in transmitted data, each time the ex queue goes empty. It will work allright but not at the throughput you expected.

A better way timing-wise is to insert the code into fputc(), or whatever function you are outputting the data from.

Well, this was back in the days of 8051 and a super-loop, so no RTOS threads. But re-read the rest of what I wrote:

In the ISR, you check to see if the transmit FIFO has something to send, and if so, pop the FIFO and write the byte to the transmitter.

So there are no gaps in the transmission, as long as something keeps the transmit FIFO from emptying. And it's the fputc() or equivalent which writes to the FIFO and then checks to see if the transmitter is busy.

[Bassman59]

You example doesn't compare favourably to the "write from scratch" variant. Besides, rather than digging somebody else's shit for a year, it's much more rewarding to spend few weeks writing your own code.

I don't want to repeat myself but you can not write a decent IPv4+6 stack in weeks.
Perhaps if you are already experienced and built it once and kept the design, notes etc. or took LwIP as example.
We are talking >30-40kB compiled code.
In a few months you would probably have bare minimum 75% sunny day coverage.
But then I guess you have to do it to believe it. Try it and we talk again perhaps you are a genius wizzard and myself and the programmers from my previous team are morons 

Two things I use that I do not want to have to write from scratch: an Ethernet stack for TCP/IP and web server, and a USB Device stack.

Thing is, I understand USB enough to be able to do that, except the documentation for many micros' USB peripheral is dense and opaque.

[Siwastaja]

Quoting nctnico, the truth is somewhere in the middle.

If integrating a complete existing TCP/IP stack and fixing/working around all the bugs took over a year for a team of four, clearly this process is broken and doesn't provide what it's supposed to do. You should be writing rest of the application and enjoying the library.

OTOH, that doesn't mean it could have been done from scratch in a few weeks, this is just way too optimistic. It sounds like the requirements for this stack were high, this was "the real thing". It's well known how colossally complex full TCP/IP solutions are.

The correct solution (for these more complex cases) is to use good existing code, and if not available, then commit into the large project from scratch. The benefit of the latter is that you gain full control and understanding over your solution. Though, if we are talking about commercial software development and not hobby projects, the team that did it should also document it very well to be able to transfer this hidden knowledge to their successors. This takes time!

Still, NorthGuy is completely right about the bias. People are ready to accept a year of work of just using a library without blinking an eye, as a normal, expected cost. In Orwellian way, this may be even called "saving time". But the mere idea of having to spend the same year of work doing something from scratch makes people outright crazy. People fear writing code, and management fears large blank sheets. People think reusing existing code as much as possible gives the assurance of getting at least something done, and that is true. At the same time, people are ready to accept whatever amount of work needed to make that existing code work, and irrationally use the amount of work required as a proof that the custom solution would have taken even more effort, maybe by orders of magnitude.

[peter-h]

If integrating a complete existing TCP/IP stack and fixing/working around all the bugs took over a year for a team of four, clearly this process is broken and doesn't provide what it's supposed to do. You should be writing rest of the application and enjoying the library.

I think this is completely ridiculous. That is something like 200k (plus at least as much again in employer tax, office space cost, etc) spent on bug fixing.

There must be more to that story.

Maybe there were some weird security requirements. Once you get into TLS and all the possible vulnerabilities, it gets much more complex. Especially in an embedded system where you get issues like secure private key storage (which is impossible unless you use specialised technologies e.g. dedicated crypto chips) or even the "simple" task of obtaining root certificates which you know are not fake.

[dietert1]

...
Still, NorthGuy is completely right about the bias. People are ready to accept a year of work of just using a library without blinking an eye, as a normal, expected cost. In Orwellian way, this may be even called "saving time". But the mere idea of having to spend the same year of work doing something from scratch makes people outright crazy. People fear writing code, and management fears large blank sheets. People think reusing existing code as much as possible gives the assurance of getting at least something done, and that is true. At the same time, people are ready to accept whatever amount of work needed to make that existing code work, and irrationally use the amount of work required as a proof that the custom solution would have taken even more effort, maybe by orders of magnitude.

Redoing existing work from scratch may just create more crap that later needs debugging. Debugging an existing library does create value. There is no alternative. This isn't about the professional experience of the pioneer, but about reuse. I mean library means reuse, so it's absolutely natural to find shortcomings and to write extra layers or interfaces to supplement the original.

Regards, Dieter

[Siwastaja]

Debugging and improving an open source project makes a lot of sense, assuming it's not totally, fundamentally screwed to the point of fixing it being more work than redoing it.

A commercial product that is sold for the purpose of making life easy? Different story. If it requires major rework (as indicated by a timeframe of 4 man-years), the question then is, should it be a joint co-operation and how is money managed? Licensing will be challenging at least! If it doesn't come with full source code, debugging it will be a slow endeavor (with broken telephone to the vendor).

Finally, most often it's not question of redoing anything, as said repeatedly by many. Usually you would write something completely different; for example, a tiny subset which performs better in the exact use case, or simply something that does not exist at all.

In the end, balancing between competition and co-operation is a big philosophical question. It's a fact that both drive development. Without them, stone wheels would be still used. It does not map 1:1, but code reuse relates to co-operation, and writing new code to competition. Wise man knows when to do which, and how. This wisdom is hard to concentrate in a short forum post.

But the "consensus" bias is that code reuse is like a religion, with reduced level of healthy suspicion, while writing new code is belittled by concepts like "NIH". This is obvious if you look at many comments where people are really cautious about not using any library, but it's really fine as long as you use something, allowing that tick-in-the-box. This is just cargo cult engineering. Same can be seen in li-ion battery management where any BMS, it can be faulty or totally unsuitable for the job, ticks that box, creating false sense of security.

[rpiloverbd]

Honestly, I found the mentioned IDE not user friendly. Once I installed that in windows 7 and stopped working at one point. I saw many options were missing. I don't even know why. I think if any of us is confident that there is a bug in STM cube, we should directly mail them regarding the issue. Or at least post in the ST community: https://community.st.com/s/

However, For those who are newly using STMcube and having difficulties in configuration and debugging, here is a  good write-up that can help: https://www.theengineeringprojects.com/2021/10/first-project-using-stm32-in-stm32cubeide.html