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

Exact match. Not showing close matches.
PICList Thread
'[PIC] Your Favorite PIC C Compiler.'
2006\08\23@175214 by Bob Axtell

face picon face
Suddenly, I have to use C.

Which one do you experts like best? Cost is not the
overall consideration, ease of use is.

--Bob

2006\08\23@180244 by Bob Blick

face picon face
> Suddenly, I have to use C.
>

Suddenly, we'd like to know which PICs you intend to use C with.

Cheers,

Bob


2006\08\23@180621 by David Novak

picon face
Hi-Tech is my favorite, but too expensive. BoostC is a very close second
with some things better than Hi-Tech and some worse. For the price, BoostC
is the way to go. I expect it will only get better over time.

David


-----Original Message-----
From: Bob Axtell [spam_OUTengineerTakeThisOuTspamneomailbox.com]
Sent: Wednesday, August 23, 2006 5:52 PM
To: Microcontroller discussion list - Public.
Subject: [PIC] Your Favorite PIC C Compiler.

Suddenly, I have to use C.

Which one do you experts like best? Cost is not the
overall consideration, ease of use is.

--Bob

2006\08\23@181039 by Paul James E.

picon face

Bob,

I've tried several.  I own CCS C (PCW), and it's okay.
I've tried C2C.  Again okay.  But I don't really care for it.
I don't own a full copy yet, but I've tried Mikroelektronika
demo version, and I like it a lot.  It has lots of built in
functions, easy to use, and cost is reasonable (~$250.00 USD).

These are my opinions.  But I still prefer assembly language.
Although, I have a project where I need to write in Basic.
So, I'll probably get the Mikroelektronika BASIC compiler.
It's only $150.00 USD.  And I like it too.

YMMV



                                     Regards,

                                      Jim




> Suddenly, I have to use C.
>
> Which one do you experts like best? Cost is not the
> overall consideration, ease of use is.
>
> --Bob
>
> --

2006\08\23@182256 by Bob Axtell

face picon face
Bob Blick wrote:
>> Suddenly, I have to use C.
>>
>>    
>
> Suddenly, we'd like to know which PICs you intend to use C with.
>
> Cheers,
>
> Bob
>
>
>  
Well, I had in mind 16F877A, but I can go with a similar 18F. haven't
looked recently.

--Bob

2006\08\23@182348 by Bob Axtell

face picon face
David Novak wrote:
> Hi-Tech is my favorite, but too expensive. BoostC is a very close second
> with some things better than Hi-Tech and some worse. For the price, BoostC
> is the way to go. I expect it will only get better over time.
>
>  
How expensive is expensive?
Got a link for BoostC?

--Bob
{Quote hidden}

2006\08\23@182828 by Harold Hallikainen

face picon face
I'm using Microchip's C18, and it works fine for me!

Harold


> Suddenly, I have to use C.
>
> Which one do you experts like best? Cost is not the
> overall consideration, ease of use is.
>
> --Bob
>
> -

2006\08\23@183538 by Robert Young

picon face
>
>
> Bob Blick wrote:
> >> Suddenly, I have to use C.
> >>
> >>    
> >
> > Suddenly, we'd like to know which PICs you intend to use C with.
> >
> > Cheers,
> >
> > Bob
> >
> >
> >  
> Well, I had in mind 16F877A, but I can go with a similar 18F. haven't
> looked recently.

CCS C is pretty good but I strongly advise NOT using the latest V4
update as it is too buggy.  Once you are a registered user and the the
appropriate license files, you can download the last stable V3 version
and use that.  Integrates pretty well with MPLAB 7.40

Also, by the way, MPLAB V7.41 comes with the CCS PCB (should be good for
the F877A) for free.

Rob

2006\08\23@184207 by piclist

flavicon
face
On Wed, 23 Aug 2006, Bob Axtell wrote:

> Suddenly, I have to use C.
>
> Which one do you experts like best? Cost is not the
> overall consideration, ease of use is.

I've been using Hi-Tech for over 8 years.  I've dabbled with other
compilers, but none come close in code quality, level of ANSI
compliance, or support.

--
John W. Temples, III

2006\08\23@185052 by rwuest

flavicon
face
Hi-Tech's C has worked very well for me and has handled everything I throw at
it, that is, it seems to support the complete C language and then some.  It
also runs on Linux which was the ultimate deciding factor when I bought it 6
years ago.  It also produces very good code.  Several hand coded in assembler
routines, I have re-written in Hi-Tech C with very good results (and lot's
easier to maintain that way).

It looks like SourceBoosts c2c compiler runs on Linux, but the BoostC is
windows only. Too bad. I'd love to give it a try, but switching to windows is
to high a price to pay.

Robert

On Wed, 23 Aug 2006 18:06:16 -0400, David Novak wrote
{Quote hidden}

> --

2006\08\23@185104 by Bob Axtell

face picon face
Paul James E. wrote:
>  Bob,
>
>  I've tried several.  I own CCS C (PCW), and it's okay.
>  I've tried C2C.  Again okay.  But I don't really care for it.
>  I don't own a full copy yet, but I've tried Mikroelektronika
>  demo version, and I like it a lot.  It has lots of built in
>  functions, easy to use, and cost is reasonable (~$250.00 USD).
>
>  These are my opinions.  But I still prefer assembly language.
>  Although, I have a project where I need to write in Basic.
>  So, I'll probably get the Mikroelektronika BASIC compiler.
>  It's only $150.00 USD.  And I like it too.
>
>  
I prefer MASM, too, but this job needs floating point, so I need a C
compiler with a
decent math unit. Its too difficult to fiddle with floating point MASM.

--Bob



{Quote hidden}

>> --

2006\08\23@190513 by Bob Axtell

face picon face
piclist@xargs.com wrote:
> On Wed, 23 Aug 2006, Bob Axtell wrote:
>
>  
>> Suddenly, I have to use C.
>>
>> Which one do you experts like best? Cost is not the
>> overall consideration, ease of use is.
>>    
>
> I've been using Hi-Tech for over 8 years.  I've dabbled with other
> compilers, but none come close in code quality, level of ANSI
> compliance, or support.
>
>  
I just took a look. If an F877A is used, can it generate float32 code?

--Bob

> --
> John W. Temples, III
>  

2006\08\23@190735 by Bob Axtell

face picon face
rwuest@wuest.org wrote:
> Hi-Tech's C has worked very well for me and has handled everything I throw at
> it, that is, it seems to support the complete C language and then some.  It
> also runs on Linux which was the ultimate deciding factor when I bought it 6
> years ago.  It also produces very good code.  Several hand coded in assembler
> routines, I have re-written in Hi-Tech C with very good results (and lot's
> easier to maintain that way).
>
> It looks like SourceBoosts c2c compiler runs on Linux, but the BoostC is
> windows only. Too bad. I'd love to give it a try, but switching to windows is
> to high a price to pay.
>
>  
How much is HiTech C for Windoze?

--Bob

{Quote hidden}

>> --

2006\08\23@194012 by piclist

flavicon
face
On Wed, 23 Aug 2006, Bob Axtell wrote:

>> I've been using Hi-Tech for over 8 years.  I've dabbled with other
>> compilers, but none come close in code quality, level of ANSI
>> compliance, or support.
>>
> I just took a look. If an F877A is used, can it generate float32 code?

It uses 24-bit floats/doubles by default, but 32 bit is availble via
command-line option.

--
John W. Temples, III

2006\08\23@194044 by rwuest

flavicon
face
www.htsoft.com/purchase/pricelist.php


On Wed, 23 Aug 2006 16:07:33 -0700, Bob Axtell wrote
{Quote hidden}

> >> {Original Message removed}

2006\08\23@194137 by David Novak

