EETimes

Embedded Systems November 2000 Vol13_12

Issue link: http://dc.ee.ubm-us.com/i/71849

Contents of this Issue

Navigation

Page 125 of 189

Priority of monitoring task This watchdog scheme is designed on the assumption that the monitoring task is running at a higher priority than any of the tasks that it is monitor- ing. This has one drawback. It means th at it may take up CPU cycles at a time when another task may be trying to meet some hard real-time target. If your moni toring task performs check other than the flags deso ·ibed here, and if those checks consume a lot of CPU cycl es, you may want to consider alte ring this scheme to one where the monitoring task runs at a lower prio• ·i- ty. If you do this you will have to ensure that the watchdog task is sched- uled to run more often so th at it will not be deferred for so long by a high priori ty task that it does not strobe the hardware watchdog in time. For exam- ple you might chedule it to kick the dog every 25ms, even th ough th e hardware watchdog only requires a kick every 50ms. It will then survive a 25ms delay caused at a time when a higher priori ty task is running. In this case, two possibilities exist for a reset. One is that a task blocks and its flag does not get set to ALNE. The monitor task will notice this and cause a reset. The second is that a task loops, preventing the monito• from running, and then the hardware watchdog will eventually bite. Using a lower priority task will improve the ability of high priority tasks to meet their hard real-time tar- ge ts. The disadvantage of such an approach is that you lose the opportu- ni ty to record the identi ty of the task that fails to set its flag to ALNE, which is useful debugging information. I also believe that it is harder to ensure that there are no circumstances where a properly functioning system will lock out th e monitoring task for long enough to get an unwanted kick. When the lower priori ty task is the monitoring task, you will also have to address the possibility that anothe r task may interrupt the monita ring task while the flags are being updated . The a sumptions made 111 th e ·ing task "Concurrent access" secti on no longer hold, and the other task may update the flag that the monitoring task ahs already read, but befo• ·e the monitoring task has a chance to write to it. One option is to use a resource lock o n th e set of flags. Another option is to ensure that examining and updating the flag in the monitor- ing task is performed as an atomic read-and-modify ope ra tion, which may be available as a single CPU opcode, or your RTOS may provide a facili ty to do this. Attention Engineers ... Keil Software C51 is the leading C compiler development suite for the 8051 family of microcontrollers. The features in Version 6 help you write and test your embedded applications faster. Call us to get the latest CD-ROM and FREE evaluation tools. Keil C51 Benefits • 1JVision2 IDE & debugger speed software development and application testing • Web-based updates keep your tools current • Training at our facility or yours shortens the learning curve • Answers to over 1,000 questions are available around the clock on our web site www.keil.com Keil Software, Inc. 1501 1Oth Street, Suite 110 Plano, TX 75074 Toll-Free .... .. .... . 800-348-8051 Phone ............... 972-312-1107 FAX ....... .... .. .... .. 972-312-1159 124 NOVEMBER 2000 Embedded Systems Programming Upgrade Today ... New Features in V6 • 32-bit programs work with Windows 95/98/NT/2000 and support long file names • Three new optimizer levels help shrink program size up to 25% • Integrated source browser • Complete device database sets all compiler, assembler, and linker options for you • Kernel-aware debugging References 1. www.hq.nasa.gov/officelpao/History/ computers! Ch4-7. htm I 2. Lowell, Agustus P., "The Care and Feeding of Watchdogs." Embedded Systems Programming, April1992, p. 38. Acknowledgments The author gives thanks to Bill Gatliff for assis- tance, encoumgement, amd ideas for this article. Conclusion A good watchdog mechanism requires careful consideration of both software and hardware. It also requires careful consideration of what action to take when th e fai lure is detected. When you design with watchdog hardware, make sure you decide early on exactly how you intend to make best use of it, and you will reap tl1e benefits of a more robust system. esp Niall Murj;hy has been writing software f or user interfaces and medical systems f or 10 years. He is the author of Front Panel: Designing Software for Embedded User Interfaces. Murphy's training and consulting business is based in Galway, Ireland. He welcomes f eedback and can be reached at nmurphy@jJanelsoft.com.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12