What's your Favorite PIC Tool Chain?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I'm starting work with a new client, who's using a PIC processor.
They've selected a C toolchain that, frankly, sucks.  It's not ANSI,
it's not apparent that I can build from the command line, and the
compiler often starts mysteriously crashing.  I was able to fix this the
last time by reinstalling, but I don't know if I have the patience to
continue doing that.

Its early enough in the project that we could change the tool chain with
little or no pain -- but I've never worked with PICs to this depth.

So, have you programmed in C for the PIC lately, and if so, what tool
chain did you use?  Did you like it?  Does it have many peculiarities (I
understand that the PIC tends to induce peculiarities into a C compiler,
which I'm willing to work with as long as I know what they are)?  Can
you build stuff from the command line, or are you stuck with an IDE?

Thanks in advance.

--

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it

Back in the last century I was using a PIC, 16 something, and gave
up on C for it.  I switched to pure assembly, and could now keep
track of things and pack the needed code into the space available.
It was necessary to keep careful track of call stack depth.  The
compiler (forget which) was a small outfit who was very
co-operative on doing something about bugs, but they were
non-ending.  I could accept limitations, but not bugs.

I have finally learned that last century is no longer the 19th :-)
Took a while.

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it
Do your self a favor.

Tell the client that PIC is a bad choice, or give up the project.

Why even bother.

Good Luck

donald

Re: What's your Favorite PIC Tool Chain?
You get what you pay for.
Get HiTech C.


Quoted text here. Click to load it



Re: What's your Favorite PIC Tool Chain?


Quoted text here. Click to load it

PIC itself sucks, no doubt about it.
I am not a picoman by any means, although the inveterate picomans that I
know do prefer the Hitech C.

VLV

Re: What's your Favorite PIC Tool Chain?

Quoted text here. Click to load it
Certainly the PIC sucks from the perspective of writing software.  The
hardware design seems solid, however.  In addition, I have heard strong
rumors that the PIC has many fewer delivery issues than some of its
competitors.  If I'm stuck between some private irritation over
non-standard C vs. allowing a client to design in a part that he can't
get when he needs it, I'll take the non-standard C.

Come to think of it, I think I'll ask about availability in a new thread...

--

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: What's your Favorite PIC Tool Chain?

Quoted text here. Click to load it

Well, it certainly sounds like a good time to at least do the following
** Move the client to a larger PIC
    ( the smallest ones are the biggest pains )
** Check different tool flows, to find one you like

-jg





Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it

The suckyness of the PIC is why you want to use C Hi-tech works fine.
Though I have never used it in command line.  They have a demo version
and a free limited lite version.  Note that the PIC18 is a little better
than the PIC16.  The small stack is a pain.  The Hi-tech is not 100%
ANSI, the PIC can not handle it.  But I have copied C from other CPUs to
it and it compiles.  The PIC is much maligned, but it gets little jobs
done well.

Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it

We heavily use CCS. They release patch very often. Just few months ago I
seen CCSC having trouble with character array, generating MyArray+i
instead of MyArray[i]. Another day a friend was showing me CCSC having
trouble with switch statement. This got fixed in a release few weeks
ago. They improved on optimisation too, code is way smaller than used to.

Some recommend Hi-Tech C, but we had only trouble with it back in 2003.
Problems with 32-bit arithmetic, expressions inside function parameters
did not evaluate, compiler ignored the settings for reserved space etc.
Ended up locating all my vars, using plenty temporary variables to
simply expressions and some inline assembly. They may have fixed the
bugs, but I never looked back.

I did not work with C18, but seen some code and worked with C30. It may
be ANSI but is Microchip ANSI. Keep one finger on underscore key and you
should be good.

-

PICs *do not* suck, their toolchains do.

Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it

C30 is essentially GCC, C18 is something bought-in and hacked at
Microchip, although I'm not sure how much bought-in code remains.
When I was last at Phoenix in 2000 the compiler team consisted of
two people, both of whom were pretty sharp and responsive!

pete
--
snipped-for-privacy@fenelon.com "he just stuck to buying beer and pointing at other stuff"

Re: What's your Favorite PIC Tool Chain?

Quoted text here. Click to load it

So it can't be long before we see a Linux port then.

Quoted text here. Click to load it


Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it

Which toolchain is it?

Quoted text here. Click to load it

I've put some 3-400,000 lines of PIC10/12/16/17/18 code through
Hi-Tech's compilers over the last 10 years, in projects ranging in
size from ~50 lines of code to ~30,000 lines of code.  I've been happy
with them.  There have been bugs, but support is always responsive.

Quoted text here. Click to load it

Given that the target platform, not too many.  Recursion/reentrancy
isn't supported, and the type of string literals is "const array of
char" rather than "array of char."  Other than that, it tracks ANSI
well.

Quoted text here. Click to load it

I use "make" exclusively.  And they support Windows, Mac, and Linux.

--
John W. Temples, III

Re: What's your Favorite PIC Tool Chain?

Quoted text here. Click to load it

Mac and Linux too? Awesome! Microchip doesn't... although the IDE and
tools do run under WINE.

Quoted text here. Click to load it


Re: What's your Favorite PIC Tool Chain?

Quoted text here. Click to load it


Which PIC family?

If PIC24 or dsPIC - then I found the Microchip supplied GCC version to do
everything I wanted, and do it well.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC





Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it

