过度抽象

在单片机领域有时候要防止过度抽象。 刚才在拉屎的时候思考到了这个问题。 起因之前设计的一个带重发通讯框架。 我们知道，为了保证通讯的准确性，最好的方法就是带重发。 所以我们需要一个重发+根据应答停止重发的机制。

之前做了一个，能够适配不同的协议的重发框架。但是是在半双工总线上使用的。并且是同步的。 (同步就是指，我这个设计的时候是一问一答形式，如果没收到应答，会继续重发，直到达到最大次数。)

在半双工总线上，这个方案是适用的。但是对于全双工非总线的地方，这个通讯方式显得很慢。 我希望像TCP那样子选择性重发，先全部发送，然后看看是哪几包没收到应答，再根据这几包去重发。而不是发一包，等多少毫秒，然后没收到应答，再去重发这包。

这个就导致了原来的代码不适用。

拉屎的时候就思考了一下这个问题。 我的感觉是，不能渴望一个代码框架去解决所有的问题。应该用一份新的代码去解决这个问题。

然后我突然问自己，为什么要把协议和重发框架解耦合？有必要吗？ 真的有很多不同的协议等着我适配吗？

于是，我发现之前的设计的带重发的框架也没必要。我实际上用到的协议就一个。 为了解耦合，代码必然写的比较冗杂。因为保证不同的协议的适配性，所以无法精简代码。 实际上我现在想想，直接把带重发这个机制做在具体的协议的内部，可能是更好的解决方法。

20250802更新

发现了这种做法的一个问题。 当抽象出两个同样协议的虚拟设备在同一个硬件串口的时候，由于重发逻辑在各自内部实现，导致两个虚拟设备之间的发送帧时间无法互相感知，用的又是同一个串口，就出现了粘包的情况。 协议和重发框架还是需要分开比较好。