picon face
BoostC can be found at http://www.sourceboost.com/. They have several
license levels, but the pro is only $150. Hi-Tech
(http://www.htsoft.com/purchase/pricelist.php) is about $1000.

David


{Original Message removed}

2006\08\23@194511 by Bob Blick

face picon face

> Well, I had in mind 16F877A, but I can go with a similar 18F. haven't
> looked recently.

Hi Bob,

I've used HiTech extensively with the 16F877A, and it works well. It's
quite mature, I don't know of any bugs in it. Doesn't come with many
pic-specific functions, you must roll your own. Supports bit operations in
several ways. Inline assembly three different ways. You can have multiple
source files each with different optimization levels. Easy to modify the
startup code. Works fine with bootloaders. Well documented.

I suggest you download the free version, PICCLITE, and give it a
once-over. It's limited to 2K output and two RAM banks, optimization is
limited, but it is quite good for what it is and will give you an idea of
what the full version is like.

Don't use their IDE.

Cheerful regards,

Bob


2006\08\23@195107 by Xiaofan Chen

face picon face
On 8/23/06, Bob Axtell <engineerspamspam_OUTneomailbox.com> wrote:
> >
> >
> How much is HiTech C for Windoze?
>

You can't go wrong with HiTech C for PIC16F. It is the same price
for Windows/Linux and Mac : US$950 for single license.

When I purchased it for my previous employer back in year 2000,
I add the extended support option (US$250) and the printed manual
(US$50). It was a good decision along with the purchase of Promate
II and ICE2000 since I had an important project at that time.

http://www.htsoft.com/purchase/price_usa.pdf

For PIC18F, you can go with the free Microchip MPLAB C18 version. It
is free even for commercial use. When it expired, only some optimizations
are turned off.

Regards,
Xiaofan

2006\08\23@200119 by Mark Rages

face picon face
On 8/23/06, Bob Axtell <@spam@engineerKILLspamspamneomailbox.com> wrote:
> >
> >
> I prefer MASM, too, but this job needs floating point, so I need a C
> compiler with a
> decent math unit. Its too difficult to fiddle with floating point MASM.
>
> --Bob

You can cross SDCC off your list.  Its floating point routines are in
ANSI C (i.e., not optimized assembly) and as recently as a month ago I
found a serious denormalization bug in the multiply routines, which
makes me think FP isn't well tested in that compiler.  (To be fair:
PIC support in SDCC is still maturing, and my bug was fixed quickly.
I've done a lot of floating point with the latest build of SDCC
without problems.)

Have you tried FP in assembly? It wasn't too terribly hard to do
floating point using Microchip's routines, once I got set up for it.
(look at piclist.com for the bugfixes!)

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\08\23@200537 by cdb

flavicon
face
I use FED C from Forest Electronics in the UK.

The code is reasonably compact - though as it uses a software stack
there is a bit of code bloat.

Its biggest attribute is the excellent debugging screen and inbuilt
terminal especially in the pro version that allows a multiple Pic
project to be modelled.

Unfortunately the demo that is locked to a 16F877 uses the RAD
interface which can only be turned off once purchased.

http://www.fored.co.uk

I used FED C to program the water meter project that is on the Piclist
competition page.

Colin

--
cdb, KILLspamcolinKILLspamspambtech-online.co.uk on 24/08/2006

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359

Do No Harm.

We must never do evil that good may come of it: William Penn 1693

.



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.405 / Virus Database: 268.11.5/426 - Release Date: 8/23/2006


2006\08\23@210354 by Peter Gelsi

flavicon
face
I also use FED C, from Forest Electronics in the UK.

I tried many different C compilers and went back to FED C

cdb wrote:

{Quote hidden}

Yes I like this, the simulator and the wave generator.  In the FED C pro
version.
For the price it's great.

>Unfortunately the demo that is locked to a 16F877 uses the RAD
>interface which can only be turned off once purchased.
>
>http://www.fored.co.uk
>  
>

Peter

2006\08\23@221954 by John Chung

picon face
Hitech free edition supports 16F877A

John

--- Bob Axtell <RemoveMEengineerTakeThisOuTspamneomailbox.com> wrote:

{Quote hidden}

> --

2006\08\23@223810 by John Chung

picon face
So far most implementation of fp in C are big......
What you can do is download the Hitech free version
and look at the output of the fp subroutine. BTW, do
you really need fp? You can get away by converting to
integers and then convert it back.

John


--- Bob Axtell <spamBeGoneengineerspamBeGonespamneomailbox.com> wrote:

{Quote hidden}

2006\08\23@224610 by Bob Blick

face picon face

> >
> >  
> I just took a look. If an F877A is used, can it generate float32 code?

The free version of HiTech supports 24 bit floats. The $950 version
supports 32 bit floats.

Cheers,

Bob

2006\08\24@004005 by Mike Hagen

flavicon
face


I have BoostC ver 6.4.  It integrates into MPLAB and Debugger.

It does not do floating point but they say you can use Microchips
Library?

I have use BoostC a little but not tried using the Microchip FP library
yet.


http://www.sourceboost.com/Products/BoostC/ExampleCode.html





Mike Hagen
Hagen Engineering
Crestline, Ca.
TakeThisOuTMikeEraseMEspamspam_OUTHagenEng.com
(909) 338-5521




2006\08\24@010804 by cdb

flavicon
face
Just going off at a slight angle - there is also XCSB basic that uses
a structured C like language - this has a tight FP library.

Colin

--
cdb, RemoveMEcolinspamTakeThisOuTbtech-online.co.uk on 24/08/2006

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359

Do No Harm.

We must never do evil that good may come of it: William Penn 1693

.



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.405 / Virus Database: 268.11.5/426 - Release Date: 8/23/2006


2006\08\24@014055 by Bob Axtell

face picon face
Mike Hagen wrote:
> I have BoostC ver 6.4.  It integrates into MPLAB and Debugger.
>
> It does not do floating point but they say you can use Microchips
> Library?
>
>  
Some years ago, I tried to follow Microchip's MASM FP routines, and they
seemed to not be right...
That's why I need C. I don't want to have to re-invent the wheel.

--Bob

{Quote hidden}

2006\08\24@014209 by Bob Axtell

face picon face
cdb wrote:
> Just going off at a slight angle - there is also XCSB basic that uses
> a structured C like language - this has a tight FP library.
>
>  
I could use basic. Got a link?

--Bob

{Quote hidden}

2006\08\24@014317 by Bob Axtell

face picon face
Bob Blick wrote:
>>>  
>>>      
>> I just took a look. If an F877A is used, can it generate float32 code?
>>    
>
> The free version of HiTech supports 24 bit floats. The $950 version
> supports 32 bit floats.
>
> Cheers,
>
> Bob
>
>  
But you know, 24-bit floats might be enough...HiTech is looking better
and better.

--Bob

2006\08\24@014613 by Marcel van Lieshout

flavicon
face
For several years already, I use wizC from http://www.fored.co.uk

Great compiler
Great simulator

Marcel

Bob Axtell wrote:
> Suddenly, I have to use C.
>
> Which one do you experts like best? Cost is not the
> overall consideration, ease of use is.
>
> --Bob

2006\08\24@014907 by cdb

flavicon
face
www.xcprod.com

If you go to my website you can see programs written using this.

Colin

--
cdb, RemoveMEcolinEraseMEspamEraseMEbtech-online.co.uk on 24/08/2006

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359

Do No Harm.

We must never do evil that good may come of it: William Penn 1693

.



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.405 / Virus Database: 268.11.5/426 - Release Date: 8/23/2006


2006\08\24@015251 by Bob Axtell

face picon face
John Chung wrote:
> Hitech free edition supports 16F877A
>
> John
>  
Yes, Hitech is beginning to look pretty good.

--Bob

2006\08\24@025738 by Olof Larsson

flavicon
face
Started out with the IAR compiler... an Ansi compiler that worked quite
well until I ran out of space in the16f819 I used at the time.. switched
to the Knudsen cc5x compiler (non-free version) which is known to
generate very small code sizes. With cc5x I went from 97% filled flash
to 52%... the price for that is that it is not full Ansi - but efficient
and small code size combined with the built-in support for asymmetric
coroutines more than makes up for that. For me, that is. If you have a
fast pic, loads of flash and limited need for concurrency, then cc5x is
probably not your best pick.

/O

Bob Axtell skrev:
> Suddenly, I have to use C.
>
> Which one do you experts like best? Cost is not the
> overall consideration, ease of use is.
>
> --Bob
>
>  

2006\08\24@033141 by Mark Rages

