embedded software boot camp

H1-b visas and Economics 101

May 1st, 2007 by Nigel Jones

USA Today has a story today about how 123,000 applications were received within 48 hours of this years H1-b visa lottery being opened on April 1. Given that there are 65,000 visas granted a year, there seems to be a large mismatch between supply and demand. Although the USA Today story talks about some of the sexy positions (Supermodels! Complete with alluring photograph!), the reality is that most of these applications are for the fields of electronics and computing, including embedded systems.

This topic interests me, in part because I came to the USA on a similar visa program (actually an E2 – but that’s another story).

Anyway, whenever this topic comes up, there’s normally some quote from a high tech industry executive explaining that they simply can’t get enough talented folks – and hence the need for the program. Whenever, I see this argument advanced, I’m always struck by the failure of the journalist to ask a basic question – namely “What would you do if the program was eliminated?” I suspect that the honest executive would answer:

  1. Lobby like mad to get it reinstated
  2. Pay what I had to to get the talent I needed
  3. Look to put the work where the talent is (i.e. ship it overseas).

Whereas I could probably discourse for a long time on answer 1, it’s the other two that intrigue me.

The reality today is that enrollment in engineering is dropping. If one was to look at non first / second generation immigrant enrollment, I’d hazard a guess that it has all but collapsed. This is despite the fact that engineering in general (and electrical engineering in particular) is always one of the highest paying jobs upon graduation, with recent graduates earning about $65K, versus the $30K earned by your typical liberal arts major. So, what would happen if these salaries doubled? Would this be enough to attract more home grown talent in to the industry? Economics 101 would suggest that if you raise the salaries high enough then supply will rise to meet the demand. The question is, by how much would salaries have to rise?

Economics 101 also suggests that as the price of a good / service rises, it is highly likely that the consumer will look for a substitute. At present this works by bringing folks in on the H1-b program. If the program was eliminated, then I assume that this would be done by shipping more work overseas.

I guess this leads me to the point of my post. The USA prides itself on its capitalist approach – and the belief that the free market is inherently the best way to solve all (OK, most) problems. As a result, Americans normally abhor government interference in the market place. But isn’t that exactly what is being done here?

If we genuinely believe in the free market, then the H1-b visa program should be abolished. Salaries would rise for engineers, more students would study engineering – and more work would go overseas. I have no idea whether the end result would be beneficial to engineers or not. It would however be ideologically consistent.

The economic purists might argue that the H1-b visa should be scrapped in the sense that anyone who wished to work here should be allowed to do so. I agree that this is also ideologically consistent. However, the reality is that the USA limits immigration in all fields. Thus to be truly consistent this would require the USA to do the same for all jobs – which is tantamount to saying there are no limits on immigration – something which isn’t going to happen.

Home

Crest factor, Square roots & neat algorithms

April 21st, 2007 by Nigel Jones

I’ve been programming microcontrollers for about 25 years now – and can count on one hand the number of times I’ve needed to compute the square root of an integer. This curious drought came to an end recently when I needed to compute the Crest Factor of the line voltage being used to power a product I was designing. (For the uninitiated / rusty out there, Crest Factor is the ratio of the Peak : RMS of a waveform. For example, A sine wave has a CF of 1.414, whereas a square wave has a CF of 1.000).

Why, you might ask, do I need to compute the CF? Well, the product uses triacs to control a number of AC loads. If the system is inadvertently powered from a square wave inverter, or just a really lousy generator, then the triacs will not self-commutate – and I could never turn off the loads. Thus to prevent this unfortunate scenario, I need to know how good (i.e. sinusoidal) the line voltage is. The CF is a direct figure of merit that allows me to make this decision.

Evidently, the computation of CF requires one to compute an RMS voltage, which in turn requires one to calculate the square root of a number. For various reasons, I need to compute the CF on a mains cycle by cycle basis – and I’m using a 7.37 MHz ATmega CPU. Thus, the computational efficiency of the algorithm is important.

Now IAR has a nifty little algorithm that computes an approximate square root. See http://supp.iar.com/Support/?note=18180&from=search+result

However, this gets blown away by the algorithm described by Crenshaw in his wonderful book: Math Toolkit for Real-Time Programming, CMP Books. ISBN 1-929629-09-5.

The code in his book is for computing the square root of a 32 bit unsigned integer. I adapted it to give the square root of a 16 bit integer. Here’s the code:

static inline uint8_t friden_sqrt16(uint16_t val)
{
 uint16_t rem = 0;
 uint16_t root = 0;
 uint8_t i;

 for(i = 0; i < 8; i++)
 {
  root <<= 1;
  rem = ((rem << 2) + (val >> 14));
  val <<= 2;
  root++;
  if (root <= rem)
  {
   rem -=root;
   root++;
  }
  else
  {
   root--;
  }
 }
 return (uint8_t)(root >> 1);
}

This will compute the exact square root of a 16 bit integer in about 268 clock cycles on an AVR – i.e. in about 33 microseconds on an 8 MHz AVR processor.

