Saturday, January 24. 2009
This is the last post in my series (see part 1 and part 2) about watchdog timers (WDTs). After that one I will stop bugging you with the topic. But probably you've already got the impression I have a certain weakness for WDTs. Anyway let's take this to the next level and find out how to improve the solution from my last post even further.
Right now we have our application directly pinging the watchdog hardware i.e. there's a watchdog module/component linked into the main executable doing all the things required to prevent a timeout. That was easy to do because it only required us to insert two function calls for (de)initialization and one for pinging inside our mainloop. Unfortunately it also introduced a tight coupling between the main application and the watchdog handling logic (see figure 1).
Other drawbacks of this approach are:
To overcome these drawbacks we put the watchdog handling logic into a separate executable and introduce a small and light-weight layer that wraps the interprocess communication (IPC) which is now required. I'll leave the choice of an appropriate IPC API to you. It should be non-blocking and easy to use (SOAP is probably a bad idea). Certainly we've added slightly more complexity to the big picture (see figure 2) but at the same time it removes any dependencies from the main application to the WDT hardware and it can be run even when there is no watchdog present at all.
Having done these architectural changes we're now ready to introduce more logic to improve the WDT behavior. We can even add a user interface to the newly created watchdog application. Please note, that the term watchdog application/process refers now to a piece of software sitting on top of the WDT hardware.
The nonobvious outcome of inserting a watchdog process between the main app and the WDT hardware is that we're getting an additional high-level fallback layer without degrading the original WDT functionality. Both applications + OS remain under WDT control (remember this is a piece of hardware hooked up to the reset line). This gives us more opportunities to take action when the main app stops pinging the watchdog process e.g. we could try to kill and restart the main application process once and ultimately initiate a shutdown sequence which is healthier than the hard reset. And that's not all! Further enhancements may include:
I'm pretty sure you'll have more features to add, but always remember: Keep it simple! It's definitely not the right application to bloat with features.
Thursday, November 6. 2008
Last month I was asked to specify and setup a computer system that will be used as part of a measurement device. To be more specific, this system is running a software that acquires and analyzes all data from the measurement device and writes it to hard disk. In fact, computer + software are an integral part of the whole device. No software, no measurement.
One of the requirements was to use reliable hardware because the system will be measuring 24/7. The plan was to drop the device at the customers site, connect it to the power supply and let it running for the next three years or so. Since there were no size or power restrictions I specified a small server machine with redundant power supply and hard disks and went shopping...
So far for the hardware. Now we come to the operating system part (I hope you're still reading). The measurement software was written for Windows XP and as you might know Microsoft stopped selling it through the retail and direct OEM channels this year (30.06.2008). OK, the Systembuilder version is still available (until 31.01.2009) and there is the option to purchase Vista and downgrade afterwards, too. But I was looking for a long term option to make the whole system configuration procedure more comfortable and repeatable for future systems.
While digging through some MS sites I've discovered that Windows XP Professional moved from the desktop world to the embedded channel and is now part of Windows Embedded Enterprise. And even more important: sales will continue till the end of 2016. That was obviously the solution I was looking for (see www.xppro2016.com).
Well, the initial purchase through the embedded channel also brought a certain overhead:
But once you've got the OEM CLA signed back from Microsoft it's reduced to the license envelope business known from Windows CE. No further installation media will be shipped anymore. The Embedded OEM CLA also brings some restrictions besides from not using the OS in life-critical applications. Here's one taken from the current CLA:
While this sounds odd at the first moment it's a clever tradeoff from Microsoft. On the one hand they can continue removing XP from the desktop market (to push Vista) and on the other hand industry/OEM customers can still sell their XP-based products for the next 8 years. This is a huge win for industry niche market products and companies with a small number of items sold per year.
For the sake of completeness, here's the full list of all Windows Embedded flavors:
Windows Embedded CE -> for battery operated devices, real-time capable
Windows Embedded Standard -> componentized XP, formerly known as Windows XP embedded
Windows Embedded POSReady -> WePOS (Point Of Service)
Windows Embedded Enterprise -> bit-for-bit compatible Windows XP Professional or Windows Vista
(Page 1 of 1, totaling 2 entries)