Is ST Cube IDE a piece of buggy crap?

[ataradov]

I've seen a lot of MISRA-C complaint code from real world products. It is very bad. Like anything Cube generated by default is the cleanest code compared to that code.

MISRA-C allows any idiot write somewhat functioning code. But this comes at the expense of actually competent programmers not being able to write good code. So you just standardize mediocrity. In theory it allows you to hire bad programmers, but as I said, in practice MISRA-compliant code looks like hot garbage and it is a miracle it works, so in the end hiring bad programmers may not be a good idea.

And the same thing comes into play - all those things I've seen are overly engineered, which also shows me complete lack of experience by people working on that stuff.

[peter-h]

", there is a certain amount of satisfaction knowing you designed something "just right" with little to no waste or any vestigial parts. "

However, that disregards the massive savings you make by re-using hardware and software developed for a previous product.

Secondary benefits are big reductions in the range of components which have to be stocked.

Coming back to CubeIDE, what I don't get is why the granularity is so coarse. The result is that a lot of the generated code is reading back config register bits and then bypassing code if some feature is not invoked by earlier code. This is stupid.

[SiliconWizard]

MISRA-C allows any idiot write somewhat functioning code. But this comes at the expense of actually competent programmers not being able to write good code. So you just standardize mediocrity.

I guess you could say that, although a number of the MISRA-C rules (not all for sure, I agree with this!) are really common sense and hard to question. Yeah, others are more questionable.
But as I said, all of this doesn't (unfortunately, you could say) really matter. MISRA-C has become industry-standard in some areas, and you just can't avoid it. If you hate it, better work in a different area.
You're of course entitled to have this opinion - just saying that, no matter how good or bad MISRA is, many people just have to do with it, and to get back to ST, you can't blame them for following MISRA-C guidelines. They do it for a reason.

Now do these hard rules and methods hinder software development in some way? I think so. It's a bit like the frantic agile movement. And yes, you're right, part of it is to allow hiring less competent programmers - which means making the hiring process much easier, and making replacing people easier too.

[dkonigs]

I follow the TinyUSB project, which aims to provide a common user-facing solution for the device classes it supports, while handling the chip-specific stuff in the background for you. As you can imagine, it's got a lot of preprocessor macros that sort out which USB peripheral and which processor are used. I haven't had a chance to really test any of it, but at least there's work going on in this area.

I've been using TinyUSB for the device side of a project I'm working on, and have been generally pleased with it. The niche it intends to fill, which is people who don't want to suffer the weird licensing terms of a vendor-specific stack and don't want to pay $$$ for a commercial 3rd party stack, is one that needs more attention.
My main gripe with it is that they don't seem to be putting as much effort into the host side of things. Which is a shame, because I'm working on another project where I'd gladly ditch the vendor stack if they did.

