Searching \ for '[PIC] PIC18 C compiler comparison' 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: 'PIC18 C compiler comparison'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC18 C compiler comparison'
2007\10\16@043345 by Vitaliy

flavicon
face
Back in July, there was a discussion titled "[PIC] Is C18 really this
stupid?", where it has been conclusively proven that C18 sucks (which
generally matches our experience). :) It produces rather inefficient
assembler code, and the fact that the libraries are no longer supported is
disheartening.

So I'm wondering if people can share their experiences using third party
compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC, mikroC, IAR (any
others I've missed?)

Specifically,

- How stable is it (bugs)?
- How well does it integrate with MPLAB?
- How good are the libraries?
- How does its performance compare to the C18, and other compilers?


RUMORS

- SDCC is buggy
- HI-TECH blows SDCC out of the water in terms of performance
- BoostC has slow compilation times
-


REFERENCES

<http://www.microchipc.com/reviews/PIC18_compiler_comparison/>

<http://www.microchipc.com/reviews/Hi-Tech_C_PICC18/index.php>

<http://forum.sparkfun.com/viewtopic.php?t=1039>




2007\10\16@050025 by Xiaofan Chen

face picon face
On 10/16/07, Vitaliy <spam_OUTspamTakeThisOuTspammaksimov.org> wrote:
> So I'm wondering if people can share their experiences using third party
> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC,
> mikroC, IAR (any others I've missed?)
>

Yes you missed the Basic/Pascal/Forth Compilers and JAL compiler.
Eg:
Basic: Melabs PICBasic Pro, Proton PICBASIC, mikroBasic, XCSB,
Oshonsof Basic, Basic 18, SourceBoost Basic, etc

Pascal compilers: mikroPascal, SourceBoost P2C

Python/Jal/Forth compilers:
http://www.gnupic.org/i_compile.html

So maybe you would like to narrow down to C compiler. Then you only
miss a few. One of them is WiZ-C (http://www.fored.co.uk/). There is
a FreeRTOS port for WiZ-C along with C18.

Xiaofan

2007\10\16@050852 by Xiaofan Chen

face picon face
On 10/16/07, Vitaliy <.....spamKILLspamspam@spam@maksimov.org> wrote:
> Back in July, there was a discussion titled "[PIC] Is C18 really this
> stupid?", where it has been conclusively proven that C18 sucks (which
> generally matches our experience). :) It produces rather inefficient
> assembler code, and the fact that the libraries are no longer supported is
> disheartening.
>
> So I'm wondering if people can share their experiences using third party
> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC,
> mikroC, IAR (any others I've missed?)
>

I think C18 is fine. It offers one of the best value. You buy it one time
and then enjoy free updates. The library may not be good but it can
serve as a good start. It also enjoy best integration with MPLAB.
The forum support in Microchip Forum is also good. Moreover, most
of the Application Notes from Microchip are written in C18.

The only better one might be HiTech PICC18 as far as I learned
from the Internet. Normally you need to develop your libraries
with PICC18. The price is higher and you need to pay for
maintenance. The examples are not many. The forum
support from HiTech Forum is good. It is said that PICC18
produces the best code but I have not used it.

To me if I am using only PIC18, I will stick with MPLAB C18. If
I will use PIC2/16 and PIC18, perhaps I will buy PICC/PICC18.

For hobbyist, C18 student edition is the best bet. It also works under
Linux with Wine. SDCC is another choice (free and open source).
CCS/HiTech both offer Linux version of the compiler. HiTech
IDE is based on Eclipse. Some people like Eclipse. But I do not...

Xiaofan

2007\10\16@073258 by Hamilton Horta - PY2NI

flavicon
face
   I have tried several "low cost" C compilers and the only one that I am
confident with
is CC5X and now CC8E, the only drawback  are the libraries, some people love
to have
a ready to go  LCD display routines and it´s not the case with this
compiler. Acctualy
I prefer to write  my own routines and after some time you  also probably
have a bunch
of them in your pocket so I don´t bother about it.
   I have started a project with PIC16F873 and after several upgrades in
software I have
to change to a 16F876 then  to a 18F2525 and next move will be toward a
18F2620, when
family changed I changed to CC8E.
   It took me about 3 hours to change a project running with CC5X and a
16F876  to one
using 18F2525 and CC8E I thought I would  spend at least 3 or 4 days. All
these steps
were very smooth and so far I am very satisfied with it: runs under MPLAB,
small code,
fast and support is superb (as with CC5X I have to mention).
   You can download a demo version of them at http://www.bknd.com they are limited
to a
1k word of program but fully functional if I am not mistaken.

   My grades for your questions are (0 - 10):

- How stable is it (bugs)? 10
- How well does it integrate with MPLAB? 10
- How good are the libraries? 5 (but see my comments above)
- How does its performance compare to the C18, and other compilers? I don´t
have any
experiences with others C compiler for 18 family because it fitted all my
needs up til now

Hamilton Horta
My mother tongue is not English as you can see.





{Original Message removed}

2007\10\16@075200 by Gerhard Fiedler

picon face
On 2007-10-16 06:31:45, Vitaliy wrote:

> So I'm wondering if people can share their experiences using third party
> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC, mikroC, IAR (any
> others I've missed?)
>
> Specifically,
>
> - How stable is it (bugs)?
> - How well does it integrate with MPLAB?
> - How good are the libraries?
> - How does its performance compare to the C18, and other compilers?

I'm using HiTech PICC compilers since a long time ago. When I made the
choice, they and CCS were the only serious contenders IIRC. I started with
CCS, but I didn't like the fact that they had to publish a bug fix update
about every week. (And, from that recent discussion here, it seems that
it's still like this. Man... :)  I mean, if you look at it from the
viewpoint of in one year, you're currently working with a compiler that
still has to receive some 50 serious bug fixes. I had to find the one or
other bug in PICC also, but that's probably normal, and every time I found
one it got fixed almost immediately.

I don't do a lot of work with MPLAB, so can't say how well the integration
works.

Regarding libraries, that's a bit like ECAD libs: in the end, you probably
make your own anyway, at least in a production environment (as opposed to a
hobbyist environment).

Don't have any performance comparison data with other compilers.

Gerhard

2007\10\16@081955 by Xiaofan Chen

face picon face
On 10/16/07, Vitaliy <spamspamKILLspammaksimov.org> wrote:
> So I'm wondering if people can share their experiences using third party
> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC, mikroC,
> IAR (any others I've missed?)
>

CCS has a web page on comparisons. It is rather good summary
but please take the benchmark result with a grain of
salt.http://www.ccsinfo.com/content.php?page=newcompilercomp

Some independent reviews from Microchipc.com:
www.microchipc.com/reviews/Hi-Tech_C_PICC18/
http://www.microchipc.com/reviews/CCS_C/
http://www.microchipc.com/reviews/PIC18_compiler_comparison/

Xiaofan

2007\10\16@085639 by Hector Martin

flavicon
face
I've only used C18 and SDCC (and I started the thread you mentioned :).
C18 is decent, but it either uses broken math (with no integer
promotion, which breaks the C standard) or has horrible, awful
optimization with integer promotion enabled (it will turn a simple BTFSS
into many instructions).

SDCC tends to do the right thing more often, though it does have a bug
or two every now and then. However, you can usually work around the bugs
(you can't really work around C18's stupid optimization, unless you turn
off IP, and then you have to change all of your code to deal with that
if it doesn't already, and hope that you never have to import some
generic C code that doesn't expect to be compiled with a broken
compiler). SDCC has pretty fast compilation times.

One thing I don't like about SDCC though is that it does a lot of
context saving in interrupts (I would like for it to be able to delay
the context saving until it is really needed, or have the option of
compiling interrupt code with a different register stack to avoid saving
anything). If you like fast interrupt code, you're going to have to do
some hacking. I had a project that needed some relatively fast interrupt
code, so what I did is declare a "naked" interrupt function (aka all
bets are off, no context saving at all; in fact it won't even add a
"return" for you). Then I used a few lines of assembler to do minimal
context saving, and call the main interrupt code. The main code is
basically a series of if statements and increments, tests, etc, and I
made sure they don't use any compiler registers when compiled (the fact
that SDCC doesn't do broken integer promotion helps here - everything
was 8 bits wide, so no temp registers were needed). When I need to call
code (during slow interrupts) that does a little more work, I do the
context saving myself.

I'm sure there's better stuff out there, but you can't really beat
SDCC's price. For my purposes, it works. Then again, I don't quite use
it for commercial purposes (yet).

--
Hector Martin (.....hectorKILLspamspam.....marcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\10\16@090921 by fred jones

picon face

> On 10/16/07, Vitaliy <EraseMEspamspam_OUTspamTakeThisOuTmaksimov.org> wrote:> So I'm wondering if people can share their experiences using third party> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC, mikroC,> IAR (any others I've missed?)

I would imagine what is important to you would be a deciding factor in choosing a compiler.  I liked the large library of routines that MikroC offers (as well as their other compilers) as well as the hardware development tools they have available.  All the hardware products have routines available for them as well.  Since I don't make my living with PICs, I couldn't justify a large price tag.  Since I bought some development boards, the compiler with no limitations, was only $149.  They have a forum with wonderful support.  As for memory, it is probably not the most efficient but cost and huge library were more important for me.
Good luck

http://www.mikroe.com
http://www.circuit-ed.com  (USA distributor)
_________________________________________________________________
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews

2007\10\16@091218 by Timothy J. Weber

face picon face
Vitaliy wrote:
> So I'm wondering if people can share their experiences using third party
> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC, mikroC, IAR (any
> others I've missed?)

I evaluated a bunch of these a few years ago.  At the time I wanted a
very low cost entry-level compiler, with a good upgrade option.  I
eliminated several because they didn't have a demo/low-cost version, or
because the demo didn't support the particular chip I was using at that
time.  Not very relevant criteria now, or probably for you.

So the two I spent serious time with were BoostC and mikroC, with a
little attention to PICC.  I chose Boost.  So my comments on mikroC may
be out of date.

Both have their own IDE as well as the compiler.  Both have simulators
with their IDEs, and neither of them was usable for me - crashes or too
many unimplemented chip features.  I use MPLAB's simulator instead.

There seems to be no real standardization among PIC C compilers on the
syntax for things like direct bit access; Boost uses "register.BIT".
All of them seem pretty equivalent, but the differences make porting
annoying.

BoostC covers both PIC16 and PIC18.

> Specifically,
>
> - How stable is it (bugs)?

Boost: Fairly stable, but I have encountered bugs periodically,
including one recently that screwed up bank switching.  Took a long time
to track it down to their linker.  Took several days to get a fix; don't
know whether that counts as slow or fast - but this was a pretty tough
bug, and they did send me a version to test before they released the fix
generally.

mikroC (and I think I also tried mikroPascal) seemed very buggy at the time.

> - How well does it integrate with MPLAB?

BoostC: Quite well with one big hole.  Variable browsing in the
simulator works well, which is the hard part; the ability to compile
just a changed file ("make logic") is missing, which seems like it
should be the easy part!  So, for multi-file projects, not really usable
under MPLAB for normal development.

mikroC: Don't remember if it's possible.

> - How good are the libraries?

Both have decent libraries for serial, LCD, 1-wire, etc; mikro has the
edge in breadth, I think (e.g., support for the PS/2 keyboard/mouse
serial, some sound, some USB), but aren't very deep.

Boost has a floating-point library, and an RTOS (separate license, I think).

> - How does its performance compare to the C18, and other compilers?

Speed of compiler: mikroC - don't remember.

Speed/size of output code: mikroC was just dreadful; generated code was
twice the size of PICC Lite's, e.g.  Boost's optimizer seems fairly
good; there are still places where I can do better by hand, but that
doesn't surprise me.  Support for the "inline" keyword and for a
software stack helps.

> RUMORS
> - BoostC has slow compilation times

Certainly under MPLAB, because of the make issue.  Doesn't seem terribly
slow otherwise, though I don't have any concrete, recent experience with
other compilers for comparison.

In general, I'm happy with BoostC, and it's quite reasonably priced.
--
Timothy J. Weber
http://timothyweber.org

2007\10\16@093513 by Alan B. Pearce

face picon face
>RUMORS
>
>- HI-TECH blows SDCC out of the water in terms of performance

Well, this lunchtime I was reading the Electronics Weekly that arrived in my
inbox this morning, and there was an announcement about a 'new feature' that
HiTech are putting across the professional range of their compilers, which
is currently available on their PICC18 and PSoC compilers. look for OCG, it
is supposed to produce significantly smaller code - including across linked
modules. Cost ? - don't know.

2007\10\16@104356 by Brendan Gillatt

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vitaliy wrote:
> Back in July, there was a discussion titled "[PIC] Is C18 really this
> stupid?", where it has been conclusively proven that C18 sucks (which
> generally matches our experience). :) It produces rather inefficient
> assembler code, and the fact that the libraries are no longer supported is
> disheartening.
>
> So I'm wondering if people can share their experiences using third party
> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC, mikroC, IAR (any
> others I've missed?)

I've used mikroC and it is the single worst compiler I have ever seen. I
don't know whether or not it doesn't like the 18f4620 - the chip I
started to build a project with (before switching to C18).

There are bugs _everywhere_. Occasionally you must add 256 (for an
unsigned char) if you want to successfully pass it to a function without
complete and random corruption. I once tried to use function pointers
with mikroC - that always ended with broken code.

> Specifically,
>
> - How stable is it (bugs)?
Apparently there are a few bugs in C18 - the only one I encountered was
fixed about a month after I reported it. To be fair, I was doing
something probably pretty crazy on such a small uC - doing about 40
pointers to structs in a kindof tree fashion.

Don't get me started on mikroC!

> - How well does it integrate with MPLAB?
microC doesn't at all - C18 does.
> - How good are the libraries?

mikroC's libraries are supposedly fantastic, shame that I got too many
bugs in the lower level code to even consider adding the higher level
libraries.

C18's are far more standard and they do the job.

> - How does its performance compare to the C18, and other compilers?

mikroC takes ~1minute for a 9KB program - a little slower than C18 I guess.
>
> RUMORS
>
> - SDCC is buggy
> - HI-TECH blows SDCC out of the water in terms of performance

I just wish I could afford HI-TECH!


One thing I'm noticing with C18 is that it throws nops in everywhere! I'm
not sure if it's because I use the free version without optimizations;
however, it shouldn't be de-optimising, should it?

Also note that with C18 it's best to enable 'large stack pointers' - it
makes code so much easier to write. That choice should really be done by
the compiler on a per-function basis, but I can't complain - it's free
after all.

Then again, for my next project I'm pretty certain that I'll try out the
AVRs *takes cover* - simply because I can use JTAG and GCC.

Okay that post was a bit of a spiel but I feel I had to voice my opinion
of mikroC.

- --
Brendan Gillatt
brendan {at} brendangillatt {dot} co {dot} uk
http://www.brendangillatt.co.uk
PGP Key: pgp.mit.edu:11371/pks/lookup?op=get&search=0xBACD7433
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFHFM4ckA9dCbrNdDMRAvFHAJ4vrZZLnDsPy3sCut97u8+IqAJA/wCgmQkh
LjnMttiNCK3g/4vCOq8Ba3s=
=hjrC
-----END PGP SIGNATURE-----

2007\10\16@115244 by Herbert Graf

flavicon
face
On Tue, 2007-10-16 at 08:09 -0500, fred jones wrote:
> > On 10/16/07, Vitaliy <spamspamspam_OUTmaksimov.org> wrote:> So I'm wondering if people can share their experiences using third party> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC, mikroC,> IAR (any others I've missed?)
>  
> I would imagine what is important to you would be a deciding factor in choosing a compiler.  I liked the large library of routines that MikroC offers (as well as their other compilers) as well as the hardware development tools they have available.  All the hardware products have routines available for them as well.  Since I don't make my living with PICs, I couldn't justify a large price tag.  Since I bought some development boards, the compiler with no limitations, was only $149.  They have a forum with wonderful support.  As for memory, it is probably not the most efficient but cost and huge library were more important for me.
> Good luck

Hehe, it's funny how different opinions can be!

Personally, libraries (beyond the basic standard stuff, i.e. strcat)
mean almost nothing to me, especially peripheral libraries.

There's always something I find out not liking about built in
libraries.

Peripheral libraries always do things in ways I don't like, they either
get too complicated to use (i.e. requiring weird structures to init
them) or they don't give enough info in what exactly they are doing
(i.e. the definitions of clock polarity and edge for SPI control differs
depending on who wrote the library). I've often spent more time trying
to figure out how to properly configure and use a peripheral library
then it would have taken for me to read the datasheet and write my own
routines. Even worse is some of the errors/bugs I've encountered in
peripheral libraries. As a result, I don't even bother with built in
peripheral libraries anymore.

As for "standard libraries", beyond the simplest members, I use them as
rarely as possible. The biggest issues here are bloat. One call to say
printf results in HUGE amount of code space being added, because printf
supports SO many different ways of doing things. Sometimes I can afford
the bloat, oftentimes I can't. As a result I just write my own simpler
routines that mimic the simpler functions of printf (i.e. "prints" which
just prints a string, no formatting, "printhex" which prints a number in
hex, etc.).

Portability is always maintained for my "standard library" substitutions
since I always wrap things in a way that I just change one minor
function to accommodate a different platform. For example, all my
"print" functions use putchar to do the actual output. putchar just
calls the appropriate peripheral function, so if I want to change serial
ports (or change to outputting to an LCD), I just change the call in
putchar and all my print functions remains the same.

Perhaps the current crop of compilers have cleaned up all the issues
that annoyed me in the past, making what I do now pointless, but so be
it! :)

TTYL



2007\10\16@120819 by Bob Blick

face picon face

--- "Alan B. Pearce" <@spam@A.B.PearceKILLspamspamrl.ac.uk> wrote:

> >RUMORS
> >
> >- HI-TECH blows SDCC out of the water in terms of
> performance
>
> Well, this lunchtime I was reading the Electronics
> Weekly that arrived in my
> inbox this morning, and there was an announcement
> about a 'new feature' that
> HiTech are putting across the professional range of
> their compilers, which
> is currently available on their PICC18 and PSoC
> compilers. look for OCG, it
> is supposed to produce significantly smaller code -
> including across linked
> modules. Cost ? - don't know.

The pro line of HiTech is very expensive. And they are
now treating their customers like criminals with their
new activation scheme. I'm not renewing my maintenance
any more, and if I need support for new chips I'm
either going to write the device file myself or find
another compiler. They finally hit my disgust
threshold and I'm not going to take any more of this
kind of crap.

But the code produced is very good, so if someone else
is paying and you don't mind products that snoop on
you, it might be right for you.

Cheerful regards,

Bob




2007\10\16@122251 by Alan B. Pearce

face picon face
>Perhaps the current crop of compilers have cleaned up all the issues
>that annoyed me in the past, making what I do now pointless, but so be
>it! :)

Well, the new professional Hi-Tech PICC18 compiler claims to fix the printf
bloat ...

Be interesting to see some actual figures. They have a test file on their
website.

2007\10\16@123310 by Alan B. Pearce

face picon face
>The pro line of HiTech is very expensive. And they are
>now treating their customers like criminals with their
>new activation scheme.

Oh, one of those 'phone home' ones, is it? A piece of software I have gave
up on that after the writer attempted to use one to get around the key
crackers, and went back to the key scheme he had used.

>But the code produced is very good, so if someone else
>is paying and you don't mind products that snoop on
>you, it might be right for you.

Well, if they are going to charge an arm and a couple of legs, then it needs
to be good.

2007\10\16@123923 by Bob Blick

face picon face

--- "Alan B. Pearce" <KILLspamA.B.PearceKILLspamspamrl.ac.uk> wrote:

> >Perhaps the current crop of compilers have cleaned
> up all the issues
> >that annoyed me in the past, making what I do now
> pointless, but so be
> >it! :)
>
> Well, the new professional Hi-Tech PICC18 compiler
> claims to fix the printf
> bloat ...

