We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,
i am starting to work with RL-ARM for CortexM3, and i have checking the manual. I miss more info about the context switch in CortexM3 using the RL-ARM. Another operating systems use the PendSVHandler() exception that executes after the last nested ISR to do the context switch. Pls. could someone clarify me how it is it done in RL-ARM, and where is located the code that does it?
Many thanks Alberto
I too am interested in this question.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
RL-RTX for Cortex-M3 uses PendSV_Handler, SysTick_Handler and SVC_Handler for the context switch. All 3 are a part of the OS Extension in Cortex-M core, so it is optimal to use all 3 of them, not just one.
For an explicit task switch (on os_tsk_pass, os_evt_wait, etc.) the SVC_Handler is used. This is because all RTX system code is executed in SVC mode.
On timeout, the SysTick_Handler is used for the context switch (when a task delay has expired, etc.). RTX for Cortex-M3 uses SysTick timer to generate RTX ticks.
On asynchronous events (isr function calls from interrupt handlers), a PendSV_Handler is used for the context switch.
Thanks Frank!!.
I have been checking the RL-ARM source code and i see (if i am not wrong) in the task level, that the OS_dispatch function start the scheduling,then calls the OS_switch_tasks function to do the context switch.
I have some doubts about the ISR level scheduler. When you have nested interrupts, you can do several posts in some of these ISRs. Do you know which is the function used to do the scheduling in the ISR level after the last nested INT? I suppose that this scheduling function should trigger the PendSv exception, and then the PendSVHandler should do the context switch. Could you be so kind to clarify it to me?, Is there any example where i can check it?
Many thanks in advance Alberto
Of course you can. That is why you have ISR FIFO Queue size configuration option in the RTX_Config.c file. Nested isr functions store requests into this fifo. The FIFO is processed later, when all of the interrupts are done. This processing is done in the PendSV_Handler.
Default setting for ISR FIFO Queue size is 16. This means that the nested interrupts can call isr 16 times, before the events get lost. However the FIFO overflow is trapped in an error function.
Thanks!!, do you know where i can get an example to study it?