To Crenshaw’s point – don’t just blindly use the code, but endeavor to understand how it works. Only then will you see it for what it truly is – a work of art. Thanks Jack.

Home

Tool Upgrades

March 31st, 2007 by Nigel Jones

As a consultant that does hardware , firmware & software work for my clients, I use a large array of software tools – half a dozen compilers, schematic capture and PCB layout tools, analysis tools as well as the usual gaggle of productivity tools that non-engineers also use. Throw in the tools for running a business and my PC is a regular treasure trove of applications.

With all these tools, the number of upgrades / updates is starting to get out of hand. Every week, it seems I’m updating a major application. The most common scenario seems to be:

  1. I haven’t used a tool in a month or so.
  2. I invoke it – and it tells me that an update is available. Often the mandate is ‘mandatory’ or at least ‘recommended’.
  3. I accept the update.
  4. The download proceeds. Some of them are simply enormous (Ever downloaded the Xilinx Webpack IDE?)
  5. The patch then proceeds. The time to execute the patch is often considerable.
  6. Finally – the dreaded ‘You must restart your computer’ directive. I’ve a dozen applications open, web pages marked, manuals at strategic places – and now I have to close them all down.

Having gone through all this rigmarole, I can finally start using the tool. Of course by now, I just want to ‘get on with it’, and so the release notes often get cursory attention. Inevitably, if I do read the release notes then I find the upgrade is completely useless to me (e.g. support for a new device that I’m not using). If I don’t read the release notes then of course there’s this really neat feature that’s been added that really makes life easier – and I don’t find out about it until weeks later.

Well – enough complaining. Do I have any suggestions? I think so. I’d like tool vendors to realize that their tool isn’t the only one in the box – and that many of us use it on a less than daily basis. With this perspective, I’d like the tool vendors to do the following:

  1. Download upgrades in the background. A lot of applications already do this – they all should.
  2. Inform me there is an update available when I close the tool rather than open it. That way I can allow the update to occur while I’m off doing productive work elsewhere.
  3. Do everything you can to avoid requiring the user to re-boot their computer.
  4. Limit updates to one or two a year. I know product managers want folks on support contracts to feel they are getting their money’s worth – but this only works if my life revolves around that tool – and it doesn’t!

Home

Wanted – a new performance metric

December 14th, 2006 by Nigel Jones

In the bad old days, the two major performance concerns in CPU selection were whether a CPU had enough processing power and memory to get the job done. Although these are still issues, it’s a rare problem that requires more bandwidth and memory than can be provided by the CPU vendors.

By contrast, today, well over half of the systems I work on are battery powered, and so I find the major question I have when designing an embedded system is ‘how long will the battery last?’ If you can work this out from studying the data sheets of the various CPU vendors then you’re a better engineer than me.

Thus to solve this problem, I propose that we introduce a new performance metric – namely how much energy (Joules) does it take to perform a set of standard tasks. Rather than the usual bunch of quasi meaningful benchmarks, I’d like to see benchmarks such as:

  1. How much energy does it take to receive and transmit one thousand characters through an asynchronous serial port running at 38400 baud?
  2. How much energy does it take to perform a task switch using a standard RTOS such as uCOS-II?
  3. How much energy does it take to perform one thousand A2D conversions?
  4. How much energy does it take to execute a 64 tap FIR filter?

With metrics such as these, the task of choosing the best CPU (and compiler for that matter) would be made much easier. I’m quite prepared to let off the hook those vendors that aren’t selling CPUs aimed at the portable market. For the other guys (TI, Atmel, ARM etc) it’s time to step up to the wattmeter and be measured.

Home

Wanted – .TEC password

December 8th, 2006 by Nigel Jones

It’s time for my first rant – you have been warned!

I recently bought a new computer, complete with a gorgeous 24″ flat panel display. The flat panel supports a speaker bar – which I also bought. The installation instructions for the speaker bar are quite straightforward – align the tabs on the bar with the holes in the display, and push until the bar clicks in to place.

Well, on my system, there’s no click. The display seems to lack the spring loaded latch necessary for this to work.

I have now had four email exchanges with ‘technical support’. The first didn’t read what I wrote, the second told me that this was a big issue and would take several days to resolve, the third did a keyword search on ‘speaker bar’ and sent me a bunch of useless links, and the fourth decided that my problem was that I didn’t understand the installation instructions – and so sent me another copy of them.

In short, I’ve been treated like a moron.

I suspect that some / many / most people that contact technical support lack, ahem, technical acumen. Well, if you are reading this blog, the chances are you are not such a person. I also suspect that you’ve had a similar experience – which got me to thinking. What I need is a .TEC password. Just as Microsoft’s .NET password lets you manage your net identities, a .TEC password would tell the recipient that they are dealing with someone who really can, at the very least, align two tabs with their mating holes and push – and so should be treated accordingly.

Thanks for listening.

Home