??? 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 |