... to the topic of real time location systems. Some people dispute the name, some people dispute which technologies apply - or are best - but perhaps all agree that momentum is growing. The ability to know the location of an item or person is useful in all manner of industries and businesses. Whether hospital, school or office; whether factory floor or warehouse; being able to locate items quickly aids efficiency of staff and helps prevent theft or misplacement of expensive items. Applications can extend beyond simply knowing location such as addition of sensors to allow the recording of information such as temperature or pressure. With such addition the system can be useful for logistics and other similar applications. Our latest whitepaper is a discussion of real time location systems and is available for download.
Wikepedia states that "Debugging is, in general, a lengthy and tiresome task." ... for debugging discussion download click here.
I would say it's like catching a black cat in a dark room. But it's better don't let it in. This implyies either we need to improve our catching skills or prevention measures (or both together).
“Debugging is, in general, a lengthy and tiresome task.“ --- It need not be if the code is designed in a modular fashion, with enough flags to facilitate debugging. Localizing the error generally takes the max time and ties up the best engineers.
* Interfacing bugs seem to be very similar to cat catching though :)
"Debugging is a game, an art, a state of play. It's hide and seek! Sure it gets frustrating some times, but that is just a part of the game.
If you enjoy writing software, you like your code to be perfect. Hunting down the oddities you created is part of the fun."
Having spent the bulk of my career creating, finding, and removing deeply embedded bugs, I've thought long and hard about what it takes to find a bug that does not want to be found. It seems to me that it takes a particular set of mental disciplines to optimize the bug hunt. For Instance:
Rigor and Patience:
To paraphrase Sherlock Holmes, "Once you have eliminated the impossible, whatever remains, however improbable, must be the truth". That is to say that the scientific hunt for a bug can consist largely of forensically eliminating candidate causes. This requires a certain kind of patience - to proceed with urgency and rigor even though you are not in danger of closing in on your prey.
Fresh Eyes/Beginners Mind
Many's the time you are completely convinced that you understand the root cause of a bug only to be completely proven wrong. You can only hope that this lesson in humility doesn't happen right after you deliver a report on the subject to your boss' boss. Sometimes the best thing you can do is walk away and come back with a fresh point of view.
Observation
Debugging black-box behavior is sometimes like opening a Chinese puzzle-box. You find a part that can be moved and you work it back-and-forth trying to observe any side effects of each movement and position.
It's cheaper to avoid bugs than to make and find them, but unfortunately there is no "silver bullet" to ensure this occurs. In my experience as trainer and engineer it's all up to the people, the working environment and some disciplined ways of working.
The person who wants to find a tricky bug many times needs to analyze a combination of hardware trace and software debug information. To do this requires a fundamental understanding of the processors and the embedded software operation. This means the person needs to understand both software and hardware and that is not inline with the traditional approach to work place and education institutions course divisions.
In these times of increasing complexity it is no longer efficient to make all the mistakes by yourself; it is much cheaper and quicker to bring over some people who have made their mistakes, listen to what they have to say and learn from them.
Robert provided training at Embedded World, Nurnberg, March 2009 and has his presentation available here.
"[In my role as business/marketing consultancy serving the embedded & mobile sectors] I think a better title would be "A strategy for developing embedded software" because you don't really go into debugging, you outline an overall strategic approach to developing embedded sw. I also note that the strategy focuses mostly on debugging software, and only has a passing reference to the really tricky problems of debugging hardware/software interaction issues....which in itself is a whole article "
