Searching \ for 'CCS C Compiler' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/language/index.htm?key=c
Search entire site for: 'CCS C Compiler'.

Truncated match.
PICList Thread
'CCS C Compiler'
1997\01\10@150541 by CCS

picon face
Andy,

As the producer of the PCB/PCM/PCW C compilers for the PIC and a
member of this PICLIST wanted to reply to your recent PICLIST
posting concerning our compiler.

Since we couldn't find you in our customer list we assume that perhaps
you have our compiler confused with the CC5X compiler also mentioned
interchangeably in the e-mail.

Just to clarify the situation, the CCS compilers are FULL C compilers
(NOT a "Baby-C") except that they do not have the full standard C
library (such as file I/O) and the types are limited to 1,8,16 bit
(no 32 bit and no floating point).  Instead of the standard library
we supply a PIC specific library.

As for your comparison of MPC/LAB-C and ours you have it backwards.
Those compilers are a C Subset.  To prove it try multi-dimensional
arrays, more than two parameters to a function, multi-bit fields
inside structures or simply arrays of structures in MPC/LAB-C.
You will find MPC/LAB-C falls far short of a "real" compiler and
except for standard library functions the CCS compilers are  "real"
C compilers.

The CCS compilers do have full 16 bit arithmetic.  In fact, types of
1,8 and 16 bit are supported where in MPC/LAB-C you can manipulate
a bit of a byte but there is not a true one bit type.

As for the optimization, the more inexpensive PCB/PCM do have areas
where the optimization could be better (PCW does have a higher level
of optimization) but they always produces less code than MPC/LAB-C.
Note that the CCS compilers go to great extent to re-use RAM between
functions that are not executing at the same time.  This is something
a MPC/LAB-C programmer has to do by hand if at all.

The CCS compilers were designed to get people up an running with a new
project as fast as possible.  The easy to use built in functions, such
as RS-232, I/O including formatted printf,  go a long way to
accomplishing this as do the large number of examples.  You can download
our library of example code from http://www.execpc.com/~ccs/download
(Leave the ref# blank and select EXAMPLES) to see the simple but
powerful applications.

It seems we have done a good job of meeting our customer needs since
with over 3000 compilers sold less than 10 have been returned and
customer surveys are almost 100% positive.  The product is always being
updated with new features suggested by customers and we do our best to
respond to customer problems ASAP.  With a product such as this the more
customers there are the better the product becomes due to the large
number of customers giving the product a good "workout."  The low cost
has helped us to build this large customer base.  Do not be tricked into
believing that a higher cost product is better (or even nearly as good).

I don't mean to sound so negative about your e-mail.  I suspect you just
have us confused with another product.  We are most happy to receive
user criticism since this helps us to make our better product, however
it is disturbing when mis-information about the product is so widely
distributed.

If you have further questions about our products feel free to contact me
or visit our web site at http://www.execpc.com/~ccs/picc.html


Regards,

Mark Siegesmund
CCS

1997\01\12@063911 by fastfwd

face
flavicon
face
   Now that I've corrected my earlier C-Compiler message, in which
   I confused CCS's "PCB" and "PCM" compilers with the "CC5X"
   compiler, I guess I should respond to some of the specific
   points that CCS's Mark Siegesmund made in his message on the
   subject.

CCS <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

{Quote hidden}

   Mark:

   Take your PCM compiler and try pointers to longs, pointers to
   shorts, pointers to consts, arrays of shorts, or -- this is
   really inexcusable -- signed math.

   I'll be kind and say that your compilers and MPC are equally far
   from the ANSI standard.

> You will find MPC/LAB-C falls far short of a "real" compiler and
> except for standard library functions the CCS compilers are
> "real" C compilers.

   Aside from the items I mentioned above, the following examples
   (all perfectly legal) fail to compile under PCM/PCB:

   NOTE:  In all the examples to follow, assume the following
          variable declarations:

       short b;    // b is a single bit.
       long v,w;   // v and w are 16-bit words.
       int x,y,z;  // x, y, and z are 8-bit bytes.

   #1:
   ---

       #define newdef define
       #newdef ten 10

   fails to compile, with an "Invalid Preprocessor Directive"
   error.

   #2:
   ---

       int a[] = {1,2,3,4,5};

   fails to compile, with an "Array dimensions must be specified"
   error.

   "If the array has unknown size, the number of initializers in the
   list deternmines the size of the array" (K&R second edition,
   section A8.7).

   #3:
   ---

       const int a[1] = {1};

   fails to compile with an "Unknown type" error.

   #4:
   ---

   The function prototype

       int func (int);

   fails to compile, with an "Expecting an identifier" error.

   #5:
   ---

       int main (int a)
       {
           return main(a);
       }

   fails to compile, with a "recursion not permitted" error.

   "Recursive calls to any function are permitted", K&R second
   edition, Section A7.3.2.

> The CCS compilers do have full 16 bit arithmetic.

   Well, if you call arithmetic that only knows about non-negative
   numbers "full", I guess this is true.

   That isn't to say, however, that your so-called "full 16-bit
   arithmetic" actually WORKS... PCM generates incorrect code, for
   example, for each of the following trivially-simple statements:

       w = 1 << x;
       x = 1 << w;
       w = x << 4;
       return (v & w) ? 1 : 0;
       if (++w) x = 1;
       if (--w) x = 1;
       if (w || x) x = 1;

   I'm sure there are LOTS more... These are just the ones that I'd
   found after an hour of playing with the compiler.

> In fact, types of 1,8 and 16 bit are supported

   Again, I'm not particularly convinced that your products can be
   called "FULL C compilers" when this support fails to include
   pointers to 1-bit or 16-bit elements, arrays of 1-bit elements,
   type conversions that work, or signed math on ANY of the types.

