[WARNING] STM32 trunk repository going crazy for a while

[Giovanni]

I am planning to do some organization changes to the STM32 HAL implementation.

- Support for shared interrupt in order to allow all timers in ST, PWM and ICU.
- Group the IRQ priority settings in a single section of mcuconf.h instead of repeating those for each driver (which makes no sense if an IRQ is shared and used by different drivers).
- Version marking of mcuconf.h files in order to avoid errors caused by mixing obsolete files in applications.
- EXT driver will be deprecated or entirely removed.
- Remove dependencies between board files and PAL driver, initialization code will be self-contained in board.c.

This will cause a rework of most drivers and, probably, introduce regressions. The demos could not all be compilable during the transition.

Giovanni

[Giovanni]

What I am going to do is the following:

- EXT driver will not be removed but officially deprecated in HAL6.
- EXT support for STM32 will be removed, too much effort in preserving it while adding callbacks support to PAL implementations.

Rationale:
- PAL is much easier to use.
- Other ports may need EXT support until PAL is adjusted.

Consequences for the STM32 port:
- Non GPIO EXTI sources will have to be handled by the various drivers, for example RTCv2 will need to handle the alarm callback by itself.
- An EXTI helper driver could be required.

Giovanni

[steved]

Consequences for the STM32 port:
- Non GPIO EXTI sources will have to be handled by the various drivers, for example RTCv2 will need to handle the alarm callback by itself.
- An EXTI helper driver could be required.

Good idea to throw out the EXTI driver - I found that it took around 1K of code on an F0, and since I only had less than 100 bytes spare, I hard-coded a handler for the RTC:

Code: Select all

/**
 * EXT handler ISR specifically for RTC
 *
 * Creating this manually saves over 1K of code!
 */
#define RTC_EXT_CHANNEL     17

OSAL_IRQ_HANDLER(Vector48)
{
  OSAL_IRQ_PROLOGUE();

  EXTI->PR = (1 << 17);
  chSysLockFromISR();
  chEvtSignalI(programmerThreadPtr, RTC_ALARM_EVENT);
  chSysUnlockFromISR();

  OSAL_IRQ_EPILOGUE();
}


void configureRTCInterrupt(void)
{
  EXTI->RTSR |= (1 << RTC_EXT_CHANNEL);             // Rising edge enable
  EXTI->FTSR  &= ~(1 << RTC_EXT_CHANNEL);           // Falling edge disable
  EXTI->IMR |= (1 << RTC_EXT_CHANNEL);              // Interrupt enable
  EXTI->EMR &= ~(1 << RTC_EXT_CHANNEL);
//  EXTI->PR     =  (1 << RTC_EXT_CHANNEL);
  nvicEnableVector(RTC_IRQn, STM32_EXT_EXTI17_20_IRQ_PRIORITY);
}


That routine which configures the interrupt could readily become a generic helper routine, I think. But harder to make the ISR generic.

[Giovanni]

I am thinking to a EXTI helper driver like RCC, just macros.

Giovanni

[FXCoder]

Hi Giovanni,
Just been migrating an old project to use the new pal callbacks.
I have a prototype function declaring the callback and then the actual callback further down the code body.

Unless I cast the callback to palcallback_t in palSetLineCallback() the compiler complains about mismatch.
Should palSetLineCallback(line, cb, arg) cast cb before calling palSetLineCallbackI(line, cb, arg)?
Or is it expected that the cast is made at the top level?

[Giovanni]

Hi,

There should be no need for a cast if your callback has the same signature of the callback type.

Giovanni

[FXCoder]

My callback is just a static void function.

Without the cast the compiler definitely complains...

Code: Select all

main.c: In function 'Decoder':
main.c:373:39: warning: passing argument 3 of 'palSetLineCallbackI' from incompatible pointer type
   palSetLineCallback(LINE_CCA, extsquelch, chThdGetSelfX());

It seems correct that the compiler should complain with a warning as the function signatures are not the same without a cast at the API level.

palSetLineCallback just passes cb straight through...

Code: Select all

#define palSetLineCallback(line, cb, arg)                                   \
  do {                                                                      \
    osalSysLock();                                                          \
    palSetLineCallbackI(line, cb, arg);                                     \
    osalSysUnlock();                                                        \
  } while (false)

palSetLineCallbackI expects a palcallback_t to be passed to it as cb...

Code: Select all

void palSetLineCallbackI(ioline_t line, palcallback_t cb, void *arg) {

  palevent_t *pep = pal_lld_get_line_event(line);
  pep->cb = cb;
  pep->arg = arg;
}

[FXCoder]

Ignore the previous.
I realized I had copied the function from other code and not changed the function parameter to void *.