John Payson (some will remember him from a few years
back, he was a very talented contributor to the
piclist) has been posting printf improvements to the
HiTech forum, it wouldn't surprise me if they have
incorporated his ideas in to the product.

Cheerful regards,

Bob

2007\10\16@125828 by Matt Pobursky

flavicon
face
On Tue, 16 Oct 2007 09:51:52 -0200, Gerhard Fiedler wrote:
{Quote hidden}

Just out of curiosity, how do you debug your applications? (Last I checked
HiTech PICC didn't have an integrated IDE debugger. I was a Hitech PICC
user but debugging was painful under MPLAB. Not doing PIC16 and PIC18 with
the same compiler was also a killer for me)

> Regarding libraries, that's a bit like ECAD libs: in the end, you
> probably make your own anyway, at least in a production environment (as
> opposed to a hobbyist environment).

I would agree with you on that point.

> Don't have any performance comparison data with other compilers.

Once again I will be the voice of dissent regarding CCS PICC. :-)

We've been using it here for ALL our PIC software development for about 3
years now. We also develop for the AVR, MSP430, Rabbit, ARM and a few other
families. We haven't found a significantly higher number of "show stopper"
bugs with the CCS compiler than with any of the other tools we use. Yes,
they update the compiler a lot and fix a lot of bugs but they also add new
part support much faster than anyone else. The rule with compilers like CCS
is to find a stable version and stick with it and only upgrade when you
have to. Also, download and ARCHIVE all versions of the compiler possible
and especially the version you use to devlelop your release code. We do
this as a standard practice with ALL our tools for all processors now since
you never know what may arise in the future and anyone who's done firmware
development knows that depending on the latest version of the compiler is
"interesting"... (in the sense of the Chinese saying, "May you live in
interesting times").

For us there are a lot of "pros" to the CCS PICC tools:

1) All families of the PIC with one compiler. They added 16 bit PIC support
this past year and it's quite stable now, based on feedback in their user
forum.