> As for the optimization, the more inexpensive PCB/PCM do have areas
> where the optimization could be better (PCW does have a higher level
> of optimization) but they always produces less code than MPC/LAB-C.

   This is demonstrably false.

   I won't bore you with a long list of optimization blunders that
   PCM makes, but I should at least point out one of the more
   egregious examples:

       w = x * 256;

   could compile to:

       clrf    w_lo
       movf    x,w
       movwf   w_hi

   but instead, it compiles to 33 instructrions which require
   HUNDREDS of cycles to execute (yes, it calls a general-purpose
   16x16 multiplication subroutine).

   Fix that... It's embarrassing.

> The CCS compilers were designed to get people up an running with a
> new project as fast as possible.  The easy to use built in
> functions, such as RS-232, I/O including formatted printf,  go a
> long way to accomplishing this as do the large number of examples.

   Yeah, the built-in functions are nice, but we're talking about
   the compiler, not its libraries.

   Besides, I hear that those libraries have bugs.

> The product is always being updated with new features suggested by
> customers and we do our best to respond to customer problems ASAP.

   Cool... Here's a problem you can fix. The following program hangs
   the compiler and requires rebooting the computer to recover:

       #define a b
       #define b a
       a

> With a product such as this the more customers there are the better
> the product becomes due to the large number of customers giving the
> product a good "workout."  The low cost has helped us to build this
> large customer base.

   So you're saying that you have over 3000 unpaid beta testers
   each of whose problems are responded to "ASAP", yet you haven't
   discovered or managed to eradicate the bugs I found in just a
   couple of hours?  I don't know what to say to this.

> We are most happy to receive user criticism since this helps us to
> make our better product, however it is disturbing when
> mis-information about the product is so widely distributed.

   Sorry about the PCM/CC5X confusion in my earlier message.  If
   anything I've said in this message is incorrect, please let me
   know.

   By the way, the compiler used for all the examples I gave was
   PCM version 2.204.

   -Andy

   P.S.  Just my opinion... I could be wrong.

Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1997\01\12@074251 by Clyde Smith-Stubbs

flavicon
face
Sorry Andy, I just have to butt in here about a couple of things -
I've got no real experience with CCS's products, but these things
need rebuttal:

Thus spake Andrew Warren (fastfwdspamKILLspamIX.NETCOM.COM):

>         #define newdef define
>         #newdef ten 10
>
>     fails to compile, with an "Invalid Preprocessor Directive"
>     error.

And so it should! You cannot define new preprocessor directives under
ANSI C.

>         int main (int a)
>         {
>             return main(a);
>         }
>
>     fails to compile, with a "recursion not permitted" error.

Non-ANSI, yes, but it is architecturally impossible to implement recursion
in any reasonable manner on a PIC, owing to its lack of anything closely
resembling a stack. BTW Andy, when discussing ANSI C it is better to
reference the ANSI standard rather then K&R, which has a few errors. I'd also
remind you that ANSI permits a free-standing implementation some latitude in
certain features compared to a hosted implementation of C.

Your comment about lack of pointers to single bits is off the mark - since
there's no bit pointer type supported by the hardware and to implement it in
software would be horrendously inefficient, it's best left out (and since
single-bit variables are not an ANSI feature, that's not an issue).

I have no comment to make on the other problems you found except to say
that if accurate, they need attention.

Cheers, Clyde

--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
.....clydeKILLspamspam.....htsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\01\12@145053 by timetech

flavicon
face
Clyde Smith-Stubbs wrote:

> BTW Andy, when discussing ANSI C it is better to reference the ANSI standard >
rather then K&R, which has a few errors.

Two good references for this are Harbison & Steele and the Plauger book
on the ANSI standard from Microsoft press.

--Tom Rogers

1997\01\12@171528 by EVAN CRANNA

flavicon
face
Mark, I followed your reply and was glad to see your response. We are on
the verge of buying a compiler and have been looking at CCx closely.
There are still a few questions tho. One is whether it supports
floating point math and if not then when.
Thx
   Evan Cranna

1997\01\12@221810 by fastfwd

face
flavicon
face
Clyde Smith-Stubbs <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> wrote:

> Sorry Andy, I just have to butt in here about a couple of things -
> I've got no real experience with CCS's products, but these things
> need rebuttal .... You cannot define new preprocessor directives
> under ANSI C.

   Clyde:

   Thanks for the info... I didn't know that.

{Quote hidden}

   I didn't say it would be easy, or even that I like using
   recursive functions (I don't).  This was simply one in a series of
   rebuttals to the claim that the CCS compilers are "full C".

> BTW Andy, when discussing ANSI C it is better to reference the ANSI
> standard rather then K&R, which has a few errors.

   True... But K&R's all I have.

> I'd also remind you that ANSI permits a free-standing
> implementation some latitude in certain features compared to a
> hosted implementation of C.

   I'm not sure how the issue became "ANSI C" compatibility.

   Mark didn't claim that his compiler was ANSI-compliant, and I
   wouldn't hold any embedded-C compiler to that standard, anyway...
   Although I mentioned ANSI once in my last nessage, what I was
   really trying to discuss was whether the compiler was compliant
   with the (admittedly less formal) definition of a "full" C
   compiler.

   We each may have our own ideas of what constitutes "full C" for a
   small embedded processor.  Rather than nitpicking about features
   like floats, pointers to functions, etc., I tried to choose
   features and operations that are likely to be used in a small PIC
   application.

   I admit that the cross-referenced #defines that crash the
   compiler, and the preprocessor-directive redefinition that you
   mentioned above, were somehwat contrived.

   I think the rest of my examples, though, were pretty realistic.

> Your comment about lack of pointers to single bits is off the mark -
> since there's no bit pointer type supported by the hardware and to
> implement it in software would be horrendously inefficient, it's
> best left out (and since single-bit variables are not an ANSI
> feature, that's not an issue).

   Again, I didn't mean for the issue to be ANSI compliance. Arrays
   of bits (and/or pointers to bits) are VERY commonly used in PIC
   applications; a compiler that supports single-bit variables should
   also support arrays of, or pointers to, those variables.

   Besides, 16-bit variables aren't directly supported by the
   hardware, either, but the CCS compilers manage (more or less) to
   support THEM.

> I have no comment to make on the other problems you found except to
> say that if accurate, they need attention.

   They're accurate when compiled with the version of PCM (2.2.04)
   that I used for my tests.

   I'm aware that there are newer versions of the CCS compiler... I
   suspect that some of the issues I raised have been addressed in
   those later versions.

   Nevertheless, the fact that I was able to find those bugs so
   quickly implies -- as everyone who's done any formal software
   testing knows -- that there are many more bugs waiting to be
   found.

   I hope no one (including Mark Siegesmund at CCS) takes my
   comments the wrong way... I have no doubt that PCM (even with
   the shortcomings I mentioned) is suitable for many PIC
   applications, and I certainly have no personal ax to grind with
   CCS.

   -Andy

Andrew Warren - fastfwdspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1997\01\13@015055 by Clyde Smith-Stubbs

flavicon
face
Thus spake Andrew Warren (@spam@fastfwdKILLspamspamIX.NETCOM.COM):

>     We each may have our own ideas of what constitutes "full C" for a
>     small embedded processor.  Rather than nitpicking about features
>     like floats, pointers to functions, etc., I tried to choose
>     features and operations that are likely to be used in a small PIC
>     application.

There are two problems with that - firstly you're having a bet each way -
if you are judging the compiler by its usefulness for typical PIC
applications, then issues like recursion and pointers to bits are
irrelevant (you concede yourself that you have no use for recursion,
and I seriously doubt you ever even considered using a pointer to a bit
in an assembler program).

The other problem is, as you said, everyone might have their own ideas about
what they want in a compiler. This leads to the Pascal syndrome, where you
have 746 different and incompatible compilers each claiming to implement
the same language. This is the whole reason for having a standard, and
the standard for C is the ANSI/ISO standard. If you're going to judge
a C compiler against anything I believe this is the only thing you
can judge it against (straightout bugs are, of course, a different
issue).

By this measure the CCS doesn't shape up well, but it isn't claimed to
be ANSI compatible. CCS do compare their product to the competition by saying
"The other compilers we have seen are limited compilers that only resemble
real C". I don't see anywhere that they claim their compiler DOES resemble
"real C", whatever that is. The claim in this mailing list that the CCS
compilers are "full C" is equally fuzzy.

Now ANSI C lacks a few things needed for embedded work; specifically:

* Support for multiple address spaces (ANSI C supports only one code and one
 data address space)
* Simple access to hardwired addresses
* Interrupt support
* Bit variables

There are other things, but they can mostly be provided without altering the
language. The points above are difficult to support in an ergonomic fashion
without extending the language - the challenge is to do so in a way that
alters the language as little as possible.

But given minor extensions, ANSI C can do an excellent job on low-end
microcontrollers, with a good optimizing compiler. And using a standard
language allows you to use such features as long or float arithmetic if
you need them (but suffer no cost if you don't).

The huge benefit of using an ANSI compiler on a PIC is not so much portability
of code (which is important, but less so than on larger processors) but
portability of people, i.e. programmers.

Anyway, getting back to CCS - apart from the issue of bugs, which presumably
can be fixed, providing it's not claimed to be a standard C compiler, and
it's limitations are documented and understood by the user, it's probably
very adequate for some applications, and it's certainly cheap. I suspect
it represents rather better value for money than Bytecraft's or Microchip's
compilers, which suffer from their own problems, and are certainly not
ANSI compliant either. Cost aside, whether it's "better" than those
products will depend on the application for which it is used.

For the record, I think using "short" for a bit variable, and "long" for
a 16 bit is a Bad Idea, as is Bytecraft's thing.0 notation for bit access.
These are unnecessary and confusing.

--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
KILLspamclydeKILLspamspamhtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\01\13@015257 by Werner Terreblanche

flavicon
face
snip-snip

> It seems we have done a good job of meeting our customer needs since
> with over 3000 compilers sold less than 10 have been returned and
> customer surveys are almost 100% positive.  The product is always
> being updated with new features suggested by customers and we do our
> best to respond to customer problems ASAP.  With a product such as
> this the more

As a another  satisfied used of the CCS compiler, I've just got one
small frustration...  I recently contacted CCS with a complaint that
the header file for the PIC16C711 doesn't work, and CCS advised me to
look on your Web page and download the latest header file.

When I tried to download it from you web page, I discovered
that I need my original invoice number to download.  However, if
you work for a large company like I do, you as the engineer *never*
even *see* the invoice yourself.  It gets handled by our accounting
department.  The end result was that I could never download the
upgraded header file and therefore could not use your compiler with
the PIC16C711 microcontrollers.  It will be very nice if you could
make it a little bit easier to download those update files.

Other than that I can recommend the CCS compiler and have done so to
several people already.

Rgds
Werner
--
Werner Terreblanche     http://www.aztec.co.za/users/werner
RemoveMEwterrebTakeThisOuTspamplessey.co.za (work)  OR  spamBeGonewernerspamBeGonespamaztec.co.za  (home)
Plessey SA, PO Box 30451,Tokai 7966, Cape Town, South Africa
or (Suite 251, PostNet X5061, Stellenbosch, 7599)
Tel +27 21 7102251   Fax +27 21 721278   Cell +27 837255164
------------------------------------------------------------

1997\01\13@022653 by fastfwd

face
flavicon
face
Clyde Smith-Stubbs <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU> wrote:

> There are two problems with [trying to judge a compiler against a
> subjective "real" or "full" C standard rather than against the
> ANSI standard] - firstly you're having a bet each way - if you are
> judging the compiler by its usefulness for typical PIC
> applications, then issues like recursion and pointers to bits are
> irrelevant (you concede yourself that you have no use for
> recursion, and I seriously doubt you ever even considered using a
> pointer to a bit in an assembler program).

   Clyde:

   Actually, I use the machine-language equivalent of pointers to
   bits often enough that I've written a whole set of MPASM macros
   to handle them.

> The other problem is, as you said, everyone might have their own
> ideas about what they want in a compiler.

   Happily conceded.  However, I think we can all agree that a
   compiler should be able to handle negative numbers, that if it
   understands pointers AND 16-bit variables it should also
   understand pointers TO 16-bit variables, and that it should be
   able to perform basic type conversions between 8-bit and 16-bit
   variables.

> given minor extensions, ANSI C can do an excellent job on low-end
> microcontrollers, with a good optimizing compiler. And using a
> standard language allows you to use such features as long or float
> arithmetic if you need them (but suffer no cost if you don't).
>
> The huge benefit of using an ANSI compiler on a PIC is not so much
> portability of code (which is important, but less so than on larger
> processors) but portability of people, i.e. programmers.

   I couldn't agree more.  In fact, the answer to Question #12,
   "What are the relative merits of C versus Assembly-Language for
   microcontroller programming?" (in the "Miscellaneous" section of
   the "Answers" area on my company's web page) includes the
   following:

       If you spend your whole life honing your assembly-language
       skills, you won't be nearly as employable as any of the
       hundreds of thousands of C programmers out there. While C
       PROGRAMS aren't always portable from one processor to
       another, C PROGRAMMERS are.

> For the record, I think using "short" for a bit variable, and "long"
> for a 16 bit is a Bad Idea, as is Bytecraft's thing.0 notation for
> bit access.

   For the record, I agree wholeheartedly.

   -Andy

   P.S.  As usual... Just my opinion; I could be wrong.

Andrew Warren - RemoveMEfastfwdspamTakeThisOuTix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1997\01\13@095648 by Walter Banks

picon face
Both Andrew Warren and Clyde Smith-Stubbs have recently made
comments on the notation (object.bit) used for bits and port
declarations in MPC.

This notation originated in our C6805 compiler to take advantage of
the some speciallized instructions that the 6805 has. At the time
we were only interested in developing code for the 6805. Like the
bit addressable features of the 8051 it was a processor specific
feature. When we created compilers for other processors we were
retained the notation to allow application developers to port
their code between target famillies.

Since last fall we have been supporting a super set of the various
bit/bits notations including ANSI structure bit fields. This is a
standard part of each new release of our compilers. The next release
of MPC has this support.

Walter Banks
http://www.bytecraft.com

1997\01\13@141740 by Martin J. Maney

flavicon
face
On Sun, 12 Jan 1997, Andrew Warren wrote:

>     I'm not sure how the issue became "ANSI C" compatibility.
>
>     Mark didn't claim that his compiler was ANSI-compliant, and I
>     wouldn't hold any embedded-C compiler to that standard, anyway...
>     Although I mentioned ANSI once in my last nessage, what I was
>     really trying to discuss was whether the compiler was compliant
>     with the (admittedly less formal) definition of a "full" C
>     compiler.

What is "full C" if not the language defined by the ANSI/ISO standard?

>     We each may have our own ideas of what constitutes "full C" for a
>     small embedded processor.  Rather than nitpicking about features
>     like floats, pointers to functions, etc., I tried to choose
>     features and operations that are likely to be used in a small PIC
>     application.

That's fine and probably even sensible, but that approach will lead to the
situation where different folks have differetn ideas of what "full C"
means - I think we see that happening here, eh?

>     Again, I didn't mean for the issue to be ANSI compliance. Arrays
>     of bits (and/or pointers to bits) are VERY commonly used in PIC
>     applications; a compiler that supports single-bit variables should
>     also support arrays of, or pointers to, those variables.

Well, it would be useful, but this is not a notion that is supported by
the Standard C language.  Which, BTW, does have a bitfield type that comes
very close to being a single-bit variable, but there aren't any arrays of
them in the language...

I think the problem is that everyone has been tossing around ill-defined
phrases like "full C" with not agreement on what that might mean, and
that's pretty much a waste of everyone's time (ie, now more time gets
spent sorting out, and perhaps arguing about, the "correct" definition -
pfui!).

AndOfCourse all this other stuff also detracts from the valid, and I would
agree to say, serious, deficencies you described.

1997\01\13@150723 by Wolfgang.Kynast

flavicon
face
> Andrew Warren <PICLISTEraseMEspam.....MITVMA.MIT.EDU> wrote:
>
>     Again, I didn't mean for the issue to be ANSI compliance. Arrays
>     of bits (and/or pointers to bits) are VERY commonly used in PIC
>     applications; a compiler that supports single-bit variables should
>     also support arrays of, or pointers to, those variables.
>

Andy,

K&R only define bit fields inside of struct's, as some kind of
redefinition of an int's, and state:
"They are not arrays, and they do not have addresses, so the &
operator cannot be applied to them"
which means also that there are no pointers to bits.
Of course, these features would be very nice to have, but they would
be an unportable extension of C.

Kind regards,
Wolfgang

1997\01\13@151823 by James Musselman

flavicon
face
> Andrew Warren <EraseMEPICLISTspamMITVMA.MIT.EDU> wrote:
>
>         Arrays
>     of bits (and/or pointers to bits) are VERY commonly used in PIC
>     applications;
>

As long as we are all PICking this apart-
How do you know this?

1997\01\13@161824 by fastfwd

face
flavicon
face
I wrote:

> > Arrays of bits (and/or pointers to bits) are VERY commonly used
> > in PIC applications

and James Musselman <RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU> replied:

> As long as we are all PICking this apart- How do you know this?

James:

I know they're common from seeing their use in my own code, in code
written by others, and in questions posted to the PICLIST.

Personally, as I mentioned in my last public message to Clyde
Smith-Stubbs, I use them often enough that I've written a set of
MPASM macros to read, set, reset, toggle, and copy the states of
arbitrary bits in large bit-arrays.  An example macro invocation
looks like:

   SETBIT FLAGS,BITPOINTER

where FLAGS is the name of the register where the array of bits
starts, and BITPOINTER is the name of the register which points to
the bit you want to set.

-Andy

Andrew Warren - RemoveMEfastfwdspam_OUTspamKILLspamix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1997\01\13@183811 by Ben Wirz

flavicon
face
Hello Everyon,

       I wanted to comment on the great CCS C debate.  I started using the
PCM complier when I first got started in PIC's and it suited my needs fine
and allowed me to get up and running with PIC's with a miminum of problems.
Personally I think it is a great way for a person who is relatively new to
microprocessors to get started fast.  After you get a PIC to flash a LED the
first time with your own code, it's all downhill from there:)  With some
experience, PIC assembly not too bad either.

       Note that I said this was for a person learning Mircroprocessors for
the first time, an Assembly expert won't need to ask where to start.

Ben,

P.S.  I owe Perter Cousins and the list an appologize for my duplicate
postings.  I realized I did this right after I sent it but it I didn't want
to waste bandwidth with another appology post.

1997\01\13@193309 by James Musselman

flavicon
face
At 11:54 PM 1/13/97 -0000, you wrote:
>Andrew Warren <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.MIT.EDU> wrote:
>> Arrays of bits (and/or pointers to bits) are VERY commonly used in PIC
>> applications;
>
>James Musselman <EraseMEjamesspamspamspamBeGoneRADIXGROUP.COM> replied:
>> As long as we are all PICking this apart-
>> How do you know this?
>
>Arrays of bits are certainly commonly used in *my* PIC programs.
> ... then use a sequence like:
>        btfsc   inport,inbit
>        bsf     buffer+0,0
>        [...]
>

That's fine, but the discussion was about C programming, not assembly.
Andrew's statement
was of interest to me because I wondered a) how he knew how other people
programmed
in C and 2) my main interest is how this was done, since I don't believe
arrays of bits, or bit operations
in general for that matter,  are well supported (?) in any of the
existing compilers.

1997\01\13@202921 by fastfwd

face
flavicon
face
James Musselman <RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU> wrote:

> the discussion was about C programming, not assembly.

   Sorry, James... I guess I wasn't clear enough; I was claiming
   that arrays of bits were common in ASSEMBLY programs.

   My original assertion ("arrays of bits are very common in PIC
   applications") was in response to Clyde Smith-Stubbs' comment
   that "since there's no bit pointer type supported by the hardware
   .... to implement [bit arrays] in software would be horribly
   inefficient."

   All I was saying was that such structures couldn't be all THAT
   inefficient if they were already being used in lots of existing
   PIC programs.  Since they're so commonly used (and relatively
   easy to implement) by assembly-language programmers, I felt that
   they should also be available to C programmers.

   Those existing PIC programs to which I was referring were
   assembly-language programs, not C programs.  This was made
   clearer in my next message to Clyde... He said, "I seriously
   doubt you ever even considered using a pointer to a bit in an
   assembler program" and I replied that I had not only CONSIDERED
   using them, but that I use them often enough that I've written
   MPASM macros to automate the task.

> I don't believe arrays of bits, or bit operations in general for
> that matter,  are well supported (?) in any of the existing
> compilers.

   We're in violent agreement here; in fact, this is exactly the
   point I was originally making.

   Sorry for the misunderstanding.

   -Andy

Andrew Warren - fastfwdSTOPspamspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1997\01\13@232404 by James Musselman

flavicon
face
At 05:34 PM 1/13/97 -0800, you wrote:
>James Musselman <spamBeGonePICLISTSTOPspamspamEraseMEMITVMA.MIT.EDU> wrote:
>
>    All I was saying was that such structures couldn't be all THAT
>    inefficient if they were already being used in lots of existing
>    PIC programs.  Since they're so commonly used (and relatively
>    easy to implement) by assembly-language programmers, I felt that
>    they should also be available to C programmers.
>

This is an excellent point.  In addition, there are many things I'd
also like to see in the C compilers.  But, I would be really happy just
to have stability and reliability for starters.

1997\01\13@233218 by Robert Lunn

flavicon
face
>What is "full C" if not the language defined by the ANSI/ISO standard?

       In my experience, there is a distinction between 'small-C',
       'K&R C', and 'ANSI C'.

       The 'small-C' compilers are usually targetted to specific micros
       and implement (sometimes highly restricted) subsets of 'full-C',
       by which is normally meant 'K&R C'.

       The 'small-C' designation (and the consequential 'full-C' and
       'tiny-C' labels) largely arose from the articles published in
       the late seventies and early eighties by various computer
       magazines (most notably 'Dr. Dobbs'), which detailed the
       implementation of various C compilers.

       Note that 'ANSI C' is a nineties phenomenon.  In a few years
       (when us old programmers die out) the designation 'full-C'
       will become synonomous with 'ANSI C', and K&R will be the
       stuff of legend.

___Bob

1997\01\14@013154 by Clyde Smith-Stubbs

flavicon
face
Thus spake Robert Lunn (KILLspamrobertspamBeGonespamRDD.NECA.NEC.COM.AU):

>         Note that 'ANSI C' is a nineties phenomenon.  In a few years
>         (when us old programmers die out) the designation 'full-C'
>         will become synonomous with 'ANSI C', and K&R will be the
>         stuff of legend.

ANSI C has been around since 1985. K&R C is already the stuff of legend.

(The ANSI C standard was finalized around 1989, but drafts very close to
the final version were circulating in 1985, and many ANSI compilers date from
then).
--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
EraseMEclydespamEraseMEhtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\01\14@015905 by Robert Lunn

flavicon
face
>>         Note that 'ANSI C' is a nineties phenomenon.
>
>ANSI C has been around since 1985. K&R C is already the stuff of legend.

       Ok, I'll say _largely_ a 90's phenomenon.  As an opinion, I
       would say that even through the late 80's it was K&R C that
       was the 'reference' for C.  Note that I'm talking about
       programmers in the field, not necessarily guys who work for
       companies that write compilers. ;)

___Bob

1997\01\14@020056 by Robert Lunn

flavicon
face
>>         Note that 'ANSI C' is a nineties phenomenon.
>
>ANSI C has been around since 1985. K&R C is already the stuff of legend.

       ...Actually, even today how many C programmers _don't_ have
       a dogeared copy of K&R's "The C Programming Language" on
       their shelf?

___Bob

1997\01\14@022027 by Clyde Smith-Stubbs

flavicon
face
Thus spake Robert Lunn (@spam@robert@spam@spamspam_OUTRDD.NECA.NEC.COM.AU):

>         ...Actually, even today how many C programmers _don't_ have
>         a dogeared copy of K&R's "The C Programming Language" on
>         their shelf?

Well, me for one. K&R was the original reference, but it was not then
and is not now a particularly well written book. If you want a reference,
get the Standard - ("The Annotated ANSI C Standard", by Schildt, Osborne
McGraw-Hill,
1990, ISBN 0-07-881952-0) - if you want a tutorial, I recommend "Programming in
ANSI C", by
Stephen Kochan, SAMS 1994, ISBN 0672303396.

Cheers.
--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
spamBeGoneclydespamKILLspamhtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\01\14@084746 by timetech

flavicon
face
Robert Lunn wrote:

>         Ok, I'll say _largely_ a 90's phenomenon.  As an opinion, I
>         would say that even through the late 80's it was K&R C that
>         was the 'reference' for C.  Note that I'm talking about
>         programmers in the field, not necessarily guys who work for
>         companies that write compilers. ;)

Uh, Guys, Harbison & Steele is on the bookshelf of every C programmer I
know..

-- Tom Rogers

1997\01\14@101836 by Martin J. Maney

flavicon
face
On Tue, 14 Jan 1997, Robert Lunn wrote:

> >What is "full C" if not the language defined by the ANSI/ISO standard?
>
>         In my experience, there is a distinction between 'small-C',
>         'K&R C', and 'ANSI C'.

Yes, all but the last are only loosely defined.  :-)

>         The 'small-C' compilers are usually targetted to specific micros
>         and implement (sometimes highly restricted) subsets of 'full-C',
>         by which is normally meant 'K&R C'.

Yes, back then K&R was the de-facto standard, insofar as there was one.  I
still have a rather used copy, of course.

>         The 'small-C' designation (and the consequential 'full-C' and

I don't recall ever having seen "full C [language]" used in any sense
other than to claim complete implementation of, depending on the time,
K&R, draft ANSI, or Standard C.  Er, until this thread came along, that
is.

>         Note that 'ANSI C' is a nineties phenomenon.  In a few years
>         (when us old programmers die out) the designation 'full-C'
>         will become synonomous with 'ANSI C', and K&R will be the
>         stuff of legend.

Strange, I was using compilers that had most of the then-draft ANSI
language, at least aside from the more obscure or new features, by the
middle of the last decade.  The final draft is ten years old this year,
thought there was a procedural error that caused formal ratification to be
delayed.  Still, The ANSI standard is getting close to ten years old, and
the work on the next revision is well underway.  And, well, it has been
the nineties for a good long while now...  :-)

