C Compiler comparison for PIC18?

Does anyone out there know about a decent c compiler which targets the pic18 family? So far, I played with the Sourceboost C compiler and the Microchip C18 compiler, I'm happy with none of these, am willing to spend some money on something really good, but won't waste my time on buying and trying...

--
Grinnikend door het leven...
Reply to
Izak van Langevelde
Loading thread data ...

It's hard to say without knowing your criteria. What were the problems with the ones your tried? I have been satisfied with HiTech, but it is more expensive.

--
Thad
Reply to
Thad Smith

True, that's why I'm looking for a decent comparison, which addresses things like quality and quantity of code, ansi compliance, ease of use, support.

The Sourceboost C Compiler has generated incorrect code on several occasions, probably because I declared a variable with a name already in use by the compiler; changing the variable name solved the problem. I cannot trust it.

The Microchip C18 compiler seems to have a steep learning curve. For instance, I spend a few days to compile things which worked when compiled from sourceboost, but fail to work through C18. For instance, you have to pin your ISR at the right location in memory yourself, while this is one of the things I'd like to delegate to a compiler/linker. This is not to say C18 doesn't generate correct code, but it takes some effort to get it up and running.

--
Grinnikend door het leven...
Reply to
Izak van Langevelde

I heard this more than once: is there any reference available for differences between chip versions?

--
Grinnikend door het leven...
Reply to
Izak van Langevelde

Yeah all the compilers out there for PICs have a pretty steep learning curve. For me most of the learning was figuring out how to configure all the different IO functions. Once you play with PICs for a while you get used to how they do stuff, but even then you'll get caught when Microchip does something a little different in a newer version of a chip.

The C18 compiler (from Microchip) has the advantage of being free if you are only using it for personal use (download the student version). It costs about $500 for commercial use. It is a bit weird to get used to, but generates pretty solid code. The weirdness is mostly due to the harvard architecture of PICs. Compilers that insulate you from that will be making assumptions that may not work all that well for you.

For example, the CCS PCH compiler handles tables in ROM differently than C18. PCH always calls a subroutine when accessing constant data. This can really slow down processing done in a loop. C18 on the other hand uses the TBLPTR register directly to access constant data. C18 actually generates code that's both smaller and runs faster than PCH if you are doing something like reading through a table that's stored in ROM.

PCH is probably a pretty good choice for PIC novices. The price is around $100. They have lots of library functions to help with setting the chip up. And lots of examples for standard stuff like writing to a LCD display, RS-232 communications, using an external I2C eeprom, etc. But their code is going to be a bit larger than what C18 generates. And some of their IO init functions are order dependent, which if you are a beginner is a real pain to figure out. Follow their examples if you can find one that is sort of like what you want to do.

I've done commercial products using the CCS PCH compiler. It's solid enough for that if you keep checking the compiler's output. I've ported some projects to C18 to see how it stacks up. For my next new project I'm leaning toward using C18.

Mark

Reply to
mhahn

In article , Izak van Langevelde writes

ANSI or ISO support? BTW most compilers only go as far as ISO C 90 + A1 and the TC's not to ISO C99

BTW given that you are on a PIC ISO C compliance is almost irrelevant.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Tech support, i.e. responsive people who know what they are talking about.

If I write code I appreciate some level of agreement about what it should do, this is where standards come in handy.

--
Grinnikend door het leven...
Reply to
Izak van Langevelde