2) MUCH, MUCH better source level debugging than MPLAB. We spend at least
80% of our time in the debugger so anything that streamlines the process
makes us more money and allows for better debugging in the given time. The
CCS ICD-U40 is also a very solid tool and works better than Microchip's
ICD2. The CCS ICD-U40 is also inexpensive enough ($75) that I supply them
to clients for updating firmware and production use. CCS also has a very
nice standalone programming application (free) for the ICD-U40 which is
great for clients and production line programming (i.e. no need to have
MPLAB and it's complicated interface once code is developed and deployed).

3) Cost is reasonable. No forced maintenance, you can pick up maintenance
anytime even if your current maintenance has lapsed.

4) Produces reasonable code. I've only seen a few compilers that produce
more compact code and then it was only slightly smaller. We've never had a
problem with code size or performance.

5) Very good peripheral libraries. We don't use these all that much as
we've developed many portable drivers. If supplied libraries are your cup
of tea then you'll probably like the supplied CCS library functions. FWIW,
this is the area that compiler bugs seem to break most often.

Part of the issue with CCS and their bugs is that they do a tremendous job
of "compiling around" silicon bugs. They incorporate as many software fixes
to errata problems as they can and given the number of PICs and their
errata this is a daunting task. It's easy to break the compiler when you
have many "special cases" for specific chips and their peripheral
libraries. In this case, it's GREAT that they provide compiler updates on a
regular basis. As a contrast, I have reported serious compiler bugs to "big
name" (and $$$) tool vendors and waited 6 months or more for an update that
fixes the problem. Bugs are a fact of life in the development world and the
more responsive the tool vendor is the better for me.

CCS PICC is not perfect but then I don't have any other toolsets that are
either.

In summary, the things we look for when evaluating new tools are:

1) Code generation. Is it reliable and does it produce reasonably compact
code?

2) Debugger interface. Is the source level debugging in C easy and
powerful?

3) Cost. Is it reasonable and do they provide reasonable maintenance fees?

4) Support. How responsive is the vendor to bugs and how quickly do they
fix them?

Matt Pobursky
Maximum Performance Systems

2007\10\16@135634 by Morgan Olsson

flavicon
face
Den 2007-10-16 18:58:24 skrev Matt Pobursky <RemoveMEpiclistTakeThisOuTspammps-design.com>:

> Just out of curiosity, how do you debug your applications? (Last I checked
> HiTech PICC didn't have an integrated IDE debugger.

I am just lurking, and just recieved replys from Hi-Tech

Their IDE, Hi-Tide nowadays support ICD2 and a lot of PIC16 and PIC18 chips.
(not the one i use, yet...)
It do not support USB, only serial connection so far.

But the December release is planned to support Real-ICE

What also is interesting is that their tools work under Linux so I can have all i need on one system.


> user but debugging was painful under MPLAB.

It is painful under MPLAB with C18 too...

Or we just do not get it...
We need tolook at variables but cannot reach them as it is stack based...
Any ideas?

Also any idea to make MPLAB and/or MSWinXP not crash a number of times per day, mainly when shifting USB devices?


I asked Hi-Tech if i could set a breakpoint, point at any variable and see its value, and they said yes.
In that case PICC18PRO + Hi-Tide + ICD2 is better than C18 + MPLAB + Real-ICE.
But maybe they thought i said register, not variable?
Anyone knows if we using Hi-Tide can see the valye of any variable of any type at a breakpoint?


--
Morgan Olsson

2007\10\16@152457 by Gerhard Fiedler

picon face
On 2007-10-16 14:58:24, Matt Pobursky wrote:

>> I don't do a lot of work with MPLAB, so can't say how well the
>> integration works.
>
> Just out of curiosity, how do you debug your applications?

Usually some form of in-process output, like prints to a serial port or pin
toggles. Most of the code I write depends heavily on outside interaction,
and simulating this appropriately would be too much work -- and running the
code without it just would get it into some kind of "limp home" mode :)

I generally develop code for smaller devices in a bigger device until it
all works (more comfortable, debugging-wise; I can just throw prints, even
printf's in as much as I need), then I port that code, now functionally
already running and tested, to the smaller device. Since I already write it
with the porting in mind, that's usually very little work -- and probably
much less work than trying to debug on a small device.


> (Last I checked HiTech PICC didn't have an integrated IDE debugger. I was
> a Hitech PICC user but debugging was painful under MPLAB.

FIWI, they are integrated, with that MPLAB plugin system, and it seems it
has improved compared to a few years ago. But if you don't like MPLAB, that
doesn't help :)


> Not doing PIC16 and PIC18 with the same compiler was also a killer for
> me)

I'm using HiTech's PICC and PICC18, and even though it's not the same
compiler, it is pretty much the same -- so much the same that the above
technique to write and debug code on an 18F device that is ultimately meant
for a 12F device is easily possible.


> For us there are a lot of "pros" to the CCS PICC tools:
>
> 1) All families of the PIC with one compiler.

For me, that's a non-issue. Whether I have to call a different exe doesn't
matter all that much. The compilers are otherwise compatible enough.

> 2) MUCH, MUCH better source level debugging than MPLAB. [...]

Can't comment on this topic, but what you say sounds reasonable.

> 3) Cost is reasonable. No forced maintenance, you can pick up maintenance
> anytime even if your current maintenance has lapsed.

Cost is higher for HiTech, but "picking up" maintenance is also possible.

> 4) Produces reasonable code.

I'd say that goes also for HiTech.

> 5) Very good peripheral libraries.

Probably a point for CCS in this comparison. There's not all that much for
HiTech compilers.

> Part of the issue with CCS and their bugs is that they do a tremendous
> job of "compiling around" silicon bugs. They incorporate as many
> software fixes to errata problems as they can and given the number of
> PICs and their errata this is a daunting task.

Well, HiTech also does that -- any decent compiler needs to incorporate
erratas that affect code generation.

Gerhard

2007\10\16@160450 by John Temples

flavicon
face
On Tue, 16 Oct 2007, Gerhard Fiedler wrote:

>> Part of the issue with CCS and their bugs is that they do a tremendous
>> job of "compiling around" silicon bugs. They incorporate as many
>> software fixes to errata problems as they can and given the number of
>> PICs and their errata this is a daunting task.
>
> Well, HiTech also does that -- any decent compiler needs to incorporate
> erratas that affect code generation.

Microchip's C18 does not have errata support.

--
John W. Temples, III

2007\10\16@160936 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Oct 16, 2007 at 08:56:31AM -0400, Hector Martin wrote:
> I've only used C18 and SDCC (and I started the thread you mentioned :).
> C18 is decent, but it either uses broken math (with no integer
> promotion, which breaks the C standard) or has horrible, awful
> optimization with integer promotion enabled (it will turn a simple BTFSS
> into many instructions).
>
> SDCC tends to do the right thing more often, though it does have a bug
> or two every now and then. However, you can usually work around the bugs

I'll second that. I keep running into weird stuff, like my recent post
about movff. Some of it's my inexperience I'm sure, but I have found
some definet bugs, arrays in the form of foo[][] were completely broken
in an older version of sdcc I've used for instance.

Actual documentation is another matter, it took me quite a while to
figure out how to make a proper Makefile.

But, it does run on Linux... and I am stubborn.

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFRo13bMhDbI9xWQRAoMjAJ9YuH6CnNItoWdaWrvkGjOfSGfPCgCeOv9s
Ox27Pjoqv0Mo2XWlzmchJ/A=
=Vv92
-----END PGP SIGNATURE-----

2007\10\16@191043 by Xiaofan Chen

face picon face
On 10/17/07, John Temples <spamBeGonepiclist3spamBeGonespamxargs.com> wrote:

> >> Part of the issue with CCS and their bugs is that they do a tremendous
> >> job of "compiling around" silicon bugs. They incorporate as many
> >> software fixes to errata problems as they can and given the number of
> >> PICs and their errata this is a daunting task.
> >
> > Well, HiTech also does that -- any decent compiler needs to incorporate
> > erratas that affect code generation.
>
> Microchip's C18 does not have errata support.
>

But the errata sheet mentioned the work-around for C18 and MPASM.
I think that is good enough. Normally you only work with a few PICs
and reading the errata is anyway necessary.

Xiaofan

2007\10\16@191636 by Xiaofan Chen

face picon face
On 10/17/07, Matt Pobursky <TakeThisOuTpiclistEraseMEspamspam_OUTmps-design.com> wrote:
>
> CCS PICC is not perfect but then I don't have any other toolsets that are
> either.
>
> In summary, the things we look for when evaluating new tools are:
>
> 1) Code generation. Is it reliable and does it produce reasonably compact
> code?

I believe C18 is good enough as long as you know some tricks or
ask Microchip or the Microchip Forum.

> 2) Debugger interface. Is the source level debugging in C easy and
> powerful?

C18 is the best within MPLAB.

> 3) Cost. Is it reasonable and do they provide reasonable maintenance fees?

C18 is the best value. You pay one time and enjoy free updates forever.

> 4) Support. How responsive is the vendor to bugs and how quickly do they
> fix them?

I believe Microchip is working hard to fix the bugs.

That is why I say C18 is recommended if you only use PIC18.

