4
\$\begingroup\$

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?

\$\endgroup\$
  • 1
    \$\begingroup\$ Religious war here. My name is Kenny and I am a PIC. \$\endgroup\$ – kenny Sep 23 '11 at 11:28
  • \$\begingroup\$ @kenny Me too.... \$\endgroup\$ – Majenko Sep 23 '11 at 12:09
  • 1
    \$\begingroup\$ You mention it's hard to get certain parts where you live, but you haven't said where that is. FILL IN YOUR PROFILE. Remember, that a courtesy to us, it's not for you. \$\endgroup\$ – Olin Lathrop Sep 23 '11 at 12:24
  • \$\begingroup\$ I'm from Pakistan, Olin. Just filled in the profile. \$\endgroup\$ – Saad Sep 23 '11 at 12:36
  • 1
    \$\begingroup\$ @Saad - Briefly, ICE can do full traces and break on data conditions without affecting the target processor, while ICD requires software breakpoints. Full question here, hoping that the community can help. I've used ICEs, but nothing where a picKIT wouldn't have done the job. \$\endgroup\$ – Kevin Vermeer Sep 23 '11 at 18:10
4
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ That is exactly what I was thinking. I'm developing a board in which I'm going to be controlling around 64 or so lines (not directly from the MCU, of course), talking to a CPLD and SD Card via SPI and then processing the data for the actual application. I think debugging would help me massively - far more than print statements. A lot of people like to embed an RS232 interface in their application so they can "see" whats going on, but I think a debugger is a better choice. \$\endgroup\$ – Saad Sep 23 '11 at 12:28
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ It really isn't my intention to start up a PIC vs Atmel war here. I'm quite sick of that, to be honest, and I tried my best to word my question in such a way that it doesn't start a forum war. :) I agree regarding performance and that is why I didn't even mention it. What is your take on the debugger for PICs? \$\endgroup\$ – Saad Sep 23 '11 at 12:42
  • \$\begingroup\$ Your question was worded fine, I was just kidding :-) I mainly use an ICD3 now, which is excellent. The PicKit3 is quite similar I believe, although it had a bit of teething trouble I think that's all sorted now. I have a PicKit2 also, which was well worth the price - it has a serial port emulator, e.g. PIC UART to PC, and also as a simple Logic analyser. \$\endgroup\$ – Oli Glaser Sep 23 '11 at 19:44
-2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Here's an outline for a lecture I attended which supports your view: andrewsterian.com/424/Lecture23.pdf - He has a very similar priority/debugging set, a notable addition is having someone else look at the code. \$\endgroup\$ – Kevin Vermeer Sep 23 '11 at 17:18
  • 1
    \$\begingroup\$ @Kevin: The lecture you linked to sounds like he's got a axe to grind. He dismisses debugging as difficult and time consuming to set up but provides no support for that argument. He even advises using printf and blinking LEDs first because they are supposedly easier. I don't know what debuggers he has used, but that's completely backwards from my experience. Plugging a RealIce into the USB and the other end to the ICSP port on your board, is pretty quick and simple, certainly faster than soldering LEDs on and modifying the code to drive them appropriately. \$\endgroup\$ – Olin Lathrop Sep 23 '11 at 17:57
  • \$\begingroup\$ Well, in my experience there are two kinds of code, the complicated algorithms that need a proper unit testing framework and proper debuggers, those get tested on the host, not the target, the other kind of code is the simple hardware manipulation code which can only run on the MCU and is frequently timing sensitive, so you can't break in with a debugger and get a useful result. \$\endgroup\$ – dren.dk Sep 23 '11 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.