Reply by Boudewijn Dijkstra●December 13, 20052005-12-13
"Grant Edwards" <grante@visi.com> schreef in bericht
news:11prm11anj8k82c@corp.supernews.com...
> On 2005-12-12, #define <u4karsh@gmail.com> wrote:
>
>> Now no there is tick interrupt... still context is switched...
>> How?
>
> 1) In many (most, in my experience) cases the event that made
> the higher priority task runnable was caused by an interrupt
> (e.g. I/O device or hardware timer). In that case, the
> context switch is done at the end of the ISR.
Unless the OS uses interrupt processes, in which case the context switch is
done at the beginning of the ISR. And again at the end.
Reply by Thad Smith●December 13, 20052005-12-13
Grant Edwards wrote:
> On 2005-12-12, #define <u4karsh@gmail.com> wrote:
>>Now no there is tick interrupt... still context is switched...
>>How?
>
>
> 1) In many (most, in my experience) cases the event that made
> the higher priority task runnable was caused by an interrupt
> (e.g. I/O device or hardware timer). In that case, the
> context switch is done at the end of the ISR.
Yes. To expand a little bit, usually when servicing an interrupt, you
execute common interrupt entry and exit code. This would typically
track the number of nested interrupts. When the exit routine determines
that it is ready to return to task (non-interrupt) code, it checks to
see if the suspended task is still active (normally a flag). If so, it
simply returns to it. Otherwise, it would save the context of the
current task and restore the context of the newly activated task and
start it.
--
Thad
Reply by Grant Edwards●December 12, 20052005-12-12
On 2005-12-12, #define <u4karsh@gmail.com> wrote:
> Let's say "some" event has happened and a HIGHER priority is
> READY.
OK, buth there's no need to SHOUT. ;)
> Now a Lower priority thread (in middle of its time slice)
RTOSes don't usually use time-slices. A few have time-slicing
as an optional feature, but it's often considered "bad
practice" to resort to time slicing.
> will still not be able to continue. (Thats what shoud happen
> right!)
Right.
> Now no there is tick interrupt... still context is switched...
> How?
1) In many (most, in my experience) cases the event that made
the higher priority task runnable was caused by an interrupt
(e.g. I/O device or hardware timer). In that case, the
context switch is done at the end of the ISR.
2) If a context switch really does need to be trigger from a
user task, all of the processors I've ever used have a
software interrupt mechanism.
--
Grant Edwards grante Yow! YOU PICKED KARL
at MALDEN'S NOSE!!
visi.com
Reply by Richard●December 12, 20052005-12-12
> Where does the RTOS saves the PC (Program Counter). Is it on the stack
> of the thread (Then how PC is pushed (i guess only CALL instruction has
> that power), or can PC be treated as any other register especially in
> 32bit RISC uC and pushed on stack)?
This depends on the processor architecture, but it is normal for the PC to
automatically get stored on the stack when context switching - just as with
any other function (or interrupt) call. Entering the function with a branch
instruction will normally automatically store the PC + offset as the return
address on the stack. Exiting the function with some form or return
instruction will normally automatically retrieve the return address from the
stack and load it into the PC.
Take a look at the second section of
http://www.freertos.org/implementation/. There is a detailed example.
Regards,
Richard.
http://www.FreeRTOS.org
Reply by #define●December 12, 20052005-12-12
Let's say "some" event has happened and a HIGHER priority is READY.
Now a Lower priority thread (in middle of its time slice) will still
not be able to continue. (Thats what shoud happen right!)
Now no there is tick interrupt...still context is switched...How?
Regards,
#define
Reply by Grant Edwards●December 12, 20052005-12-12
On 2005-12-12, #define <u4karsh@gmail.com> wrote:
> Where does the RTOS saves the PC (Program Counter). Is it on the stack
> of the thread
Usually.
> (Then how PC is pushed (i guess only CALL instruction has that
> power),
Most RTOSes (at least the ones I've seen the insides of) do
their context switching from an interrupt service routine, so
the processors interrupt mechanism does the "push".
> or can PC be treated as any other register especially in 32bit
> RISC uC and pushed on stack)?
Depends on the processor. Sometimes it can.
> Then, how does the contents of PC changed by RTOS once it is
> done restoring (popping) registers etc. again there is no such
> thing as POP PC !!!!
Depends on the processor. Sometimes there is.
> (RET and JMP A+@DPTR come to mind)
Usually you switch the stack pointer over to point to the stack
of the new thread and then do a "return from interrupt".
--
Grant Edwards grante Yow! I HAVE a towel.
at
visi.com
Reply by #define●December 12, 20052005-12-12
Hello,
I have one basic doubt about how context switching work in RTOS.
Where does the RTOS saves the PC (Program Counter). Is it on the stack
of the thread (Then how PC is pushed (i guess only CALL instruction has
that power), or can PC be treated as any other register especially in
32bit RISC uC and pushed on stack)?
Then, how does the contents of PC changed by RTOS once it is done
restoring (popping) registers etc.
again there is no such thing as POP PC !!!! (RET and JMP A+@DPTR come
to mind)
Anybody????? Helppppp me.
Regards,
#define