Y
Your Name
- Jan 1, 1970
- 0
whats the best compiler for a pic 16f684?
whats the best compiler for a pic 16f684?
certainly, but only for some value of 'best'. which the OP left
unspecified....
Wouter van Ooijen
certainly, but only for MOST valueS of 'best'. which the OP left
unspecified....
Someone (person left unmentioned) who has posted the post 2 posts ago mightSergio Masci said:Hi Wouter,
I have corrected the typos in you post for you (free of charge)
;-)
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
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
[email protected] (Wouter van Ooijen (www.voti.nl)) wrote in
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
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
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.
BASIC isn't necessarily the preferred language to deal with the
low-level memory and register handling that's often required in embedded
solutions
A larger user base does not imply more stability.
Your said:whats the best compiler for a pic 16f684?
Scott Seidman said:"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.
What about IIC and SPI???
Alexander
And is it Interrupt driven or is it with those damn delays???Scott Seidman said: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.
And is it Interrupt driven or is it with those damn delays???
"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.
and in JAL++ it would
LED on
Stef
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?
I gave up a long time ago on trying to write MCU code that's easy to port
from family to family or compiler to compiler. "Portability" of code was
a straw pony that you associated with c compilers on MCU's, and then you
correctly showed that it just ain't the way things are.
Programs that fit in the family of chips that I tend to stick to just
don't take that long to translate over from scratch.
The functionality described is certainly expensive, but incredibly
convenient. I wouldn't be able to get the same functionality out of
Hitech without rolling up my sleeves--which is one reason why I tend not
to use Hitech. Many things like this seem to require a tad more work--
even interrupt handling, where you need to case on the interrupt flags in
Hitech, but write separate routines in CCS (though nothing prevents you
from writing your own global interrupt handler in CCS). If you need
cheaper UART capability in CCS, it can certainly be written, as well.
When I can afford to use printf, I do it, and I'm glad its there.
Don't get me wrong. I've no intention of criticizing XCSB-- I've never
used it. There are just a variety of reasons above and beyond any
functionality why I think that it wouldn't be a first (or maybe only)
compiler of choice for those just breaking into embedded systems.