I am interested in programming languages in general and particularly as they apply to embedded systems programming. The most popular programming language for embedded continues to be C. Clearly it offers the capabilities and facilities that most developers need today, but what comes next?

I think we can get some ideas by looking at the genealogy of C – where it comes from and how it relates to other languages … (more…)

Like most people nowadays, I have a selection of electronic devices that have become part of the fabric of my life. I have certain expectations: I want a device to do what it is supposed to do. I want it to be easy to use. I am after reliability. I want it to consume the minimum amount of power – either to conserve battery life or to simply be environmentally friendly. Lastly, I want the device to be available and ready to use when I want it.

As such devices are generally embedded systems, my requirements are generally met [or not!] by the software. It is the last of my criteria, and the influence that software might have on it, that I find particularly interesting…

There are a selection of factors that can affect the availability and readiness of a device. Obviously, it has to be affordable and compatible with the rest of my world. For a portable device, its power consumption affects availability, as a dead battery can be something of a show stopper. But a really key parameter is start up time. How fast a device starts up can have a significant effect upon its usability.

(more…)

The Agile methodology has been talked about for some years. To be frank, I have given the matter very little attention – I just had a basic idea of what it was all about. I suppose I had a feeling that the approach was rather chaotic and disorganized, which is at odds with my view of what programming should be like. However, I attended a talk at a conference a while ago which changed my mind. The presenter was, in essence, trying to sell some project management tools that support the Agile methodology. But he also described the philosophy in terms that I could appreciate. I realized that what was being proposed was very similar to the approach that I have espoused for many years … (more…)

At the heart of a real time operating system (RTOS) is the kernel, which is comprised of the task scheduler and a bunch of services that are available for application programs. Control of the scheduler and access to these services is by means of the kernel’s application program interface (API). APIs differ from one RTOS to another (although there are some standards, like POSIX), but there are some characteristics which are common to many. One of those similarities is the concept of blocking and non-blocking calls.

The idea is fairly straightforward. A program may make an API call to request a specific resource or service. Such a call may normally return with the required result and/or a pointer to requested resources. There may also be the possibility for an error result. But, what if the call is valid, but the resource or service cannot be provided at this time? There are two ways to make such a call, which differ in their response to this unavailability: a blocking call results in the task being suspended (put to sleep) and the task will be woken when the request can be fulfilled; a non-blocking call results in an error code being returned and the task has the option of trying the call again later.

(more…)

When I first started programming, the only language available to me was Fortran. I punched cards with my code and later received back a print-out with [mostly] error messages. I was always intrigued by being able to program a computer in such a straightforward way. I understood what assembly language or even machine code was all about, but felt that high level languages had a mystique. In due course, while still at university, I tried out any other languages that were available: BASIC, BCPL, Simula, SNOBOL 4, Algol W and I am sure there were others.

When I graduated and found myself in the “real world”, moving towards embedded programming, I found that a selection of languages was still on offer … (more…)

There is a good, albeit rather general, rule that applies to the management of a successful business: focus on what you do well, then do it better than everyone else. There are numerous examples of how companies have been very successful by following this approach.

But the world of embedded software is commonly an exception … (more…)

Today, for a change, instead of discussing some embedded software technology, I would like to put forward a concept for a product. It is an embedded system, which I believe could sell in high volumes. Maybe someone reading this blog would like to develop it. I am happy to waive any rights to royalties on the idea so long as we have an understanding that you will use Mentor Graphics products in your design.

This product is the iBrush … (more…)

At Mentor Graphics I have to be careful what I say – I am treading on thin ice. The problem is that I am a software engineer. A very large proportion of my colleagues in the company have a hardware design background. Now I would not say that the two disciplines are at war, but there has always been a tension between hardware and software developers. In an embedded design, if something goes wrong, both parties tend to assume that the other is at fault. Worse still, if a hardware design flaw is located late in the development process, it may be too late to fix it economically, so the only option is to accommodate the problem in software. And gosh, does that rankle.

So, I tend to regard hardware as a necessary evil that allows me to run my software. It is probably no surprise, therefore, to learn that a favorite technology of mine is simulation …

(more…)

Today I am going to tell you a tale. It is a true story of events that happened long, long ago in a land far, far away. We are always told that we should learn from our experience [or from our mistakes – it depends whether you do “glass half full” or “glass half empty”]. Hopefully, there are less painful lessons to be learned from the experience of others.

Once upon a time …

There was a young engineer, who was working on software for some fairly simple, 8-bit embedded systems. Although the term “embedded” had not yet been coined. The code was written in assembly language, but it needed to be modular, scalable and maintainable. Having worked on real time computer systems, he concluded that he needed a real time, multi-tasking kernel. Having no idea of any alternative option, he was very pleased to have the opportunity to design and write a kernel. The result of a couple of weeks work was a kernel that was pre-emptive and time-sliced with a background task. It worked well for the required application and the project was completed on time. (more…)

We are bombarded with numbers all the time. They are used to inform us and to try to sell us things. But how successful can you be if you endeavor to communicate using lots of zeros?

I have a lot of trouble visualizing or conceptualizing big numbers. For example, I can easily imagine a crowd of 100 or 1000 people. But when I read that the UK population has reached 61 million, I just cannot picture all those faces. The world population is heading for 7 billion, which I find totally impossible to imagine. The same problem occurs with money. I can just about visualize a pile of banknotes representing the value of my house, but the national debt is just lots of digits in a row.

I am not alone in my difficulty. I think most people suffer “number blindness” to some extent. I guess the extreme case is a rumored tribe in South America who have no real concept of numbers. Counting for them is “one”, “two”, “lots”.

(more…)