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

The mother of camparisions. Over the past few months the project I have been working on projects which have demanded a fast processor and a compiler that is full featured and generates tight code. So I have changed platforms, and changed tool suites like there was no tommorow, here are my conclusions.

Pic16Fxxx: Slow. If you want to make blinking lights it is fine

Pic18Fxxx: If you are gonna use a pic you might as well start using the Pic18 instead, they are just as cheap as the Pic16 and generally offer better bang for the buck. The biggest Plus is that you can download a 60 day trial of the MPLABS C18 compiler for free to work with Pic18.

AVR: Great platform, more features than PIC, and faster. Huge amount of language support for this platform. Better value than the PIC.

PicBasic: Slow, generates big code, very user friendly actually painfully user friendly as it tends to castrate many of the hardware features on the PIC.

Proteus: better than Picbasic, but not by far. Castration issues as with Picbasic.

Hitech C for PIC: Complicated, you would think you are doing a PHD thesis when you read the 500 page manual. This is the exact opposite of Picbasic or Proteus, userfriendlyness was the last thing they considered. If you have time it should be great. DOes not seem to have much support for special hardware features.

MPLABS C18: C compiler for PIC18 platform. Integrates into MPLAB IDE, great manual, great interface, generate efficient code, not overly complex to use and has great support for special hardware. By far the best compiler for the PIC, i switched to Pic18 just because of this great compiler and the fact that it is free.

PIC ASM: started writing my own math 16 bit routines and gave up, good for blinking lights but bad for anything complex.

Summary: If you must choose PIC then you would be a fool not to choose the PIC18 and the free MPLABS c18 compiler. If you must use PIC16 then use whatever language you want, since you probally aren't after fast or efficient code, just something that is easy and quick.

If you are looking to learn something new and want a better platform, Use AVR. However I have found that the language suites are not as well designed as that of the PIC, really the best language suite I have found for embedded systems is MPLABS C18. If they had a compiler of similar caliber and a manual as concise as that of MPLABS C18 there would really be no reason to use the PIC platform at all.

So if you want the best hardware then choose AVR but if you are after quality compilers then choose PIC. I am not putting Picbasic or proteus down, they are actually very easy to use and generally do most jobs well, but there are definite limits to what you can do with those tools. And there are definte limits to what the pic can do.

Well just want add one more thing.

I a both thankful and regretful for starting out using the PIC. Thankful that it was easy to get into and regretful that I invested so much time and oney on a platform that is not as great as other platforms. If I had started out with AVR maybe I would of given up doing anything in ebedded systems because of the learning curve and just done everything using discrete electronics.

Good comparison, but there are many issues to consider beyond simple "what is the fastest" or "best bang for buck". There's always going to be a "new kid on the block", but you might not want to hastily jump into bed with him!

I beg to differ, I love jumping into beds with new kids. AVR is not a new kid on the block really since they were avialable in the early to mid 90s. You are right that there are alot of other factors involved. Pic does have excellent datasheets, i perfer the pic datasheets over atmel datasheets. Also pics are very tough, it can take a good wack of voltage or force and still perform, they also offer very high flash write cycles. Pics also have lots of goodies for motor control and offer an abundance of A/D ports. My biggest biggest dissapointment is that I have yet to find a pic that can offer PWM of 2 or more frequencies, i really needed that bad.

But honestly everywhere I go people ask why I use the PIC and not the AVR or ARM platform, the simple truth was that I already bought a programmer, bought many PICS, bought several language suites, invested so much time in them that I really did not have the luxury of switching. I can not tell you how many times i had to comprimise my design objectives because the PIC just could not cut the mustard. Most comprimises worked out very well, but sometimes I wonder what I would of achieved with a more powerful platform.

Not all is peaches and cream with the AVR, the documentation of the C language suites is very bad, and to top it off I really knew very little about object oriented C to begin with. For a harware platform that is so good the software sure is nasty. Man imagine what I could do if I had a great toolsuite with excellent documentation and a good forum. Yup the grass is always greener on the other side.

The biggest thing I want to get across to anyone reading this is to try out different platforms and different languages.

Umm after re-reading my post I think I came across as "dissing" PICBASIC and its like. Picbasic really is a decent language, I am so comfortable coding in Picbasic and in all truthfullness with a bit more work picbasic would be "all that and a bag of chips". A much more detailed manual would be nice, the manual is something like 300 pages, it sound like alot but the font and the spacing is huge. If the authors put alot more detail in there then that would be fantastic. How bout a book mark tab in the PDF manual? Better support for hardware is another thing that is required, for example most PWM hardware on PICs support 10 bit but PICbasic only offers 8 bit, or how bout having a real interrupt routine. Maybe getting rid of some routines that are a bit odd, the RC time thing was odd, and what is the real difference between SERIN and SERIN 2?

Hi, Toalan

I've found Mel very very kind in her answer ...

you just have to know what you really want ... should be difficult !!!

... for your charge pump: this is simply called a capacitor ...

Alain

Whats this "Proteus" compiler? I know they offer support for a number of compilers including AVR's and VSM's but I have never seen there compiler.

