Is ST Cube IDE a piece of buggy crap?

[SiliconWizard]

Of course, if only a single .c file uses a function or a variable, and you know others never need it, then you make that function or variable static (another confusing keyword; really controls if the thing is exposed to the outside world or not), and do not add a declaration in .h. Most of the functions and variables usually are this way (which also makes one think, the static works the wrong way; the default behavior should be an "internal" function or variable, with a PUBLIC keyword or similar. But oh well, C is like this. At least the functionality is there! You just need to know how to use it.)

I always get a chuckle out of the absurdity of having to declare a variable as volatile static.

I agree with the simple point of seeing static global symbols (variables, functions) as "private" and the others as "public".
One may question the choice in C to make things "public" by default, the other way around would probably have made more sense. But we are not going to redefine a 50-year old language - use another if you don't like it.

As to volatile static, I don't see what the chuckle is all about.
A typical example would be a static global variable that is modified in an ISR and used in other functions. Very common use. If not qualified volatile, access to said variable may get optimized out, we know the deal (same for multi-threaded programming). Making it static makes sense if it's not going to be used outside of the compilation unit it's defined in. That's something I've actually done quite often.

I would prefer any global object to be static by default as in my first paragraph, but it's not the case. So.

[peter-h]

Every day is a school day

To me, "static" for a variable = located in main RAM (also means DMA can access it, in my 32F4 project, although of course one can have statics in the CCM too). For a function, it is private to the .c file (but still needs a prototype if called by code before it).

Globals have to be static (in main RAM or in CCM) although I don't use that qualifier; I just declare them before / outside of any function. Not actually true; you could have a variable declared on the stack in main() and so long as main() never terminates, these will be always accessible.

[westfw]

Globals have to be static

Global variables declared "static" behave like static functions.  They "must" have permanence, but their scope is limited to the source file that they are defined in.

Code: [Select]

> cat bar.c
#include <stdio.h>
extern void bar1(int);
static int x;
int main() {
  printf("%d", x);
  bar1(x);
}

> cat bar1.c
#include <stdio.h>
extern int x;
void bar1(int a) {
  printf("%d, %d\n", x, a);
}

> gcc bar.c bar1.c
Undefined symbols for architecture x86_64:
  "_x", referenced from:
      _bar1 in bar1-4f0ab8.o
ld: symbol(s) not found for architecture x86_64It is perhaps unfortunate from some academic purity PoV that C uses "static" to indicate both locality and permanence, and that global variables default to "permanent but not local" and function variables default to "local but not permanent", but that's usually the way you want things to be.

[Siwastaja]

As to volatile static, I don't see what the chuckle is all about.

You'd get the chuckle better if you didn't know what the keywords mean in C. Look at dictionary definitions!

Yes, the keywords chosen are absolutely ridiculous. Like if you have a red hammer, you describe it in C as "blue nail". Then you just learn, learn and learn until you know that in C, blue means red and nail means hammer.

This mess is saved by the the small number of such ridiculous keywords choices. You can learn a few stupid details in matter of weeks, if you choose to do so, and have proper information available.

C could be made (seemingly) much better by maybe 5-10 small changes in the language (including making things "private" by default as you say), but on the other hand, the changes would be small enough so that we can also totally live with as it is now.

[Siwastaja]

To me, "static" for a variable = located in main RAM

No!

Note that static has two different meanings!

Outside function body, static just controls whether the thing (function or variable) is public or private. Either way, static or not, the variable ends up in .data or .bss! The difference is whether the compiler exposes the symbol for the linker. If it's static, it's truly private; different compilation units can have a variable under the same name, and they end up being totally different. "Global" is not a descriptive word for such variable; it's "global" only for the compilation unit, but not for the project. Now, non-static is global for the project.

Inside function body, static makes the variable act like it was defined outside of the function, even though the scope of access is still within that function; i.e., it will retain the values (and be initialized like globals).

[newbrain]

LTO is a completely unrelated thing.

It is for effects on the compiled code, but making the intermediate representation available to the linker (instead of a fully compiled object) enables the linker (which as Siwastaja said is now really compiling the whole thing) to catch conflicting type errors.

Code: [Select]

C:\Users\newbrain> get-content a.c
extern int *a;

