Bill: Today we have the hardware hooks to debug processors with on-chip memory. But it's not enough. Code size and chip clock rates have risen, so we need better on-chip debugging resources.
Ray: Don't forget, it's the hardware that gives you programmers the hooks to debug code running on today's embedded processors. Hardware provides the breakpoint comparators and trace buffers so you can see where your code goes—south instead of north.
Bill: Yes, but we need more to do a first-class job. You hardware folks are pretty stingy. Four or six breakpoint comparators may seem like a lot to you, but it's too little, too late for us. We're talking about big programs with complex code. You're giving us a trike with training wheels when we need Harley power.
Ray: But at least our stuff works. Unlike software, hardware is something you can trust. Software is always the bottleneck, the last to cross the schedule finish line. Hardware works because it has finite limits: a gate drives only so many gates. Software has no such restrictions. Unlike a gate, a function can be called by thousands of functions, making it easy to get spaghetti code.
Bill: On-chip debugging technology is changing from a limited breakpoint and trace buffer set to a more software-oriented function. On-chip monitors provide a software level to support target debugging without disturbing the application and RTOS software.
Ray: That's a neat trick. But remember, it's still code executing on a hardware platform, and that platform has limits. Nothing comes for free. Comparators and trace buffers can run in parallel with program execution. But when you hit a breakpoint, the CPU's resources will be shared.
Bill: Debugging can live with slower execution or an execution break. But we need the debug data transformed into useful forms, relating execution events to the listing. Trace buffers and larger trace ports let us track threads and see what happened with what data values.
Ray: True, engineers should be more responsive to programmers' debug needs. But programmers also need to understand hardware limitations. Let's really figure out what's needed to debug applications. Debugging hasn't changed much since Microsoft's and Borland's IDEs.
Bill: "Times are a-changing." Faster chips, bigger programs, and more on-chip memory mean that we have to get better about tracking, monitoring, and executing software.
