Searching \ for 'PIC C compilers' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=c
Search entire site for: 'PIC C compilers'.

Truncated match.
PICList Thread
'PIC C Compilers'
1995\02\04@014355 by William Chops Westfield

face picon face
   Andrew Warren - spam_OUTfastfwdTakeThisOuTspamix.netcom.com said:
   Maybe I should just keep re-posting my "MPC is the only C compiler
   suitable for professional software development" message until it
   finally sinks in...

Maybe, but that doesn't mean it needs to be.

A C-compiler aimed at generate byte-codes similar to what parallax uses in
the basic stamp might be a lot easier.  A pascal compiler easier still
(Since it's been done - remember p-codes?)

Personally, I'll side with the guy who thought trying to program a PIC in C
was silly.  Sorta like trying to reprogram your video game machine in
smalltalk.  The sort of C program that fits in a couple K of memory on a
machine with no stacks or pointers could equally well be written in any high
level language.  There might be portability reasons for writing C code
without pointers or stackframes or printf or any of that stuff, but the
resulting code would end up so PIC specific anyway, there wouldn't be much
point.

Structured assembler anyone?

[So, I haven't introduced myself yet.  I work for cisco Systems, the
networking company, writing code in C.  Before that I was a dec-20 assembly
programmer.  I like assembly.  I thought I wanted to be a EE, but I got into
microcontrollers in about 1976 (in highschool), when I realized that nearly
every electronic project I had ever built could have been equally easilly
programmed in the RCA1802 system recently published in popular electronics.
In college I chased microprocessors, noting what was neat about each one.  I
wrote a simulator for the 8085, and for a senior project code for an SDK-86.
Sadly, few of the newer processors are "neat" in the same way that they were
in the heyday of the 70s and 80s - now everything is designed with the fact
that a compiler is going to hide all the gross stuff from the user.  Except
microcontrollers.  Some of those are still neat, perhaps driven by the need
to write programs in finite memory space.  While older microcontroller
systems might have replaced electronic projects, the new low pin count
controllers might well replace any number of individual chips.  That's neat
too.  I've got a PICstart on my shelf, awating attention.  And an 82750 kit
too.  I want to play with them, and perhaps put them in model rockets.

When I get time...]

BillW


'PIC C Compilers'
1995\12\06@110422 by Jim Baughman
flavicon
face
Greetings all.  I'm sure this message has come up before (sorry about that)
but I couldn't find any information to answer my question in any of the
online FAQs/WWW pages/etc...so here goes.

What is the best C compiler for the PIC, for the price?

I've found information on two different compilers, one from Byte Craft and
the other from Custom Computer Services.  The main difference that I can
see is the cost.  $795 vs $100.

Anyone out there have experience with these compilers?

Any reason why I shouldn't buy the compiler from CCS for a hundred bills?

-----
o----------------------------------------------------------------------o
|                           James C. Baughman                          |
|                                                                      |
|  Applied Research Laboratories            .....jbaughmnKILLspamspam@spam@mail.utexas.edu   |
|   University of Texas, Austin               Home: (512) 836-3272     |
|      Work: (512) 835-3633                  Mobile: (512) 923-9418    |
o----------------------------------------------------------------------o

1995\12\06@112745 by Rick Miller

flavicon
face
On Wed, 6 Dec 1995, Jim Baughman wrote:

> Greetings all.  I'm sure this message has come up before (sorry about that)
> but I couldn't find any information to answer my question in any of the
> online FAQs/WWW pages/etc...so here goes.
>
> What is the best C compiler for the PIC, for the price?
>
> I've found information on two different compilers, one from Byte Craft and
> the other from Custom Computer Services.  The main difference that I can
> see is the cost.  $795 vs $100.
>
> Anyone out there have experience with these compilers?
>
> Any reason why I shouldn't buy the compiler from CCS for a hundred bills?

Depends...  If you're compiling for the PIC16C84,
you could use the *FREE* C compiler "pic_cc" available
in source code from the GNUPIC archive:

 http://www.execpc.com/~digalog/.magic/address.html

It's only good for the PIC16C84, and requires you to use
Parallax's PASM (pseudo-8051-style assembler) under DOS,
but it works.

Rick Miller, Design Engineer  (and local "Internet Guy")
Digalog Systems, Inc.         <rickspamKILLspamdigalogsys.com>
3180 S. 166th St.             <.....Rick.MillerKILLspamspam.....Linux.org>
New Berlin, WI  53151  USA    +1 414 797 8000 x-228

1995\12\06@114049 by Tim Braun

flavicon
face
> Date:         Wed, 6 Dec 1995 09:46:09 -0600
> From: Jim Baughman <EraseMEjbaughmnspam_OUTspamTakeThisOuTMAIL.UTEXAS.EDU>

> What is the best C compiler for the PIC, for the price?

For my money, it was the MPC.

> I've found information on two different compilers, one from Byte Craft and
> the other from Custom Computer Services.  The main difference that I can
> see is the cost.  $795 vs $100.

Quite a bit more to it than that.  The ByteCraft MPC supports all PIC's,
you need two compilers from CCS, so the comparison should be $200 <-> $795.

The way either compiler does the nitty-gritty stuff is different, so you
can't easily support both with one source code.  The MPC is _much_ more
robust, and fits better into an experienced developers work environment.

> Anyone out there have experience with these compilers?

I've used both.  There's a difference, indicated by the prices.  If
you can afford it, get the ByteCraft.

> Any reason why I shouldn't buy the compiler from CCS for a hundred bills?

The first one that comes to mind is that it may not do what you want,
rendering the $100 spent wasted.  I resent the time I wasted on it more
than the cash.

Of course, I wasn't targetting the 16c84, so the free ones (which weren't
widely available 9 months ago) weren't an option then.  Check them out.

Tim Braun                             | Voice: 204-942-2992 ext 228
Continental Healthcare Systems Canada | FAX:   204-942-3001
1900-155 Carlton St                   | Email: timspamspam_OUTchs.mb.ca
Winnipeg, Manitoba, Canada R3C 3H8    | www: http://www.chs.mb.ca/~tim/home.html

1995\12\06@142602 by myke predko

flavicon
face
{Quote hidden}

Just a couple of questions (I'm also not sure if this will show up in the
discussion group, so if it isn't passed thru it, please let me know and I'll
resend it) with regarding to using the "C" language with the PIC.  I've been
toodling around with '84s for the past little while and I'm curious to
understand how any "C" implementation works, because I would have thought
the overhead required (both in Space and Execution Time) for the language
would seriously affect any applications.

I haven't used any of the "C" implementations mentioned, so the questions
probably would be answered just by looking at the packages.

How do the Compilers handle the various ports and functions within the PICs?
I would guess the true "C" way of doing things would be to write a library
(in Assembler?) and then call it from the main program.

With regards to functions, how does the compiler pass arguements back and
forth?  This is a huge question because there is also the problem of
pointers and structures based on the pointer.  Non of the PICs have a stack
pointer, so the
passing of data can be tedious/dangerous (in terms of getting overwritten).

Are reenterant functions allowed?

How are Interrupt Handlers handled?  I know from personal experience that
there is more to an Interrupt Handler than just having the code starting at
address 4 and ending with a "retfie".  How is the status and w registers
handled?

And lastly, what type of data types are available and how are they
manipulated by the language?  I would expect the space used for anything
greater than 8 bits to be a problem because of the space required for the
operation.

Thanx for your answers,

Myke Predko

1995\12\06@181328 by John Payson

flavicon
face
> How do the Compilers handle the various ports and functions within the PICs?
> I would guess the true "C" way of doing things would be to write a library
> (in Assembler?) and then call it from the main program.

