ChibiOS Free Embedded RTOS

OK thanks, I just figured since they had a fix merged in the issue (increase the timings slightly) that might be something that the ChibiOS HAL might have included as well.

Ill try the workaround and report.

I might have run into an issue similar to this: https://github.com/stm32-rs/stm32l4xx-hal/issues/180 There are quite some errata sheets that point to something suspiciously similar to what I have been experiencing.. I'm using a STM32L496 where I have a bunch of ADCs connected. We have built hundreds...

Hi Giovanni and faisal, thank you so much for your help, I really appreciate that! In the meantime I found another solution that works without any communication and comes with a shortcoming we can live with. That's why I cannot tell right now whether the queue approach works out. Anyway I learned th...

Hi everyone, we implemented a new feature in our code that required a new mailbox. After hat we faced the issue that the thread-callup timings have increased. Not much, but enough to make a system-in-the-loop test fail. we filled the mailbox here in sender.c, which is located in Thread A: int send(u...

Hi everyone, we're trying to make our efl_lld descriptor automatically get adjusted to the MCU we are using, since the L4 has different flash sizes. Due to the struct being const, we had to define a couple and then use an if/else to return the correct one: https://github.com/Stabl-Energy/ChibiOS/pul...

Can you elaborate on how to generate the board files as part of the build?

Yeah we had this part in our board.c #if STM32_HAS_GPIOI {VAL_GPIOI_MODER, VAL_GPIOI_OTYPER, VAL_GPIOI_OSPEEDR, VAL_GPIOI_PUPDR, VAL_GPIOI_ODR, VAL_GPIOI_AFRL, VAL_GPIOI_AFRH, VAL_GPIOI_ASCR, VAL_GPIOI_LOCKR}, #endif Which wasn't defined in the board.h, maybe we need to figure out how to fix that on...

For example the STM32L496Vx Series, with the LQFO100 footprint. Whereas the STM32L496Ax series with UFBGA169 would work.

We're using 20.3.x, refer to this topic: viewtopic.php?f=35&t=5946

Basically the STM32_HAS_GPIOI flag was set to true for all STM496, but there are some packages that don't have a GPIOI.

Fix #1198 breaks compilation for all STM496 (and maybe even L4A6) with less than 169 pins, since they don't have a GPIOI. Example Chip is the STM32L496Vx Series. Is there an elegant way to fix this? Our workaround is to revert this commit (sorry I can't navigate sourceforge that well): https://githu...