Is ST Cube IDE a piece of buggy crap?

[Nominal Animal]

Can anyone name a missing feature of ARM32 GCC 11 which arrives with GCC 12 and which is relevant to embedded development?

As you mention you only use C, you might be interested in the Compiler support for C23 and C99 page at cppreference.com.

GCC 12 adds digit separators (so that 0xDEADBEEFCAKECAFE = 0xDEAD'BEEF'CAKE'CAFE) in literal constants, #elifdef and #elifndef preprocessor directives, so nothing really important.

However, GCC 13 adds constexpr support which I believe is a major enhancement to C.  Basically, it allows constructs like
    static constexpr size_t  pool_size = 16 * 23 + 42 * 25;
    static unsigned char  pool_data[pool_size];
where the compiler computes and verifies pool_size at compile time.  If you use floating-point values, then the values are computed at compile time (using the floating point implementation on the host doing the compilation).  These are immutable, and the compiler can hard-code their value in the machine code, even if it reserves space for the object (which it doesn't need to, unless it is externally visible or someone takes its address using &).

Indeed, using

Code: [Select]

static constexpr size_t         hashtable_entries = 31*33 + 1;

static struct hashtable_entry  *hashtable_entry[hashtable_entries];

static inline struct hashtable_entry *hashtable_entry_for(size_t hash) {
    return hashtable_entry[hash % hashtable_entries];
}

static inline struct hashtable_entry **hashtable_entry_ref(size_t hash) {
    return hashtable_entry + (hash % hashtable_entries);
}
for a fixed-size hash table, whose size is computed at compile time, allows the compiler to optimize the hash % hashtable_entries into hash & 1023 (and GCC definitely does this for the above).

Thus far, we've had to use preprocessor macros for such sizes, and their values weren't checked for overflow and such; constexpr are.  So do think of them as more similar to preprocessor macros than to const variables or objects, for practical use cases.  If you have configuration preprocessor constants set at build time, this allows using them to calculate complex sizes and derivative values at compile time, and verify those fit their type.

Additionally, with GCC 9 and later you can use _Static_assert() (and static_assert() in GCC 13 and later, or when using <assert.h>) to verify requirements at compile time.  For example,
    static_assert(hashtable_entries > 0, "hashtable_entries is too small");
    static_assert(hashtable_entries < MAX_HASHTABLE_ENTRIES, "hashtable_entries is too large");
will be evaluated at compile time, and will not generate any runtime machine code at all.

These two additions can really help a careful embedded C developer to calculate and verify compile-time constants, leading to better and more thoroughly verified and compiler-understood code.  These alone would be enough for me personally to switch from C99 to C23 as the tools mature, but there are more goodies there.  To me, the era after C99 up till C17 was pretty much dark ages for C, but C23 looks very, very promising.

[peter-h]

Have they added 0b10101010 so you don't have to type 0xaa, which gets real fun for 32 bit values

[ataradov]

They've also added group separators, so you can type  0b10101010'11100010'00011100'01010101 and things are a bit more readable.

[peter-h]

In which GCC version was 0b10101010 possible?

I found this
https://gcc.gnu.org/onlinedocs/gcc/Binary-constants.html#Binary-constants

and sure enough GCC v11 supports it. I wonder how old this is?

[ataradov]

Binary constants are not a standard C, but GCC extension.  A proposal to add them to the standard was rejected somewhere around C99 for some stupid reason. Something like lack of precedent and insufficient utility. Which, I guess was true at that time, but you could have established the precedent.

But as an extension they existed for a very long time, from about that C99 time. They are widely used in avr-gcc ports.

[peter-h]

The main issue would seem to be if a part of the code was to be built to run on a PC for some reason. The MS VC++ doesn't support 0bxxxx (apparently). And someone working on my project did build the MbedTLS code as a win32 executable because it makes it much easier to track down TLS crypto suite [non] negotiation cases.

[ataradov]

Well, this is the downside of using non-standard features. Not much you can do here, if you want portable code, stick to the standard.

And you can still build on the PC using GCC, of course.

[peter-h]

OK that's news to me; I thought everybody was using just MSVC++ for windoze apps, and gone are the days of Borland, etc. I used to do command line apps with Borland. Did some GUI stuff with Delphi but GUI apps are not really relevant to this context.

[SiliconWizard]

OK that's news to me; I thought everybody was using just MSVC++ for windoze apps, and gone are the days of Borland, etc. I used to do command line apps with Borland. Did some GUI stuff with Delphi but GUI apps are not really relevant to this context.

Nope, I've used GCC extensively to build Windows apps in C (both CLI & GUI, but only sticking to the Windows API which is pretty much pure C).
For CLI stuff, absolutely no problem whatsoever. (For GUI, you'll probably have to stick to the Windows API, which may not be your cup of tea.) Your easiest path would probably be to use something like Code blocks: https://www.codeblocks.org/downloads/ , although there are Windows binaries for just the GCC toolchain that you can use without any IDE as well.

But if you were familiar with Delphi and don't mind using Object Pascal, you can consider having a look at Lazarus/Freepascal: https://www.lazarus-ide.org/
if anything, that'll be a fun experience and will bring back cool memories.

[westfw]

A proposal to add them [0b0010 numbers] to the standard was rejected somewhere around C99 for some stupid reason.

"Compiler nerds hate microcontroller/hardware nerds"  :-(

[SiliconWizard]

Well, to be fair, I don't consider binary literals particularly useful in practice either. Most often people want to use them to describe settings to some registers, and while it may be a bit more work upfront, it's much more readable to define such constants with bit fields.

Something like this:

Code: [Select]

typedef union
{
struct
{
uint32_t Count : 16;
uint32_t Padding: 15;
uint32_t Enable : 1;
};

uint32_t reg;

} MyReg_t;

const MyReg_t MyReg_Foo = (MyReg_t){ .Count = 10, .Enable = 1};

And yes yes, it does create the constant at compile time as expected (assigning it to a const global variable is just as an illustration, you can of course define the same as a macro and use it in your code without having to create global constants.)

But some people like to put a bunch of hard-coded values everywhere, and binary if possible as it's potentially even less readable. To each their own, of course! Just suggesting one approach.

[gmb42]

The main issue would seem to be if a part of the code was to be built to run on a PC for some reason. The MS VC++ doesn't support 0bxxxx (apparently). And someone working on my project did build the MbedTLS code as a win32 executable because it makes it much easier to track down TLS crypto suite [non] negotiation cases.

MSVC 2019 definitely does, I think it may have been added in MSVC 2015.

[zapta]

And yes yes, it does create the constant at compile time as expected (assigning it to a const global variable is just as an illustration, you can of course define the same as a macro and use it in your code without having to create global constants.)

Can these values be constexpr?

[Nominal Animal]

And yes yes, it does create the constant at compile time as expected (assigning it to a const global variable is just as an illustration, you can of course define the same as a macro and use it in your code without having to create global constants.)

Can these values be constexpr?

Yes, of course.  Just remember to tell GCC (or Clang) that you're using C23: -std=c23 with GCC 14 and later, and with Clang trunk (19 and later).

See this example of the above using GCC-14.2.0 -std=c23 -O2 -Wall -march=armv7e-m -mtune=cortex-m4 -mthumb.  The return values from wrapper functions returning different parts of MyReg_Foo compile to returning the corresponding fixed values.  You can also observe the effects of different reasonable optimization levels: -O2, -O1, -Os and -Og all generate the exact same code.

[westfw]

I don't consider binary literals particularly useful in practice either. Most often people want to use them to describe settings to some registers, and while it may be a bit more work upfront, it's much more readable to define such constants with bit fields [in a structure definition.]

I'm not in the habit of modifying or augmenting the vendor-provided register definitions.  In addition to being "more work", it makes code less readable to other people who are familiar with the vendor definitions ("oh, of course uart.txready is the same as (UCSR0A & UDRE0); isn't that obvious?")

[peter-h]

I've done mostly asm since the 1970s but I think, regardless of the language, the coding style should be done for brevity when examined years later by somebody else e.g.

Code: [Select]

DMA1_Stream3->CR = 0 << 25 // CHSEL: ch 0
|  0 << 23   // MBURST: memory burst - single transfer ??
|  0 << 21 // PBURST: peripheral burst - single transfer ??
|  3 << 16 // PL: highest priority
|  0 << 15 // PINCOS: no peripheral address increment offset
|  0 << 13 // MSIZE: memory data size: byte
|  0 << 11 // PSIZE: peripheral data size: byte
|  1 << 10 // MINC: memory address increment: 1
|  0 << 9 // PINC: peripheral address increment: 0
|  0 << 8 // CIRC: no circular mode
|  0 << 6 // DIR: peripheral to memory
|  0 << 5 // PFCTRL: DMA is flow controller
|  1 << 0; // EN: enable stream
especially when, like the above, there is no runtime cost.

But there are many cases where 0b10101010 etc are appropriate.

(tabs broken in above example, due to forum tab setting)

[SiliconWizard]

I gave the bit field example, which I think is handy and elegant, but some consider that it's not fully portable (although if you stick to GCC or Clang, it will always give you the expected result) and prefer bit masks.
I admit I also often use bit masks instead. But I do define, as much as possible, all bit masks I use with macros, to make things readable. I don't like "hard-coded" values.

There normally isn't any runtime cost with the approach I gave with bit fields though.

For MCUs, some vendors provide header files with bit field definitions (usual with Microchip, at least back when I was using them), others tend to prefer bit masks (like STM) - but more generally speaking, it appears to be more of a CMSIS "convention" (base vendor header files are usually part of their CMSIS "distribution"). But either way, you usually get one or another - it's now pretty rare to see vendors not providing that and leaving you only with register pointers and datasheets, so hard-coded values are rarely justifiable. But what I've witnessed is that quite a few developers don't actually know where to find those header files (especially if they are more used to HALs of some kind).

As an example, for the STM32F4, you'll find that in the STM32CubeF4-x.x.x/Drivers/CMSIS/Device/ST/STM32F4xx/Include directory. They define all register bits (or fields) with a bit position and a bit mask.

[peter-h]

They define all register bits (or fields) with a bit position and a bit mask.

Indeed; my example above could have been written entirely with the predefined bit positions. But if you comment properly, it is OK. The drawback of the names bit positions is that you have to keep right-clicking on Show Declaration to find what the hell that obscure name is And you still have to comment it properly.

That said, all the ST code uses the predefined names.

[Siwastaja]

I've done mostly asm since the 1970s but I think, regardless of the language, the coding style should be done for brevity when examined years later by somebody else e.g.

Code: [Select]

DMA1_Stream3->CR = 0 << 25 // CHSEL: ch 0
|  0 << 23   // MBURST: memory burst - single transfer ??
|  0 << 21 // PBURST: peripheral burst - single transfer ??
|  3 << 16 // PL: highest priority
|  0 << 15 // PINCOS: no peripheral address increment offset
|  0 << 13 // MSIZE: memory data size: byte
|  0 << 11 // PSIZE: peripheral data size: byte
|  1 << 10 // MINC: memory address increment: 1
|  0 << 9 // PINC: peripheral address increment: 0
|  0 << 8 // CIRC: no circular mode
|  0 << 6 // DIR: peripheral to memory
|  0 << 5 // PFCTRL: DMA is flow controller
|  1 << 0; // EN: enable stream
especially when, like the above, there is no runtime cost.

But there are many cases where 0b10101010 etc are appropriate.

(tabs broken in above example, due to forum tab setting)

I kinda like this example, and prefer similar style myself over the industry-standard solution of: 100 000 lines of bitmask #defines with horribly long names in an attempt to pseudo-namespace them, which still can be misused in wrong contexts (i.e., a bitmask register meant to be used with register A, used in register B) because of lack of namespacing, and which are slow to write, slow to read, and hard to remember, and due to the sheer amount, autocompletion of IDEs not being ideal either.

At some point I realized that whenever I work with peripheral registers, I must have the manual page open anyway because the names themselves are not descriptive enough for all the details, I can just as well do like (made-up example with imaginary UART peripheral:)

UART->CR = 57<<16 /*magic value as explained in manual*/ | 0b10<<5 /*bit pattern explained in the manual to enable certain prescaler */ | 1<<3 /*tx empty interrupt enable*/ | 1<<0 /*enable it*/;

This is very easy to cross reference with the manual and maintain. Say, for example, you want to change the prescaler. Instead of first looking at the manual what choices are available, and then looking how they are named in the 100000LoC header and how these names map into the datasheet values, you just directly write the number given in the manual.

But bitfields are of course most robust and most elegant (if you accept the potential portability issue). Well designed peripherals usually map quite neatly into bitfields and that is the best solution of course as you now got an actually functioning autocomplete from the IDE which only shows the correct context; you get actual namespacing as those fields are only part of that particular register, and so on.

In my opinion, manufacturers could just stop producing those huge #define mess files, I would not miss them at all. They could give unions with raw access + bitfields instead.

[dietert1]

One could write a simple tool to convert the vendor provided hardware header files into something more compact, using bitfields and enums. Kind of a precompiler. For somebody working at the hardware layer that could save quite some effort.
As far as possible i am using the vendor provided HAL with its initstructs instead.

[zapta]

Python's number separators are more intuitive IMO.

0b10101010_11100010_00011100_01010101

[newbrain]

Python's number separators are more intuitive IMO.

0b10101010_11100010_00011100_01010101

In C23, a single quote has been chosen to keep consistency with C++.
In its turn C++ could not use _ (underscore) as it would generate ambiguity with custom user defined literal suffixes.
They have to be named with a valid identifier, so it would be difficult to disambiguate things like 0xCACA_CACA.

n2626: https://open-std.org/JTC1/SC22/WG14/www/docs/n2626.pdf

[zapta]

Python's number separators are more intuitive IMO.

0b10101010_11100010_00011100_01010101

In C23, a single quote has been chosen to keep consistency with C++.
In its turn C++ could not use _ (underscore) as it would generate ambiguity with custom user defined literal suffixes.
They have to be named with a valid identifier, so it would be difficult to disambiguate things like 0xCACA_CACA.

n2626: https://open-std.org/JTC1/SC22/WG14/www/docs/n2626.pdf

Never heard before about user defined suffixes.  Not a bad idea.

[paulca]

I've done mostly asm since the 1970s but I think, regardless of the language, the coding style should be done for brevity when examined years later by somebody else e.g.

Code: [Select]

DMA1_Stream3->CR = 0 << 25 // CHSEL: ch 0
|  0 << 23   // MBURST: memory burst - single transfer ??
|  0 << 21 // PBURST: peripheral burst - single transfer ??
|  3 << 16 // PL: highest priority
|  0 << 15 // PINCOS: no peripheral address increment offset
|  0 << 13 // MSIZE: memory data size: byte
|  0 << 11 // PSIZE: peripheral data size: byte
|  1 << 10 // MINC: memory address increment: 1
|  0 << 9 // PINC: peripheral address increment: 0
|  0 << 8 // CIRC: no circular mode
|  0 << 6 // DIR: peripheral to memory
|  0 << 5 // PFCTRL: DMA is flow controller
|  1 << 0; // EN: enable stream
especially when, like the above, there is no runtime cost.

But there are many cases where 0b10101010 etc are appropriate.

(tabs broken in above example, due to forum tab setting)

My code review:

* Apology comments can be replaced with definitions having proper names.
* "Magic numbers" ^^ see above.
* Tabs are usually deprecated in favour of grouped spacing, the former causes too many issues with different editors and the later is easy for any to process.  As you found out.
* Expand acronyms.  CR?
* A link to source documentation could be handy.

None of this has runtime impact.

As for justification and impact.

Code is for people.  Not machines.  Writing it as such will speed future development.  It not only matters the compiler understand the code, but the developer who joins the project next Thursday does too.

Impact for non-adherence.  Uncaught bugs, slow onboarding, poor quality, delayed work units.

[peter-h]

What is an "apology comment" and "magic numbers"?

Yes I also do not like "CR" but if one gets into the "DMA context" (which is what the above is about) then CR is the config register, and looking it up in the RM makes it obvious.

Links to source doc break pretty fast. But I often put links to EEVBLOG or ST forum threads into my source code

Re tabs, frankly, I don't care if the EEVBLOG code listings look funny. At least I post them, working ones, while 99% of people on tech social media just leach