How do I perform a long jump to a numerical address from my C code? I'm pretty sure I have to do this with inline assembly - however that seems complicated for C51. I figured in C I could do this:
typedef void (*jmpPtr)(void); jmpPtr jmp; ... unsigned int address = 0x4000U; jmp = (jmpPtr) address; (*jmp)();
OK, I refuse to be stumped (yet). How about implementing jump-like functionality by pushing a return address on the stack and returning to it? This should be achievable in C thusly:
unsigned int address = 0x4000U; unsigned char idata *p; p = SP; SP += 2; p[0] = address & 0xFF; p[1] = address >> 8; return;
Oops. I forgot about a nuance of 8051 stack pointer operation. Change:
p = SP;
p = SP + 1;
unsigned int address = 0x4000U; unsigned char idata *p; p = SP; SP += 2; p[0] = address & 0xFF; p[1] = address >> 8;
unsigned char data *p;
Huh? The difference between IDATA (0x80-0xFF) and DATA (0x00-0x7F) is that IDATA is only accessible through SP, R0, and R1. DATA is accessible through SP, R0, R1, and using direct addressing. What you're suggesting is that R0 can't access DATA space, and we know that's not right (e.g., STARTUP.A51 uses exactly that technique to clear DATA, as well as IDATA). My followup has nothing to do with endianness. My byte ordering is correct. It has to do with the SP's pre-increment behavior. For example, reset initializes SP to 0x07 (&RB0/R7) the first LCALL writes the return address addresses 0x08-9. Now, I'll admit, that my approach may very well *not* work, but I don't think it will be for the reasons you give. I've not tried it, since I'm not at my development system, but I intend to later. Then when it doesn't work I'll tell everone why and take the heat for my lame suggestion :-> --Dan Henry
What you're suggesting is that R0 can't access DATA space, and we know that's not right (e.g., STARTUP.A51 uses exactly that technique to clear DATA, as well as IDATA). Actually, we're both right. Using R0 as an indirection register startup.a51 clears out the entire IDATA space from 0x00 to 0xFF (on 8052's). Note that the IDATA space overlap's the DATA space. The I stands for Indirect, thus, whenever you Indirect through R0 or R1 you are by definition in IDATA. Your byte ordering was correct, I didn't say otherwise. The 8051 is little-endian for 16-bit values. Regards, - Mark
Thanks Dan, I've used the same type of thing with the pentium. Thanks for reminding me about that. Can you post the code for fixing up the stack from inside an interrupt handler?
Gee, and just when things were looking easy... Well, I can give it a shot. It obviously depends on whether the straight-forward version already posted will work first. Since you are probably following all of this thread, you know that Mark says it won't work, and since I haven't tried it yet, I can't say whether he's right. But, in case it does work, can you provide us with some more information? I take it that you'll be performing this "jump" from within an ISR, right? Upon entry, ISR has pushed some processor context on the stack and possibly even switched register banks. What kind of "fixing up" is required? We need to know what, if any (and hopefully none), of the saved processor context needs to be preserved across the jump. Are you jumping from interrupt context to interrupt or non-interrupt context? Or is it more like a software reset to a dynamic address? You're still wanting all this done in C, right? --Dan Henry
Actually, I was trying to do all this in C so I wouldn't have to figure out how to do 'inline' assembly from C. However, it may just be easier to do the assembly. What I am doing is caputring an interrupt and passing it on to another interrupt handler. So it would be interrupt handler to interrupt handler. Now that I think about it I suppose I would have to fix up the stack regardless, otherwise I'll crash... Any help would be appreciated of course.
Your needing an ISR-to-ISR jump complicates things a bit. Conceptually, the "jump using RET" is still do-able, but a C interrupt function returns using RETI instruction to restore the interrupt priority logic and that's (probably) not desireable at that point in servicing the interrupt. There's also the issue of differences in saved processor context needs between ISR functions. Maybe I've fallen victim to some form of limited thinking, but to reliably do what you want requires a bit of assembler, I think. Keil doesn't support inline assembly in the way we both probably understand the term, so I'm providing a short assembly language excerpt to show how I'd dynamically re-vector an interrupt. The idea is to provide a fixed ISR front-end that will "jump" through an address you provide in a global. That address is the dynamic address of your C interrupt function, which has presumably been relocated in flash. Since you want some ISR front-end code, you have to disable the compiler's automatic vector generation by using the NOINTVECTOR compiler option and write your own interrupt vectoring code. The following is a snippet for that assembler file (say, intvects.a51). I have tested this code and know it to work.
EXTRN DATA (Ext0_Addr) EXTRN DATA (Tmr0_Addr) CSEG AT 00003H Ext0_IntVector: ;** Calling the revector function pushes a ;* return address that will be overwritten ;* by the target ISR's address. ;** LCALL Ext0_Revector ; Never returning to here! CSEG AT 0000BH Timer0_IntVector: LCALL Timer0_Revector ; Never returning to here! ;** ==MORE VECTOR CODE SNIPPED== Ext0_Revector: USING 0 PUSH AR0 ; Save MOV R0,SP ; &Saved_R0 DEC R0 ; &RET_ADDR_MSB MOV @R0,Ext0_Addr ; Target ISR's addr MSB DEC R0 ; &RET_ADDR_LSB MOV @R0,Ext0_Addr+1 ; Target ISR's addr LSB POP AR0 ; Restore RET ; "Jump" to target ISR ; ..and RETI from there. Timer0_Revector: USING 0 PUSH AR0 ; Save MOV R0,SP ; &Saved_R0 DEC R0 ; &RET_ADDR_MSB MOV @R0,Tmr0_Addr ; Target ISR's addr MSB DEC R0 ; &RET_ADDR_LSB MOV @R0,Tmr0_Addr+1 ; Target ISR's addr LSB POP AR0 ; Restore RET ; "Jump" to target ISR ; ..and RETI from there. ;** ==MORE RE-VECTOR CODE SNIPPED== END
I've tested the following code and verified that it works as advertised.
unsigned address; void JumpedTo( void ) { while (1) ; } void main( void ) { unsigned char idata *p; /* Set stack pointer to 0x7E, forcing the * "pushed" address to straddle the data/idata * boundary at 0x80. NOTE: Only for 8052 * derivatives. */ SP = 0x7E; address = JumpedTo; p = SP + 1; SP += 2; p[0] = address & 0xFF; p[1] = address >> 8; return; }
I've tested the following code and verified that it works as advertised.<br> <br>
Let's try that again. Dan, you have inspired me. Here's my "Jump to an absolute address" that I hope solves the "jump from C" issue.
// 'r_' prefix denotes a CPU 'r'egister. sfr r_stackPointer = 0x81; void main(void) { // Point so that this will work for 8051's and 52's. unsigned char data *p = 0x7E; // Little endian, LSB in lower address, MSB in higher address. *p = 0x00; // LSB of address 0x4000. ++p; *p = 0x40; // MSB of address 0x4000; // Now fool the CPU (this is the magic part). r_stackPointer = 0x7F; // "Jump via return" return; }