Micks Distractions

First up: This has been discussed to death on forums and mail groups for a long time. The winner is that there isn’t one. The basic truth is that either will do for you a good job. However, I found subtle differences between the two that made me end up going with Atmel. Here’s why:

What I needed.

• Speed I had a project in mind that required an MCU. I tend to be a fairly impatient fellow, and like to see something happening pretty quickly. So I wanted something that gave me a quick development cycle. I also wanted to do C and not futz around in assembler, (until I had to optimize stuff).
• Short learning curve I’m an old hand at the classic CPUs 6502, 8051, 8086. However, that was some time ago, and I’ve been out of it for long time. I needed to come up to speed again pretty quick. So I needed something easy on the head.
• Low cost I didn’t want to have to start shelling out mega bucks for compilers, assemblers, yadda, yadda, yadda. I certainly don’t have one of those money trees in my backyard.
• Linux support What’s this new fangled windows thingy anyway? Give me a shell anyday.

Microchip PIC

PROs:

• History: PICs have been around for a long time. Consequently, there’s a huge amount of info on the web, code people have written, forums. You name it. A good resource is the piclist.
• Boot loader: I know, not all PICs are capable of this. But some are, and this is definitely a PRO. As long as a PIC is self programming, you can chuck a boot loader on it, to ease the pain of development. You don’t need a programmer once you have a boot loader present. You simply program via the UART port of the PIC.
• Options: This is the big thing I like about PICs. There are a huge amount of options with PICs. A lot more than with the AVRs. You have PICs that can do RF, PWM, timers, A2D, interrupts, USB, I2C, counters, etc. I know a lot of these appear in the AVRs as well, but the PICs have a lot more of these options contained on each PIC. The PICs, for example, have the ability to interrupt on pin level changes, (basically a glorified interrupt), but the AVRs only seem to have 2 interrupt inputs.
• Current drive: The PICs ara really good at driving current. You can whack an LED straight off an output without issue.
• Power saving: The power saving modes are nice on the PICs. You have more options than the AVRs. On some PICs you can slowly downgrade the internal clock, so you could have some code that would increase the clock rate on demand. Also, a lot of PICs can run at 3v, more than the AVRs.

CONs:

• Pages: PICs cannot address all of it’s I/O space. So, to be able to get to all of it’s registers and memory it has to page. It does this with a special register that is present across all pages, (of course it has to be). This means that yo
  u have to ensure that you are referencing the correct page. This makes it especially difficult when you have interrupts going off, as you have to ensure that the old page is set when exiting the ISR or just ensure the correct page is set for every memory/register access. To make matters worse, there’s no way of telling what page you’re on! Also, if you want to move data around you are forced to use
  the ‘w’ register. Why?
• Interrupts: PICs do not have vectored interrupts. This essentially means that your code will be more complex. Once an interrupt has fired, you need to poll all the registers to find out who the hell made the noise. This slows things down a LOT.
• Clock cycles: The execution cycle of a PIC is 1/4 that of the oscillator speed. This means a PIC running with a 20MHz clock will execute instructions every 200nS, (roughly), and not every 50nS. This one bit me in the bum when I started out.
• Instruction set: The PICs have a very small instruction set, (35 instructions). They don’t have any compare, (huh?), they have very simple branching instructions. Gawd, the hassle you have to go through just to compare two numbers takes 4 instructions, and bearing in mind that each instruction is 1/4 clock frequency it all adds up.
• Locking: You can lock a PIC chip to avoid people downloading your code. However, once done that’s it! You can’t change it, game over, throw it out if you got it wrong.

Atmel AVR

PROs:

• No pages: Flat memory model, aaaaah. Nice! No stupid paging. Also, registers are mapped into memory as well, and they can be addressed as memory or register. Basically it’s all there – something compilers really like.
• Interrupts: Nice vectored interrupts. On some of the more recent AVRs, you can also select where you want to place your vectors!
• Clock cycles: 1 clock cycle is 1 instruction cycle.
• Instruction set: You have 130 instructions at your disposal. Also, combined with the memory layout aspect, it gives the MCU the feel of a real CPU. Also, (for me that is), the instruction set just felt a lot more complete.
• Boot loader: The boot loader support is much better in the AVRs. You can specify a boot section and lock it out to avoid overwriting. PICs have the lock ability, but you have to specify the whole darn memory.
• Locking: You can lock an AVR, then erase it, and restart over. Nothing is foreever in AVR land.

CONs:

• Options: There aren’t as many options with AVRs as there are with PICs. It just seems that Microchip have a good sense of which pins to provide what functions. It seems to fit naturally. I found that with my project wanting to use a particular function on a pin, but couldn’t because it was being used for something else. I didn’t seem to have that issue with the PICs.
• Power: Not as many options with power management than you have with the PICs. You have less scaling options with the internal clock, and most AVRs demand 5v. [UPDATE]: Although now you can get AVRs that can go down to 2.5v!
• Price: Overall the AVRs are more pricey than the PICs, although this seems to be changing.

The summary

From the above info my decision was pretty much a no-brainer.

• The AVRs had the feel of a real risc CPU – real memory space, registers, interrupt vectors, 1 instruction per clock cycle.
• I could code up in C, and optimize in assembler.
• Pretty much no restrictions on code space, where to put things, and other bizarre things to confuse matters.
• The boot loader support is really cool.

However, the things I didn’t like with the AVRs:

• Price – A bit more expensive.
• Less pin options – Microchip are much better at function placement on pins.
• All the other CONs I could live with.

No related posts.