Step Into Embedded System World

A basic rule of software engineering is to limit routines to a page or less
 Start with a well-defined spec/requirements document, use a formal process of inspections on all work products (from the spec to the code itself), and give the developers powerful and reliable tools. Skip any of these and bugs will consume too much time and sap our spirits
 If we’re doing something that will likely be wrong, proactively take some action to catch the likely bug  Why do we continue to leave our unused ROM space initialized to some default value that’s a function of the ROM technology and not what makes sense for us? Why don’t we make a practice of setting all unused memory, both ROM and RAM, to a software interrupt instruction that immediately vectors execution to an exception handler?  Set all unused memory to the appropriate instruction, and write a handler that captures program flow if the software interrupt occurs  Fill all of your unused interrupt vectors with a pointer to a null routine. During debug, always set a breakpoint on this routine. Any spurious interrupt, due to hardware problems or misprogrammed peripherals, will then stop the code cleanly and immediately, giving you a prayer of finding the problem in minutes instead of weeks  Perhaps one of the most proactive things we can do to isolate bugs is to build a comprehensive test plan, rather than the ad hoc qualification that seems de rigor  The cardinal rule of interrupt handling is to keep the handlers short. A long ISR simply reduces the odds you'll be able to handle all time-critical events in a timely fashion.Short, of course, is measured in time, not in code size. Avoid loops. Avoid long complex instructions (repeating moves, hideous math and the like)  Build a stack monitor into your code. A stack monitor is just a few lines of assembly language that compares the stack pointer to some limit you've set. Estimate the total stack use, and then double or triple the size. Use this as the limit  Generating reusable libraries  Consider using Hungarian Notation. Hungarian notation uses lower case characters that indicate the type of a variable as the name's prefix. Then, you can look at any variable and instantly know it's type  Don't use globals. Globals are a problem because any routine, at any time, can alter the state of any global. Perhaps a few globals might be needed, to maintain major state parameters of the system. Limit the number of these  Make your comments clear, concise, and well organized . Avoid long paragraphs. Use simple sentences: noun, verb, object  Back up your work constantly. Backing up is perhaps not part of a programming style, but is equally a part of the culture and philosophy of being in this business  Basic philosophy of debugging any system is to follow these steps: For (i=0; i< # findable bugs; i++) { while (bug(i)) { Observe the behavior to find the apparent bug; Observe collateral behavior to gain as much information as possible about the bug; Round up the usual suspects; Generate a hypothesis; Generate an experiment to test the hypothesis; Fix the bug; }; };  Never, never, never forget to check Vcc. Time and time again here at Softaid we see systems that don't run right because the 5 volt supply is really only putting out 4.5... or 5.6... or 5 volts with lots of ripple. The systems come in after their designers spent weeks sweating over some obscure problem that in fact never existed, but was simply the ghostly incarnation of the more profound power supply issue  Sometimes you'll have no clue what the problem might be. Scoping the logical places might not generate much information. Or, a grand failure like an inability to boot is so systemic that it's hard to tell where to start looking. Sometimes, when the pangs of desperation set in, it's worthwhile to scope around the board practically at random. You might find a floating line, an unconnected ground pin, or something unexpected. Scope around, but be always on the prowl for a working hypothesis  Never, ever, fix the bug and assume it's OK because the symptom has disappeared. Apply a little common sense and scope the signals to make sure you haven't serendipitously fixed the problem by creating a lurking new one  Plan ahead. Think before doing. Don't try something without knowing what the possible outcomes are... and without having some idea what you'll do for any of those outcomes. You may find that the next step will be the same regardless of the results of the experiment. In this case, save time and do something else  Keep functions short. That implies that a function should do just one thing. Convoluted code that struggles to manage many disparate activities is too complex to be reliable or maintainable. Express independent ideas independently, each in its own crystal clear function. One rule of thumb is that if you have trouble determining a meaningful name for a function, it’s probably doing too many different things  Get rid of redundant code. Redundancies are code snippets that have no effect, like assigning a variable to itself, initializing or setting a variable and then never using that value, dead code, or complex conditionals where a subexpression will never be evaluated, since its logic is already part of a prior subexpression  Flow, don’t jump. Avoid continues, gotos, breaks and early returns. These are all useful constructs, but generally reduce a function’s clarity. Overused, they are the basic fabric of spaghetti code. Eliminate deeply nested loops or conditionals – no one is smart enough to understand all permutations of IFs nested 5 levels deep  Never allocate or free memory in an ISR unless you have a clear understanding of the behavior of the memory allocation routines. Garbage collection or the ill-behaved behavior of many runtime packages may make the ISR time non-deterministic.  Assume nothing. Test everything. The PCB may have manufacturing errors on internal layers. Power and ground may not be on the pins you expect - particularly on newer high density SMT parts. Signals labeled without an inversion bar may actually be active low. You might have ROMs mixed up. Perhaps someone loaded the wrong parts on the board  Plan ahead. Think before doing. Don't try something without knowing what the possible outcomes are... and without having some idea what you'll do for any of those outcomes. You may find that the next step will be the same regardless of the results of the experiment. In this case, save time and do something else. The best troubleshooters are closet chess grand masters. They think many steps ahead  One of the very best practices of Extreme Programming is writing detailed tests concurrently with the code, which can in many cases find these problems early  Many modern programming approaches emphasize frequent releases of subsets of the project. All recognize the difficulty of meeting customer expectations when we dump one huge, completed, system in their laps. The spiral development model (code, release, re-estimate the next iteration, and repeat) is one such method that recognizes the difficulty of up-front estimation, particularly of risky projects  Inspect all new code. That is, use a formal process that puts every function in front of a group of developers before they spend any time debugging. The best inspections use a team of about 4 people who examine every line of C in detail. They’ll find most of the bugs before testing.Study after study shows inspections are 20 times cheaper at eliminating bugs than debugging  Identify bad sections early, before wasting too much time on them, and then recode. Count bug rates using bug tracking software. Histogram the numbers occasionally to find those functions whose error rates scream “fix me!”… and have the team recode  Real-time code is error-prone, expensive to write, and even more costly to debug. If it’s at all possible, move the time-critical sections to a separate task or section of the program. When time issues infiltrate the entire program then every bit of the program will be hard to debug  Watchdog timers are another type of preventative medicine often employed to detect failures  Comments: Begin every module and function with a header in a standard format. Every module (source file) must start off with a general description of what’s in the file, the company name, a copyright message if appropriate, and dates. Start every function with a header that describes what the routine does and how, goes-intas and goes-outas (i.e., parameters), the author’s name, date, version, a record of changes with dates and the name of the programmer who made the change. Explain the meaning and function of every variable declaration. Long variable names are merely an aid to understanding; accompany the descriptive name with a deep, meaningful, prose description  Figure on adding test points for the firmware as well. For example, the easiest way to measure the execution time of a short routine is to toggle a bit up for the duration of the function. If possible, add a couple of parallel I/O bits just in case you need to instrument the code