The use of the "const" qualifier - GCC

[peter-h]

I have a weird issue with

static const char fred = "abcd";

It causes some code to compile incorrectly. I am suspecting a linkfile issue. This is despite the project already containing lots of "static const" items - but not in a particular module which has its own linkfile section.

The const means it start in flash and does not get copied to ram.

Regarding the typically used section names, the above goes into "rodata". If the "const" was missing, it would go into "data". So rodata is the same category as text, except that rodata should never be executable code.

In GCC before v10, BSS and COMMON were used for the same stuff (e.g. int x;) but that doesnt apply here.

Is the above right?

Are there any common gotchas with the use of "const"?

[RoGeorge]

I remember const as a qualifier that will make the compiler to error if you try to reassign it.  Other than that, const is just like any variable.

I don't think const will guarantee to put the variable in flash and to not copy it in RAM.  In fact I expect a const variable to be copied to RAM just like a normal variable, but I'm no C expert.

[madires]

Yep, 'const' simply tells the compiler that the variables's value is constant and can't be changed. However, there can be additional options to specify where the value should be stored. For avr-gcc:

Code: [Select]

/* stored in FLASH */
const char fred[] PROGMEM = "abcd";

/* stored in EEPROM */
const char fred2[] EEMEM = "abcd";


[langwadt]

Avr needs to do more, because it need special instructions to access progmem

[Siwastaja]

I don't think const will guarantee to put the variable in flash and to not copy it in RAM.  In fact I expect a const variable to be copied to RAM just like a normal variable, but I'm no C expert.

Yeah - to be clear, C itself says nothing about this, it's up to implementation. But it's clear from peter-h's description that the linker scripts he uses are similar to what most people use with Cortex-M microcontrollers - i.e., const qualified objects being put by compiler to .rodata, which is then put by linker script into flash and not copied to RAM during startup, saving RAM with the expense of (usually) slightly slower access. But you are free to write your own linker scripts for a different behavior.

[ejeffrey]

I have a weird issue with

static const char fred = "abcd";

Do you mean static const char fred[5] = "abcd";

Are there any common gotchas with the use of "const"?

Print out the value of a pointer to fred and make sure it's in the right memory area, and not being unintentionally copied to RAM.

[peter-h]

Sorry...

 static const char fred[] = "abcd";

That code is working fine but it seriously breaks unrelated stuff, and I strongly suspect it is buggering up init values where these are nonzero (zero ones should go into BSS which is zeroed by definition). Like this

[golden_labels]

peter-h didn’t describe, what is the issue he experiences, so for now I’m skipping his question entirely.

I’m also making an assumption this is C, though that was not stated either.

Yep, 'const' simply tells the compiler that the variables's value is constant and can't be changed.

It says it can’t be written in the context in which the compiler sees the variable as const. It doesn’t mean it can’t change.

However, static const effectively tells the compiler that it has a complete view of the variable. Which is the case in here. Of course that doesn’t indicate, where the variable goes or if it’s allocated at all, as you have noted.

[T3sl4co1l]

peter-h didn’t describe, what is the issue he experiences, so for now I’m skipping his question entirely.

Related to ongoing thread: https://www.eevblog.com/forum/programming/weird-strcat()-behaviour/

[golden_labels]

… which, the last time I checked, lacked minimal code reproducing the issue or any point to start from. This is exactly, why I mentioned peter-h failing to describe the problem. This is not the first time he expects help, but gives us nothing to work with.

Inflating the thread with random pieces of information about C, in hope that maybe OP fetches something useful from that, is not productive.

[peter-h]

Thanks for that help

If I could post a code snippet which you might have time to read, say 10-20 lines, then I would have solved the problem quicker than typing it up.

