Is ST Cube IDE a piece of buggy crap?

[Siwastaja]

I love seeing threads full of high-horse armchair experts like this one.

... Everyone seemed to have such high expertise, and such a high opinion of what the standard skill level should be, that I couldn't help but feel grossly inferior and inadequate.

I have felt the same, but I didn't care, I kept improving myself despite this. Get better, that's the way to go. You don't need to become world class expert, but you need to get past the beginner state.

I despise the current trend of being proud of mediocrity and being proud about being stuck at beginner-level solutions and calling that professional just because you get paid for it.

You are right about the quality of many who appear "experts". It's actually quite easy to surpass most in this field. Now the problem is to make others see your excellency. The solution: don't care about it. Do the right thing.

What I at least try to do is not only brag with my excellent super skills (this is tongue in cheek because I know many on this forum for example do better), but try to teach others, see the "intermittent failures" thread going on where I elaborate on "instrumentation" which I talk about as an alternative to "just single-step in debugger until it works" by "professionals".

[Siwastaja]

I've found that the best people in the field also do it as a hobby--in fact, that's a very good indicator of how competent someone is, so I always ask that in an interview.

This is also why "armchair experts" on the internet usually are right and have more comprehensive understanding, than "real experts".

Of course, within those "real experts", there are some truly highly experienced individuals who also do not struggle with basics (like the C standard) like most professionals do.

[Sal Ammoniac]

I've found that the best people in the field also do it as a hobby--in fact, that's a very good indicator of how competent someone is, so I always ask that in an interview.

This is also why "armchair experts" on the internet usually are right and have more comprehensive understanding, than "real experts".

Of course, within those "real experts", there are some truly highly experienced individuals who also do not struggle with basics (like the C standard) like most professionals do.

I think you might have misunderstood what I was saying. I wasn’t saying that hobbyists (someone with no formal training) make the best embedded engineers, I was saying that what you call “real experts” also happen to do personal work at home unrelated to their jobs. These people do have training in their field—they just don’t leave that training behind when they walk out the office door. I find that this correlates well with someone’s professional competence (although that’s not to say that someone who doesn’t do it as a hobby can’t be a good engineer).

[Siwastaja]

It's the path, they started it as a hobby, it became a profession, but they never lose the ambition, so they participate in discussions about it on their free time, or do hobby projects, too.

[Kjelt]

When I started in the 90s the SW careerpath was as follows:
Start: Junior SW eng
3-5yrs: Medior SwEng
3-5 yrs: Senior SwEng

3-5yrs: Junior SwArch
3-5yrs: Medior SwArch
3-5 yrs: Senior SwArch

3-5 yrs: System Architect

So our system architects back then had at least 20yrs domain knowledge and hands down (in the mud) experience with one or preferably two workareas (mechanics, thermo, EE, SW, etc)

Nowadays a guy from India, 27 yrs old graduated five years ago from some university in Bangalore introduces himself: "Hi I am the Sr System Architect of the new product" 

[peter-h]

I am deeply suspicious of anyone in electronics calling themselves an "architect", "artisan" etc

But the business plays on this, and uses these terms to massage the inflated egos. This one is one of the best laughs https://laravel.com/

One thing which seems to be more or less true is that software guys hate software after about 40-50. It's a pity because they have loads of experience. They grow to hate the business because every few months there is a new "paradigm" or "framework", which one needs like a hole in the head.

Fortunately, in embedded work, and unless you are doing internet connectivity, you can ignore most of that IF you own the company.

[nctnico]

One thing which seems to be more or less true is that software guys hate software after about 40-50. It's a pity because they have loads of experience. They grow to hate the business because every few months there is a new "paradigm" or "framework", which one needs like a hole in the head.

If you look closely enough most of these terms are bogus or new names for things that have existed long before. Take the term 'full stack developer' for example. That used to be called 'all round software developer'. Or grazy terms like CEO or something. When I grow my business bigger, I will be the general oversight director!

But it sucks if you want to get a project but get all these newfangled, meaningless terms thrown at you. I'm too old for that doo-doo. I write software, not namecards.

[peter-h]

Something else has just popped up between windows and linux installs of Cube.

There are various compiler etc paths where you have to edit a \ to a / or vice versa.

Of course this is no big deal but it introduces interesting challenges on multiple people working on the same project. Basically, afaict, they can't unless only say the .c and .h files are the "common" stuff and everything else is local.

[nctnico]

Typically the / is converted by Eclipse to \ when it runs on Windows. / is more or less the defacto standard for paths.

[newbrain]

Typically the / is converted by Eclipse to \ when it runs on Windows. / is more or less the defacto standard for paths.

Also because Windows internally supports / as a path separator since (gasp) MS DOS 3.11 (not sure if already since 2.1).

Code: [Select]

