nerd1951.com

Most embedded systems software is written in C. I’ve written a number of rants about the reasons that C++ can improve the quality of your software and the productivity of your team. But, making the switch from C to C++ is not easy.

In many ways C++ requires a new approach to organizing your code. Developing C++ objects requires more up-front thinking than writing C functions. Don’t expect to become a great C++ programmer on your first project. Pick a small part of a project, or better yet, refactor a bit of existing code as part of an upgrade, for your first attempt.

As Mark Twain said, “Experience is the best school.” but I say it’s more productive to learn from someone else’s mistakes - like mine. My first C++ experience was with a large completely new project. We finished a year late and over budget. Fortunately for the software team, we were also developing a complex ASIC that was nearly as late as the software. Our management understood and the company went on to adopt C++ for the embedded software for nearly all of their new product development.

Such stories are the exception. Usually management views such results as disasters and C++ is abandoned. Such horror stories abound in our community. Be realistic. Learn and adopt C++ incrementally. You’re much more likely to succeed.

Here’s some more advice about starting with C++ from Bjarne Stroustrup himself: The C++ Style Sweet Spot.

I recently read yet another article bemoaning that the embedded systems community is not ready for the multi-core “revolution.” The article “Embedded software stuck at C - No parallel languages for multi-core on horizon” concluded that we embedded systems programmers would have to learn how to partition our programs to run on several processors. Excuse me but based on personal experience, I think we learned how to do that say, over twenty-five years ago.

One of the first embedded systems that I worked on, a terminal multiplexer used multiple Intel 8080 processors and a shared memory. Some of the processors handled the serial ports for the terminals or parallel ports for printers. One processor handled the “high speed” serial port that was used to connect to a remote minicomputer. Buffers were kept in shared memory and we used flags to indicate the status of each buffer: free, in-use, or ready to transmit. This system was designed in the late ‘70s.

I’ve worked on a number of embedded systems since then that were based on parallel/distributed processing. Some used symmetric multiprocessing and many used asymmetric multiprocessing with DSPs doing the fast numerical processing and other processors doing the more complex tasks. We had varying levels of success with partitioning our software but we made the systems work.

The point is that I believe embedded systems programmers and architects probably have more experience in partitioning software for multi-processor environments than anyone in the general purpose software community. And, the same rules don’t apply to us. We usually know up front that we are dealing with a very limited set of functions. This makes it much less complicated to assign tasks to specific processors. We can do this during design and we don’t need run time functions to assign tasks to processors or parallel programming languages to do the job for us.

Most of the programming websites and blogs feature comparisons and even arguments about “What is the best programming language.” The discussion usually includes languages like PHP, Ruby, Java and even Perl. But these discussions are mostly concerned with developing Web applications and the languages they discuss are all fine for developing the presentation tier. Most of these sites ignore C++ or even pronounce C++ as dead.  The irony is that two of the largest sites on the Web; Amazon.com and Google, do most of the heavy lifting in their applications using C++. Another irony is that most database-driven sites, including many blogs, use MySQL which was also written in C++. C++ applications are actually all over the Web. They are just hiding in the background, quietly and robustly doing their jobs and not being noticed. For more applications written in C++, check out Bjarne Stroustrup’s list of C++ Applications.

I know my readership has fallen off quite a bit since I haven’t been blogging regularly. I’m hoping that I still have a few loyal readers who might share their opinions with me. I am writing a book about using C++ for embedded systems. Much of the content is dissecting how C++ compilers implement the code they compile. This can vary from compiler to compiler and from processor to processor so I want to test a variety of C++ compilers on at least two processors that are commonly used in embedded systems.

I’m planning to use the ARM-7 processor which seems to be the ubiquitous low cost 32 bit processor and the Power Architecture (formally PowerPC) which is commonly used in more high-end embedded applications. MIPS is also a possibility. I want to stay away from single-vendor processors like Freescale’s ColdFire. I also don’t believe that C++ has much to offer for eight bit processors. Applications for eight bit processors should be simple enough that they can easily be written in C.

Compliers are more of a problem. GNU’s GCC covers all of the processors that are of interest. I like IAR’s compiler for the ARM though it is not a complete C++ implementation and does not support the Power Architecture. Freescale’s Code Warrior supports the Power Architecture but it’s not clear at this point how well it supports the ARM processors. Green Hills has a complete C++ implementation for all of the processor architectures but their tools are expensive and I have yet to explore obtaining some kind of evaluation copy.

So, my questions to you are: “Did I leave out any processor architectures of interest?” and “Do you know of any other C++ compilers that I should consider?”