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

Exact match. Not showing close matches.
PICList Thread
'[PIC] C Compiler'
2007\01\29@221152 by John Dammeyer

flavicon
face
Hi,

Is there a GCC port of a C compiler for the PIC-18 series yet?

Thanks

John Dammeyer

2007\01\29@233727 by Mark Rages

face picon face
On 1/29/07, John Dammeyer <spam_OUTjohndTakeThisOuTspamautoartisans.com> wrote:
> Hi,
>
> Is there a GCC port of a C compiler for the PIC-18 series yet?
>
> Thanks
>
> John Dammeyer
>

I don't think so.  SDCC is GPL and pretty good for PIC-18.

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

2007\01\29@235415 by John Dammeyer

flavicon
face
Hi Mark,

Thanks.  Doesn't look like it's far enough along for a code port from Mchips
C18 though.  The reason I'm asking is that I've developed a project called
an Electronic Lead Screw or ELS for short (Yahoo group E-Leadscrew) that
replaces or augments the gears on a lathe among other things.  With it
someone can make a lathe easily thread or even cut tapers.

The first version source code has already been posted and when debugging is
complete the full version will also be published under the GNU licensing
model.

In essence the board has a 2 line LCD display, 34 buttons, quadrature encode
knob, 1 analog input and a 3 Amp 55V micro-stepper motor driver.  Schematics
and gerbers will also be published.  However, people who want to modify it
or upgrade it would have to buy the Microchip C so I'm just looking for a
lower cost alternative.

John Dammeyer

{Quote hidden}

> --

2007\01\30@000733 by Xiaofan Chen

face picon face
On 1/30/07, John Dammeyer <johndspamKILLspamautoartisans.com> wrote:
>
> In essence the board has a 2 line LCD display, 34 buttons, quadrature encode
> knob, 1 analog input and a 3 Amp 55V micro-stepper motor driver.  Schematics
> and gerbers will also be published.  However, people who want to modify it
> or upgrade it would have to buy the Microchip C so I'm just looking for a
> lower cost alternative.
>

Why? MPLAB C18 student version is free. Unless the code space is a
problem, it is free and people can use it to modify your code. Microchip
does not limit the usage of the student version.

http://www.microchip.com/c18

Regards,
Xiaofan

2007\01\30@020719 by Wouter van Ooijen

face picon face
> Is there a GCC port of a C compiler for the PIC-18 series yet?

no, and none is likely to exist, ever, for the same reason a 14-bit core
port is missing: the PIC architecture (12,14,16 bit) is too different
from what GCC assumes that a port will be very very difficult, if not
impossible.

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\01\30@040454 by Alan B. Pearce

face picon face
>Why? MPLAB C18 student version is free. Unless the code
>space is a problem, it is free and people can use it to
>modify your code. Microchip does not limit the usage of
>the student version.

I agree. Also you do not need to be a whiz kid to get the demo version to
last forever and accept the updates. ...

2007\01\30@042006 by John Dammeyer

flavicon
face
Is the C18 limited in code size?

John Dammeyer
>
>
> >Why? MPLAB C18 student version is free. Unless the code
> >space is a problem, it is free and people can use it to
> >modify your code. Microchip does not limit the usage of
> >the student version.
>
> I agree. Also you do not need to be a whiz kid to get the
> demo version to
> last forever and accept the updates. ...
>
> --

2007\01\30@055422 by Xiaofan Chen

face picon face
On 1/30/07, John Dammeyer <.....johndKILLspamspam.....autoartisans.com> wrote:
> Is the C18 limited in code size?
>

No. It only disables the optimization after expiration.

Regards,
Xiaofan

2007\01\30@060429 by Xiaofan Chen

face picon face
On 1/30/07, Wouter van Ooijen <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl> wrote:
> > Is there a GCC port of a C compiler for the PIC-18 series yet?
>
> no, and none is likely to exist, ever, for the same reason a 14-bit core
> port is missing: the PIC architecture (12,14,16 bit) is too different
> from what GCC assumes that a port will be very very difficult, if not
> impossible.
>

I do not know much about this. However, Scott Dattalo once mentioned
that it is possible to use GCC as the back end for the 18F device. He
chose to use SDCC at that time though. It will be not easy and SDCC
is improving quite fast so maybe it is a better idea to improve SDCC
instead of porting GCC to PIC18F even though it is technically possible.

Last time there was a thread in GNUPIC list about this topic.
www.linuxhacker.org/cgi-bin/ezmlm-cgi?1:sss:5528#b

2007\01\30@101452 by Bob Barr

flavicon
face
On Tue, 30 Jan 2007 18:54:20 +0800, "Xiaofan Chen" wrote:

>On 1/30/07, John Dammeyer wrote:
>> Is the C18 limited in code size?
>>
>
>No. It only disables the optimization after expiration.
>

While some of them are disabled, most of the optimizations continue to
work after the demo period expires.

I'm certain that 'procedural abstractions' are disabled. I think that
the 'extended mode' instructions are disabled as well but I'm not 100%
sure about that.


Regards, Bob

2007\01\30@104027 by Rolf

face picon face
Bob Barr wrote:
{Quote hidden}

==quote==
After 60 days, the optimizations related to procedural abstraction and
to the extended instruction set of the newer PIC18XXXX devices will be
disabled. Code compiled after the expiration date will function but may
occupy more memory space.
==/quote==

Rolf

2007\01\30@112926 by Wouter van Ooijen

face picon face
> After 60 days, the optimizations related to procedural
> abstraction and
> to the extended instruction set of the newer PIC18XXXX
> devices will be
> disabled. Code compiled after the expiration date will
> function but may
> occupy more memory space.

Is there a compiler setting that will create that after-expiration
effect? I guess it would make sense to use the compiler that way
immediately, to avoid surpraises after 60 days.

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\01\30@120521 by Rolf

face picon face
Wouter van Ooijen wrote:
{Quote hidden}

Yes. You can customize the optimizations used by the compiler. In MPLAB
you can go to the compiler settings tab, and choose "none", "debug",
"all", and "custom". You need "debug" if you are going to do ICD (at
least with the ICD2), otherwise I use "all". The "Custom" option
"un-greys"  a bunch of individual optimizations available, and you can
choose the ones you want. One of them is "Procedural Abstraction".
Additionally, when you set up your build you have to either enable or
disable the extended instruction set. This is not an "optimization", but
a build strategy.

Rolf

2007\01\30@122641 by Carl Denk

flavicon
face
PROJECT > BUILD OPTIONS > PROJECT > MPLABC18 > CATOGORIES > OPTIMIZATION
There you can disable selctively or all. I set mine to "ALL" disabled so
I wouldn't get a surprise some day.

Rolf wrote:
{Quote hidden}

2007\01\30@124428 by Harold Hallikainen

face
flavicon
face