face picon face
On 8/24/06, Bob Axtell <RemoveMEengineerspam_OUTspamKILLspamneomailbox.com> wrote:
> Mike Hagen wrote:
> > I have BoostC ver 6.4.  It integrates into MPLAB and Debugger.
> >
> > It does not do floating point but they say you can use Microchips
> > Library?
> >
> >
> Some years ago, I tried to follow Microchip's MASM FP routines, and they
> seemed to not be right...
> That's why I need C. I don't want to have to re-invent the wheel.
>
> --Bob

Did you try applying the bugfix from
http://www.piclist.com/techref/microchip/math/round/fp-24bint-ng.htm ?

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\08\24@064106 by Mat

flavicon
face
Just out of interest is there any reason not to use C18, ive been using it
for a few years now, and im more than happy with the price :) and what it
can do.

Mat

{Original Message removed}

2006\08\24@070816 by olin piclist

face picon face
Bob Axtell wrote:
> Suddenly, I have to use C.

You have my condolences.

> Which one do you experts like best? Cost is not the
> overall consideration, ease of use is.

You didn't say what PIC family, which makes a big difference.

For the PIC 18, the Mirochip C18 compiler is the only choice if you are
already familiar with MPASM and might need to integrate a assembler routine
or two into the project.  The other popular C compiler for the PIC 18 is not
MPLAB compatible, making it a complete non-starter.  MPLAB C18 is also the
only PIC 18 compiler supported by my PIC development environment ;-)

For the dsPIC, use the Microchip C30 compiler.  At full optimization it
actually produces reasonable code, and the calling conventions are sensible
(unlike MPLAB C18).  Integrating ASM30 and C30 in the same project and
debugging both with MPLAB works well.

For the PIC 16 there is no good compiler from any source.  You might
seriously consider walking away from the job if the customer absolutely
insists you use a C compiler for a PIC 16.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\24@073458 by olin piclist

face picon face
Bob Axtell wrote:
> I prefer MASM, too, but this job needs floating point, so I need a C
> compiler with a
> decent math unit. Its too difficult to fiddle with floating point MASM.

Huh?  I assume you really mean MPASM?  I've used floating point a few times
with MPASM and it's no big deal if the interface to the floating point
routines is done right.  My floating point routines are integrated with my
"general register" model I use anyway.  REG0-REG3 are defined as a single 32
bit register REGA, REG4-REG7 as REGB, etc.  The wide registers are used by
various wide math routines, including my floating point routines.
Performing wide math on the wide registers is just calling the appropriate
routines.  For example the source lines

    movlw  16
    movwf  reg8        ;pass number of fraction bits
    gcall  fp24flt     ;16.16 fixed point to floating point
    gcall  fp24mul     ;multiply by REGB

Convert the 16.16 fixed point number in REGA to 24 bit floating point in the
low 3 bytes of REGA, then multiply that by the 24 bit floating point value
in REGB and write the result back to REGA.

Another advantage of doing it this way is that you aren't stuck with IEEE 32
bit floating point.  Compiler writers are often hung up on standards
complience at the expense of doing what it more useful in a small embedded
system.  If you're measuring values with a 10 bit A/D and will ultimately
produce a 8 bit PWM output, 16 bits of mantissa is plenty for intermediate
calculations.  Very very few real world control systems need more than 16
bit accuracy for any calculations, nor all the fancy exception handling
built into the IEEE standard that compilers waste a lot of cycles and space
on.  You're not going to output 10**35 volts.  Something else is already
wrong and the result of the calculation most likely irrelevant if such a
value ever comes out.

I don't give out the floating point routines with the PIC development
environment that is available from the web site.  In your case I'd be happy
to let you use them for free, although you probably have to buy into using
the whole development environment for the FP routines to be useful.  Contact
me privately if you want them.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\24@075142 by Tamas Rudnai

face picon face
I think few people here would like to do other things than claculating PWM
stuff. I am not sure but for example for a public key cryptography they
probably need higher accuracy. But for those probably is better to use
co-processor? Is there any good math processor for this purpose?

Tamas


On 24/08/06, Olin Lathrop <RemoveMEolin_piclistTakeThisOuTspamspamembedinc.com> wrote:
{Quote hidden}

> -

2006\08\24@075847 by Bob Axtell

face picon face
Olin Lathrop wrote:
{Quote hidden}

No, I can use PIC18F.

Thanks for the info.

--Bob
> ******************************************************************
> Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> consultant in 2004 program year.  http://www.embedinc.com/products
>  

2006\08\24@075930 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: EraseMEpiclist-bouncesspamspamspamBeGonemit.edu [RemoveMEpiclist-bouncesKILLspamspammit.edu]
>Sent: 24 August 2006 12:10
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] Your Favorite PIC C Compiler.
>

>The other popular C compiler for the PIC 18 is not MPLAB
>compatible, making it a complete non-starter.

Hitech?  In what way is it not compatible with MPLAB?  I've used the simulator, debugger and programming facilities of MPLAB with HiTech C projects.  I don't use the editor or project manager because they both suck IMO, and Ultraedit and a makefile are vastly superior in almost every concievable way, but they are not incompatible.  The only 'incompatibility' (if you can describe it as such) that HiTech has is that it has it's own assembler and linker rather than using the Microchip tools.

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.
=======================================================================

2006\08\24@080258 by Hamilton Horta - PY2NI

flavicon
face
   I fully agree with Olof, I am a quite happy user of CC5X and also CC8E
(18FXXX version) not
to mention you can always talk to the owner/developer whenever you have any
trouble (very rare), I
don´t need any other C compiler up till now.
Visit http://www.bknd.com
P.S Only a satisfied user.

Horta

{Original Message removed}

2006\08\24@081822 by Tom Sefranek

face picon face
Olin Lathrop wrote:

>For the PIC 18, the Mirochip C18 compiler is the only choice if you are
>already familiar with MPASM and might need to integrate a assembler routine
>or two into the project.  The other popular C compiler for the PIC 18 is not
>MPLAB compatible, making it a complete non-starter.  MPLAB C18 is also the
>only PIC 18 compiler supported by my PIC development environment ;-)
>
I have to add my voice,  I bought HI Tech, then they "upgraded it" and I
had to buy the upgrade,
so far I have $1,500 into a compiler that is as Olin says, "a complete
non-starter.".  I could not
get started in it.  And it certainly does NOT have the peripheral
support libraries for the PICs.
Yea, for trancendentals it probably is nice...I'm a bit banger, and bell
ringer.
I cold care less about square roots, mantissas, floating point, etc.

I use the C18 and C30, and I can actually get things done, I wish I had
not wasted my money listening
to the opinions of the piclist.  But it could just be my lack of experience.

>For the dsPIC, use the Microchip C30 compiler.  At full optimization it
>actually produces reasonable code, and the calling conventions are sensible
>(unlike MPLAB C18).  Integrating ASM30 and C30 in the same project and
>debugging both with MPLAB works well.
>
I also agree, I have had excellent success with embeded ASM in the C code.

>******************************************************************
>Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
>consultant in 2004 program year.  http://www.embedinc.com/products
>  
>
Tom

