Archive for September, 2006

Legal Limbo

Tuesday, September 26th, 2006 Nigel Jones

I don’t intend to write much about political issues, since it isn’t the purpose of this blog. However, when something arises that affects a lot of us in the high tech industry, then I’ll make an exception. The case in point today is the proposed legislation in the US Senate that attempts to codify the administration’s position on detaining terrorism suspects, interrogating them etc. I’m no lawyer, so I have to rely upon the expertise of others in understanding what the legislation is all about. In this case, I’m relying upon the testimony of Senator Patrick Leahy.

At this point, you’re probably wondering what this has to do with embedded systems. Well, have a read of this excerpt from Senator Leahy (The full text appears here). I’ll then make my point.

Today we are belatedly addressing the single most consequential provision of this much-discussed bill, a provision that can be found buried on page 81 of the proposed bill. This provision would perpetuate the indefinite detention of hundreds of individuals against whom the government has brought no charges and presented no evidence, without any recourse to justice whatsoever. That is un-American, and it is contrary to American interests.

Going forward, the bill departs even more radically from our most fundamental values. It would permit the president to detain indefinitely—even for life—any alien, whether in the United States or abroad, whether a foreign resident or a lawful permanent resident, without any meaningful opportunity for the alien to challenge his detention. The administration would not even need to assert, much less prove, that the alien was an enemy combatant; it would suffice that the alien was “awaiting [a] determination” on that issue. In other words, the bill would tell the millions of legal immigrants living in America, participating in American families, working for American businesses, and paying American taxes, that our government may at any minute pick them up and detain them indefinitely without charge, and without any access to the courts or even to military tribunals, unless and until the government determines that they are not enemy combatants. [Emphasis mine]

I’m a legal resident alien in the USA. Huge numbers of the people I know in the embedded systems field are also non-citizens of one form or another. I find this very disturbing and I suspect they will to. Now imagine if you were a talented person from overseas who was considering moving to the USA in search of a better life. Maybe it’s just me, but I suspect that a lot of those folks would eschew the USA and opt for other pastures. If that happens, then the life blood of the high tech industry in general (and embedded systems in particular) will dry up.

Am I being overly dramatic here? Quite possibly. However, if you were, for instance, a muslim contemplating a move to the USA, what would you do if this indeed becomes the law of the land?


Reset Reason

Saturday, September 23rd, 2006 Nigel Jones

The title of this post is rather ambiguous and can be read several different ways. This is no accident as it reflects the ambiguity that I see concerning the most fundamental event in an embedded system’s life – reset. Being a consultant, I get to write a lot of my own code. I also get to read a lot of other people’s code and the one area where I almost never see much thought given is to handling the various causes of a system reset. In the bad old days, you were reset and that was all you knew. Today, however, modern processors contain registers that may be interrogated to determine the cause of the last reset. For example, an AVR processor I am working with lists the following possible causes:
Power Up
Brown Out
External Reset

Based on my experience, I’d say that 99% of the embedded systems out there don’t care what caused their last reset. This strikes me as foolhardy. At the very least, an embedded system should keep track of the number of times it has taken a watchdog reset for post deployment quality analysis (you do do this don’t you?). Furthermore, a portable system should take remedial action if it underwent a brown out reset – presumably indicating that the battery is failing. As for a JTAG reset, could this be construed as an attempt by someone to determine the inner workings of your system – and if so what should you do about it?

I have been involved in systems where support for handling the different interrupt sources has been added as an afterthought – and it shows. As a result, I’ve come to the conclusion that the only way to handle this is to think about it from the start, and to know up front what needs to be done for each of the different reset sources. If you go through this exercise, you’ll find that your startup code becomes a lot more sophisticated. You’ll also find that you’ve designed a better system – which after all is the point.


Datasheet Errors

Friday, September 22nd, 2006 Nigel Jones

As someone that also designs hardware for a living, I spend a lot of time reading data sheets. Recently I have had to deal with a rash of data sheet errors. I’m not talking about minor errors. I’m talking about colossal, fundamental errors, whereby the device simply does not do what the data sheet describes. How can this be I ask myself? I think there are two possibilities:

1. I have to wonder whether this is one of the consequences of IC design being moved off-shore such that the designers of the IC are non English speakers, and consequently are in no position to proof-read the data sheet.

2. With new ICs being introduced at a phenomenal rate, is this simply the case that so much information is being generated that these sorts of errors are to be expected hence forth?

I’m inclined to think that option 2 is the more likely. If this is the case, why aren’t the engineers that are designing these parts insisting upon reading the data sheet before it’s published? The next thing you know, the software industry will expect its customers to find their bugs for them…


Five Nines Reliability or POTS versus VOIP

Friday, September 22nd, 2006 Nigel Jones

My ISP has just recovered from a system wide crash that resulted in a 20 hour outage. Notwithstanding that it resulted in loss of email etc, it also resulted in the loss of my VOIP service. After decades of POTS , the telephone companies have rung out all the bugs and we have a service that just works. By contrast, the internet (and by extension VOIP) is still in it’s infancy, such that the availability is simply pitiful by POTS standards.

It would be interesting to know what percentage of internet outages are caused by software failures!


Encrypted email and NDAs

Tuesday, September 19th, 2006 Nigel Jones

Being a consultant, I do business with a lot of different companies – nearly all of which require a Non-Disclosure Agreement (NDA) to be executed. Most of these NDA’s require me to protect the company’s intellectual property as if it was my own. So far so good. Once the NDA has been executed however, I’m continually amazed at how often I get sent schematics, source code, technical documents, projects plans etc as attachments to unencrypted email. I send out my digital signature (public key) on all my emails, so it’s a trivial step for people to send me encrypted mail. It makes me wonder how many trade secrets are being lost every year simply because the default is to send out email as plain text. Shouldn’t your company insist that all email be encrypted and that all external vendors provide them with public keys before any sensitive communication take place?