PIC mplab c18 C compiler

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.

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.

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).

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.

--

> 
> TIA

A colleague of mine is using MPLAB C compiler and is struggling with the

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

In article , darkknight writes

try wwww.iar.com

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

[snip]

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

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"

Also they support the 12/16/17 18 and dsPIC

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In what ways is IAR "orders of magnitude" better than Hi-Tech?

--
John W. Temples, III

stack based with re-entrancy dyn mem alloc

ANSIness. Reentrancy (if you want it). Ability to declare "generic" pointers that can address data or code space. (OK, this leads to hideously inefficient code, but it means *you can construct platform-independent code and expect it to run on a PIC*. Yes, it's inefficient relative to something designed specifically for a PIC's architecture, but in a world where systems are increasingly constructed from the output of code-generation tools, this is often very important.

Hi-Tech is OK if you want something for developing "PIC applications" with; if you want to do "real programming" that just happens to target the PIC, IAR is the only choice. CCS is... something that looks a bit like C.

pete

--
pete@fenelon.com "there's no room for enigmas in built-up areas"

Hi-Tech has all of that except reentrancy (which I don't want). It also has a reasonable code generator, which IAR did not in my last evaluation. An application that generated 24K of code with Hi-Tech generated 36K of code with IAR, and didn't even fit in the target's

32K of flash.

Do you feel that's not possible with Hi-Tech? I have no problems doing it.

--
John W. Temples, III

Yes all ten lines of it - if you're lucky.

That's such an understatement, it's like saying "a rocket is a little beefed up compared to a kite".

It's a bit pointless if the generated code wont fit in a PIC or executes too slowly.

Good code generation tools for embedded targets do exist. Relying on tools "hacked" together by programmers (and I use the term VERY losely here) that know nothing about embedded or realtime systems is a big mistake. If you are using a tool that cannot take advatage of the properties of a particular target, either get a new tool or hire someome that can do the job properly.

So what anything else is not "real programming" ?

Regards Sergio Masci

- optimising PIC compiler FREE for personal non-commercial use

.

You could also look at Knudsen Data's compiler

for the PIC. I've just come across this one, does anyone have any experience of it?

Vic