--
 *
 |  __O    Thomas C. Sefranek   WA1RHPSTOPspamspamspam_OUTARRL.net
 |_-\<,_   Amateur Radio Operator: WA1RHP  
 (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz

hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org


2006\08\24@082502 by Per Linne

flavicon
face
I use CCS PCWH. For me it is very good.
It has a lot of built in functions for RS-232, I2C,
SPI and many more, ready to use. When you want
there is of course no problem to write your own.
Lots of example programs are included for example
interrupt serviced RS-232.
32 bit floating point. 1, 8, 16, 32 bit integers.
Built in trigonometry functions.
I've been using it for years. I buy annual maintenance.
It integrates perfectly with Mplab.
No problems at all to use it with ICE2000, ICD2 etc.
One can singlestep in the C source.
Price is very good for a professional tool kit.
http://www.ccsinfo.com

PerL

----- Original Message -----
From: "Bob Axtell" <spamBeGoneengineerSTOPspamspamEraseMEneomailbox.com>
To: "Microcontroller discussion list - Public." <KILLspampiclistspamBeGonespammit.edu>
Sent: Wednesday, August 23, 2006 11:52 PM
Subject: [PIC] Your Favorite PIC C Compiler.


> Suddenly, I have to use C.
>
> Which one do you experts like best? Cost is not the
> overall consideration, ease of use is.
>
> --Bob
>
> --

2006\08\24@082626 by olin piclist

face picon face
Tamas Rudnai wrote:
> I think few people here would like to do other things than claculating
> PWM stuff.

Some probably would, but I think you're right in that PWM is probably the
dominant output for control systems.  Either the thing being driven is
modulated by PWM directly like a motor or a solenoid, or the PWM is filtered
into a analog signal that is used for old fashioned control.

> I am not sure but for example for a public key cryptography
> they probably need higher accuracy.

Higher than what?  I think you are responding to comments on floating point,
but encryption is done with integers anyway.

In any case, you can certainly come up with reasons for needing more than 16
bit accuracy in special cases.  However, I think those special case are
unusual or even rare in the kind of real world control applications PICs
find themselves in.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\24@084525 by Michael Rigby-Jones

picon face


{Quote hidden}

You are entitled to one free upgrade, and you don't have to buy any more unless you need a specific feature of the newer version.  Commercial compilers cost money to develop and support, if you wanted a hobby level compiler then yes, you undoubtedly bought the wrong product.


>so far I have $1,500 into a compiler that is as Olin says, "a complete
>non-starter.".  I could not
>get started in it.  And it certainly does NOT have the peripheral
>support libraries for the PICs.

Does assembler have these support libraries? No, you develop your own to do exactly what you want and you understand their operation perfectly.  Hitech has the essentials such a EEPROM and FLASH read/write support, but I MUCH prefer to develop my own libraries for complex peripherals.  If done properly you only need to do it once.

The hobby level compilers have large peripheral support libraies as they are aimed at beginners/non-experts who possibly don't fully understand the operation of the device but can knock together a basic working program using these libraries.  Such users rarely care about performance or code size, as long as it fits in the chosen device.  Again the HiTech compiler is most certainly not aimed at this kind of user.

>Yea, for trancendentals it probably is nice...I'm a bit
>banger, and bell
>ringer.
>I cold care less about square roots, mantissas, floating point, etc.
>

Sounds like assembly language would be ideal for you?

>I use the C18 and C30, and I can actually get things done, I
>wish I had
>not wasted my money listening
>to the opinions of the piclist.  But it could just be my lack
>of experience.

Without wishing to be rude, it sounds like that may be the case in all honesty.

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.
=======================================================================

2006\08\24@084705 by rlistas

picon face
Hi Marcel

Does they have a forum ou discussion group ?
I didn´t found any in the page.

Rubens

At 02:46 24/8/2006, you wrote:
{Quote hidden}

>

2006\08\24@084822 by Mike Harrison

flavicon
face
On Thu, 24 Aug 2006 08:18:20 -0400, you wrote:

>Olin Lathrop wrote:
>
>>For the PIC 18, the Mirochip C18 compiler is the only choice if you are
>>already familiar with MPASM and might need to integrate a assembler routine
>>or two into the project.  The other popular C compiler for the PIC 18 is not
>>MPLAB compatible, making it a complete non-starter.  MPLAB C18 is also the
>>only PIC 18 compiler supported by my PIC development environment ;-)

Are you really talking about Hi-tech here...?  If so you are just plain wrong.
It integrates and works fine with MPLAB, ICE2000 etc. once you've installed Hi-Tech's MPLAB
interface stuff.
You can easily integrate assembler, both as inline or seperate modules. Some of the  assembler
syntax may be slightly different but this is no big deal.


2006\08\24@092555 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> In any case, you can certainly come up with reasons for needing more than 16
> bit accuracy in special cases.  However, I think those special case are
> unusual or even rare in the kind of real world control applications PICs
> find themselves in.

