Scripting Is Not Enough

Oct. 28, 2002
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...

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.

About the Author

William G. Wong | Senior Content Director - Electronic Design and Microwaves & RF

I am Editor of Electronic Design focusing on embedded, software, and systems. As Senior Content Director, I also manage Microwaves & RF and I work with a great team of editors to provide engineers, programmers, developers and technical managers with interesting and useful articles and videos on a regular basis. Check out our free newsletters to see the latest content.

You can send press releases for new products for possible coverage on the website. I am also interested in receiving contributed articles for publishing on our website. Use our template and send to me along with a signed release form. 

Check out my blog, AltEmbedded on Electronic Design, as well as his latest articles on this site that are listed below. 

You can visit my social media via these links:

I earned a Bachelor of Electrical Engineering at the Georgia Institute of Technology and a Masters in Computer Science from Rutgers University. I still do a bit of programming using everything from C and C++ to Rust and Ada/SPARK. I do a bit of PHP programming for Drupal websites. I have posted a few Drupal modules.  

I still get a hand on software and electronic hardware. Some of this can be found on our Kit Close-Up video series. You can also see me on many of our TechXchange Talk videos. I am interested in a range of projects from robotics to artificial intelligence. 

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!