Colin has graciously let me use this space to tell you about the things I’m doing to get ready for my presentation at NVIDIA’s GPU Technology Conference on May 15th. So, hello! …

Now, wait a minute, you’re probably wondering; what are we doing talking about GPUs? Isn’t this an embedded software blog? And indeed it is; the systems that I’m working on come from an odd corner of the world called High Performance Embedded Computing. The control system in an unmanned aircraft might be equivalent to a multi-server compute cluster, but it has size, weight, and power constraints just like any other embedded system. The challenge is to get as much computational performance as you can within those constraints — and, when you really need a lot of compute power, the performance-per-watt numbers on a GPU start to look very attractive.

However, making GPUs work in an embedded system is really difficult on a lot of levels. In absolute terms, they draw a lot of power — about 70W for a typical embedded chip. Our friends at GE Intelligent Platforms, Curtiss Wright, and Mercury Computer have been building hardware that can support GPUs and keep them cool in a flight-capable system, and some of the tricks they’ve used are pretty intense. (Ask Curtiss-Wright about their air-flow-through technology!) But even when you have the hardware in place, that’s not the end of the problems; GPUs are also notoriously difficult to program if you want to get maximum performance.

That’s where we come in, with Mentor’s Sourcery VSIPL++ library. It’s a library for writing embedded high-performance signal- and image-processing applications, designed so that the user can write simple code that’s hardware-independent, and we can make their code go fast on many different hardware platforms. We’ve been working on the GPU version for several years now, but we also have versions for a couple of different CPUs, and we did a version for IBM’s Cell/B.E. processor back when that was the hot new thing. Like the hardware builders, we’ve put a lot of tricks into making this actually work and work well, and that’s part of what I’m going to be presenting. I’m trying to pack a lot of technical detail into the presentation, so people can really learn from what we’ve done and use some of the same tricks in their own code.

No presentation is complete without a good demo, though, and that’s the other part of what I’m hurrying to get finished by the 15th. We have a sample Synthetic Aperture Radar computation that we’ve been using as a benchmark for a number of years, and a brand new NVIDIA GTX-680 GPU in our lab that we just got last week (it’s the first card they’ve released with the new “Kepler” architecture), and so we’ll be presenting some benchmark numbers on how well that works. I’ve only run a couple of quick things so far, but the first look indicates that it’s substantially faster than the last-generation Tesla C2050 card we’ve been using.

So, if you’re in the San Jose, California area on the 15th, come by the conference and listen to the presentation, or stop by our booth. I’d be very glad to see you! And, if you can’t make it, come back here in a couple of weeks and I’ll be posting a recap of the presentation for the loyal readers here.

Apart from embedded software, I have a number of interests and one of those is photography. This is certainly a market which has been shaken by a disruptive technology and is set to get another shake up very soon …

For over 100 years, film photography was the dominant still [and moving] image recording technology. Then, about 15 years ago, digital began to get a grip and there has been no stopping it. I bought my first “serious” digital camera in 2003 and have not used a roll of film since. I doubt whether I ever will do so again. As my main interest is taking pictures, rather than necessarily the underlying technology, the immediacy of digital just makes my photography more fun.

I guess this was a disruptive technology, as it’s introduction changed all the rules. A typical film camera consisted of: optics + mechanics + a bit of electronics [maybe]. On the other hand a digital camera is: optics + a lot of electronics + a bit of mechanics [perhaps]. [You might argue that a DSLR has a lot of mechanics, but I regard these machines as over-priced throw-backs, which are unlikely to persist in their current form.]

It is this mix of technologies that has changed and caused the disruption. The result is that many camera companies have disappeared – most notably Kodak. Some have adapted and continued to flourish – notably Canon and Nikon – though they do cling on to conventional DSLR technology and have not enthusiastically embraced the “mirrorless” approach. Other companies – and I have in mind Sony and Panasonic as examples – who are strong in electronics, have risen to be market leaders.

