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