If we talk about dsPIC/PIC24, it is said that MPLAB C30 produces
better code than HiTech dsPICC.

Xiaofan

2007\10\16@194949 by piclist3

flavicon
face
On Wed, 17 Oct 2007, Xiaofan Chen wrote:

> On 10/17/07, John Temples <RemoveMEpiclist3spamTakeThisOuTxargs.com> wrote:
>
>> Microchip's C18 does not have errata support.
>
> But the errata sheet mentioned the work-around for C18 and MPASM.
> I think that is good enough.

Not all errata can be worked around by user code.  For example, look
at the errata in the early 18F452 silicon.  You could not develop
software for these chips with C18 unless you were willing to accept
random crashes in your code.

--
John W. Temples, III

2007\10\16@211844 by Xiaofan Chen

face picon face
On 10/17/07, piclist3EraseMEspam.....xargs.com <EraseMEpiclist3spamxargs.com> wrote:
> On Wed, 17 Oct 2007, Xiaofan Chen wrote:
>
> > On 10/17/07, John Temples <RemoveMEpiclist3EraseMEspamEraseMExargs.com> wrote:
> >
> >> Microchip's C18 does not have errata support.
> >
> > But the errata sheet mentioned the work-around for C18 and MPASM.
> > I think that is good enough.
>
> Not all errata can be worked around by user code.

In that case, the feature can not  used at alll...

I think you mean C code.

> For example, look
> at the errata in the early 18F452 silicon.  You could not develop
> software for these chips with C18 unless you were willing to accept
> random crashes in your code.
>

If my understanding above is correct,  you mean the silicon bug
may need  C compiler built-in fix. In that case, the user may
be able to fix it by in-line assembly or some tricks, right?

Xiaofan

2007\10\16@215945 by piclist3

flavicon
face
On Wed, 17 Oct 2007, Xiaofan Chen wrote:

> On 10/17/07, RemoveMEpiclist3spam_OUTspamKILLspamxargs.com <RemoveMEpiclist3TakeThisOuTspamspamxargs.com> wrote:
>> On Wed, 17 Oct 2007, Xiaofan Chen wrote:
>>
>>> On 10/17/07, John Temples <EraseMEpiclist3spamspamspamBeGonexargs.com> wrote:
>>>
>>>> Microchip's C18 does not have errata support.
>>>
>>> But the errata sheet mentioned the work-around for C18 and MPASM.
>>> I think that is good enough.
>>
>> Not all errata can be worked around by user code.
>
> In that case, the feature can not  used at alll...
>
> I think you mean C code.

I mean user code in a C program, whether C or assembly language.

>> For example, look
>> at the errata in the early 18F452 silicon.  You could not develop
>> software for these chips with C18 unless you were willing to accept
>> random crashes in your code.
>
> If my understanding above is correct,  you mean the silicon bug
> may need  C compiler built-in fix. In that case, the user may
> be able to fix it by in-line assembly or some tricks, right?

No.  For example, look at errata #7 of the 18F452 B2 silicon.  The
first required work around is "Insert a data word of value FFFFh as
the first instruction in the destination of a CALL or GOTO."  How
would a user insert some arbitrary data at the beginning of a
function?  The function body begins with stack manipulation code
generated by the compiler, not user code.

--
John W. Temples, III

2007\10\17@002329 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
> Regarding libraries, that's a bit like ECAD libs: in the end, you probably
> make your own anyway, at least in a production environment (as opposed to
> a
> hobbyist environment).

Yes, we do the same. We don't use Eagle libraries for anything anymore. :)

But I think it's a problem of the way the libraries are implemented, not the
library concept itself. In the end, you end up with your own "homegrown" set
of libraries -- why can't the vendor provide those in the first place? It
makes sense to use the largest blocks available, especially if the problem
is relatively straightforward.

As someone has pointed out, libraries also provide a good starting point
(tweak/change to suit your needs).

Vitaliy

2007\10\17@002751 by Vitaliy

flavicon
face
Brendan Gillatt wrote:
> One thing I'm noticing with C18 is that it throws nops in everywhere! I'm
> not sure if it's because I use the free version without optimizations;
> however, it shouldn't be de-optimising, should it?

Hm, IIRC the NOPs you see in the debugger are just blank memory locations.
Also, sometimes NOPs are used by the simulator after branches to keep an
accurate cycle count (they're not present in the actual hex file).

Vitaliy

2007\10\17@004221 by Vitaliy

flavicon
face
Matt Pobursky wrote:
> Once again I will be the voice of dissent regarding CCS PICC. :-)
[snip]

In order not to skew the responses prematurely, I failed to mention that our
company purchased some PIC18 code written for the CCS compiler. ;-)

Thank you for the very detailed reply. I just have one question: which
version should we buy -- PCH or PCWH? It sounds like you like the CCS IDE
over MPLAB, but the PCWH seems like an overkill (it supports the full 12-bit
and 14-bit range as well as the PIC18).  Ideally, we would want just
PCH+IDE.

Thanks again for your feedback.

Vitaliy

2007\10\17@005215 by John Temples

flavicon
face
On Tue, 16 Oct 2007, Vitaliy wrote:

> Brendan Gillatt wrote:
>> One thing I'm noticing with C18 is that it throws nops in everywhere! I'm
>> not sure if it's because I use the free version without optimizations;
>> however, it shouldn't be de-optimising, should it?
>
> Hm, IIRC the NOPs you see in the debugger are just blank memory locations.

More likely they're the second word of two-word instructions.

--
John W. Temples, III

2007\10\17@030730 by Matt Pobursky

flavicon
face
On Tue, 16 Oct 2007 21:39:50 -0700, Vitaliy wrote:
> Matt Pobursky wrote:
>> Once again I will be the voice of dissent regarding CCS PICC. :-)
>>
> [snip]
>
> In order not to skew the responses prematurely, I failed to mention that
> our company purchased some PIC18 code written for the CCS compiler. ;-)
>
> Thank you for the very detailed reply. I just have one question: which
> version should we buy -- PCH or PCWH? It sounds like you like the CCS IDE
> over MPLAB, but the PCWH seems like an overkill (it supports the full 12-
> bit and 14-bit range as well as the PIC18).  Ideally, we would want just
> PCH+IDE.

I don't think you can get the Windows IDE/Debugger with anything but PCWH.
You can always use the PCB, PCM or in your case PCH (PIC18) command line
compiler and debug with MPLAB. CCS does have a compiler plugin for MPLAB.

If I were going down this road then I would probably use Microchip's C18 or
Hitech's PICC as they are slightly better compilers (ANSI compliant for
instance). For me the real value in the CCS tools is the source level
debugging of PCWH.

Matt Pobursky
Maximum Performance Systems

2007\10\17@080212 by Morgan Olsson

flavicon
face
Den 2007-10-17 06:52:13 skrev John Temples <RemoveMEpiclist3KILLspamspamxargs.com>:

> On Tue, 16 Oct 2007, Vitaliy wrote:
>
>> Brendan Gillatt wrote:
>>> One thing I'm noticing with C18 is that it throws nops in everywhere! I'm
>>> not sure if it's because I use the free version without optimizations;
>>> however, it shouldn't be de-optimising, should it?
>>
>> Hm, IIRC the NOPs you see in the debugger are just blank memory locations.
>
> More likely they're the second word of two-word instructions.

We found that to be it.
Very stupid it is listed as NOP, they could just have used * or anything else.

--
Morgan Olsson

2007\10\17@080844 by Morgan Olsson

flavicon
face
Den 2007-10-17 03:59:42 skrev <piclist3STOPspamspamspam_OUTxargs.com>:

>
>> If my understanding above is correct,  you mean the silicon bug
>> may need  C compiler built-in fix. In that case, the user may
>> be able to fix it by in-line assembly or some tricks, right?
>No.  For example, look at errata #7 of the 18F452 B2 silicon.  The
> first required work around is "Insert a data word of value FFFFh as
> the first instruction in the destination of a CALL or GOTO."  How
> would a user insert some arbitrary data at the beginning of a
> function?  The function body begins with stack manipulation code
> generated by the compiler, not user code.
>

Interesting.

Is it possible to tell what Erratas are implemented?

Do they implement workarounds for bugs in SPI, UART etc, there are a lot of them.
It could lead to negative effects out od user control or intent.

How do they handle different bugs between different chip revisions...?
Do you tell it what chip revision you use?

--
Morgan Olsson

2007\10\17@083515 by Alan B. Pearce

face picon face
>>> Hm, IIRC the NOPs you see in the debugger are just blank memory
>>> locations.
>>
>> More likely they're the second word of two-word instructions.
>
>We found that to be it.
>Very stupid it is listed as NOP, they could just have used * or anything
>else.

Not really. IIRC PIC18 series chips have the second byte of a 2 byte
instruction set up so they behave as a NOP, so that conditional jump
instructions can deal with having a 2 byte instruction after them, as they
step the program counter only 1 step, not 2.

2007\10\17@083517 by Jan-Erik Soderholm

face picon face
Morgan Olsson wrote:
> Den 2007-10-17 06:52:13 skrev John Temples <spamBeGonepiclist3STOPspamspamEraseMExargs.com>:
>
>> On Tue, 16 Oct 2007, Vitaliy wrote:
>>
>>> Brendan Gillatt wrote:
>>>> One thing I'm noticing with C18 is that it throws nops in everywhere! I'm
>>>> not sure if it's because I use the free version without optimizations;
>>>> however, it shouldn't be de-optimising, should it?
>>> Hm, IIRC the NOPs you see in the debugger are just blank memory locations.
>> More likely they're the second word of two-word instructions.
>
> We found that to be it.
> Very stupid it is listed as NOP, they could just have used * or anything else.
>

Why anything at all ?
They *are* two-word instructions and should be listed as such...

2007\10\17@084430 by Dario Greggio

face picon face
Jan-Erik Soderholm wrote:


> Why anything at all ?
> They *are* two-word instructions and should be listed as such...

IMO (as it happens on any other platform/disassembler), if you start
disassembling from the middle of that 2-words instruction, then a NOP is
the only thing that can be reported.
In all other cases, the correct 2 word instructions should be recognized...

--
Ciao, Dario

2007\10\17@085418 by Jan-Erik Soderholm

