Archive for the ‘Uncategorized’ Category

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?

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!

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…


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.


Embedded systems boot times

Monday, October 26th, 2009 Nigel Jones

Last week saw the release of Windows 7. Looking over the new features, the one that struck me the most was the effort that Microsoft had put into decreasing the boot time of the OS. If the reports are to be believed, then Windows 7 boots dramatically faster than its predecessors – to which I say about time! Almost contemporaneously with the Windows 7 announcement I took delivery of a beautiful new Tektronix Mixed Signal Oscilloscope. It’s a model MSO2024 with four analog channels, 16 digital channels, a huge color display, great user interface, tremendous connectivity etc. Despite all this, I’m disappointed with the product. The reason – it takes 75 seconds to boot. Now if I’m preparing a major debug session, then this 75 seconds isn’t terrible. However, most of the time when I turn a scope on, I’m interested in just getting a quick look at a signal – and then I’m done. For this usage mode, the MSO2024 fails miserably.

Now I’d like to think that this scope is an oddball in this respect – but it isn’t. I purchased a big fancy flat screen TV last year – and it takes about 5 seconds to boot from standby (i.e. powered, yet ‘off’) to being ‘on’. Maybe it’s my type A personality, but I find that time unacceptable (in part because I’m never sure if I’ve actually turned the thing on, or whether the remote control signal missed its mark).

Now without a doubt, these long boot times are a function of large processors, huge memories, complex RTOS’s etc. However, I also think they are equally a result of poor design by the engineers (or maybe poor specification by the marketing department).

Thus the bottom line – think about the boot time of your product. Your end user will appreciate you doing so.

Incidentally, if there is sufficient interest, I may publish some tips on how to minimize boot times in future blog postings.


Reader feedback

Sunday, September 13th, 2009 Nigel Jones

If I’m to believe the numbers for this blog, I’m getting both a large number of page views per day as well as a significant number of readers coming back on a regular basis to see what I have to say. While the page view statistics are nice, I actually value the returning reader far more than I do the one-time visitor who drops in looking for a solution to a particular problem. Thus I find myself in a bit of a quandary. While the page view statistics give me a very good idea about what is driving first time visitors to this site, I really don’t have a clue as to why anyone actually bothers to come back, or indeed what they are hoping to see on their next visit. Thus if you are a regular reader I’d be obliged if you could give me some feedback on what you (dis)like about this blog, and perhaps more importantly – what you’d like me to address in future postings. Feel free to use the comment section or to email me if you’d prefer your thoughts to be private. Thanks! Home

Debugging with cell phones

Saturday, July 11th, 2009 Nigel Jones

If you walk in the door of a doctor’s office here in the USA, the chances are there will be a sign admonishing you to turn off your phone. Most people probably assume this has something to do with common courtesy – and I’m sure that’s part of it. However the larger issue is the fact that cell phone transmissions can play havoc with an EKG.

What’s this got to do with embedded systems? Well yesterday I was trying to debug a piece of code – only to be faced with a debug environment that would just randomly crash, taking down the debugger with it. Naturally my first thought was that I had made a stupid coding error. However, after some serious head scratching I noticed that I had placed my Blackberry down next to the ribbon cable leading from the emulator to the target. If a cell phone can mess up an EKG being performed 10 m away, I’m sure it can really do a number on a high speed debugger interface when it’s a mere 10 cm away. In short, not a smart idea. Removal of the cell phone solved the problem.

What’s the lesson here? Well the obvious one is that cell phones have no business in a laboratory. However, upon reflection there is a larger issue. I take great effort to make my code as hygienic as possible. However, my workbench is usually a disaster area with extraneous stuff all over the place. Maybe it’s time I literally cleaned my act up in this department. If I had I’d have noticed the phone a lot sooner.