Which PIC18 C Compiler? - Page 4

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

Translate This Thread From English to

Threaded View
Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

Walter gave a good answer regarding recursion in 8051 compilers, totally
unrelated to gcc and/or sdcc (since there is no gcc port for the 8051).

Quoted text here. Click to load it

We've been through this before.  There are certainly some optimisations
that gcc does not currently support which good commercial embedded
compilers *do* support.  In particular, there is only limited support
for whole-program optimisations, and link-time optimisations are still
under development.  These are very relevant to small 8-bit compilers,
but much less so for large 32-bit systems (which we all agree is gcc's
main target area).

Quoted text here. Click to load it

On many 32-bit systems, it is the standard (and sometimes the only)
compiler.  Of course, there is plenty of variation according to the
specific target - there are many different 32-bit cpus.  But in my
experience on ColdFire's and PPC's, it has generated similar to or
better than the few commercial compilers I have seen.

Quoted text here. Click to load it

The 16-bit market is very small - there is the msp430 (for which the gcc
port is perfectly good, but based on a rather old version of gcc and
therefore missing many recent improvements), some Freescale devices (I
don't know if there is a gcc port there), and various devices from the
far east (again, I don't know about gcc there).

Quoted text here. Click to load it

There is only one serious 8-bit target for gcc, and that's the AVR.  The
port is good, and generates good code.  It's not perfect, and I'm sure
that the biggest and best commercial compilers still generate tighter
code.  But avr-gcc is close enough to be perfectly good for serious
professional work - that's why Atmel support it.

Quoted text here. Click to load it

No - some commercial compilers have some techniques that gcc does not
use, and some of these techniques may have been in use for years.  There
is a big difference here - there is no doubt that for example Byte Craft
use optimisation and compilation techniques that are well beyond what
gcc can do at the moment.  But that does not imply that gcc is
equivalent to a 5 or 10 year old embedded compiler!

No one would (sensibly) expect a hypothetical 8051 gcc port to compete
with Byte Craft's in quality of code - such a device needs the type of
optimisation that Byte Craft specialise in in order to get the best from
it.  But on the other hand, I would not except Byte Craft to be able to
port their compiler to an Intel Core Duo and get the same speed as gcc,
without an enormous amount of effort.  gcc's awareness of cache
locality, pipeline stalls, vectorisation, and other such things are
years ahead of Byte Craft's - simply because these are relevant to gcc's
main targets, but irrelevant to Byte Craft's.

Devices like the AVR fall somewhere in between most small cpus and
32-bit devices in terms of suitability of a gcc port - thus the port is
pretty good, but not as tight as is theoretically possible.


Finally, in all this discussion, you are missing out the concept of
"good enough".  Suppose that, say, IAR's AVR compiler generates 20%
smaller and faster code than avr-gcc.  So what?  For some projects,
that's relevant - if it means a large production run can use a smaller
flash then you have saved a lot of money.  But for many commercial
developments, it's not going to make a big difference.  Similarly, even
if we guess that Keil's 8051 compiler is twice as good as sdcc, there
are still plenty of professional projects where that is not a problem.
Of course, there may be other issues involving development time,
debugger support, reliability, or certification - I haven't used sdcc,
and can't comment there.

Quoted text here. Click to load it

gcc supports the C standards to a similar degree to most commercial
compilers - i.e., it seldom has 100% compliance, is generally late in
reaching almost-complete compliance, and it has its own extensions.
What is unusual about gcc is that it has more extensive extensions than
many other compilers (in the interests of generating better code, or
allowing higher quality source code).  Many of these extensions
pre-dated newer C standards (such as some crosses between C and C++),
and many have later been copied by other compilers.

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

I'm repeating myself here just for the record - but the PIC24 and dsPIC
(16bit devices) have a good GCC port.


Quoted text here. Click to load it

<snip>

This has been discussed add infinitum.


Quoted text here. Click to load it


What makes a standard?  What a committee publishes but nobody uses, or what
a large user base use, comply with, and expect to see?

It is always amusing watching language 'gurus' cut their teeth in the
embedded word, fall flat on their faces, then blame the compiler for not
implementing the 'standard'.  They know which page of which standard a
particular construct is described, but have no idea how to create an
embedded system.  Which is the most useful skill?

[expecting to be flamed]

--
Regards,
Richard.

We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

Bloody good question!

Quoted text here. Click to load it

Not my me!  I agree completely .

This is a major problem with some people on standards committees they
have absolutely no industrial or embedded experience.




--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

Sorry, I didn't think about these (I always think of "PIC" as PIC12,
PIC14 and PIC16 - possibly PIC18.  I never had occasion to look at the
newer, bigger PIC's more closely).

Quoted text here. Click to load it

That's an important point.  The C standards are a helpful reference, but
since almost *no* compiler seems to implement all of any given standard,
and none of the standards are sufficient for embedded programming, they
are only an indication of language support.  For example, if the
compiler is approximately C99 compliant, you know you can mix
declarations and statements in a function (if you thought that was a
good idea...).  And if you know you are sticking to gcc, it is safe to
use gcc extensions (some of which can be very useful).  The standards
make life easier, but by no means easy, for writing cross-target code.

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

"gcc -W -Wall -ansi -pedantic" is an ISO C90 compiler.
Modifications to "-ansi" make it a slightly incomplete C99
compiler.

--
 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: Which PIC18 C Compiler?

Quoted text here. Click to load it

As the author of the R8C/M16C/M32C port for gcc, I disagree.  Our
benchmarks and code comparisons show gcc's 16 bit port is similar to
Renesas's other compiler (the NC series), and the users agree, some
even claiming it produces better code for their application.

In addition, if you buy the 16-bit development kit from Microchip, it
*is* gcc.

Also, the gcc core is *constantly* undergoing improvements and
replacements to keep up with (or even invent) the latest technology.
I'm not sure how that qualifies as "old".

Re: Which PIC18 C Compiler?
writes
Quoted text here. Click to load it

Do you get the source for it?


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

Naturally.  Otherwise their huge legal department would not be doing their
job properly.

--
Regards,
Richard.

We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?

Quoted text here. Click to load it

Of course.  I have my copy.

Re: Which PIC18 C Compiler?
writes
Quoted text here. Click to load it

As I am involved in compiler validation and know several people who
validate and analyse compilers (all of whom are under NDA with  various
compiler companies)  I am being told with evidence that GCC is 5-10
years behind current compiler development. It does not "invent the
latest technology" far from it.


Regards
  Chris
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?

Quoted text here. Click to load it

Microchip is an excellent company, on some fronts.  They treat smaller
companies generally quite well, have had in the past well informed
technical support staff with genuine personal software development
experience as well as a good hardware understanding (and I mean this
in comparison to other micro manufacturers' technical support staff,
which have been consistently inferior to those at Microchip), they
track problems in a consistent fashion you can understand, and they
support their professional tools almost forever.  Old chip production
tools are supported far longer than I've found elsewhere.  As in, I've
never had them tell me "we don't support that anymore and cannot get
you a replacement."  I'm sure they have their problems, as well.

Quoted text here. Click to load it

Which version?

Quoted text here. Click to load it

The PICs have an instruction set and/or a page control register
(depends on which PIC how much of what is what) that makes it "easy"
to access variables on a "base page" that is 256 bytes in size.  This
means that you will want to place variables there, those which need
faster access and/or where you think it may help in terms of code size
because of the number of places that reference them.  You don't have
to do that.  But if you want that advantage, you need to let the
compiler know what you consider a high priority for that, so it can do
it.  I suppose they could have written something to take a more
general clue from you (size vs speed, for example) and "figure some
things out" on its own.  But instead they just let you wrap the
definitions so that the compiler is directed what to do about that.

Quoted text here. Click to load it

Roughly speaking.  The 18-series is better about this than some of the
16F-series, themselves better than some of the old 16C-series, if
memory serves.  But having programmed PICs since 1989, I might be
mixing in a few experiences.  Things vary a little.  And the PIC18's
are definitely nicer, in this regard.

Quoted text here. Click to load it

I don't recall that requirement.  I believe in some code I wrote for
the 18-series (it's been a few years, so forgive my memory), I could
just declare the variables and the compiler/linker placed them
'satisfactorily.'  I wrapped definitions that I cared to place on the
base page (0), that's all.

Quoted text here. Click to load it

The C18 compiler uses #pragma's.  Use something like:

#pragma udata access myarea
// definitions go here
#pragma udata

to wrap your variable definitions.  The C18 compiler (I don't think it
works on PIC16's) uses the term 'access' to mean the faster access ram
in bank 0.

Read the C18 compiler manual and look for those terms.

Jon

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

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
*/
                                    /* inside function call properly */
        zseek(FLOG,LogMmc);

* 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



Re: Which PIC18 C Compiler?

Quoted text here. Click to load it

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.

Re: Which PIC18 C Compiler?

Quoted text here. Click to load it

The portability is overplayed with small microcontrollers. The PIC
is not made for C language. CCS does a very good job at optimizing
the code and that it very important when code memory usage is high.

I don't think that the fact that IAR is more ANSI compliant is a
good justification for the high price.

I don't see the logic is making it easier to swith a design from
a PIC to a mainframe.

--
John Kerry for president
http://www.johnkerry.com /

We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

It's not. We have customers in automotive who demand portability, they
want the same platform running on platforms from PIC right up to PowerPC.

For people who are building one or two products, yes, portability is not
important. For big customers, it is.

Quoted text here. Click to load it

The PIC18 was intended to be C-friendly. Microchip knew they'd screwed
up with the PIC17.  

Quoted text here. Click to load it

I do, and so do large customers.

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas"

Re: Which PIC18 C Compiler?
Quoted text here. Click to load it
I find it VERY unlikely that any of your customers demand that the code
be portable between PICs and Power PCs.  

Quoted text here. Click to load it
Why?  I have found after doing this for over 20 years that in "big"
projects COST is the big factor.  Not once did anyone ask me to make
sure that the code that runs on one of our gaming voucher printers be
portable to a Wintel bos, but they sure ask about the price.
When you say "big" I take it you mean big numbers of shipped units.
Quoted text here. Click to load it
Many of us have sucessfully completed 17 series parts using 'C'.
Just as many of us learned to deal with the limitations of the Intel
segmented architecture of the X86 we have learned to deal with the
oddities of small MCUs.
 
Quoted text here. Click to load it
Once again I find that ridiculous.

                 Jim


Re: Which PIC18 C Compiler?
On Thu, 8 Jul 2004 15:34:43 -0500, the renowned "Talal Itani"

Quoted text here. Click to load it

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
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Which PIC18 C Compiler?
...also try the CCS compiler...  www.ccs-info.com

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

Quoted text here. Click to load it
parts
get.
http://www.trexon.com
Quoted text here. Click to load it
http://www.speff.com



Re: Which PIC18 C Compiler?
Apologies for the incorrect web address...

www.ccsinfo.com (no dash)...


Quoted text here. Click to load it
CCS
is
the
code
reward"
Quoted text here. Click to load it



Re: Which PIC18 C Compiler?
Quoted text here. Click to load it

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 PORTA12%3 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 :)

Site Timeline