face picon face
Alan B. Pearce wrote:
>>>> Hm, IIRC the NOPs you see in the debugger are just blank memory
>>>> locations.
>>> More likely they're the second word of two-word instructions.
>> We found that to be it.
>> Very stupid it is listed as NOP, they could just have used * or anything
>> else.
>
> Not really. IIRC PIC18 series chips have the second byte of a 2 byte
> instruction set up so they behave as a NOP, so that conditional jump
> instructions can deal with having a 2 byte instruction after them, as they
> step the program counter only 1 step, not 2.
>

And the cond.jump becomes a *3* cycle instruction when followed
by a 2-word instr. Easy to miss that... :-)

Jan-Erik.

2007\10\17@101921 by wouter van ooijen

face picon face
> But I think it's a problem of the way the libraries are
> implemented, not the
> library concept itself. In the end, you end up with your own
> "homegrown" set
> of libraries -- why can't the vendor provide those in the
> first place?

Because your library preferences arn't mine.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\10\17@104224 by Xiaofan Chen

face picon face
On 10/17/07, Vitaliy <KILLspamspamspamBeGonespammaksimov.org> wrote:
> Gerhard Fiedler wrote:
> > Regarding libraries, that's a bit like ECAD libs: in the end, you probably
> > make your own anyway, at least in a production environment (as opposed to
> > a hobbyist environment).
>
> Yes, we do the same. We don't use Eagle libraries for anything anymore. :)
>
> But I think it's a problem of the way the libraries are implemented, not the
> library concept itself. In the end, you end up with your own "homegrown" set
> of libraries -- why can't the vendor provide those in the first place? It
> makes sense to use the largest blocks available, especially if the problem
> is relatively straightforward.
>
> As someone has pointed out, libraries also provide a good starting point
> (tweak/change to suit your needs).

I pointed out this in my first reply to your post. C18 has a peripheral
library and Microchip does not want to support it any more at
some point. However it seems to me they may want to change.
The problem is that they forget to put a disclaim that the library
needs some fine tuning and may have bugs.

A relevant discusion:
http://forum.microchip.com/tm.aspx?m=282340

Notice some C18 and HiTech PICC18 power users refer
CCS/mikroC as toy compiler...

Xiaofan

2007\10\17@114558 by Brendan Gillatt

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vitaliy wrote:
{Quote hidden}

Ah, thanks for clearing that up!

- --
Brendan Gillatt
brendan {at} brendangillatt {dot} co {dot} uk
http://www.brendangillatt.co.uk
PGP Key: pgp.mit.edu:11371/pks/lookup?op=get&search=0xBACD7433
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFHFi4lkA9dCbrNdDMRAirJAKClIX6t8ULH0EfoQ3Xvgq6MA/nywwCfaox3
DPgRIBuuDw4pNHO3KM9EdXs=
=/tNG
-----END PGP SIGNATURE-----

2007\10\17@115927 by John Temples

flavicon
face
On Wed, 17 Oct 2007, Morgan Olsson wrote:

> Is it possible to tell what Erratas are implemented?
>
> Do they implement workarounds for bugs in SPI, UART etc, there are a lot of them.
> It could lead to negative effects out od user control or intent.
>
> How do they handle different bugs between different chip revisions...?
> Do you tell it what chip revision you use?

Hi-Tech documents which errata they've worked around in the manual.
You can enable/disable specific work arounds with command-line
options.

--
John W. Temples, III

2007\10\17@125049 by Walter Banks

picon face


Morgan Olsson wrote:

{Quote hidden}

Essentially that is what is done in the better compilers.

"It is the compilers job to make code that will run on the silicon"

In our compilers we look for solutions that will run on the
broadest spectrum of silicon possible and then it we can't
guarantee that the code will run we resort to processor specific
information communicated through the processor specific
header files.

This is a argument to use a compiler where there is an internal
data base of silicon issues is available to shape code generation
when processors are changed and code re-used.

Silicon I/O bugs are a lot more complex. Some of the bugs
must be dealt with at the library or driver level. A more complex
bug that we encounter in I/O is side effects based on order of
register access, for example buffers and flags are cleared based
on register access. A more complex case is the order requirements
to access 16 bit registers, both of these we code in our
compilers. These are the kind of issues that are encoded in
silicon revision to revision, for compiler writers it is often more
reliable to code around an issue and get it right once than repair
an inconvenient but not fatal silicon bug.

Walter Banks.

2007\10\17@194157 by Xiaofan Chen

face picon face
On 10/17/07, Walter Banks <@spam@walter@spam@spamspam_OUTbytecraft.com> wrote:

> > How do they handle different bugs between different chip revisions...?
> > Do you tell it what chip revision you use?
>
> Essentially that is what is done in the better compilers.
>
> "It is the compilers job to make code that will run on the silicon"


The compiler will help but it is the user's job to make the
code working. ;-)

By the way, why no MPC for PIC18? Is the market too small
for another compiler? Or did C18 spoil the market?

Xiaofan

2007\10\18@021128 by Vitaliy

flavicon
face
wouter van ooijen wrote:
>> But I think it's a problem of the way the libraries are
>> implemented, not the
>> library concept itself. In the end, you end up with your own
>> "homegrown" set
>> of libraries -- why can't the vendor provide those in the
>> first place?
>
> Because your library preferences arn't mine.

I don't want to start a pointless debate, but this is just another proof of
my assertion that an awful lot of people (especially us embedded engineers)
like to forge and thread their own nuts and bolts. Some of us even prefer to
mine our own iron ore.

Wow, I'm starting to use metaphors to prove my point, just like Russell! You
can't argue with metaphors! ;-D


2007\10\18@025348 by William \Chops\ Westfield

face picon face

On Oct 17, 2007, at 11:09 PM, Vitaliy wrote:

>>
>> Because your library preferences arn't mine.
>
> I don't want to start a pointless debate, but this is just another  
> proof of
> my assertion that an awful lot of people (especially us embedded  
> engineers)
> like to forge and thread their own nuts and bolts.

I have to admit that I feel pretty uncomfortable about the current  
crop of
ARM processors (for example) that provide a C library for accessing the
various peripherals on their chips, and not a whole lot else.  It  
reminds
me of the time I typed in a copy of 8085 Forth, ran it through my  
homemade
assembler, and tried to run it on my homemade 8085 simulator.  It didn't
work (of course?) and I was faced with the daunting task of figuring out
WHICH piece of software was broken.  Simulator, Assembler,  
transcription,
or the original published source?  If you write in assembler, and write
all the code yourself, you at least know that any bug that exists is in
YOUR code.  Having to debug someone else's library, or someone's  
compiler,
when you expected to have them "just work", really sucks.

(Of course, it's like code efficiency in compilers vs assembler.  95% of
the time it doesn't really matter.  Hopefully.  Because I REALLY, REALLY
want the 20% of the project that is "difficult" (and takes 80% of the  
time)
to be resolvable by me doing clever things in the right places, and  
NOT by
hunting down someone elses bugs.)

BillW

2007\10\18@032520 by Xiaofan Chen

face picon face
On 10/18/07, Vitaliy <spamBeGonespamspamKILLspammaksimov.org> wrote:
>
> I don't want to start a pointless debate, but this is just another proof of
> my assertion that an awful lot of people (especially us embedded engineers)
> like to forge and thread their own nuts and bolts. Some of us even prefer to
> mine our own iron ore.
>

Actually I kind of agree with you. A thoroughly tested library is of very
good value. Unfortunately the reality in the embedded arena is
different. Often you have pretty good and well tested standard C
libraries but you can not really expect very good and well tested
peripheral libraries right now, from any MCU vendors and
any MCU C compiler vendors. This has something to do with
the fact that a generic library will tend to be less efficient.

In the PIC C compiler world that the two leading compilers
do not do a good job providing a nice peripheral library. The others
may do a "better" job in providing a peripheral library but produce
not as good code. In this case, I will go with the one which is
less buggy even though with less peripheral library support.

Take note Hitech PICC/PICC18 has standard C library support
but you hardly use them in real world application.

Xiaofan

2007\10\18@033348 by Xiaofan Chen

face picon face
On 10/18/07, William Chops Westfield <.....westfwspam_OUTspammac.com> wrote:

> I have to admit that I feel pretty uncomfortable about the current
> crop of ARM processors (for example) that provide a C library
> for accessing the various peripherals on their chips, and not a
> whole lot else.

Which C Compiler vendor does this?

I do not think any of the leading ARM C compiler (Keil/IAR/etc)
providers provide a C libraries for accessing the various peripherals.
Often it is the MCU vendors who did the job by providing a firmware
framework. ST is a good example.

{Quote hidden}

That is why you pay for a good C compiler.  And you make your own
libraries. Often this will be based on some existing libraries (eg:
newlib for ARM7 MCUs) and the vendor supplied libraries.

> (Of course, it's like code efficiency in compilers vs assembler.  95% of
> the time it doesn't really matter.  Hopefully.  Because I REALLY, REALLY
> want the 20% of the project that is "difficult" (and takes 80% of the
> time) to be resolvable by me doing clever things in the right places, and
> NOT by hunting down someone elses bugs.)

I think if you go to ARM, code efficiency is often not the issue and very
few will write the code in assembly. Portability may or may not be a big
issue.  Code maintainability is much more important issue here.

Xiaofan

2007\10\18@034026 by Michael Rigby-Jones

picon face


{Quote hidden}

To continue the analogy, I think a lot of people like to use nuts and bolts with a standard thread.

Library functions that are supplied with the compiler to access peripherals vary widely in quality, functionality  and the interface that the compiler vendor has chosen to implement.  Why would I want every project that uses a different CPU to use an entirely different set of functions to achieve the same thing?  I'd far rather port my existing libraries to a new compiler, giving me a familiar interface and all the functionality I require.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\10\18@035326 by wouter van ooijen

face picon face
> >> But I think it's a problem of the way the libraries are
> implemented,
> >> not the library concept itself. In the end, you end up
> with your own
> >> "homegrown" set
> >> of libraries -- why can't the vendor provide those in the
> >> first place?
> >
> > Because your library preferences arn't mine.
>
> I don't want to start a pointless debate, but this is just
> another proof of
> my assertion that an awful lot of people (especially us
> embedded engineers)
> like to forge and thread their own nuts and bolts.

