Which PIC18 C Compiler?

"Talal Itani" <titani@airmail.net> wrote in message news:<cckb50$cl9@library2.airnews.net>...
> Hello,
> 
> I currently have an ICD2 from Microchip.  I use it to develop PIC16 code
> using the MPLAB debugger and assembler.  I need to move to the PIC18 parts
> and C language, but I am struggling figure out the development tools to get.
> Do you have any experience with the CCS compiler running with MPLAB and
> ICD2? ($175 solution)
> 
> Thanks,
> Talal

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

I wrote:
> The Hitech C compiler for the PIC18 seems to
> be professional and of very high quality.

Pete Fenelon wrote:
> 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).

Neil Kurzman <nsk@mail.asb.com> writes:
> Actually Putting Variables on the stack is not a C requirement.  It is just
> the most common implementation.

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:
> If you are writing reentrant code on a small 8 bit cpu, you are looking for
> trouble (i.e. slow and big).

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.

I wrote:
> 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: http://sdcc.sourceforge.net


Also there is the gputils package providing assembler, linker
and librarian.
URL: http://gputils.sourceforge.net


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


Vangelis Rokas



"Talal Itani" <titani@airmail.net> wrote in message
news:cckb50$cl9@library2.airnews.net...
> Hello,
>
> I currently have an ICD2 from Microchip.  I use it to develop PIC16 code
> using the MPLAB debugger and assembler.  I need to move to the PIC18 parts
> and C language, but I am struggling figure out the development tools to get.
> Do you have any experience with the CCS compiler running with MPLAB and
> ICD2? ($175 solution)
>
> Thanks,
> Talal
>
>

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: http://sdcc.sourceforge.net

Also there is the gputils package providing assembler, linker
and librarian.
URL: http://gputils.sourceforge.net


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


Vangelis Rokas




"Talal Itani" <titani@airmail.net> wrote in message news:<cckb50$cl9@library2.airnews.net>...
> Hello,
> 
> I currently have an ICD2 from Microchip.  I use it to develop PIC16 code
> using the MPLAB debugger and assembler.  I need to move to the PIC18 parts
> and C language, but I am struggling figure out the development tools to get.
> Do you have any experience with the CCS compiler running with MPLAB and
> ICD2? ($175 solution)
> 
> Thanks,
> Talal

"Talal Itani" <titani@airmail.net> wrote in message news:<cckb50$cl9@library2.airnews.net>...
> Hello,
> 
> I currently have an ICD2 from Microchip.  I use it to develop PIC16 code
> using the MPLAB debugger and assembler.  I need to move to the PIC18 parts
> and C language, but I am struggling figure out the development tools to get.
> Do you have any experience with the CCS compiler running with MPLAB and
> ICD2? ($175 solution)
> 
> Thanks,
> Talal

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





 

tronnort@yahoo.com (David L. Jones) wrote in message news:<894aa0b3.0407082132.6ac9c0e5@posting.google.com>...
> "Talal Itani" <titani@airmail.net> wrote in message news:<cckb50$cl9@library2.airnews.net>...
> > Hello,
> > 
> > I currently have an ICD2 from Microchip.  I use it to develop PIC16 code
> > using the MPLAB debugger and assembler.  I need to move to the PIC18 parts
> > and C language, but I am struggling figure out the development tools to get.
> > Do you have any experience with the CCS compiler running with MPLAB and
> > ICD2? ($175 solution)
> > 
> > Thanks,
> > Talal
> 
> 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 :)

Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhn0293aop.fsf@ruckus.brouhaha.com...
> I wrote:
> > 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.

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

Pete Fenelon wrote:

> In comp.arch.embedded Talal Itani <titani@airmail.net> wrote:
> 
>>Hello,
>>
>>I currently have an ICD2 from Microchip.  I use it to develop PIC16 code
>>using the MPLAB debugger and assembler.  I need to move to the PIC18 parts
>>and C language, but I am struggling figure out the development tools to get.
>>Do you have any experience with the CCS compiler running with MPLAB and
>>ICD2? ($175 solution)
>>
> 
> 
> 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

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.

-- 
Mike Page BEng(Hons) MIEE           www.eclectic-web.co.uk
Quiet! Tony's battling the forces of conservatism, whoever we are.