Hello,
I am currently starting the evaluation of ChibiOs as the RT OS for one of my projects and I have a question regarding the OS locking mechanism on Cortex M3/4 targets.
I took a look at the device driver model and it appears that every time I want to configure a device (with spiStart() for example) the osalSysLock() function is called, preventing (as I understand it) any context switching during the configuration process.
Could you please confirm that (or not)?
Thank you.
OS locking during HAL configuration
-
Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: OS locking during HAL configuration
Hi,
Lock/unlock operations are used for implementing critical sections, on Cortex-M this is achieved by raising the value into the BASEPRI register.
Their use prevents IRQ servicing until the initialization is complete which happens in a small finite time, it is a simple procedure, IRQ are not lost but just delayed until osalSysUnlock().
Critical sections are used across the HAL, not just when configuring peripherals, it is done in order to keep certain operations atomic.
Giovanni
Lock/unlock operations are used for implementing critical sections, on Cortex-M this is achieved by raising the value into the BASEPRI register.
Their use prevents IRQ servicing until the initialization is complete which happens in a small finite time, it is a simple procedure, IRQ are not lost but just delayed until osalSysUnlock().
Critical sections are used across the HAL, not just when configuring peripherals, it is done in order to keep certain operations atomic.
Giovanni
Re: OS locking during HAL configuration
Thank you for your quick reply Giovanni.
That is what I thought. And unfortunately it is a big no-go for me, such a (thread) latency is unacceptable for most of my projects.
And I still don't see the point. The (small piece of) code that I reviewed can be interrupted without any issue and doesn't need any kernel locking mechanism.
From my point of view it kills the benefits of a called-fast RT kernel.
That is what I thought. And unfortunately it is a big no-go for me, such a (thread) latency is unacceptable for most of my projects.
And I still don't see the point. The (small piece of) code that I reviewed can be interrupted without any issue and doesn't need any kernel locking mechanism.
From my point of view it kills the benefits of a called-fast RT kernel.