That might be true (I think it is true!), but my statement is no support
for it. I use Olimex for most PCB work, and they have certain
requirements with regard to silk screen line width and drill diameters.
And my PCBs are often used by hobbyists, so I prefer to use large pads
(if I don't it will cost me in support hours). I use things that are not
in the available libraries, so I had to learn to make library elements
anyway (no big deal).

To summary: I don't *like* to build my own library, I *must*!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\10\18@051232 by William \Chops\ Westfield

face picon face

On Oct 18, 2007, at 12:33 AM, Xiaofan Chen wrote:

>> I have to admit that I feel pretty uncomfortable about the current
>> crop of ARM processors (for example) that provide a C library
>> for accessing the various peripherals on their chips, and not a
>> whole lot else.
>
> Which C Compiler vendor does this?

Not compiler vendors.  Chip vendors.  Luminary, for instance.
Sometimes it seems like they expect the provided library to
replace thorough documentation of the peripheral...

BillW

2007\10\18@053105 by Xiaofan Chen

face picon face
On 10/18/07, William Chops Westfield <.....westfwspamRemoveMEmac.com> wrote:
>
> On Oct 18, 2007, at 12:33 AM, Xiaofan Chen wrote:
> >
> >Which C Compiler vendor does this?
> >
> >I do not think any of the leading ARM C compiler (Keil/IAR/etc)
> >providers provide a C libraries for accessing the various peripherals.
> >Often it is the MCU vendors who did the job by providing a firmware
> >framework. ST is a good example.
>
> Not compiler vendors.  Chip vendors.  Luminary, for instance.
> Sometimes it seems like they expect the provided library to
> replace thorough documentation of the peripheral...
>

I think the vendors are expected to give  good example codes
for the customers to jump-start the developement. This is
true for other MCU vendoes. Of course that is not
a good substitute for good documentations for the
peripherals. In the case of ARM, the core documentation
is already there so their jobs are already cut by quite  a bit.


Xiaofan

2007\10\18@061357 by Alan B. Pearce

face picon face
>> Because your library preferences arn't mine.
>
>I don't want to start a pointless debate, but this is just
>another proof of my assertion that an awful lot of people
>(especially us embedded engineers) like to forge and thread
>their own nuts and bolts. Some of us even prefer to
>mine our own iron ore.

But how many would use a provided library to get a project up and running
before attacking the library code, or replacing library code with your own?

Sometimes it pays to use the iron from someone elses foundry before setting
your mine ...

2007\10\18@085516 by Timothy J. Weber

face picon face
wouter van ooijen wrote:
> To summary: I don't *like* to build my own library, I *must*!

I agree - e.g., BoostC has a good set of libraries, including a module
for 1-Wire.  But, for one project I needed two separate 1-Wire buses,
and their library doesn't support that, so I used my own code from a
previous project, and added support for two buses.

Now, what if their library was open source?  And not only open source,
but really easy to get write access to?  Maybe I would have made the
modifications to their library instead, potentially benefiting the next guy.

There are other reasons to keep one's own library to oneself - the
competitive edge, e.g., or the perception thereof - but one of them is
the simple fact that most compilers' libraries don't (easily) accept
customizations from the outside world.  They're frozen, from the user's
standpoint, and frozen code is a liability more than an asset.
--
Timothy J. Weber
http://timothyweber.org

2007\10\18@092143 by Xiaofan Chen

face picon face
On 10/18/07, Timothy J. Weber <RemoveMEtwspamspamBeGonetimothyweber.org> wrote:
> wouter van ooijen wrote:
> > To summary: I don't *like* to build my own library, I *must*!
>
> I agree - e.g., BoostC has a good set of libraries, including a module
> for 1-Wire.  But, for one project I needed two separate 1-Wire buses,
> and their library doesn't support that, so I used my own code from a
> previous project, and added support for two buses.
>
> Now, what if their library was open source?  And not only open source,
> but really easy to get write access to?  Maybe I would have made the
> modifications to their library instead, potentially benefiting the next guy.
>
> There are other reasons to keep one's own library to oneself - the
> competitive edge, e.g., or the perception thereof - but one of them is
> the simple fact that most compilers' libraries don't (easily) accept
> customizations from the outside world.  They're frozen, from the user's
> standpoint, and frozen code is a liability more than an asset.

MPLAB C18 has a "open" library (not in the sense of open source
because of license restriction) but that does not translate to
a better library.

Related Microchip Forum Thread:
http://forum.microchip.com/tm.aspx?m=282340

Xiaofan

2007\10\18@094939 by wouter van ooijen

face picon face
> MPLAB C18 has a "open" library (not in the sense of open
> source because of license restriction) but that does not
> translate to a better library.

But it does have the advantange that you can grab the source, edit and
correct what you want, and use it. With closed source libraris the only
choices are use it or write your own.

I agree that the quality of the C18 libraries is not very high.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\10\18@100258 by Timothy J. Weber

face picon face
Xiaofan Chen wrote:
> MPLAB C18 has a "open" library (not in the sense of open source
> because of license restriction) but that does not translate to
> a better library.

To my mind, the degree of "openness" needed for libraries is not just
"you can get the source," but "you can integrate your changes back into
the source."  Because if you can't, every new release of the library
means you have to merge your changes in again.  Even if you have good
version control to help with that, it's annoying.

The argument that "libraries are too generalized to ever be practical"
seems like a generalization itself.  Libraries need to be flexible and
modular, support exactly the features you need but without any overhead
incurred by things you don't need, fit conceptually into your
architecture, etc.  That makes it hard to write good libraries, but that
doesn't mean they don't exist.
--
Timothy J. Weber
http://timothyweber.org

2007\10\18@130737 by William Benson

picon face

Hi,

I would like to know how to build a LIBRARY file?


BEN> From: spamBeGonewouter@spam@spamspam_OUTvoti.nl> To: TakeThisOuTpiclistspamspammit.edu> Subject: RE: [PIC] PIC18 C compiler comparison> Date: Thu, 18 Oct 2007 09:51:40 +0100> > > >> But I think it's a problem of the way the libraries are > > implemented, > > >> not the library concept itself. In the end, you end up > > with your own> > >> "homegrown" set> > >> of libraries -- why can't the vendor provide those in the> > >> first place?> > >> > > Because your library preferences arn't mine.> > > > I don't want to start a pointless debate, but this is just > > another proof of > > my assertion that an awful lot of people (especially us > > embedded engineers) > > like to forge and thread their own nuts and bolts.> > That might be true (I think it is true!), but my statement is no support> for it. I use Olimex for most PCB work, and they have certain> requirements with regard to silk screen line width and drill diameters.> And my PCBs are often used by hobbyists, so I prefer to use large pads> (if I don't it will cost me in support hours). I use things that are not> in the available libraries, so I had to learn to make library elements> anyway (no big deal).> > To summary: I don't *like* to build my own library, I *must*!> > Wouter van Ooijen> > -- -------------------------------------------> Van Ooijen Technische Informatica: http://www.voti.nl> consultancy, development, PICmicro products> docent Hogeschool van Utrecht: http://www.voti.nl/hvu> > > >

2007\10\18@134934 by wouter van ooijen

face picon face
> I would like to know how to build a LIBRARY file?

In what context? This discussion is/was about PIC18 C compilers, I was
talking about eagle.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\10\18@142022 by Vitaliy

flavicon
face
Xiaofan Chen wrote:
> I pointed out this in my first reply to your post. C18 has a peripheral
> library and Microchip does not want to support it any more at
> some point. However it seems to me they may want to change.
> The problem is that they forget to put a disclaim that the library
> needs some fine tuning and may have bugs.
>
> A relevant discusion:
> http://forum.microchip.com/tm.aspx?m=282340

Yes, I've run into this issue while writing code for a newer 18F. I ported
the libraries I wanted to use, then scrapped them and wrote my own
functions.

> Notice some C18 and HiTech PICC18 power users refer
> CCS/mikroC as toy compiler...

I couldn't find any such references by following the link above, except your
own:

"CCS is shipping some libraries but it is said to be very buggy."

Matt doesn't seem to think CCS is a toy.

2007\10\18@142027 by Vitaliy

flavicon
face
Matt Pobursky wrote:
> I don't think you can get the Windows IDE/Debugger with anything but PCWH.
> You can always use the PCB, PCM or in your case PCH (PIC18) command line
> compiler and debug with MPLAB. CCS does have a compiler plugin for MPLAB.

Matt, you think C18 is *better* than CCS? Aside from ANSI compliance (which
C18 is really not, 100%), what makes it better? From own experience, and a
recent thread (which I quoted in the OP), it sounds like C18 is actually
pretty dumb.

> If I were going down this road then I would probably use Microchip's C18
> or
> Hitech's PICC as they are slightly better compilers (ANSI compliant for
> instance). For me the real value in the CCS tools is the source level
> debugging of PCWH.

What if cost was not a big consideration, would you choose PCWH? And which
part of PCWH's source level debugging do you value the most?

2007\10\18@155814 by Vitaliy

flavicon
face
wouter van ooijen wrote:
> That might be true (I think it is true!), but my statement is no support
> for it. I use Olimex for most PCB work, and they have certain
> requirements with regard to silk screen line width and drill diameters.
> And my PCBs are often used by hobbyists, so I prefer to use large pads
> (if I don't it will cost me in support hours). I use things that are not
> in the available libraries, so I had to learn to make library elements
> anyway (no big deal).
>
> To summary: I don't *like* to build my own library, I *must*!

OK, then it seems that our disagreement is superfluous. In practice, we
never use standard EAGLE libraries (except to copy/modify), for two reasons:

1. We don't want the changes we make to components to be overwritten by the
next update.
2. We trust more in the quality of our "homegrown" libraries.

It seems to me that both issues are not unsurmountable.

I understand that there is often a need to write custom functions to solve a
particular problem, for which a generic function does not exist. However,
majority of code writing is not about solving unique problems.

The higher one goes up the chain, from assembly to HLLs, the better are the
opportunities for code reuse. One rarely sees programmers writing the code
to display a button, and in most circuimstances it's a lot less work to use
a library to communicate with the serial port, than to write one's own.
There's a higher probability that the code you buy from a vendor is also of
better quality -- because the code is exposed to more real-world testing,
and because the vendor can afford to make a bigger investment in the code
(he can sell it many times).

Recently I've started investigating design patterns:

http://tinyurl.com/yuhjgu

and have been thinking about the possibilities of using the Facade pattern,
or Adapter pattern to "decouple" my code from the library in order to
provide a simpler interface, and to "wrap" library functions to provide a
more consistent interface.

The book is relying heavily on OOP, and targeting desktop applications. In
the embedded world, the cost of an extra function call is often prohibitive.
Although if that is not the case, using wrappers can help speed up a project
considerably.

Instead or writing the code from scratch, simply write a wrapper that calls
a library function. If performance becomes an issue, you can always go back
and put "real" code in the wrapper, without affecting the rest of the
program.

Vitaliy


2007\10\18@165516 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Xiaofan Chen wrote:
>> A relevant discusion:
>> http://forum.microchip.com/tm.aspx?m=282340

>> Notice some C18 and HiTech PICC18 power users refer
>> CCS/mikroC as toy compiler...
>
> I couldn't find any such references by following the link above,

Second post on that page, by Kruse. Didn't mention specifically CCS or
mikroC, though.

Gerhard

2007\10\18@170137 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Instead or writing the code from scratch, simply write a wrapper that
> calls a library function. If performance becomes an issue, you can
> always go back and put "real" code in the wrapper, without affecting the
> rest of the program.

This is how I try to do things, at least on 18F projects, at least
initially. Of course this depends on your production numbers... if you're
designing for 100k a month, you use a different approach than when you're
designing for 1k a year. The balance between development time and hardware
cost is different. (I'm mostly in the lower number sector, which moves the
balance towards quicker development. With 1k a year, it takes quite a while
to pay two weeks of code optimization that resulted in $1 less hardware
cost -- with 100k a month, this is a no-brainer :)

Gerhard

2007\10\18@194141 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
>> Xiaofan Chen wrote:
>>> A relevant discusion:
>>> http://forum.microchip.com/tm.aspx?m=282340
>
>>> Notice some C18 and HiTech PICC18 power users refer
>>> CCS/mikroC as toy compiler...
>>
>> I couldn't find any such references by following the link above,
>
> Second post on that page, by Kruse. Didn't mention specifically CCS or
> mikroC, though.

Kruse is a condescending know-it-all with the "REAL men don't use no
libraries" attitude:

"Listen mate:
If you are looking for 'prefabricated' libraries and other amatuer stuff
there are several toy compilers that will fullfill your needs.

Proffesionals do their libraries them selves since those libraries you are
refering to are seldom usefull for anything else than demonstration."

Learn to spell, dude.

2007\10\18@194604 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
> Of course this depends on your production numbers... if you're
> designing for 100k a month, you use a different approach than when you're
> designing for 1k a year. The balance between development time and hardware
> cost is different. (I'm mostly in the lower number sector, which moves the
> balance towards quicker development. With 1k a year, it takes quite a
> while
> to pay two weeks of code optimization that resulted in $1 less hardware
> cost -- with 100k a month, this is a no-brainer :)

Very true.

2007\10\18@200541 by Xiaofan Chen

face picon face
On 10/19/07, Vitaliy <spamEraseMEspammaksimov.org> wrote:
> Gerhard Fiedler wrote:
> > Of course this depends on your production numbers... if you're
> > designing for 100k a month, you use a different approach than when you're
> > designing for 1k a year. The balance between development time and hardware
> > cost is different. (I'm mostly in the lower number sector, which moves the
> > balance towards quicker development. With 1k a year, it takes quite a
> > while
> > to pay two weeks of code optimization that resulted in $1 less hardware
> > cost -- with 100k a month, this is a no-brainer :)
>
> Very true.
>

And the thing is often this 1k per year project need to be supported
in 10 years (often the case in Industrial Automation market). Therefore
maintainability is quite important. In the last job,a Germany colleague
used CCS compiler and he had to specifically archive that particular version
of CCS C compiler along with the codes. He found that different
version of CCS C compiler produced different code which might or
might not work. That is about 3 years ago so I am not sure about the
situation now.

I also want to have quicker development, but never achieved it.

Xiaofan

2007\10\18@211909 by Gerhard Fiedler

picon face
Vitaliy wrote:

>> Second post on that page, by Kruse.

> Kruse is a condescending know-it-all [...]

I didn't mean to say that I agree with him :)

But some of these compilers with lots of peripheral support don't seem to
publish the sources for their libs. For me, that's a no-no, at least for
professional use. (And probably would also be for hobby use.)

Gerhard

2007\10\19@000422 by Matt Pobursky

flavicon
face
On Wed, 17 Oct 2007 23:18:58 -0700, Vitaliy wrote:
> Matt Pobursky wrote:
>> I don't think you can get the Windows IDE/Debugger with anything but
>> PCWH. You can always use the PCB, PCM or in your case PCH (PIC18)
>> command line compiler and debug with MPLAB. CCS does have a compiler
>> plugin for MPLAB.
>>
>
> Matt, you think C18 is *better* than CCS? Aside from ANSI compliance
> (which C18 is really not, 100%), what makes it better? From own
> experience, and a recent thread (which I quoted in the OP), it sounds
> like C18 is actually pretty dumb.

Sorry, my point was if you are going to debug in MPLAB then you might as
well use C18 since (last I checked) you lose a lot of the cool debug
features of PCWH when using PCW and the plugin for MPLAB. My experience is
that PCW produces significantly smaller code a lot of the time than C18. I
haven't checked C18 in the past few years so that may have changed but I
doubt it's changed significantly. Hitech PICC generates very good code, as
does Bytecraft's MPC. When I made a decision on which PIC tools to
standardize on they didn't have integrated debuggers and relied on MPLAB.

>> If I were going down this road then I would probably use Microchip's
>> C18 or
>> Hitech's PICC as they are slightly better compilers (ANSI compliant for
>> instance). For me the real value in the CCS tools is the source level
>> debugging of PCWH.
>>
>
> What if cost was not a big consideration, would you choose PCWH? And
> which part of PCWH's source level debugging do you value the most?

I can get C18 almost for free since I'm a registered Microchip Consultant.
I still use PCWH because it's faster overall to debug code for us. Things
like "mouse overs" to display a variable value, display of local variables,
structs, arrays, working with breakpoints, breakpoints inside interrupts
-- generally anything that is tightly coupled to the compiler.

I think with the PIC it's very difficult to write a good C compiler since
it has no real software stack, a limited hardware stack and constant tables
are somewhat problematic. The tool vendors use different tricks and methods
to optimize the code generation and that makes debugging difficult and
fairly compiler specific. It seems that all the plugins for MPLAB are
pretty generic and not very tightly coupled with the compiler. Whether this
is the tool vendors fault or MPLAB's I don't know.

I contrast that to the tools available for the MSP430. They are virtually
all excellent, all produce decent code and most of them are very
affordable. It's just a much easier architecture to write a C compiler and
debugger for.

Matt Pobursky
Maximum Performance Systems

2007\10\19@001440 by Matt Pobursky

flavicon
face
On Wed, 17 Oct 2007 23:24:45 -0700, Vitaliy wrote:
{Quote hidden}

No, I don't. We don't use the CCS supplied libraries all that much except
for "quick and dirty" projects -- test code, test sets, things like that.
For production code we have a standard framework template and a lot of
libraries we've developed that port easily from one microcontroller family
to another.

CCS is always a "work in progress". As long as you remember this and stick
with a version you find stable then you will be OK. I just recently
upgraded to their 4.x version because I needed support for some newer PICs.
The 4.x version of the compiler was a major overhaul and the early versions
were quite buggy (sounds like Windows, huh?). I let the dust settle over
the past six months and the version I'm running now seems very stable and
I've had no problems with it. I had been using the same previous 3.x
version for well over a year before that and still have it installed.

Matt Pobursky
Maximum Performance Systems

2007\10\19@002346 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
>> Kruse is a condescending know-it-all [...]
>
> I didn't mean to say that I agree with him :)

I didn't think so. :)

> But some of these compilers with lots of peripheral support don't seem to
> publish the sources for their libs. For me, that's a no-no, at least for
> professional use. (And probably would also be for hobby use.)

Does CCS provide source code for their libraries? I agree that that is a
must.

2007\10\19@002634 by Matt Pobursky

flavicon
face
On Fri, 19 Oct 2007 08:05:40 +0800, Xiaofan Chen wrote:
{Quote hidden}

I've found that to be true with pretty much every tool set we use here.
It's been our policy to archive the tool set used to create the production
code at every release. It's the only way we can guarantee that we can re-
create the code at a later date. We also put a note of which development
tools and version were used to create the code in each header file for each
module in a software project.

This strategy has paid dividends quite a few times. Just recently we had a
client request a code change to a product that was designed by us back in
the mid-1980's. We had the tools and code archived away and were able to do
it, much to their surprise.

Matt Pobursky
Maximum Performance Systems

2007\10\19@004736 by Xiaofan Chen

face picon face
On 10/19/07, Matt Pobursky <@spam@piclistRemoveMEspamEraseMEmps-design.com> wrote:
> > Matt doesn't seem to think CCS is a toy.
>
> No, I don't. We don't use the CCS supplied libraries all that much except
> for "quick and dirty" projects -- test code, test sets, things like that.
> For production code we have a standard framework template and a lot of
> libraries we've developed that port easily from one microcontroller family
> to another.

Now I understand your point. You do not use the CCS libraries! And that
is the point CCS is touting against other C compilers.

> CCS is always a "work in progress". As long as you remember this and stick
> with a version you find stable then you will be OK. I just recently
> upgraded to their 4.x version because I needed support for some newer PICs.
> The 4.x version of the compiler was a major overhaul and the early versions
> were quite buggy (sounds like Windows, huh?). I let the dust settle over
> the past six months and the version I'm running now seems very stable and
> I've had no problems with it. I had been using the same previous 3.x
> version for well over a year before that and still have it installed.

I see. This is very good advice for CCS users. So the commens that
CCS was buggy is really true but the new versions are better according
to your experiences.

Xiaofan

2007\10\19@005447 by Bob Blick

face picon face
Matt Pobursky wrote:

>
> I've found that to be true with pretty much every tool set we use here.
> It's been our policy to archive the tool set used to create the production
> code at every release. It's the only way we can guarantee that we can re-
> create the code at a later date. We also put a note of which development
> tools and version were used to create the code in each header file for each
> module in a software project.
>
> This strategy has paid dividends quite a few times. Just recently we had a
> client request a code change to a product that was designed by us back in
> the mid-1980's. We had the tools and code archived away and were able to do
> it, much to their surprise.

Here's a place where I'll get on my soapbox. Imagine for a moment if
your toolset requires a hardware dongle, key disk, or remote activation.
Can make it kind of difficult in some scenarios. I tried to explain that
recently to HiTech but they had themselves convinced that they weren't
going to lose any customers other than me.

Cheerful regards,

Bob

2007\10\19@014841 by William \Chops\ Westfield

face picon face

On Oct 18, 2007, at 5:05 PM, Xiaofan Chen wrote:

> maintainability is quite important.

One of the things we've run into is limits to growth.  If you
use you own home-grown libraries or home-modified libraries,
you can never hire anyone who knows anything about them, and
anyone you DO hire will have to go through a longer "training"
period trying to learn what your libraries do.  They'll probably
never figure out all the wonderful nuances that you put in when
you wrote it, and they might as well be using some similar standard
library.  Worse, not fully understanding the library, they may add
bugs.  If you had used the "XYZ C library for PICs" (from the
well known XYZ compiler company), you could just advertise for
someone familiar with that library.

BillW

2007\10\19@042017 by wouter van ooijen

face picon face
> In
> the embedded world, the cost of an extra function call is often
prohibitive.
> Although if that is not the case, using wrappers can help speed up a
project
> considerably.

If that extra call is your main concert check whether you can write your
wrapper or adapter as a macro, or maybe both in a
function call version (easier for argument type error reporting) and in
a macro version.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2007\10\19@071148 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Does CCS provide source code for their libraries? I agree that that is a
> must.

Matt would be more qualified to respond to this :)

