If you are on a path to doing very large projects you want to use the AVR -- it has more of a 'big processor' feel to it, it works better with C than a PIC, and there are free C compilers available.
If all you ever need is an itty bitty sequencer, then there's no technical reason to choose an AVR over a PIC.
Generally I choose microprocessors based on the following:
Do they have the peripherals I need? Often the features that drive my decision is whether I can do what I want with the peripheral set; the core is just what happens to be attached to the peripherals.
Do the pins have enough oomph to do what I want? A circuit with a processor and a bunch of drivers is much larger than a circuit with just a processor. IIRC the PIC and the TI MPS430 excel at this.
Will it be fast enough, and big enough? You have to be careful here -- you're not just looking for raw speed and storage, but speed and storage as you're going to use them. Both the MPS430 and the AVR fit C better than the PIC does, which means that they get more out of the underlying resources than the PIC if you're using the language. If all you're going to use is assembly, then it's not so big a deal.
For small projects I look at how familiar I am with the chip, because it takes time to spin up on a new architecture. For large projects I figure that the time to learn the new architecture and the expense of new tools will be paid back in efficiency as time goes on -- this is obviously a judgment call, and one that should be made carefully.
If it's my choice, I pick the micro and ask for additional money for different micro. For example:
Arm (cost)
Avr (cost + 100)
Freescale (cost + 300)
MSP (cost + 500)
PIC (cost + 1000)
I will do any micro with the right price. Otherwise, I prefer ARM M3 Cortex nowaday, except for very low power and code density with AVR. ARM M3 is around 30% higher in power and 40% higher in code space than AVR, but a non-issue most of the time.
The LMI chips meet most of what I need, except for the relatively new company. TI and ST are coming on-line with M3 soon. Hopefully, they will have parts close enough to LMI.
You will see violently different opinions on this.
Many people learned their first micro projects on the PIC. Many learned their first projects on the AVR.
If you have experience with Z80 code, you will not have terrible difficulty picking up either architecture, but the AVR will be more familiar to you (not that it's particularly Z80-like, but it's simply less weird than PIC).
Having used both architectures, my preference is strongly for AVR.
Download the tool sets and try them. Find one you like.
Or choose an application, and work backwards from there.
I suggest you also look at SiLabs C8051F family, and their ToolSticks TI MSP 430 family, Similar toolsticks, but no 5V parts Zilog's devices, since you already have some background there eZ80, Z8F, ZENO etc Freescale, who are having a push on their smaller parts.
AVRs certainly do not, anyway. In fact, Atmel is taking the AVRs in the opposite direction, and has halved the specified source and sink current recently in some newer parts (e.g. TinyX61). Very disappointing for us! I hope they reconsider.
As most people tend to suggest AVR, (I've chozen PIC, and I'm very happy with them ;-) a few pros for PIC:
- the availability of PICs is much better ("Microchip cares about small customers")
- there are number of good C-like, Basic-like, Pascal-like, Python-like freeware compilers (e.g. JAL v2: (including a complete IDE), see
formatting link
- the number of peripherals per pin is very high on PICs
- the JAL community is very helpful in solving problems (don't know the status of AVR groups)
Maybe the most important factor, determining your choice: "what's your neighbor using ?", so you can get help with those small but nasty startup problems.
Now that bit definitely is true. The PIC achitecture sure is weird. But I've been coding PICs in assembler for what must be about 2-years now so am almost used to it.
The PIC makes you think, ALOT. But I find there are things you can do with them that are just mind boggling amazing. Being able to multiply and divide a 24-bit number in 4 clock cycles on a 40 MIPS dsPIC makes you wonder where you'd been all your life. That's like 100nanoseconds!!
But PICs sure are weird. As I have become programming them.
Also, each PIC release architecture is almost drastically different from the next, ie. 12F, 16F, 18F, 30F. Things like getting used to having the target register on the left, is now on the right. Perculiar stuff like that.
From what I've read of the specs, the dsPIC is a whole new beast, very different from its little PIC siblings. I also remember reading something about an engineer at Microchip saying that basically the dsPIC was a new core with just a bit of PIC likeliness bolted on.
YMMV as usual, but while I tend to seriously dislike the PICs, I'm quite neutral regarding the dsPIC. It seems to be a clean and nice design; I'll wait until I'll actually work with it to make up my mind.
Very unlikely. There is a general trend downwards in drive ability in uC, as they push the die sizes down. 8-10mA is now a common spec point, with PIN maxs in the region of 25mA, and package Max's 100-200mA.
If you want more on one pin, add a transistor.
If you want to push many-pin drive, you are better with CPLDs, where the package limits are 500mA @ 44pin or 1000mA @ 100pin
I second JG on his Zilog mention. They have a few different families, and quite a lot of different parts in the Z8 Encore! (XP or not) one.
The main Z8 Encore! advantages I see are:
- very low cost dev kits, including USB probes
- free development environment: asm, unlimited C compiler, debugger, ...
- good documentation
- not a choice of peripherals as wide as Microchip's, but good ones (one of Zilog's historical strengths)
- low cost chips, and they're available in DIP packages! (Someone with more experience and buying budget might give you a more accurate picture when it comes to large-quantity prices.)
I must say I'm biased, as for some reason I'm very much at home with the Zilog chips, much more than with other architectures. I like their assembly, the way they're set up and so on, but of course you would have to check for yourself, Z80 background or not.
The ZNEOs, the new 16-bitters in the family, seem to be very very nice chips. Well I say 16-bitters, but actually they're 32-bit chips with a
24-bit address space and a 16-bit bus width... Their design is clean, and although I have not yet taken the time to do a proper systematic analysis, they seem to be close to a Z80000 running in Z8000 mode (ie with the 24 bits address space, just like the Z8001). That would make them very much like the Motorola 68000, with the possibility of evolution to a full 32-bit chip. They're fairly orthogonal, and with 16 general-purpose registers they're much more modern designs than the Z80/eZ80.
As with the Z8s, some low-cost dev kits are available, with free tools. Not many parts yet though, basically variants of the same one with different Flash and RAM sizes and with/without the external bus. This core's first silicon errata also shows an annoying bug in the stack frame handling, so you might want to wait for a new revision to bypass this issue.
OK, enough of the shameless plug. Zilog, you owe me on this one. :)
If you're planning on learning and experimenting with those chips, low-cost kits and tools and DIP packages are pretty useful. But if you want to do this for a living, at any rate follow all advice given to you by the wise people of this NG: play with the tools, design you application and go backwards from there. Best way to get the right part for the job.
I suppose this wasn't an assembly source. If you choose the AVR, you better forget the ATMEL assembler and write your own. I can tolerate crippled hardware (you have to make compromises if you want small and cheap chips) but there is no reason to use a confusing assembly syntax. Here a example of a simple program, once written with the Atmel assembler and once written with a clean syntax for the AVR:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.