前后台系统的精髓

有个产品负责把RS485上的通讯转到电力线（PLC）上。这样这个产品主要由两个任务组成：PLC通讯及485通讯。

第一个工程师在裸机上实现了功能！因为当时项目忙，没空检查其程序。（唉，现在想起来，公司对软件项目没有一套成熟的管理制度，导致那时项目管理非常吃力！）

因为公司待遇低，第一个工程师走了。项目转给第二个工程师时，工程师报告说两个通讯老有冲突：忙485时，忙不了PLC。 一检查：原来程序里几乎都是在main函数里用分时实现了两个通讯，还有一大堆的delay调用。于是给第二个工程师指示：这样不行的，通讯应该尽量使用中断来收发最低层的数据！
于是第二个工程师开始改程序。完了报告说：不错，有进步了！

因为公司待遇不理想，第二个工程师很快也走了 （公司把开发工程师的薪水跟生产线工程师来比－－你们研发部工程师的薪水是我们公司所有工程师里最高的！）。项目转给了第三个工程师时，工程师报告说有时485发送的数据PLC还是不理会！一检查：原来第二个工程师优化程序时竟然把所有的PLC的接收代码放进了PLC的接收中断程序，把所有的485接收代码放进了RXD中断程序。于是给第三个工程师指示：紧急的事务一定要用中断处理；中断只处理紧急事务！

其实，这是前后台系统最典型的应用（也是任何一个系统必需要注意的）：紧急的事务一定要放到前台（前后台系统里称中断程序是前台：可实时处理的），让所有不紧急的事务放到后台处理（前后台系统里称主程序里的死循环为后台：在后面处理不紧急事务的）。这样，上面的程序就是这样了：

主程序：系统初始化－》使能485发送及接收中断－》使能PLC发送及接收中断－》主程序的死循环。
死循环内容：
1.如果485接收完成一个数据包：处理它，处理完后可能会开启一个数据包的发送，开启发送中断，让发送在前台进行；
2.如果PLC接收完成一个数据包：处理它，处理完后可能会开启一个数据的包的发送，开启发送中断，让发送在前台进行；

485接收中断：把串口接收里的一个字节读入到内存（也可能是几个字节，这要看MCU的支持）； 如果这是一个包的最后一个字节，用全局变量／信号量的方法通知后台主程序去处理；

485发送中断：把下一个字节装入串口发送寄存器里（也可能是几个字节，这要看MCU的支持）；如果这是一个包的最后一个字节，关掉自己的（中断），以免下次再进入。

PLC接收中断：把IO里一个bit的数据读入到内存；如果这是一个包的最后一个位，用全局变量／信号量的方法通知后台主程序去处理；

PLC发送中断：把下一个位从IO口送出；如果这是一个包的最后一个字节，关掉自己的（中断），以免下次再进入。

这样，最紧急的收发位／字节都是在前台中断完成；对整个包的处理都在后台主程序完成。没有delay，没有干扰，两个通讯完美地融合在一起！

紧急的事务一定要用中断处理！中断只处理紧急事务！