But I think that it is all going to change again. Most keen [digital] photographers like to shoot in RAW. This means that their cameras simply store the data that comes out of the sensor, instead of processing the image to be a JPEG. This means that the photographer has much more latitude later to make decisions and fix problems on the computer. This level of image control is very appealing. I guess that they are very much on a par with film workers in the darkroom.

At the fundamental level, things have not changed. The camera focuses an image onto something, which stores it for later reproduction. The photographer chose what was in focus – he selected the focal plane [where the image is totally sharp] and the depth of field [the distance in front and behind the focal plane that is also acceptably sharp]. This is the way that all cameras work and have worked since they were first invented. Until now …

Enter the light ray camera. This type of device – which is on the market now – works on a different principle. It simply gathers and stores a digital representation of all the light rays that enter the lens. Later, this can be uploaded to the computer and the photographer can then locate the focal plane and decide on the depth of field. I see it as a kind of “RAW on steroids”.

As I see it, this has the potential to change photography for ever. I want one of these cameras. Now. Currently, they only ship to the US, but I can easily get around this. The only thing that is stopping me is that the special image processing software, that lets you set the focus parameters and convert to a conventional format, is only available on Mac and I do not have one [and have no other immediate incentive to get one]. Apparently a Windows version is coming. I will wait.

If you have tried a light field camera, please comment or email and share your impressions.

I began to wonder why there are not many devices that work in the same way …

As the router allocates IP addresses to computers and other devices on the network, it seems unsurprising that it allocates one to itself. To take advantage of the resulting functionality, it is only a matter of entering this IP address into the browser on any other device on the network. There is then the opportunity to view and adjust lots of settings and parameters for the broadband connection.

So, how does this work? Essentially, the router contains a Web server. This term makes me think of a big powerful computer, which has access to an enormous database of Web pages that it can serve up to a remote computer on demand. It would be more accurate to call it an HTTP server, as essentially all it does is respond to this standard protocol in order to deliver data which looks very like a website. The developers of the router software could very easily construct quite a sophisticated user interface using just a few HTML files.

Although I know that my router is far from unique in operating in this way, it does seem to me that there is enormous potential for other equipment to be given this capability. For example, my hard disc video recorder could be easily controlled from my iPhone or iPad, without the manufacturer needing to create and maintain an app. The same might go for my heating system [program and adjust from anywhere in the house or elsewhere even] or my digital camera [deal with settings, view pictures etc.] or many other electronic devices.

Although you might think of a Web server as being large, an HTTP server which is optimized for embedded applications is quite small in terms of code size and requires very little memory in which to store the HTML pages, which can probably be compressed anyway. Most embedded operating systems have networking options and an HTTP server is a common option – like our Nucleus product, for example.

The possibilities for this kind of UI are really only limited by the designer’s imagination.

I would like to share some more of those ideas with you today …

I have 3 tips to pass on in this posting. The first 2 are about starting the presentation and the third is concerned with answering questions.

As I mentioned in my last posting, I feel very strongly that the presenter should always be in complete control of what is displayed on the screen, as any spurious display will only be a distraction and you want your audience’s complete attention. So, tip #1 is: do not turn on the projector [or, at least, do not connect the laptop to the projector] until you have your first slide on display. This might take place long before you plan to start talking. A useful, informative title slide on the screen is welcoming and reassuring ["I am in the right room!"] to attendees as they arrive.

In order to get to this point efficiently, you need to be able to easily access your presentation. A good way to do that is to remember the 3 golden rules of successful presentation: prepare, prepare, prepare. In this case, the simplest preparation is to apply tip #2: put a shortcut to the presentation file [or a copy of the file, if you prefer] on the desktop, where you can get to it instantly after booting up. To make a shortcut, just open the folder where your PPT file is stored and drag the file to the desktop using the right mouse button. When you drop the file on the desktop, you will get a menu and one of the options is to create a shortcut. You can use a tip from my last posting – right click and choose “Show” – to have your slides on display in no time.

Many presenters are nervous about getting questions from the audience, as they are afraid that they will not have the answer. This is a reasonable fear, up to a point, as it is an opportunity for you, as the presenter, to lose control, which is not good. This can generally be avoided in a simple way by just saying “I am sorry. I do not know.” and moving on. I actually fear not getting questions, as audience interaction is almost always wholly beneficial. It is important to think about how you are going to behave while answering a question.

