阻塞任务环境运行框架的构建

前段时间，接手一个项目，刚开始看了下代码框架，一点时间片的思想都没有，有点类似于操作系统样的，一个事件一个while，这样导致看到代码里面的喂狗处很频繁，而且代码重复率很高，整个代码的耦合度非常之高，改动一处，可能就会影响另一个地方。由于它始终不是一个操作系统调度，而是靠由一堆事件标志来进行切换，最终还是前后台轮询框架，由于接手时，需要增加WIFI功能框架，最开始我想使用时间片调度框架嵌入到里面，应该是没什么问题的，后来发现，随着功能需求的增加，从而导致这个框架已经不能很好的适用，一方面是越来越冗余（主要是运行的WIFI运行状态机加入多条事件后，逻辑变得混乱不清），另一方面，我所用的时间片框架竟然会影响原来的框架（主要是放在中断里面的任务调度器），没办法，项目变得愈来愈紧急，而测试组一方面提出新的要求，一方面又测试出新的BUG（当然原来的代码就有许多逻辑BUG），最后我就按照之前在一个事件中构建的一个框架，发现它很兼容或者很适合这种代码框架，于是我就重整了代码，摒弃原来写得框架代码，也是没办法，经过几番测试后，发现运行良好，且代码的维护性大大提升，代码间的耦合也降低了不少，随后就正式应用新的代码发布中，终于项目接近了尾声，完美的结束。
最近，发现原先的代码框架很好，但写法还是有点繁冗，故思之为之改进，改完后下载测试良好。现贴如下：

其实博客原先也写了这篇，当时也是最开始记录了思想，里面也包含了一点错误，遂在此重新写之。
这份阻塞式框架我觉得应用场合还是比较少，我个人在裸机情况下，还是更热衷于开放式的时间片调度框架，其代码耦合度较低。
另外我觉得在接收别人的代码时，我觉得还是最好先了解一下别人的框架，以及构建一个能够兼容别人代码的框架是很重要，要不然的话，为了填代码而填代码，补BUG而补BUG，那将是个非常头疼的事情。一旦解决框架问题，问题也随之解决。