[参考译文] MSP430FR2355：如何在消息流进入时同步消息流？

PCM 编码器使用同步模式为多路解复用器提供同步机会。 通常是 Barker 代码或类似的代码。

这适用于同步位流、我怀疑您使用的是带 UART 的异步流。 但执行类似的操作。 使用几个0xFFs 开始每个数据包、以便 UART 有机会与您的起始位同步。 然后是同步字节、最后是数据。

接收器等待 UART 将 SYNC 字节推出、然后才开始处理数据。 您可能还需要检查错误标志是否存在帧错误、但请记住、读取数据寄存器会复位这些位、因此请首先检查它们。

大卫…

是的，我正开始思考这条路径...尝试确定是否可以使用我的系统 ID (消息的前四个字节)来实现这一目的？  由于 OAR 效率的原因、我更倾向于使用它而不是 FF 和同步字节。  如果我在消息中添加所有这些内容、我的开销会大大超出我的有效负载、我最终会花费射频功率来传输我不需要的大部分内容。  如果我确实使用系统 ID 的四个字节进行同步和有效、我将在该事件后检查 CRC。  在 CRC 之前执行系统 ID 检查是否合理？  现在、我使用 CRC 验证消息、然后检查我的节点是否在系统上。

谢谢

Steve

您的射频接收器将有时输出随机垃圾、您必须对此进行规划。 即使发送器始终开启、也会偶尔出现信号压降。 因此、您必须执行一些操作、以确保 UART 同步到有效的起始位。 否则、只有一个随机位会将其关闭。

如果您知道要查找的内容、则可以使用系统 ID 进行同步。

在处理数据之前验证数据。

我想我正在做所有这些，但仍然有问题…

我的 RX ISR：

* prx = UCA1RXBUF；
prx++；
if (prx >(incoming + 7))｛
PRx =传入；
mssgRcvd = T；
UCA1RXBUF = 0；
UCA1IE &=~UCRXIE；
UCA1IFG &=~UCRXIFG；
_BIC_SR_REGISTER_ON_EXIT (LPM3_BITS)；
｝

和 main 中，我处理 Rx msgs 首先检查 CRC 以进行验证，然后我执行 memcmp 来验证数据...不确定其他什么或额外的同步字节会有所帮助？

如果(！transmitter)｛
if (msgRcvd)｛
mssgRcvd = F；
PRx =传入；
memcpy (noCRC、传入、sizeof (noCRC))；
CRC_RESULT = CRC (noCRC)；
if ((char)((((crc_result >> 8)& 0xFF)= Incoming[6])&&((char)(((crc_result & 0xFF)= Incoming[7])))｛
ValidRFPackets ++；
if (！memcmp (incoming、mssg、4))｛
/*
*系统 ID 检查
*
ValidMsgPackets ++；

您好、Steve、

您的问题如何？  是否有任何更新？

您是否需要我们的进一步支持？

此致

Johnson

你(们)好，约翰逊  

我仍然有问题。  我正在发送三种类型的消息...当我按住按钮时，我发送的其中一条消息每80ms 发送一次...我发送的每条消息都使用前四个字节作为同步/系统 ID，并且消息的最后两个字节始终是 CRC。  包含 CRC 的消息长度仅为8字节。  我始终按预期接收阵列前8个位置的20字节阵列中的8个字节(由于在 main 运行之前发生了一些初始化内容、阵列为20字节)。  但是、有时同步字节不在阵列的[0]条目处、这是意料之中的。  发生这种情况时、我不同步、此时我的 CRC 将运行并失败。  我不知道是什么使消息在数组中滚动、并且认为它必须是指针。  我已经通过在代码的各个方面重置指针来解决问题、我已经完成了我可以想到的所有工作、但我还没有看到它得到解决。  很明显，如果我重置主板，问题就会得到解决，我发现，如果我发送另外三种类型的消息之一(顺便说一下，这三种消息一次只有8个字节，而不是每80ms 一次)，有时它会重新对齐，并且我还在做生意..... 是否有任何关于如何继续的想法？？

谢谢

Steve

您好、Tezla、

 有关问题：的简要总结

每次发送8字节数据、前四个字节作为同步/系统 ID、最后两个字节消息始终为 CRC、因此有用数据仅为两个字节、如下所示：

SYNC1 SYNC2 SYNC3 SYNC4 Data0 Data1 CRC1 CRC2。

您的问题应该是无法保证每次 SYNC1都将存储在数组[0]中。

因此、我建议将您的 SYNC1-SYNC4设置为固定字符、例如：0x55 0xF5 0x55、

接收数据0x55后、转到检查以下三个字节是否与0x55 0xf5 0x55匹配

当这四个字节(或三个字节：未检测到第一个0x55不影响使用)与设置匹配时、您可以接收有用的数据和 CRC。

此致

Johnson

你好，约翰逊。。。

您已正确描述了问题...我有四个已修复的字节(系统 ID/Sync --用户一次编程)。  收到消息后，我首先运行 CRC，然后查看前四个字节，以查看它们是否与客户端 FRAM 中存储的四个字节匹配...如果是，消息是良好的。 正如您所说的、存储在 array[0]中的第一个字节并不总是 SYNC1。  当然、我知道这是因为 CRC 失败。  我希望数据会不时取消同步。  这是预期的、因为整个链路是 RF 链路。  

我的问题是从这种情况中恢复。  我想保证快速恢复。  有时、我会发送更多消息并恢复设备、但在大多数情况下、我必须对评估模块进行硬复位。  这是不可接受的、因为这些装置将位于远程位置。  目前，我似乎无法得到这部分内容...就像我说过的，CRC 失败时的立即响应是丢弃该消息，并再次将指向数组的指针重置为数组[0]。  我执行此操作两次、一次是在 main 内、一次是在失败后、另一次是在 ISR 内、以防在我完成 main 处理时出现一个字节。

老实说，我看不到您的建议会在恢复方面产生什么影响...基本上我正在做您建议的事情来接收消息。 那么、有没有关于恢复的想法呢？  我可以脱机将代码发送给您，如果这样做是有帮助的，但它相当大......

谢谢

Steve

问题不在于恢复、而在于接待处。

您的射频接收器很可能会偶尔输出随机噪声、尤其是在没有发射信号的情况下。 这很容易导致 UART 检测到一个开始位并生成一个字节的垃圾。 您需要对此执行一些操作。 当 RXERR 置1时、您是否至少丢弃接收到的数据？

大卫…

如果射频触发的 UART 有坏数据，会显示在我的8深缓冲区中...它不是8深缓冲区总是正确的，它只是旋转...它的旋转 bcz 指针正在变得更高级， 然而，指针的进步意味着数据被写入数组...无论它们是什么，我每8个字符就会被唤醒并处理...现在，我已经承认，将来我可以从一个嘈杂的射频中得到有故障的字符...我将深入研究 RXERR 正如你推荐的 bcz，我绝对不会使用它…

谢谢

步骤