🤴🏽 😖 🤥 数据传输民谣 🧑🏿‍🤝‍🧑🏿 🤹🏽 ✏️

在文本出血的第一行中，我想说以下几点：关于这一点已经写了很多，我也会写我的愿景。用于传输信息的标准接口很棒，但就我的需求而言，它们不能提供足够令人满意的（良好或几乎）数据传输。我将尝试进行一些补充，以使其达到适合我的状态。

有两个或更多设备之间的距离必须足够大（1-100米），并且必须在这些设备之间传输数据。检查了一些接口（rs232 / 422/485，I2C，以太网）后，我得出的结论是，要么它们不能保证明确的数据传输，要么我也不喜欢很多电线，它们也没有给出信息被接受的答案。我决定以RS485接口为基础-它的优势远非两线，可以同时连接一堆设备，这很简单（UART）几乎在任何控制器上。

在我的情况下，领导其余奴隶的经典方案1对我来说很合适。消息传递算法如下：数据以交换周期传输，一个交换周期包含一条消息，该消息从主机发送到从属设备，作为响应，主机接收到从属设备的消息，其他所有消息均保持沉默。在同一基础上，实现从属设备的数据请求。

一个交换周期。

为了满足我的数据传输需求，我只需要解决两个问题。问题一：检查发送的字节是基于RS-485接口本身，但是不能保证可靠地发送字节-如果在接口本身中找到一个字节，则该字节会从接收到的数据中丢弃，但是仍然有可能传输错误的字节-如果它已更改（变坏））一个字节中偶数个位。即需要检查传输的字节数和传输数据中字节的有效性。

问题二：接收对发送的响应消息。

关于第一个问题：提出了这种方案：初始字节，
整个消息中传输的字符数的字节，别的东西，校验和字节（BCS），最后字节。

注意：应将校验和字节视为模2。

根据提议的方案，可以判断出如果答案未返回，则跟随者不可用。在这种情况下，当损坏的消息到达关注者但他没有响应，或者消息到达他并发送答案，但答案变差而领导者忽略它时，可以使用选项。

为了解决这个问题，它被接受了：如果答案没有（或者是但不可靠），则重复（无精神错乱的次数）重复当前的交换周期。在这里可能会发生以下错误。假设我们发送一条命令告诉设备您需要将音量调大+1个单位。当消息到达从站时，他执行命令以调高音量并发送响应“好，我按您的意愿做了”，但是结果可能是答案不正确，并且演示者不理解该命令已被执行，然后再次发送消息。结果，在从属端接收到命令后，该音量将已经以+2个单位相加。为了避免这种现象，习惯上引入消息差异的标识符（NS-消息编号）。如果消息号是重复的，则这是重复的消息，并且不需要执行指定的命令，但只需发送上一条回复消息。

我在这里还输入了另外两个参数-这是向其发送数据的设备的编号（代码），以及指示应执行哪个命令（或消息中包含哪些数据）的编号（子代码）。

结果，我将所有这些放在一起，并以将继电器的阈值提高5摄氏度并从从属设备获取当前温度为例，以一个交换周期为例：我

从主设备生成传输的数据：

收到消息后，从属设备查看2个字节，哪里是发送的字节数，如果发送的字节数等于接收的字节数，则消息没有丢失字节，那么如果它='$'，则我们查看起始字节（字符），如果= =则查看结束字节（字符）＃'-这是来自的消息前往奴隶。

我将立即考虑从主站到从站的可能的消息选项，该消息的起始和最终字节有错误，以及消息中的字节数有错误的选项。我将立即保留3个我认为正确的2和3的参数值，即如果3个参数中有2个可能一致，则认为该消息有效。

1.开始字节='$'，接收的字节数= 7（发送的字节数= 7），结束字节不等于'＃'；
2.初始字节不等于“ $”，接收的字节数= 7（发送的字节数= 7），最后的字节=“＃”；
3.起始字节='$'，接收的字节数= 7（发送的字节数= 7，字节数不是7），最后字节='＃'。

