Abstract

Real-time debugging of large microprocessor control software applications can be a formidable task. Programmers must be concerned with more than software requirements. The develop ment tools, the electrical control hardware and debugging techniques all affect an individual's productivity. This paper contrasts software debugging environments and their capabilities. A xerographic copier is used as an example of a real- time application. Two debugging environments are discussed. One is a real-time-only configuration where copier application software is debugged using the actual copier. The other, sug gested as an improved method, substitutes a real-time simulator in place of the copier. In each case the actual electrical control system of the copier is used. A copier is a mechanical device that cannot be stopped quickly. This characteristic is not a good match for software debugging methods that use breakpoints and stepping techniques. Com mercial microprocessor development equipment aids the de bugging effort by adding hardware support to store trace infor mation while debugging in real time. Although this is an effective method for debugging software, there are several shortcomings that should be evaluated. These are: • Only a portion of software debugging techniques can be used in this real-time-only environment. • The copier's operation is difficult to monitor and change. The copier is inflexible in comparison to the capabilities of the software debugging tools. Simulating the copier, on the other hand, offers significant debugging capabilities to the control applications engineer. • It is a separate computer system. The computer characteristics of the simulator match the character of the software de bugging tools. • It can be manipulated, as desired, on-line. • It is capable of displaying the copier in two-dimensional form. The complete development environment including the simu lator, a microprocessor support and in-circuit emulator system, a logic analyzer and copier controls can be stopped by adding a hardware signal called "freeze." This signal is asserted by any development equipment to synchronously stop the entire en vironment. Considerations for designing the freeze function into the electrical controls system are discussed. Synchronizing the development environment during debugging, enables use of powerful non-real-time debugging techniques. This configuration offers the controls application programmer an efficient alternative to "run to crash" techniques commonly used in real-time-only efforts.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call