I certainly agree that a full implementation of (unhosted) Standard C for
the 12 or 14 bit members of the PIC family is more a wonder than a truly
useful thing (I reserve judgement about the 17Cxx parts as I have no
experience with them); however, I don't think that makes a good argument
against using Standard C as the standard of comparison.  It is the only
clearly defined base against which to describe the omissions and additions
of a well-crated dialect that targets a small microcontroller - and it's
the only part that can really contribute much to the portability of
programmers that's been mentioned recently.

1997\01\14@135433 by John Halleck

flavicon
face
On Tue, 14 Jan 1997, terogers wrote:

> Robert Lunn wrote:
>
> >         Ok, I'll say _largely_ a 90's phenomenon.  As an opinion, I
> >         would say that even through the late 80's it was K&R C that
> >         was the 'reference' for C.  Note that I'm talking about
> >         programmers in the field, not necessarily guys who work for
> >         companies that write compilers. ;)
>
> Uh, Guys, Harbison & Steele is on the bookshelf of every C programmer I
> know..

 In the 80's it was K&R.   Now it is Harbison & Steele.

 (Hopefully not the first edition of Harbison & Steele, I submitted
  enough error reports on the "C Grammer" section that it was pulled
  totally in later editions.)

> -- Tom Rogers

1997\01\14@160550 by William Chops Westfield

face picon face
   >         Note that 'ANSI C' is a nineties phenomenon.  In a few years
   >         (when us old programmers die out) the designation 'full-C'
   >         will become synonomous with 'ANSI C', and K&R will be the
   >         stuff of legend.

   Strange, I was using compilers that had most of the then-draft ANSI
   language, at least aside from the more obscure or new features, by the
   middle of the last decade.

It was definately the 90's before we started using (in a multi-megabyte C
embedded system) Ansi style function definitions (void foo (int a, char *b))
rather than K&R style definitions (void foo(a,b) int a; char *b;), and you
can still generate a heated debate by suggesting that certain functions be
converted to their ansi counterparts...

BillW

1997\01\14@172023 by Clyde Smith-Stubbs

flavicon
face
Thus spake William Chops Westfield (.....billwspam_OUTspamCISCO.COM):

> It was definately the 90's before we started using (in a multi-megabyte C
> embedded system) Ansi style function definitions (void foo (int a, char *b))

I assume you're speaking from the perspective of Cisco, and I would
imagine you had (have?) a large code investment written in K&R C, but
embedded ANSI C compilers were both in demand and in use by 1987.