(In both cases, I've needed to make minor modifications to these stacks to deal with real world issues they neglected to cover. I'd much rather make such modifications to a full F/OSS solution where I can easily publish the change I had to make, than to something distributed under semi-restrictive terms where their source goes into a repo as periodic dumps and there's really no one on the other end to have a conversation with.)

[ataradov]

I guess you could say that, although a number of the MISRA-C rules (not all for sure, I agree with this!) are really common sense and hard to question.

But those things are already a part of the coding styles, and have been for ages before MISRA came in.

If you hate it, better work in a different area.

For sure, I'm not arguing that it did not become standard. And I personally would do everything I can to avoid working in such environment, as it is a huge waste of time and productivity. This may reduce my earning possibilities, but I prefer sanity over that.

Significant part of what MISRA-C is for is to cover your ass in case of issues. The more paper you have have - the cleaner your butt.

[peter-h]

"part of it is to allow hiring less competent programmers "

Surely that was the purpose of C++ ?

If you have say 20 people working on one product, in C, it's likely to end up a mess, because no more than 2 or 3 of them will be good.


Kidding aside, I had never heard of MISRA, so I searched for it. Found a lot of people trying to make money out of it - presumably selling validation/consultancy services

This has some info
https://pvs-studio.com/en/blog/posts/cpp/0702/

and it looks like good stuff. I too avoid malloc(). This is quite funny - who does it??
"Loop counters mustn't be of the floating-point type"

Actually I have used malloc() but only in an RTOS task which is started optionally and never terminates, so there is no free(). It avoids wasting static memory, and avoids the need for a huge RTOS stack for that task.

[ataradov]

If you have say 20 people working on one product, in C, it's likely to end up a mess, because no more than 2 or 3 of them will be good.

But from places that need MISRA compliance, you would expect to naturally hire better people.

Found a lot of people trying to make money out of it - presumably selling validation/consultancy services

Yep. That's pretty much the point.

"Loop counters mustn't be of the floating-point type"

Not only that. Loops must generally be over positive integers and don't have complex ending conditions.

There are a lot of other bat shit crazy requirements.

The issue that MISRA solved a long time ago was lack of static code checking in compilers. We have that now. Most concrete things from MISRA are now checked by the compiler. And other more organizational requirements are not really checked at all, even by those expensive tools.

Also, MISRA allows exceptions as long as you document them and explain why you need it. Which relies on a better judgment, which in this case will come from the same unqualified, but easy to hire people.

And yes, I understand why framework authors make their code MISRA compliant, but that is also a good reason to not use it - it always ends up more convoluted and complicated to workaround artificial limitations.

[SiliconWizard]

"part of it is to allow hiring less competent programmers "

Surely that was the purpose of C++ ?

This is exactly what Linus Torvalds said.

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

[peter-h]

I have a complete solution for MISRA compliance: Pascal 1975

That is roughly the level at which I use C. The other day I found this gem, which works but I have little idea why (actually I did look it up)

Code: [Select]

amplitude0 = (amplitude0 > 32768) ? 32768 : ((amplitude0 < -32768) ? -32768 : amplitude0);
(the variable is int32_t, btw)

Someone could suggest Pascal to ST, as a Cube option.

[Kjelt]

Well hiring better people..... they stopped teaching C in universities and colleges.
Most new applicants have C# or  C++.
It takes some time to learn them the embedded C ropes and then the question remains if it is a good move for a recently graduated SW engineer to learn embedded C ?
I always said yes but the last years seeing the job advertisements I start to say no.
If you need to get another 30 years working before retirement you better do something modern that is still in demand over fifteen years.

[ataradov]

Well hiring better people..... they stopped teaching C in universities and colleges.
Most new applicants have C# or  C++.

You are hiring embedded people, what C#? C++ is fine, as long as they understand how to apply it in embedded systems.

if it is a good move for a recently graduated SW engineer to learn embedded C ?

If they want to do embedded work, then what are their other options?


All MISRA code I had to review was in C, not even C++. I don't anticipate this to change for some time.

[nctnico]

Well hiring better people..... they stopped teaching C in universities and colleges.
Most new applicants have C# or  C++.

You are hiring embedded people, what C#? C++ is fine, as long as they understand how to apply it in embedded systems.

if it is a good move for a recently graduated SW engineer to learn embedded C ?

If they want to do embedded work, then what are their other options?


All MISRA code I had to review was in C, not even C++. I don't anticipate this to change for some time.

I agree the embedded world moves slowly. Not long ago there where still debates about C versus assembler. IMHO the next good move would be C++ because it allows getting rid of using pointers (passing a struct by reference is a whole lot safer than using a pointer).

But a much better move would be to use a scripted language like Lua or Python which runs in a VM and has boundary checks built in. But that likely takes another decade to become considered as a viable option.

[SiliconWizard]

It takes some time to learn them the embedded C ropes and then the question remains if it is a good move for a recently graduated SW engineer to learn embedded C ?

If you want to work on embedded software, of course it is.
Now if you want to write financial software, not so much. Define your goal.

I always said yes but the last years seeing the job advertisements I start to say no.
If you need to get another 30 years working before retirement you better do something modern that is still in demand over fifteen years.

C will still be in demand long after we'll be all dead IMO. It may appear to vanish if you look at job ads - not because it's not used anymore in embedded dev (what else otherwise, as ataradov asked?), and we'll always need that, but because other kinds of software have literally exploded, so they are masking the demand. So it all depends on what you want to work on.

[Kjelt]

Let me clarify the job is called embedded software engineer because the software controlls industrial machines but there are no small 32 bits micros , but huge linux servers. Still the software is all written in C and we are looking to see if we are going to switch over to C++. But that is a huge effort and risk esp. when mixing in the transition phase.
Anyhow the question remains if say your nephew of 28 just graduated and looking for his first job, would you recommend him to go to an C embedded job ?
I personally would not anymore, too little good paid jobs and not very future proof.

[ataradov]

Anyhow the question remains if say your nephew of 28 just graduated and looking for his first job, would you recommend him to go to an C embedded job ?

I would, since it gets you as far away as possible from web and javascript. But different people have different preferences, so ultimately it depends on what they like.

I'm not sure there are any fewer MCU-style embedded jobs. Someone has to program those things.

And if you want to get paid well, then be a lawyer or something like that.

[SiliconWizard]

I'm not sure there are any fewer MCU-style embedded jobs. Someone has to program those things.

There are more. MCU use is exploding.

And since there are fewer young people able to program in C, the demand is not going to plummet, but it's going to explode.
Now sure this will still be a "small market" compared to the rest of the software world. But ask yourself the right questions. As we said above, what do you want to do? Do you want to be able to apply for jobs that everyone else can also apply for, and thus, even if there are many jobs available, there's also a lot of competition - but maybe feel more like part of the herd, or do you prefer a niche? It's the whole question.

But the question of fearing to find no job is irrelevant. Heck, look at COBOL. Even if almost nobody is talking about it these days, and I bet you practically see no ad with a COBOL job, there's still high demand, and it pays very well. It will be the same with C.

Oh, and last word: someone really asking themselves what they should choose now to make sure it'll still be there in 15 years? It's definitely the wrong way to look at it. While I'm certain C will still be massively used in 15 years, and even in 30 years from now, you should not approach a career this way. Whatever happens in the next 15 years is yours to build. It's going to evolve. And, ironically, while C will likely still be relevant in 15 years and more, that may not be the case for other, more recent and hyped languages - so you need to reflect on that. And whatever you do now, keep preparing yourself for the next thing at all times. Just my 2 cents.

[peter-h]

The thing which would worry me about C and embedded etc "exploding" is how much skill you need to do embedded work well, compared to e.g. server side coding, with PHP being probably most common historically but there are many other languages, and most people I know who do this have a very short experience (say 2 years) and those who have been doing it since the internet became popular (say year 2000) are doing their best to get out of it because they got sick of working in an environment where the requirements change so often.

Even those who run their own business - traditionally with a high level of job satisfaction because you can control your job spec - are trying to get out of it. I run a few websites and have had to deal with server side project spec and management and it is a bloody nightmare. I spec new projects to be done in PHP because it is IMHO the only language which will remain "in fashion" for many years. One site I run was done in Ruby on Rails and it is a nightmare unless you want to chuck 1k/day at someone. You can get a good PHP coder for $50/hr.

The way CubeIDE does C code generation is only enough to get you started without reading the RM. To do anything nontrivial you need the usual amount of embedded experience, as well as knowledge of where the skeletons are buried in real time code generally. And I don't see any way to get around this, other than re-use of working code, paying somebody (who has been doing it for many years) to write it, etc. So I see plenty of demand for C coders, and most of it will be embedded because C isn't used much elsewhere.

[Kjelt]

I would, since it gets you as far away as possible from web and javascript. But different people have different preferences, so ultimately it depends on what they like.

I understand. Embedded programming on small uCs was probably one of the most fun jobs I have had.
Unfortunately I have seen mostly all those projects move overseas where the results were not better but the labour cheaper. Hope that it will return so newer generations can also enjoy.
If you are single, a contractor and willing to travel the world you probably could earn very nicely.
If you have a family and bought a house, priorities change to finding a job closer by.

[peter-h]

Should Cube behave differently on Linux to Windows?

I am trying to set up a copy of the project on a Linux machine and the project won't build. It fails to find some files... but they should come with either Cube (same version, 1.8.0, is used) or with the project files.

[nctnico]

Should Cube behave differently on Linux to Windows?

I am trying to set up a copy of the project on a Linux machine and the project won't build. It fails to find some files... but they should come with either Cube (same version, 1.8.0, is used) or with the project files.

I'm using cube on Linux. The biggest pitfall with moving projects between Windows and Linux is that Linux is case sensitive where it comes to filenames and directories.

[peter-h]

Indeed; I realised this pretty quickly.

I also reckon that the ST Cube libs won't build under unix, because of case diffs between some files and some directory names. They probably never tested the package they send out except under Windows.

If say 2 people collaborate on the same project, one windoze and one unix, the windoze guy needs to do a few edits on filenames And do them again if the ST libs are updated (which may not happen for ages, if ever, because it's obviously dangerous).

One also has to recompile any post-build executables, re-do scripts, etc, but that's not the fault of Cube. I am told one could avoid that if these were done in Java

[Kjelt]

If say 2 people collaborate on the same project, one windoze and one unix, the windoze guy needs to do a few edits on filenames

2 or 20 or 200 all the same ballgame, they should use one repository,  one and the same toolchain on the same os.
In any company (at least the four I worked for in the past) there is a document or wiki describing exactly which tools and toolchains , which versions etc. etc. should be installed. Some bigger companies offer an out of the box completely installed VM or VDI .

[peter-h]

Sure, but I think you will find the ST libs won't build out - under unix - of the box, due to some case differences.

[nctnico]

If say 2 people collaborate on the same project, one windoze and one unix, the windoze guy needs to do a few edits on filenames

2 or 20 or 200 all the same ballgame, they should use one repository,  one and the same toolchain on the same os.

Why? The OS doesn't matter because the very same compiler is built for several OSses producing the exact same binary.

[Siwastaja]

Why? The OS doesn't matter because the very same compiler is built for several OSses producing the exact same binary.

I agree with you, but I understand why - in certain types of corporate environment, dancing around complexity and uncertain tooling is the key which drives the management jobs. If a working product emerges, that is only a side effect.

I'm all for Doing The Right Thing. Limiting everyone to the same compiler version makes sense in embedded products, but it's already ugly enough that I would strongly avoid adding other tooling to that rule. IDE should not matter, let people use what makes them productive, and if this is a problem, then fix the broken process instead of working around it by forcing people to use the exact same tools that are broken in the same way.

The deliverable should be code, not an IDE project file. If an IDE does not support participating in a project without requiring everyone set up the same IDE, then this IDE is broken.

The fact that ST code does not work under everything else but Windows is totally unsurprising. Just don't use broken crap. Case-sensitive filenaming is basics of the basics. I understand some particular company might specialize in some niche such as Windows-only desktop apps or maybe small embedded projects always and only using PIC microcontrolers, where this does not matter. But ARM development Windows-only, ignoring all Unix-y systems? Give me a break.