Searching \ for '[PIC] Status of SDCC, especially with reference to' 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=sdcc
Search entire site for: 'Status of SDCC, especially with reference to'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Status of SDCC, especially with reference to'
2005\09\08@164522 by John Nall

picon face
Would someone who is knowledgeable of such things tell me the current
status of the SDCC compiler with PIC's?  And especially the 16F675,
since that is what I currently need to compile an already existing C
program for?

I looked at the information about SDCC, but it just said that "work is
progressing on PIC support," without any amplification of that
statement.  (I realize that I may have looked at the wrong place, but
this was at sdcc.sourceforge.net, which I would consider to be a pretty
good place to start).

And assuming, for the sake of argument, that the answer is "they're not
there yet!" then what C compiler would be suggested for compiling a C
program where the target chip is a 16F675?  (Preferably free, since I do
not want to buy a compiler just to compile one program!)

John

2005\09\08@165958 by Bob Blick

face picon face
Hi John,

There are a lot of variations when it comes to C on the PIC. You say you
have an existing program. How good are you at porting a program written
for one vendor's C to another? printf? math? I/O?

Many C compilers come with a time- or size-limited version. That might be
your best option. Figure out what compiler this program you want to
compile is written for, and get the demo.

Cheers,

Bob


{Quote hidden}

2005\09\08@170215 by Bob Blick

face picon face
And another thing, didn't you mean to write 12F675, not 16F675?

2005\09\08@170403 by Bob Blick

face picon face
HiTech PICCLite is free(beer) for the 12F675:

http://htsoft.com/products/PICClite.php

2005\09\08@171806 by John Nall

picon face
Bob Blick wrote:

>Hi John,
>
>There are a lot of variations when it comes to C on the PIC. You say you
>have an existing program. How good are you at porting a program written
>for one vendor's C to another? printf? math? I/O?
>  
>

Well I have already managed to answer the second part of the question,
in that the free version of the Hi-Tech  C compiler will compile with a
16F675 as the target, according to what they say at their website.  The
program was originally written for a 14C000 and is not very complex.  I
do not see any particular problem in porting it (which may, of course,
be wildly optimistic).  There are no library calls (or, to be more
accurate, the library routines are included as source with the program).

But I am still curious about the status of SDCC, if someone knows.

John

2005\09\08@181956 by John Nall

picon face
Bob Blick wrote:

>> And another thing, didn't you mean to write 12F675, not 16F675?
>  
>
Well . . . both yes and no.  :-)  I meant to write 16F675, and I did
write 16F675, but I SHOULD have written 12F675.  So the bottom line is
that you are correct, and I was just plain mistaken about the number of
the chip.  There is a reason for having made that mistake, but it is not
a very good one, and so I will not present it here.

John


2005\09\08@201429 by Chen Xiao Fan

face
flavicon
face
Hi-Tech PICC Lite is both available on Windows and Linux.

There are some other non-free C compiler for PICs which
offer limited demo versions. Since you are using 12F675,
the free version of MicroC may be a good alternative to
PICC Lite. The only limitation of the free version is that
it cannot generate hex output over 2K of program words.
Thye also offer demo versions of Pascal for PICs and dsPICs.
www.mikroelektronika.co.yu/english/product/compilers/mikroc/download.
htm

In terms of SDCC, its support for PIC14 (12F/16F) are still
experimental and seems there are no library support. It is
much more usable for PIC16 (18F).

However I think 12F675 anyway does not need C library support.
There is a good tutorial on how to use SDCC for PIC under Linux.
http://ubicomp.lancs.ac.uk/%7Emartyn/sdcc_linux


Regards,
Xiaofan

-----Original Message-----
From: Bob Blick
Sent: Friday, September 09, 2005 5:04 AM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] Status of SDCC, especially with reference to 16F675

HiTech PICCLite is free(beer) for the 12F675:

http://htsoft.com/products/PICClite.php

