Archive for December, 2009

The best search terms of 2009

Thursday, December 31st, 2009 Nigel Jones

One of the interesting things about writing a blog is looking at the search terms that result in people visiting the blog. The vast majority of the search terms are quite reasonable. However, every once in a while a term pops up that brings a wry smile to my face. With that being said, I thought I’d share with you the ‘best’ search terms of the year. The terms appear below, together with my take on them…

Stay away from embedded systems
What can I say? This just conjured up images of someone’s mother telling them that going into embedded systems would be the ruin of them. It certainly was for me.

Crazy enough to use unsigned
I guess I must be a raving lunatic then.

Clueless consultant
I winced when I saw this. I’ll just note for the record that at least it wasn’t paired with my name!

Personality as it relates to programming eprom
Huh?

Why is c so complicated?
A profound question indeed. So many responses came to mind, but at the end of the day none seemed adequate…

Should I correct grammer and spelling on my blog comments?
Not withstanding the irony that ‘grammar’ is misspelled I found this to be an unintentionally revealing insight into the minds of those that blog!

With that I will say goodbye to 2009 and welcome to 2010. I hope 2010 is a better year for the industry as a whole and for my readers in particular. I’ll be back to my ‘regular’ topics with my next posting. As always, thanks for reading.

Home

Terrorist engineers

Wednesday, December 30th, 2009 Nigel Jones

From time to time I comment on things related to engineers (as opposed to engineering). This is one of those times!

Anyway as you may know, someone tried to blow an airliner out of the sky the other day. What you may not know is that once again the perpetrator was an engineer. I say ‘once again’ because as this opinion piece in the New Scientist discusses, engineers are distressingly common in terrorist groups. Anyway, I suggest you read the article as it addresses some of the ‘obvious’ reasons, while suggesting something insightful about engineers as a group. I also suggest you read the comments as many of them are very thought provoking.

My next posting will be a little more cheerful.

Hardware costs versus development costs

Thursday, December 24th, 2009 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

Automated kiosks

Monday, December 21st, 2009 Nigel Jones

I’m not prone to rants on this blog, but I think it’s time to vent about automated kiosks. Automated kiosks are popping up everywhere – airline check in, the movies, grocery stores and so on. While it’s true that as a consumer I can’t say I particularly like these beasts, I think it’s the engineer in me that’s really ticked off. Why is this you ask? Well I have several beefs with them.

Processing Speed
I am constantly amazed at how amazingly slow most of these kiosks are. It’s ridiculous the number of times I’ve stood in front of a kiosk while it tells me ‘System Processing’. What exactly does ‘System Processing’ mean – and how in the age of Gigahertz processors do I find myself having to wait for a computer to do something as pedestrian as process a credit card payment?

Lack of Parallel Processing
Why is it that these terminals do tasks sequentially that could (and should) be done in parallel? For example, at my local grocery store coupons are only printed after payment has been accepted. Why aren’t they printed on the fly?

Availability
The up time of these kiosks seems to be amazingly bad. My local cinema has three kiosks. I have never seen all three working at the same time. The availability of check-in kiosks at airports can be even worse.

So what to make of this? Well I think the reasons for these problems becomes apparent if one notices that these kiosks all have a common hardware platform (a CPU with a color flat panel display, a touch screen, a card reader and a printer) and all are trying to solve a common problem (provide an easy to use interface to a big database). I don’t know for sure, but I think it’s highly likely that most of these kiosks are running a Windows X86 platform and that they are programmed in VC++ by folks who do VC++ PC programming. In short they are computers and not embedded systems, and as such are programmed using the usual PC mindset. No wonder they are so bad!

Before I leave this topic, I’ll mention that there is one class of kiosk that for the most part doesn’t have the aforementioned problems – and that is Automated Teller Machines (ATMs). While I can find the user interface on ATMs quite maddening at times, I’ve never gone to use an ATM and found myself staring at the Windows logo. My suspicion is that when it comes to ATMs, banks worked out a long time ago that they needed robust systems with high availability and thus they they went the embedded systems approach as opposed to the PC approach. Without a doubt this is a much more expensive – but boy can I tell the difference!

Update
I went Christmas shopping today. I went to pay for car parking only to be faced with a kiosk stating ‘Printing ticket’ and a piece of paper stuck to the kiosk saying ‘Out of order’. I tracked down another kiosk and successfully paid the parking fee. When I went to exit the car park, the card reader could not read the ticket. A (human) attendant had to manually let me out…

Home

Century Post

Friday, December 18th, 2009 Nigel Jones

My blogging software tells me that this is the one hundredth posting to this blog. I have to admit I’m somewhat astonished to find that not only have I found so many things to write about, but that the list of topics seems to be growing rather than shrinking. Anyway, rather than post on my (un)usual topics, I thought I’d mark the occasion by letting regular readers know what has been going on and where stack-overflow is going in the year ahead.

First off, I suspect that many of you have noticed that my blog posting rate has dropped in the last month or so. This has been primarily because as part of running my consulting business, I have been working on a major website overhaul which has consumed a lot of my time, but which has just been completed. If you want to see some of things I get involved in, then do please take a look. I’d appreciate any feedback you may have about the site. (It’s unclear if the hosting change has completely propagated through the DNS hierarchy. If you find yourself looking at a mostly blue website, then you are on the new site).

I’d also like to mention some upcoming changes to EmbeddedGurus in general, and this blog in particular. EmbeddedGurus is becoming a popular place and so a redesign is in the works to reflect its increased stature . I suspect that Michael Barr will have more to say on this topic in the near future. With regard to stack-overflow, it’s clear to me that the blog has outgrown its current template. As such, as part of the EmbeddedGurus overhaul I’m hoping to switch to a better template which is not only more suited to my posts, but which will allow visitors to more easily find previous posts, as well as allow them to search the blog.

Finally, to those of you that answered my request for reader feedback a few months back. You have not been forgotten! I hope to incorporate as many of your suggestions as possible in 2010.

As always, thanks for reading.

Home