给你说一个方法,你定义一个结构体,比如:
typedef struct{unsigned long err_trig_ms; //开始超过额定值的时间点,只起记录作用用来产生err_commit_msunsigned long err_commit_ms; // 等待确认故障的时间点,由触发时间点确认uint8_t err_id; // 每个错误的id,建议使用enum定义好uint8_t is_err_trigged; // 是否此错误已经被触发}PassLimit_Fault_Info_t;这个结构体每个故障定义一个。
typedef struct{uint8_t next_trig_id = 0; // 0表示无故障,其它id表示下一次需要检查的fault的err_idunsigned long next_check_point; //下一次需要比较的时间点,由next_trig_id确定uint8_t on_fault_cnt; // 正在发生等待确认的故障id,故障已经清除或者已经确认的不再此列表中不计算}FAULT_MGMT_t;static FAULT_MGMT_t sys_fault_mgmt; //系统故障管理结构体每次故障被触发的时候就刷新当前发生故障的结构体,然后更新一下sys_fault_mgmt。比如当前的sys_fault_mgmt.next_trig_id不为零,就比较一下当前发生的故障要检查的时间点是否早于sys_fault_mgmt.next_check_point.如果更早就用这个故障的特征刷新。如果更晚就不用刷新。总之在故障产生、清除和确认的时候都刷新sys_fault_mgmt。而每次1ms中断的时候就只比较sys_fault_mgmt上面的事件。这个比较很简单不会耗费很多资源。
个人觉得当故障是这样的时候,裸机程序可以这样管理故障。当然如果你的系统有现成的链表。那么用链表的方法可能更好。就是说每次将最先需要检查的id放在链表的头部。依照事件顺序,插入新发生故障的链表可能会更好。
给你说一个方法,你定义一个结构体,比如:
typedef struct{unsigned long err_trig_ms; //开始超过额定值的时间点,只起记录作用用来产生err_commit_msunsigned long err_commit_ms; // 等待确认故障的时间点,由触发时间点确认uint8_t err_id; // 每个错误的id,建议使用enum定义好uint8_t is_err_trigged; // 是否此错误已经被触发}PassLimit_Fault_Info_t;这个结构体每个故障定义一个。
typedef struct{uint8_t next_trig_id = 0; // 0表示无故障,其它id表示下一次需要检查的fault的err_idunsigned long next_check_point; //下一次需要比较的时间点,由next_trig_id确定uint8_t on_fault_cnt; // 正在发生等待确认的故障id,故障已经清除或者已经确认的不再此列表中不计算}FAULT_MGMT_t;static FAULT_MGMT_t sys_fault_mgmt; //系统故障管理结构体每次故障被触发的时候就刷新当前发生故障的结构体,然后更新一下sys_fault_mgmt。比如当前的sys_fault_mgmt.next_trig_id不为零,就比较一下当前发生的故障要检查的时间点是否早于sys_fault_mgmt.next_check_point.如果更早就用这个故障的特征刷新。如果更晚就不用刷新。总之在故障产生、清除和确认的时候都刷新sys_fault_mgmt。而每次1ms中断的时候就只比较sys_fault_mgmt上面的事件。这个比较很简单不会耗费很多资源。
个人觉得当故障是这样的时候,裸机程序可以这样管理故障。当然如果你的系统有现成的链表。那么用链表的方法可能更好。就是说每次将最先需要检查的id放在链表的头部。依照事件顺序,插入新发生故障的链表可能会更好。
举报