int main(void)
{
    return a[0];
}
C:\Users\newbrain> get-content b.c
int a[] = { 1, 2, 3, 4 };
C:\Users\newbrain> arm-none-eabi-gcc -c b.c -o b.o -flto; arm-none-eabi-gcc -c a.c -o a.o -flto
C:\Users\newbrain> arm-none-eabi-gcc -flto a.o b.o -o ab
a.c:1:13: warning: type of 'a' does not match original declaration [-Wlto-type-mismatch]
    1 | extern int *a;
      |             ^
b.c:1:5: note: 'a' was previously declared here
    1 | int a[] = { 1, 2, 3, 4 };
      |     ^
b.c:1:5: note: code may be misoptimized unless '-fno-strict-aliasing' is used
C:\Users\newbrain> arm-none-eabi-gcc -c b.c -o b.o ; arm-none-eabi-gcc -c a.c -o a.o
C:\Users\newbrain> arm-none-eabi-gcc a.o b.o -o ab
C:\Users\newbrain>

[peter-h]

Siwastaja - I knew that bit but you put it much better than I could

[SiliconWizard]

As to volatile static, I don't see what the chuckle is all about.

You'd get the chuckle better if you didn't know what the keywords mean in C. Look at dictionary definitions!

Yes, the keywords chosen are absolutely ridiculous. Like if you have a red hammer, you describe it in C as "blue nail". Then you just learn, learn and learn until you know that in C, blue means red and nail means hammer.

That's cute, but kind of pointless. =)
If you insist on programming languages having the usual semantics of natural languages, you're in for a lot of chuckling. Conversely, insisting on doing just that when designing a programming language *has* been attempted numerous times in the past and often led to even more ridiculous stuff.

That said, the "static" keyword is poorly choosen in C, but it's probably a matter of legacy. The keyword may have not had the full definition in C it has these days when it was first introduced (I do not know enough of "original" C to remember that clearly.) For instance, it has a pretty different meaning when used for qualifying local variables inside a function, and used outside on global objects. The natural semantics of "static" makes more sense for the former.

[dietert1]

It even gets better with "const" in C++. Reuse of keywords appears to be what experts consider "C style". Like physicists say about quantum mechanics: You don't understand it, but you get used to it.
Anyways there is enough open source available nowadays (e.g. the STM32 Cube libraries). So you just need to change your attitude and try to learn something from there.

Regards, Dieter

[DavidAlfa]

Static is one of the simplest aspects of C language, why all this?

You could pass a pointer to a static, and use the pointer inside an interrupt.
Does it make sense? I don't know... But the compiler should be aware of that condition by declaring it as volatile, right?

Static is very useful sometimes.
Declared as static global? Like private in other languages, can only be accesed by functions in that source file.
Inside a function? Same as local variables, but becomes non-volatile, always keeping its value. Very handy for machine states, timers...

[Bassman59]

As to volatile static, I don't see what the chuckle is all about.

You'd get the chuckle better if you didn't know what the keywords mean in C. Look at dictionary definitions!\

Dang, I wish I didn't have to explain what I mean, but ...

I know what the keywords mean in C.

I also know what the words mean in English.

"static" means "doesn't change."

"volatile" means "subject to change without notice."

The two words are antonyms.

Hence, the chuckle.

[SiliconWizard]

It even gets better with "const" in C++. Reuse of keywords appears to be what experts consider "C style".

The reuse of keywords when adding features to an existing language is most often a necessity.
Adding more keywords is problematic and always has to be carefully weighed in. It's bound to increase the probability of getting identifier clash on existing code, for instance.

Now some languages try to circumvent that by adding new "operators" when adding features, instead of keywords. While keywords can clash with identifiers, new operators (usually, but they have to be choosen carefully) can't. Up to you to decide if putting a lot of !, ?, @, @! or whatever looks less confusing than reusing keywords with a slightly different semantic.

[DavidAlfa]

Correct me if I'm wrong, it's const which is for "doesn't change (ever)", static is like "local variable but keeps the value".
Doesn't define anything about its volatibility.

What about changing the thread title to "Learning to use Cube IDE and stm32”? 

[Siwastaja]

Correct me if I'm wrong, it's const which is for "doesn't change (ever)", static is like "local variable but keeps the value".