Remember, slides are just an aid to conveying a message. They can also be a distraction, if the content is not relevant to what you are saying, as may be the case during a Q&A interlude. This can also happen if you go “off piste” and discuss a side issue for which you do not have supporting slides. To avoid a distracting backdrop to your question answering, you could just turn off the projector [or break the connection], but there is a much simpler way, which is to apply tip #3: hit the B or W key. This will cause the screen to be blanked to black or white respectively. Hitting any key restores the slide display. Black is the best choice, as a bright white screen is rather distracting, but, in a badly lit room, white may be better.

Hopefully these tips will be helpful in your next presentation. There will be more …

The first edition of “The Works” was my second book, which I talked about here, so I guess this is my third. Although the experience of holding the first copy of my first book will never be repeated, it is very satisfying to see the completion of such a project.

I will be straight with you. This book is not a complete rewrite. What I did was go through all the articles, updating some, as appropriate, removing a few that seemed less relevant and adding some new ones that cover contemporary topics, like open source software. I hope that the book will continue to be of value to those who are new to embedded software, teachers of the subject and engineers who need background information on a variety of embedded software topics.

If you would like a copy, it is available now [in the US; very soon elsewhere] directly from the publishers or from your favorite online book seller. The ISBN is 0124158226. As with the first edition, all the royalties will be paid to a worthwhile charity.

When I was at ESC the other week, I made the mistake of not hiding or looking frantically busy at some point. The result was that I got interviewed by some guys from ARM about the Stella robot that we were showing and the Nucleus RTOS that powers her. It has now been posted on YouTube.

I do not think that this one is going to go viral …

Many years ago, there was no standard time and all anyone could use was the position of the Sun. When church clocks became commonplace, the hourly chime was the source of all temporal knowledge. In recent years, we have turned to technology, but that brings its challenges …

When I was a kid, the common way to check the exact time was to telephone the “speaking clock”. This was a low cost call, which would be answered by a recording of a lady with a rather plummy accent, who would say something like “At the third stroke, it will be three fifteen precisely” and this would be followed by three “pips” [short bleeps]. It seems that you can still access it in the UK by dialing 123 or you can hear a modern version of it here. I am sure that a similar service was available in most countries.

For the last three decades, my reference point for timekeeping would be the radio. The BBC broadcasts “the pips” at the top of the hour and these are well known to be accurate. But lately, this has become unreliable because of advancing technology. Digital radio seems to have what appears to be a fixed lag, so the pips are always late. If, indeed, the lag is predictable, then I do not understand why the BBC have not simply compensated for it when they broadcast the time signal. Nowadays, I listen to the radio mainly through the Internet and here there is a non-deterministic lag. I have noticed that, if I play the same radio station in two rooms with my Sonos system [and do not tell it to synchronize them], there can be several seconds difference between the two.

I am not really that challenged, however. I have a number of clocks that receive a radio signal [from somewhere] that keeps them adjusted correctly [and even handles the madness of daylight savings] and my phone adjusts for timezones too. It seems that young people eschewing watches have the right idea.

I am only now coming to grips with how the OSS model really works, why it is a good thing and how business can leverage it to mutual benefit …

We are used to thinking about software development as writing code. However, if we are going to build an embedded Linux system with hundreds of packages, most of the code already exists! This is the big attraction of using the operating system. Our challenge is gluing it together – which of course does require some code. But, the primary hard problems become different. For example, when something breaks, it may well not be in your code – it is in the underlying OSS. This raises some interesting questions:

• How can you figure out what is broken?
• Since nobody that works for you wrote the code, how can you fix it?
• If you can fix it, can you get the fix upstream so that you do not have to fix it again in the next release?
• What do you do if the basic trade-offs [e.g. speed vs space] made by the OSS developers are different from your needs?

These are all very valid questions, which occur all the time during deployment of OSS. Solving them costs money. This is why OSS is not free.

