SX48 single context switch
Peter Verkaik
Posts: 3,956
Hi,
I appended a program to perform a single context switch using the secret instructions.
My goal is to have a single userdefined interrupt routine, that executes outside the isr.
Several issues:
1)
I save register M manually but since the context switch is done inside the isr (the real isr via rtcc)
M gets restored to whatever value it had upon entering the isr. How to restore M to
its value before running the misr (mainlevel interrupt)
2)
Upon finishing the misr (which runs as mainlevel code outside isr) I await the next
rtcc interrupt before returning to the normal mainlevel code. Is it possible to do
a context switch outside isr that will never be interrupted by an rtcc interrupt.
This to avoid the wait.
3)
I use bank0 to save registers and skipped the first 4 bytes as these are used by SX/B.
The others are not as far as I know. Please tell me if these are·used and for what purpose.
regards peter
I appended a program to perform a single context switch using the secret instructions.
My goal is to have a single userdefined interrupt routine, that executes outside the isr.
Several issues:
1)
I save register M manually but since the context switch is done inside the isr (the real isr via rtcc)
M gets restored to whatever value it had upon entering the isr. How to restore M to
its value before running the misr (mainlevel interrupt)
2)
Upon finishing the misr (which runs as mainlevel code outside isr) I await the next
rtcc interrupt before returning to the normal mainlevel code. Is it possible to do
a context switch outside isr that will never be interrupted by an rtcc interrupt.
This to avoid the wait.
3)
I use bank0 to save registers and skipped the first 4 bytes as these are used by SX/B.
The others are not as far as I know. Please tell me if these are·used and for what purpose.
regards peter
Comments
It takes a little doing figuring out what you're up to.
My comments are:
1) In the SX48 M is saved/restored on entering/exiting the ISR. Not so with the SX20/28.
How to get around that, I'm not sure.
2) You can context switch any time; inside the ISR or in the mainline. To eliminate the wait, why not simply test the size of the RTCC register to see how close to an interrupt you are, and then decide to wait for that, or force a switch.
3) Can't help you here.... this is Bean's turf.
Some other points.....
Are the register saves (PUSHes after the POPs) in "runMisr" not redundant ? Perhaps I don't understand and need to study what you are doing some more.
You need to deal with the issue of making a context switch when the interrupted code was in the middle of a "skip" instruction. Messing with the STATUS register during such an occurrence will cause you to drop the skip on returning. (Took a LONG time to figure that out because it usually happens so infrequently)
There is also the issue of dealing with the SX's internal interrupt flag... context switching/returning can mess that up, forever keeping your interrupts off (or on, I can't recall for sure).
Caveat: these additional points are for the SX20/28; and probably the SX48, but I have not tested that because of your point number 1).
Looks like you're having fun though!
Cheers,
Peter (pjv)
I found the solution for 1).
Since the misr executes outside the isr, I just need to save M at the start of
mainlevelInterrupt and restore it at the end of mainlevelInterrupt. This works,
because at the start of mainlevelInterrupt, m has the value it had before rtcc interrupt.
I think the pop/push construct is necessary to save the current mainlevel code
register values into bank0. If it is time to run misr, upon isr exit the mainlevelInterrupt routine
is executed which may be interrupted itself, but then the isr knows the misr is running and then
these registers are not saved to bank0. Once mainlevelInterrupt is done, the context switch
reloads the values that are stored in bank0.
I added code to check rtcc and force a context switch if there are enough cycles
left before the next rtcc interrupt.
How do I deal·with the issue of making a context switch when the interrupted code was
in the middle of a "skip" instruction?
regards peter
Post Edited (Peter Verkaik) : 2/24/2007 12:01:42 AM GMT
The skip flag is shadowed in the STATUS byte bit 3 (power down), and the forced interrupt is in bit 4 (time out).
Do separate RETIs after PUSHing those into the STATUS set and cleared to follow what their inpact is. Pretty trickey I say!
Have fun.
Peter (pjv)
SX/B uses the first available 5 bytes in bank zero (__PARAM1-4, __PARAMCNT).
It also uses the last available bytes in the last bank to save/restore (__PARAM1-4, __PARAMCNT, and other registers) when an interrupt occurs.
If you can use any bank I would suggest the 2nd available bank (SX/B uses bank 0 and the next bank for it's "normal" variables), then you can just declare an array to reserve the space.
"CONSWITCH VAR BYTE (10)" just make sure it is the very first array declared.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
·
I moved the variables to rambank2 so not to conflict with sx/b.
I adjust the shadowed interruptbit and skipbit as follows (which I think is correct):
When the mainlevelInterrupt routine must execute, I clear the shadowed skipbit but
leave the shadowed interrupt bit, because we will enter the mainlevelInterrupt routine
at the start of an instruction, coming from the isr.
When exiting the mainlevelInterrupt routine from outside the isr, I clear the shadowed
interrupt bit but leave the shadowed skipbit, because we return to the mainloop,
that may have been interrupted in the middle of a skip instruction.
When exiting the mainlevelInterrupt routine from inside the isr, or when the mainlevelInterrupt
routine itself is interrupted, I leave both the shadowed interrruptbit and the shadowed skipbit intact.
regards peter
I have not confirmed that what you are doing is consistent with the recollection of my experience, but it looks like you're on your way!
Cheers,
Peter (pjv)