C Compiler comparison for PIC18?

Izak van Langevelde wrote:
> In article <1133708948.055663.79770@g49g2000cwa.googlegroups.com>,
>  mhahn@hvc.rr.com wrote: 
> 
>>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.
> 
> I heard this more than once: is there any reference available for 
> differences between chip versions?

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

In article <4393d201$0$240$892e0abb@auth.newsreader.octanews.com>,
 Thad Smith <ThadSmith@acm.org> wrote:

> Izak van Langevelde wrote:
> > In article <1133708948.055663.79770@g49g2000cwa.googlegroups.com>,
> >  mhahn@hvc.rr.com wrote: 
> > 
> >>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.
> > 
> > I heard this more than once: is there any reference available for 
> > differences between chip versions?
> 
> 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. 
>   ;-)

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

-- 
Grinnikend door het leven...

Izak van Langevelde wrote:
> In article <1133708948.055663.79770@g49g2000cwa.googlegroups.com>,
>  mhahn@hvc.rr.com wrote:
>
> > 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.
>
> I heard this more than once: is there any reference available for
> differences between chip versions?
>
> --
> Grinnikend door het leven...

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

On 5 Dec 2005 02:37:56 -0800, mhahn@hvc.rr.com wrote:

>Izak van Langevelde wrote:
>> In article <1133708948.055663.79770@g49g2000cwa.googlegroups.com>,
>>  mhahn@hvc.rr.com wrote:
>>
>> > 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.

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

Izak van Langevelde wrote:

> Are you sure there are datasheets for the different revisions of, say, 
> 18f4620?

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

In article <4p46p1tlou7vqff30kvh1m25s2ng0q4kp7@4ax.com>, 
speffSNIP@interlogDOTyou.knowwhat says...
> On Sun, 4 Dec 2005 15:26:31 +0000, the renowned Chris Hills
> <chris@phaedsys.org> wrote:
> 
> >In article <eezacque-79A5A0.11501804122005@news1.news.xs4all.nl>, Izak
> >van Langevelde <eezacque@xs4all.nl> writes
> >>In article <43923d9d$0$226$892e0abb@auth.newsreader.octanews.com>,
> >> Thad Smith <ThadSmith@acm.org> wrote:
> >>
> >>> Izak van Langevelde wrote:
> >>> 
> >>> > 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...
> >>> 
> >>> It's hard to say without knowing your criteria.  
> >>
> >>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.
> >
> >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. 
> 
> Well, there is at least one that has 8-bit ints...  8-( 
> 

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

Jim wrote:
>> 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
>>
> 
> 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 

And then ISR performance is a joke.

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

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

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

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

> And then ISR performance is a joke.

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.

In article <B3Fkf.13598$w73.1669@newsfe1-gui.ntli.net>, "Jim" <tech@picmodules.com> wrote:
>
>> 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
>>
>
>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.
>

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.

Izak van Langevelde <eezacque@xs4all.nl> wrote:
> In article <43923d9d$0$226$892e0abb@auth.newsreader.octanews.com>,
> Thad Smith <ThadSmith@acm.org> wrote:
> 
>> Izak van Langevelde wrote:
>> 
>> > 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...
>> 
>> It's hard to say without knowing your criteria.  
> 
> 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 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"