> Yes. You can customize the optimizations used by the compiler. In MPLAB
> you can go to the compiler settings tab, and choose "none", "debug",
> "all", and "custom". You need "debug" if you are going to do ICD (at
> least with the ICD2), otherwise I use "all". The "Custom" option
> "un-greys"  a bunch of individual optimizations available, and you can
> choose the ones you want. One of them is "Procedural Abstraction".
> Additionally, when you set up your build you have to either enable or
> disable the extended instruction set. This is not an "optimization", but
> a build strategy.
>
> Rolf


I've run the ICD-2 with all optimization enabled. It works, but the code
is incredibly hard to follow when you single step since the optimizations
reuse code from one function in another. So you're single stepping along
and suddenly you're off in some strange location. Keep stepping and you're
back where you should be. Keeping the debug optimization DOES help!

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2007\01\30@135511 by Rolf

face picon face
Harold Hallikainen wrote:
{Quote hidden}

Hmmm... while I agree with you, it *can* work, it was just yesterday
that I was unable to create a breakpoint in a particular place because
it was optimized away. I remembered to change my compile settings and it
all worked.

So, stepping through some optimizations may be OK, but putting
break-points there may not....

Rolf

2007\01\30@141516 by Harold Hallikainen

face
flavicon
face

{Quote hidden}

I agree! The optimization away from debug does code reuse, so it the
program counter really wanders around the address space. You were probably
trying to set a break point on some point where the code "wandered away"
from that particular point in the source code, so it really didn't know
where to put the breakpoint. It's an interesting optimization. Pretty much
turns your code into spaghetti.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2007\01\30@143355 by Herbert Graf

flavicon
face
On Tue, 2007-01-30 at 11:11 -0800, Harold Hallikainen wrote:
> I agree! The optimization away from debug does code reuse, so it the
> program counter really wanders around the address space. You were probably
> trying to set a break point on some point where the code "wandered away"
> from that particular point in the source code, so it really didn't know
> where to put the breakpoint. It's an interesting optimization. Pretty much
> turns your code into spaghetti.

I find that if I have the room, while developing, I always turn pretty
much all of the more "fancy" optimizations off. It just gets too
frustrating trying to figure out whether the issue you're seeing is
because of something you did yourself, or something fancy the compiler
is doing to optimize things.

Certain optimizations are safe from a debug point of view, but some as
you've described can REALLY result in "weird" behaviour.

Of course one may not have the luxury of turning optimizations off (i.e.
chip is close to full). It's for reasons like that that I always try to
prototype on the absolute largest reasonable part possible.

TTYL

2007\01\30@144729 by Harold Hallikainen

face
flavicon
face

{Quote hidden}

I agree. I've also put compiler flags in my code to disable sections that
work so I can get the resulting nonoptimized code small enough to debug
other sections.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2007\01\30@153246 by John Dammeyer

flavicon
face
Hi all,

Yes.  Currently my project is at

           55824 out of 66584 program addresses used, program memory
utilization is 83%

With all optimizations on.  I haven't been able to use debug mode for some
time now.

However, the idea of turning on debug in only one file hadn't occurred to
me.  Good idea if it's possible.  Much of the space in my application is
text strings for status out the serial port as the system operates.  I turn
most of that off this way:

#ifdef FULL_DIAGNOSTICS
#define DEBUGSTR(s) printf((far rom char *)s)
#else
#define DEBUGSTR(s)
#endif

The Electronic Lead Screw runs a 23kHz timer giving me an interrupt every
43uS.  Optimization is critical there since there are times when almost all
of that 43uS is used inside the interrupt routine.  Outside that an LCD is
updated periodically with floating point values so the float to string
functions and everything involved with floating point take a lot of space.

John Dammeyer

{Quote hidden}

2007\01\30@194110 by Xiaofan Chen

face picon face
On 1/30/07, Rolf <learrspamspam_OUTrogers.com> wrote:
> >
> ==quote==
> After 60 days, the optimizations related to procedural abstraction and
> to the extended instruction set of the newer PIC18XXXX devices will be
> disabled. Code compiled after the expiration date will function but may
> occupy more memory space.
> ==/quote==
>

Just curious, what does this procedural abstraction do? It seems to
affect the code size by quite a lot. For example, the Microchip USB
Bootloader from the USB framework will not fit unless full optimization
is turned on.


Regards,
Xiaofan

2007\01\30@201526 by Bob Barr

flavicon
face
On Wed, 31 Jan 2007 08:41:09 +0800, "Xiaofan Chen"
<@spam@xiaofancKILLspamspamgmail.com> wrote:

>On 1/30/07, Rolf <KILLspamlearrKILLspamspamrogers.com> wrote:
>> >
>> ==quote==
>> After 60 days, the optimizations related to procedural abstraction and
>> to the extended instruction set of the newer PIC18XXXX devices will be
>> disabled. Code compiled after the expiration date will function but may
>> occupy more memory space.
>> ==/quote==
>>
>
>Just curious, what does this procedural abstraction do? It seems to
>affect the code size by quite a lot. For example, the Microchip USB
>Bootloader from the USB framework will not fit unless full optimization
>is turned on.
>

AIUI, procedural abstraction recognizes repeated code sequences from
various parts of the program and converts them into subroutines
wherever it can. Since many of these code sequences can be implemented
with a single subroutine, the code size reduction can be significant.


Regards, Bob

2007\01\30@201841 by John Temples

flavicon
face
On Wed, 31 Jan 2007, Xiaofan Chen wrote:

> Just curious, what does this procedural abstraction do?

It creates subroutines to replace redundant code.

--
John W. Temples, III

2007\01\30@212249 by Mark Rages

face picon face
On 1/29/07, John Dammeyer <RemoveMEjohndTakeThisOuTspamautoartisans.com> wrote:
> Hi Mark,
>
> Thanks.  Doesn't look like it's far enough along for a code port from Mchips
> C18 though.  The reason I'm asking is that I've developed a project called
> an Electronic Lead Screw or ELS for short (Yahoo group E-Leadscrew) that
> replaces or augments the gears on a lathe among other things.  With it
> someone can make a lathe easily thread or even cut tapers.
>
> The first version source code has already been posted and when debugging is
> complete the full version will also be published under the GNU licensing
> model.
>
> In essence the board has a 2 line LCD display, 34 buttons, quadrature encode
> knob, 1 analog input and a 3 Amp 55V micro-stepper motor driver.  Schematics
> and gerbers will also be published.  However, people who want to modify it
> or upgrade it would have to buy the Microchip C so I'm just looking for a
> lower cost alternative.
>
> John Dammeyer

Is this be sized for the 7" Chinese lathes?  I might be interested to
build this.  If I do,  I would do an SDCC port, since M'chip C isn't
supported on my computer.

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

2007\01\30@215352 by John Dammeyer

