嵌入式软件时序设计相关的问题

　　软件时序设计相关的问题时序问题是最容易出问题的地方，“时”代表时间顺序和时效性，一旦执行顺序错乱，或执行过慢失去时效，就会导致错误。

　　消息的串行化处理

　　每个任务、线程，只能按顺序的处理串行的消息，然而，其他线程发送过来的消息并不是串行发送的，不同线程都是并行、异步发送消息的，这会导致线程在没有处理完一个消息，另一个消息又回来了。如何把外部的并发消息转换成线程的串行处理呢？

　　每个任务、线程都应有一个消息队列，外部线程向消息队列中发送数据，目标线程从消息队列中读取消息，这样所有的消息被串行在消息队列中，线程就会串行的处理每个消息，只有当一个消息处理完（函数调用返回）时，才会处理另一个消息。参考《嵌入式软件的设计模式（上）》中的 第3.3节 “队列模式”。

　　超时或消息丢失引发的问题

　　一个任务、线程给另一个任务、线程发送消息，等待对方的应答，有时候对方忙，发送时队列满发送失败，或者接收方没有处理回复，等待一段时间后空闲了才处理该消息并应答时，但对于发送方已经超时。发送方超时，就需要进入异常处理。这里容易出问题，它可能会引发一连串的异常处理反应，也有可能影响后续的正常消息的处理。

　　消息丢失是必须考虑情况，发送方不能假设接收方一定能够收到消息，也不能假设接收方一定能够及时的回应，必须充分考虑到消息因为传输的问题丢失或对方忙，没有及时回应的情形。

　　消息丢失就容易产生理论上该执行的动作没有执行，或者消息里面动态内存未释放。或者消息处理慢导致对外设的控制延迟产生异常，曾经出现共享单车锁里面的马达停止消息处理不及时导致车锁无法再次上锁。尤其处理通信时序要求严格，或外设控制要及时的场景需要注意。

　　性能本身问题

　　数据处理尤其是复杂算法耗时，导致消息处理不及时，最终对外设的控制或者通信交互时序状态延迟，产生异常。这种只能优化算法，或对时序部分单独特殊处理，不考虑设计模式保执行效率。或者评估阶段就选择性能资源更佳的硬件方案。

　　异常处理不充分问题

　　软件设计一般是考虑正常流程，然而实际运行中，并非是理想状态，系统总会遇到各种异常，健壮的系统，能够充分考虑到各种异常情况，一旦异常发生，程序也不会轻易崩溃。

　　超时：增加超时定时器事件以及事件处理，不能假设对方一定应答消息。

　　空指针：不能假设一定能够申请到内存，要考虑到返回为NULL的情形，通过指针访问内存对象时需要及时的检查指针是否为空。

　　并发访问：在并发执行的系统中，如果要访问全局变量，不能假设只有一个线程访问全局变量，需要通过锁对全局共享资源进行加锁，特别是要访问全局的数据结构。

　　消息队列：不能假设消息队列始终有效，要考虑消息队列满或空的情形。

　　设计：在软件设计时就考虑软件的异常处理机制，功能层面就支持异常记录、售后调试的需求，而不是把这个工作留给编程人员。