I did a lot of PIC18 C programming a few years ago.

You need to ask yourself several questions:

* do you really need to work in C? - the PIC12-PIC16 are not C-friendly;
  the PIC17 is a complete dog's breakfast, the PIC18 will *tolerate* a C
  compiler; the PIC24 and PIC30 are actually rather nice!

* do you really need to work in ANSI-like C (i.e. do you actually need
  to port code to the PIC)!, or can you live with the C syntax and quirky
  semantics of some of the compilers?

The main limitations on a lot of PIC compilers are caused by the tiny
register set and Harvard architecture of the devices. On the "not quite
real C" compilers these typically manifest themselves as:

* no reentrancy
* no 'automatic' variables - the default storage class is 'static'
* no unified pointer type to both code and data space
* no 'constants in ROM' due to the pure Harvard architecture

A lot of people are OK with this; their code base is PIC only and they
work with the quirks of the toolchain. They treat C as a higher-level
assembler and don't get too hung up on portability, standards etc. I've
encountered some low-level flak in this group before for criticising
wildly non-standard C compilers - but my opinion has always been "if it
works for you, go for it - please don't call it C though!"

When I was working on the PIC18 however we were dealing with a
codebase that needed to be portable across a range of devices from
PICS to 64-bit RISCS.  For that you want a toolchain that works
like the rest of the world...  mostly ;)

The IAR compiler is the nearest to a 'conventional' C compiler I've
seen on a PIC. At least on the PIC18 it works around the first three
limitations (the unified pointer types are particularly hairy,
involving a lot of runtime library calls, but they do work in
combination with some hacks to put data into code space).
You're *better off* if you think about how your code is going to
be mapped onto the hardware, but you can mostly treat a PIC as 'just
another micro' with IAR.

Microchip's own compiler moves too fast to characterise but it used to
be a cheap'n'cheerful bought-in effort that they've improved themselves.
They seemed to believe in 'release early; release often' rather than
engineering a lot of bugs out of it.

pete
--
snipped-for-privacy@fenelon.com "he just stuck to buying beer and pointing at other stuff"

Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it

My favourite PIC toolkit is the wastebin....

Meindert



Re: What's your Favorite PIC Tool Chain?

Quoted text here. Click to load it
The consensus seems to be for the Hitec C.  I'll see if I can bring the
client around to paying for it (reminding him that he can either pay me
to reboot my machine or pay me to get work done may help).

To those who asked:

The problem child compiler is MikroC from Mikroelectronika, but we're
transferring the registration from my client to me, and the bugs could
conceivably stem from weirdo registration issues.  So I'm going to give
them another chance, but only one if I can help it (of course, if my
client wants to pay me to struggle with the registration process...)

It's a PIC 18.

I understand the ANSI issues -- I probably shouldn't have mentioned them
because the PIC, like the 8051, is quite hostile to the C virtual
machine.  Given that, you can't expect total ANSI compliance without a
lot of overhead.

The application is really too big for assembly language, at least given
that I don't have an extensive library of stuff already written.  I'd
much rather write in 'pretend C' than assembly, particularly if the
client is going to have some other folks working on this (he may).

--

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: What's your Favorite PIC Tool Chain?

Quoted text here. Click to load it

I'm not sure how well this will be recieved (in light of the many
other responses you've had) but I like the PIC and I like the CCS
compiler.  It was inexpensive (compared to Hi-tech C) and it addresses
many of the high-level functional interfaces available on the PIC
(I2C, SPI, serial, PWM, etc).  While it's true the compiler is not
strictly "ANSI-C", it still works.  A command-line is also available.
I've used the compiler through several generations on several PIC12,
PIC14, PIC16, and PIC18 projects ranging from the simple to the
extensive.  The compiler allows bit-oriented low-level accesses to
registers, also.
With the latest version of the CCS compiler, though, (version 4.001)
they have made major cosmetic changes while providing no appreciable
improvements in operation.  I had it installed (briefly) and found it
difficult to work with.  I had major issues with the operation of the
editor.  Questions posted to their tech support went completely
unanswered.

...my 2 cents...

Dave

Please remove the "AT" and "DOT" from the return address before
replying.
The return address has been intentional mangled to reduce spam.

Re: What's your Favorite PIC Tool Chain?
Quoted text here. Click to load it

I would also second the vote for CCS. I've used it on PIC16 and PIC18 devices
without any problems. The generated code is fairly well optimized and you can
cram a LOT of code into a little 8K device. The built-in support for
the peripherals is nice, so you can call a function like set_pwm2_duty(1023)
without having to worry about doing the bit-twiddling yourself.

However I'm also using version 3.x and I have't tried 4.x yet. The only
downside of 3.x is that it doesn't have a linker.
--Tom.

Re: What's your Favorite PIC Tool Chain?
says...
Quoted text here. Click to load it

I third the CCS vote.
It gets the job done with a minimal amount of hassle and a reasonable
price.
Just avoid using the strange length short, int, and long data types and
stick with int8, int16, int32 and so on and life is good.
As with any major update release, their tech support system has been a
bit overwhelmed, but the Rev 4.XX has been working well for me.
BTW, you get a full set of device headers (16F88.h for example) that are
always being updated and a pretty good project wizard that will get a
majority of the hardware setup from the get go.

                     Jim

Site Timeline