printf, “just”-Flash and other Debugger Stories
Hardware-Debugging – An Embedded Software Developer’s Daily Business
In the 1990s, there were basically two tool-based solutions for debugging embedded software on real hardware: The monitor debugger, i.e., a piece of software that was programmed in the memory of the embedded system and reacted to requests of a debugger software from outside. And the in-circuit emulator, a (large) piece of hardware that replaced and emulated the microcontroller/processor located in the target hardware by adaptation.
This article is not about in-circuit emulators. It is about the evolution of debugging and the today's challenges in development and test of embedded software.
Summary
The debugger is more and more turning into a process tool. The basic functions of a debugger find their ordinary application and are supplemented by powerful analysis functions. The increasing complexity of software, the vast number of software and hardware tools used in software development itself, and their interdependencies, drive the need for knowledge transfer and consulting services between tool manufacturers, chip suppliers and customers. A continuous and open communication between all parties involved in these developments is the key to success. Already today, customers no longer want to buy tools, they want to use them whenever and wherever those are needed. New business models for embedded software development and software testing will come into play where tools, knowledge transfer and consultancy are a common product and ultimately a service. Just like in the software industry, the subscription business model is most appropriate for global embedded software development and testing.
Further links and resources