[home] :: The ten secrets of embedded debugging :: [the-ten-secrets-of-embedded-debugging-1]
0 products in your
0 products in your
To deliver productivity, tools have to provide more than powerful visualization: they must also be usable on the system. Real-time systems are much more sensitive to intrusion than desktop systems. Will that profiler slow your system? Not a problem for your GUI. But if it makes the network interface drop packets, you may not be able to profile your embedded application at all.
Tools must also be used. Inserting instrumentation or code changes requires time and effort. Even simple recompilation with new flags can be a barrier, especially for larger team-built applications. As a result, most programmers don't immediately turn to the tool. They'll try changing the code and recompiling many times first. While each step seems insignificant ("I'll just try a printf"), this pot-shot technique is a huge drain on productivity. Fear and inertia are also factors; many programmers don't even try the tools they already own.
A source-level debugger lets you step through your code, stop it, and then examine memory contents and program variables. It's the fundamental first tool to bear on a problem.
A simple printf statement (or your language's equivalent) is perhaps the most flexible and primitive tool. Printing out variable values allows you to discover how your program is operating. Unfortunately, printf is both clumsy to use (requiring code changes and recompiling) and quite intrusive because it greatly slows execution. It also can produce reams of data that obscure the real problem.
In-circuit emulators (ICE) and JTAG debuggers allow you to carefully control the running chip. During the early stages of developing a custom board, an ICE is indispensable. There's just no substitute for full control of the processor when you don't trust the hardware. You can start debugging the board as soon as it comes out of reset, allowing you to see everything going on in those first crucial microseconds. You can debug code in ROM. You can usually ignore the minimal intrusion. However, once the operating system is up, hardware tools sometimes fall short. Hardware emulators aren't the same as the production CPU. They don't do well debugging multiple processes. They aren't nearly as flexible as a full set of software tools.
Data monitors show you what your variables are doing without stopping the system. Data monitors can collect data from many variables during execution, save the histories, and display them in a live graphical format.
Tools must also be used. Inserting instrumentation or code changes requires time and effort. Even simple recompilation with new flags can be a barrier, especially for larger team-built applications. As a result, most programmers don't immediately turn to the tool. They'll try changing the code and recompiling many times first. While each step seems insignificant ("I'll just try a printf"), this pot-shot technique is a huge drain on productivity. Fear and inertia are also factors; many programmers don't even try the tools they already own.
A source-level debugger lets you step through your code, stop it, and then examine memory contents and program variables. It's the fundamental first tool to bear on a problem.
A simple printf statement (or your language's equivalent) is perhaps the most flexible and primitive tool. Printing out variable values allows you to discover how your program is operating. Unfortunately, printf is both clumsy to use (requiring code changes and recompiling) and quite intrusive because it greatly slows execution. It also can produce reams of data that obscure the real problem.
In-circuit emulators (ICE) and JTAG debuggers allow you to carefully control the running chip. During the early stages of developing a custom board, an ICE is indispensable. There's just no substitute for full control of the processor when you don't trust the hardware. You can start debugging the board as soon as it comes out of reset, allowing you to see everything going on in those first crucial microseconds. You can debug code in ROM. You can usually ignore the minimal intrusion. However, once the operating system is up, hardware tools sometimes fall short. Hardware emulators aren't the same as the production CPU. They don't do well debugging multiple processes. They aren't nearly as flexible as a full set of software tools.
Data monitors show you what your variables are doing without stopping the system. Data monitors can collect data from many variables during execution, save the histories, and display them in a live graphical format.