FWIW, there are cases where using 24 or 32 bit integer math (actually fixed
point, but that's the same) can help avoiding floating point math.

Gerhard

2006\08\24@104440 by dr. Imre Bartfai

flavicon
face
Hi,

for that case, I suggest BKND (http://www.bknd.com). It is something for purists,
and the floating point is one of its strongest side. I use it
occasionally, too.

Regards,
Imre

On Wed, 23 Aug 2006, Bob Axtell wrote:

{Quote hidden}

2006\08\24@121736 by olin piclist

face picon face
Mike Harrison wrote:
> Are you really talking about Hi-tech here...?

Yes.

> If so you are just plain wrong.

I looked into this a few months ago.  At that time at least the HiTech PIC
18 compiler was in its own separate world.  There was no way to mix C and
MPASM.  You had to use either inline assembly or their own proprietary
assembler.

> It integrates and works fine with MPLAB, ICE2000 etc. once you've
> installed Hi-Tech's MPLAB interface stuff.
> You can easily integrate assembler, both as inline or seperate modules.
> Some of the  assembler syntax may be slightly different but this is no
> big deal.

Actually it is a big deal, making this compiler useless to me.  "Slightly
different" is still incompatible.  I ended up using the Microchip C18
compiler, which works fine in a mixed project with MPASM.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\24@122517 by Michael Rigby-Jones

picon face


{Quote hidden}

Sorry Olin, but that's just over dramatising.  It might be slightly less convienient in you wish to reuse some existing assembly code, but it's hardly useless.

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.
=======================================================================

2006\08\24@125057 by olin piclist

face picon face
Michael Rigby-Jones wrote:
> Sorry Olin, but that's just over dramatising.  It might be slightly
> less convienient in you wish to reuse some existing assembly code, but
> it's hardly useless.

I don't consider having to worry about what subtle misconceptions it might
have about thousands of lines of existing code a slight inconvenience.
Besides, there is no compelling advantage compared to MPLAB C18 with does
explicitly allow for mixing C and MPASM in a project.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\24@131937 by Bob Blick

face picon face

> I don't consider having to worry about what subtle misconceptions it might
> have about thousands of lines of existing code a slight inconvenience.
> Besides, there is no compelling advantage compared to MPLAB C18 with does
> explicitly allow for mixing C and MPASM in a project.

Olin,

Since you are a relative newcomer to the PIC, you may not remember how
MPASM was 10 years ago. When HiTech C was released for the 12 and 14 bit
parts, it was the real thing. A good assembler, linker and compiler. It is
still the C compiler of choice for the 12 and 14 bit parts(and the 17C
series I suppose) and was the one recommended by Microchip(perhaps still
is). It is a great compiler for the 14 bit parts and I use it every day.

The original poster said the 16F877A was the targeted part. I don't see
how any of your arguments relate to the topic at hand. MPLAB C18 will not
work on that part.

Cheerful regards,

Bob


2006\08\24@133812 by Marcel van Lieshout

flavicon
face
There is a Yahoo group: http://groups.yahoo.com/group/FEDPIC

Marcel

rlistas wrote:
{Quote hidden}

>> -

2006\08\24@222310 by John Chung

picon face
I have seen FP routine go wrong in assembly and C.
More so in assembly due to the lack of testing. The
problem is that assembly FP need much more
testing....... If you need the accuracy please double
check on the specs that you need.

John

--- Bob Axtell <TakeThisOuTengineer.....spamTakeThisOuTneomailbox.com> wrote:

{Quote hidden}

www.sourceboost.com/Products/BoostC/ExampleCode.html
{Quote hidden}

> --

2006\08\24@223620 by John Chung

picon face
Mike,

  Did you managed to get UltraEdit to autocomplete
*intelligently*? I have been trying for so long now :(

John

--- Michael Rigby-Jones
<.....Michael.Rigby-JonesspamRemoveMEbookham.com> wrote:

>
>
> >{Original Message removed}

2006\08\24@224137 by John Chung

picon face
Public encryption requires plenty of code. I am
talking about blowfish,PGP and etc. So the normal PIC
16 don cut it. You will have to use dsPIC or PIC24
that is 16-bit. But the problem is that the byte
manipulation is quite intense. Therefore the hex
output would be big.

John

--- Tamas Rudnai <RemoveMEtamas.rudnaispamspamBeGonegmail.com> wrote:

{Quote hidden}

******************************************************************
> > Embed Inc, Littleton Massachusetts, (978)
> 742-9014.  #1 PIC
> > consultant in 2004 program year.
> http://www.embedinc.com/products
> > --

2006\08\24@224523 by John Chung

picon face
Olin,

    Is the FP routines written by you? You are not
using the Microchip FP routines?

John

--- Olin Lathrop <TakeThisOuTolin_piclistspamspamembedinc.com> wrote:

{Quote hidden}

******************************************************************
> Embed Inc, Littleton Massachusetts, (978) 742-9014.
> #1 PIC
> consultant in 2004 program year.
> http://www.embedinc.com/products
> --

2006\08\25@074653 by olin piclist

face picon face
John Chung wrote:
> Is the FP routines written by you?

Yes.

> You are not using the Microchip FP routines?

Right.

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\25@080746 by Tamas Rudnai

face picon face
> Public encryption requires plenty of code. I am
> talking about blowfish,PGP and etc. So the normal PIC
> 16 don cut it. You will have to use dsPIC or PIC24
> that is 16-bit. But the problem is that the byte
> manipulation is quite intense. Therefore the hex
> output would be big.

I think sometimes you can make some hardware assistance for those
manipulations - like the DES bit scrambling is just wiring the bits from
here to there.

But returning to the original context Olin has right that most of the times
don't need large precision floating point, I would say a fixed point
arithmetic is just enough for most tasks.

Tamas


On 25/08/06, John Chung <kravnusEraseMEspamyahoo.com> wrote:
{Quote hidden}

>

2006\08\25@121344 by Gerry Duprey

flavicon
face
Howdy,

> For the PIC 16 there is no good compiler from any source.  You might
> seriously consider walking away from the job if the customer absolutely
> insists you use a C compiler for a PIC 16.

I guess I would disagree.  I've been using the HiTech C compiler for the 16
series for about a year.  Before that, I coded many projects in ASM and while
there are a few occasions I drop back to ASM, the output from the HiTech
compiler is pretty impressive (I regularly review their assembly listings the
first time I use a new construct).  I rarely can come up with better ASM code
than their generator creates (for common idioms/expressions).

About the only time I drop by to ASM now is for timing critical stuff (where I
have to count instruction cycles to get things right).

It integrates with MPLAB if you'd like just fine -- compiler, debugger,
linker, etc.  It's also available for other platforms (I primarily use linux,
so that's a great plus).

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\08\27@001651 by Herbert Graf

flavicon
face
On Fri, 2006-08-25 at 12:15 -0400, Gerry Duprey wrote:
> Howdy,
>
> > For the PIC 16 there is no good compiler from any source.  You might
> > seriously consider walking away from the job if the customer absolutely
> > insists you use a C compiler for a PIC 16.
>
> I guess I would disagree.  I've been using the HiTech C compiler for the 16
> series for about a year.  Before that, I coded many projects in ASM and while

I tried out the HiTech C compiler a couple years ago.

It seemed to work quite well.

I then found two bugs in the compiler. One case was the compiler didn't
generate the correct bank settings for a particular SFR (I confirmed the
problem by looking at the ASM it spit out, the bank setting was
missing). The second bug related to an integer divide not working (never
traced down the problem, simply replaced it with a "loop" divide that
worked without issue).

I'm sure both those bugs were fixed LONG ago, but based on the amount of
time I wasted tracing down those compiler bugs I decided to NEVER AGAIN
use a HiTech C product.

Since then I've stuck with the 18F and 30F parts, using C18 and C30. I
haven't encountered ONE compiler bug (I know there were issues with the
peripheral libraries, but since I've never used them that has never
affected me).

Where I work tool issues are a very large part of the time I waste in
the course of the day, having those same issues with my private PIC
stuff was unacceptable.

I don't often agree with Olin, but on this issue I believe he and I
share the same opinion.

TTYL

2006\08\27@012753 by John Temples

flavicon
face
On Sun, 27 Aug 2006, Herbert Graf wrote:

> Since then I've stuck with the 18F and 30F parts, using C18 and C30. I
> haven't encountered ONE compiler bug (I know there were issues with the
> peripheral libraries, but since I've never used them that has never
> affected me).

C18 certainly isn't bug free; check the release notes.  And if you
look on the forum, you'll find bugs that seemingly haven't been
acknowledged by Microchip, e,g:

http://forum.microchip.com/tm.aspx?m=148949

--
John W. Temples, III

2006\08\27@110538 by Gerry Duprey

flavicon
face
Howdy,

>>>For the PIC 16 there is no good compiler from any source.  You might
>>
>>I guess I would disagree.  I've been using the HiTech C compiler for the 16
>>series for about a year.  Before that, I coded many projects in ASM and while
>
> I then found two bugs in the compiler. One case was the compiler didn't

Yeah -- I ran into a bank switching bug too.  I guess to be fair, trying to
merge banking stuff on the PIC (which is pretty oddly worked between the
difference in RAM access and FSR access) with C is tough, but then again,
that's why you pay.  HiTech took care of it as soon as I identified it
(granted, as you say, identifying it was the tough part).

But that was one bug in nearly 3 years of use and dozens of projects.  I can
create the guts of a new project in nearly no time using it (which is more
about using a slightly higher level lang than ASM) and use the saved time for
when I need to fine tune an ASM routine (about 1 in 4 projects require that
sort of timing).

My time is worth a lot (for myself and billing wise) and while this is
expensive, in terms of compact and quality code, none of the other C compilers
(for the 16 series) matched it.

> I'm sure both those bugs were fixed LONG ago, but based on the amount of
> time I wasted tracing down those compiler bugs I decided to NEVER AGAIN
> use a HiTech C product.

It was a pain to be sure, but I have to imagine there is other software you
use that has had bugs and you continue to use it?  One (understandably
frustrating) bug seems like a pretty low bar to expel a piece of software.
For myself, with that sort of bar, I'd probably not be able to turn on my
computer :-)

> Since then I've stuck with the 18F and 30F parts, using C18 and C30. I
> haven't encountered ONE compiler bug (I know there were issues with the
> peripheral libraries, but since I've never used them that has never
> affected me).

I've started using the 18F stuff for some larger projects and appreciate the
extra space and speed.  Often though, for smaller/simpler projects, the 16F
still is a cheap solution.

> I don't often agree with Olin, but on this issue I believe he and I
> share the same opinion.

Well, his statement was that there no good compiler from any source and unless
you define "good" as "100% bug free" (which would eliminate virtually every
compiler out there for any platform/technology), that is the point I disagree
with.

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org

2006\08\27@111039 by Xiaofan Chen

face picon face
On 8/27/06, Herbert Graf <EraseMEmailinglist3spam@spam@farcite.net> wrote:

> Since then I've stuck with the 18F and 30F parts, using C18 and C30. I
> haven't encountered ONE compiler bug (I know there were issues with the
> peripheral libraries, but since I've never used them that has never
> affected me).

That is what I hear from others as well. In general C18 and C30 are both
quite good. The peripheral libraries have quite some issues.

It is said that HiTech PICC18 produces better code than MPLAB C18 in
general for PIC18F. But it is said that MPLAB C30 produces better code
than dsPICC for PIC24/dsPICs.

For PIC16F, HiTech PICC is undoubtedly the best C compiler available.

Regards,
Xiaofan

2006\08\27@173610 by Herbert Graf

flavicon
face
On Sat, 2006-08-26 at 22:27 -0700, John Temples wrote:
> On Sun, 27 Aug 2006, Herbert Graf wrote:
>
> > Since then I've stuck with the 18F and 30F parts, using C18 and C30. I
> > haven't encountered ONE compiler bug (I know there were issues with the
> > peripheral libraries, but since I've never used them that has never
> > affected me).
>
> C18 certainly isn't bug free; check the release notes.  And if you
> look on the forum, you'll find bugs that seemingly haven't been
> acknowledged by Microchip, e,g:

Please understand, I never meant to imply that C18 and C30 have no bugs,
to say that would be obviously foolish, since NO tool is 100% free of
bugs.

