当前位置：首页 > news >正文

【学习笔记】TI-OSAL

news 2026/6/18 16:56:29

个人观点

只能定时“触发事件”的定时器不够灵活

目前的定时器是内部实现是定时触发事件，即“往xx任务发送xx event”；

如果设计成通用的软件定时器，定时回调的方式；
在回调函数中，不管是定时触发事件还是定时做什么动作；

这样就比较的灵活；

任务初始化

void osal_Task_init(void)只能在osal_add_task完成之后实现任务的初始化；无法实现动态的添加任务；比如（某个任务状态就是增加一个周期的子任务做某个检测）

事件标志位

因为没有办法知道相应了哪个事件；所有将没有相应的事件返回，用于下一次处理；

消息的队列的方向

-fifo enqueue = 入队 = 添加到队列尾部
- fifo dequeue = 出队 = 从队列头部移除

消息队列的设计

“用户透明的队列”，状态了消息头的设计

系统消息的理解

typedef struct { osal_event_hdr_t hdr; uint8* data; } osal_sys_msg_t; //默认系统消息结构体

上述结构的osal_event_hdr_t hdr; 实际使用了msg->hdr.event起到了定义消息类型的作用；

msg->hdr.status 没有起到任何作用；

对于oasl_sys_msg_t 不是系统级别消息，而是任务之间的数据消息；

那么对于“数据消息”，重点是定义数据消息的类型，以及数据消息的内容；
至于数据消息的内容，一种是值传递，即直接将消息的值，放在消息队列中；另一种是地址传递，即将消息数据的地址作为消息，与消息类型一起传递；

消息查找

osal_event_hdr_t *osal_msg_find(uint8 task_id, uint8 event)
找到与task_id 和 event相匹配的消息头；

其中这个event 就是“消息类型”

定时器

taskid + event 一起定义一种定时器；

消息头的长度信息

没有作用；

消息头需要表征：从哪里来，到哪里去，什么消息类型

TODO

+ 消息订阅机制，处理同一个消息发送给不同的任务；

LOG

msg

删除 uint8 osal_msg_send(uint8 dest_task, uint8 *msg_data)中对id最大值的判断if(dest_task >= tasksCnt)；改判断通过if(SUCCESS != osal_set_event(dest_task, OSAL_MSG_EVENT))实现；

删除osal_event_hdr_t

删除osal_sys_msg_t

删除 osal_event_hdr_t *osal_msg_find(uint8 task_id, uint8 event);

删除 osal_msg_hdr_t的len 字段

task

删除 uint8 tasksCnt = 0; 因为task_id 计数器可直接表征任务数量；

删除了task_active的变量；完全可以用局部变量实现对应的功能；

修改add_task为create_task；

在 add_task的地方增加 return TaskNew->pfnInit(TaskNew->taskID);

修改了 uint8 *osal_msg_receive(uint8 task_id) ；listHrd 给的值始osal_msg_hdr_t；而不是像其他一样使用“消息体”的地址

timer

修改 event_flag 为 event_mask 体现位掩码的概念防止理解出错

修改 osal_start_reload_timer 为 osal_start_repeat_timer ，方便理解

修改 osal_update_timers为 svoid osal_update_ticks(uint16 ticks) //ISR ;意味更新tick时钟，该函数通常用在isr中；需要与osal_timer_update分开使用；一个是更新tick ；一个是在主循环中检查是否有要触发的event ；

删除 osal_timer_hw_setup 因为没有使用的场景；低功耗场景直接通过关闭硬件timer 实现osal_timer的停止计数；其他场景下，系统暂停时，osal_timer不应该被停止；