Would a PIC suit me better than an AVR?

Question

This is probably a question that only I can answer, but I fear I lack the experience. It is relatively harder to source Atmel parts where I live. For instance, I recently had to order the AT Mega 128L from the USA because it was not available in my country (the 5V version Mega 128 was there, though). The PICs are more widely available. They also seem to be cheaper here.

Up until now, I've only had experience with just AVRs. Not because I prefer them or anything but I was/am a beginner and all the research I did led me to think that it doesn't really matter when you're starting out. So I bought a AVR ISP MKII and Mega 168 and learned to program on it.

The other thing that really attracts me towards the PICs is a massively cheaper debugger. The PICKit 3, it seems, has in-circuit-debugging and the AVR ISP MKII that I own does not. I suppose I could purchase the AVR Dragon, but I have heard it has its own problems. And the AVR JTAG ICE MKII is $300. I was considering this, but then I started thinking about purchasing a PICKit 3.

Finally, I feel that I should know how to program on both platforms. I think this would be quite beneficial because I would be able to choose a controller best suited for the job.

My main requirements, at the moment, are really only that it should have

1. SPI
2. 3.3V input voltage
3. In-Circuit-Debugging
4. 50 or so I/O pins (I think 64-pin TQFP would be great)

Would you folks tend to agree that a PIC would be better option because of the availability, price and the cheaper debugger?

Answer 1

Yes you need to write good code intended to be maintainable and to make it easy to catch mistakes before you run it. However, debugging is still a reality. In a small embedded system, you can't put print statements all over the place. There is no place to print to. You also can't test the code in the same language on a PC because on a microcontroller you're always dealing with the hardware which isn't present on the PC.

A simulator on a PC can be a useful tool, but the more your code has to interact with external hardware, the less useful it becomes. Eventually you need to test and debug on the real target hardware. People telling you they don't do that or that you don't need it obviously haven't done a lot of real microcontroller projects.

I don't know the Atmel debugging environment, so can't compare it to that of PICs. Both processor families can do what you want. If one of them has better availability in your area or you think the setup has a cost advantage, go for it. You're certainly not going to go wrong with PICs, although that's probably true of any of the major microcontroller lines.

Answer 2

These questions can light the blue touch paper, so I'll try and avoid the PIC vs Atmel stuff :-)

There is so little in it performance wise (despite what some might say) to make it irrelevant unless you are pushing things to their limits (in which case you usually just go up a level family wise anyway) or need e.g. a specific peripheral that is only provided by one of the two.
With the requirements you give this should not be an issue.

So the only thing left is price and availability. If PICs are cheaper and more readily available in your locality then I'd say it's an easy choice. I think generally the price/availability/longevity of PICs is a little better than Atmel anyway (just based on what I hear, not personal experience with Atmel so I may be quite mistaken)

Of course there is no reason why you can't use both in the long run. It's good to have experience with a variety of parts, but be sure to weigh up the cost/benefits of the extra effort involved.

Answer 3

Don't rely too much on the debugger, it's crutch that leads to laziness.

I have all the tools needed to do in-circuit debugging with AVR (AVR JTAG ICE MKII) and I never use it, what I do in stead is:

1. Understand the code
2. Take care to write robust code.
3. Write code that can be tested (and debugged using much better debuggers) on the PC in a framework that supplies much better data than available in the real actual application.
4. Insert print statements that are #ifdef'ed out if something goes wrong.

The advantages of really understanding the code and writing testable code cannot be overestimated or replaced by a debugger.

In fact, I rarely use a debugger even on platforms where it's very, very easy (IDEA for Java or perl for instance)

Firing up a debugger can fool you into fixing the symptoms of problems rather than understanding what's going on.

Sure, debuggers have their uses, but don't let it steer you around, it's not that important compared to your skills, part availability, software availability or community support.

That being said, if there are other reasons for using a PIC, go for it, it's important to get experience with a wide variety of parts.