Well, there is at least one that has 8-bit ints... 8-(

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

Just to add. I have used CCS compilers professionally for a few years and also was considering C18 for future projects. So I ported working CCS code to C18. The fiddly interrupt methodology (where you have to know which registers your ISR is going to use so that you can save them on entry), was a bit of a joke. Hitec & CCS hide you from this (unless you specifically don't want them to). The latest version of the C18 compiler was supposed to address some of the ISR issues. However, they have only gone part of the way which in my opinion is even worse. My Microchip FAE is still looking into a problem where high ISRs corrupt some registers on exit from the high ISR when the high ISR interrupts a low ISR. It has been appeox. 2 months and they are still scratching heads.

In some cases the CCS compiler was much better at producing smaller code. I didn't expect this as I have always been of the opinion that the CCS compiler is a bit 'cheasy'. Anyway, at the moment I have decided not to comit to using the C18 compiler until the known issues are fixed.

Hitec is similar is many ways to the C18 compiler but with much better C friendly interrupt handling (if you so choose). Hitec has a good reputation and I must say that I have never had any problems with it... ever.

My 2p worth = Hitec is best, then CCS, then others.

Jim

Reply to
Jim

I put this together last year:

formatting link

--
John W. Temples, III
Reply to
John Temples

I think Microchip has some app notes on porting some particular cases that they consider a natural upgrade, especially when they are obsoleting parts. In general, though, you should print datasheets and compare. I, too, have been caught by features that are almost the same. ;-)

--
Thad
Reply to
Thad Smith

Are you sure there are datasheets for the different revisions of, say,

18f4620?
--
Grinnikend door het leven...
Reply to
Izak van Langevelde

As others have said there is no better method than RTFM (read the f'ing manual) :-)

Unfortunately Microchip doesn't seem to publish manuals in the convienent dead tree format. My eyes tend to glaze over after reading

100 or so pages of a PDF file. One recent acquisition of mine is an old HP Laserjet 4 printer. Now when I start looking at a new PIC, I just print out the whole data sheet. Try to budget time to read the whole data sheet. You will find little things mentioned in it that will save you a lot of trouble later.

Also pay attention to the errata sheets for the part you have chosen for a design. Sometimes a feature that made you choose that chip in the first place doesn't work as well as you'd like.

Mark

Reply to
mhahn

Many of the chips have either sepearate migration guide documents, or sections in the back of the datasheet detailing the differences.

Reply to
Mike Harrison

For a particular model, 18F4620, the specified operation is the same. There could be some fixes applied to errors in early versions. These should be addressed in the errata, also online.

--
Thad
Reply to
Thad Smith

Yes, the CCS product has a 1 bit short and an 8 bit int, and a 16 bit long. They have kinda' fixed things while still maintaining backwards compatibility with older code by adding types that have the holder size in them. Like :

int8 unsigned int16

for data types. Which worked out OK for me since I had already typedefed their funky type specifiers.

Jim

Reply to
James Beck

And then ISR performance is a joke.

If it wasn't so buggy. I do not know most recent HI-TECH PIC cc, but 2 years ago I had problems with compiler "forgetting" to switch the bank,

32-bit calculations inside the call did not work (like foo(a+b, c) ), command line switches for avoiding certain memory areas did not work, etc.

If there were not those bugs, HI-TECH would get my 10 in comparison with other compilers especialy for ANSI conformance. I was able to share the declarations between PC host and PIC firmware with no problem at all. CCS choked on those headers because those days they lacked 32-bit integer support.

Roman

Reply to
roman

Yeah, I thought that would be the case as well. But it simply isn't. To get C18 to work properly several save=xxx parameters have to be be appended so that used registers are saved and restored. The newest C18 compiler has problems with TABLAT (still, but only when high ints are used), and so even if you don't use it you will see looking at the assembler that C18 uses it (and sometimes forgets to restore it!!!), when you take all this into account C18 is approx the same speed (and indeed slower if you use FAST option in CCS. Look at CCS assembly produced for an ISR and it is almost the same (on my test only the comms ISR was slower on CCS and serial comms doesn't have to be quick). Saying all that if you were able to properly save just the registers you use in an ISR then of course it would be quicker. But in my experience only the most demanding of circumstances requires the extra

10-20 clock cycles used in saving a few more registers than than you actual need to use.
Reply to
Jim

I've used both CCS and C2C, I've never tried Hitec or C18. I find the CCS compiler to be fairly good, the output is always correct, interrupt handing is easy and I really like the integraded development environment with the built-in debugger. Using an ICD and a 5-pin connenction to your target you can do all the usual debugging things like setting breakpoints in your souce code, single-stepping, watching variables etc. The only thing I don't like about it is it's RAM allocation strategy on PICs with banked RAM. On a 16F877 it would sometimes fit the variables into banks so that some functions would nearly double in size due to all the bank switching instructions. I found myself manually assigning variables into banks in order to reduce the number of bank switches. This is obviously less of a problem on the PIC18 series.

--Tom.

Reply to
Tom

The only one I could recommend from that point of view is IAR's. It's expensive, but you get what you pay for.

The Microchip compiler is cheap and cheerful and nowhere near as good as Microchip's; none of the others seemed to be anywhere close to ANSI.

pete

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

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.