flavicon
face
Hi Mark,

Check out

http://groups.yahoo.com/group/E-LeadScrew/

For the running banter on this project.  The source code and schematics for
a simple serial port based version is also on that site and on the November
06 Circuit Cellar Magazine Archives.

And yes, the 7x8,10,12,14" lathes along with lathes like older South Bends
etc.  I've added stepper motors to a home built Gingery Lathe and can now
use it to cut an MT2 taper that's a good fit the first time not to mention
both metric and imperial threads.

Even if not used for an ELS, the board will be useful for a wide variety of
other projects.  I plan on writing code to make it into a back fence
controller for my sheet metal shear/brake.  One stepper, a home switch and
menu's with metal thickness info should, if all goes well, let me fold metal
correctly without a lot of mistakes.  In addition to the features below it
also has room for a CAN bus driver and RS232.  Uses PIC18F4680.

John Dammeyer


{Quote hidden}

> --

2007\01\30@221821 by Xiaofan Chen

face picon face
On 1/31/07, Mark Rages <spamBeGonemarkragesspamBeGonespamgmail.com> wrote:
>
> Is this be sized for the 7" Chinese lathes?  I might be interested to
> build this.  If I do,  I would do an SDCC port, since M'chip C isn't
> supported on my computer.
>

Microchip C18 (as well as MPLAB C30) runs fine under Linux with Wine.
You can also use Piklab as the GUI to drive it under Linux.

But a port to SDCC is nice too. ;-) If possible ,it is always nice to have a
native application under Linux (gputils/sdcc/gpsim/piklab/pk2/pyk/...) and
not to use Wine or VMware.

It is said that MPLAB and ICD2 debugging work well under Linux
with VMware provided that one has a Windows License. However
personally I would choose to dual-boot between Windows and Linux
in this case since I do not want to pay for VMware and do not want
the hassle of using a virutal machine on a personal computer. But it
might be a good solution for people who mostly work under Linux and
do not want to dual-boot.

2007\01\31@183440 by Rolf

face picon face
Have you seen this tool, by the way:

http://piclist.org/techref/microchip/language/c/stringformat.htm

Can re-arrange your pointers to optimize messages where they overlap. I
use it all the time to make space.... ;-) Also it encourages me to use
similar messages in lots of places.

Rolf



John Dammeyer wrote:
{Quote hidden}

2007\01\31@190555 by John Temples

flavicon
face
On Tue, 30 Jan 2007, Rolf wrote:

> Have you seen this tool, by the way:
>
> http://piclist.org/techref/microchip/language/c/stringformat.htm
>
> Can re-arrange your pointers to optimize messages where they overlap. I
> use it all the time to make space.... ;-) Also it encourages me to use
> similar messages in lots of places.

Any reasonable C compiler (C18 included) will optimize duplicate
strings and merge overlapping strings without using external tools.

--
John W. Temples, III

2007\01\31@194649 by John Dammeyer

flavicon
face
Pretty cool.  However, won't it break if the strings are longer than 256
bytes total since then they could overlap a page?  At least that used to be
a problem with the PIC16F series.

I tried this:

M_1="\nThreadSize is %s\n"
M_2="ThreadDepth is %s\n"
M_3="ThreadArea is %s\n"

Result was:

Messages
===
Optimization saved 0 characters from being duplicated

Most of my strings are literals used in printf statements

Still, it bears looking into.

Thanks.

John Dammeyer


Automation Artisans Inc.
http://www.autoartisans.com
Ph. 1 250 544 4950


> {Original Message removed}


'[PIC] C Compiler'
2009\08\29@001101 by David Duffy (AVD)
flavicon
face
Currently I need to write firmware to read audio (and possibly text)
files from an SD card.

I have only ever programmed in assembler for PICs, and then only for the
12 & 16 series devices.

There are numerous C examples (usually for 18 series PICs) on the 'net,
but not having learnt C is a problem. I have done a fair amount of
Delphi programming for Windows if that helps.

I don't mind buying a C complier (up to $500 or so), but the choice out
there is confusing. Can anyone point me to a recent discussion of the
various merits of each?
David...

--
___________________________________________
David Duffy        Audio Visual Devices P/L
Unit 8, 10 Hook St, Capalaba 4157 Australia
Ph: +61 7 38235717      Fax: +61 7 38234717
Our Web Site: http://www.audiovisualdevices.com.au
___________________________________________

2009\08\29@002834 by cdb

flavicon
face


:: ! don't mind buying a C complier (up to $500 or so), but the choice
:: out
:: there is confusing. Can anyone point me to a recent discussion of
:: the
:: various merits of each?

Well that'll start the flame wars! :-)

I can't help you with a recent discussion all I can say is I use FED-c
(PIC16/18). I'm tempted by CCS products, though if I had the money I
would be tempted towards Hitech-C.

Within your budget, CCS and FED-c would be fine.

The only thing that makes me feel uneasy about CCS products is the way
most functions seem to be inbuilt, even after reading the manual I'm
not sure if I could ignore the built in functions and just go with my
own.

As you know I'm not that far from you, so i could always sling you
last years version of FED-C if you wanted to try it out.

Dontronics sells both products.

Colin
--
cdb, TakeThisOuTcolinEraseMEspamspam_OUTbtech-online.co.uk on 29/08/2009

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

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

No matter how many times you push the envelope it always remains
stationery.





2009\08\29@012421 by solarwind

picon face
On Fri, Aug 28, 2009 at 9:10 PM, David Duffy
(AVD)<RemoveMEdavidspamTakeThisOuTaudiovisualdevices.com.au> wrote:
> Currently I need to write firmware to read audio (and possibly text)
> files from an SD card.
>
> I have only ever programmed in assembler for PICs, and then only for the
> 12 & 16 series devices.
>
> There are numerous C examples (usually for 18 series PICs) on the 'net,
> but not having learnt C is a problem. I have done a fair amount of
> Delphi programming for Windows if that helps.
>
> I don't mind buying a C complier (up to $500 or so), but the choice out
> there is confusing. Can anyone point me to a recent discussion of the
> various merits of each?
> David...

I would recommend HI-TECH C but they are expensive ($1000) if you want
to buy. You have a 30 day trial though and various methods of making
it work for you.