2005\09\08@205919 by Timothy J. Weber

face
flavicon
face
Chen Xiao Fan wrote:
> There are some other non-free C compiler for PICs which
> offer limited demo versions. Since you are using 12F675,
> the free version of MicroC may be a good alternative to
> PICC Lite. The only limitation of the free version is that
> it cannot generate hex output over 2K of program words.
> Thye also offer demo versions of Pascal for PICs and dsPICs.
> www.mikroelektronika.co.yu/english/product/compilers/mikroc/download.
> htm

I have not looked deeply into lots of C compilers for PICs, but I have
tried a few.  What stands out to me about MicroC is their standard library:

http://www.mikroelektronika.co.yu/english/product/compilers/mikroc/builtin.htm

Seems pretty impressive to me, at least from the perspective of getting
a quick project going - I don't know how deep each functional area is,
but I've tried a couple (PS/2, sound) and they were just what I needed
to get a neat gizmo up and running.

Also, their demo limitation is simple and clear: 2K code limit.  Aside
from that, it supports their full range of chips (which also seems
extensive, though it doesn't include dsPICs yet - they do support it in
separate Pascal and BASIC compilers).

AND their IDE is nice.
--
Timothy J. Weber                 http://www.lightlink.com/tjweber
spam_OUTtjweberTakeThisOuTspamlightlink.com

2005\09\08@213953 by Chen Xiao Fan

face
flavicon
face
One more good thing about MicroC/MicroBasic/MicroPascal, they
are all running under Linux with Wine. The IDE seems to be
quite well written. However I have not really tried it since
we have PICC (old version only) for PIC16 and MPLAB C18
(full version from Microchip).

Regards,
Xiaofan

{Original Message removed}

2005\09\09@023200 by Wouter van Ooijen

face picon face
> One more good thing about MicroC/MicroBasic/MicroPascal, they

One thing I found very frustrating was that writing in-line assembly
using variables and/or parameters required me to know the mangled names,
which can only be seen in the assembly listing *and change when you
change procedure and/or module names*.

Wouter van Ooijen

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


2005\09\09@042157 by Jan-Erik Soderholm

face picon face
> Since you are using 12F675,
> the free version of MicroC may be a good alternative to
> PICC Lite. The only limitation of the free version is that
> it cannot generate hex output over 2K of program words.

Well now, the 12F675 has 1K of prog mem, so the 2K limit
doesn't seems as a show stopper here.

And besides, how much C-runtime can you cram into
a 1K prog mem anyway ? Is there any room left for
the user code ?

Was the original target also limited to 1K prog mem ?

Regards,
Jan-Erik.



2005\09\09@044449 by Wouter van Ooijen

face picon face
> And besides, how much C-runtime can you cram into
> a 1K prog mem anyway ? Is there any room left for
> the user code ?

Which runtime? C specifies that the global variables are 0 at the start
of the program, that requires a few instructions, and compilers often
have an option to omit this. Beyond that everything that is included is
because you used it (for instance multiply/divide, multi-byte
calculations, floating point).

Wouter van Ooijen

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


2005\09\09@045325 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote :

> > And besides, how much C-runtime can you cram into
> > a 1K prog mem anyway ? Is there any room left for
> > the user code ?
>
> Which runtime?...

Yes, "runtime" wasn't the right word.

I thought more about startup code, "extra" code
around function calls and so on.

I'm guessing (on thin ice here, yes) that C might use
a little more code for such things then when you
write your own optimized asm code...

As usualy, I might be completly wrong, of course... :-)

Jan-Erik.



2005\09\09@085719 by John Nall

picon face
Jan-Erik Soderholm wrote:

>> And besides, how much C-runtime can you cram into
>a 1K prog mem anyway ? Is there any room left for
>the user code ?
>
>Was the original target also limited to 1K prog mem ?
>  
>
Yeah, good question.  The original target was a 14C000, so will just
have check it out.  Darn!  Every time I  think I have a problem solved
something new pops up.

