[RFC] HAL-OSAL rework

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
Post Reply

Making HAL compatible with more RTOSes

Good idea
1
17%
Low priority
3
50%
Not sure
2
33%
Not a good idea
0
No votes
 
Total votes: 6

User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

[RFC] HAL-OSAL rework

Post by Giovanni »

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 :D it would enable 1:1 comparisons between RT/NIL and other solutions using the same HAL/setup.

Giovanni
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: [RFC] HAL-OSAL rework

Post by Giovanni »

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
Post Reply