If not, I recommend CCS C compiler next
(http://www.ccsinfo.com/content.php?page=Purchasing1) (starting $350).
They are far cheaper and will still work very well.

Then there's mikroe C ($250), it's also really good.

2009\08\29@014415 by Bob Blick

face
flavicon
face
David Duffy (AVD) wrote:

> There are numerous C examples (usually for 18 series PICs) on the 'net,
> but not having learnt C is a problem. I have done a fair amount of
> Delphi programming for Windows if that helps.
>
> I don't mind buying a C complier (up to $500 or so), but the choice out
> there is confusing. Can anyone point me to a recent discussion of the
> various merits of each?

Aren't the majority of freely available libraries and samples for the 18
series written for the Microchip compiler? That would seem the default
position to start from unless there was a real strong argument for
something else.

Cheerful regards,

Bob

2009\08\29@021442 by David Duffy (AVD)

flavicon
face
Bob Blick wrote:
> David Duffy (AVD) wrote:
>
>  
>> There are numerous C examples (usually for 18 series PICs) on the 'net,
>> but not having learnt C is a problem. I have done a fair amount of
>> Delphi programming for Windows if that helps.
>>
>> I don't mind buying a C complier (up to $500 or so), but the choice out
>> there is confusing. Can anyone point me to a recent discussion of the
>> various merits of each?
>>    
>
> Aren't the majority of freely available libraries and samples for the 18
> series written for the Microchip compiler? That would seem the default
> position to start from unless there was a real strong argument for
> something else.
>  

That's a good question Bob. To be honest, I'm confused about what I
really want / need in the way of a C compiler, what's free and what's not!

I've just started reading an eBook on C (for PICs) and maybe it's not
all that different to Delphi (Pascal) after all. Sure the syntax is
different, but the overall idea seems to be much the same.

I've always programmed in assembler. Perhaps it is really an inefficient
way (time wise) to do things, but I just program the way I know how.

Projects that involve more complexity seem (to me) to be better suited
to C. Maybe not in reality. I really don't know. I'd just like to get
projects out the door with less low level programming these days.
David...

--
___________________________________________
David Duffy        Audio Visual Devices P/L
Unit 8, 10 Hook St, Capalaba 4157 Australia
Ph: +61 7 38235717      Fax: +61 7 38234717
Our Web Site: http://www.audiovisualdevices.com.au
___________________________________________

2009\08\29@025026 by Bob Blick

face
flavicon
face
David Duffy (AVD) wrote:

> That's a good question Bob. To be honest, I'm confused about what I
> really want / need in the way of a C compiler, what's free and what's not!

The Microchip MPLAB C18 compiler has full optimization during the demo
period and then drops to partial optimization but is still free to use.
So you can try it out and decide if the extra optimization is worth
paying $495 for. It comes with lifetime support/updates which is pretty
rare.

Cheerful regards,

Bob

2009\08\29@030752 by David Duffy (AVD)

flavicon
face
Bob Blick wrote:
> David Duffy (AVD) wrote:
>  
>> That's a good question Bob. To be honest, I'm confused about what I
>> really want / need in the way of a C compiler, what's free and what's not!
>>    
>
> The Microchip MPLAB C18 compiler has full optimization during the demo
> period and then drops to partial optimization but is still free to use.
> So you can try it out and decide if the extra optimization is worth
> paying $495 for. It comes with lifetime support/updates which is pretty
> rare.
>  

But the C18 complier only supports 16 bit chips? I mainly use 16F628 &
16F88 at present. I had a quick look but couldn't see pin compatible
parts in 18F series?
David...

--
___________________________________________
David Duffy        Audio Visual Devices P/L
Unit 8, 10 Hook St, Capalaba 4157 Australia
Ph: +61 7 38235717      Fax: +61 7 38234717
Our Web Site: http://www.audiovisualdevices.com.au
___________________________________________

2009\08\29@035556 by Mohit (Lists)

picon face
All Microchip compilers:
Hi-Tech C Compiler for PIC10/12/16
C18 for PIC18s
C30 for PIC30s & PIC24s
C32 for PIC32

Please see:
http://tinyurl.com/l4n2ur
and
http://tinyurl.com/kvve74


David Duffy (AVD) wrote:
{Quote hidden}

2009\08\29@040443 by Per Linne

flavicon
face
Of course you don't have to use the supplied functions.
They are not "built in" in a way that loads your program.
If you don't use them, no code will be generated for them.

I have used CCS (professionally) for more than 10 years.
I allways see to that I have the latest version btw.
I use all four flavors.

Regards,
PerL

{Original Message removed}

2009\08\29@044727 by cdb

flavicon
face


:: Ihave used CCS (professionally) for more than 10 years.
:: I allways see to that I have the latest version btw.
:: I use all four flavors.

I was looking around at the version for the 24F, as Hitech and
Microchip are more than I want to pay. though I'm using the uChip free
C30 compiler at the moment.

Colin
--
cdb, colinEraseMEspam.....btech-online.co.uk on 29/08/2009

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

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







2009\08\29@083130 by olin piclist

face picon face
David Duffy (AVD) wrote:
> I don't mind buying a C complier (up to $500 or so), but the choice
> out there is confusing. Can anyone point me to a recent discussion of
> the various merits of each?

My main experience with C on PICs has been with C18 and C30.

C18 seems to work correctly, but uses idiotic stack conventions and
subroutine linkage.  This effects overall performance and RAM use, and makes
any assembly code in the same project more difficult and less efficient.
I've talked to Microchip people about this, and they aren't inclined to fix
it any time soon.

C30 seems to be a nice piece of work.  The assembly code I've looked at
actually makes sense most of the time.  If you're stuck having to use C
(yucc), then try to do it on one of the 16 bit PICs like the 24, 30, or 33
series.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\29@084022 by olin piclist

face picon face
David Duffy (AVD) wrote:
> But the C18 complier only supports 16 bit chips?

No, the C18 compiler is for the PIC 16 series, which are 8 bit chips.  So
are the PIC 10, 12, and 16.  The PIC 24, 30, and 33 are 16 bit machines, and
the PIC 32 is a 32 bit machine.

> I mainly use 16F628 & 16F88 at present. I had a quick look but
> couldn't see pin compatible parts in 18F series?

18F1320, but beware the long rocky errata history of this part.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\29@101501 by Gaston Gagnon

face
flavicon
face
David Duffy (AVD) wrote:
> Currently I need to write firmware to read audio (and possibly text)
> files from an SD card.
>
> I have only ever programmed in assembler for PICs, and then only for the
> 12 & 16 series devices.
>
> There are numerous C examples (usually for 18 series PICs) on the 'net,
> but not having learnt C is a problem. I have done a fair amount of
> Delphi programming for Windows if that helps.
>
> I don't mind buying a C complier (up to $500 or so), but the choice out
> there is confusing. Can anyone point me to a recent discussion of the
> various merits of each?
> David...
>
>  
This one is pretty hard to beat: works with 12, 16 and 18 series and
cost 149.95$ for the PRO version.
www.sourceboost.com/Products/BoostC/Overview.html
It is supplied with its own IDE but you can if you prefer you can use it
from within mplab.
Gaston

2009\08\29@104601 by Isaac Marino Bavaresco

flavicon
face
David Duffy (AVD) escreveu:
> That's a good question Bob. To be honest, I'm confused about what I
> really want / need in the way of a C compiler, what's free and what's not!
>
> I've just started reading an eBook on C (for PICs) and maybe it's not
> all that different to Delphi (Pascal) after all. Sure the syntax is
> different, but the overall idea seems to be much the same.
>
> I've always programmed in assembler. Perhaps it is really an inefficient
> way (time wise) to do things, but I just program the way I know how.
>
> Projects that involve more complexity seem (to me) to be better suited
> to C. Maybe not in reality. I really don't know. I'd just like to get
> projects out the door with less low level programming these days.
> David...
>  

If you don´t need to extract every bit of performance from the CPU, C is
much faster to program and get things running. Besides, it is easy to
port to different processors and maintain.

If you are building an engine controller, which needs cycle-exact loops
and timing, etc. then I would advise using assembly. For a calculator,
with lots of user interaction and complicated logic it is better to use
C, perhaps with some assembly routines for time intensive calculations.

Remember, you can always mix C and assembly. The complex and not
performance critical tasks may be done in C (eg.: user interface), and
the high-performance tasks in assembly.


Another thought: tasks that only may be done in assembly in one CPU,
sometimes can be done in C in a more powerful CPU.

Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\08\29@112016 by Bob Blick

face
flavicon
face

On Sat, 29 Aug 2009 08:41:46 -0400, "Olin Lathrop"
<EraseMEolin_piclistspamembedinc.com> said:
> David Duffy (AVD) wrote:
> > But the C18 complier only supports 16 bit chips?
>
> No, the C18 compiler is for the PIC 16 series,

I think you meant "PIC 18 series".

-Bob

--
http://www.fastmail.fm - Or how I learned to stop worrying and
                         love email again

2009\08\29@125845 by olin piclist

face picon face
Bob Blick wrote:
>>> But the C18 complier only supports 16 bit chips?
>>
>> No, the C18 compiler is for the PIC 16 series,
>
> I think you meant "PIC 18 series".

D'oh, now I've added even more confusion.  The C18 compiler is for the PIC
18, which is a 8 bit machine with 16 bit core.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\29@183729 by David Duffy

flavicon
face
Isaac Marino Bavaresco wrote:
> If you don´t need to extract every bit of performance from the CPU, C is
> much faster to program and get things running. Besides, it is easy to
> port to different processors and maintain.
>
> If you are building an engine controller, which needs cycle-exact loops
> and timing, etc. then I would advise using assembly. For a calculator,
> with lots of user interaction and complicated logic it is better to use
> C, perhaps with some assembly routines for time intensive calculations.
>  

Thank you to everyone for their input so far. In some ways, I'm now
feeling that C may be a waste of time since I already program in
assembler. What are the advantages of moving to C?

Going back to the project that prompted all this; does it sound
reasonable to write assembly code for accessing an SD card and dealing
with the FAT?
David...

--

___________________________________________
David Duffy        Audio Visual Devices P/L
Unit 8, 10 Hook St, Capalaba 4157 Australia
Ph: +61 7 38235717   Fax: +61 7 38234717
New Web: http://www.audiovisualdevices.com.au
___________________________________________

2009\08\29@190315 by Tony Vandiver

flavicon
face
Just guessing, I'd say it would take you about as long to write the
assembly version as to learn enough C to get a FAT level SD card access
to work using the existing libraries.  If you choose the C route, you're
going to learn about something that could give you a big tool to put in
your bag for the future, but if you choose the assembly route, you're
going to learn all the ins and outs of the SD card interface and FAT
structure.  If you want to become a FAT guru, choose assembly, but if
you just want to get the project to work without an intimate knowledge
of the inner workings while getting the side benefit of much faster
future software development, choose C.

best wishes either way,

Tony


David Duffy wrote:
> Going back to the project that prompted all this; does it sound
> reasonable to write assembly code for accessing an SD card and dealing
> with the FAT?
> David...

2009\08\29@191800 by Isaac Marino Bavaresco

flavicon
face
David Duffy escreveu:
> Isaac Marino Bavaresco wrote:
>  
>> If you don´t need to extract every bit of performance from the CPU, C is
>> much faster to program and get things running. Besides, it is easy to
>> port to different processors and maintain.
>>
>> If you are building an engine controller, which needs cycle-exact loops
>> and timing, etc. then I would advise using assembly. For a calculator,
>> with lots of user interaction and complicated logic it is better to use
>> C, perhaps with some assembly routines for time intensive calculations.
>>  
>>    
>
> Thank you to everyone for their input so far. In some ways, I'm now
> feeling that C may be a waste of time since I already program in
> assembler. What are the advantages of moving to C?
>  

Suppose an if/else sequence with several complex expressions. In
assembly you would need to deal with lots of gotos, labels and all the
internals of the expressions themselves.

In C, you could write each expression in one line, with a more math-like
syntax (easier to understand at first glance than a long sequence of
instructions). You could use indentation also (not that you can´t use it
in assembly, but it is more awkward). Multi-byte values are treated
exactly as single-byte ones (in assembly, multi-byte operations take
much more source code lines to be written).

> Going back to the project that prompted all this; does it sound
> reasonable to write assembly code for accessing an SD card and dealing
> with the FAT?
> David...
>  

There are several free/open-source packages to deal with FAT file
systems, all in C. I don´t know any in assembly.

Best regards,

Isaac


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\08\29@193357 by Jim

flavicon
face
David,

My 2 cents worth.  I've stated this several times on this forum, so it
shouldn't be a surprise to anyone who has been here for
any length of time.  And that is I think typical HLL's are a bit overkill
for PIC's.  The resources on a PIC are limited and
there just isn't enough of an advantage of using an HLL over assembly.    If
you already know an HLL, regardless of flavor,
then you might save a little time.  But I prefer to program PIC's in
assembly.  And in my opinion, if you already know assembly,
don't bother with an HLL.  By the ime you learn to program with any skill at
all in the HLL, you could have had the assembly
program up and running.   I have two C compilers and two BASIC compilers,
and they mostly sit idle.  I don't use them unless
I have to.

With that said, anyone who prefers HLL's to program PIC's should by all
means follow their passion and use the HLL.
I will use assembly unless the customer insists on an HLL.

Anyone who disagrees with this assessment can chastise me offline.

So, David, my advice is stick with assembly.  If you have to learn
something, let it be something that can expand on what you
already know and practice.  However, the ultimate decision is up to you.


Regards,

Jim



{Original Message removed}

2009\08\29@194138 by Jim

flavicon
face

All,

Just a point of interest here and that is if you look at the output of a
compiler, you'll see exactly what is explained here.
Several Calls, Goto's, Labels, etc.  But that is necessary.  That's what the
PIC, (or any controller / uP) understands.
And the source code lines in a "C" or "BASIC" program ultimately get
converted into many assembly instructions,
and ultimately into machine code.   So, it is easier to write one line of
"C" for instance, and have the compiler worry about
keeping track of everything and converting it to assembly/machine code.
But, do you learn anything in this process?
Maybe, but not enough to justify using it in my opinion.

Anyway, that's my input on this subject.

Regards,

Jim





{Original Message removed}

2009\08\29@203346 by Isaac Marino Bavaresco

flavicon
face
Jim escreveu:
> All,
>
> Just a point of interest here and that is if you look at the output of a
> compiler, you'll see exactly what is explained here.
> Several Calls, Goto's, Labels, etc.  But that is necessary.  That's what the
> PIC, (or any controller / uP) understands.
> And the source code lines in a "C" or "BASIC" program ultimately get
> converted into many assembly instructions,
> and ultimately into machine code.   So, it is easier to write one line of
> "C" for instance, and have the compiler worry about
>  

The point here is exactly this: less code to write (faster), easier to
understand (and remember) and for others to understand too, less need
for comments, more compact code, simpler to port to other architectures
(when porting assembly code to a different line of processors,  many
times it may be easier to rewrite everything) and one can focus on the
problem rather than in the implementation.

> keeping track of everything and converting it to assembly/machine code.
> But, do you learn anything in this process?
>  

Sometimes I learn more by understanding well the problem than diving
into the fine details of the assembly instructions. What will the OP
learn by writing the program in assembly language if he already knows it
well? If he learns a HLL to write the program, then he will learn a
little (or a lot) more than he knows now.

Is the OP planning to get stuck forever with PICs? If not, what will he
do with all the code he has written already?

I program in assembly as well (or badly) as I do in HLLs, but I´m trying
to make a living out of programming and if coding in C shortens the
development cycle and gives better quality code, then I go for it.


> Maybe, but not enough to justify using it in my opinion.
>
> Anyway, that's my input on this subject.
>
> Regards,
>
> Jim
>  

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\08\29@213923 by Jim

flavicon
face

Issac,

I agree with all you say except for the "More compact code"
The source code may be more compact, but the object code will NOT
always be more compact.  Generally, at best, the compiler code will be
the same size.  Typically, it will be larger.  And on ocassion, it will be
smaller
due to optomizations.  But those cases are few and far between in my
experience.

But, the bottom line is, you prefer HLL's because you are trying to make a
living at this.  I, on the other hand, have a day job, and PIC programming
is a moonlighting
job for me.  Don't get me wrong, I do real programming on real PIC's, and
generate some
sophiscated systems.  But if I lost all my PIC programming jobs, I could
still live as I have
my day job.  At least I still had it as of last week.

I have been working with PIC's since about 1990 or 1991.  The lineup of
parts offered
by Microchip was a total of 4.  The assembler was DOS based.  The Simulator
was a seperate app.
Etc, etc.  My first programmer was a homebuilt unit connected to a parallel
port.  And I still have
every development tool for them.  Maybe that's not important to anyone, but
my point is, I have
been working with PIC's almost since their initial release after the sale of
the PIC dept of General Instruments.
I have been using assembly all that time, with a few jobs where I had to use
an HLL due to the customer requirements.
But for the most part, I have been using assembly for the better part of 18
or so years.  I am familiar with it, and I don't
think the HLL's for PIC's is the panacea they are cracked up to be, so I
stick with assembly.

And anyone who wants to or needs to use an HLL has my blessing.


Jim




{Original Message removed}

2009\08\29@222144 by Isaac Marino Bavaresco

flavicon
face
Jim escreveu:
> Issac,
>
> I agree with all you say except for the "More compact code"
> The source code may be more compact, but the object code will NOT
> always be more compact.  Generally, at best, the compiler code will be
> the same size.  Typically, it will be larger.  And on ocassion, it will be
> smaller
> due to optomizations.  But those cases are few and far between in my
> experience.
>  

By my experience, most projects end with a good deal of unused program
memory space, so I don´t worry much about final code size. These days,
it is even less important as the program memory of the new devices is
getting larger at the same time their price is dropping.

> But, the bottom line is, you prefer HLL's because you are trying to make a
> living at this.  I, on the other hand, have a day job, and PIC programming
> is a moonlighting
> job for me.  Don't get me wrong, I do real programming on real PIC's, and
> generate some
> sophiscated systems.  But if I lost all my PIC programming jobs, I could
> still live as I have
> my day job.  At least I still had it as of last week.
>  

I simply found that it is more profitable if I finish a project faster
and move to the next.
And it really is easier to debug C code than assembly and to change
something  in it after some months or years after it is finished.

> I have been working with PIC's since about 1990 or 1991.  The lineup of
> parts offered
>  

I started with micro-controllers in 1992 (8051 family) and with PICs
approx. in 1996.

{Quote hidden}

Best regards,

Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\08\29@225218 by Dave Tweed

face
flavicon
face
Isaac Marino Bavaresco wrote:
> Suppose an if/else sequence with several complex expressions. In
> assembly you would need to deal with lots of gotos, labels ...

Not necessarily. For example, I use a "structured assembly" preprocessor
that takes care of all of those details for me. I've written about it
before, last time back in February.

> ... and all the internals of the expressions themselves.

Well, yes. There's no simple way around that.

-- Dave Tweed

2009\08\29@230226 by Terry Harris

picon face
On Sat, 29 Aug 2009 22:52:16 -0400 (EDT), you wrote:

>Isaac Marino Bavaresco wrote:
>> Suppose an if/else sequence with several complex expressions. In
>> assembly you would need to deal with lots of gotos, labels ...
>
>Not necessarily. For example, I use a "structured assembly" preprocessor
>that takes care of all of those details for me. I've written about it
>before, last time back in February.

Me too, its called a C compiler.

2009\08\30@084015 by olin piclist

face picon face
Isaac Marino Bavaresco wrote:
> By my experience, most projects end with a good deal of unused program
> memory space, so I don´t worry much about final code size. These days,
> it is even less important as the program memory of the new devices is
> getting larger at the same time their price is dropping.

This is nonsense of course.  There will always be high volume cost sensitive
projects pushing the limits.  If the parts get more capable and cheaper,
more things will be crammed in or cheaper parts used.  The majority of
projects aren't cram jobs, but a significant fraction do bump into limits.
Since those are generally high volume projects, they account for a much
larger fraction of microcontrollers sold.  In fact, I'd say such projects
dominate in terms of units produced.

> And it really is easier to debug C code than assembly

I have found completely the opposite.  At least with C18, I can rarely get
MPLAB to show me local variables, step cleanly from one source line to the
next, etc.  Debugging the C18 parts of a mixed C18/MPASM project is *much*
harder than the MPASM parts.

> and to change
> something  in it after some months or years after it is finished.

Then you need to learn to document your code better.  This is not a language
issue, but a code discipline and documentation issue, and applies to all
languages.  I've seen some horribly obtuse C code.  You can make a mess in
any language, and you can also write clear code.  Don't blame the language.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\31@132218 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
> Isaac Marino Bavaresco wrote:
>  
>> By my experience, most projects end with a good deal of unused program
>> memory space, so I don´t worry much about final code size. These days,
>> it is even less important as the program memory of the new devices is
>> getting larger at the same time their price is dropping.
>>    
>
> This is nonsense of course.  There will always be high volume cost sensitive
> projects pushing the limits.  If the parts get more capable and cheaper,
> more things will be crammed in or cheaper parts used.  The majority of
> projects aren't cram jobs, but a significant fraction do bump into limits.
> Since those are generally high volume projects, they account for a much
> larger fraction of microcontrollers sold.  In fact, I'd say such projects
> dominate in terms of units produced.
>  

For some very critical cases the assembly language may be better, but if
the object code fits in the program memory, it doesn't matter if it
takes 50%, 70% or even 80% of the memory.
It is good to have some spare space for future enhancements, but in the
case you mention of a high volume project, it is OK even if it takes
100% of the program space.

>> And it really is easier to debug C code than assembly
>>    
>
> I have found completely the opposite.  At least with C18, I can rarely get
> MPLAB to show me local variables, step cleanly from one source line to the
> next, etc.  Debugging the C18 parts of a mixed C18/MPASM project is *much*
> harder than the MPASM parts.
>  

MPLAB is indeed buggy, but it is not the only available option. Again
you resort to a very specific case to make your point. You are taking
MPLAB SIM/IDE bugs as if they are due to the C language, and not of the
buggy implementation done by Microchip.

With a good IDE and debug Tool, all the advantages of C pop to the eyes.

You appear to be locked to a single vendor and architecture. If you had
to design using AVR, ARM and x86 (software only) besides PIC, you would
understand the need for high-level languages.

>> and to change
>> something  in it after some months or years after it is finished.
>>    
>
> Then you need to learn to document your code better.  This is not a language
> issue, but a code discipline and documentation issue, and applies to all
> languages.  I've seen some horribly obtuse C code.  You can make a mess in
> any language, and you can also write clear code.  Don't blame the language.
>  

Your argument only stands if you assume I document poorly my C code and
you document your assembly code well. Just suppose somebody very
disciplined write and document both the C and assembly code, which one
is more compact, has less lines of code and is easier to understand?

What if you are studying somebody else's code, isn't it easier to
understand if it is in a high-level language? Specially if you don't
know the architecture?



Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\08\31@133826 by Walter Banks

picon face


Isaac Marino Bavaresco wrote:

> For some very critical cases the assembly language may be better, but if
> the object code fits in the program memory, it doesn't matter if it
> takes 50%, 70% or even 80% of the memory.
> It is good to have some spare space for future enhancements, but in the
> case you mention of a high volume project, it is OK even if it takes
> 100% of the program space.
>

The only case where asm should ever be needed is when exact
timing is required.

There are many reasons for efficient code in applications. Code size
is only one of them. Making sure the code will fit the available ROM
is important.

Execution time and RAM usage are two additional important
application metrics that are important to a successful project.

Execution time is directly related to the amount of generated EMI
and power consumption.

Regards


Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com


2009\08\31@155350 by olin piclist

face picon face
Isaac Marino Bavaresco wrote:
> For some very critical cases the assembly language may be better, but
> if
> the object code fits in the program memory, it doesn't matter if it
> takes 50%, 70% or even 80% of the memory.

It does if it's a high volume project and a cheaper processor could have
been used.

>> I have found completely the opposite.  At least with C18, I can
>> rarely get MPLAB to show me local variables, step cleanly from one
>> source line to the next, etc.  Debugging the C18 parts of a mixed
>> C18/MPASM project is *much* harder than the MPASM parts.
>
> MPLAB is indeed buggy, but it is not the only available option.

I'm not sure if this is due to bugs or just how it works or the kind of
information C18 passes to the COD file via the linker.

> With a good IDE and debug Tool, all the advantages of C pop to the
> eyes.

I agree that the problems debugging C18 with MPLAB are not inherent to C,
but that's nonetheless what I have to deal with.

> You appear to be locked to a single vendor and architecture.

This is the *PIC* list.  Yes, I'm talking about PIC development.

>> Then you need to learn to document your code better.  This is not a
>> language issue, but a code discipline and documentation issue, and
>> applies to all languages.  I've seen some horribly obtuse C code.
>> You can make a mess in any language, and you can also write clear
>> code.  Don't blame the language.
>
> Your argument only stands if you assume I document poorly my C code
> and you document your assembly code well.

Yes, since that appears to be the case.

> Just suppose somebody very
> disciplined write and document both the C and assembly code, which one
> is more compact, has less lines of code and is easier to understand?
>
> What if you are studying somebody else's code, isn't it easier to
> understand if it is in a high-level language?

Not necessarily.  It all depends on how logically the project is broken up
and how well documented.  This is largely independent of language.
Unfortunately some languages make it easier to make a mess or write obtuse
code than others, like C, but you can still write good or bad code in any
language.

> Specially if you don't know the architecture?

Obviously for assembler we are assuming familiarity with the architecture.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\31@163742 by Isaac Marino Bavaresco

flavicon
face
Olin Lathrop escreveu:
>>> Then you need to learn to document your code better.  This is not a
>>> language issue, but a code discipline and documentation issue, and
>>> applies to all languages.  I've seen some horribly obtuse C code.
>>> You can make a mess in any language, and you can also write clear
>>> code.  Don't blame the language.
>>>      
>> Your argument only stands if you assume I document poorly my C code
>> and you document your assembly code well.
>>    
>
> Yes, since that appears to be the case.

Perhaps that is not the case, I don't know if you have enough knowledge
about my work to make such a statement.

Well, OK, I shouldn't  have started a discussion against God Himself. I
beg your forgiveness My Lord.

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\08\31@195117 by Bob Axtell

face picon face
"So, David, my advice is stick with assembly.  If you have to learn
something, let it be something that can expand on what you
already know and practice.  However, the ultimate decision is up to you."

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

I own a copy of Mikro Pascal and an ancient copy of CCS C.

I am embarassed to say that in over 30+ years of development, not even
ONCE was the commercial firmware written in a HLL. That does NOT mean
I didn't try. I just didn't feel that the commercial HLL was "stable
enough".

As hard as assembler is to write, HLL is rarely better or faster
overall, but you can "whip up" something in short order. But I always
want to know, CLEARLY, how each routine actually worked. Sometimes it
seemed pretty odd how the result was derived.

Just because you are using an HLL does NOT mean that you are magically
doing everything right. You may have misunderstood the firmware specs
and already have a mess, regardless of the language. Or, maybe you
have still installed a small bug somewhere; it STILL has to be rooted
out aqnd killed.

If I were starting over, I'd do the same thing: learn the hardware in
assembly, then, later, move to C.

--Bob

2009\08\31@201353 by Vitaliy

face
flavicon
face
Bob Axtell wrote:
{Quote hidden}

FWIW, all of our production code for the PIC was written in C. I have never
really written anything worth mentioning in assembly.

I'm not saying your suggested approach is wrong; I'm simply pointing out
that based on my experience, it's OK to skip over assembly and jump right
into C.

Vitaliy

2009\08\31@202541 by Vitaliy

face
flavicon
face
Olin Lathrop wrote:
> Isaac Marino Bavaresco wrote:
>> For some very critical cases the assembly language may be better, but
>> if
>> the object code fits in the program memory, it doesn't matter if it
>> takes 50%, 70% or even 80% of the memory.
>
> It does if it's a high volume project and a cheaper processor could have
> been used.

Olin -- out of curiosity, what was the highest volume project you've ever
worked on? 100k, 1M, 10M, 100M?

Vitaliy


'[PIC] C Compiler'
2009\09\01@000510 by William \Chops\ Westfield
face picon face
> It does if it's a high volume project and a cheaper processor could  
> have been used.

I dunno.  Judging by high volume consumer gear, the price of chips  
doesn't have a lot to do with the product price.  If you have THAT  
high a volume, apparently you start negotiating with manufacturers for  
lower prices on the chips.  Thus a high-volume consumer digital camera  
costs less than a microcontroller "evaluation board" even though the  
former has chips that dwarf the complexity of the latter, and wouldn't  
even be purchasable in low volumes...

In this case (FAT filesystem on a flash card) using a high level  
language has an advantage I haven't seen explicitly stated yet.  Since  
most of the "complexity" of the problem is external to the PIC itself,  
the advantages of dealing directly in assembler are lessened AND the  
PORTABILITY of the code is VERY MUCH IMPROVED by being in C.  (In many  
cases, portability is not important, because the application is so  
inherently chip-specific anyway.  But this isn't one of them.)  You  
could write some carefully portable C code (an art in itself, alas)  
that would work on your initial selection of a 16F628 chip, and be  
nearly-instantly installed on an 18F chip when you discover you need a  
lot more program space, or on a 24F chip when you discover you need  
more speed, or on a freescale chip if Microchip pisses you off and you  
decide to switch vendors (although usually it seems to go the other  
direction :-)

That said, a FAT file system isn't THAT complex, and an implementation  
written in assembler should be pretty doable by someone with  
experience.  And I would think that there would be a lot of people  
interested in seeing the resulting code, especially if it turns out to  
be significantly smaller than the C versions floating around.  (In my  
experience, FAT implementations tend to get pretty bloated.)

BillW

2009\09\01@155405 by olin piclist

face picon face
Vitaliy wrote:
> Olin -- out of curiosity, what was the highest volume project you've
> ever worked on? 100k, 1M, 10M, 100M?

It looks like one product will get to around 5M, including variants with
largely the same firmware.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\09\01@155436 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> Isaac Marino Bavaresco wrote:
>>> I have found completely the opposite.  At least with C18, I can
>>> rarely get MPLAB to show me local variables, step cleanly from one
>>> source line to the next, etc.  Debugging the C18 parts of a mixed
>>> C18/MPASM project is *much* harder than the MPASM parts.
>>
>> MPLAB is indeed buggy, but it is not the only available option.
>
> I'm not sure if this is due to bugs or just how it works or the kind
> of information C18 passes to the COD file via the linker.
>
>> With a good IDE and debug Tool, all the advantages of C pop to the
>> eyes.
>
> I agree that the problems debugging C18 with MPLAB are not inherent
> to C, but that's nonetheless what I have to deal with.

How's your Pascal compiler doing in this respect? Can you step through
the source code, view variable values? Is it any better than C18? If
not, is this an argument against Pascal?

FWIW (and this of course applies only to whoever thinks it applies :),
for a pro it should be possible to buy a tool chain that works. If
MPLAB/C18 doesn't, I'd get one that does.

There are people who think that MPLAB isn't well suited for programming
chips. There are also people who think that MPLAB isn't well suited for
programming -- and both may have a point, or may not :)

Gerhard

2009\09\01@170932 by olin piclist

face picon face
Gerhard Fiedler wrote:
> How's your Pascal compiler doing in this respect? Can you step through
> the source code, view variable values? Is it any better than C18? If
> not, is this an argument against Pascal?

I don't have Pascal for PICs.  Even if I did create a compiler from my
translator, I'd still have to create MPLAB debug records for it to allow for
Pascal source level debugging in MPLAB.

> FWIW (and this of course applies only to whoever thinks it applies :),
> for a pro it should be possible to buy a tool chain that works. If
> MPLAB/C18 doesn't, I'd get one that does.

This concept doesn't work when the customer specifies a particular compiler
or you have to use a piece of code written for a particular compiler.

> There are people who think that MPLAB isn't well suited for programming
> chips. There are also people who think that MPLAB isn't well suited for
> programming -- and both may have a point, or may not :)