--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
TakeThisOuTclyde.....spamTakeThisOuThtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\01\14@200842 by Martin J. Maney

flavicon
face
On Tue, 14 Jan 1997, terogers wrote:

> >         Ok, I'll say _largely_ a 90's phenomenon.  As an opinion, I
> >         would say that even through the late 80's it was K&R C that
> >         was the 'reference' for C.  Note that I'm talking about
> >         programmers in the field, not necessarily guys who work for
> >         companies that write compilers. ;)
>
> Uh, Guys, Harbison & Steele is on the bookshelf of every C programmer I
> know..

I just love being an odd statistic!  I started out with K&R back when that
was damned near all there was, and along about the time I probably should
have been reading H&S - I understand they did a fine job of sorting out
what was and wasn't generally portable in practice - I was far more
interested in the ANSI standardization effort.  So I never have owned a
copy of H&S, nor even held one for more than a couple tens of minutes, and
I was writing C under CP/M, DOS, AMOS, Xenix, and I don't recall what all
else back in the eighties.

Not that I necessarily recommend this approach...  :-)

1997\01\15@085600 by EVAN CRANNA

flavicon
face
Clyde...I am sure you receieve tons of e-mail and my question may have
gotten lost somewhere.  So I thought I'd break in here to get your
undivided attention. My question relates to using your C compiler and
programming a PIC16C84 using Micrchips 16B programmer...The 16B
programmer does not load the code generated from your Compiler..ie
neither led.hex or led.obj loads. Suggestions?
Thx Evan


'CCS C COMPILER'
1998\05\11@042242 by -Dossary %166.87.109.11%
flavicon
face
I purchased CCS C compiler the for $99. it included a manual and some
example programs  with it . are there any body out there who can direct
me to web sites for some tutorials for programming the pic with CCS
compiler ?


'CCS C Compiler'
1998\12\19@131947 by Cumhur Kizilari
flavicon
face
I have got CCS C Compiler
and I have some problems about printing Unsigned Long Integer Numbers

if I write

unsigned long int any_long_variable;

any_long_variable =256;
printf(" %lu ",any_long_variable);

In screen (via RS232) appears only 0x20 chars(lots of space)

Are there any experience about this problem ?

Thanks For All Answers
Cumhur Kizilari
ICQ:4910324


'CCS C Compiler'
1999\06\04@230146 by Jamil J. Weatherbee
flavicon
face
CCS C compiler is the one with a lot of library functions for about $99,
I've heard good reports about it.  Anyone know if I will have any problems
on a 16c73a?

Does anyone know where I can order this online and download it.

1999\06\05@003913 by Eric Oliver

flavicon
face
www.ccsinfo.com

Various users have reported problems with the CCS compiler on this list.  I
have owned it for a short time and given it limited usage. Can't really
comment on it's quality yet. The reasons I bought it :

Supports a wide range of PICs
Larger library than any freeware c compiler I found
Could not afford an industrial strength compiler

Eric

On Friday, June 04, 1999 10:00 PM, Jamil J. Weatherbee
[SMTP:TakeThisOuTjamilKILLspamspamspamSCOTTIBOX.COM] wrote:
> CCS C compiler is the one with a lot of library functions for about $99,
> I've heard good reports about it.  Anyone know if I will have any
problems
> on a 16c73a?
>
> Does anyone know where I can order this online and download it.

1999\06\05@103623 by ronruss

flavicon
face
You can order a copy for $89 online at the PicWiser site;

http://www.picwiser.com

There isn't an 'online download' delivery system but it ships
immediately using Priority Mail and arrives in 2 or 3 days.

Jamil J. Weatherbee wrote:

> CCS C compiler is the one with a lot of library functions for about $99,
> I've heard good reports about it.  Anyone know if I will have any problems
> on a 16c73a?
>
> Does anyone know where I can order this online and download it.



--

