embedded software boot camp

Hardware costs versus development costs

Thursday, December 24th, 2009 by Nigel Jones

Earlier this year I posted about how to solve the problem of PIC stack overflow. As part of that article I asked the question as to why does anybody use a PIC anyway when there are superior architectures such as the AVR available? Well, various people have linked to the posting and so I get a regular stream of visitors to it, some of whom weigh in on the topic. The other day, one visitor offered as a reason for using the PIC the fact that they are cheap. Is this the case I asked myself? So I did some rough comparisons of the AVR & 8 bit PIC processors – and sure enough PIC processors are cheaper to buy. For example comparing the ATmega168P vs the PIC16F1936 (two roughly equivalent processors – the AVR has more memory and a lot more throughput, the PIC has more peripherals) I found that Digikey was selling the AVR for 2.60 per 980 and the PIC for $1.66 per 1600. A considerable difference – or is it?

Most of the products I work on have sales volumes of 1000 pieces a year, with a product life of 5 years. Thus if I chose the AVR for such a product, then my client would be paying approximately $1000 a year more for say 5 years. Applying a very modest 5% discount rate, this translates to a Net Present Value of $4,329.

This is when it gets interesting. Does the AVR’s architecture allow a programmer to be more productive? Well, clearly this is a somewhat subjective manner. However my sense is that the AVR does indeed allow greater programmer productivity. The reasons are as follows:

  1. The AVR’s architecture lends itself by design to being coded in a HLL. The PIC does not. As a result, programming the PIC in a HLL is always a challenge and one is far more likely to have to resort to assembly language – with the attendant drop in productivity.
  2. The AVR’s inherent higher processing speed means that one has to be less concerned with fine tuning code in order to get the job done. Fine tuning code can be very time consuming.
  3. The AVR’s greater code density means that one is less likely to be concerned with making the application fit in the available memory (something that can be extremely time consuming when things gets tight).
  4. The AVR’s superior interrupt structure means that interrupt handling is far easier. Again interrupts are something that can consume inordinate amounts of time when things aren’t working.

Now if one is a skilled PIC programmer and a novice on the AVR, then your experience will probably offset what I have postulated are inherent inefficiencies in the PIC architecture. However what about someone such as myself who is equally comfortable in both arenas? In this case the question becomes – how many more days will it take to code up the PIC versus the AVR and what do those days cost?

Of course if you are a salaried employee, then your salary is ‘hidden’. However when you are a consultant the cost of extra days is clearly visible to the client. In this case, if using an AVR reduces the number of development days by even a few, the cost difference between the two processors rapidly dwindles to nothing. Thus the bottom line is – I’m not sure that PICs are cheaper. However I suspect that in many organizations what counts is the BOM cost of a product – and perhaps this finally explains why PIC’s are more popular than AVR’s.

As always, I’m interested in your thoughts.
Home

Tags: , ,

12 Responses to “Hardware costs versus development costs”

  1. Gauthier says:

    There are also other ARM chips than AVR, I am not sure which are comparable to the chips you chose, but these look cheap:http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2556109&k=cortex%20m0Which part would you say matches the PIC16F1936, and how much does it cost?

  2. Anders says:

    Hi Nigel,Your post on hardware costs was very interesting, as always, and it is always refreshing to see this kind of arithmetics worked out. I think your numbers for breakeven are very valid for a small to medium sized production series. But I think it can change dramatically if the intended production volume is large or huge.We were once involved in a ABS braking project for a German automotive OEM. They chose a PIC16 over another 8-bit CPU mainly for cost reasons. Considering the production volumes for German car manufacturers in general and the number of embedded CPU:s in a modern car in particular I can really understand why they went for the PIC. But I'm not 100% sure that it was a sensible choice from a technical point of view… 🙂

  3. GregK says:

    HiNice point Nigel.Apart of topic why we do not us high level of abstraction when interfacing with hardware (using RTOS or not)? If so we can get rid of of problems with changing architecture, upgrade hardware etc. However I do not know if 8bit's PIC allow on high level abstraction, what I am reading is not. Mayby this is reason why do not use 8bit's PICs.

  4. Nigel Jones says:

    You are quite right about the volume issue Anders. If you read this post http://www.embeddedgurus.net/state-space/2009/03/insects-of-computer-world.html by Miro Samek you'll get another point of view on the PIC. As for whether the PIC was the right choice for an ABS system, my sense is that it was a poor choice.

  5. Nigel Jones says:

    Hi Greg:Hardware abstraction has been the holy grail of low level embedded systems for a long time now. My gut feel is that it isn't going to happen (at least at the 8 bit level). However, we'll probably get close if and when the Cortex architecture consumes the entire embedded space. Personally as much as I can see the economic benefits of achieving this, I rather like the different personalities (quirks) of the various processor families. So if this does come about, I think I'll be a little bit sad.

  6. Anders says:

    Miro Samek's article is very interesting and is much in line with what we see. However, I think that his observation on the sweet spot for ISAs can be extended a bit if one looks at a bigger set of benchmarks; it seems that right now the sweet spot for a general instruction set architecture is 16-bit wide fixed-width instructions with a 32-bit risc like register and memory architecture, much like the thumb and thumb-2 ISAs. But it goes almost without saying that the msp430 ISA is exceptionally well designed, especially when considering it's relative age. (The interesting thing is that Samek's article benchmarks the PIC18 which is far better suited for the C language than the older PIC16 architecture… 🙂 )

  7. Goldfish says:

    Hi Nigel,What IDE do you use to develop for AVR, and on what OS?I'm curious, because an IDE can be one of the biggest time savers in development, and I think AVR studio leaves a lot to be desired, although admittedly I haven't used it ectensively.

  8. Nigel Jones says:

    I use Embedded Workbench from IAR running on XP. I agree with your comment. For further thoughts on free tools and the like, you might want to check out this posting that I did a while back: http://www.embeddedgurus.net/stack-overflow/2008/09/low-cost-tools.html

  9. ashleigh says:

    These kind of trade-offs are rarely considered.Even on salary, engineering costs your employer (where I live, its more in the USA) $100 / HOUR.It does not take many hours to burn up the cost saving made in a cheaper part.Bean counters tend to see the cost on the BOM and get up tight about it, and ignore the cost of labour. Until a consultant is involved.All engineers should get better at looking at the cost trade-offs.In one of the designs I worked on we used a processor costing $5 more than we could have go away with, because at about 1000 pieces / year, the engineering time trade off amount to $5K. We would burn through that in labour in a week. And the cheaper part would have meant spending months more on coding.

  10. Adam says:

    I first learned on 16 series PIC’s, got sick of them and then went running to AVR’s. In a later project I needed a small chip with 2 uarts and found exactly what I needed in the PIC24 series. I’ve since converted back to the PIC24/32 series because they pack a real punch of the great peripheral options, remappable I/O pins, and larger amounts of RAM than the AVR series in small footprints. PIC is also extremely DIP friendly for easy prototyping. Every chip has its place, but don’t forget that microchip has moved well past the 16 series.

Leave a Reply