Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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

List of 17 messages in thread
TopicAuthorDate
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      

Back to Subject List