Pumpkin, Inc.

Pumpkin User Forums

Determining what registers and variables must be saved by ISR

For issues specific to Microchip's PICmicro® MCUs, including compilers (e.g. HI-TECH PICC & PICC-18, Microchip MPLAB®-C18) and IDEs (e.g. Microchip MPLAB®).

Determining what registers and variables must be saved by ISR

Postby dfleck » Wed May 15, 2002 9:35 am

I am using the HI-TECH PICC18 compiler and slp800aa.lib. When I call a Salvo function (OSTimer, OSSignalBinSem, ...) from the ISR the compiler assumes worst case because it can't "see" these functions and saves all registers and btemp variables. So how can I determine what registers and btemp variables are used, so I can use the '#pragma regsused' to limit what the ISR saves? I used the HI-TECH librarian to 'list modules with symbols', and it seems to show what btemp variables are used in each module. But it doesn't list the registers. If I temporarily included timer.c in my project so the compiler would produce timer.obj and timer.lst, would this timer.obj be identical to the one in the library? Or would I have to make sure my salvocfg.h was EXACTLY the same as the salvocfg.h used to generate the library? Is there any way to do what I want to do without resorting to a source code build?

------------------
Donald A. Fleck

Donald A. Fleck
dfleck
 
Posts: 28
Joined: Sun May 12, 2002 11:00 pm
Location: Breinigsville, PA, USA

Re: Determining what registers and variables must be saved by ISR

Postby aek » Wed May 15, 2002 10:09 am

Hi Donald.

I don't think there's a reliable way to do this without resorting to a source-code build and examining the functions in question.

In-lining OSTimer() and OSSched() will resolve the registers used issue for those two functions, but then calling OSSignalBinSem() from an ISR gets you back to the "compiler assumes the worst case" situation with a full set of saved registers.

My worry about trying to deduce what is being used in the library is that even if you got it right now, a future release of PICC-18 might do things differently, and then things would be broken. So I don't feel comfortable with that approach.

I suspect that it's really only the btemps that need to be #pragma regused, as the standard registers (e.g. WREG, FSRn, etc.) are probably being saved by default anyway for a dummy ISR.

quote:
If I temporarily included timer.c in my project so the compiler would produce timer.obj and timer.lst, would this timer.obj be identical to the one in the library?
Yes, assuming you're using the same version of the compiler that was used to generate the library. That becomes a big IF when Pumpkin or you upgrade to a new version of PICC-18 ... But by inlining OSTimer() (and/or OSSched()), you get around that problem. Don't even try to create a (large) salvocfg.h that matches the one used to generate the library -- instead, use the salvocfg.h for use with library builds -- it uses salvolib.h to end up with the right "effective" salvocfg.h.

Here's an idea -- I haven't tried it yet, but it ought to work. Without changing your salvocfg.h, and in a library build, #include timer.c, sched.c, binsem.c, binsem2.c and event.c in your isr.c (the file that has your ISR in it). IOW, create a large source file that has all of the code that will be called from the ISR. Note that this is not the same as a simple source-code build with timer.c, binsem.c, isr.c nodes ... By having your isr.c include those files, the compiler will be able to come up with the minimum set of saved registers, and you'll end up with a relatively small context save and restore in the ISR.

How many registers and btemps are currently being saved? Is it that bad?

One more idea -- an alternative to signaling from within an ISR is to create your own flag bit that you set in the ISR. You then test-and-clear this bit (with interrupts disabled) in your main()'s infinite loop, just before calling OSSched(). If the bit is set, you then call OSSignalBinSem(). This is at the background level (the ISR is at the foreground level). This works pretty well, since OSSched() comes after OSSignalBinSem(), and in many low-performance applications the overall system behavior will look the same. But it has its drawbacks -- i), you're always polling that bit (or bits, if you do more than one of these), and ii) the order in which events occur is now all messed up, as it's based on what order you poll your bit(s) in, not when the interrupt(s) actually happen. But if the PIC18's interrupt-save and restore is going to break you, then this is a viable alternative.

Regards,

------------------

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Determining what registers and variables must be saved by ISR

Postby dfleck » Wed May 15, 2002 10:28 am

Thanks for the suggestions.

When the compiler can see OSTimer it saves 7 bytes, when it can't it saves 31 bytes. A big increase, but for now we'll accept it and fix it only if it becomes a problem.

------------------
Donald A. Fleck

Donald A. Fleck
dfleck
 
Posts: 28
Joined: Sun May 12, 2002 11:00 pm
Location: Breinigsville, PA, USA


Return to PICmicro MCUs

Who is online

Users browsing this forum: No registered users and 1 guest

cron