Home > No Category > The meaning of ESC

The meaning of ESC

Friday, October 9, 2009 Leave a comment Go to comments

Some wistful thinking, as a break from blogging about SKC++.

I spent the last two days at the ESC in Farnborough, UK. Would that be:

  1. Embedded Systems Conference, or
  2. Embedded System Complication, or
  3. Embedded System Confusion?

Or all three?

I went to 1, experienced 2 and came away suffering from 3.

Like the PC industry, the embedded world seems to be rushing headlong into mind-boggling (and, for the most part, mindless) complexity. Now that Moore’s Law has hit the buffers, because transistors have to have more than a few atoms in them in order to function and because electrons can travel only so far in a nanosecond, we apparently can no longer do enough quickly enough in one chip, so we have “multicore”. And immediately we have a new and exciting challenge: how to program the beasts. The problem is not that we sometimes need multiple processors in a system; we really are trying to do cleverer things, these days, in our embedded work. Rather, things are getting out of hand because of the accelerating syndrome of software bloat and faster, more complex hardware, arising from the commercial pressures from within these separate disciplines.

It seems perfectly reasonable to me to have two processors in a middling embedded system:

  • One to run the lean-and-mean really real-time code which does the real work.
  • One to run the not really real-time Linux to take advantage of all that built-in TCP/IP and HTTP stuff we tend to use these days to communicate with the system.

A simple serial link is all we need for the intercommunication between these two chips or, indeed, cores on a single chip.

But, of course, it would be cheaper, wouldn’t it, if we did it all with one processor using some clever multiplexing software. Let’s call that “virtualization”. Now there’s a name for it, there’s also a commercial opportunity. But the commercial opportunists need to make the virtualization software generic and therefore rather heavyweight. It needs some heavyweight processing power to match. In walk the eager hardware vendors with multicore chips featuring symmetric multiprocessing – they need to be generic, too. This gives the virtualization guys a bit of a headache, but they get over it, adapting their software and finally getting it to work. It’s bigger now, of course, so it needs lots of that expensive multi-port memory to run in.

So what started out as two fairly simple processors and a serial link has turned into a large, complicated virtualization package running on at least two processors sharing at least one bus and communicating with and through multi-port memory with the aid of hardware semaphores, etc., etc. Cheaper? I don’t think so. More effective? Probably not. More reliable? Extremely doubtful. Unnecessarily complicated? Certainly.

Lamentably, this is a trend we’re probably going to have to get used to. Not so, the following one, I hope:

In one of the Q&A sessions some people were extolling the supposed virtues of Java in embedded systems. Not for games to run on mobile ‘phones but for real programming, down on the hardware. So to do that you must bypass the virtual machine and presumably add nasty things like pointers back into the language. And you really have to get rid of garbage collection – not only because of bypassing the virtual machine, which does it, but also to introduce some degree of determinism into the system. Am I being naïve, or has the language by then more or less reverted to C++, whence it came?

For all this, I enjoyed the show. It’s nice to get out, sometimes.

Rant over. Normal service resumes on Monday.

Advertisements
Categories: No Category
  1. Friday, October 9, 2009 at 23:02

    Multiple processors; a simple serial link – did I hear someone at the back mutter, “Transputer”…

    Surely not!

  2. Peter Bushell
    Friday, October 9, 2009 at 23:27

    I heard that, too, but I never got involved with the transputer, so can’t comment further on that.

    I do remember Intel’s first attempt at symmetric multiprocessing, though: the so-called 432. There was to be a two-dimensional array of busses with a chip at each crosspoint. Unfortunately, maximum performance occurred with just four chips, on a single bus. Anything more complicated and a disproportionate amount of time got sucked into the interprocessor communication. So they abandoned it. Maybe the new products work better.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: