best compiler

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View


whats the best compiler for a pic 16f684?

Re: best compiler



Quoted text here. Click to load it


XCSB compiler!


Regards
Sergio Masci

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



.




Re: best compiler


Quoted text here. Click to load it

certainly, but only for some value of 'best'. which the OP left
unspecified....


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics

Re: best compiler



On Wed, 28 Sep 2005, Wouter van Ooijen (www.voti.nl) wrote:

Quoted text here. Click to load it

Hi Wouter,

I have corrected the typos in you post for you (free of charge)

Quoted text here. Click to load it

;-)



Regards
Sergio Masci

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



.



Re: best compiler



Quoted text here. Click to load it
Someone (person left unmentioned) who has posted the post 2 posts ago might
say that JAL is "recommended".
He also says some good things about best p.e.: "A question that contains
'best' is suspect, especially when no constraints are given"
All of this can be found in the FAQ of PICS on his homepage
http://www.voti.nl

Alexander



Re: best compiler



Quoted text here. Click to load it


Hi Alex,

"2 posts ago" might get a little confusing for some readers depending
on which news reader they use, say "Wouter" instead.

So Wouter if I say you make the "best" PIC programmer around, is "best"
still suspect here :-)

BTW I do use Wouter's Wisp628 programmer and I would recommend it.


Regards
Sergio Masci

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



.

Re: best compiler


Quoted text here. Click to load it

of course!

+ it is cheap
+ it is intelligent (no serial port compatibility issues)
+ it is ICSP
+ all code is available ( != open source)
etc

- it is not Microchip, it is supported by 'only' by a one-man shop and
a few ethousiastic users
- it is not a multi-vdd programmer
- its support for the latest chips is still lacking
- it is not 'zero parts' / 'zero cost'
- it is not a debugger
- it does not work with MPLAB
etc


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics

Re: best compiler


snipped-for-privacy@voti.nl (Wouter van Ooijen (www.voti.nl)) wrote in

Quoted text here. Click to load it

not to mention that BASIC isn't necessarily the preferred language to deal
with the low-level memory and register handling that's often required in
embedded solutions

--
Scott
Reverse name to reply

Re: best compiler



Quoted text here. Click to load it

There are many dialects of BASIC. If you are refering to PicBasic or
PicBasic Pro then you are correct. If you are refering to XCSB then you
are not.

XCSB allows you to directly access registers very efficiently without
resorting to embedded assembler

e.g.

the XCSB source:

    proc inline set_bit(uint bit_id)

        *(ubyte *)(bit_id >> 3) |= (1 << (bit_id & 3))

    endproc

    const RB2 = (PORTA << 3) + 2


    proc main()

        set_bit(RB2)

    endproc

is converted by the compiler into the following single machine code
instruction

    bsf    6,2


The XCSB compiler actually generates code which rivals that of expensive
high end PIC C compilers :-)


Regards
Sergio Masci

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




Re: best compiler



Quoted text here. Click to load it

And the CCS C-code to output a high on port B bit 2 would be
void main(){
output_high(PIN_B2);
while(1);
}

The defs for PIN_B2 are in the CCS-supplied header for the chip.  The
assembly would be much the same, and I wouldn't have to write the code
for set_bit.

Plus, I'd be using a compiler with a fairly large user base, which
implies more stability and more sources of support.

--
Scott
Reverse name to reply


Re: best compiler


Quoted text here. Click to load it
and in JAL++ it would

LED on

Stef

Re: best compiler



Quoted text here. Click to load it


Hi Stef,

I also have a function like that in XCSB

LED_on()

;-)



Regards
Sergio Masci

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



.




Re: best compiler


Quoted text here. Click to load it
hi Sergio,

that's nice !
Now there's only one step to make it simpeler ...
... measuring our brain waves ;-)

cheers,
Stef

Re: best compiler



Quoted text here. Click to load it

Actually the set_bit function is already defined as a library function
within XCSB and so too is RB2 but for me to say that

    set_bit(RB2)

generates

    bsf    6,2

would have been meaningless

Quoted text here. Click to load it

Actually one of the gripes I used to see a lot was that CCS was constantly
releasing fixes, often more than one a week, and as one bug got fixed
another would spring up. The concensus was "don't upgrade until you really
have to". A larger user base does not imply more stability. If it did,
windows would have been rock solid years ago.

Anyway what has this to do with your assertion that:

Quoted text here. Click to load it

The XCSB compiler generates very efficient code regardless of whether it
was written by the compiler writer or a user. Some compiler rely very
heavily of hand crafted assembler libraries written by the compiler
writers to overcome deficiences in the compiler's optimisation
capabilities.

BTW is the CCS "output_high" function actually a macro, and if so what
would it make of:

    int    bit;

    bit = PIN_B2;

    output_high(bit);


Regards
Sergio Masci

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



.




Re: best compiler



Quoted text here. Click to load it

"Stability" in the sense that the company has a large user base, so its
more likely to be there tomorrow.  When investing in a compiler (free or
not), this is certainly one of the inputs to the decision.

"Output_high" is listed as a built in function in the compiler
documentation.  I'm not sure it's a macro.  You might be right about it
though.  The "function" can definitely take an integer constant, but I
haven't tried it with a variable.  There are lower level functions that can  
be used that way.

How does XCSB handle UART?  That's a trouble spot for many compilers, but
as easy as a "printf" in CCS (once the clock rate and RS232 parameters are
set with two #use pragmas.  It does generate a ton of code, but not as much
as some competitors.  It gets a tad tricky when you try to change the RS232
parameters on one hardware uart.



--
Scott
Reverse name to reply
We've slightly trimmed the long signature. Click to see the full one.
Re: best compiler



Quoted text here. Click to load it

What about IIC and SPI???

Alexander



Re: best compiler



Quoted text here. Click to load it

They have a "use_i2c" pragma which is very similar.
The commands along these lines that are available:
RS232 I/O
 getc()
 putc()
 gets()
 puts()
 printf()
 kbhit()
 set_uart_speed()

I2C I/O
 i2c_start()
 i2c_stop()
 i2c_read()
 i2c_write()
 i2c_poll()

SPI 2 Wire I/O
 setup_spi()
 spi_read()
 spi_write()
 spi_data_is_in()

I haven't used the I2C or SPI command sets, but I have bit-banged both
protocols (habits die hard)

With CCS, you can get the compiler for 12-bit or 14-bit parts for $125
each, and the PIC18 compiler for $175.  You get the whole ball of wax,
including an IDE, for $425, but you don't need the IDE as the compilers
work with MPLab.  


--
Scott
Reverse name to reply


Re: best compiler



Quoted text here. Click to load it
And is it Interrupt driven or is it with those damn delays???



Re: best compiler


@news3.zwoll1.ov.home.nl:

Quoted text here. Click to load it

The hardware UART can be interrupt driven, as can SPI and I2C, on chips
that support hardware UART, SPI, and I2C.  I've used the uart, and know it
works.  The "use" statements will figure out if you mean to use hardware or
software control for a protocol (you can specify software if you have the
hardware but don't want to use it), and interrupts, for obvious reasons,
only work with the hardware.  I haven't tried this using I2C and SPI, so I
can't verify.

--
Scott
Reverse name to reply
We've slightly trimmed the long signature. Click to see the full one.
Re: best compiler



Quoted text here. Click to load it

Ok, I understand what you meant by "stability" now. Unfortunatly this
still does not follow. I learned this myself the hard way. About 12 years
ago I bought a Watcom C/C++ compiler. Excellent compiler, very well
respected and so too was the company. Large user base, good support,
exactly what you are tallking about now. Along came a company called
Powersoft, bought Watcom and very soon afterwards shutdown the compiler
section. You couldn't buy the thing even if you throw cash at them. A few
years later the compiler made its way into the open source domain where it
is now limping along.

I understand your need for some kind or criteria to base your purchase on.
It is the same for all of us. We all need to think of a way to identify
what we should be spending our hard earned cash on or what we should be
investing our time in. But size of user base is not it.

Ok, maybe picking a standard language like 'C' (so that if your tool
vendor disapears you can move to another tool vendor) is the answer. Sure
but only if you stick to the absolute standard specification of the
language and don't use any of the compiler specific extensions or
specialised libraries for which you do not have the source. I have been
programming in C for a very long time, I have used many different
compilers and I can tell you that porting an app between two compilers can
be a real nightmare.

Ok, maybe picking 'C' because you want to learn 'C'. Fine but if you
really just want to learn 'C' there are much better ways to do it than on
a tiny embedded MCU. The GNU C compiler is free and so to is the debugger.
An excellent way to learn 'C' and discover the pitfalls is to use these
tools on a PC.

Ok, maybe picking 'C' because any program you write in 'C' is portable. So
if you write a program for the PIC you can simply use it on an AVR? No
things don't work this way. You need to put a lot of effort into writing a
portable 'C' program especially for a small embedded MCU. Either you put a
lot of effort in while you are developing your program and a little when
you actually move it across, or you put a little effort in while you are
developing your program and a lot when you actually move it across. Either
way there is a lot of work involved in making the same program work on
different embedded MCUs. Programming in C does not give you instant free
portability.

Quoted text here. Click to load it

It has library functions that read from and write to the USART. Some
functions will operate on the USART directly others use FIFO buffering.
There is no "printf" in XCSB because it is incredibly expensive. If you
want to convert a 32 bit integer of floating point number to ASCII and
then send it to the USART you would use the convert function followed by
the write function. If you don't like this then you can write your own
function to combine the two operations and be happy in the knowledge that
the compiler will optimise this very well on your behalf. The real upside
to all this is that XCSB will not "busy wait" while it is printing your
formatted output, it will allow you to execute other tasks during this
process (XCSB supports multitasking natively and not as an addon library).

Besides, what you are describing (the #use pragma) is a CCS 'C' extension.
How would you port this code to (say) the HiTech 'C' compiler and get the
same functionality without adding a lot more code yourself?

When I wrote the XCSB compiler it wasn't with the intention of writing
another cheap BASIC or 'C' compiler. Or even to just create something
that was easy to implement. It was with the intention of writing
a compiler (that could be used by professionals) that would generate very
efficient code for an embedded MCU. I wanted it to be easy to use and not
have the 'C' free format pitfall. I tried to make it easy for both 'C'
and BASIC programmers to use (staying clear of clever syntax and
grammer). Unlike most C compilers XCSB uses a static run time stack. The
positions of all the variables (including function locals and
arguments) are calculated at compile time and not at run time, this means
that they can be accessed directly without the need to calculate stack
offsets at run time. The XCSB multitasking system takes all this into
account generating task safe local variable and functions. With an addon
multitasking library the user is often forced to jump through hoops to
achive the same high level of run time performance.


Regards
Sergio Masci

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


Site Timeline