That would be a common method.  I think the preferred method of handling
things like integer math in C would be to have a couple registers reserved
as an "integer accumulator" and have functions like [add int acc. to memory
pointed to by FSR/W [function would have two entry points; the first would
start with "MOVWF FSR" and fall through to the second].  For expressions
which need more than one integer accumulator, turn the others into local
variables [see below]

> With regards to functions, how does the compiler pass arguements back and
> forth?  This is a huge question because there is also the problem of
> pointers and structures based on the pointer.  Non of the PICs have a stack
> pointer, so the
> passing of data can be tedious/dangerous (in terms of getting overwritten).

Preferred approach I've seen on micro compilers is to have functions' argu-
ments allocated statically using a call-graph to overlay variables [e.g. if
function main calls foo and bar, neither of which calls each other, and all
three functions have two byte-variables named main_i, main_j, foo_i, foo_j,
bar_i, and bar_j, then a total of four bytes need to be allocated: one each
for main_i and main_j, one shared between foo_i and bar_i, and one shared
between foo_j and bar_j.

Note that on many compilers the variables for a function must be located
sequentially; this sometimes limits what the linker can do with allocation.
For something like a PIC, it would be better if a compiler/linker could sub-
divide functions into zones depending upon which variables were alive/dead,
but I don't know if any do.

Parameters on such compilers are defined as local variables, and are written
to directly by the calling procedure.  A variable argument list is defined
as an array of char [of compiler-option-settable length] which is filled in
by the calling procedure.

> Are reenterant functions allowed?

Generally not.

> How are Interrupt Handlers handled?  I know from personal experience that
> there is more to an Interrupt Handler than just having the code starting at
> address 4 and ending with a "retfie".  How is the status and w registers
> handled?

Pretty much as you'd expect; the compiler creates standard prologue/epilogue
code.  For the PIC, you may get lucky and have a compiler skip, e.g., the
saving of the status register, if nothing in the code affects status.  I'd
not expect such a thing, however; if your interrupt procedure consists only
of, e.g., incrementing a counter I'd expect the compiler to generate [nb:
code to reset cause of interrupt elided:

       .org    4
       movwf   WSAV
       swapf   STATUS
       mofwf   SSAV
       incfsz  Timer
        goto   $+2
       incf    Timer+1
       swapf   SSAV,w
       movwf   STATUS
       swapf   WSAV
       movf    WSAV,w
       retfie

rather than the [shorter and faster]

       .org    4
       incfsz  Timer
        goto   $+3
       incfsz  Timer+1
        nop
       retfie

> And lastly, what type of data types are available and how are they
> manipulated by the language?  I would expect the space used for anything
> greater than 8 bits to be a problem because of the space required for the
> operation.

Any decent micro compiler will support at least 16 bits decently [a 16-bit
add translates as:

       movf    Source,w
       addwf   Dest
       btfsc   C
        incf   Dest+1
       movf    Source+1,w
       addwf   Dest+1

[Saves time: 6 instructions; 6 cycles] or possibly as:

       movlw   Source  ;[address of]
       call    Load16
       movlw   Dest
       call    Add16f

Load16:
       movwf   FSR
       movf    IND,w
       movwf   AccL
       incf    FSR
       movf    IND,w
       movwf   ACCH
       return

Add16:
       movwf   FSR
       movf    IND,w
       addwf   AccL
       btfsc   C
        incf   AccH
       incf    FSR
       movf    IND,w
       addwf   AccH
       return

[Saves code if many adds are used: 4 instructions per add; 24 cycles execution]


'PIC C compilers'
1996\04\29@145727 by john.seamons
picon face
A couple of questions I didn't find answered in the FAQs:

Has anyone used the CCS C compiler with the Parallax simulator/emulator?
It looks like the .lst file produced by the CCS compiler isn't compatible
with the Parallax tools.  Anyone got a conversion program? (DOS)

Any opinions on code quality/space of the CCS compiler ($99) versus the
Byte Craft compiler ($795)?

Thanks,
-jks


'PIC C compilers'
1997\01\09@181635 by Eddie Starling
flavicon
face
I'm looking for an inexpensive C compiler for PIC processors. Has anybody
had any experience with the CCS compiler. I'm looking at the 14 bit
compiler (PCM). Are there any others worth considering.

Eddie Starling
Telephonics Corp.
(516)549-6066
@spam@edstarKILLspamspamsw.telephonics.com

1997\01\09@184231 by Todd Peterson

picon face
At 06:14 PM 1/9/97 -0500, you wrote:
>I'm looking for an inexpensive C compiler for PIC processors. Has anybody
>had any experience with the CCS compiler. I'm looking at the 14 bit
>compiler (PCM). Are there any others worth considering.

The PCM works great for me, and seems to have some features the others
don't.  Also, it works with MPLAB, which is a big plus.

      -Todd



____________________________________

Todd Peterson (KILLspamtpetersonKILLspamspamnetins.net)
 E-LAB Digital Engineering, Inc.
        (712) 944-5344

Embedded Control &
 Integrated Circuit Solutions

ELECTRONICS RESOURCE DIRECTORY at:
http://www.netins.net/showcase/elab

1997\01\09@184719 by Jeff King

flavicon
face
At 06:14 PM 1/9/97 -0500, you wrote:
>I'm looking for an inexpensive C compiler for PIC processors. Has anybody
>had any experience with the CCS compiler. I'm looking at the 14 bit
>compiler (PCM). Are there any others worth considering.
>
>Eddie Starling
>Telephonics Corp.
>(516)549-6066
>RemoveMEedstarTakeThisOuTspamsw.telephonics.com
>
>

I've developed a number of projects on the CCS compiler, I like it. Its the
only PIC 'C' compiler I've used. At the time I bought it, cost was a issue
for me as well. Since them I've talked with ByteCraft a number of times and
they haven't been able to give me any compelling reason to 'upgrade' to
their compiler. Cost wouldn't be much of a issue at this point so I think
that might say something about the CCS compiler.

The one I have used the most is 'PCB' which is for the 5x core. I also own
PCM but haven't used it a whole bunch yet.

Good luck

Regards,

------------------------------------
| Jeff King      Aero Data Systems |
| spamBeGonejeffspamBeGonespammich.com  P.O. Box 9325     |
| (810)471-1787  Livonia, MI 48151 |
|F(810)471-0279  United States     |
------------------------------------

1997\01\10@033521 by Dag Bakken

picon face
    You should have a look at the CC5X C-Compiler.  This compiler supports
    the 12-bit and 14-bit PIC core.  It integrates 100% with MPLAB.  This
    is (as far as I know) the oldest PIC C-compiler available (i.e very
    well debugged).  CC5X will also generate the most compact code, and
    reuses RAM whenever possible.  This is the main advantage of this
    compiler.  When most compilers have filled up your ROM, CC5X may be
    able to generate the same program in 2/3 of the space.
    The most frequent question from customers, is how to implement inline
    assembly...  This is something that is not possible, and you don't
    need it.  The reason for using inline assembly is usually to make sure
    a routine executes in a precise number of instructions, or to make a
    piece of code very compact.  CC5X will generate precise assembler
    instructions if you want it to.  Delays can be written in C with the
    accuracy of assembler programming.

    Try any internet search-engine, and search for CC5X.  One of the pages
    should be the "Ormix page" which holds a more or less new demo
    version.  Another page also contains a PIC C-compiler comparison test.

    Regards,
    Dag Bakken


______________________________ Reply Separator _________________________________
Subject: PIC C compilers
Author:  Eddie Starling <TakeThisOuTedstarEraseMEspamspam_OUTSW.TELEPHONICS.COM> at Internet_Exchange
Date:    09.01.97 18:14


I'm looking for an inexpensive C compiler for PIC processors. Has anybody
had any experience with the CCS compiler. I'm looking at the 14 bit
compiler (PCM). Are there any others worth considering.

Eddie Starling
Telephonics Corp.
(516)549-6066
RemoveMEedstarspamTakeThisOuTsw.telephonics.com

1997\01\10@045355 by fastfwd

face
flavicon
face
Eddie Starling wrote:

> I'm looking for an inexpensive C compiler for PIC processors. Has
> anybody had any experience with the CCS compiler. I'm looking at the
> 14 bit compiler (PCM). Are there any others worth considering.

... and Dag Bakken <PICLISTEraseMEspam.....MITVMA.MIT.EDU> replied:

> You should have a look at the CC5X C-Compiler.  This compiler
> supports the 12-bit and 14-bit PIC core.

   But not the 16-bit core.

> This is (as far as I know) the oldest PIC C-compiler available (i.e
> very well debugged).

   While the compiler itself has very few real bugs, the libraries
   included with it (which are the most compelling reason for
   anyone to buy the compiler) often DO have serious bugs... New
   revisions of those libraries seem not to be tested very well by
   CCS before they're released.

> CC5X will also generate the most compact code, and reuses RAM
> whenever possible.  This is the main advantage of this compiler.
> When most compilers have filled up your ROM, CC5X may be able to
> generate the same program in 2/3 of the space.

   It's important to note that:

   1) CCS doesn't use any high-powered optimization algorithms or
      anything... The compactness of their generated code is due
      almost entirely to the fact that the compiler only supports
      a "Baby-C" subset, limited to the operations that are DIRECTLY
      supported by the PIC instruction set.  16-bit math, for
      example, is not directly supported; in fact, the compiler
      doesn't even support SIGNED math.

   2) The CCS compiler doesn't really generate code that's all THAT
      compact, anyway.

   Here's a simple example of optimization failure:

       byte1 = x;
       byte2 = x;
       byte3 = x;

   In this case, the compiler produces:

       movf    x,w
       movwf   byte1
       movf    x,w
       movwf   byte2
       movf    x,w
       movwf   byte3

   The trivial optimization that the compiler misses is, of course:

       movf    x,w
       movwf   byte1
       movwf   byte2
       movwf   byte3

   "A-ha!" you say, "But what if 'x' is an I/O port?  In THAT case,
   the optimized code might be inaccurate."

   Well, ok... But shouldn't a compiler written specifically for
   the PIC know the difference between an I/O port and a
   general-purpose file register?  I mean, really...

   Besides, when the compiler's given:

       byte1++;

   it compiles it to:

       movf    byte1,w
       incf    byte1

   What's up with THAT?

> The most frequent question from customers, is how to implement
> inline assembly...  This is something that is not possible, and you
> don't need it.

   You DO need it, and it IS possible... To write inline assembly,
   just bracket your assembly code with #ASM and #ENDASM directives.

   I know that Eddie didn't want to spend a lot of money, but if
   anyone else on the list is looking for a "real" C compiler, I
   recommend MPC and MPLAB-C.

   -Andy

=== Andrew Warren - EraseMEfastfwdspamix.netcom.com                 ===
=== Fast Forward Engineering - Vista, California          ===
===                                                       ===
=== Did the information in this post help you?  Consider  ===
=== contributing to the PICLIST Fund.  Details are at:    ===
=== http://www.geocities.com/SiliconValley/2499/fund.html ===

1997\01\10@100956 by James Musselman

flavicon
face
----------
> From: Andrew Warren <RemoveMEfastfwdEraseMEspamEraseMEIX.NETCOM.COM>

>
>     It's important to note that:
>
>     1) CCS doesn't use any high-powered optimization algorithms or
>        anything... The compactness of their generated code is due
>        almost entirely to the fact that the compiler only supports
>        a "Baby-C" subset, ...
>