John

2005\09\09@091501 by Jan-Erik Soderholm

face picon face
John Nall wrote :

> >Was the original target also limited to 1K prog mem ?
> >  
> >
>
> Yeah, good question.  The original target was a 14C000, so will
just
> have check it out...

4 Kword prog mem.

At least "PIC14000", the "C" version just seems to be the OTP
version...

A 12F675 might be a little bit on the low side.

Jan-Erik.



2005\09\09@105004 by Timothy Weber

face
flavicon
face
Jan-Erik Soderholm wrote:
>
>>>And besides, how much C-runtime can you cram into
>>>a 1K prog mem anyway ? Is there any room left for
>>>the user code ?

> I'm guessing (on thin ice here, yes) that C might use
> a little more code for such things then when you
> write your own optimized asm code...
>
> As usualy, I might be completly wrong, of course... :-)

I'd say you're partly right.  :)  Of course HLLs tend to tradeoff chip
time/cost/size vs. human time, in general.

But using a HLL doesn't immediately bloat the code past 1K; it just
generally adds a bit of overhead for each function.  There are plenty of
projects that can fit in 1K using C.
--
Timothy J. Weber
http://www.lightlink.com/tjweber

2005\09\09@113432 by William Chops Westfield

face picon face
> And besides, how much C-runtime can you cram into
> a 1K prog mem anyway ? Is there any room left for
> the user code ?
>
C doesn't really have much of a 'runtime environment' (and certainly
not the way something like visual basic does.)  It's essentially a
language explicitly WITHOUT a runtime environment, or I/O, or even a
significant set of standard built-in functions.  That makes it ideal
for embedded applications; if you don't use a particular function
(say, printf()), then there is no code for that function in your
binary.  Good embedded compilers go further, so that only the pieces
of printf() you actually use get included (usually leaving behind all
that floating point code, for instance!)

The overhead of C calling conventions can be higher than a raw call
instruction.  Or not.  The programmer has to be somewhat careful not
to use C conventions that map particularly badly to the underlying
architecture (passing multi-byte structures, gratuitous use of
floating point, etc.)

I've been pretty impressed with how small the code produced by PIC
C compilers can turn out...

BillW

2005\09\09@115407 by Bob Blick

face picon face

> And besides, how much C-runtime can you cram into
> a 1K prog mem anyway ? Is there any room left for
> the user code ?

There is no runtime code.

This fits nicely in 1K:
http://www.bobblick.com/techref/projects/lcdterm/lcdterm6.c

Cheers,

Bob


2005\09\09@122914 by sergio masci

flavicon
face


On Fri, 9 Sep 2005, Timothy Weber wrote:

{Quote hidden}

Not necessarily. The XCSB compiler will notice if an actual parameter to a
function is invarient (i.e. all calls to that function pass the same
variable or constant for that parameter) and the parameter is not modified
within the function AND will eliminated the parameter passing overhead for
that parameter and embed it directly within the function if possible.

This can produces huge optimisations when addresses of buffers are passed
to functions as pointers.

The compiler will even promote the result of a function if possible so
that it ends up in the destination without having to copy it from a
temporary location

e.g.

       proc inline int SUM(int A, int B)

               return A + B

       endproc

       int        X, Y, Z

       X = SUM(Y, Z)

generates the same optimised code as:

       X = Y + Z


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use




2005\09\09@125544 by Timothy Weber

face
flavicon
face
sergio masci wrote:
>
>>But using a HLL doesn't immediately bloat the code past 1K; it just generally
>>adds a bit of overhead for each function.
>
> Not necessarily.

No, just generally.  I meant across many languages and compilers - code
generators and optimizers vary in quality.  Many aren't as good as
yours.  :)
--
Timothy J. Weber
http://www.lightlink.com/tjweber

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