I've been looking at a number of microcontroller development kits from Atmel, Cypress Semiconductor, Parallax, Mitsubishi, Motorola, Ubicom, and Rabbit Semiconductor. It's surprising how inexpensive the kits are and how easy it is to get started using them. All the kits come with development tools like assemblers, compilers, and debuggers. They are good, but we should tell vendors that they can do better.
Integrated development environments (IDEs) have simplified debugging as the debugger has been more integrated with other aspects of the IDE. Unfortunately, de-buggers have not shown the same improvement in performance or ease-of-use as other parts of the IDE. Such features as color-coded source code make debugging easier, but they are really editor enhancements.
Don't get me wrong. Debuggers have been improved. Features like breakpoint scripting found in higher-end development tools are available in these inexpensive development kits. But these additions tend to exist elsewhere.
I'm a bit spoiled when it comes to debugging because I have worked with Smalltalk and Lisp systems. With these environments, it's possible to build almost anything that's not already in the base debugger. For example, displaying data and data structures within an application was easy. Better yet, the job could be done in the middle of a debugging session. New functions could be written to analyze and display information.
Once these enhancements were completed, they could be used in the next debugging session. Complex breakpoint or trace support was extremely flexible because the entire system and programming language could be brought to bear instead of trying to jump through hoops with a basic scripting system.
The closest thing that I have found when using conventional languages like C++ or Java is to add this type of support within the application. This is not really a problem with desktop or server development where processing power and memory are in great supply. I spent many years doing this with Microsoft's Visual Studio. Although not an easy job, it was possible.
The problem is that embedded development typically occurs in a cross-platform environment. The host PC has plenty of resources, yet the embedded target often has very scarce memory and processing resources for debugging.
Cross-platform debuggers get around this problem by putting most of the debugger on the PC and limited probes on the target system. But access to the probes is limited. Scripting tools frequently have access to things like breakpoints and memory, but they tend to have limited capability using the window and menu system on the host.
Two things are needed to vastly improve debugging capabilities. One is access to the debugger's internals. An open-source tool, such as GDB, makes this possible, though it's not with most commercial debuggers. This includes the more limited, very target-specific debuggers found in the microcontroller development kits. The alternative is to provide public application programming interfaces (APIs) to developers.
The other way to improve the debuggers is to make use of these APIs. Most vendors fall down here. They expect users to start from scratch. Developers need a friendly front end to take advantage of this newfound information. It should be easy to display an array as a histogram, or to change a text string. Attaching a button to a variable should not require writing a function. Provide some good examples and give away the source code. The results might surprise vendors and please developers. I know I would use it.
Reprints