In my case, changing a declaration to const changed RAM addresses for all subsequent variables, so while "const" itself should not do anything bad (and is obviously better for r/o stuff which for whatever reason you don't #define instead) it can expose a problem.

In my case it seems to have been a dodgy linkfile syntax.

But when I started this thread I was looking for any gotchas with "const" from the much more experienced people here. I don't go on forums just to waste time. And - unlike some 99% - if I solve something, I post that too!

[coppice]

The const means it start in flash and does not get copied to ram.

No it doesn't. The const qualifier just means the compiler won't assign to the value. It doesn't mean it will be in flash, and it doesn't mean it won't be copied into RAM as the program starts. Lots of things have no flash or other forms of ROM, but const still works. Lots of things run code slowly from flash, so some things are configured to copy from flash to RAM at startup, and are used from RAM from them on. Some things have partitioned memory which demands things get copied from a starting position to a working position at startup.

Now, its pretty common with modern flash MCUs that a C compiler will do what you said, but its neither a requirement or universal.

[peter-h]

Just to conclude this thread for anyone seeing it in the future, this turned out to be a really obscure linkfile issue, with DATA, which tooks a week or two of work to narrow down
https://www.eevblog.com/forum/programming/a-specific-q-on-gcc-linker-script-syntax/
The use of "const" merely moved some stuff around.

[DiTBho]

Lots of things run code slowly from flash

yup, it is much more common to compile an image designed to run entirely in ram, so all the addresses of all the functions and variables belong to the ram range, however the final binary image is then inserted into flash.

What happens at startup?
In flash there is a "loader" that copies the entire image into ram, then jumps to crt0, which in turn initializes some parts, and then jumps to main.

However, when ram is scarce ... someone thinks of leaving some parts, such as LUTs, or in any case "immutable" data structures in the "constant pool", in flash.
Things get complicated, especially if the flash is not accessible to uint8_t but only to uint16_t or worse to uint32_t.

When I can, I try to propose the simplest possible scenario.

[peter-h]

DiTBho posted that he's blacklisted me so he probably won't see this

copies the entire image into ram

One of the chinese copies of the 32F407 does exactly that - there's a thread on it here. It thus runs a bit faster, but probably not much. My own tests on loop timings (delay loops done for special hardware timing, in asm to prevent optimisation) actually run slower in RAM on the 32F417 than in FLASH, presumably because the CPU cache makes so much of a speedup. I found this when writing a boot loader, which runs in RAM.

[coppice]

DiTBho posted that he's blacklisted me so he probably won't see this

copies the entire image into ram

One of the chinese copies of the 32F407 does exactly that - there's a thread on it here. It thus runs a bit faster, but probably not much. My own tests on loop timings (delay loops done for special hardware timing, in asm to prevent optimisation) actually run slower in RAM on the 32F417 than in FLASH, presumably because the CPU cache makes so much of a speedup. I found this when writing a boot loader, which runs in RAM.

That is normal cache dynamics. If the device is executing little loops while running from fast main memory you see no benefit over slow main memory. Make the working set exceed the size of the cache and suddenly you see a large difference.

[DiTBho]

DiTBho posted that he's blacklisted me so he probably won't see this

I do NOT read his posts, but if someone quotes them, I see that he is there behaving like a petulant child.
Yes, he is on the ignore list, and he will remain there, until he learns to respect others, the time dedicated to him, and open source.

edit:
I changed the subject of the sentence, so it's even clearer, in case another quote should be missing, whom I'm referring to.

[coppice]

DiTBho posted that he's blacklisted me so he probably won't see this

I do NOT read your posts, but if someone quotes them, I see that you are there behaving like a petulant child.
Yes, you are on the ignore list, and you will remain there, until you learn to respect others, the time dedicated to you, and open source.

If you are going to insult people try to insult the right one, you dumb moron.

[DiTBho]

If you are going to insult people try to insult the right one, you dumb moron.

"dumb moron" is an insult!
I am not here to insult, so hey? respect!
I am writing form the smartphone, the keyboard is not good, so I missed a quote!

[Simon]

If you are going to insult people try to insult the right one, you dumb moron.

"dumb moron" is an insult!
I am not here to insult, so hey? respect!
I am writing form the smartphone, the keyboard is not good, so I missed a quote!

So to be clear you made a mistake. Right, now can we all be friends again?