Page 70 - The Art of Designing Embedded Systems
P. 70

Real  Time Means Right Now!  57

                           more commonly it’s set up by the firmware. Forget to initialize the
                           device and the system will crash as the device supplies a bogus
                           number.
                           Some peripherals and interrupt inputs will skip the acknowledge
                           cycle because they have predetermined vector addresses.
                        9  All CPUs let you disable interrupts via a specific instruction (DI,
                           CLI, or something similar). Further, you can generally enable and
                           disable interrupts from specific devices by  appropriately setting
                           bits in peripheral or interrupt control registers.
                        9  Before invoking the ISR the hardware disables or reprioritizes in-
                           terrupts. Unless your code explicitly reverses this, you’ll see no
                           more interrupts at this level.

                        At first  glance the  vectoring seems unnecessarily complicated.  Its
                    great advantage is support for many varied interrupt sources. Each device
                    inserts a different vector; each vector invokes a different ISR. Your UART
                    Data-Ready ISR  is  called  independently of  the  UART  Transmit-
                    Buf fer-Full routine.  The  vectoring  scheme  also  limits  pin  counts,
                    since it requires just one dedicated interrupt line.
                        Some CPUs sometimes directly invoke the ISR without vectoring.
                    This greatly simplifies the code, but unless you add a lot of manual pro-
                    cessing,  it  limits  the  number  of  interrupt  sources  a program  can  con-
                    veniently handle.


                         Interrupt Design Guidelines
                        While crummy code is just hard to debug, crummy ISRs are virtually
                    undebuggable. The software community knows it’s just as easy to write
                    good code as it is to write bad. Give yourself a break and design hardware
                    and software that eases the debugging process.
                        Poorly coded interrupt service routines are the bane of our industry.
                    Most ISRs are hastily thrown together, tuned at debug time to work, then
                    tossed in the “Oh my God, it works” pile and forgotten. A few simple rules
                    can alleviate many of the common problems.
                        First, don’t even consider writing a line of code for your new em-
                    bedded system until you lay out an interrupt map (Figure 4-3). List each
                    interrupt and give an English description of what the routine should do. In-
                    clude your estimate of  the interrupt’s  frequency.  Figure the  maximum,
                    worst-case time available to service each. This is your guide: exceed this
                    number, and the system stands no chance of  functioning properly.
                        The map is a budget. It gives you an assessment of where interrupt-
                    ing time will be spent. Just as your own personal financial budget has a
   65   66   67   68   69   70   71   72   73   74   75