C:\Users\newbrain\Git> cd ../STM32Cube/Repository/STM32Cube_FW_F0_V1.11.0
C:\Users\newbrain\STM32Cube\Repository\STM32Cube_FW_F0_V1.11.0>

[nctnico]

Typically the / is converted by Eclipse to \ when it runs on Windows. / is more or less the defacto standard for paths.

Also because Windows internally supports / as a path separator since (gasp) MS DOS 3.11 (not sure if already since 2.1).

Code: [Select]

C:\Users\newbrain\Git> cd ../STM32Cube/Repository/STM32Cube_FW_F0_V1.11.0
C:\Users\newbrain\STM32Cube\Repository\STM32Cube_FW_F0_V1.11.0>

I've always been under the impression that support for / as path seperator has been added (as in being fully functional) later on (starting from Windows 7). On Windows 7 I can do: cd c:/windows/system32. On Windows XP this doesn't work; the slash after c: needs to be the backslash ( \ ). When I look at what Eclipse is feeding into the compiler (using Windows XP) is that the path to the source file contains C:/  but it works nevertheless. So appearantly it is not Eclipse doing the conversion, but the compiler itself.

[ataradov]

Support for both types of separators was added to MS-DOS v2 along with the concept of directories. It should work on WinXP for sure. But different non-system utilities may have issues parsing that stuff, same with spaces in the names.

The reason for the whole mess is that they already used '/' for command line switches (like '/h' for help). But once directories became a thing, they wanted it to look like Unix, and even tried to switch people from using '/' for command line switches. This was done on a request from OEMs (I assume primarily IBM).  You could set SWITCHAR variable in config.sys to anything you like (the expectation was that it would be set to '-'), and all system commands would accept that. But by MS-DOS v3 they gave up and removed that option.

[SiliconWizard]

You could try opening a file on XP with / as a path separator, using fopen() or even CreateFile() from the Windows API, to check this.

I suspect the problem you mention here using 'cd' in the cmd prompt is not with Windows XP not supporting / as a path separator per se, but the 'cmd' shell itself and its internal parser.
Likewise, a number of Windows applications still do not support / as a path separator. Not because of Windows - just because the app itself implements path handling functions that do not support it.

[peter-h]

Finally, 1.9.0 has come out. ST have changed the compiler version and it doesn't compile anymore

Lots of "multiple definition of" with declaring a variable as a structure.

So, off looking at whether some config options have been changed.

EDIT: no obvious changes. It doesn't like

Code: [Select]

typedef struct __SPI_HandleTypeDef
{
  SPI_TypeDef                *Instance;      /*!< SPI registers base address               */
  SPI_InitTypeDef            Init;           /*!< SPI communication parameters             */
  uint8_t                    *pTxBuffPtr;    /*!< Pointer to SPI Tx transfer Buffer        */
  uint16_t                   TxXferSize;     /*!< SPI Tx Transfer size                     */
  __IO uint16_t              TxXferCount;    /*!< SPI Tx Transfer Counter                  */
  uint8_t                    *pRxBuffPtr;    /*!< Pointer to SPI Rx transfer Buffer        */
  uint16_t                   RxXferSize;     /*!< SPI Rx Transfer size                     */
  __IO uint16_t              RxXferCount;    /*!< SPI Rx Transfer Counter                  */
  void (*RxISR)(struct __SPI_HandleTypeDef *hspi);   /*!< function pointer on Rx ISR       */
  void (*TxISR)(struct __SPI_HandleTypeDef *hspi);   /*!< function pointer on Tx ISR       */
  DMA_HandleTypeDef          *hdmatx;        /*!< SPI Tx DMA Handle parameters             */
  DMA_HandleTypeDef          *hdmarx;        /*!< SPI Rx DMA Handle parameters             */
  HAL_LockTypeDef            Lock;           /*!< Locking object                           */
  __IO HAL_SPI_StateTypeDef  State;          /*!< SPI communication state                  */
  __IO uint32_t              ErrorCode;      /*!< SPI Error code                           */

} SPI_HandleTypeDef;

SPI_HandleTypeDef hspi2;


The last line it complains about:

