On the Road to Embedded World 2021: Episode 2

Editor’s Note: In the first blog in this series of five blogs leading up to Embedded World 2021, Episode 1, an overview of what Embedded World is was presented. In this installment, Episode 2, Randy brushes up on his C programming language. Episode 3 focuses on how using Object-Oriented Programming can reduce complexity. Episode 4 shows how the fundamental measure of good design is its ability to be reconfigured as requirements change without having to reimplement the building blocks. In the final blog, Episode 5, the ever expanding space required by operating systems is questioned and system decomposition is touched upon prior to Randall’s keynote presentation at Embedded World 2021.

My mind is on complexity and the general need to reduce it. I want my presentation to show how complexity has been addressed over the decades, remind people of how we got to where we are, and surface some simplifying techniques that are not well known.

As I said last month, I have time to pursue technical interests in my semi-retired state. Recently, in getting up to speed with a client’s embedded development tools, I had to look up some forgotten C programming language syntax, so I grabbed my copy of “The C Programming Language” by Brian Kernighan and Dennis Ritchie (K&R) to brush up. I actually have both the original version of this text and the 2nd edition.

Source: Wikipedia ( C Programming Language)

I ended up rereading their prefaces, introductions, and chapter 1, all of which brought back memories from a time when I was first learning this language. I started my career as an assembly language programmer in the late 1970s. I remember the difficulty switching my thinking to higher level concepts. Assembly language programming was like programming my HP-67 programmable calculator; you dealt directly with the machine’s registers and steps to get the correct result. I was an assembly language programmer. Writing assembly language was tedious but simple. I recall wondering if this higher level was really worth it because the only advantage it had for me at the time was the ability to switch CPUs.

My assembly language programs were used in one of nine microprocessors that were embedded in electronic musical instruments made by Baldwin Piano and Organ Company in Cincinnati, Ohio. Baldwin invented the electronic organ and was committed to cutting edge technology. Being able to generate an accompanying musical rhythm while decoding the chords the musician was playing imposed very severe real-time constraints. Predictable performance was tantamount to success. Reducing complexity was not.

Anyway, Chapter 1 in each K&R text is a tutorial. To my great satisfaction, upon entering the examples in my Linux machine exactly as they were shown in the text and upon executing the verbatim commands to compile and run those examples, everything worked exactly as described. It was such a great feeling. This text was first published in 1978. My Linux machine is running the latest version of Linux (i.e.: 5.8.14) that was released 7 October 2020 and nothing was changed to prevent my simple C program from working. Outstanding! I’m reminded of the adage, “If it ain’t broke, don’t fix it.”

With this experience, I decided to pick up and reread the introductory sections of my C++ book. This is “The C++ Programming Language, 2nd edition” by Bjarne Stroustrup published in 1991. Both my C and C++ books are written by those languages’ creators. I like reading how the inventors thought. Books written by subsequent authors might describe things clearer, having had the benefit of reading how the authors thought, but they can also be bloated with more than one really needs to learn a concept.


Stroustrup, in only 10 pages, explains the cascade of technologies that drove his goal (you could say computer scientists’ goal) with C++ and this strategy was to most fundamentally reduce the complexity of modeling real-life problems that could be solved with a computer program.

He explained that we started with Procedural Programming and then Modular Programming followed by Data Abstraction and finally Object-Oriented Programming. To review, Procedural Programming, as expressed by Stroustrup, is:

Modular Programming per Stroustrup is:

Here we see an iota to reduce complexity; that is, to hide data in modules. This is a key attribute of simplifying systems. It is the beginning of the concept of encapsulation.

Stroustrup continues with his Data Abstraction paradigm:

Data Abstraction is not without its problems according to Stroustrup. He explains that adapting the abstraction to new uses requires modifying its definition. So, once one has to modify a definition, one is unable to reuse exactly that which has been defined. This brings him to the concept of Object-Oriented Programming:

So, now, we have the concept of hierarchy and this is a core concept to reduce complexity.

What I write in these blogs is not where I am in my current research in preparing for my Embedded World keynote address. I am on a cascade of technologies of my own but the concepts that I write about in these blogs is what has shaped my thinking. I have more to share in my next episode.

About this author

Image of Randy Restle

Randall Restle has over 40 years’ experience in the electronic components industry.  He is now semi-retired and served as Digi-Key Electronics’ Vice President of Applications Engineering. His experience includes directing teams of skilled application engineers, technicians, and management personnel to develop original and unique advanced technology products.

His personal pursuits include digital signal processing, programmable logic implementation, motion control improvements, and software design.  He holds patents across multiple industries and is a Senior Member of the IEEE.  Randall holds BSEE, MS and MBA degrees from the University of Cincinnati.

More posts by Randall Restle