ChibiOS Free Embedded RTOS

Posted: **Tue Mar 03, 2026 10:19 am**

Hi,

How high would you rate modifying the OSAL to make HAL porting to other RTOSes a real possibility?

Currently the OSAL is very close to the RT own patterns, for example:

Code: Select all

osalSysLock();
if (!condition) {
  osalThreadSuspendS();
}
osalSysUnlock();

Going to sleep atomically inside a critical section is something that most (all) other RTOSes cannot do, there are also other similar patterns. Because of this current OSAL is very hard to port correctly to other RTOSes.

Making a different OSAL and reworking HAL would be a huge effort, wondering if it is something worth doing.

Alternatively, instead of modifying HAL/OSAL (huge legacy and effort) it could be targeted to the experimental XHAL currently in trunk which is much more a work-in-progress.

BTW not considering this out of pure generosity

it would enable 1:1 comparisons between RT/NIL and other solutions using the same HAL/setup.

Giovanni

Posted: **Fri Mar 06, 2026 3:11 pm**

I am beginning to think that OSAL could be removed entirely:

1) It cannot easily implemented by other RTOSes because I-S-class API is exclusive to ChibiOS.
2) Making it more abstract would be a huge rework of the whole HAL (S-class functions would need to disappear with loss of functionality).
3) As it is there is no real added value.

The only use case is using HAL on bare metal and that could still be done by creating stubs of the normal "ch" API instead of the "osal" API.

Advantage in removing it:
1) Many hundreds lines of code removed.
2) Architectural simplicity.
3) Integration simplicity-
4) Hypothetical other RTOSes supporting something like I-S-class could simply emulate the "ch" API instead of the "osal" API, just the name changes.

Giovanni

ChibiOS Free Embedded RTOS

[RFC] HAL-OSAL rework

[RFC] HAL-OSAL rework

Re: [RFC] HAL-OSAL rework