With lots of software, like a real time operating system [RTOS], for example, you have a “make vs buy” decision to make. You can write your own RTOS, which will have significant development and ongoing support costs, or go to a commercial supplier and purchase a product like Nucleus. Deployment of OSS gives a similar opportunity to choose between two possible approaches:

• You can develop the expertise to work with available Linux distributions etc., learn the processes for sharing your work and nurture relationships within the OSS community. This is a major investment, but it makes sense if you have an ongoing need to deploy significant amounts of OSS across numerous projects and over an indefinite time period.
• You can work with a company [like Mentor Embedded] that is well established in the OSS world and are able to offer you the support to deploy OSS for your project, without you needing to develop significant expertise. This support might include the straightforward provision of Linux distributions, tailored to your needs, along with integrated [OSS] tools and technical support, if you have queries or problems.

The choice is yours. But, however you go about it, OSS is not free.

Thanks to my colleague Mark Mitchell who provided the core ideas for this posting.

Those were interesting times and I learned a lot about the culture of an international company …

The company was very much centered on the US head office – that is where all the higher management, product experts/management and engineering teams were located. So, naturally, the satellite offices would request support or assistance with sales, marketing and customer relations. I noticed that my colleagues in Germany would commonly request a visit from senior technical guys. In France, however, they were more likely to seek help from the management team. I often wondered why there was this different emphasis.

Then I learned about meetings. I thought that I understood about meetings. A meeting is a situation in which a number of people – who may be peers, but management and “experts” may also be present – get together to discuss stuff. That was my understanding and was broadly correct, but only in the UK/US. It seems that in other countries, the culture dictates that meetings have other purposes. It is a very broad generalization, but, in Germany, a meeting is where you go to hear from the expert; in France, you get to hear from the boss.

I think that the cultural nuances are much more subtle than this, but this gives a flavor. Another aspect of meeting practice comes, I think, from the American culture: this is proactive vs reactive or “push” vs “pull”. I recall that it was very common for the US office to announce that some executive was going to visit Europe and would we please set up some customer meetings. This was, of course, completely pointless. Customers want to have meetings when they have something to discuss, not because it suits their supplier. So, therefore, we preferred the “pull” approach: set up the meeting and request the executive visit.

The result of the first approach was unsatisfactory meetings. This meant that we were less successful at attracting the execs when we needed them. But, somehow, we got by.

So, next time that you are invited to a meeting, think about what the purpose of the meeting is and what your role will be …

But, I digress. What I am interested in is the comparison of my modest PC with a supercomputer and how that rates against embedded devices …

I recall that, while a student at university, I was playing with a mathematical puzzle and enlisted the help of a supercomputer in a remote city to do my calculations. I sent off the “job” and, after a couple of days, I got a printout back saying that I had consumed my quota of 20 minutes of CPU time, but not arrived at a solution. I have often wondered just home much computing power I had had access to. Now I have an idea.

Let’s consider a typical [quite high end] embedded processor: the Zynq Cortex-A9 [ARM processor embedded in a Xilinx FPGA device]. It is a dual core device running at 800 MHz. It has a theoretical peak floating point performance [single precision] of 12.8 GFLOPS. It consumes around 1 Watt of power.

Now, compare that with a desktop PC CPU – an Intel “Ivy Bridge”. This is a quad core device running at 3.5 GHz. It has a theoretical peak floating point performance [single precision] of 224 GFLOPS. It consumes around 80 Watts of power.

So, this illustrates the wide range of performance options with modern CPUs. How does this compare with a 1980s supercomputer? Let’s consider a Cray X-MP. This was a dual core machine running at 105 MHz. It has a theoretical peak floating point performance [double precision] of 200 MFLOPS. It consumes around 60 Kilowatts of power.

Things have changed! Clearly, the description of my desktop PC is not unreasonable and maybe I need to revisit my mathematical puzzle. I guess that what I learn from this is that engineers who complain that they have not got enough CPU power for their embedded application do not know when they are well off.

Thanks to my colleague Brooks Moses for drawing my attention to these statistics.