Personally I'm pretty happy with MPLAB for debugging assembly code.  There
are of course a few things I'd like added or changed, but on the whole MPLAB
is a decent and very usable piece of software.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\09\02@043641 by Vitaliy

face
flavicon
face
Olin Lathrop wrote:
>> Olin -- out of curiosity, what was the highest volume project you've
>> ever worked on? 100k, 1M, 10M, 100M?
>
> It looks like one product will get to around 5M, including variants with
> largely the same firmware.

Wow. Definitely puts things in perspective. :)

Can you volunteer any more details? Is this a consumer item? What's the
approximate price per unit?

Vitaliy

2009\09\02@074422 by olin piclist

face picon face
Vitaliy wrote:
> Wow. Definitely puts things in perspective. :)

Plenty of products have way higher volumes than that, and they're not all
cheap disposable consumer items either.  Take a look at the number of PC
motherboards sold per year, or the numbers for a popular car model.

> Is this a consumer item? What's
> the approximate price per unit?

These are commercial items that are used for a month or less then discarded.
I think the customer price is in the $5 to $10 range.  Obviously even $.05
per unit production cost can make a meaningful difference.  It should be no
surprise, but there is far more engineering in the production of these
things than in their design.  I alone spent more time on the production
tester electronics and firmware than on the units themselves, and there is
another engineer that only works on production matters and hasn't done any
design of these units.

By the way, those testers are at the other end of the spectrum.  So far I
think only 4 testers boards have been produced, although there will probably
be a few 10s made over the life of this product.  For a project I'm working
on today we created just 3 copies of a particular design the customer
wanted.  These are essentially USB interfaces for live data gathering from
another gizmo for testing, debugging, and research.  In that case we built
them by hand by adding a few parts to our ReadyBoard-02
(http://www.embedinc.com/products/ready02).


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

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