Thank you Andy for the heads-up on CCS.  I have never, in all the
discussion,
ever heard this on the PICLIST about the CCS compiler.  Are any of the
PICsters C programmers?

>
>     I know that Eddie didn't want to spend a lot of money, but if
>     anyone else on the list is looking for a "real" C compiler, I
>     recommend MPC and MPLAB-C.
>

Our perspective is one of writing production code in RAD environment.
We have extensively used the MPC compiler (MPLAB-C as of release
last summer was a frozen, prior version of MPC according to ByteCraft).
Although Walter Banks
et al at ByteCraft are really good people with outstanding tech support, we
are disappointed with the 18,000 versions of the MPC product.  I have not
tried the latest v1.20 of the linker equipped MPC.

Has anyone used the MPC compiler with linker?

(PS Walter, if your listening, I know it must drive you crazy to try and
write a C compiler for a chip that is so resource limited as the PIC;
Microchip
can't even do it)

1997\01\10@123030 by Walter Banks

picon face
James Musselman wrote:
>
> I have not tried the latest v1.20 of the linker equipped MPC.
>
> Has anyone used the MPC compiler with linker?
>
> (PS Walter, if your listening, I know it must drive you crazy to try and
> write a C compiler for a chip that is so resource limited as the PIC;
> Microchip can't even do it)

Thanks for the comments.

Its tough to write a compiler in public for processors that did not have
an existing high level language and processor family that had many major
variations.

V1.20b that was sent to all our registered users at the end of the
summer
was was designed to stabalize the MPC compiler and the process. In
parallel
to the V1.20 release we had another project working on additions to meet
the
needs of application developers.

Walter Banks
http://www.bytecraft.com

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...