Today, I am going to tell you a tale. It’s a true story of events that happened long, long ago in a land far, far away. We’re always told that we should learn from our experiences (or from our mistakes, depending on whether you do "glass half full" or "half empty"). Hopefully, there are less painful lessons to be learned from the experience of others.
Once upon a time, there was a young engineer, who was working on software for some fairly simple, 8-bit embedded systems, although the term “embedded” hadn’t yet been coined. The code was written in assembly language, but it needed to be modular, scalable, and maintainable. Having worked on real-time systems, he concluded that he needed a real-time, multi-tasking kernel. Having no idea of any alternatives, he was pleased to have the opportunity to design and write a kernel. The result of a couple of weeks work was a kernel that was preemptive and time-sliced with a background task. It worked well for the required application and the project was completed on time.
The next project came along and the hero of our story saw another opportunity to make use of his kernel. So, he spent a couple days enhancing it to incorporate some new ideas he learned from his experiences in the previous project. Then he used it as the basis for the new application. Once again, the project was completed successfully and on time.
The young engineer was feeling very pleased with himself and, when the third project came along, did not hesitate to use his kernel again. Just like the previous occasion, he invested a little time to improve the kernel based upon his experiences. And, yet again, he was very successful.
I can imagine that you are now thinking that this guy needed a reality check. Things were going too well for him and he needed to be brought back down to Earth with a bit of healthy failure—which is exactly what happened.
After the third project, it was decided to update the hardware that had been used in the first one and this necessitated modifications to the software. So, our hero dug out the code listings he had written a few months prior. He had a shock. What was this kernel that had been used? It was, of course, the one that he had written. But he had gone through two rounds of enhancements since then and his recent work only bore a passing resemblance to its ancestor.
He left the company shortly after this to pursue an opportunity with an embedded tools and RTOS company. As you may have guessed, that young engineer is now a rather older, grizzled engineer who often writes blogs and articles and makes videos on embedded software. I left behind me not one, but three in-house designed kernels. Fortunately, I did a reasonable job with documentation, so I did not run away from a terrible mess. However, if I had been able to source a commercial real-time kernel, I would have only left behind a single, comprehensively documented software package.
In recent years, I’ve frequently given a talk looking in detail at the issues that should, in an ideal world, drive the decision to make or buy an RTOS, as this is still a subject of debate. Let me know if your company needs advice on this topic.
Colin Walls is an Embedded Software Technologist at Mentor Graphics’ Embedded Software Division.monthly-eletter-09-01-2017