个人观点只能定时“触发事件”的定时器不够灵活目前的定时器是内部实现是定时触发事件即“往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 消息订阅机制处理同一个消息发送给不同的任务LOGmsg删除 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不应该被停止memory - 堆堆空间被划分为两部分小块内存和大块内存。小块内存用于频繁分配的小数据块而大块内存则用于较大的数据块分配。这种设计减少了内存碎片化提高了分配连续大内存块的成功率。基于OSAL的嵌入式裸机事件驱动框架——内存管理osal_memory_stm32 osal-CSDN博客数据对齐Header [申请的size ,经过x对齐处理 ]对比 freertos heap_4其他TI-OSALosal_on_pc它是原版的从ti-osal中剥离的里面也收集了很多公共的模块还有关于osal的文档tslf 堆库TLSF与FreeRTOS-heap4对比 | 耀眼的大神 (dazzlingokami.github.io)eOSAL-3.0耀眼的大神 (dazzlingokami.github.io)task独立的消息队列消息头消息头的三个参数 分别送给了 消息处理函数timerflag 的位定义1中是硬件中调度2是软件延时调度作者为了这个“延时”问题下了不少功夫我的理解如果一个任务需要延时裸机处理方式有两种1.使用状态机等待延时-分状态多2.使用PT的delay方式实现等待-好理解阅读代码友好直接“穿过”任务轮询的主函数不被打断end