ChibiOS Free Embedded RTOS

What about the following approach for obtaining a general CPU usage value when
ChibiOS is configured with thread statistics and the idle thread enabled?

The idea is to sum the cumulative execution time of all registered threads,
subtract the idle thread contribution, and compute the CPU load as a ...

What is the reason for the compilation error when activating the same peripheral for both Serial and UART drivers?

I'm referring to this message:

#error "SD1 requires USART1 but it is already used"

...and similar checks involving STM32_USART*_IS_USED .

Is this just a safeguard to prevent ...

Edoardo1982 wrote:...

Thank you for your feedback, I remove that sleep from the code right away.

Edoardo

Would it be possible to remove it as well from at least the latest stable version, [font=Courier New]stable_21.11.x[/font]?

...
Could you give me some feedback on how FDCAN works without that sleep?
...


Hi Edoardo,

After a week in production without that sleep command, I haven't encountered any issues with FDCAN transmission.
It seems we can safely remove it.

The issue I encountered was due to a flaw in my code ...

I’ve been using this patch in production for several months now, and it has been working as expected.

What can I do to get it merged into the current trunk and the latest stable branch?
Do I need to extend my patch with additional configurations, examples, or anything else?

I encountered a limitation caused by the chThdSleepS(OSAL_MS2I(1)) delay in the FDCANv2 driver for STM32. A similar delay also exists in FDCANv1 .

Due to this delay, I’m unable to send CAN FD frames faster than 1 kHz from a single thread, whereas my application requires a 2 kHz transmission rate ...

...
I also have another FDCan patch to make filtering a little bit faster : in the current implementation of filters, all the filters are enabled, and the filters not in use just filter nothing, but filtering hardware have to try them all. I have a patch that dynamically adjust the filter table ...

Hello, Alexandre

It seems that this proposal is implemented with ChibiOS trunk (rev 16769).

Yurii

Attached is the patch that adds I2C5 peripheral support to the STM32H7 port. I hope this helps to incorporate the missing peripheral into the development and latest stable branches.

Is there any specific reason why the I2C5 peripheral is absent in the STM32H7 mcuconf?