接下来，我们计算剩余的3个字节（字节3、4、5）的校验和，如果它与BCS一致，我们将继续分析数据，寻找该数据的设备以及应如何处理，在这种情况下，从代码为55，子代码2表示关于需要在继电器的阈值上再增加5度，并在响应消息中发送当前温度数据。我检查NS是否不等于先前的消息编号，然后执行命令并将继电器阈值的当前值增加5度。如果它们相等（NS），则我不执行所指示的动作，然后继续进行响应消息的形成。

方案['$'] [发送/接收的字节数] [...] ['＃']的应用-极有可能保证在发送的数据中找不到这样的组合，并引发错误消息。

我根据收到的消息形成从站发送的数据：

处理原理如下：查看2个字节，如果发送的字节数等于接收到的字节数，并且发送的字节数等于接收的字节数，并且起始字节='@'和结束字节='＆'-这是从站到主机的消息。如果需要，我使用3之2的机制，类似于上述仅用于响应消息（对于字符'@'和'＆'）的机制。主机收到此消息后，将分析校验和9（从第3个到第11个）字节，如果校验和匹配，则认为消息中的数据可靠，并且继续进行进一步的数据分析。如果发送和接收的消息的代码，子代码和NS一致，我们将继续分析对主机发送的消息的响应。接下来是对接收到的数据的分析，在我的情况下，在第6个字节中，值为1表示将继电器阈值增加5度的命令已成功执行，其余5个字节指示当前温度读数;第7个字节是指示传输温度的可靠性的标志（即我正在考虑从站开启并响应的选项，但传感器可能无法工作）和4个字节的浮点温度值。

在消息的开头和结尾使用2个测试字符的可能性很高，这可以确保在发生错误时不会混淆从属节点和主节点的消息。同样，通道中的随机（非随机）数据也不会破坏交换。

关于从站到从站的数据传输的一些信息，以及从主站到所有从站的集中消息。

首先，最后一个-通过分配设备代码255来执行从设备从主设备进行的传输，设备代码255告诉从设备这是一条集中的消息，然后它仅用于解决常见子代码的问题，也可以按设备代码进行分组分配设备代码254和3或4个设备将使用此代码接收消息;其余设备将忽略它，自然地，从设备发送响应的部分在这里不应该工作，即无法保证追随者会明确接受这些消息！

从站将有关数据传输的信息发送到从站，由主站实现，从站向从站（slave1）发送一条消息，信息应从该消息发送到另一个从站（slave2），slave1向主站发送响应，而slave2侦听此答案，将数据带到自身。同样，不能保证从slave1到slave2的消息传递明确，必须考虑到这一点！

接口功能理论上连接的设备数约为250，每个设备的命令/数据类型最多为248，消息中有用信息的长度最多为250字节。

谈论陷阱：

所有数据传输均设计为按时工作，即应当注意消息之间的某些延迟。我还建议您在主机发送的消息与从机的响应之间设置固定的延迟，以便从机可以生成数据并将其完全传输到通道。

组织从属服务器响应的时刻也很重要，它可能会发生，从属服务器很忙，并且一次在其通道中有几条数据消息，您应该避免对过时的消息进行答复（因为领导者不再等待它们）忽略它们，只执行最新的命令消息并给出答案。

另外，我要强调按时间进行设备同步的问题-应该牢记，从站在接收消息时的时间同步需要考虑将数据发送到通道的时间延迟（速度为9600，将以10字节的速度发送消息约11 ms），并在中断被触发时结束在从设备侧接收数据时，如果没有中断，则值得考虑检查数据在设备缓冲区中的到达时间等。

还值得注意的是，重新发送消息循环也会增加细微差别，我建议使用不重复发送消息来进行时间同步，并使用新的NS编写消息。

聚苯乙烯我怀疑我在这里发现了一些新东西，所有这些都在某种程度上用在不同的界面中！借助此涂抹方法作者的轻松帮助以及该协议在我的开发中的应用，我想为该数据传输协议“ SRDB2”起个名字。

数据传输民谣

More articles: