电子发烧友App
在嵌入式系统中为提高微型机系统的可靠性和安全性, 常用的方法就是使用“看门狗”。看门狗分硬件看门狗和软件看门狗。硬件看门狗采用“看门狗”电路, 通过定时器, 对微型机任务即“喂狗”在运行时间上加以约束, 任务必须在最大指定时间范围内完成, 否则重启系统。软件看门狗采用处理器内部定时器, 把任务的理论最大运行时间作为时间约束, 如果该任务超过了这个时间跨度, 则强制退出本次任务。上述看门狗采用的是单任务的顺序机制, 容易实现。在多任务系统中情况稍为复杂, 如果每个任务都像单任务系统那样,只要有一个任务正常工作并定期“喂狗”,看门狗定时器就不会溢出, 而只有所有任务都出现问题时, 定时器才会溢出。重庆师范大学叶帮利老师曾在windows 系统中探讨和解决了这个问题[ 1 ] , 在嵌入式系统中也有人曾谈到过[ 2 ] , 但是却没有具体实现方法的叙述。
文中把u C / O S - I I 操作系统移植到PHILIPS 公司生产的LPC2132 内核中,基于系统的消息机制和优先级权限, 设置了一个优先级最高的任务作为监视器对微型机上运行的所有任务进行监控, 只要一个任务出现故障, 该监视任务就延迟喂狗, 使定时器溢出, 重启系统, 以保障微型机及所有任务处于长期稳定的运行状态。
1 系统概述
1 . 1 硬件和开发环境简介
把uC/OS-II 操作系统移植到LPC2132的开发板中。LPC2132 是一个支持实时仿真和跟踪的32 位ARM7TDMI-STM 核微处理器,带64kB 高速FLASH 存储器,4 个通信接口, 2 个32 位定时器, 1 个10 位8 路ADC,2 个硬件接口,47 个GPIO 以及多达9个边沿或电平触发的外部中断, 完全能满足一般应用程序及扩展的需求。
uC/OS-II 是一个抢占式多任务实时操作系统, 其源代码公开、可移植性强, 有着易用性、易开发性和普及性的特点。uC/OS- Ⅱ最多可以管理64 个任务, 这些任务通常都是一个无限循环的函数。在目前的版本中, 保留了优先级为0 、1 、2 、3 、OS_LOWEST_PRIO-3、OS_LOWEST_PRIO-2 、O S _ L O W E S T _ P R I O - 1 、OS_LOWEST_PRIO 的任务,所以用户可以同时拥有5 6 个任务, 足以满足用户设计的各种要求。
1 . 2 系统实现的功能
在多任务系统中, 往往希望有一个任务出问题时把该任务重启, 而不重启整个系统, 以达到不影响其他关键任务运行的目的, 在多次重启该任务无效时再重启系统。当系统的主程序出现错误或者系统硬件出现问题时重启系统。基于以上分析设计的看门狗主要实现以下功能。
( 1 ) 当某个任务出现异常时, 由软件看门狗重启该任务。
( 2 ) 当多次重启某一任务失败时, 重启系统。
( 3 ) 当操作系统本身出现异常时, 或者系统硬件出现异常时, 由软件看门狗或者是硬件看门狗重新启动微处理器。
2 多任务看门狗监控原理
结合LPC2132 内置硬件看门狗和uC/O S - Ⅱ操作系统, 设置了一个优先级别最高的任务作为监视器监视各应用任务是否正常运行, 该监视器称为软件看门狗。该任务对每个被监视任务都设定一个计时器, 被监视任务在设定的时间内对对应的定时器定时清零, 称为“喂软狗”。在被监视的任务都正常工作的情况下, 软件看门狗对内置硬件看门狗定时器周期性清零,称为“喂狗”。如果被监视任务群某个任务出现故障, 不能在设置的时间内对软件看门狗“喂软狗”, 与之对应的定时器溢出,系统内核发送指令, 把该任务的堆栈地址指到其起始地址, 复位该任务, 如果在设定的次数内不能够有效启动该任务, 则延时“喂狗”, 硬件看门狗计数器溢出, 重启系统。另外当监视器任务本身出现故障时,也不能及时对看硬件看门狗定时器清零,重启系统。
3 软件实现
3 . 1 应用任务与软件看门狗之间的通信
在多任务软件看门狗与各应用任务间之间进行信息传递时, 每个应用任务都会对监视器发送运行状态消息, 监视器任务也要对每个任务发送消息。在应用任务较多的情况下, 如果采用信箱进行通讯, 会造成大量无效操作, 也使得编程变得繁琐, 所以在监视器任务中采用消息队列来实现与各应用任务间的消息传递, 而在各应用任务中设置两个信箱, 一个用来对监视器消息队列发送消息, 一个用来接收监视器任务消息队列发送的消息。当某个应用任务在执行出错时,调用OSQPost()函数向监视器任务消息队列发送消息, 监视器任务通过调用OSQPend()函数从消息队列读取该消息,然后调用OSMboxPost()函数向该应用任务的消息接收信箱发送代表不同意义的消息,该任务调用OSMboxPend()函数从信箱中读取该消息后执行相应的操作。
3 . 2 多任务软件看门狗的实现
工商网监
评论