Maker Pro
Maker Pro

best compiler

S

Sergio Masci

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


Wouter van Ooijen

Hi Wouter,

I have corrected the typos in you post for you (free of charge)
certainly, but only for MOST valueS of 'best'. which the OP left
unspecified....

;-)



Regards
Sergio Masci

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



..
 
A

Alexander

Jan 1, 1970
0
Sergio 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
 
S

Sergio Masci

Jan 1, 1970
0
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


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



..
 
S

Sergio Masci

Jan 1, 1970
0
[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

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
 
S

Scott Seidman

Jan 1, 1970
0
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.
 
S

Sergio Masci

Jan 1, 1970
0
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.

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
Plus, I'd be using a compiler with a fairly large user base, which
implies more stability and more sources of support.

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:
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 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



..
 
S

Scott Seidman

Jan 1, 1970
0
A larger user base does not imply more stability.

"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.
 
A

Alexander

Jan 1, 1970
0
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
 
S

Scott Seidman

Jan 1, 1970
0
What about IIC and SPI???

Alexander

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

Alexander

Jan 1, 1970
0
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???
 
S

Scott Seidman

Jan 1, 1970
0
And is it Interrupt driven or is it with those damn delays???

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

Sergio Masci

Jan 1, 1970
0
"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.

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

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
 
S

Scott Seidman

Jan 1, 1970
0
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.
 
S

Sergio Masci

Jan 1, 1970
0
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.

Hi Scott,

I applaud your attitude.
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.

This is an excelent reason to choose a tool: it does what YOU want. I
cannot fault you here.
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.

My only concern was the initial implication that BASIC is bad for embedded
systems without regard for the specific XCSB dialect itself.

Although I agree with your reasoning for YOU using CCS, I feel I should
point out that as XCSB grows in popularity, users will add powerful
libraries of their own which will rival those written by a compiler
writer. The point is that the XCSB compiler allows users to write very
efficient code and they do not need to rely on the compiler writer to
provide the functionality they require (unlike many other compilers out
there). Take a look at Colin Barnards "one wire" library for XCSB for
example http://www.btech-online.co.uk/onewire.html

So whereas CCS is right for you XCSB will be right for others.


Regards
Sergio Masci

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



..
 
Top