best compiler

XCSB compiler!

Regards Sergio Masci

- optimising PIC compiler FREE for personal non-commercial use

.

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

Wouter van Ooijen

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

Webshop for PICs and other electronics Teacher electronics and informatics

Hi Wouter,

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

;-)

Regards Sergio Masci

- optimising PIC compiler FREE for personal non-commercial use

.

"Sergio Masci" schreef in bericht news: snipped-for-privacy@yoda.srts.co.uk...

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

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

- optimising PIC compiler FREE for personal non-commercial use

.

Shouldn't that be 'for MOST BASIC values of 'best''?

Wouter van Ooijen

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

Webshop for PICs and other electronics Teacher electronics and informatics

Not mentioning myself :) I can add that there are certainly specific values for 'best' that would make Jal the best choice. These values are obviously different from the values that would make XCBS best, and those values are both different from the values that would make SDCC best, etc etc

Wouter van Ooijen

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

Webshop for PICs and other electronics Teacher electronics and informatics

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

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

Webshop for PICs and other electronics Teacher electronics and informatics

snipped-for-privacy@voti.nl (Wouter van Ooijen

wrote in news: snipped-for-privacy@news.xsall.nl:

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

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

Sergio Masci wrote in news: snipped-for-privacy@yoda.srts.co.uk:

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

and in JAL++ it would

LED on

Stef

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

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:

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

- optimising PIC compiler FREE for personal non-commercial use

.

Sergio Masci wrote in news: snipped-for-privacy@yoda.srts.co.uk:

"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

If you are familiar with programming in C, I would recommend SourceBoost.

"Scott Seidman" schreef in bericht news:Xns96E0C011CF5A8scottseidmanmindspri@130.133.1.4...

What about IIC and SPI???

Alexander

"Alexander" wrote in news:dhjjq3$sqq$ snipped-for-privacy@news2.zwoll.ov.home.nl:

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

"Scott Seidman" schreef in bericht news:Xns96E172EC1D8ACscottseidmanmindspri@130.133.1.4...

And is it Interrupt driven or is it with those damn delays???

"Alexander" wrote in news:dhjvq3$55g$1 @news3.zwoll1.ov.home.nl:

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