| ??? 05/14/06 11:38 Read: times |
#116178 - interrupt table copy |
Hello,
I'm currently working on writing my own monitor and debugger for my PHYtec microMODUL-8051 with Oki 80c154s controller. I have 64K of FLASH and 32K SRAM as XRAM. At reset I have a standard Harvard architecture memory map for my Flash memory but I can switch over to von-Neumann architecture via some memory mapped I/O functions. Everything is working fine so far.... At boot I have code space from 0000h to FFFFh in Flash memory while I have Flash only from 8000h to ffffh after the switch over. Now I did setup my interrupt vectors in Flash memory starting at a000h and I want to copy them to my XRAM which will double as code space from 0000h to 7fffh in my monitor. The idea is to install the vectors in RAM so that a) my user code can alter them at ease b) they are properly initialized now that I can't access 0000h to 7fffh on Flash anymore Currently I'm using a routine like this:
mytable CODE 0A000h
resetv XDATA 0000h
...
mov r0,#026h ; bytes to copy 26h-1
mov r1,#025h ; lower byte of destination address
mov dptr,#mytable ; DPTR points into my Flash
copyloop:
mov A,r0 ; load offset into my original table
movc A,@A+dptr ; get byte from code space
mov P2,#(resetv SHR 8) ; set upper byte of reset vector to the XRAM bus
movx @r1,A ; lower byte on bus = offset - write the byte from CODE space there
dec r1 ; decrement destination pointer
djnz r0,copyloop ; loop for all bytes in charge
Is there a chance to optimize this more? Any comments and suggestions welcome! thanks, Matthias |
| Topic | Author | Date |
| interrupt table copy | 01/01/70 00:00 | |
| optimisation | 01/01/70 00:00 | |
| yes i had that in mind but... | 01/01/70 00:00 | |
| No P2 worries | 01/01/70 00:00 | |
| thanks for making this clear! | 01/01/70 00:00 | |
| single chip solutions | 01/01/70 00:00 | |
| Ofcourse | 01/01/70 00:00 | |
| Why does it need optimising? | 01/01/70 00:00 | |
| Not necessarily! | 01/01/70 00:00 | |
| are you sure this is OK? | 01/01/70 00:00 | |
| THANKS! | 01/01/70 00:00 | |
| >256 byte long table | 01/01/70 00:00 | |
| I'll give it a go... | 01/01/70 00:00 | |
| worked! | 01/01/70 00:00 | |
| Re: >256 byte long table | 01/01/70 00:00 | |
| not quite this issue | 01/01/70 00:00 | |
issue resolved | 01/01/70 00:00 |