From: Ron Russ
  EMICROS  - Embedded Micro Software
 (http://www.emicros.com)
  CANPORT  - Lowest cost PC to Controller Area Network Adapter
 (http://www.emicros.com/canport.htm)
  CANTEC11 - 68HC11 SBC with Controller Area Network
 (http://www.emicros.com/cantec11.htm)

1999\06\07@102752 by Lawrence Lile

flavicon
face
I'm doing a lot of work with CCS.  I bought it for two reasons -

1.  I wanted to learn C without a big $ investment.

2.  I coulnd't convince my boss that I needed a C compiler.  He is still
stuck on "Why didn't you buy B compiler or A compiler first?" and "What do
you need a compiler for, anyway? "  (See Dilbert.com for further explanation
of boss behaviour)

Let's face it, a microcontroller is a finicky beast in ANY language.  Much
of my struggle has simply been learnming curve on how any high level
language deals with hardware.  I have retracted my earliest vitriolic
comments and now believe that CCS is a decent tool and I didn't know how to
use it.  Given the price range of the competition  ($150 to $700???) it is
low up front cost (plus $100 a year support!) and it's features and brief
documentation  match it's price level.  It is NOT the best, but it IS a
useful tool.



{Original Message removed}

1999\06\09@201714 by Roger Morella

flavicon
face
"Jamil J. Weatherbee" wrote:

> CCS C compiler is the one with a lot of library functions for about $99,
> I've heard good reports about it.  Anyone know if I will have any problems
> on a 16c73a?
>
> Does anyone know where I can order this online and download it.

I have been using the CCS compilers for 4 ro 5 years and, as far as I am
concerned, its as good as any other.  They offer the closest thing to an EC
(Embedded C) compiler that I have come across.

You can order it from CCS and download it (
http://www.ccsinfo.com/download.html ) after they give you the order number
over the phone.  I would recommend ordering the PCM compiler first since this
is the one that works with 14 bit devices like the 16C73.  The PCB compiler
works with 12 bit devices such as the basic 16C56.  Each of these are $99 each
(+ $7 s/h) or you can buy the development package which includes both
compilers and an IDE for $350.

I use it with MicroChips MPLAB (which you can download from MIcroChip site)
and it works great.  I have only had to use the CCS IDE a few times in order
to take advantage of the memory reporting and listing features for code
optimization purposes, however,  I have used it often enough to justify the
extra $150.

You can practice optimization techniques very easily using MPLABs simulator
mode and the PICC compiler. The best way to do this is the old fashion single
stepping through the program listing.  I have discovered a few bugs this way.
but, so far, they have been fairly easy to work around.  The support at CCS
has been great.  They have been very quick to get updates on their web page
immediately, and have even let me download the updates after the 30 day
warrenty expired, if I could show them that a bug has caused me to "hit a
wall".

If code optimization is essential, you will have to do some assembly coding. I
have only had to do this a few times and, as I become more familiar with
writing C code and the CCS compilers, it is becoming increasingly rare that I
have to resort to writing any assembler at all.

In my opinion, mixing the 14 bit PCM compiler with the Micro Chip MPLAB
development software, gives you a real bargain at $106  giving you a PIC
processor simulator with, editor, and compiler.

1999\06\10@081543 by Andy Kunz

flavicon
face
>concerned, its as good as any other.  They offer the closest thing to an EC

Yup, and Hitler was about as good a politician as Bill/ary.

Andy
==================================================================
  Andy Kunz - http://www.montanadesign.com - .....andyspamRemoveMEmontanadesign.com
          Life is what we do to prepare for Eternity
==================================================================

1999\06\15@175408 by Roger Morella

flavicon
face
Your sarcastic response is annoying, as well as, useless.  If you don't agree
with my opinion, you should consider a response that is more informative, so
that myself and others might actually learn something from your words. I don't
mind debating any of my opinions, and stand ready to be corrected when whatever
I say falls short of the mark,  but it's kinda hard to debate a response that is
the equivalent of sticking your thumbs in your ears, and wiggling your fingers,
while blurting out a raspberry. (at least without fealing foolish)

Andy Kunz wrote:

> >concerned, its as good as any other.  They offer the closest thing to an EC
>
> Yup, and Hitler was about as good a politician as Bill/ary.
>
> Andy
> ==================================================================
>    Andy Kunz - http://www.montanadesign.com - RemoveMEandyspamspamBeGonemontanadesign.com
>            Life is what we do to prepare for Eternity
> ==================================================================

1999\06\15@181945 by Andy Kunz

flavicon
face
Check the comments of others using CCS.  It is not a SERIOUS development
tool.  It is a great hobbyist tool, if you can deal with the bugs.

I bought it.  I got screwed by having a different version every day.  It
had more bugs than a dead possum, and more with every release.  I sold it
to someone who wanted it for hobby purposes, and he has been happy with it
(to my knowledge).

I have fewer updates (ie, bugs) to the HiTech PICC compiler in the past
couple years than I had in a few months with CCS.

Now are you happy?

PS.  Sorry it appeared sarcastic.  Actually, I would personally put
Bill/ary and Adolph in the same camp so far as personal liberties,
understanding of right and wrong, and basic disregard for the law go.

>Your sarcastic response is annoying, as well as, useless.  If you don't agree
>with my opinion, you should consider a response that is more informative, so
>that myself and others might actually learn something from your words. I don't
>mind debating any of my opinions, and stand ready to be corrected when
whatever
>I say falls short of the mark,  but it's kinda hard to debate a response
>that is
>the equivalent of sticking your thumbs in your ears, and wiggling your
fingers,
{Quote hidden}

==================================================================
  Andy Kunz - http://www.montanadesign.com - TakeThisOuTandyspamspammontanadesign.com
          Life is what we do to prepare for Eternity
==================================================================

1999\06\16@084409 by Barry King

flavicon
face
Despite Andy's inappropriate political asides, I agree with his
opinion- about the compiler.

The problems are mostly in support of large-RAM parts.  The banking
bits are the nemesis of assembly programmers, and the CCS code
generator, too, it seems.

It works for the simpler chips, and the high level "library" routines
for some I/O gets a very fast jump start on some projects.   Do not
try to use it for large RAM, especially with "far" pointers, unless
they fixed a lot of things in the last few months.

A happy customer tells 5 friends, a dis-satisfied customer tells 10
friends.  Or more.  :)

I am doing some big projects now, and the excellent support
for mutiple files, MAKE, and seperate linking in Hi-Tech is making me
very happy.  Hi Tech does have bugs, contrary to the claims of some
previous evangelists here on the list.  But they fix them for free.

This is professional work, I prefer a more expensive, more responsive
tool vendor, so I am not left stuck, or with production code with
compiler work arounds all over it.

------------
Barry King, KA1NLH
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
Hinesburg, Vermont, USA
barryEraseMEspamnrgsystems.com
"The witty saying has been deleted due to limited EPROM space"

1999\06\16@112009 by Roland Koehler

flavicon
face
We found the CCS compiler to be quite usable until we ran into troubles that
could be traced to banking problems. In our application it occurred when the
main()used switch...case AND a timer interrupt program also used
switch...case. After having a close look at the assembler code generated we
found a workaround: always lock the interrupt before the SWITCH and unlock
it after each CASE.
Not very elegant, but since there was no response from CCS, it was the only
thing we coud do in the middle of a project.

Greetings, Roland Koehler.

1999\06\16@142945 by Aaron and Hifumi

picon face
Looking at the revision chart for the compiler, I see that this bug was fixed
in version 2.645, about a half a year ago. Good news for you, if you are still
using the compiler and have a updated version.

Aaron

Roland Koehler wrote:

{Quote hidden}

1999\06\16@145515 by Kevin

flavicon
face
> Not very elegant, but since there was no response from CCS, it was the only

I've never used this particular compiler, but to me, the above line
speaks volumes. Even a free compiler with no support (or source to fix
it yourself) is worth it's cost.

Cheers,

Kevin

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