Time is on my side? It can be if you plan ahead | Cypress Semiconductor
Time is on my side? It can be if you plan ahead
Last week I was in Taiwan. Taking a trip from the US to the Far East always intrigues me, especially because of the way time gets messed about. This time I left late on Saturday (actually Sunday morning, but only barely) and arrived in time for an all-day meeting Monday morning. And at the end of the week, I left late (again) on Saturday and arrived back in Seattle in time for Saturday dinner, 5 hours before I left. And through the entire week I felt like a big clock was always hanging over my head - and now I have to readjust to Pacific Standard Time.
In embedded designs, you can similarly feel like you are under old man time's thumb (sorry for mixing Rolling Stones' allusions) - first the project schedule is tight and then there are likely time-related specifications to meet like response time and refresh time (these are common touchscreen specifications, the difference between these is that response time refers to acting upon a finger and usually includes any low-power timing, while refresh time refers to how fast new data is available in active scanning mode). These two time issues can be related in that ignoring the specifications can cause additional schedule pressure when late in the design cycle the system has to be "optimized" to try and meet the time specs. There is an additional "time" issue in embedded designs, and that is how to deal with the "Watchdog Timer".
So now let's see how all three of these are related and how to keep from feeling thrice beaten.
1) Consider time and timing at the outset. This means designing to meet timing specifications as well as planning/scheduling calendar time to improve or optimize the timing.
2) Keep track of the current time spec performance.
3) Start the design with a watchdog rather than trying to force one in later.
The best place to service a watchdog timer is the start of the main/foreground loop. The tricky part about finding exactly where to service it is that the point of the watchdog is to catch a catastrophic failure (the proverbial "lost in weeds" situation) and therefore must be serviced in a location that won't be executed once the CPU gets lost. In an interrupt-driven system, that means finding a non-interrupt driven function in which to service the watchdog. So if the loop that executes periodically and produces the applications data is triggered by a timer interrupt, is this still the right place to service the watchdog? Yes, but a watchdog alone may not provide complete protection for your system - you may need to consider additional tests such as a stack-level check to indicate/ensure application health.
What should the timing of the watchdog be? It is funny, but so many places in embedded design the number "3" shows up (like in debouncing a switch or action, majority voting, the number of times you can make the same mistake before getting fired) and again "3" is appropriate for watchdog timing: look at the standard loop timing when the watchdog will be serviced and set the timeout to about 3 times the expected timing. Why 3? Any system can have it's timing intermittently perturbed and that alone should not trigger the watchdog. This also helps to alleviate the main error in watchdog timing: servicing the watchdog in multiple places because "normal conditions" cause an occasional timeout. I have seen many examples where under certain circumstances a long interrupt routine causes a watchdog to trip during development.
Common solution: service the watchdog in the interrupt under these conditions. Bad solution.
Better solution: fix the interrupt length and the watchdog timeout so that all normal conditions can be met without tripping the watchdog.
So what about the schedule and refresh timing issues? First, build in benchmarking support for the timing specifications (typically this means bit twiddling) and regularly benchmark this timing throughout development. This will help keep the goals in mind and raise warning flags early on (the specs might be too tight or require more extraordinary measures to meet them). No one want to be blindsided, but with ample warning, expectations can likely be managed (for instance, alpha might promise timing within 2x of the timing spec, beta at 1.5x and by first official release timing is "met", either original or through spec relief negotiations).
And remember: the better you manage "time" and meet expectations this time, the harder the specs will be next time :)