PIC mplab c18 C compiler

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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/