However, on this page
<http://www.ccsinfo.com/content.php?page=compspecific> they call them
"built-in functions", which doesn't sound like "library with source code
provided". On other pages, they refer to the same functions as being part
of "libraries", though. (I guess it's either one or the other; this is an
expression of what I didn't like about CCS.)

FWIW, all the HiTech libraries come with sources. Most of it is C, with
some optimized assembly interspersed.

Gerhard

2007\10\19@073822 by Walter Banks

picon face


Gerhard Fiedler wrote:

{Quote hidden}

Byte Craft MPC supplies sources for all of its libraries. Our libraries are
written entirely in C. If we had to resort to assembler it would mean there
something amiss in the compiler :)

Regards

--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
Fax (519) 746 6751
http://www.bytecraft.com
EraseMEwalterspam@spam@bytecraft.com


2007\10\19@081407 by Xiaofan Chen

face picon face
On 10/19/07, Walter Banks <@spam@walterspam_OUTspam.....bytecraft.com> wrote:
> > FWIW, all the HiTech libraries come with sources. Most of it is C, with
> > some optimized assembly interspersed.
>
> Byte Craft MPC supplies sources for all of its libraries. Our libraries are
> written entirely in C. If we had to resort to assembler it would mean there
> something amiss in the compiler :)
>

