Some RTC Macro did'nt use pHandle

[CanastraRF]

The following RTC Macro didn't use HANDLE

G4

__HAL_RTC_WRITEPROTECTION_DISABLE( __HANDLE__);
__HAL_RTC_WRITEPROTECTION_ENABLE( __HANDLE__);
__HAL_RTC_ALARM_ENABLE_IT(__HANDLE__, RTC_IT_ALRA);
__HAL_RTC_ALARM_DISABLE_IT(__HANDLE__, RTC_IT_ALRA);
__HAL_RTC_ALARM_GET_IT_SOURCE(__HANDLE__, RTC_IT_ALRA)

__HAL_RTC_ALARMA_ENABLE( __HANDLE__);
__HAL_RTC_ALARMA_DISABLE( __HANDLE__);
__HAL_RTC_ALARMB_ENABLE( __HANDLE__);
__HAL_RTC_ALARMB_DISABLE( __HANDLE__);

__HAL_RTC_WAKEUPTIMER_ENABLE( __HANDLE__);
__HAL_RTC_WAKEUPTIMER_DISABLE( __HANDLE__);
__HAL_RTC_WAKEUPTIMER_CLEAR_FLAG(__HANDLE__, RTC_FLAG_WUTF);
__HAL_RTC_WAKEUPTIMER_ENABLE_IT(__HANDLE__, RTC_IT_WUT);
__HAL_RTC_WAKEUPTIMER_DISABLE_IT(__HANDLE__, RTC_IT_WUT);
__HAL_RTC_WAKEUPTIMER_GET_IT_SOURCE(__HANDLE__, RTC_IT_WUT)

__HAL_RTC_TIMESTAMP_ENABLE( __HANDLE__);
__HAL_RTC_TIMESTAMP_DISABLE( __HANDLE__);
__HAL_RTC_TIMESTAMP_CLEAR_FLAG(__HANDLE__, RTC_FLAG_WUTF);
__HAL_RTC_TIMESTAMP_ENABLE_IT(__HANDLE__, RTC_IT_TS);
__HAL_RTC_TIMESTAMP_DISABLE_IT(__HANDLE__, RTC_IT_TS);
__HAL_RTC_TIMESTAMP_GET_IT_SOURCE(__HANDLE__, RTC_IT_TS)
__HAL_RTC_TIMESTAMP_GET_IT(__HANDLE__, RTC_IT_WUT)

In other families HANDLE is required. My compiler report warning: unused variable 'HANDLE' [-Wunused-variable]

example: STM32G4:

define __HAL_RTC_WRITEPROTECTION_ENABLE(HANDLE) \

do{ \ RTC->WPR = 0xFFU; \ } while(0)

STM32F4:

define __HAL_RTC_WRITEPROTECTION_ENABLE(HANDLE) \

do{                                       \
   (__HANDLE__)->Instance->WPR = 0xFFU;  \
 } while(0)

Please do it always the same way

BTW Can you explain the do {...} while(0) ? What is the the improvment to {...}

RetoFelix

[ALABSTM]

Hi @CanastraRF,

Thank you for having reported and especially for the exhaustive list of macros needing to be updated. The issue has been confirmed and logged into our internal database. A fix will be made available in a future release (not the next, v1.4.0, rather a later one).

With regards,

[ALABSTM]

ST Internal Reference: 102002

[ALABSTM]

Hi @CanastraRF,

I hope you are fine. The issue you reported has been fixed in the frame of version v1.5.0 of the STM32CubeG4 published recently on GitHub. Thank you again for having reported.

Regarding your question about the advantage of surround our macros' bodies with do { ... } while(0) instead of simply using braces { ... }, it is to cover as much cases as possible. Let me illustrate with the example below from our development teams .

Consider the following macro:

#define SOME_FUNC(val) { foo(val * 2); \
                         bar(val); }

Assume it is used in the code snippet below:

  if (...)
    SOME_FUNC(42);
  else
    ... ;

Because of the semicolon ; after the SOME_FUNC(42) macro invocation, the code snippet will look like below once the macro expanded, which is invalid:

  if (...)
  {
    foo(val * 2);
    bar(val);
  };
  else
    ... ;

One would argue we simply have to avoid the semicolon in this particular case. But requiring from our users to check whether a trailing semicolon is required each time they invoke a macro in their code is not the best thing to do. Hence, we use the do { ... } while(0) structure . I hope this answers your question.

With regards,

[CanastraRF]

Hi @ALABSTM

Happy new Year Thank you for the Update and the explanation

[ALABSTM]

Hi @CanastraRF,

Happy new year to you too. My best wishes of health, happiness and serenity. You are more than welcome.

With regards,