Shadow Registers ??
DWinchell
Posts: 60
I am intrested in doing some real time premptive Multi-Tasking using the RTCC and the four pages inthe SX chip. Is there any to see what's in the stack to get and /or change the Program counter ?? The SX docs indicate that the running task is pushed into "Shadow Registers" when servicing interrupts. I can't find any way to look at the stack or these shadow registers.·Are the 8·stack registers memory mapped to accessable bank registers ??
6.1.2 Subroutine Stack
The subroutine stack consists of eight 11-bit save registers.
A physical transfer of register contents from the program
counter to the stack or vice versa, and within the
stack, occurs on all operations affecting the stack, primarily
calls and returns. The stack is physically and logically
separate from data RAM. The program cannot read or
write the stack.
Upon return from the interrupt service routine, the contents
of PC, FSR, STATUS, and W registers are restored
from their corresponding shadow registers. The interrupt
service routine should end with instructions such as RETI
and RETIW. RETI pops the interrupt stack and the special
shadow registers used for storing W, STATUS, and
FSR (preserved during interrupt handling). RETIW
behaves like RETI but also adds W to RTC.
Is there another approach to Multi-Tasking ??
6.1.2 Subroutine Stack
The subroutine stack consists of eight 11-bit save registers.
A physical transfer of register contents from the program
counter to the stack or vice versa, and within the
stack, occurs on all operations affecting the stack, primarily
calls and returns. The stack is physically and logically
separate from data RAM. The program cannot read or
write the stack.
Upon return from the interrupt service routine, the contents
of PC, FSR, STATUS, and W registers are restored
from their corresponding shadow registers. The interrupt
service routine should end with instructions such as RETI
and RETIW. RETI pops the interrupt stack and the special
shadow registers used for storing W, STATUS, and
FSR (preserved during interrupt handling). RETIW
behaves like RETI but also adds W to RTC.
Is there another approach to Multi-Tasking ??
Comments
the stack memory and the shadow registers are not memory mapped, i.e. you cannot directly read from or write to these registers. The handling of pushing the current PC on the stack, and saving the most important registers to the shadow registers on an interrupt, and restoring these registers on a RETI, or RETIW instruction is fully transparent to the application.
Using shadow registers was a clever idea of the SX designers because this makes it unnecessary to "manually" save these registers at the entry point of the ISR, and restoring them before a return from an interrupt like it is required with other controllers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Post Edited (Stephen) : 10/18/2004 6:22:38 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
http://users.senet.com.au/~akouz/main.html
It shows a program pic_rrr (round robin rtos for pic16)
If you download the package and read the files
readme.txt and pic_rrr.asm and macro.asm
you see how it is done for the pic. Macro's !
This should be portable to sx without too much effort.
Not quite pre-emptive, but you can return control to the kernel
to mimic·pre-emptive behaviour. (eg. all tasks run predefined time slices)
regards peter
explanations and source code.
http://www.eetkorea.com/ARTICLES/2000JUN/2000JUN06_CT_AN3.PDF
regards peter
http://www.sxlist.com/cgi-bin/mpasm2sasm2.exe
to convert from MPASM to SASM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
I did run across something interesting when I put to much code in the last Code page ( $600-$7FF ) The error message reads: "THE LAST 136 BYTES ARE RESURVED FOR THE DEBUGGER" Not sure if 136 was the real number or not. I was actually to busy to think about this until latter. Now let's see if we extracted the code in this space, disassembled it, I bet we would have a debugger :-) Let's see I bet the break point jumps to this address :-) AND THE BEAT GOES ON :-) This machine just seems to get better all the time :-)
Thank You
David Winchell
Personally, I don't know if the new instructions (or the old) will let you disassemble the code used to communicate with the SXKey. Chip Gracey is the person who wrote this software originally (and designed the key and wrote the software for it as well), and after having worked with it for a few years now, I am ever more aware of how much work he had to put into it. If you try it, I wish you lots of luck and all the long hours you feel like putting into it. Of course, you could simplify your life and just use the existing software that works right now...
hanks, PeterM
Paul