I just returned from the Embedded Systems Conference (ESC) in Boston where I taught a course on lessons learned from hardware/firmware interface design. These conferences are always good for interacting with other engineers and learning from them. Two things I learned at ESC apply directly to this month’s topic on anticipating the impact: debugging facilities and platform-specific code.

My first realization occurred at lunch before my class at ESC while I was swapping war stories with other instructors. I explained that my old HP LaserJet development team had to run 30 printers overnight to get one to crash with an intermittent failure. I mentioned I had a debug logging utility in my code, and everybody started laughing. At first, I did not know why they laughed. Then I learned why.

They all had assumed my debug logging caused the failure, that some log buffer overflow or performance hit caused the problem. They knew the negative impact supposedly harmless debugging code can cause. They had experienced it and were remembering lessons learned; they assumed that was the point of my story. But they had assumed incorrectly.

My debugging log did not cause the problem – it was the key to solving that intermittent failure. But I knew what they were talking about. I had dealt with overflowed logging buffers and performance hits. I knew the impact of taking up code and memory space for debug code and logs. But by applying the same level of coding and testing rigor that I used on my regular code, I had developed a robust and reliable debugging facility that proved its worth time and time again in solving a variety of hardware/firmware problems during development.

• Best Practice: Follow your standard firmware development process when developing firmware debugging facilities to ensure reliability and minimize impacts to the rest of the system.

My second epiphany occurred during my class at ESC. I was discussing the negative impact of a hardware task that required some time to carry out but did not have a status or interrupt bit to indicate the task was complete. Instead, firmware had to use a tuned busy loop to induce the delay. I mentioned that when the code was ported to a new platform with a different CPU and clock speeds, the busy loop was too fast, violating the hardware requirement. My point was that hardware should have a status or interrupt bit to indicate completion to prevent the firmware engineer from tuning firmware every time.

But having that bit is not always an option. One of the attendees in the class suggested putting a marker in the code comments so when code is ported to a new platform, a search for all locations with that marker can help engineers revisit the timing conditions for the new platform. I thought that was an excellent idea.

I have seen engineers use something like REVISIT in their comments to mark sections of code they need to get back to. In this case, something like TIMING, TUNE TIMING, or CHECK TUNING could be viable markers to help find that section of code later. The marker should be standardized and documented within your organization so anyone on your team can find it in the future.

• Best Practice: Use standardized and well-documented comment markers to clearly identify hardware-specific firmware code for future tuning or porting.

While markers in the comments have their place, there generally are better ways to manage platform-specific code. I will discuss that in next month’s newsletter.

Until the next bridge…