multiple definition of `hspi2'; .... first defined here

and referencing the same line!

[ataradov]

Do you by any chance include the same file multiple times and declare  the variable in the include? Although it would have been broken with the old compiler too.

But again, this is 100% you doing something wrong. Hard to tell what without more details.

[peter-h]

It seems to be here
https://gcc.gnu.org/gcc-10/porting_to.html

A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. If tentative definitions of particular variables need to be placed in a common block, __attribute__((__common__)) can be used to force that behavior even in code compiled without -fcommon. As a workaround, legacy C code where all tentative definitions should be placed into a common block can be compiled with -fcommon.

Yes doing literally what you suggest would break previous compiler.

I am working on a "test copy" of the project and fixed all the errors by using "extern" in front of stuff like this

extern TIM_HandleTypeDef  htim6;

but I don't understand why. Right before that is

#include "stm32f4xx_hal_tim.h"

and in there is TIM_HandleTypeDef defined. So it isn't "external" in any way i.e. no need to resolve it with the linker. But I am no C expert. Now it compiles with no errors. And it runs. Somewhat bigger: 364.13 to 365.2kbytes.

The old bug that you have to build twice to get the Build Analyser to show is still there

[DavidAlfa]

The typedef should be on the header file, but not the variable declaration... That should be declared somewhere else.
Otherwise, all files including that header will re-declare the variable, causing that error.

If global, then declare an extern variable wherever it's used, or try doing so in the header file.

Ex.: main.c

Code: [Select]

SPI_HandleTypeDef hspi2;
Other files or ex. spi.h header (Where SPI_HandleTypeDef is declared):

Code: [Select]

extern SPI_HandleTypeDef hspi2;

[peter-h]

The typedef should be on the header file, but not the variable declaration

You are right, of course...

Interesting ST have bundled in v10 from October 2021, which is quite recent. How solid is this?

I can continue work on Cube 1.8 and have just the one machine with Cube 1.9, for a while.

[ataradov]

Don't worry about solidity of GCC. It is solid.

[newbrain]

[...]
So it isn't "external" in any way i.e. no need to resolve it with the linker.
[...]
The old bug that you have to build twice to get the Build Analyser to show is still there

Just to make it clear: "extern" does not refer to the type.
Types are either intrinsically known to the compiler (e.g. int, char etc.) or defined in the current "translation unit" (simplifying: source file, with the includes included).
In this case, the type is defined in the HAL include file.
The linker does not really know about types*.

"extern" refers instead to the actual storage of the object: it tells the compiler (and the linker!) that the definition of the object is in another translation unit, so it should not allocate space for it "here" (simplification).

*Linkers can be made aware of the types by using "link time optimization" options during compiling and linking, but are otherwise mostly agnostic (which can lead to spectacular errors, as addressed by this SEI-CERT rule)

Oh, that GUI problem also happens with MCUxpresso. Especially with dark themes. Crappy, overbloated, pointlessly complex IDE.

[DavidAlfa]

Never got link time optimization to work. Saved *a lot* of space, but the stm32 would always boot completely dead.
Didn't lose more time fighting it as I managed to overcome the low space issue by other means.

[peter-h]

Why would link time opt save space?

My simple-mind understanding of "extern" is that the compiler just needs to allocate that space, and the linker will resolve it at link time. It suppresses the "undefined symbol" warning. It probably also prevents the variable from being optimised-out if not used for any "final" purpose.

[ataradov]

LTO is a completely unrelated thing. And on big projects it saves 15-30% flash space. It is essentially a recompilation of everything as a single unit at a link stage.

It is very easy to get working on plain GCC, but if your code relied on a lot of undefined behaviour and stuff like this, then it all might break, and you just have to work through it.

[Siwastaja]

My simple-mind understanding of "extern" is that the compiler just needs to allocate that space, and the linker will resolve it at link time. It suppresses the "undefined symbol" warning. It probably also prevents the variable from being optimised-out if not used for any "final" purpose.

I'm not saying this is wrong, but... how weird way of thinking.

But I understand the confusion, there are many poor choices for reserved words in C; for example "extern", "static", etc. "extern" gives you an idea this is something about something being external, but this is not the case at all. The keyword controls the difference between declaration and definition.

The "extern" keyword just means you are declaring a variable or function: telling the compiler the important meta information such as type and type qualifiers; and of course, the fact that it exists. Memory is never reserved for it.

When you leave out "extern" keyword, then whatever you write becomes both a declaration and definition. Of course if you already have a declaration earlier, the types and qualifiers must exactly match.

It should be really this simple. It's made a bit confusing by the fact that
type func();  <-- note the ;
automatically works like there was extern written here, even if you omit it - i.e., declaration only. The idea was probably to save some typing time; compiler can figure out from the lack of function body that this can only be a declaration.

Another confusing thing are the "tentative definitions". Better just forget this part, and follow the logical and least confusing way:
* Explicit, clear declarations in header files, which are included wherever needed. This means extern keyword on all variables. It's matter of taste if you use extern on function declarations or leave it out. Doesn't affect the result.
* Exactly one definition in exactly one compilation unit, in a .c file.

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.)

TLDR:

module1.h

Code: [Select]

#pragma once

extern int public_int;
extern void public_func(); // extern can be omitted here

module1.c

Code: [Select]

#include "module1.h"

int public_int;
static int private_int;

void public_func() {
    ...
}

static void private_func() {
    ...
}


[Bassman59]

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.