Hello all,

I've been using the linux version of CCS for the 18-series parts for 4-5
months.  Unfortunately my experience has been one of repeated
frustrations.  The documentation is sparse, important details of
built-in functions are nonexistent, I have personally found a number of
bugs that a compiler out-of-beta-test should never have - and wasted 30
hours finding one of them, I assumed it was a lot of other things before
finally reading the assembly it produced - and I've had both good and
bad results when reporting bugs to them.  You shouldn't have to call 3
times over 6 business days to get a showstopper bug (i.e. crash - I've
found several) fixed.

I've only used the 18-series version of the compiler.  But take a look
at the list of the bugs fixed since the first release.  75% of them
should have been found, and fixed, in beta test before release.  There
are regressive bugs.  I don't think they have a proper qa department.
When I call to get a linux build (they don't keep it up to date, even
though it is a shipping product) the random techie I get on the phone
seems to be the one that does the build.  As in, no formal
build/test/release process.  It was I that figured out at one point
their linux build was broken, and the only differences between versions
1.48 (or whatever it was) and 1.42, 1.36, back for 2 months, was a
timestamp in the executable.  It would report 1.36 as its version, yet
it was supposedly a fresh build of the latest code.  They were that bad.
  Of course, I'd spent many hours downloading the "latest" version, on
their advice, to see if it fixed whatever bug I had at that time.  I
proved this by doing binary diffs on the executables for the various
supposed versions.

But, they are on linux (the only ones), and cheaper than microchip and
Hi-tech.  Microsoft VC++, even the bad releases (4.0, for example) were
much better.

You basically can't really trust the thing.

example - try to set optimization level.  crash.
Pass a reference to a struct in an array to a function.  crash.
(these are the current crashes I haven't felt like getting them to fix.)
i2c using PIC hardware - works.  software - nope.  Not friendly when you
are trying to debug your hardware too!

But, at this point I can avoid the known problems and have code to do
useful things that works, so I will continue to use it.  Its paid for
already.

Jesse





j. d. s. wrote:
> tony,
>
> just my 0.02 on the matter.   below a non-CCS user enumerates
> some "non-information" that he got secondhand a few years ago.
> i think we can do better.
>
> your query of
>
>>>Do you have experience with CCS?
>>
>
> should have been met in this case with "no, i don't".
>
> i think you asked for a compiler recommendation, so here is a
> more balanced approach.  i'm a EE/ME with a decent amount of
> coding behind me in areas ranging from instrumentation and PID
> control to handheld test equipment.  appplications have mostly
> been higher-end telecommunications gear where the nickels are
> not really as important as 24x7x365 uptime.
>
> i have used CCS C for about 5 years, primarily with the pic16
> series devices (16F84, 16C65/67, 16C74, 16F873/876) and most
> recently with a pic18 series device (18F252).
>
> my initial project, which required dealing with i2c and serial
> comms (RS485 and RS232), drove me to look into the PIC devices
> and from there i selected the CCS compiler.  my selection was
> based on price and the large number of built-in functions that
> were available.  the way i saw it was that i could concentrate
> on application code rather than worrying about bit-banging i2c.
>
> the compiler, like any new programming environ, took a bit of
> time getting used to.  but i felt i was immediately productive
> and not "fighting the tool" as so often happens in r&d.  there
> were no major compiler-related issues with my first project and
> as i result i kept CCS in my toolbox.
>
> future projects were of course more complicated and as i gained
> confidence in both the pic devices and the compiler i found that
> CCS provides a very nice product.  the large number of built-in
> functions work very well, and allow for very rapid prototyping
> of code.  most of the time what i initially believed to be a
> compiler issue turned out to be a result of my sloppy typing.
> another time i just misunderstood how the compiler was in fact
> using the #use_i2c directives when i had three i2c buses.  to
> that i would like to add that the ability to synthesize i2c or
> rs232 drivers on any pins, and do so quickly, is a huge benefit.
> looking at the output assembly intermixed with the C source is
> a nice feature, and i've never really had to tweak the compiler's
> output to fix a deficiency.  as for code size in comparison with
> other compilers, try this on for size: "i don't know" -- since
> i've never used other PIC compilers.  when was the last time
> you heard such honesty on the 'net?  :*)
>
> im summary, i have used and abused CCS C for quite some time,
> and i've not found a reason to stray.  it is not expensive, but
> it is not just a "hobbyists" compiler.  in terms of quality, the
> output code is immediately usable, and of course if you want to
> intermix assy with your C source, have at it.  coding purists
> will content that there are some marginal features, for example
> pointers to functions comes to mind.  but there are of course
> way to work around these types of issues.  the other 99% of
> the infrastructure-related PIC-specific functions are functional
> and produce reasonable if not you-couldn't-hand-code-better
> output.  at this point in the compiler's evolution, i would not
> hesitate to use any of the PIC-specific functions.  to be fair,
> the situation when v3.000 was first released was not pretty.
> but there is always a danger with any software ending in ".0",
> and likewise the current 3.17x is fairly refined.  the best and
> worst part of CCS Inc is the frequent compiler releases. i would
> be happier if they marked a version "production stable" and the
> rest "beta" until the best of the betas was declared "fully fit".
>
> from the www.ccsinfo.com website you can download the current
> CCS C manual, and also pose questions in their forum.  several
> of the forum members should be in the PIC hall-of-fame, and are
> active participants when dealing with compiler or design issues.
> that kind of ecosystem is nice to have in your back pocket.
>
> btw
> there's a chance that this email comes to you via a product that
> i worked on, which in turn has a PIC monitoring and alarming some
> aspects of it's operating environment.
>
> jds
>
>
>

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu