[WARNING] STM32 trunk repository going crazy for a while

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome.
User avatar
Giovanni
Site Admin
Posts: 10140
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 206 times
Been thanked: 183 times
Contact:

[WARNING] STM32 trunk repository going crazy for a while

Postby Giovanni » Thu Aug 31, 2017 8:19 am

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

User avatar
Giovanni
Site Admin
Posts: 10140
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 206 times
Been thanked: 183 times
Contact:

Re: [WARNING] STM32 trunk repository going crazy for a while

Postby Giovanni » Fri Sep 01, 2017 9:38 am

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
Posts: 429
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 3 times
Been thanked: 28 times

Re: [WARNING] STM32 trunk repository going crazy for a while

Postby steved » Thu Sep 07, 2017 10:11 pm

Giovanni wrote: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.

User avatar
Giovanni
Site Admin
Posts: 10140
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 206 times
Been thanked: 183 times
Contact:

Re: [WARNING] STM32 trunk repository going crazy for a while

Postby Giovanni » Thu Sep 07, 2017 10:13 pm

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

Giovanni

User avatar
FXCoder
Posts: 52
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 10 times

Re: [WARNING] STM32 trunk repository going crazy for a while

Postby FXCoder » Fri Sep 08, 2017 7:38 am

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?

User avatar
Giovanni
Site Admin
Posts: 10140
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 206 times
Been thanked: 183 times
Contact:

Re: [WARNING] STM32 trunk repository going crazy for a while

Postby Giovanni » Fri Sep 08, 2017 7:55 am

Hi,

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

Giovanni

User avatar
FXCoder
Posts: 52
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 10 times

Re: [WARNING] STM32 trunk repository going crazy for a while

Postby FXCoder » Fri Sep 08, 2017 8:18 am

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;
}

User avatar
FXCoder
Posts: 52
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 6 times
Been thanked: 10 times

Re: [WARNING] STM32 trunk repository going crazy for a while

Postby FXCoder » Sat Sep 09, 2017 2:37 am

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


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 3 guests