下位机程序架构总结

项目经验：下位机程序架构总结

经过一段时间的项目经历，发现不同的项目之间在程序架构上面有着一些共同点，所以打算写来总结一下，方便以后对比补充和借鉴。
下位机往往都会和上位机通讯，所以我把软件架构总体划分为2个部分：前端通讯部分和后台管理部分。可能这里的比喻不是很恰当，所以我解释一番。回想一下，很多下位机工作在这样一个场景，上位机发一条指令，下位机执行，然后反馈结果。所以，前端通讯代表了下位机与上位机之间通讯的部分，而后台管理代表了动作的执行或者反馈给上位机需要的数据。
刚才说的还是很笼统，下面细分一下。
前端通讯：作为整个项目的通讯架构，必须要有可靠的职能划分。我一般将通讯架构划分为：接收、解析、处理，返回四个部分。
1）接收：保证接收数据的完整性，为接下来的解析提供数据。
2）解析：对接收到的完整数据进行解析，解析方式按照协议规则即可，这个操作之后，得到的是指令字与数据，它们将为接下来的处理提供依据。
3）处理：经过上面2个操作以后，我们得到了需要执行的指令和数据，其实这里的数据有时候为空，看具体指令需求了，相当于入参。我们一般会根据不同指令做出不同的处理，有时处理是驱动一个电机，有的处理是反馈一些数据，那么这就需要整个架构的另外一个部分来参与了，即后台管理部分。
4）返回：处理以后，需要将数据返回，可以是指令回复或者是上位机所请求的数据。
后台管理：所谓后台，一般处于长期运行的状态，下位机往往会接很多传感器，那么后台的主要职能为:数据的采集、加工、更新、存储以及动作的执行。往往它会处于数据准备阶段，当上位机需要反馈数据时它将数据反馈，当上位机需要执行某个动作时，它会执行某个动作。
以上就是我总结的一般下位机程序架构，2个部分：通讯部分和后台管理部分。
接下来，我想接着总结下项目中往往遇到的缓存机制。项目中往往会遇到这样的情况，在某段时间内上位机会频繁地发送指令或者数据，如果不添加缓存机制那么会造成数据覆盖或者丢失。
那么在什么前提下缓存才有意义呢？可能你会说这是句废话，前面不是说防止数据丢失嘛？其实不是，因为有时候即使你添加了缓存也未必能解决数据不丢的问题。如果把数据发送方比作“生产者”，把数据处理方比作“消费者”，那么缓存机制可以发挥作用并且有意义的前提条件就是：在某段时间内，生产者的速度要大于消费者的速度，而在总体时间内，消费者的平均速度却要大于生产者的速度。试想，如果消费者的处理速度一直比生产者的速度快，那么根本不需要缓存，所以缓存存在的意义是某段时间内，生产者生产的数据激增，消费者一下子消费不完，所以要缓存起来慢慢处理。那么问题来了，这个慢慢可以无限慢吗？当然不行，缓存都是有界限的，所以你必须在缓存池未满之前将数据消费掉，那么就需要消费者的平均速度要快于生产者的速度，否则一定会产生数据溢出丢失的情况。
上面说了，缓存有意义的前提条件，下面说一下如何进行缓存。再说这个之前，我们先谈一下如何保证数据接收的完整性，如果数据接收不完整，缓存到的就是废掉的数据。
一般保证数据接收完整可以有2种方法（我就知道2种），一种是延时等待，一种是结合首尾标记判断。延时等待的方案为判断数据接收的连续性，即从接收到第一个字节开始，如果在一段时间内没有再接收到数据，则认为数据接收完毕。而结合首尾标记判断则为从首字节开始接收，到尾标记字节停止接收，而在此以外的数据都将被抛弃。这2种方案，我个人更喜欢第二种，因为它更可靠，简单，延时总会有不确定性。
谈完数据接收完整性以后，我们再回到刚才的缓存机制。既然要缓存，那么必须要有缓存池，那么你会采用什么样的数据结构来建立缓存池呢？普通的数组？还是队列？当然这里的队列也是顺序表队列，而非链式队列，单片机往往裸奔，没法malloc。我一般会根据情况选择，如果数据存储在RAM里，我会选择队列，因为队列可以进行先进先出，比如尾部入，首部出，这样可以最大程度的使用缓存池，但是数据需要不断的搬运，比较耗费资源，比较而言，如果选择普通的数组进行缓存，那么数据只要不断的往后加载，即使前面的数据处理完毕以后也没有及时清除，然后数据处理完后再从头缓存，这样，在操作上减少了数据的搬移，但是如果处理不当或者数据过多时会造成混乱，它也没有重复利用缓存空间，造成浪费。如果你的数据是存在外部Flash中，那么还是使用类似数组的办法吧，可以定义2个索引（上下指针），上指针负责加载数据，下指针负责处理数据，当首尾指针一致时认为数据处理完毕，然后从头缓存，否则你要像在队列里那样不断的从flash里搬移数据，将耗费大量时间，w25q128对一个扇区的写时间网上说是300ms，具体没测试过，但是确实很耗时间，不建议使用队列的方案。
好了，以上是项目总结的一些经验，供自己以后学习总结，必有错误之处，仅供参考。