Embedded Systems October 2000 Vol13_11

Issue link:

Contents of this Issue


Page 179 of 181

BREAK POINTS . Crea.te a dynamic model oj code size. Few of us really create a meaningful esti- mate of ROM/ flash needs. Instead, we tend to ask for as much ROM as possi- ble, or perhaps double the amo unt used on the previous proj ect. It's tough to estimate binary sizes when starting a large project. But we can't abdicate our responsi- bility to monitor code growth. Telling the boss a month before delivery- when the hal-dware design is cast in PCBs-that we need more ROM is a sure path to career stagnation. It's a simple matter to build a spreadsheet that lists all of the mod- ules the system will contain with esti- mates of their size (in lines of code, function points, or any other reason- able measure). Edit in the real source line and object size of each module as it's completed. Over time you' ll find a reasonabl e approximation to the number of bytes of code per line of C; have the model apply this to the as-yet- uncompleted po rtions of the code to predict final system size. Odds are you' ll spot ROM shortages early on, when there's still time to take design action. Size doesn't matter. Be content with your- self and who you are. Reuse and maintenance Be realistic about reuse. Reuse is hard. Good ru les of thumb: Before you can develop code for re use you must have d evelo ped it at leas t three times. Before you can reap th e be n- efits of re use you mu t have reused it three times. One proposa l for Reagan 's version of the Star Wa rs miss il e defense sys tem, which was pegged at 100 millio n lines of code, was that every module had to have been used three times before be ing included in th e sys tem. Not a bad idea, especially for a sys tem so diffi- cult to test. Avoid dejJendencies. Global variables are responsible for most of the evil in the world. A program infested with globals becomes non-maintainable, buggy, and a nightmare for all team mem- bers. Globals also make reuse all but impossible. Embedded sys tems suffer from another dependency problem: code th at talks to hardware. Encapsulate all I/O operations. Self documenting code does not exist. Long variable names do not self document- ing code make. judiciou name selec- tion is just a part of good coding. Comment aggressively. Any idiot can write code. Even teenaged hackers manage to crank o ut working soft- ware. Professionals create beautiful code that is crystal clear and a j oy to maintain . Accurate, lucid comments are an important ingredient of well- written firmware. Code is nothing more than the computerese descrip- tion of what's going on; comments are the human description. Use active vo ice. Capitalize usin g standard English rul es. Ch eck your sp e llin g. Desc ribe concise ly th e goes-intas and goes-outtas, as we ll as what happe ns and why. Some e nlighte ned programme rs write all of the comme nts first, and the n fill in the C at their le isure . The ha rd pa rt, after all , is crea tin g an accu- ra te, documented design. The code is nothin g mo re than a simple trans- lation o f a good design in to comput- er-lingo. Keep comlJiles clean. Don 't come to the dinner table with dirty hands, and don't deliver code reeking of unpleas- ant warnings. Why do we tolerate warning messages from our compiler? Firmware lives forev- er. When someone else opens your code five years ii-om now for an upgrade and finds hundreds of war'nings scrolling off the screen, he' ll have no idea if the mes- sages are expected or are an effect of tlle way he's reinstalled the tools. Maintenance is an unavoidable aspect of the software development process; he who programs WitJlout maintenance in mind is an amateur. Keep the code strictly ANSI com- pliant to minimize warnings and max- imize portability. Segment unavoid- able deviations from the standard to separate modules which document expected unusual compiler behavi ors. EncalJSulate. The OOP fo lks chant "encapsula tio n, polymorphism and inheritance." Of those three, encapsu- lation is the easiest and most powerful tool for building well-written, easy-to- understand code. It's equally effective in assembly, C, or C++. Bind "meth- ods" (code that accesses a device or data structure) with the data itself. Floss. Yo u' ll miss your teeth when they' re gone. esp Jack G. Ganssle is a lecturer and consul- tant on embedded development issues. He conducts seminaTS on embedded systems and helps companies with theiT embedded challenges. He Jounded two coml)(tnies spe- cializing in embedded systems. Contact him at References 1. Gilb, Tom and Dorothy Graham. Software Inspection. Reading, MA: Addison-Wesley, 1993. 2. Wheeler, David A., Bill Brykczynski, and Reginald N. Meeson, eds. Software Inspection: An Industry Best Practice. Los Alamitos: IEEE Computer Society, 1996. EMBEDDED SYSTEMS PROGRAMMING (lSSN 1040·3272) IS published monthly, with an ddditionalissuc published In September, by CMP Media. 525 Market St , Ste. 500, San FranCISco, CA 94105, (415) 905·2200. Please dkect advertising clnd edilorlallnquiries to this address. SU8SCRIPTION RATE for the United States is $55 for 13 I~sues Canadian/Mexican orders must be accompanied by payment in U.S. funds with additional postage of S6 per yeal. All other foreign subscliptlons mu~t be prepaid in U.S, funds with additional postage of $15 per year for surface mall ,md $40 per year for a!rm available on microfilm/fiche from UnIVersity Microfilms International, 300 N. Zeeb Rd., Ann Arbor. MI 48106, (313) 761-4700 176 OCTOBER 2000 Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11