之前在做一个产品，里面有多块板卡，每块板卡负责不同功能，但是对外是一个独立的设备。

把我折磨的个够呛。

之前也没经验，设计的的方案是每个板卡都负责各自的业务逻辑。 然后上报给带WIFI模组的板卡，再统一上报状态参数。

现在项目一步步推进，已经木已成舟了。 我发现这个设计哲学上，真的巨坑无比。花费了巨大的精力在维护通讯上。

可能APP下发一条控制命令。它的路线是这样的(括号内为通讯方式，XXX为公司内保密的一种单工的通讯方式，延时约为有200ms)

APP->(WIFI)->BL602->(UART)->MCU1->(XXX)->MCU2->(485)->MCU3 每个通讯之间都有防丢而做的应答机制，没有应答会重发。这个导致数据有点多。

这个路径中最坑的就是XXX这个通讯方式。导致了两面数据的处理能力不同(经过XXX之后，数据最快也只有200ms一包了)

然后APP组的同事是不会给你做任何处理的。我得自己做一个逻辑去防止数据泛洪。因为业务逻辑是在不同的板卡内各自处理的。 处理完之后还要返回状态。导致整条通讯链路的数据量对于XXX来说有点多。它还是单工的，无法同时收发。

经验

我感觉之后这种类似的产品，最好把所有的业务逻辑都放在MCU1上处理，后面的板卡都只当做一个没有大脑的外设。 只能通过查询命令，去轮询状态。这样子对写代码来说会比较友好。

但是现在想改动，为时已晚，已经改不动了。