I simply stated that I haven't encountered a single bug with either
compiler. Whether that's luck or something else is for you to decide.
All I know is, so far, neither has let me down.

TTYL

2006\08\27@174610 by Herbert Graf

flavicon
face
On Sun, 2006-08-27 at 11:05 -0400, Gerry Duprey wrote:
> Howdy,
>
> >>>For the PIC 16 there is no good compiler from any source.  You might
> >>
> >>I guess I would disagree.  I've been using the HiTech C compiler for the 16
> >>series for about a year.  Before that, I coded many projects in ASM and while
>  >
> > I then found two bugs in the compiler. One case was the compiler didn't
>
> Yeah -- I ran into a bank switching bug too.  I guess to be fair, trying to
> merge banking stuff on the PIC (which is pretty oddly worked between the
> difference in RAM access and FSR access) with C is tough, but then again,
> that's why you pay.  HiTech took care of it as soon as I identified it
> (granted, as you say, identifying it was the tough part).

Interesting. When I found it I looked up the forums for a solution. The
bug didn't seem to be mentioned anywhere. So I simply worked around it
(set the bank manually) and completed the project.

> > I'm sure both those bugs were fixed LONG ago, but based on the amount of
> > time I wasted tracing down those compiler bugs I decided to NEVER AGAIN
> > use a HiTech C product.
>
> It was a pain to be sure, but I have to imagine there is other software you
> use that has had bugs and you continue to use it?  One (understandably
> frustrating) bug seems like a pretty low bar to expel a piece of software.

Very true, and had it been only one bug, I would have been OK with the
tool. The problem was it was TWO bugs, both VERY SIMPLE things. It's not
like I was doing anything complicated. The first was the FSR banking
bug, a BEAR to figure out.

The second bug was a result of an integer divide, something like:
       i = 25/x;

The result was clearly wrong, but only THAT LINE of my code was wrong,
all other divides seemed to work fine. This was a similar train of
events as I found with the banking bug, all other SFRs had their banking
bits set properly, but ONE line didn't work right. I replaced the divide
with a for loop and my routine worked fine after that. (the ICD2 was
EXTREMELY helpful in figuring this one out, for the first bug I didn't
have the ICD2 making it that much harder to figure out what was going
wrong).

One bug I can stand. Two bugs, in the span of less then a month, was my
tipping point. Some might consider that harsh, but so be it. In
actuality that was also the last hobby project I did with a 16F part.

> For myself, with that sort of bar, I'd probably not be able to turn on my
> computer :-)

The bar is variable. It's not the NUMBER of bugs that will tip the scale
with me, it's the amount of time I waste BECAUSE of a bug that counts.
In the case of windows it took way more then 2 bugs to cause me to
switch, but that point eventually came, and now I'm basically
exclusively Linux. Linux surely has bugs as well, but I've found that
solving them is actually possible, and very easy to figure out (google
is your best friend for Linux problems IMHO).

> > Since then I've stuck with the 18F and 30F parts, using C18 and C30. I
> > haven't encountered ONE compiler bug (I know there were issues with the
> > peripheral libraries, but since I've never used them that has never
> > affected me).
>
> I've started using the 18F stuff for some larger projects and appreciate the
> extra space and speed.  Often though, for smaller/simpler projects, the 16F
> still is a cheap solution.

Since all of my PIC work is either hobbyist, or on the professional side
prototype volumes, cost/PIC isn't an issue for me. I can see however
that if you're selling many products why a 16F/12F/10F may be appealing.

> > I don't often agree with Olin, but on this issue I believe he and I
> > share the same opinion.
>
> Well, his statement was that there no good compiler from any source and unless
> you define "good" as "100% bug free" (which would eliminate virtually every
> compiler out there for any platform/technology), that is the point I disagree
> with.

"Good" is very subjective, it isn't possible to define it since it's
different for everything. To me, the HiTech compiler for the 16F is not
"good", but that's just my opinion.

TTYL

2006\08\29@035226 by Michael Rigby-Jones

picon face


{Quote hidden}

