Forums

PIC mplab c18 C compiler

Started by darkknight December 16, 2005

Hi

A colleague of mine is using MPLAB C compiler and is struggling with the
saving of registers in ISRs.  Apparently the compiler manual says you
have to manually scan the assembler code generated by the compiler to
work out what registers to save/restore in interrupt routines.  His
software is crashing and he appears to be struggling to solve the
problem.

Does anyone have any experience with this C compiler?

Is there an easy way to determine what registers to save?

Are there any more reliable C compilers for the PIC micro than MPLAB?

Is the PIC micro tricky to use with lots of gotchas?

TIA


Forgot to mention that it's the C18 C compiler but I can't remember the
chip name except that it's 16K or 32K ROM and I think it has "18" in
it's name.





On Fri, 16 Dec 2005 21:03:55 +1300, darkknight wrote:

> > >Hi > >A colleague of mine is using MPLAB C compiler and is struggling with the >saving of registers in ISRs. Apparently the compiler manual says you >have to manually scan the assembler code generated by the compiler to >work out what registers to save/restore in interrupt routines. His >software is crashing and he appears to be struggling to solve the >problem. > >Does anyone have any experience with this C compiler? > >Is there an easy way to determine what registers to save? > >Are there any more reliable C compilers for the PIC micro than MPLAB? > >Is the PIC micro tricky to use with lots of gotchas? > >TIA
darkknight wrote:
> Hi > > A colleague of mine is using MPLAB C compiler and is struggling with the > saving of registers in ISRs. Apparently the compiler manual says you > have to manually scan the assembler code generated by the compiler to > work out what registers to save/restore in interrupt routines. His > software is crashing and he appears to be struggling to solve the > problem.
This hasn't been necessary in my experience with PIC18 C and I do not recall that passage in the compiler manual unless it's an obscure case (I would check this myself, but I don't have the compiler documentation with me). Perhaps behaviour differs between models, but on the PIC18 variants I've used, the microcontroller takes care of most state on ISR entry and exit. Check the datasheet for the part in question.
> > Does anyone have any experience with this C compiler? > Is there an easy way to determine what registers to save? > Are there any more reliable C compilers for the PIC micro than MPLAB?
If your colleague can actually narrow his problems down to the compiler, that can be a valid question, but probably only answered by direct evaluation. I had few, if any problems with the Microchip C18, as long as one understands the tradeoffs in code generation. Some constructs are simply inefficient since the instruction set is definitely not a good fit for HLLs (Extended mode on some models addresses certain shortcomings).
> > Is the PIC micro tricky to use with lots of gotchas?
Sort of - but nothing that a very thorough reading of the data sheet won't resolve. The documentation is dense but generally complete and accurate. --T
> > TIA
A colleague of mine is using MPLAB C compiler and is struggling with the
> saving of registers in ISRs. Apparently the compiler manual says you > have to manually scan the assembler code generated by the compiler to > work out what registers to save/restore in interrupt routines. His > software is crashing and he appears to be struggling to solve the > problem. > > Does anyone have any experience with this C compiler? > > Is there an easy way to determine what registers to save? > > Are there any more reliable C compilers for the PIC micro than MPLAB? > > Is the PIC micro tricky to use with lots of gotchas?
Ahhh. That old chestnut!. Yes the older version of C18 had many 'problems' in this area (some users like it and others don't). It's further complicated if your ISR calls any other function. Thankfully the latest version for available for download from Microchip does the register saving for you for the ISR but NOT for functions called in the ISR. Look at the save= sections in the compiler manual. If you head along to the Microchip site and register on the forum you will see lots of C18 ISR issues and solutions. I know there is at least one outstanding problem with C18 and ISRs and I believe 'someone' at Microchip is still looking into it. My advice would be to use the latest version of C18 and do not call any functions from within the interrupt. One important thing to know is not to re-enable the interrupt at the end (before exit). This is automatically done for you in the latest version of the compiler (the manual is wrong in this respect). This one had me for a long time where high interrupts were corrupting low interrupts on exit. If you do all of these things then I believe you will have skirted most of the known problems and your code should be ok. I've recently written a reasonably full app using C18 using these methods and all 'seems' ok. Good luck Jim www.picmodules.com
In article <fhs4q1he2ugf34h639jbbnvmig39nqt5uj@4ax.com>, darkknight
<darkknight.21@gmail.com> writes
> > >Hi > >A colleague of mine is using MPLAB C compiler and is struggling with the >saving of registers in ISRs. Apparently the compiler manual says you >have to manually scan the assembler code generated by the compiler to >work out what registers to save/restore in interrupt routines. His >software is crashing and he appears to be struggling to solve the >problem. > >Does anyone have any experience with this C compiler? > >Is there an easy way to determine what registers to save? > >Are there any more reliable C compilers for the PIC micro than MPLAB?
try wwww.iar.com -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
On Fri, 16 Dec 2005 21:03:55 +1300, darkknight
<darkknight.21@gmail.com> wrote:

>A colleague of mine is using MPLAB C compiler and is struggling with the >saving of registers in ISRs. Apparently the compiler manual says you >have to manually scan the assembler code generated by the compiler to >work out what registers to save/restore in interrupt routines...
The problem is common to some other compilers too, like the CSS. The reason has to do with the lack of a true stack in these midrange PICs. Normally in C, local (automatic) variables are allocated off the stack. This ensures that local variables used by an ISR will not collide with variables used in the main program. In order to simulate this kind of behavior without a stack, the PIC compilers do a call tree analysis of the program and from that analysis they statically allocate memory for automatic variables. This offers much of the same RAM savings that a true stack would offer because many times the same RAM location is used for several automatic variables, as long as the call tree analysis shows that these uses are in parallel branches of the tree. The trouble is that ISRs are like a new branch of the call tree that can be inserted anywhere that interrupts are enabled. Therefore automatic variables used in an ISR cannot share any RAM locations with automatic variables used anywhere else in the program. One work-around is to make sure your ISR does not use any automatic variables. Just declare static variables instead. The CCS compiler enforces the division of automatic variables in ISRs and the main program only if you use the "managed" version of the ISRs. That's where you let the CCS library routines handle the interrupt, save the registers, and check the various interrupt flags for any interrupts that are currently enabled. But if you choose to bypass the "managed" version of ISR handling and do your own saving, restoring, and interrupt case handling, then you better not use any automatic variables in your ISR. I don't know if this protection extends to subroutines called from within the ISR. To be safe, keep your ISRs so simple that you don't call subroutines and you don't use automatic variables. -Robert Scott Ypsilanti, Michigan
On Sat, 17 Dec 2005 02:59:20 GMT, Robert Scott wrote:

>On Fri, 16 Dec 2005 21:03:55 +1300, darkknight ><darkknight.21@gmail.com> wrote: > >>A colleague of mine is using MPLAB C compiler and is struggling with the >>saving of registers in ISRs. Apparently the compiler manual says you >>have to manually scan the assembler code generated by the compiler to >>work out what registers to save/restore in interrupt routines... >
[snip]
> >The CCS compiler enforces the division of automatic variables in ISRs >and the main program only if you use the "managed" version of the >ISRs. That's where you let the CCS library routines handle the >interrupt, save the registers, and check the various interrupt flags >for any interrupts that are currently enabled. But if you choose to >bypass the "managed" version of ISR handling and do your own saving, >restoring, and interrupt case handling, then you better not use any >automatic variables in your ISR. I don't know if this protection >extends to subroutines called from within the ISR. To be safe, keep >your ISRs so simple that you don't call subroutines and you don't use >automatic variables.
Thanks everyone. Unfortunately the interrupt routines are a little complex by necessity. I get the feeling that for reliability, the IAR, Hi-tech or CCS compilers would be a better choice than microchip mplab compiler because the microchip compiler still has a long list of outstanding issues and the version that supports automatic saving of context was released only a couple of months ago (it seems my colleague is not using it so we will at least upgrade to that). Do you have any idea which of IAR, HI-tech or CCS would be the most reliable - trouble-free? Graeme
where I worked some years ago we got the Microchip C compiler. It was
unusable because of all the bugs so we got the Hi-tech compiler. It was
very good, apart from one or two problems that we had to get round.

Leon

darkknight <darkknight.21@gmail.com> wrote:
> > Do you have any idea which of IAR, HI-tech or CCS would be the most > reliable - trouble-free?
IAR, by orders of magnitude. It's the only C compiler on PIC that is even *remotely* like using C on a more conventional micro. Expensive, but you get what you pay for. The code density isn't bad too these days. pete -- pete@fenelon.com "there's no room for enigmas in built-up areas"
In article <m0p0od.4cq.ln@fenelon.com>, Pete Fenelon <pete@fenelon.com>
writes
>darkknight <darkknight.21@gmail.com> wrote: >> >> Do you have any idea which of IAR, HI-tech or CCS would be the most >> reliable - trouble-free? > >IAR, by orders of magnitude. It's the only C compiler on PIC that is >even *remotely* like using C on a more conventional micro. Expensive, >but you get what you pay for. The code density isn't bad too these days. > >pete
Also they support the 12/16/17 18 and dsPIC -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/