2024-02-21 08:16 AM
As title suggest.
If I do
int my_var;
my_var = 0b01;
my_var stays 0
Instead with
int my_var;
my_var = 0x01;
Everything works
STM32CubeIDE
Version: 1.14.1
Build: 20064_20240111_1413 (UTC)
2024-02-21 08:47 AM - edited 2024-02-21 08:53 AM
Do you get any warnings/errors ?
Binary literals aren't part of the C standard - only available by extension - so are you sure it's valid for the language spec you're using?
CORRECTION
Binary literals were introduced in C23:
So they are very new!
2024-02-21 08:54 AM
Hello @nico23
I've personally tested using the STM32WB55-NUCLEO and the STM32CubeIDE V1.14.1 and this simple code:
/* USER CODE BEGIN 1 */
int my_var;
__NOP();
my_var = 0b01;
/* USER CODE END 1 */
And that works fine (even without the __NOP() ) and set the my_var to 1 as you can see:
Could you give more details about your issue.
Best Regards.
STTwo-32
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-02-21 08:59 AM
And if you add volatile to your declaration :
volatile int my_var;?
2024-02-21 09:02 AM
That might not help prevent it from being optimized.
Memory inspection only works if the value is in memory, not in registers.
Get printf() / STDIO plumbing working, and printf() the value, or sprintf() via HAL_UART_Transmit()
2024-02-21 09:03 AM
Still, likely to be exceedingly non-portable..
2024-02-21 09:28 AM
Memory inspection only works if the value is in memory, not in registers.
Indeed, but in the current case the variable and its affectation is in the memory.
2024-02-21 09:34 AM
2024-02-21 09:41 AM
Contextually its not presented well enough.
Could be an auto/local variable, which might mean it's held in a register or on the stack.
If it's not throwing a syntax error on compilation I'd assume one hurdle has been jumped. Looking at a disassemble or listing file might give an idea about what is / is not happing.
Not clear how it's being viewed, or how the determination is made it has the wrong value in reality.
2024-02-21 12:11 PM
There is no chance the compiler is not handling this correctly. Likely to be you misinterpreting the data. Not enough information presented to reproduce or even verify the claim.