ChibiOS Free Embedded RTOS

Hi,

Notes regarding HAL and OSAL evolutions. The general direction is to simplify OSAL and make it more easily implementable on 3rd parties RTOSes.

- Switch in RT OSAL to map events to RT Events OR Callbacks. This would all drivers to operate using callbacks like they already do under NIL.
- Add an sdWaitTransmit() API to the serial driver, it would wait for TX completion without having to use events. Apparently it is a common use case.
- Make all HAL API default to milliseconds for timeouts not ticks. This would simplify the OSAL API because conversion macros could be removed.
- Introduce osalXxxxFromISR() functions in OSAL not requiring explicit use of osalSysLockFromISR() and osalSysUnlockFromISR(). That would make implementation of OSALs easier on RTOSes without the lock/unlock paradigm. Some I-class could be removed after the change.
- Introduce the concept of "clock driver", clock handling would no more be crammed into the general HAL.
- Introduce a common "Critical Errors Handler" that would intercept all critical errors. User could customize the behavior, default would be halt.
- Introduce a common "Runtime Anomalies Handler" that would receive signals of anomalous but not critical conditions from other drivers. From this handler a global event/callback could be triggered.
- Rename OSAL types by adding an osal_ prefix in order to not conflict with RTOS types.
- [DONE] Modify SPI configuration structure to use PAL iolines rather than port/pad.

to be continued

Giovanni

Hi Giovanni,

Why shall the HAL API default to milliseconds, not microseconds? I absolutely agree that systicks should be hidden by the API, but millisecond precision might be too coarse for many cases.

Thomas

Giovanni wrote:..... make it more easily implementable on 3rd parties RTOSes.

It's very good of you to try and remedy the deficiencies of other HALs, but not of relevance to me (and, I suspect, many others)

Giovanni wrote:- Add an sdWaitTransmit() API to the serial driver, it would wait for TX completion without having to use events. Apparently it is a common use case.

There are, of course, two possible flags for 'Tx Completion' - essentially 'Memory buffer empty' and 'All data physically sent' . Dependent on the application, either might be of use. (The updated serial driver with callback options which I submitted can do this with a small amount of supporting code).

Giovanni wrote:- [TENTATIVE] Make all HAL API default to milliseconds for timeouts not ticks. This would simplify the OSAL API because conversion macros could be removed.

Makes sense to default to 'real' units of time. However I agree with Thargon that microsecond resolution would be preferable. (As a small prod in that direction, I seem to be using Posix-compatible libraries a fair amount recently, and IIRC they go down to microseconds. Things are only going to get faster - I haven't fully adjusted from the Z-80 days of a minimum 1usec to execute a single assembly-level instruction).

Giovanni wrote:- Introduce the concept of "clock driver", clock handling would no more be crammed into the general HAL.

This is presumably a different way to handle the clock trees you love so much?

Giovanni wrote:- Introduce a common "Critical Errors Handler" that would intercept all critical errors. User could customize the behavior, default would be halt.
- Introduce a common "Runtime Anomalies Handler" that would receive signals of anomalous but not critical conditions from other drivers. From this handler a global event/callback could be triggered.
- Rename OSAL types by adding an osal_ prefix in order to not conflict with RTOS types.

Good ideas

Thargon wrote:Why shall the HAL API default to milliseconds, not microseconds? I absolutely agree that systicks should be hidden by the API, but millisecond precision might be too coarse for many cases.

OSAL has 2 different times currently:

1) Timeouts for I/O functions, I am trying to decouple this from the underlying system time resolution for sake of simplicity.
2) Real time counter that can be used for high resolution stamps and accurate polled wait functions.

I wonder if there are use cases requiring sub-millisecond resolution for I/O timeouts. The problem is that it would not be portable, you need the underlying RTOS to be able to handle high resolution, I know just one RTOS with that capability...

steved wrote:It's very good of you to try and remedy the deficiencies of other HALs, but not of relevance to me (and, I suspect, many others)

I used to not care too but a lot of work went into HAL and it covers very few families and only STM32 with decent coverage, increased adoption would benefit ChibiOS users too. Considering the kind of £%$% that are commonly mislabeled as HALs this could work. Anyway, the idea is to simplify the OSAL API to what is strictly required by HAL.

steved wrote:This is presumably a different way to handle the clock trees you love so much?

A way to have multiple "clock configurations" that can be switched at runtime, right now we have only one static configuration. It would also be foundation for hals/sleep/standby support in the HAL

Giovanni

Hi Giovanni,

Nice list already.
How about a new abstract ioline interface, which can be used by the SPI driver to select/unselect a line. This way the \CS line can be controlled by the PAL driver, an I2C IO expander or another SPI IO expander, etc..

I can write a prototype for it if you like the idea.

Marco

Hi Marco,

We already have iolines in PAL, the SPI implementations should be updated to use that instead of port/pad, a fallback mode is also required. Adding it to the list.

Giovanni

Giovanni wrote:Hi Marco,

We already have iolines in PAL, the SPI implementations should be updated to use that instead of port/pad, a fallback mode is also required. Adding it to the list.

Giovanni

Hi Giovanni,

I know, and i already use them in the Tiva testhal and demo applications, but it is not abstract enough.
Imagine the attached image. AFAIK this is not possible right now without custom code.

Marco

It is a way too specific use case and it would be problematic to implement too, the spiSelect() and spiUnselect() functions are meant to be callable from any context (thread and ISR) while the I2C driver can only be used from thread context being synchronous.

Giovanni

Giovanni wrote:It is a way too specific use case and it would be problematic to implement too, the spiSelect() and spiUnselect() functions are meant to be callable from any context (thread and ISR) while the I2C driver can only be used from thread context being synchronous.

Giovanni

I understand. I didn't pay attention to that spiSelect() and spiUnselect() are callable from any context. I'm sorry for the noise

Marco

np, it is food for thought in any case.

Giovanni