e m be dde d.co m http://www.embedded.

co m/design/pro to typing-and-develo pment/4008303/A-guide-to -C--fo r-the-cautio us-embeddedpro grammer

A guide to C++ for the cautious embedded programmer

Colin Walls In some ways, writing embedded sof tware is much like writing sof tware f or any other kind of application. But in other ways it dif f ers widely. T his means that embedded sof tware developers can learn lessons f rom their desktop-bound counterparts, but they must harvest that wisdom selectively. Embedded sof tware technology appears to lag behind - it's of ten a little late in picking up on the latest trends and f ashions. T his is largely because embedded developers have a cautious, conservative attitude, which is borne out of years of experience contending with limited resources: memory that cannot be treated as unlimited and CPUs that are just powerf ul enough to get the job done. T he choice of programming language echoes this pragmatic conservatism. Embedded sof tware engineers were slow to pick up on high-level languages years ago, but eventually C became accepted. It took the arrival of very high quality code generation and f lexible, transparent debugging technology f or the industry to accept such innovative ideas, and that was only under the relentless pressure to become more productive. T he obvious step f orward f rom C is C++. Even though its use f or embedded sof tware has steadily increased in recent years, it is f ar f rom universal. Why is that? It is not stubborn resistance to change. It's simply continued worries about resource utilization. Memory may be bigger, but embedded sof tware developers cannot just add an extra gigabyte when needed. Processors are much f aster, but cost and power limitations mean they are way behind the devices f ound in even the more modest PCs. Five good ideas for using C++ in embedded apps Is this concern about the suitability of C++ f or embedded sof tware really justif ied? Not really. Like any tool, the language needs to be handled correctly to yield good results. T he cautious (embedded) programmer needs guidelines. Good Idea #1: Understand how C++ actually works. To get the best f rom any programming language, you need to f ully understand what the language constructs mean and what kind of code the compiler might generate. Look at the code produced and try to understand why it's done the way it is. Pay attention to details. For example, if you think the two statements i++; and ++i; are always identical in C++, think again. (T hey yield the same result, but the postf ix operator probably requires intermediate storage, so the pref ix version may be more ef f icient.) Good Idea #2: Start by applying C++ incrementally. If you're using C, it may be a big step to change to C++. However, since C++ is not an object-oriented language (it's a procedural language with some object oriented f eatures " and is basically a super-set of C) you can start taking advantage of the extra f unctionality one bit at a time. As you learn new f eatures and see how they can improve your code, you can start to apply them. Good Idea #3: Apply language features in appropriate ways. Like C, C++ was not designed specif ically f or embedded applications, so it is not 100% suited to the task. Some f eatures of the language carry

absolutely no cost in resources like overloaded f unctions, f or example, which are just a compiler/linker symbol issue; these may be used f reely as required. Other f eatures can cause signif icant overhead and should be used with care or avoided all together. A good example is the exception handling system (EHS). T his f acility enables the construction of very robust code, with very little ef f ort required by the programmer to accommodate a wide range of exceptional events smoothly. T he downside is that, behind the scenes, a lot of code has been silently generated to accommodate this f unctionality. Although avoiding the EHS entirely may not be necessary, using it in a simple way minimizes unwelcome surprises. It's worth noting that the EHS overhead code may be generated, even if EHS is not being deployed; EHS support is switched on, by def ault, in many compilers. Good Idea #4: Encapsulate expertise in objects. An embedded sof tware team has a diverse set of skills. Dif f erent members of the team have dif f erent areas of expertise. Endeavor to encapsulate that expertise into classes so that it can be utilized saf ely by other members of the team. For example, a hardware device may have some very precise requirements associated with its access; representing the device by an object means that not every user needs to understand its eccentricities. A similar approach can be used to hide the specif ics of a real-time operating system. Good Idea #5: Use tools that are optimized for embedded. It's a known f act that embedded sof tware development is dif f erent f rom desktop programming. T his is widely recognized and a great many companies of f er tools f or embedded programming, but tread caref ully here. Some tools are much more oriented towards the needs of embedded developers than others; some vendors simply adapt desktop development tools. Five things to avoid #1: Writing "clever" code is never smart. C++ gives you the opportunity to write very clear, concise code. It also provides the means to write very convoluted, arcane code which does nothing except illustrate how clever you think you are. Do not give in to this temptation. For example, in C++ you can def ine your own operators. Always ensure that their f unctionality will not surprise a reader of the code. For example, you could def ine a new class and include a def inition of the + operator, such that an expression may be written like this: a + b; T he above example adds the value of the object b to the object a. T his is unwise, as the + operator does not normally f unction in this way. Redef ining the += operator would be much better. If they do not serve to clarif y the logic of the sof tware, do not use overloaded operators; just use member f unctions with meaningf ul names instead. Neither language f eature introduces any hidden overheads into the resulting code. #2: Do not treat an embedded system like a desktop computer. If you're programming a PC, you can assume that memory is inf inite (and f ree) and that you will always have enough CPU power. With embedded sof tware, you need to be more circumspect as both memory and CPU power are limited. T he best approach is to write some code, then measure its size and its execution perf ormance. Only when you are satisf ied that these measurements are within reasonable bounds should you move on. #3: A purely top down implementation may be dangerous. It may be attractive to build a sof tware application by starting at the high level and including just stubs f or lower level f unctions. T hen, when that structure is debugged, you can start implementing the next level down.

T he drawback to this strategy is that a nasty surprise may be waiting just around the corner. You can f inish coding and f ind that the whole program is too big and/or too slow. And you have no idea where you acquired the additional overhead. A better approach is to start at the other end. Encapsulate the lower level f unctionality in objects and build the application up f rom there " f ollowing the previous advice of measuring as you go. With this approach you will not encounter any surprises. #4: Avoid the use of deeply nested inheritance. Part of the point behind object-oriented programming is the ability to def ine classes in terms of others (base classes) that have been previously created (by you or by another developer) without the need to f ully understand the inner workings of the base classes. T his is inheritance. T he downside is that objects instantiated f rom such derived classes may carry some overhead " not much, but some. And this overhead may mount up as the depth of inheritance increases. So, f or an embedded application, where overheads may really count, you need to be vigilant. #5: It is not logical to avoid language features just because your tools do not handle them well. Some language f eatures can be very usef ul, but will carry an overhead if not handled in an appropriate way f or embedded applications. An obvious example is f unction templates which if badly implemented, can cause an enormous code bloat. A common implementation of templates results in instantiations which are local to a module. T his can lead to numerous copies of identical code that could waste an enormous amount of memory. If your tools do not handle such constructs well, do not eschew good programming practice. Get some tools that will enable you to program productively. Conclusion As code size and complexity increases relentlessly, C++ is becoming an excellent programming language of choice f or embedded applications. Past f ailures have deterred many developers f rom adopting the language choosing instead to continue using C. T he key to success with C++ is to use it intelligently, f ocus on the problems that it addresses, and pay attention to its implementation on an embedded system.