[NOTE] HAL 6 and OSAL Evolutions

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome.
User avatar
Giovanni
Site Admin
Posts: 10341
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 231 times
Been thanked: 205 times
Contact:

[NOTE] HAL 6 and OSAL Evolutions

Postby Giovanni » Sat Aug 12, 2017 12:26 pm

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

Thargon
Posts: 56
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 3 times
Been thanked: 3 times

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby Thargon » Mon Aug 14, 2017 10:16 am

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

steved
Posts: 456
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 3 times
Been thanked: 34 times

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby steved » Mon Aug 14, 2017 1:55 pm

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

User avatar
Giovanni
Site Admin
Posts: 10341
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 231 times
Been thanked: 205 times
Contact:

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby Giovanni » Mon Aug 14, 2017 5:13 pm

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

Marco
Posts: 122
Joined: Tue Apr 16, 2013 8:22 pm
Has thanked: 4 times
Been thanked: 10 times

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby Marco » Tue Aug 15, 2017 1:15 pm

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

User avatar
Giovanni
Site Admin
Posts: 10341
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 231 times
Been thanked: 205 times
Contact:

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby Giovanni » Tue Aug 15, 2017 2:44 pm

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

Marco
Posts: 122
Joined: Tue Apr 16, 2013 8:22 pm
Has thanked: 4 times
Been thanked: 10 times

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby Marco » Tue Aug 15, 2017 4:00 pm

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
Attachments
Screenshot from 2017-08-15 16-58-58.png

User avatar
Giovanni
Site Admin
Posts: 10341
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 231 times
Been thanked: 205 times
Contact:

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby Giovanni » Tue Aug 15, 2017 5:30 pm

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

Marco
Posts: 122
Joined: Tue Apr 16, 2013 8:22 pm
Has thanked: 4 times
Been thanked: 10 times

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby Marco » Mon Aug 21, 2017 10:50 am

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 :oops:

Marco

User avatar
Giovanni
Site Admin
Posts: 10341
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 231 times
Been thanked: 205 times
Contact:

Re: [NOTE] HAL 6 and OSAL Evolutions

Postby Giovanni » Mon Aug 21, 2017 11:11 am

np, it is food for thought in any case.

Giovanni


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 2 guests