Read above. That is only one use for static; the one which is likely the more "original" one as it makes sense in the human language meaning.

Static keyword is also reused for a completely different purpose, to control the internalness/externalness of the variable or function.

Reuse of same keywords for totally different purposes is highly confusing, but it's understandable indeed because you can't add keywords to a language as they would clash with existing programs (someone might have "int public;" in their program, so can't add keyword public).

[peter-h]

They still haven't fixed the phantom breakpoints



It's been suspected that setting and unsetting a bkp at where the phantom one is suspected to be, removes it. But just now it didn't work. I had to select-all everything in this window



and delete them.

This issue has been there for years.

[ataradov]

You mean that circle with a "-" in it? Are those actually breakpoints? This looks like code folding feature. Can you click on this minus and it will minimize the body of the function into a single line?

And do they really show up in the breakpoint list?

[DavidAlfa]

Yeah, that happens sometimes, but it's not so bad.
Just use the breakpoint window as you're doing.

[peter-h]

Are those actually breakpoints? This looks like code folding feature

That is, yes. Breakpoints show like this

And do they really show up in the breakpoint list?

Affirm. AFAICT they don't show up anywhere at all. They don't even show up as disabled (unchecked) breakpoints in the breakpoint window.

It is as if they were in the bpt window but in white text So when you do control-a to select all, then Delete, they go.

Cube did have issues with white text in the console window, but it was machine-dependent (was seen on win7-64 and win10, but running Cube over RDP (remote desktop) unsurprisingly never showed that. I haven't see that problem since around 1.7 so maybe they fixed it.

Oh and BTW guess how big an "int" is in the standard 32F417 ST Cube library code?

[Sal Ammoniac]

Another option, if you’re using a J-Link is Segger’s Ozone debugger. I’ve found it to be much more robust and bug free than the debugger built into tools like CubeIDE.

If you’re using a Nucleo or Discovery board, Segger has firmware that converts the built-in ST-Link on the board to a J-Link.

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

[peter-h]

I bought a Segger unit to try out. It worked ok but I could not see any difference. Maybe there is a difference in some situations; perhaps stuff like debugging low power modes?

I am now using STLINK V3 ISOL which is isolated and thus should make it a bit harder to blow up the target. It runs at a slower speed than STLINK V3 (there is a thread on it here somewhere) but in practice one can't tell the difference.

[Sal Ammoniac]

The biggest advantage of using a J-Link, IMO, is the ability to use Ozone.

[peter-h]

I had a play with it and thought it was something running under MS-DOS A fairly typical bit of software written in the 1980s by a small company; in this case an old German one.

IMHO the debugger integration in Cube is good; they just need to improve some areas and above all make it more reliable. Frequently, Cube "loses contact" with the debugger. I don't know whether this is a timing issue or what.

[Sal Ammoniac]

I had a play with it and thought it was something running under MS-DOS A fairly typical bit of software written in the 1980s by a small company; in this case an old German one.

IMHO the debugger integration in Cube is good; they just need to improve some areas and above all make it more reliable. Frequently, Cube "loses contact" with the debugger. I don't know whether this is a timing issue or what.

Sure, Ozone looks dated on the surface, but don’t judge a book by its cover.

As Han Solo said, “She may not look like much, but she's got it where it counts, kid.”

[peter-h]

OK but what does that actually mean in terms of specifics?

In debugging, you want breakpoints to work, and you want to examine variables when you get one. You then want to step through the code, basically.

The more pricey Segger boxes have some fancy stuff like breakpoints in FLASH (they dynamically reprogram the CPU FLASH) which gets over the 5-breakpoint hardware limit in the CPU. But this is rarely needed. And the pricey ones are really pricey.

[Sal Ammoniac]

OK but what does that actually mean in terms of specifics?

It means the basics (breakpoints, watchpoints, single-stepping) work and work very reliably. I’ve never had Ozone “lose contact” with the debugger. Ozone talks directly to a J-Link — there’s no GDB involved — and since Segger knows the internals of a J-Link intimately, I consider Ozone to be more tightly integrated with the target than most other debugger/debug pod combinations.

The internals are documented really well. I wrote an RTOS-aware extension for a custom RTOS in 30 minutes by following the details in the user manual.

There are other nice features as well. Download the user manual and give it a read.