Featured Engineer

Interview with Colin Walls

Colin Walls

Colin Walls - Embedded Software Technologist at Mentor Graphics Corporation

How did you get into electronics/ engineering and when did you start?

In my early teens, electronics was a hobby, sparked when I picked up a copy of Practical Wireless magazine. In those days, most designs were discrete transistors or even vacuum tubes. ICs were starting to appear, but only small- and some medium-scale integration, of course. Later, at university, I was exposed to computers and was fascinated by software. A career in embedded software was almost inevitable.

Over the 25 years you have been working in the electronics industry, what are some of your most memorable projects?

I think that all my early embedded software projects will stick in my memory. At that time, the technology was new and there were no rules or procedures. Typically there was a CPU and an empty ROM awaiting the creation of software from scratch to give it life. We learned how to create real time systems, how to do debugging and when to point the finger at the hardware. I would readily confess nostalgia for those “pioneering” days [as some people, not I, term them].

What are your favorite software tools that you use?

The Mentor Embedded products, of course!

What is the hardest/trickiest bug you have ever fixed?

Quite early in my career, I was working on a multi-core system. It was actually two discrete 16-bit CPUs of different architectures, but conceptually, that is still multi-core. The processors were linked by a couple of Kilobytes of shared memory. We knew that we needed to create a protocol and buffers etc. – that was easy enough. But we found an odd bug. The transferred data was getting scrambled. We quickly spotted that the bytes of each word were being swapped. It took us a while to figure out why: each CPU had its own idea of byte order, and they differed. Years later, I would learn the terms “big endian” and “little endian” to describe the two approaches. The key lesson we learned was that it is good practice to define a clean interface across any communications medium. Thus we only needed to include a byte swap in one place to make the problem disappear.

What is on your bookshelf?

I have a large collection of vintage books on software and electronics, including at least one on every major programming language I think. Only recently, I took down my copy of the original “K&R” when pondering the sad news of the death of Dennis Ritchie. I have the first three editions of Bjarne Stroustrup’s original book on C++, all signed by the author. Among contemporary books, there is always room on my shelves for such authors as Jean J. Labrosse and Jack Ganssle.

Can you tell us about the books and technical article you have written?

In 1986, I wrote what was probably the first book on embedded software – “Programming Dedicated Microprocessors”. The term “embedded” had yet to be coined. This book was inspired by a bright computer science graduate, who was assigned to my team. He knew everything about software, but was clueless about working close to the hardware. His endless questions resulted in my writing the book and, thus, fulfilling a life-long ambition. Since them I have written countless articles, a large number of which were gathered together for my second book, a mere 20 years later: “Embedded Software: The Works” [www.EmbeddedSoftwareWorks.com]. This has sold quite well and I am currently working on the second, updated edition which should appear in early 2012.

Do you publish a blog?

Yes. In early 2009, Mentor Graphics started a program of blog publication and I was invited to contribute on the topic of Embedded Software. From the beginning, I was advised to mix “on topic” material with other posts on matters that have caught my interest. This strategy, along with regular [usually two posts per week] updates, seems to get good results. Of all the Mentor individually contributed blogs, mine is consistently the most well read. The blog can be found at blogs.mentor.com/colinwalls

What are you currently working on?

I have a number of projects on the go, of course. Apart from working on a new edition of my book, as I mentioned, I am working on a program to provide basis training in embedded software to hardware specialists. Details are sketchy at this time, but keep an eye on my blog for news.

Can you tell us about some of the new projects Mentor is working on?

I am not allowed to talk about what is in the pipeline – we have strict rules about only announcing products that are actually ready to sell. However, of late, the most interesting strategic move was the incorporation of CodeSourcery into the Embedded Software Division. These guys are experts in open source tools and enable us to offer customers a true alternative way to deploy an embedded software development environment. I was genuinely surprised to learn about how challenging it could be to obtain, configure and deploy an embedded software development toolchain based on open source [primarily GNU] technology. We are now in a strong position to alleviate that challenge for our customers. Along with new products, based on open source technology, we are in good shape to offer our customers all the necessary backup services they need to be successful.

Another interesting recent development is the addition of power management facilities to the Nucleus RTOS. Nowadays, developers are trying to create designs that have the lowest possible power consumption and software has an increasingly important role to play.

What direction do you see your business heading in the next few years?

Market research suggests that, before long, the majority of embedded systems will be implemented using multi-core processors. There are numerous ways in which multi-core systems can be configured, which raise a wide selection of challenges. So far, we have released an SMP version of the Nucleus RTOS, which addresses applications where multiple identical cores are being used to simply provide more processing horsepower. For AMP systems, where cores are not necessarily the same, we recognize that many developers will want to implement a variety of different operating systems in one design. To that end we released an implementation of the MCAPI standard for inter-core communication and also declared a variant of this – OpenMCAPI – open source.

With multi-core systems, the biggest challenge is probably debugging and verification. The award-winning Sourcery System Analyzer is a tool designed to help by providing uniquely flexible ways to observe the behavior of systems with multiple cores and, perhaps, multiple OSes. This is certainly an area of technology that will see a lot of attention in the coming months and years.

What challenges do you foresee in our industry?

One of the biggest changes that has occurred in recent years is the emergence of open source solutions for embedded developers. This is largely manifest as GNU tools and the Linux operating system. This trend leads to two problems:

First, there is the perception that open source software is “free”. This is far from the case. All software takes development effort. Very little of that effort for open software is actually provided for free; the largest proportion is funded – largely by semiconductor vendors. Furthermore, using software in a professional context means that configuration, deployment and ongoing support are all endeavors that need to be paid for.

Second, there is a big temptation among many developers to use open source for everything. In the case of operating systems, that means using Linux for every design. This is not a wise approach. Whilst Linux is a good solution for many embedded applications, it is not a universal panacea. Using Linux inappropriately could be an expensive and damaging mistake. This is a topic that I have addressed at a number of conferences lately.

Can you tell us about your interests out of work?

I like reading/writing, food/drink/cooking, but my #1 hobby is photography, which enables me to express my artistic side.

Previous Spotlights

Click Here