Hi everyone.
I am starting a new project and i wanted to ask your opinion on a MCU Matter.
I can work on both , Atmega & PIC.
But which one is better? Or what are the differences?
(Not including the pin count)
Read the data sheets carefully.
Leon
Tnx Leon. But operationally Wise which would be more reliable ?
I want to use the MCU as a Servo Controller, So In general which one would be best ?
Just my 2 cents: PICs have hundreds of differents devices and when I start studying them, it was too complex to choose the right device. I decided to move to AVR: everything looks simple, two families, Tiny and Mega, and very few parts in each family.
Angelo
Tnx For the Info Polux
Wrong section 
Anyway, my opinion is that AVR is better if you want to program it in high level languages like C (there are good GCC implementations) but the chip is a bit harder to use because the internal fuses and the many internal I/O registers to learn.
Use both
There is a wonderful little servo controller based on an Atmega MCU called the [[SSC-32](http://www.lynxmotion.com/Product.aspx?productID=395&CategoryID=52). This little gem does many cool things, such as group moves, timed and speed controlled moves (usable with group moves), controls up to 32 servos, and is very compact. I have two of them and they are awesome! It's very well documented and support for it is excellent. It's a [[Lynxmotion](http://www.lynxmotion.com) product. The Lynxmotion [[user forum](http://www.lynxmotion.net) is very active.fgcity:
Tnx Leon. But operationally Wise which would be more reliable ?I want to use the MCU as a Servo Controller, So In general which one would be best ?
8-Dale](http://www.lynxmotion.net)](http://www.lynxmotion.com)](http://www.lynxmotion.com/Product.aspx?productID=395&CategoryID=52)
i have a couple of those but i can’t use them cause i need to control the servos through I2C bus so i have to build my own.
Also isn’t PIC faster (for example pic16F887) ?
Atmega runs on 16Mhz but PIC on 20Mhz.
Or am i wrong here?
You could have a PIC control the SSC-32 using a serial port. You couldn then communicate with the PIC using I2C to send commands.fgcity:
i have a couple of those but i can’t use them cause i need to control the servos through I2C bus so i have to build my own.
The 18F PICs can run up to 40 MHz, and those with USB can run up to 48 MHz. The 30F dsPICs can run up to 120 MHz.fgcity:
Also isn’t PIC faster (for example pic16F887) ?
8-Dale
Tnx for the Info. It really helped. I guess i am going to do a custom design. I wanted to use the Servo Controller in the beginning but my application has to be small so the controller doesn’t fit the box
It’s true that PICs have higher clocks than AVRs but you must consider that all PIC assembler instructions take 4 clock cycles except branches that take 8 cycles, while many AVR instructions take only 1 clock cycle. So if you run a PIC and an AVR with the same frequency, the AVR is faster.
I didn’t know that. Tnx
I wish there were resources on the web that compared PICs and AVRs. (neither of which are ARMs, BTW)
Oh wait, 800K results: http://www.google.com/search?complete=1 … gle+Search
Hello fgcity,
by me AVR is ALWAYS better than PIC. Actually this a topic for a big dicussion. I’ve used PIC MCU’s a couple of times, only because I was forced to do it, and my impression was very bad. Generally spoken, the core is the thing which is not OK - the PICs are SLOW, you don’t have to implement delay loops by yourself, as the CPU does them al the time
Moreover the assembler is a complete SHIT, the paid C compiler also.
I suggest to use some real RISK machine, like AVR or MSP. Currently I’m using ARM core from Atmel, and I’m pretty happy, although my expectations were not fully covered.
I don’t know for shure why people are using PIC, but I guess because they are ralatively cheap, they have plenty of device family members on the market, very nice support - plenty of application notes are availale on the web, but for me these things are not enough.
I have heard the PIC microcontrollers being called “A triumph of marketing over engineering.”, which for those who work with these things on a day-to-day level is probably an apt description.
From a CPU standpoint, there are a few things I don’t like about the PIC in the way it works but personally, for the stuff I do, as a hobby, the PIC isn’t too bad a chip. Nice and cheap, abundant, and all sorts of features. Not to mention trying to pick up a programmer for an AVR, let alone an AVR chip itself locally is impossible.
Basically as far as I am concerned, it’s your typical camp argument…
PIC vs AVR, just like
Intel vs AMD
nVidia vs ATI
Playstation vs XBox
Ford vs Holden (got to be Australian to get that one :))
It’s all a case of personal preference, and even in this instance, the best tool for the job.
nVida owns ATI now. :)Heffo:
nVidia vs ATI
8-Dale
RISK machine lol!
Heffo:
Basically as far as I am concerned, it’s your typical camp argument…PIC vs AVR, just like
Intel vs AMD
Completely disagree.
When we talk pic here we talk mostly about midrange PIC16 or PIC18.
PIC and AVR are not compatible in any way,
occupy different processing power shelves.
My impression is that the only reason to use PIC is to pick something for 2USD like PIC16F690 and get 9 ADC channels talking via SPI to larger uC. PICs are completely outgunned by any simple ATMEGA and with todays hobbies it would be waste of time to stress PIC to the limits when for few USD more we got AVR and ARM7 or even ARM9. Today the quest is between AVR and ARM7, PIC doesnt fit here. The only reason to use PIC is availability of cheap HEX file that let you make simple switch whatever you want for free.
One of the worst nightmares of PIC is the mess with PINS-they are completely irregularly affected, if looks like some sort of drop-in replacement policy that has not been applied with an offset per chip generation.
Second problem is the absence of free gcc for midrange PIC. this kills the situation, all other modern uC accept some version of gcc, what flattens learning curve per uC.
You can say lets use upper range say PIC18 or better and have gcc, but this time code example pool is so much smaller, programmers are much less tested, popular than comparative programmers to AVR series.
All in all there is a lot of mess, and with every PIC bought I have different sort of problems programming it, lately with 16F690. I have 4 programmers, 2 aknowledge they should be able to program it, but none does. Some programmers detect and flash PIC12F675, others 12F683, others both. This is total mess in all dimsions.
It depends on the application. For a given application a PIC might be better than an AVR, for another application an AVR might be better, or an MSP430, or an ARM.
The Microchip ICD 2 programs and debugs all PICs without any problems (apart from an adapter being needed for debugging the smallest devices).
Leon