I don't think I would have a single compiler availble to me if I took that view.  C18 was riddled with bug a few years back, the AVR port of GCC that I've been using has numerous bugs and examples of appalling lack of optimisation (though it's not the very latest version).

Personaly I think their is only one sensible way in which to judge a compiler, at least from a commercial point of view: support.  It doesn't matter is you only wasted an hour finding a compiler bug if the vendor won't fix it.  I have reported a couple of bugs in HiTechs compilers and either it was a known issue and a patch was already available or one was made available very quickly.

Best 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.
=======================================================================

2006\08\29@090917 by Herbert Graf

flavicon
face
On Tue, 2006-08-29 at 08:52 +0100, Michael Rigby-Jones wrote:
> >The bar is variable. It's not the NUMBER of bugs that will tip
> >the scale with me, it's the amount of time I waste BECAUSE of
> >a bug that counts. In the case of windows it took way more
> >then 2 bugs to cause me to switch, but that point eventually
> >came, and now I'm basically exclusively Linux. Linux surely
> >has bugs as well, but I've found that solving them is actually
> >possible, and very easy to figure out (google is your best
> >friend for Linux problems IMHO).
>
> I don't think I would have a single compiler availble to me if I took that view.  C18 was riddled with bug a few years back,

Well, with that view both C18 and C30 have been good to me.

> the AVR port of GCC that I've been using has numerous bugs and
> examples of appalling lack of optimisation (though it's not the
> very latest version).

I tried getting into AVRs once. I had a bear of a time getting the
software to work at all. Kept getting very weird errors. In the end it
turned out another tool I was using used the same environment variable
as the AVR port of GCC. I did get the tool working, but I had wasted
enough time that I lost interest in AVRs. I haven't gone back.

> Personaly I think their is only one sensible way in which to judge a compiler, at least from a commercial point of view: support.  It doesn't matter is you only wasted an hour finding a compiler bug if the vendor won't fix it.  I have reported a couple of bugs in HiTechs compilers and either it was a known issue and a patch was already available or one was made available very quickly.

Support is useless if you don't know the bug IS a compiler bug. The bank
switching bug took me a day to debug. Only right at the end did I
discover it was a compiler bug. What good was support to me at that
point? I had already wasted a day. By finding out WHAT the bug was, I
also found a solution (setting the bank manually), so support was
useless to me.

The second bug I discovered was found quicker by me since I already
doubted the compiler. And again, once I determined it WAS a compiler
bug, the solution was 5 minutes away (a for loop). Again, support was
completely useless to me in that case since all the wasted work was
spent determining it was a compiler bug.

In my professional work tool issues are a VERY big part of my wasted
time, as such my tolerance for sub par tool quality isn't very high. If
a tool keeps wasting my time I simply switch to another. After all, I'm
not being paid to be their beta testers, why should I spend my time
being one?

TTYL

2006\08\29@111206 by olin piclist

face picon face
Herbert Graf wrote:
> Only right at the end did I discover it was a compiler bug.

Why, do you usually keep looking once you discover it's a compiler bug?

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\29@115118 by Robert Young

picon face

>
> Herbert Graf wrote:
> > Only right at the end did I discover it was a compiler bug.
>
> Why, do you usually keep looking once you discover it's a
> compiler bug?
>
> ******************************************************************
> Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> consultant in 2004 program year.  http://www.embedinc.com/products

The problem will always be in the last place you look, so be sure to
look there first!

Rob

2006\08\29@142539 by Herbert Graf

flavicon
face
On Tue, 2006-08-29 at 11:09 -0400, Olin Lathrop wrote:
> Herbert Graf wrote:
> > Only right at the end did I discover it was a compiler bug.
>
> Why, do you usually keep looking once you discover it's a compiler bug?

I don't really understand the question? I think the answer is yes, since
usually once I discover a tool issue, the next step is either solving
the tool issue (by checking support), or working out a way that bypasses
the tool issue (which can take a while). In this case however, once I
found the tool issue, the "workaround" was obvious, so my work on the
bug was finished.

To clarify I knew I had a bug. The whole time I assumed the problem was
my code. After checking things in my code as far as I could I decided
the problem must be outside my code (I had condensed the code to such a
simple chunk that it was clear to me the problem wasn't the code). That
left me with three suspects, the compiler, the programmer and the PIC.
The programmer and PIC were less likely the source of the problem then
the compiler, so I decided to look into what the compiler was
generating.

I took out the manual, figured out how to get the compiler to generate
the asm listing and started investigating. On close inspection (and
keeping track of bank settings, which isn't easy since compiler
generated ASM often jumps around a lot) I discovered the bank bits were
wrong for one of the SFRs I was using. (BTW this is exactly the kind of
situation that makes me recommend everybody who uses a PIC has at least
a basic understanding of ASM before going to an HLL. I started with ASM
so looking at the ASM produced by the compiler was no big deal. A person
with no familiarity with ASM would have been faced with both learning
ASM, and THEN figuring out what was wrong). I added a manual setting of
the bank bits to the C code, recompiled, confirmed the bank settings
were in the ASM file, programmed the PIC, and the problem was gone.

As I said before, I have no doubt that the HiTech C product these days
is WAY better then the version I used. Unfortunately I'll probably never
find out.

TTYL

2006\08\29@144934 by Wouter van Ooijen

face picon face
>>> Only right at the end did I discover it was a compiler bug.

>> Why, do you usually keep looking once you discover it's a
>> compiler bug?

> I don't really understand the question? I think the answer is
> yes, since usually once I discover a tool issue, the next step
> is either solving the tool issue ...

Didn't you notice the implied smile? IMO discovering (anything) is
always the end of the search (at least the end of the search for that).

Wouter van Ooijen

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


2006\08\29@150020 by olin piclist

face picon face
Herbert Graf wrote:
>>> Only right at the end did I discover it was a compiler bug.
>>
>> Why, do you usually keep looking once you discover it's a compiler bug?
>
> I don't really understand the question?

It was a joke.  I thought it was funny when you said that you discovered it
was a compiler but "right at the end".  As apposed to what?  Finding the bug
then continuing to search elsewhere anyway?  Of course when you are
searching for something you always find it in the last place you look
(presuming a certain minimum intelligence, I suppose).


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\29@153954 by Herbert Graf

flavicon
face
On Tue, 2006-08-29 at 20:51 +0200, Wouter van Ooijen wrote:
> >>> Only right at the end did I discover it was a compiler bug.
>  
> >> Why, do you usually keep looking once you discover it's a
> >> compiler bug?
>
> > I don't really understand the question? I think the answer is
> > yes, since usually once I discover a tool issue, the next step
> > is either solving the tool issue ...
>
> Didn't you notice the implied smile?

I guess not, I'm not sure why not, just didn't occur to me.

> IMO discovering (anything) is
> always the end of the search (at least the end of the search for that).

Absolutely not IMHO, at least in the realm of bug fixing. Finding the
source of a bug can often be only half the effort. Actually, more often
then not FIXING the bug is more work then finding it.

TTYL

2006\08\29@155435 by Mike Singer

picon face
Not PIC compilers, but anyway good docs.


VB.NET and C# Comparison
This is a quick reference guide to highlight some key syntactical
differences between VB.NET (version 2) and C#.

http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html


------------------------------------

Java (J2SE 5.0) and C# Comparison
This is a quick reference guide to highlight some key syntactical
differences between Java and C#.

http://www.harding.edu/USER/fmccown/WWW/java1_5_csharp_comparison.html


---
MS

2006\08\29@161845 by Wouter van Ooijen

face picon face
>>>>> Only right at the end did I discover it was a compiler bug.

> Absolutely not IMHO, at least in the realm of bug fixing. Finding the
> source of a bug can often be only half the effort. Actually,
> more often then not FIXING the bug is more work then finding it.

But even then finding is still at the end of the search, and "end" in
"at the end did I discover" reads to me as the end of searching, not as
"the end of the search-and-solve processes". But maybe that's my
non-native English (hinein-) interpretation.

But, IME (In My Experience) finding is often the largest part, much more
difficult than solving.

A side note about finding "the" problem. Way back when I was employed by
software/hardware companies I was often called to ckack the realy
difficult problems. One technique of locating the source of a problem is
a kind of binary search: disable part of the program (or hardware), if
the problem disappears you focus on that part and disable a smaller part
of it, if it persists you re-enable that part and look elsewhere. I
found that this technique failed me more often than I expected, because
the problem at hand (as it manifested itself) had two (I don't recall
more than two) independent sources. So whatever part you disable, the
problem would still persists (unless you happened to disable both
sources - not likely. I don't think this is typical for everyday
problems, but it happened to me more often than I expected.

Wouter van Ooijen

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


2006\08\29@170033 by Herbert Graf

flavicon
face
On Tue, 2006-08-29 at 22:20 +0200, Wouter van Ooijen wrote:
> A side note about finding "the" problem. Way back when I was employed by
> software/hardware companies I was often called to ckack the realy
> difficult problems. One technique of locating the source of a problem is
> a kind of binary search: disable part of the program (or hardware), if
> the problem disappears you focus on that part and disable a smaller part
> of it, if it persists you re-enable that part and look elsewhere. I
> found that this technique failed me more often than I expected, because
> the problem at hand (as it manifested itself) had two (I don't recall
> more than two) independent sources. So whatever part you disable, the
> problem would still persists (unless you happened to disable both
> sources - not likely. I don't think this is typical for everyday
> problems, but it happened to me more often than I expected.

Hehe, yes, those types of problems are REALLY frustrating! It's funny
how like minds think alike. One time I was using that technique, and the
problem went away when either half was removed, but was there when both
haves were present! Now that was a tricky one to nail down...

TTYL

2006\08\29@174203 by Mike Singer

picon face
Wouter van Ooijen wrote:
>  One technique of locating the source of a problem is
> a kind of binary search: disable part of the program (or hardware), if
> the problem disappears you focus on that part and disable a smaller part
> of it, if it persists you re-enable that part and look elsewhere. I
> found that this technique failed me more often than I expected,

On a related note from:

http://msdn.microsoft.com/library/default.asp?url=/archive/en-us/dnaruml/html/msdn_visualmod.asp

… If you want to build a doghouse, you can pretty much start with a
pile of lumber, some nails, and a few basic tools such as a hammer, a
saw, and a tape measure. In a few hours, with little prior planning,
you'll likely end up with a doghouse that's reasonably functional, and
you can probably do it with no one else's help. As long as it's big
enough and doesn't leak too much, your dog will be happy. If it
doesn't work out, you can always start over, or get a less demanding
dog.

If you want to build a house for your family, you can start with a
pile of lumber, some nails, and a few basic tools, but it's going to
take you a lot longer, and your family will certainly be a lot more
demanding than the dog. In this case, unless you've already done it a
few dozen times before, you'll be better served by doing some detailed
planning before you pound the first nail or lay the foundation. At the
very least, you'll want to sketch out several ideas of what you want
the house to look like. If you want to build a quality house that
meets the needs of your family and of local building codes, then
you'll need to draw some blueprints as well, so that you can think
through the intended use of the rooms and the practical details of
lighting, heating, and plumbing. Given these plans, then you can start
to make reasonable estimates of the amount of time and materials this
job will require. Although it is humanly possible to build a house
alone, you'll find it to be much more efficient to work with others,
possibly subcontracting out many key parts or buying prebuilt
materials. As long as you stay true to your plans and stay within the
limitations of time and money, then your family will likely be
satisfied. If it doesn't work out, you can't exactly get a new family,
and so it's best to set expectations early and manage change
carefully.

If you want to build a high-rise office building, it would be
infinitely stupid for you to start with a pile of lumber, some nails,
and a few basic tools. Since you are probably using other people's
money, they will demand to have input into the size, shape, and style
of the building. Often, they will change their minds, even after
you've started building. You will want do to an extensive amount of
planning, because the cost of failure is high. You will be just a part
of a much larger group responsible for developing and deploying the
building, and so the team will need all sorts of blueprints and models
to communicate with one another. As long as you get the right people
and the right tools and actively manage the process of transforming an
architectural concept into reality, you will likely end up with a
building that will satisfy its tenants. If you want to keep building
buildings, then you will want to be certain to balance the desires of
your tenants with the realities of building technology, and you will
want to treat the rest of your team professionally, never placing them
at any risk or driving them so hard that they burn out.

It's a curious thing, but a lot of software development organizations
start out wanting to build high rises, but approach the problem as if
they were knocking out a dog house.

Sometimes, you get lucky. If you have the right people at just the
right moment in time and if all the planets align properly, then you
might, just might, get your team to push out a software product that
dazzles its users. Typically, however, you can't get all the right
people (the right ones are often already over committed), it's never
the right moment (yesterday would have been better), and the planets
never seem to align (instead, they keep moving, entirely out of your
control). Given the increasing demand to develop software in Internet
time, development teams often fall back on the only thing they really
know how to do well—namely, pound out lines of code. Heroic
programming efforts are legend in this industry, and thus often it
seems that working harder is the proper reaction to any crisis in
development. Oft times, however, these are not necessarily the right
lines of code, and furthermore, some projects are of such a magnitude
that even adding more hours to the work day is just not enough to get
the job done.

2006\08\29@184410 by peter green

flavicon
face
> It's a curious thing, but a lot of software development organizations
> start out wanting to build high rises, but approach the problem as if
> they were knocking out a dog house.
partly i think it comes from the perception that code is cheap (no materials
only time and a good coder can write it pretty quickly) and easy to test
(near instant compile and run). Why spend time designing code when you could
spend that same time actually writing it.

And some certainly are guilty of overplanning, writing plans that are
basically an alternate representation of every peice of code is rather
wastefull. In this area i think there is a similar issue to with commenting,
the schools teach people they should plan thier programs and comment thier
code but the programs simply aren't big enough to require the use of
planning or comments.

Equally though as soon as more than one person is involved and sometimes
before that good planning of the boundry interfaces, discussion of exactly
what is needed from what part of the sytem and descisions about the timing
(who has the CPU when and associated management interfaces is a major issue
when desiging single threaded systems) are required.

ultimately it's getting the balance between time spent on design and
time/bugs saved by design right that is so difficult.

another issue seems to be lack of oversight. With any building (except
smallish temporary structures) you are going to have to get your plans past
planning and building control (for non-uk readers planning is concerned with
looks and other affects on the local area, building control is about making
sure the building is safe, energy efficiant, disabled accessible etc). On
the other hand for software (with few exceptions) the only person making
demands of software is the client. Until clients demand and pay for quality
software engineering clients won't get quality software.


2006\08\29@191420 by Russell McMahon

face
flavicon
face
> On a related note from:

http://msdn.microsoft.com/library/default.asp?url=/archive/en-us/dnaruml/html/msdn_visualmod.asp

{Quote hidden}

That's revolutionary.
Someone should tell Microsoft about this.



       RM

:-)


2006\08\29@200840 by olin piclist

face picon face
peter green wrote:
> the schools teach people they should plan thier programs
> and comment thier code but the programs simply aren't big enough to
> require the use of planning or comments.

Wrong, wrong, wrong!

Perhaps overt planning where a software structure document is created isn't
necessary for small programs, but comments certainly are.  Your kind of
attitude is why 99% of all software out there is crap and nearly useless for
modifying it.  Even a two line subroutine needs a comment explaining what it
does.  Code tells you actions in minute detail, comments tell you intent and
higher level purpose.  The two are very different and therefore both are
necessary components of any properly written software.

You are also implying that comments cost time.  This is totally wrong,
although a all too common fallacy.  Even the sloppiest and worst programmers
out there would probably admit that comments would have saved time after
several revisions are made to the code.  However they also save time right
away too.  Not chasing one bug probably pays for a few 100 lines of comments
on time alone.  Commenting every or most every line with paragraph comments
interspersed every 10-30 lines or so forces you to think about what you're
doing and doesn't allow for sloppy thoughts.  Comments are written in plain
text, which is easier and faster to type than most code which contains a
high proportion of special and unusual punctuation characters.  Unless
you're a complete imbecile with a keyboard, writing a end of line comment
kind of happens automatically.  You think the words and the fingers type the
characters by themselves.  The cost is really minimal, so the cost/benefit
in terms of reduced debugging time and higher quality result should be
self-evident to anyone who calls themselves a software engineer.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\29@205508 by Jinx

face picon face
> Not chasing one bug probably pays for a few 100 lines of
> comments on time alone. Commenting every or most every
> line with paragraph comments interspersed every 10-30
> lines or so forces you to think about what you're doing and
> doesn't allow for sloppy thoughts

Amen

2006\08\29@222552 by Herbert Graf

flavicon
face

On Wed, 2006-08-30 at 11:14 +1200, Russell McMahon wrote:
> > On a related note from:
>
> msdn.microsoft.com/library/default.asp?url=/archive/en-us/dnaruml/html/msdn_visualmod.asp
>
> > … If you want to build a doghouse, ...
>
> > ... If you want to build a house for your family ...
>
> > ... If you want to build a high-rise office building ...
>
> > It's a curious thing, but a lot of software development
> > organizations start out wanting to build high rises,
> > but approach the problem as if they
> > were knocking out a dog house. ...
>
> That's revolutionary.
> Someone should tell Microsoft about this.

Hehe, I was thinking the exact same thing... :)

TTYL

2006\08\30@024108 by Wouter van Ooijen

face picon face
>>It's a curious thing, but a lot of software development
>>organizations start out wanting to build high rises,
>>but approach the problem as if they
>>were knocking out a dog house. ...

> That's revolutionary.
> Someone should tell Microsoft about this.

:)

OTOH the doghouses argument is often overrated. Software projects that
try to build something that (on aspects of content and scale) was
succesfully done before generally succeed. The trouble is that we get
bigger computers every year, so a software project is likely to try
something that has not been done before. When you build the first
scyscraper or 1km suspension bridge all you can do is hire expierienced
doghouse builders...

Note that I am not saying that stupidity does not exist is software
projectes, I have seen (or been?) my share. Like trying to apply
last-years succesfull software technique on this-years project. (Though
often the problem is not last-year/this-year but the characteristics of
the projects, like applying database-transaction-based notations and
techniques on real-time chemical plant control).

Wouter van Ooijen

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



2006\08\30@043622 by Alan B. Pearce

face picon face
>In my professional work tool issues are a VERY big part of
>my wasted time, as such my tolerance for sub par tool quality
>isn't very high. If a tool keeps wasting my time I simply
>switch to another. After all, I'm not being paid to be their
>beta testers, why should I spend my time being one?

Hmm, is tool swapping really a solution? After all having found a bug, you
know how to work around it. Swapping to another similar tool may well have
you using a tool that has other bugs still to be revealed.

2006\08\30@101200 by Herbert Graf

flavicon
face
On Wed, 2006-08-30 at 09:36 +0100, Alan B. Pearce wrote:
> >In my professional work tool issues are a VERY big part of
> >my wasted time, as such my tolerance for sub par tool quality
> >isn't very high. If a tool keeps wasting my time I simply
> >switch to another. After all, I'm not being paid to be their
> >beta testers, why should I spend my time being one?
>
> Hmm, is tool swapping really a solution?

In my experience yes. I find that when a tool starts becoming "cranky"
the competitors step up to capture market share. It's a sort of yo-yo
effect.

> After all having found a bug, you
> know how to work around it. Swapping to another similar tool may well have
> you using a tool that has other bugs still to be revealed.

As I've said before, ONE bug isn't much of an issue with me. It's when a
tool starts having multiple bugs that I start looking for an
alternative.

TTYL

2006\08\30@210001 by Timothy Weber

face picon face
Wouter van Ooijen wrote:
> OTOH the doghouses argument is often overrated. Software projects that
> try to build something that (on aspects of content and scale) was
> succesfully done before generally succeed. The trouble is that we get
> bigger computers every year, so a software project is likely to try
> something that has not been done before. When you build the first
> scyscraper or 1km suspension bridge all you can do is hire expierienced
> doghouse builders...

Reminds me of Putt's Law - directly or indirectly related to the
statement "When you attempt something that's never been done before,
failure due to incompetence is indistinguishable from failure because
the task was impossible."  Corollaries and consequences are endless.
--
Timothy J. Weber
http://timothyweber.org

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