cancel
Showing results for 
Search instead for 
Did you mean: 

'register' specifier in Cube/LL

waclawek.jan
Super User

I have a bunch of following warnings:

c:/programs/ARMtools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F1xxxx/STM32F1xx_HAL_Driver/Inc/stm32f1xx_ll_gpio.h: In function 'void LL_GPIO_SetPinMode(GPIO_TypeDef*, uint32_t, uint32_t)':
c:/programs/ARMtools/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F1xxxx/STM32F1xx_HAL_Driver/Inc/stm32f1xx_ll_gpio.h:343:22: warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
  343 |   register uint32_t *pReg = (uint32_t *)((uint32_t)((uint32_t)(&GPIOx->CRL) + (Pin >> 24)));
      |

in several LL headers.

Can this please be fixed in some suitable way? One way to do that might be to replace the 'register' specifier by a macro, which would be defined based on the __cplusplus  standard preprocessor macro and its value. A simple version would be to add

#if __cplusplus >= 201703L
#define register
#endif

to each header where this occurs, but I am not a C++/build-environment specialist so don't know whether this may have some unwanted effect I am not aware off.

Thanks,

JW

6 REPLIES 6
Andrew Neil
Super User

Same Issue recently:

HAL functions using archaic terms - why? 

(the "archaic term" is the register specifier)

 

PS:

and from 2018:

Is the "register" storage class specifier necessary in STM32 LL interfaces?

TL;DR: No.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
T_Hamdi
ST Employee

Hello @waclawek.jan ,

Please refer to the package available on GitHub. it has been updated and this item has been removed from the header file: stm32f1xx_ll_gpio.h 

Please download the latest version of the package from the GitHub page.

thank you!

Hamdi

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.
Hamdi Teyeb

Is it just the F1 that's been updated?

The other linked threads refer to U0 and L4

Presumably (all?) others are similarly affected?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

hello @Andrew Neil 

Yes, all of them have been updated, not just the F1.
The same change has been applied to the other affected series.

thank you!

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.
Hamdi Teyeb
waclawek.jan
Super User

Hi @T_Hamdi ,

thanks, that would solve it for this particular header file.

But what about other headers, e.g. https://github.com/STMicroelectronics/stm32f1xx-hal-driver/blob/a433ed968f1812eff2de76288af48aab2e369e9f/Inc/stm32f1xx_ll_rtc.h#L553 ?

JW

Hello @waclawek.jan 

Thank you for bringing this issue to our attention.

I reported this internally. Internal ticket number: 225259 (This is an internal tracking number and is not accessible or usable by customers).

Best regards,

Hamdi

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.
Hamdi Teyeb