Do you have a URL?

Quote:

---

Originally Posted by Acetronics

Hi, Toalan

I've found Mel very very kind in her answer ...

you just have to know what you really want ... should be difficult !!!

... for your charge pump: this is simply called a capacitor ...

Alain

---

Capacitor wont' work in my case, i already considered it.

Quote:

---

Originally Posted by OXIMBIT

Whats this "Proteus" compiler? I know they offer support for a number of compilers including AVR's and VSM's but I have never seen there compiler.

Do you have a URL?

---

As i know, Proteus is not a compiler but a simulator. Voted to be one of the best on the market... as i heard....

here's the link http://www.labcenter.co.uk/

Proteus is a compiler as well, they have a whole package that includes compiler. simulator and Spice modelling, they might even have a PCB layout program in there as well.

MPLABS IDE has a very good simulator as well and it is free. The best simulator I have used so far is PICsimulator, but it does not have PWM support and has support for only a limited number of PICs.

toalan

I think you are thinking about Proton which is by Crownhill and comes with Proteus as well as 6 VSM boards to sim your code on.

I have used Proteus for both PCB design and Siming and IMHO there is nothing that comes within a mile of it. You can sim up to I think 5 pic's all running basic code, single stepping, and interacting to each other.

Proteus VSM is not a compiler.

http://www.labcenter.co.uk/

List of the supported third party compilers:
http://www.labcenter.co.uk/index.htm.../compilers.htm

* * *

Proton Development Suite

http://www.picbasic.org/proton_development_suite.php
http://www.labcenter.co.uk/index.htm.../crownhill.htm

If you buy the Proton Development Suite you get:

The full version of the Crownhill Associates Proton+ Compiler
and a limited version of the Labcenter Proteus VSM.

The Proton version of Proteus is included in the price of the Development Suite, however,
if you want to change the design of the Virtual Hardware Boards or design your own circuit
for a project, you will need to purchase a licence for the full Proteus VSM software.

Six Virtual Hardware Boards for simulation are included in the
Proton Development Suite:

12F675 PICmicro® (8-pin 14bit core)
16F628A PICmicro® (18-pin 14bit core)
16F877 PICmicro® (40-pin 14bit core) with Alphanumeric LCD
16F877 PICmicro® (40-pin 14bit core) with Graphic LCD
18F452 PICmicro® (40-pin 16bit core) with Alphanumeric LCD
18F452 PICmicro® (40-pin 16bit core) with Graphic LCD

Prices for the full Proteus VSM software:

Commercial price list:
http://www.labcenter.co.uk/index.htm...ng/cprices.htm

VSM Educational price list:
http://www.labcenter.co.uk/index.htm...eprices_uk.htm

* * *

Complete and official info here:

http://www.labcenter.co.uk/
http://www.picbasic.org/index.php


Luciano

... AVR are faster than PIC but it all really depends on ur project... for me 10 mips is good enuff...


i ahvent tried AVR yet... enjoying the PICs.. they solve most of my project needs from counting pulses.. controlling a robot with 3 infrared detectors, 1 sonar ranging, and 2 stepper motors..

current project is a UAV using a raptor heli r/c.. controlling 4 servos + 1 gyro.. a polaroid sonar 6500 ... waiting for a AHRS frm project owner.. and everythings seems to be well... and many other smaller projects..

i would love to strt with ARM but not really sure of AVR.. and one things for sure pbp is so powerful to me... u can say tht a c compiler is better or just coding in assembly.. thts true

i'm currently doing my industrial training under a lecturer and he force me to use CCS C.. not much different only thing is extra typing for me.. i compared some codes compiled performing the same task and usually they are about the same size between pbp and c.

it all really depends how good u r and how comfortable u r at using the specific compiler.

anyway toalan why dnt u try coding reading a 4x4 matrix keypad using ccs c. compare the lines of C codes u need to type and also compare the size of the hex file created frm pbp and ccs. wat i'm tryign to proof is tht it really all depends on the programmer on twisting and turning to get to the destination as fast as possible and in good shape. it takes me lots of line to code in c because i'm just not good in c programming.

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.

- 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

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

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.

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.

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.

AVR info and forum:

http://www.avrfreaks.net

too much experimenting for me with different MCUs, time for me to do some work. Thanks Luc for pointing me to DSPic, I will look into them once I get frustrated enough with AVR.

Update:

I started to use IAR embedded workbench a month ago and everything is super fast without many glitches. The same program written in MC18 ported over to atmel using IAR embedded workbench is, I would say based on my experience, about 50% faster.

IAR is really good stuff, tougher to digest than most languages, I would say it is onpar with HiTech C. Documentation is not all that good, but the language is solid and there are many optimization options which really makes things faster and smaller.

My fav language is still MPLAB's MC18 but IAR is not too far behind it. PICBasic is still the easiest language I ever used though, with Proton in a close second.

I still do use PicBasic once in a while to do smaller projects as coding for it is easy and the software USART not needing a MAX232 chip is just utter brilliance.