nevermindzzt / cpost Goto Github PK

我看readme中说支持keil/iar/gcc，然后在源代码中看到如下代码段：
#elif defined(__ICCARM__) || defined(__ICCRX__)
想问一下，CCRL是否支持呢？
瑞萨部分芯片是用CCRX，还有一些用CCRL，另一部分是ARM，我正好用的是CCRL……

Hello,有demo工程供验证吗？

发现这两个功能好像，都是为了将为了去除模块间的耦合，用这种“注册-回调”或者说“广播-事件”模型来解耦

两者都是在编译时映射事件-回调，cevent借助ld文件在运行初始化来达成，lwevt则通过lwevt_t结构体在编译时展开来达成；

目前感觉cevent相对于lwevt的缺点是需要移植，依赖链接脚本，而lwevt则只要是ANSI-C就可以；
而event在传参这块比lwevt要优雅些，或者说更加灵活些，而且lwevt目前只能注册一个回调，接收多个事件。

但是，两位作者虽然都是为了解耦，但是举出例子的场景不太相同，lwevt举的是编译时设置多个事件-初始化时注册回调-后续任何事件发生都可以回到回调函数中；cevent则是编译时绑定事件-回调【此时就可以将事件宏定义抽象为执行函数的句柄，发送这个事件即可以触发绑定的事件】，而后使用中对应使用即可。

这里有些疑问，cevent可以将多个事件注册到同一个回调函数么，如果可以，应该也可以实现lwevt的场景例子

• https://github.com/MaJerle/lwevt

cposhHandlers[]数组名为何不是cpostHandlers?
看起来有点不爽呀.

cpost(test_cpost, .param = &s_Param, .attrs.flag = CPOST_FLAG_ADD_NEW);
例如cpost调用函数如上，这里有一个问题就是
.param = &s_Param
这里s_Param是一个静态变量，关键点在于
当还未来得及回调 cpostProcess();的时候，s_Param的值就发生了改变的话，那么等到cpostProcess回调时是传入执行函数的参数
也就发生了改变，再者如果s_Param是某个函数内的非静态变量，那么当cpostProcess回调时传入执行函数的参数应该是不可预知的，
因为.param最后记住的是一个地址。

是否考虑在cpost内部增加一个s_Param的值的副本来实现入参值的保存？

`CPOST_MAX_TICK - cposhHandlers[i].startTime > cposhHandlers[i].delay
                ? tick - cposhHandlers[i].startTime >= cposhHandlers[i].delay
                : CPOST_MAX_TICK - cposhHandlers[i].startTime + tick >= cposhHandlers[i].delay`

这一段，当CPOST_MAX_TICK - cposhHandlers[i].startTime<cposhHandlers[i].delay时后面的CPOST_MAX_TICK - cposhHandlers[i].startTime + tick >= cposhHandlers[i].delay出现了问题。

假设CPOST_MAX_TICK=10，cposhHandlers[i].startTime=8，delay=4。

那么当tick=9的时候，10-8+9>4,返回真。按理来说这时应该返回假吧。

CPOST_MAX_TICK - cposhHandlers[i].startTime + tick >= cposhHandlers[i].delay这一段是不是该替换为(tick>cposhHandlers[i].startTime ? tick-cposhHandlers[i].startTime: CPOST_MAX_TICK - cposhHandlers[i].startTime + tick) >= cposhHandlers[i].delay

大佬可以实现一个简单的linux下的测试程序吗?看了您的demo有点不太会用

这个cpost相当于把中断或者对于时间不敏感的处理抛出类似于进入队列的形式，在mainloop中不断从这个队列中取出执行，然后cevent是不是类似于把需要第一个时间段处理的任务在各个c文件或者需要的地方进行注册，也类似于上述的队列，然后把第一步需要执行的操作，注册到任务一队列，第二部执行的注册到任务二队列，然后再main中按照任务顺序执行，如果需要重复，就把需要循环的任务注册到一个队列里面。这部分关于初始化的解耦，我感觉用__attribute__((constructor(pority)))可以同样的实现，而重复需要mainloop的任务就用cpost这样一个压入队列的操作就可以 了？

void cpostProcess(void)
{
size_t tick;
for (size_t i = 0; i < CPOST_MAX_HANDLER_SIZE; i++)
{
if (cpostHandlers[i].handler)
{
tick = CPOST_GET_TICK();
if (cpostHandlers[i].time == 0 ||
(tick >= cpostHandlers[i].time
? CPOST_GET_TICK() >= cpostHandlers[i].time
: CPOST_MAX_TICK - cpostHandlers[i].time + CPOST_GET_TICK()))
{
cpostHandlers[i].handler(cpostHandlers[i].param);
cpostHandlers[i].handler = NULL;
}
}
}
}

CPOST_MAX_TICK - cpostHandlers[i].time + CPOST_GET_TICK()
这一个判断条件是当 tick<time 时执行，判断是否计时溢出。
这里的话 max >= time 肯定会为真，而只有 max-time=0 且 tick=0 时为假，
这会造成误判吗？
这里不会造成误判的前提是调用此函数的周期必须小于等于systick的周期吗？