Pic16 vs Pic18 vs AVR, Picbasic Vs Proteus Vs ASM Vs Hitech C Vs MPlabs c18

[toalan]

I have read that ccs c is not a good language when it comes to outputing tight code. Hitech C is supposed to compile the tightest code, I think that the MPLABS C18 would be very competitive with Hitech C for Pic18 stuff.

An ANSI C compliant compiler does not make the most sense when it comes to PICs. ANSI C was developed initially for computers and not microcontrollers. The bread and butter functions "printf/scanf" in C does not mean a whole lot when applied to Microcontrollers. But it seems that the best high level compilers for almost any MCU platform seems to be in C, by best I mean output the tightest code.

C is an odd ball when you code it for PICs, I mean who really needs structures when doing embedded stuff, but it is nice to know that if you need it you have it.

I think I made a mistake when I said proteus I think I meant proton. The cool thing about proteus is that you can sim a digital PIC with analog hardware simultaneously. But I perfer to use the Simulator in MPLABS IDE and do my analog simulations in LTSPICE, both program are free and do their respective job very well.

[Ceug2005]

- the best tool - is the tool you heave on the desk
- the best software - is the software that you learned


All the rest is imagination

- the verry best software - is the free software.
- the verry best tool - is always on the other desk

[OXIMBIT]

I have a friend who is a Pic compiler writer and when he wants to see whats the best possible code he will run it through the CCx compiler. There is nothing better for producing the tightest code.

C though as has been pointed out is not the best language for a PIC it's meant for PC's, so unless you are writing big code on say a 18 series I recon it gets in the way. I does though make you write proper code in that you have to cast the variables so you think hard about what type you need and maths can only have 3 arguments.

In the Picbasic world the only compiler that really tries hard to produce the tightest code and that's Proton

Take this code for example for 16F877

a var byte
b var byte
c var byte

if a > b then
a = c / 4
endif

Pbpro will compile it to 50 words in but in Proton it will do it in 13 words. That will match the CCxs compiler.

If you change the code to

gosub sub1
stop

sub1:
if a > b then
a = c / 4
endif
return

Pbpro takes 57 words, Proton takes 16 and I think CCxs will take about 14 or 15. as its clever enough to see that Sub is only used once and will just let it run into the routine and place the stop afterwards.

I doubt if I will ever use C as its so hard to read and while you can do any thing you want to in it you have to do it your self. The only thing I like is the code reusability in C not even Proton makes it as easy. But that's only for a short while as even that I'm going to crack with a new IDE plugin.

A number of C's have an optimiser pass again the only Basic compiler to have that is Proton.

I do agree with this though

- the best tool - is the tool you have on the desk
- the best software - is the software that you learned

[toalan]

I stumbled on a Link to a Microchip document titled something like "The Truth", it was a comparision between the PIC and the AVR. I did not read much of it but basically it showed that PICs were competitive with AVRs. It was a document written in 1997. I lost the link.

[toalan]

Learning AVR is such a B*tch, It seems that Atmel is releasing MCUs well before they have fully debugged their software and programmers. I am learning the atmega48, the atmel programmer I bought for it was not able to correctly program the atmega48 at all, i just downloaded a firmware upgrade and now finnaly I can get ISP programming for the atmega48 to work, but high speed parallel programming still will not work. Even in the release notes they did not mentioin ISP fixes for the atmega48, but atleast I can program it now.

I have been working for the past 5 days on coding PWM and again it seems that the atmel software does not correctly support atmega48 correctly, this time it is with PWM.

I just downloaded an upgrade to the atmel software suite and I am not holding my breath that PWM will work with atmeg48 this time around.

Atmel datasheets are just bad, they go into a bit more detail than PIC datasheets, but they are so long winded in the datasheets, they mention the same things over and over again.

PIC really does seem alot more well supported, and well organized; both development tools wise and datasheet wise. But the Atmel just offers so much more peripherial options for the same price as the PIC, for instance the atmega48 has, 6 PWM outputs and you can configure different frequencies for each PWM unit, that is crazy.

[mister_e]

probably this is why Microchip made DsPIC too. You should have a look on those. i actually play with a dsPIC30F6010 just for fun and learning.

[Luciano]

AVR info and forum:

http://www.avrfreaks.net