Which PIC18 C Compiler?

get.

Where I used to work we used the Hi-Tech compiler for the PIC18, and had relatively few problems. The Microchip compiler was unusable. They have probably improved it.

Leon

If you're going for C on the PIC18, the only professional-quality solution is the IAR compiler. It's expensive, but you get what you pay for. Microchip's compiler lags it significantly on code density and quality, and (IMHO) CCS takes too many liberties with the standard to actually be called C. It's a C subset with some semantic differences and some PIC-specific enhancements. This might not matter to you if you're just using it instead of assembler to save the hassle of low-level programming, but if you have any interest in migrating C code to/from the PIC, IAR is the one and only choice.

pete

Try Hi-Tech's compiler. You can download a limited-time demo that is almost entirely functional from their web site (I think you have to register). It's < $1K.

Best regards, Spehro Pefhany

I respectfully disagree. The Hitech C compiler for the PIC18 seems to be professional and of very high quality.

It isn't proper C though, it gets the semantics of automatic variables wrong (treats them like statics rather than allocating on the stack) and you therefore can't write reentrant code with it. (At least, you couldn't last time I looked).

Yes, it's a better product than CCS. But it's not a serious C compiler.

pete

...also try the CCS compiler...

Maybe the "non-standard" C is adequate for your needs. I've been using CCS compilers for years with success. I've never found any of the "non-standard" issues to be major show-stoppers in my applications. CCS is also looking at customer feedback for improvements in their compiler (as witnessed by the inclusion of a "real" sprintf() function as opposed to the work-around they had listed in their examples of the previous versions).

I don't know if the CCS compiler will run with the ICD2 but I do know it will integrate with the MPLAB environment. The 6-pin (telco connector) pinout of the CCS debug module conforms with the ICD2 pinout for pins 1 through 5. Pin 6 is also picked up in the CCS debugger as going to the B3 pin of the target. Pin 6 is a no-connect in the ICD2.

Basic bottom line is many time or size-limited versions exist out there. Try them all and pay for the one you want to use.

Best of luck.

Dave

parts

get.

Apologies for the incorrect web address...

CCS

is

the

code

reward"

I will share some of my experience with HiTech. Maybe 8.20 PL1 was just unfortunate version; I had the following problems:

• the firmware was split into 2 independent modules, bootloader and application code. I needed to reserve certain memory, but compiler was ignoring the command line options for that and happily generated variables in restricted zones, i.e. colliding with bootloader. The workaround was to assign them spefic address:

static u16 MmcRoot @ 0x204; /* MMC: first sector of root directory */ static u8 MmcRootSz @ 0x207; /* MMC: size of root directory */

• 32 bit expression in function call did not work, I had to pull it out into temporary var:

LogMmc = LogSec + LogFile; /* compiler does not compile expression

• And I recall that in one case it "forgot" to switch the bank. Cannot locate the snippet though.

Otherwise it is a good compiler. I cannot compare it, because I used CCS only for significantly simpler projects.

Roman

Actually Putting Variables on the stack is not a C requirement. It is just the most common implementation. If you are writing reentrant code on a small 8 bit cpu, you are looking for trouble (i.e. slow and big). If you want pure ANSI C you will trade it for code size. my $0.02

I don't have experience with the 18 series compilers, but for the 16 series the HiTech ones beats the pants off the CCS compiler, much more professional. At the time I needed to do floats in printf() and the CCS compiler wouldn't do it. The HiTech compiler also sensibly uses the acutal register names as used in the datasheet, so you can simply go PORTA=123 etc. I would avoid any compiler which doesn't allow this as standard.

The 18 series HiTech compiler uses their new HiTide windows interface. Gotta be better than the DOS version on the 16 series compiler. Although I now integrate the PIC-C compiler with the MPLAB program, it's painless.

If you can afford it, go for the HiTech compiler. Although the CCS one will probably do you just fine if you are on a budget.

Dave :)

Neil Kurzman writes:

It is true that the C Standard does not require them to be on a stack. But it does require that if they are declared with no linkage and without the storage specifier "static", that they be of storage class "automatic". The standard further explains that if the block with which the automatic variable is associated is entered recursively, a new instance of the instance of the object is created each time. (see ISO/IEC 9899:1999 (E) section 6.2.4 paragraphs 4 and 5)

If the Hitech compiler treats automatic variables as static, Pete is correct that this violates the C standard. I have not verified Pete's claim.

Neil further wrote:

That's a separate issue. If you're writing code for an 8-bit CPU, perhaps you should explicitly declare variables to be static, rather than expecting the compiler to violate the C standard and do it for you.

On further consideration, it seems like it would be nice to mark a function declaration as being non-reentrant, so that the compiler is allowed to treat automatic variables specially (but not necessarily the same as static variables). If the function *did* get called reentrantly, all bets would be off.

Alternatively, a new storage class for local variables could be defined to have that effect.

But it seems unlikely that the next version of the C standard would include such an extension, since the committee is not focused on the requirements of very small systems.

In my opinion the IAR, Hightech and CCS compilers are all good compilers with each one having it's strong and weak points.

The Hightech and IAR compilers are made by companies that also make compilers for other processors. Very likely the processor variants have a shared code base and many programmers working on it. This results in high quality code as a bug found for one processor will be fixed for all. So these two are professional compilers with linker and locater as you know them from other environments. Prices are professional too... :-(

The CCS compiler is a whole other kind of compiler, it is designed specifically for the PIC processor and is growing with the development of the PIC family. The PIC processor is not a standard kind of processor and because the CCS compiler was designed specifically for the PIC it can create sometimes more optimized code than the other compilers can.

Which one to choose? The PIC processor was not designed to support C, for example it's missing a stack for automatic variables, so any C compiler will have to create some work arounds that are difficult to work with in the beginning. You can choose either one of the mentioned compilers based on personal favor and available budget. I personally like the CCS compiler, mostly because of the low price and good support from the user's forum and quick response to bug reports. My department has done about 10 different small projects with the CCS compiler and PIC16 and this worked great. Now we are doing a larger project with the PIC18 and we are still happy with CCS.

Just one important note: On the CCS website you can download two versions of the compiler: The latest release, and an older release. CCS is not mentioning why they offer two different versions, but this is because the older version is a proven stable release while the newest release is more like a beta release. Use the latest version only if you need the new funtionality. For a stable environment stick to the last stable release, currently 3.191.

What about the SDCC compiler? It has a port for PIC18 processors called pic16 port.

Its in development yet, but it can handle simple projects. URL:

Also there is the gputils package providing assembler, linker and librarian. URL:

Both compile under Windows/Cygwin/Mingw installations (SDCC compiles under MSVC too...)

Vangelis Rokas

What about the SDCC compiler? It has a port for PIC18 processors called "pic16" port. (pic16 stands for 16-bit core devices)

Its in development yet, but it can handle simple projects. URL:

Also there is the gputils package providing assembler, linker and librarian. URL:

Both compile under Windows/Cygwin/Mingw installations (SDCC compiles under MSVC too...)

Vangelis Rokas

I just finished a pretty large project (15K lines of C on a PIC18F8720) using the CCS pic18 compiler (PCH). It worked pretty well. I only found two bugs that could be blamed on CCS. The compiler is not standard C, but it's close enough that you will be able to get coding pretty quickly. It helps to look at the code it generates for your program, and to try to understand why it does some things the way it does.

If you are not set on using the ICD2, I'd look at the CCS PCW package. It includes support for their ICD firmware (which you can run on an old Microchip ICD1, or you can buy an ICD from them for about $75). The whole package makes for a very nice source level debugger.

PCH seems to generate pretty tight code. When I have some free time (hah) I'm going to try running my code thru the Microchip C18 compiler (they have a time-limited trial version) and see which is more efficient. I'm also curious to see how much I'll have to change my CCS code to get it to run on C18. Developing a set of macros and defines that allows development with either compiler would be handy.

I don't have any vested interest in CCS other than being a reasonably happy customer.

Mark Hahn

At the place i'm contracting at, I have used the IAR compiler for the TI MSP430, and the CCS compiler for the PIC. I also personally own the Hi-Tech compiler.

I have not used the Hi-Tech compiler much, mainly because it is not used at work. However, I do know that the Hi-Tech compiler is pretty stable. It doesn't really have any libraries to run the PIC's peripherals (e.g. spi, i2c, uart, etc.), but it's a good thing I guess. I have not heard of many bugs as far as the C-compilation goes.

IAR has a nice GUI. I don't know though how optimal the code is though, compared to the Hi-Tech or CCS compilers.

Which leads me to the CCS compiler. I have mixed feelings on this one. They do offer a lot of releases, sometimes every two weeks or so. This is to be expected since they have a lot of functionality to offer in terms of library functions. They also keep up-to-date with PIC programming erratas on a timely basis. Sometimes, however, they end up breaking something every few releases, and need to release again. That is why I keep separate folders for each release, in case something gets broken that affects me. Usually it doesn't affect me, but there is always someone out there whose previously running software gets broken by each new release.

-Mike

You don't need a new storage class to do this. The compiler just needs to be intelligent enough to analyse the code, determin that a function is not reenterent and allocate locals accordingly. The problem with allocating local variables off the stack is one of RAM re-use. If you have a large number of functions each allocating its locals as static then your RAM requirements grow considerably. The way to get around this is to make the compiler more intelligent and get it to generate the locals on a static stack. This way RAM is re-used between functions. The upside is that PIC code runs a hell of a lot faster using a static stack than using a dynamic (runtime) stack. The XCSB compiler does this but it is not a C compiler.

Regards Sergio Masci

I have used Hitech for some years now, and their compilers appear perfectly decent for PICs.

My experience of IAR products is they're so good you don't notice them; until you have to justify the cost. It should always be remembered when comparing products from different economies that exchange rate can be significant (which is why Swedes come to England for Christmas shopping, and Brits go to France), as I believe is the case with IAR. If you really "get what you pay for" that would make GCC a really crap compiler, which it obviously isn't.

On the issue of reentrancy, the PIC18 like the 8051 has limitations which shouldn't prevent widespread acceptance but may provoke a little local difficulty. If the OP doesn't like the architecture, he should consider something else. AVR and MSP come to mind.

Regards, Mike.