I didn't see this question asked plainly, even though the thread The purpose of SVC_Handler does shed some light into the eventual answer.
Today, so-called "hypervisors" (think of the mbed uVisor, or Nordic's Softdevice) are becoming more and more popular in order to separate a protected execution area where security, communication stacks and other "manufacturer provided" functionality can live without risking corruption from the "user developed" application.
You call into the hypervisor services via the SVC instruction, and the SVC handler is thus provided by the hypervisor code itself. These hypervisors don't necessarily provide services for real-time scheduling, or any other RTOS functionality. These are left to the "application developer" to choose.
So here is the question:
As QK implements its own SVC handler, how would you solve the apparent incompatibility between both so as to still be able to use QK with an hypervisor that implements its own SVC handler ?
1) If you could modify the SVC handler in the hypervisor code?
2) If such modification is impossible?
The hypervisors generally forward most ISR's from their own ISR table to the application provided ISR table.
Thanks,
-nestor
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In case of 3rd-party "hypervisors" the SVC_Handler must obviously not be used by the real-time kernel. In that case, the alternative design whith just the PendSV_Handler must be applied.
I will look into this for the futue release of QP, especially because the QK preemptive kernel is planned to be extened to support traditional blocking. Such QXK ("extended QK) kernel would be capable to run blocking tasks ("extened" tasks in OSEK terminology). This would be useful to run various 3-rd party middleware designed for traditional blocking, without the need to run QP on top of a traditional RTOS. Needless to say, QXK would simplify the overall system and reduce the cost.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At this point the QXK component is in the requirements gathering phase, so it is hard to make estimates before even knowing what is to be built.
One of the biggest issues is the minimal set of blocking primitives that such a kernel must provide in order to be useful in the middleware out there. Here I could use help from developers. What is your middleware using? Would just a blocking semaphore with a timeout suffice? (Such a semaphore could also double as a blocking time delay)? Any help in nailing this down would be greatly appreciated.
--MMS
Last edit: Quantum Leaps 2015-11-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think a semaphore with a timeout would be a very good start. It definitely matches the blocking interface I've seen in LWIP as well as a few GUI packages. Some of these require more than 1 semaphore, IIRC.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I mean of course one semaphore type, but with as many instances as needed.
However, any given semaphore instance would be limited to blocking only one task, as opposed to blocking muliple tasks. In other words, only one task would be able to "take" the semaphore. Of course, such a semaphore would not be useful for mutual exclusion. But, for mutual exclusion (if needed) the current priority-ceiling mutex should do, right?
On the oher hand, multiple tasks/ISRs could "give" the semaphore.
Would such a "single-take" semaphore suffice for the middleware that you guys use?
--MMS
Last edit: Quantum Leaps 2015-11-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
However, any given semaphore instance would be limited to blocking only one task, as opposed to blocking muliple tasks. In other words, only one task would be able to "take" the semaphore. Of course, such a semaphore would not be useful for mutual exclusion. But, for mutual exclusion (if needed) the current priority-ceiling mutex should do, right?
That is a very good question. I don't know how it works inside the GUI package that was requesting 2 semaphores. Presumably it was for 2 tasks but I didn't look inside the code. IIRC, this was the emWin code but I only had the binary from ST so no code. I guess I would start looking at how it's used in the emWin code. I would guess that you'd see something similar in the LWIP package. Yes, I know the current port works perfectly well for it but it should give a good idea about how they are using those semaphores internally.
Hell, they could have been asking for mutexes (instead of semaphores) now that I think about it a little more...
I guess what I'm saying is to look at those packages and see what they are requesting as far as resources.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Miro, should we better start a new thread "RFC new features in QXK" ?
Regarding the original question, with the current QK implementation, 5.4.2a, if I can modify the "hypervisor" SVC_Handler code (that takes one parameter that identifies the system call) to handle a new service that would do exactly what the QK SVCall_Handler does this would sort the problem for now. Do you agree?
Otherwise, if I can't modify the hypervisor but can trigger another ISR by setting a bit on the NVIC, and then implement that ISR_Handler to pop that exception stack frame from the stack this would also work, right? What about the priority for this ISR? As far as I can see any priority would work... What do you think ?
-nestor
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I will start a new discussion thread to solicit comments about the planned features for the "extended" kernel (QXK).
Regarding the elimination of SVC_Handler from the existing QK port, there is no need to improvise. An implementation without the SVC is already available and is working in the lab. The code is undergoing testing and so far has passed all the preemption tests that I could think of. The code will be released very soon as QP/C 5.5.2-beta. This release will contain the updated QK port to ARM Cortex-M for all supported complers: ARM-Keil, GNU-ARM, IAR EWARM, and TI-CCS-ARM.
All the changes for the new ARM Cortex-M QK port are confined to the port and applications are not affected at all (except that SVC_Handler is not used anymore.)
--MMS
Last edit: Quantum Leaps 2015-11-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you please give a brief description of how the QK Cortex-M port preemption and context switching works without using SVCall since v5.6.0? Is there any performace difference to previous versions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The recent QK ports to ARM Cortex-M work as follows:
The QK_ISR_EXIT() macro (which must be called before exiting every "kernel-aware" ISR) calls the function QK_schedPrio_() to find out the highest-priority AO ready to run. The function returns 0 if there is no such AO of priority higher than the current priority. When the function returns non-zero (meaning that there is a new highest-priority AO to run), this priority is saved in the QK_nextPrio_ static variable to be used later and the PendSV exception is triggered. Otherwise, the ISR simply returns to the preempted context.
NOTE: Previously, the QK_ISR_EXIT() macro always triggered the PendSV exception, which had to find the highest-priorty AO and do the simple return if such AO was not found.
The PendSV exception starts off with inspecting the QK_nextPrio_ variable. If this variable is non-zero, then it indicates that the QK scheduler needs to be called to perform the asynchronous preemption. Please note that QK_nextPrio_ cannot be zero when the PendSV is triggered from an ISR.
After the QK scheduler returns, the variable QK_nextPrio_ is set to zero and the PendSV is called again to pefrom the interrupt-return to the original context.
NOTE: Previously, PendSV triggered the SVCall exception to return to the original context. Now, SVCall is NOT used.
Going back to the beginning of PendSV exception, if QK_nextPrio_ turns out to be zero, PendSV removes its own stack frame from the stack and returns to the preempted context.
NOTE: Previously, this return to the previous context was done in the SVCall exception, but now it is peformed in the other branch of the PendSV exception. Taking this extra branch does not incurr much cost, because the variable QK_nextPrio_ needs to be loaded into a register anyway, so a branch costs ony a test against zero.
Regarding the performance difference between the previous and current QK port to Cortex-M, it depends a bit on the pattern of use.
If most of your interrupts lead to context switch (because they activate a higher-priority AO), then the previous implementation was slightly more efficient. If significant number of ISR return to the original conext without asynchronous preemption, then the new implementation is more efficient.
But, to put things in perspective, the differences are only a few machine instructions, so are completely in the noise.
--MMS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for taking the time to provide such a clear and complete description. I know that the Cortex M QK / scheduler code has undergone a lot of changes, and you always update the App Note pdf with the current description of the behavior. Much different than what was originally documented in PSiCC2!
Hello,
I didn't see this question asked plainly, even though the thread The purpose of SVC_Handler does shed some light into the eventual answer.
Today, so-called "hypervisors" (think of the mbed uVisor, or Nordic's Softdevice) are becoming more and more popular in order to separate a protected execution area where security, communication stacks and other "manufacturer provided" functionality can live without risking corruption from the "user developed" application.
You call into the hypervisor services via the SVC instruction, and the SVC handler is thus provided by the hypervisor code itself. These hypervisors don't necessarily provide services for real-time scheduling, or any other RTOS functionality. These are left to the "application developer" to choose.
So here is the question:
As QK implements its own SVC handler, how would you solve the apparent incompatibility between both so as to still be able to use QK with an hypervisor that implements its own SVC handler ?
1) If you could modify the SVC handler in the hypervisor code?
2) If such modification is impossible?
The hypervisors generally forward most ISR's from their own ISR table to the application provided ISR table.
Thanks,
-nestor
In case of 3rd-party "hypervisors" the
SVC_Handlermust obviously not be used by the real-time kernel. In that case, the alternative design whith just thePendSV_Handlermust be applied.I will look into this for the futue release of QP, especially because the QK preemptive kernel is planned to be extened to support traditional blocking. Such QXK ("extended QK) kernel would be capable to run blocking tasks ("extened" tasks in OSEK terminology). This would be useful to run various 3-rd party middleware designed for traditional blocking, without the need to run QP on top of a traditional RTOS. Needless to say, QXK would simplify the overall system and reduce the cost.
--MMS
This would be incredibly helpful. I'm stuck using QP on top of FreeRTOS for exactly this reason on a project at work currently.
Hi Miro
I know it is always difficult to make estimations for new features, but can you share some kind of time frame for QXK?
Thanks,
Gawie
At this point the QXK component is in the requirements gathering phase, so it is hard to make estimates before even knowing what is to be built.
One of the biggest issues is the minimal set of blocking primitives that such a kernel must provide in order to be useful in the middleware out there. Here I could use help from developers. What is your middleware using? Would just a blocking semaphore with a timeout suffice? (Such a semaphore could also double as a blocking time delay)? Any help in nailing this down would be greatly appreciated.
--MMS
Last edit: Quantum Leaps 2015-11-09
I think a semaphore with a timeout would be a very good start. It definitely matches the blocking interface I've seen in LWIP as well as a few GUI packages. Some of these require more than 1 semaphore, IIRC.
I mean of course one semaphore type, but with as many instances as needed.
However, any given semaphore instance would be limited to blocking only one task, as opposed to blocking muliple tasks. In other words, only one task would be able to "take" the semaphore. Of course, such a semaphore would not be useful for mutual exclusion. But, for mutual exclusion (if needed) the current priority-ceiling mutex should do, right?
On the oher hand, multiple tasks/ISRs could "give" the semaphore.
Would such a "single-take" semaphore suffice for the middleware that you guys use?
--MMS
Last edit: Quantum Leaps 2015-11-09
That is a very good question. I don't know how it works inside the GUI package that was requesting 2 semaphores. Presumably it was for 2 tasks but I didn't look inside the code. IIRC, this was the emWin code but I only had the binary from ST so no code. I guess I would start looking at how it's used in the emWin code. I would guess that you'd see something similar in the LWIP package. Yes, I know the current port works perfectly well for it but it should give a good idea about how they are using those semaphores internally.
Hell, they could have been asking for mutexes (instead of semaphores) now that I think about it a little more...
I guess what I'm saying is to look at those packages and see what they are requesting as far as resources.
Hi Miro, should we better start a new thread "RFC new features in QXK" ?
Regarding the original question, with the current QK implementation, 5.4.2a, if I can modify the "hypervisor" SVC_Handler code (that takes one parameter that identifies the system call) to handle a new service that would do exactly what the QK SVCall_Handler does this would sort the problem for now. Do you agree?
Otherwise, if I can't modify the hypervisor but can trigger another ISR by setting a bit on the NVIC, and then implement that ISR_Handler to pop that exception stack frame from the stack this would also work, right? What about the priority for this ISR? As far as I can see any priority would work... What do you think ?
-nestor
Yes, I will start a new discussion thread to solicit comments about the planned features for the "extended" kernel (QXK).
Regarding the elimination of
SVC_Handlerfrom the existing QK port, there is no need to improvise. An implementation without the SVC is already available and is working in the lab. The code is undergoing testing and so far has passed all the preemption tests that I could think of. The code will be released very soon as QP/C 5.5.2-beta. This release will contain the updated QK port to ARM Cortex-M for all supported complers: ARM-Keil, GNU-ARM, IAR EWARM, and TI-CCS-ARM.All the changes for the new ARM Cortex-M QK port are confined to the port and applications are not affected at all (except that
SVC_Handleris not used anymore.)--MMS
Last edit: Quantum Leaps 2015-11-12
Thanks!
-nestor
Hi Miro,
Can you please give a brief description of how the QK Cortex-M port preemption and context switching works without using SVCall since v5.6.0? Is there any performace difference to previous versions?
The recent QK ports to ARM Cortex-M work as follows:
QK_ISR_EXIT()macro (which must be called before exiting every "kernel-aware" ISR) calls the functionQK_schedPrio_()to find out the highest-priority AO ready to run. The function returns 0 if there is no such AO of priority higher than the current priority. When the function returns non-zero (meaning that there is a new highest-priority AO to run), this priority is saved in theQK_nextPrio_static variable to be used later and the PendSV exception is triggered. Otherwise, the ISR simply returns to the preempted context.NOTE: Previously, the
QK_ISR_EXIT()macro always triggered the PendSV exception, which had to find the highest-priorty AO and do the simple return if such AO was not found.The PendSV exception starts off with inspecting the
QK_nextPrio_variable. If this variable is non-zero, then it indicates that the QK scheduler needs to be called to perform the asynchronous preemption. Please note thatQK_nextPrio_cannot be zero when the PendSV is triggered from an ISR.After the QK scheduler returns, the variable
QK_nextPrio_is set to zero and the PendSV is called again to pefrom the interrupt-return to the original context.NOTE: Previously, PendSV triggered the SVCall exception to return to the original context. Now, SVCall is NOT used.
QK_nextPrio_turns out to be zero, PendSV removes its own stack frame from the stack and returns to the preempted context.NOTE: Previously, this return to the previous context was done in the SVCall exception, but now it is peformed in the other branch of the PendSV exception. Taking this extra branch does not incurr much cost, because the variable
QK_nextPrio_needs to be loaded into a register anyway, so a branch costs ony a test against zero.Regarding the performance difference between the previous and current QK port to Cortex-M, it depends a bit on the pattern of use.
If most of your interrupts lead to context switch (because they activate a higher-priority AO), then the previous implementation was slightly more efficient. If significant number of ISR return to the original conext without asynchronous preemption, then the new implementation is more efficient.
But, to put things in perspective, the differences are only a few machine instructions, so are completely in the noise.
--MMS
Miro,
Thanks for taking the time to provide such a clear and complete description. I know that the Cortex M QK / scheduler code has undergone a lot of changes, and you always update the App Note pdf with the current description of the behavior. Much different than what was originally documented in PSiCC2!
And who can forget that epic 50+ post thread on Embedded Gurus ("What's the State of your Cortex?" - http://embeddedgurus.com/state-space/2011/09/whats-the-state-of-your-cortex/) with Paul Kimelman weighing in.