EETimes

Embedded Systems October 2000 Vol13_11

Issue link: http://dc.ee.ubm-us.com/i/71842

Contents of this Issue

Navigation

Page 174 of 181

Jack G. Ganssle Momisms Momism ( mom iz' em) n. l. A brief statement of a principle passed maternally. 2. A tersely warded statement of an observation of truth: APHORlSM. The image of mom gently guiding her young ones down paths of .-ight- eousness, teaching tllem the basic ele- ments of being civilized, helping witll school work, is powe rful indeed . Yet we still leave home ill-equipped for real life; college itself does but a pOOl-j ob in preparing us for careers and adult- hood. Pe rhaps mom should have taught us some more lessons. Here are a few thoughts. Interrupts Keep lSRs Sh OTt. Debugging interrupt service routines is tough and, in some cases, almost impossibl e. Too often tllose expensive tools wOI -k poorly or not at aIL inside an ISR. Breakpoints fail because tlley operate at human peeds, while th e inte rrupts come much faste r. Single stepping, the old standby of many developers, just won't work whe re interrupts arrive at any sort of reasonable rate. Single tep in a se tion of code where inte rrupts are reenabled, and you' ll likely debug dif- fe rent instantiations of the ISR with each step. An emulator with trace will cap ture the service routine's execu- tion, but even the largest trace buffers fill quickly from loops and recursion. A very wise fr-iend taught me the fun- damental rule of debugging ISRs: don't. Keep the routine so short, so simple, that you can debug by inspection. A good rule of thumb is to limit JSRs to a dozen or so lines. Worst case, keep them shorter than a page. If the ISR really must do a lot of work, why not spawn a task that handles the complexity? Avoid NMi. Non-maskable interrupt, also known as Trap, level 7, or any of a number of monikers, can't be shut off, ever. Other intermpt inputs succumb to tlle "disable" instruction, and gener- ally turn off automatically when a hard- ware-initiated intermpt occurs. Until you explicitly turn the intelTupt back Why would spurious inte rrupts occur? Maybe the hardware is defec- tive or glitchy-it's a prototype during developme nt, isn't it? Perhaps you've misprogrammed one of the hundreds of registe rs inside of today's too com- plex peripherals. Bette r to fill all unused vectors Witll a pointer to a debug routine that either logs the erroneous interrupt or reaches a lurking breakpoint. Look here if you want to know what Moms have to offer the embedded world. You'll also benefit from some of Jack's tips. on, the unavoidable no n-reen tran t parts of the ISR are safe. An NMJ han- dle.-, however, is never safe. Non-reen- trant code will be destroyed if the inter- rupt recurs. Many CPUs use an edge- sensitive input for this beast, 0 the slightest bit of noise can create multiple false NMls over the course of a few microseconds. And debugging tools, like emulators, often couple small bi ts of spu.-ious noise into the target system. Reserve NMI for one-time events like power fai lure or tlle apocalypse. Fill -un-used vectors. Though a CPU might support hundreds of interrupt sources, each one defin ed by an en try in the dispatch table, we rarely use more than a handf ul. If you leave those unused dispatch table entri es blank, any weird vectoring will crash the application horribly, leaving no trail of evidence to the root cause. Listen-don't intermt)t others. You ' ll leanl far more listening than talking, and the listene r never puts his foot in his mouth. Bugs Inspect rather than deb-ug. Bottom line: code inspections find bugs some 20 times more efficiently than debugging by test. Inspect the code, design, specs, and all relevant design documents to find problems before writing/ debug- ging/ testing and then chucking a lot of expensive firmware. Inspections won 't find all of the problems, but a well-implemented inspection process wrings out 70% to 80% of the defects fo r a fraction of the cost. Studies indicate tllat in many sys- tems 50% of the code never gets test- ed . It's difficult at best to devise test conditi ons for eve ry error condi- Embedded Systems Programming DaDBER 2000 In

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11