That is a very interesting remark. As far as I know, most MCU
C compilers all have kind of startup code and some libraries
function written in assembly or inline assembly code.

Example: MPLAB C18, MPLAB C30, AVR-GCC, IAR
for ARM, Keil C51.

Xiaofan

2007\10\19@085330 by Xiaofan Chen

face picon face
On 10/19/07, Bob Blick <spamBeGonebbblickEraseMEspamsbcglobal.net> wrote:
> Here's a place where I'll get on my soapbox. Imagine for a moment if
> your toolset requires a hardware dongle, key disk, or remote activation.
> Can make it kind of difficult in some scenarios. I tried to explain that
> recently to HiTech but they had themselves convinced that they weren't
> going to lose any customers other than me.
>

It is a bit difficult for them to do in this case. For small compiler
vendors, it is not easy to do copyright protection other than
resort to hardware dongle or locking to IP address.

Without copyright protection, the vendors may suffer loss of
revenue due to missue of the software.

I am not so sure if there are good answers to software
copyright protection methods for ptofssional software with
relative few customers.

When I bought PICC 7.85, therre was no dongle and key
disk. But now we have dongles for IAR C compiler for ARM.
And our Keil C51 Compiler licenses are locked to IP
addresses (they allow one desktop and one laptop for
one license since the developer will use both).

Xiaofan

2007\10\19@085406 by Walter Banks

picon face


Bob Blick wrote:

{Quote hidden}

As a software tools developer we have thought about both of these issues a
lot.

1) Archived compilers need to have a reasonable probability of running
   when they are reloaded on systems often many years later. This means
   implementation rules for the tools originally must be conservative without
   any version specific OS requirements.

2) Protection is basically inconvenient all round. Most protection schemes
   don't achieve very well and it is essential to be able to wake up and
   old project and initially use  the original tools to validate that the
   archived sources and builds will still create the expected application
   code. Most protection schemes hurt most the very customers
   that tool companies want to have.

   Lots of companies get obsessed with protection. Most customers
   just want to get their development projects done and when needed
   get answers to their questions and timely response to tools issues.

   We decided against protection schemes a long time ago having
   decided it was counter productive.

w..


2007\10\19@085943 by Xiaofan Chen

face picon face
On 10/19/07, Matt Pobursky <piclistspamBeGonespammps-design.com> wrote:
> I think with the PIC it's very difficult to write a good C compiler since
> it has no real software stack, a limited hardware stack and constant tables
> are somewhat problematic. The tool vendors use different tricks and methods
> to optimize the code generation and that makes debugging difficult and
> fairly compiler specific. It seems that all the plugins for MPLAB are
> pretty generic and not very tightly coupled with the compiler. Whether this
> is the tool vendors fault or MPLAB's I don't know.
>
> I contrast that to the tools available for the MSP430. They are virtually
> all excellent, all produce decent code and most of them are very
> affordable. It's just a much easier architecture to write a C compiler and
> debugger for.
>

I found TI MCUs are good but they do not offer enough mix of
chips. MSP430 is nice but of limited use IMHO. And I would not
say that their documentation is good.

Maybe dsPICs/PIC24 change the situation for Microchip. MPLAB C30
(based on GCC) is said to be rpetty decent.

Xiaofan

2007\10\19@151720 by Gerhard Fiedler

picon face
Xiaofan Chen wrote:

> On 10/19/07, Walter Banks <RemoveMEwalter@spam@spamspamBeGonebytecraft.com> wrote:
>>> FWIW, all the HiTech libraries come with sources. Most of it is C, with
>>> some optimized assembly interspersed.
>>
>> Byte Craft MPC supplies sources for all of its libraries. Our libraries
>> are written entirely in C. If we had to resort to assembler it would
>> mean there something amiss in the compiler :)
>
> That is a very interesting remark. As far as I know, most MCU C
> compilers all have kind of startup code and some libraries function
> written in assembly or inline assembly code.
>
> Example: MPLAB C18, MPLAB C30, AVR-GCC, IAR for ARM, Keil C51.

For example, HiTech supplies a NOP() macro, which is implemented as
embedded assembly. I wouldn't know how to do that in standard C.

Gerhard

2007\10\20@032452 by Vitaliy

flavicon
face
wouter van ooijen wrote:
>> In
>> the embedded world, the cost of an extra function call is often
> prohibitive.
>> Although if that is not the case, using wrappers can help speed up a
> project
>> considerably.
>
> If that extra call is your main concert check whether you can write your
> wrapper or adapter as a macro, or maybe both in a
> function call version (easier for argument type error reporting) and in
> a macro version.

Good point.


2007\10\20@033202 by Vitaliy

flavicon
face
Walter Banks wrote:
> Byte Craft MPC supplies sources for all of its libraries. Our libraries
> are
> written entirely in C. If we had to resort to assembler it would mean
> there
> something amiss in the compiler :)

Walter, the website is kind of difficult to navigate. So what would I need
to program an 18F or a 24H?

Vitaliy

PS I read the "C versus Assembly" article over dinner, and found it to be
sort of dry... like there was more to be said. I don't know why, but I was
expecting something more exciting, like "developer X saw a 30% improvement
in space use and performance by rewriting the Assembly program in C, and
said he'll never go back". :)

2007\10\20@062740 by Xiaofan Chen

face picon face
On 10/20/07, Vitaliy <.....spam@spam@spamEraseMEmaksimov.org> wrote:
> Walter, the website is kind of difficult to navigate. So what would I need
> to program an 18F or a 24H?
>

I think the website is very easy to navigate but they do not have anything
on 18F and dsPIC/PIC24 on the website since they do not support it yet.

The MPC demo is also quite old. The list of supported PICs for MPC are
quite old (no added chip after 2004). I actually downloaded the MPC demo
and found out the example projects are for Microchip MPLAB 6 and did
not work right out of the box so I gave up.
www.bytecraft.com/Devices__Microchip_PIC
Projects failed to be built:
C:\Program Files\Byte Craft\MPC Demo\Examples\MPLAB_6

Worse is that after the error, I need to go to Windows Task
Manger and kill the process MPCW.exe and MPLAB.exe.

Maybe this is because I am using MPLAB 7.62.

Maybe the website has not been updated for a while.

Sorry but this is what I just tried and I think I should report this.

Xiaofan


'[PIC] PIC18 C compiler comparison'
2007\11\04@082025 by Walter Banks
picon face


Vitaliy wrote:

> Walter Banks wrote:
> > Byte Craft MPC supplies sources for all of its libraries. Our libraries
> > are> written entirely in C. If we had to resort to assembler it would mean
>
> > there something amiss in the compiler :)
>
> PS I read the "C versus Assembly" article over dinner, and found it to be
> sort of dry... like there was more to be said. I don't know why, but I was
> expecting something more exciting,

Proof that there is no code size or execution time advantage by writting in
assembler.

The white paper addressed how we established that we could write
any program in C in equal or less space than an implementation in asm.

Regards

--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
Fax (519) 746 6751
http://www.bytecraft.com
.....walterRemoveMEspambytecraft.com






2007\11\07@021041 by Vitaliy

flavicon
face
Walter Banks wrote:
>> Walter Banks wrote:
>> > Byte Craft MPC supplies sources for all of its libraries. Our libraries
>> > are> written entirely in C. If we had to resort to assembler it would
>> > mean
>>
>> > there something amiss in the compiler :)
>>
>> PS I read the "C versus Assembly" article over dinner, and found it to be
>> sort of dry... like there was more to be said. I don't know why, but I
>> was
>> expecting something more exciting,
>
> Proof that there is no code size or execution time advantage by writting
> in
> assembler.
>
> The white paper addressed how we established that we could write
> any program in C in equal or less space than an implementation in asm.

Yeah, I got that part -- and my comment ended with a smiley. You cut off the
key part, where I explain what I mean by "something more exciting". An
actual "field test" (rewriting an Assembly program using C), versus
"replacing this Assembly snippet with C results in more compact code".

No big deal, really -- I'm not arguing that your conclusions are invalid.
And I'm sure the paper is exciting in a "written for engineers, by
engineers" sort of way. ;-)

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