Reading jyiu book on Cortex-M4 and general information about usage of PendSV exception type.
One application highlighted is of context switching in the RTOS wherein on a Systick timer interrupt, instead of context switching, it will set the PendSV bit. This will then execute the context switching at the lowest priority after all other interrupts have been handled. Again this is because the priority of PendSV will be kept the lowest.
However, is the same not possible if we just lower down the priority of Systick timer exception? In that case, if any interrupt is active, the systick timer exception handler will get executed after all other interrupts are done with.
If that is possible, then what is the major benefit in using PendSV?
Am I missing something?
Hello Gopal,
my understanding of PendSV is it is a sort of the asynchronous trap.
The word of the asynchronous means the trap does not occur immediately for the request and it will be pending until an appropriate time.
Although I have not read the Mr. Joseph Yiu's book, I think the example would say that the SysTick interrupt requested the context switch but the context switch should be postponed until all other interrupt requests would be handled.
Anyway, Mr. Joseph Yiu will give us clear answer.
Best regards,
Yasuhiko Koumoto.
Thank you yasuhikokoumoto
Yes that is correct that it is kind of asynchronous trap/exception. But I wonder the same purpose may be achieved using low priority Systick. Or there may be some more uses of the pendsv which I have not understood.
There is another example for non-OS based systems like you can split a long running ISR in two parts. First you execute the high priority work in the main ISR and then rest of the low priority work can be postponed to PendSV handler. This makes sense.
You could achieve something similar by setting the priority of Systick to be very low. But there is a danger in that. The system tick timer is usually one of the most important events in the system and needs servicing with short latency as much of the functionality of the system will depend on it (context switches, task scheduling, watchdogs etc). If you set the priority very low then its latency will inevitably increase as it will have to wait for all other interrupts to be serviced before it is handled. But, for something like a context switch, the important thing is to capture that a context switch needs to occur, the context switch itself can usually wait for other urgent tasks to complete. This is what PendSV allows you to do - the Systick timer can be set to have high priority so it is serviced with very low latency and then time-consuming operations (like a context switch) can be pended to occur later.
I hope that makes sense.
Chris
A key question is, with all the other interrupts going on in a system with RTOS, is it possible that the SysTick exception get blocked out for over 1 tick?
If the OS tick timer (can be SysTick or other timer) is set to lowest priority, and when there are lots of other interrupt services happening, a SysTick exception can be missed, and therefore affect task scheduling as most OS use the OS tick timer to control task scheduling. For example, a certain task X is scheduled to take place in 100 ticks time, and if the system can miss OS ticks occasionally, then it means the task X will not get executed on time. Of course, there are other ways to implement task scheduling in other ways. An OS can use additional peripheral timers with higher interrupt priority for such purpose.
Thank you Chris. That is good explanation. Basically since Systick can be used for other purpose as well in addition to the context switching, it makes sense not to disturb the execution times of those things done in Systick.
Thank you Joseph. Understand now the logic.
I have another question on SVC. Will add another thread.
But isn't the priority of the systick timer unconfigurable? The manuals say that it is configured with a static priority -3(Highest).
SysTick exception's priority level is programmable. Could you let me know which document said it is fixed? It might be a documentation error. Thanks
Joseph