STM32CubeWB

STM32CubeWB copied to clipboard

Hello -

The Q4 GCC ARM embedded toolchain has arrived (see https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads) with C++20 support. I don't know if the STM32Cube's goal is to be compatible with a C++20 compiler yet (e.g. includes like the LL_* family of functions), but if it is:

Part of C++20 deprecates some usages of volatile (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r4.html). You can no longer assign a volatile directly from a volatile; it must go through a temporary value so that the loads and stores are a bit more explicit. The following is the compiler error when compiling against the C++20 standard for the stm32wbxx.h file:

stm32wbxx.h:135:38: error: compound assignment with 'volatile'-qualified left operand is deprecated [-Werror=volatile]

https://github.com/STMicroelectronics/STM32CubeWB/blob/17fe6be729cbb8c2a92cff3be3d16696c1d3fc8a/Drivers/CMSIS/Device/ST/STM32WBxx/Include/stm32wbxx.h#L135-L147

It's a fairly trivial change in the header file to correct it. The SET_BIT(...), CLEAR_BIT(...), and MODIFY_REG(...) macros need to be of the following form where a temporary is explicitly set (e.g. no |=, or &= permitted):

#define SET_BIT(REG, BIT)                                   \
            do {                                            \
                uint32_t tmp = REG;                         \
                tmp |= BIT;                                 \
                REG = tmp;                                  \
            } while(0)

Unfortunately that means "REG" is used twice in the macro in that specific, but it's probably the best one could do. Hopefully no-one is expecting to call it like SET_BIT(x++, y) in their usages of it (which I think would be an unexpected usage).

Thanks, Tim

#define SET_BIT(REG, BIT)     ((REG) = (REG) | (BIT))
#define CLEAR_BIT(REG, BIT)   ((REG) = (REG) & ~(BIT))

Seems to fix the warning too. But I'm not sure if it fixes the problem!

#define SET_BIT(REG, BIT)     ((REG) = (REG) | (BIT))
#define CLEAR_BIT(REG, BIT)   ((REG) = (REG) & ~(BIT))

Seems to fix the warning too. But I'm not sure if it fixes the problem!

You're right, that form fixes the volatile warning from C++20 too. Of course, in both cases, REG is inside the macro twice which is unavoidable with |= and &= being deprecated with volatiles. Granted, I still think it'd be really weird for someone to call SET_BIT or CLEAR_BIT with an increment on REG. Technically if you knew the bit width was always 32-bits wide, you could do something like:

#define SET_BIT(REG, BIT)     do { \
    volatile uint32_t *tmp = &(REG); \
    ...

which would guarantee only one instance of "REG" in the macro, but I'm betting there are probably 16-bit width usages of the macro since currently it's effectively generic.

Hi @alexanderwachter,

Thank you for contribution. It has been transferred to our technical teams for deeper analysis. We will be back to you as soon as we get an answer. Thank you for you again for your contribution.

With regards

ST Internal Reference: 107263

For what it's worth, C++23 has dedeprecated some of this. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r1.pdf. (E.g. it might not be an issue with C++23.)

Hello @alexanderwachter,

Please allow me to close this thread as no activity. You may reopen it at any time if you have any details to share with us in order to help you to solve the issue. Thank you for your comprehension.

With regards

Hello Tim, I reopen the issue do you check the latest version.?

Hi @RJMSTM -

Simple code inspection shows if it's an issue with C++20 still or not, and technically it's still an issue against C++20. However, after I made my additional comment (and removed it), I had forgotten about the fact that C++23 dedeprecated the deprecation. So while the title of it is against C++20, it's a non-issue in C++17 and C++23. It's probably okay to mark it as "won't fix" as a decision instead of "no activity thus no longer an issue".

However, I don't know if views towards volatiles from the C++ community will change again, but likely not? :shrug: I'll leave the decision with ST whether or not they care about the C++20 compatibility since it's resolved in C++23.

Thanks, Tim

See also https://github.com/STMicroelectronics/STM32CubeF0/issues/11

Hello @tim-nordell-nimbelink,

Thank you for your contribution, Unfortunately, our development team has declined your proposal. According to them, no intention indeed for Cube1 to be compliant with C++20.

see (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r0.pdf) Now idea yet of the outcome

In this case, please allow me to close this issue. Thank you for your comprehension and thank you again for your proposal.

With regards, Rania