多个微控制器之间的通讯

我想开始实现一个由N个微控制器（N> = 2个MCU）组成的系统，但是我想知道让它们彼此通信的可能性。

理想情况下，将（N-1）个微控制器放置在充当客户端的房屋内部，而最后一个（“服务器”）微控制器则通过USB连接到PC。我现在遇到的问题是如何将这些（N-1）个微控制器连接到“服务器”。客户端MCU执行非常简单的任务，因此仅使用它们提供CAN / PHY-MAC的方法，使用ARM进行此类简单的工作可能不是一个好的解决方案。

对于大多数设备而言，每隔几分钟通信一次，对于其他设备而言，通信不会超过一次。速度不是很关键（消息很短）：1 Mbit / s我认为对于我的目的来说是过大了。

我计划使用的MCU如下。

• Atmel AVR Tiny / Mega
• 德州仪器MSP430
• ARM Cortex M3 / M4
• （可能是Atmel AVR UC3-32位）

我想尽可能避免使用PIC（个人选择），这仅仅是因为编程它们的可能性很小（上述所有功能都有或多或少的开源工具以及一些官方工具）。

我知道有些ARM提供CAN功能，但对其他ARM 不太确定。

现在，我想到了以下可能性：

1. 简单的GPIO发送数据（例如，高电平时> 16位表示消息的开始，低电平时> 16位表示消息的结束）。但是，它必须处于标准频率<<（frequency_client，frequency_server）才能检测所有位。每个客户端MCU仅需要一根电缆。
2. RS-232：我认为这是迄今为止最常用的通信协议，但是我不知道它的扩展性如何。我现在正在考虑使用多达64个客户端MCU（可能以后再考虑）
3. USB：AFAIK大多类似于RS-232，但是在这种情况下，它的扩展性不太好（尽管USB支持许多设备-如果我记得没错，则支持255-对于此应用程序可能过于复杂）
4. RJ45 /以太网：这是我真正喜欢使用的，因为它可以无障碍地进行长距离传输（至少使用屏蔽> Cat 6电缆）。问题是成本（PHY，MAC，变压器等）。我不知道您是否真的可以在家焊接好。这样我就不需要客户端MCU
5. 无线/ ZigBee：模块非常昂贵，尽管这可能是避免桌子后面出现“意大利面”的一种方式
6. 射频模块/收发器：我说的是300 MHz-1 GHz频段的模块，因此在家里很难焊接。这些模块都是内置的，但它们与ZigBee相当昂贵（至少在Mouser，Sparkfun的RF模块似乎更便宜）。
7. 能够？它似乎非常强大。即使我不打算在汽车应用中使用它，它仍然可能是一个不错的选择。
8. I²C / SPI / UART？再说一次-如果可能的话，最好避免电缆出现“意大利面条”
9. PLC并不是真正的选择。随着长度的增加，性能会很快下降，并且取决于电网的电容负载。我认为价格方面与以太网大致相同。

此外，在同时传输的情况下，哪个协议会“更好”（让我们假设两种设备在同一时刻开始传输的罕见情况：哪个协议提供了最佳的“冲突管理系统” /“冲突管理系统”？

综上所述：考虑到灵活性（最大设备数量，冲突/冲突管理系统，...）和价格，我想听听做非常轻量级数据通信的分布式客户端系统的最佳解决方案是什么。 ，很容易在家里制作（焊接），...我想避免在通讯模块上花费20美元，但同时在桌子后面放30条电线会很烂。

我现在想像的解决方案是通过GPIO或RS-232在附近的MCU之间进行基本通信（便宜！），并在每个“区域”的一个MCU上使用以太网/ ZigBee / Wi-Fi与服务器进行通信（昂贵）。，但仍然比每个客户端MCU每个以太网模块便宜很多）。

代替电缆，也可以使用光纤/光纤。尽管有必要进行其他转换，但我不确定在这种情况下这是否是最佳解决方案。我想听听有关它们的更多详细信息。

在这种情况下，CAN听起来最适用。可以通过CAN以500 kbit / s的速度处理房屋内的距离，这听起来可以满足您的带宽需求。最后一个节点可以是现成的USB至CAN接口。这样，计算机中的软件就可以发送CAN消息并查看总线上的所有消息。其余的是软件，如果您想将其作为TCP服务器或其他东西呈现给外界。

CAN是您提到的唯一实际上是总线的通信方式，除了使用I / O线滚动通信之外。所有其他点对点，包括以太网。可以使以太网看起来像带有交换机的总线，但是各个连接仍然是点对点的，因此获得逻辑总线拓扑将很昂贵。每个处理器上的固件开销也比CAN多得多。

关于CAN的一个好处是，最低层的协议层是在硬件中处理的。例如，多个节点可以尝试同时发送，但是硬件负责检测和处理冲突。硬件负责发送和接收整个数据包，包括CRC校验和的生成和验证。

您避免PIC的原因没有任何意义。有许多设计供程序员自己构建。一个是我的LProg，其原理图可从该页面底部获取。但是，除非您以几分钱/小时的价格来评估自己的时间，否则构建自己的方法将不会具有成本效益。它还不仅仅是程序员。您将需要一些有助于调试的内容。Microchip PicKit 2或3是成本非常低的编程器和调试器。尽管我对他们没有亲身经历，但我听说其他人经常使用它们。

添加：

我看到了一些有关RS-485的建议，但是与CAN相比这不是一个好主意。RS-485是纯电气标准。它是差分总线，因此允许多个节点并且具有良好的抗噪能力。但是，CAN也拥有所有这些，还有更多。CAN通常也实现为差分总线。有人认为RS-485易于与电气接口。这是事实，但CAN也是。两种方式都可以由单个芯片来完成。对于CAN，MCP2551是一个很好的例子。

因此，CAN和RS-485在电气方面具有几乎相同的优势。CAN的最大优势在于该层之上。使用RS-485，在该层之上没有任何东西。你只能靠自己。可以设计一个协议来处理总线仲裁，数据包验证，超时，重试等，但是要正确地做到这一点比大多数人意识到的要复杂得多。

CAN协议定义了数据包，校验和，冲突处理，重试等。它不仅已经存在，经过深思熟虑和测试，而且真正的最大优势是可以在许多微控制器上直接在硅片中实现。固件在发送和接收数据包级别上连接到CAN外设。对于发送，硬件执行冲突检测，退避，重试和CRC校验和生成。对于接收，它进行数据包检测，时钟偏斜调整和CRC校验和验证。是的，与RS-485经常使用的UART相比，CAN外设需要更多的固件来驱动，但是由于芯片处理了大量的低层协议细节，因此其总体代码要少得多。

简而言之，RS-485属于过去的时代，对于当今的新系统而言已毫无意义。主要的问题似乎是过去使用RS-485并认为CAN某种程度上“复杂”的人们。CAN的低电平很复杂，但是任何合适的RS-485实施也是如此。请注意，基于RS-485的几种众所周知的协议已被基于CAN的较新版本取代。NMEA2000是这种更新的基于CAN的标准的一个示例。还有另一种汽车标准J-J1708（基于RS-485），现在已被基于CAN的OBD-II和J-1939淘汰了。

我建议使用CAN控制器，因为此功能完全用于控制器联网。

RS232可以轻松实现，但是如果您尝试实现两个以上节点之间的通信，则会遇到很大的挑战（因为它不是为此目的而构建的）。

以太网也是一个不错的选择，因为您提到了一些主机和客户端互连，这对于以太网的实现是很自然的。

如果可以将同一根线连接到所有设备，则使用多根线的RS-485在这里可以很好地工作。

例如，如果它与传统的5e类网络电缆一起使用，则可以有两对电缆用于双向数据传输（使用全双工模块），可以有一对或什至单根电缆作为公共接地，其余的可以协商哪个设备将在哪个时刻进行传输。RS-232有点复杂，但是模块比CAN和以太网便宜，电缆限制为1200 m。缺点是您必须制定自己的冲突解决协议。也许要传输的设备检查一根专用线，看它是否高。如果不是，请将其调高并开始进行通信，如果是，请等待一个随机的时间段。仍然我不确定这在长距离上的效果如何。

我会选择使用曼彻斯特编码数据的RS-485总线。

RS-485，因为：

• 便宜
• 易于实施
• 是使用低功耗
• 允许远距离（最长1200米）
• 高数据速率（高达10 Mbps）
• 抗干扰能力强
• 有收发器可在同一总线上最多允许256个设备
• 零件数量少

曼彻斯特编码，因为：

• 易于实施
• 可自我同步

为了数据完整性，该消息可以包括长度和CRC字段。

CRC函数的示例：

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INIT和CRC_POLY是用于计算CRC的任意值。

带有长度和CRC字段的消息示例：

让我将您的首选以太网与我的首选CAN进行比较。

所需组件：

• 以太网：RJ45连接器，磁性，Phy芯片（除非集成到MCU中）。还需要交换机和从交换机到每个节点的电缆。每个PCB需要相当多的电容器和端接电阻，也可能需要铁氧体。需要良好的PCB设计。
• CAN：收发器芯片（便宜），任何连接器，便宜的电缆都可以在站点周围的环路中从一个节点跳到另一个节点。收发器只需要一个电容器，总线的每一端都需要一个终端电阻。

您正在谈论的是价值1美元的微控制器。总线成本比MCU高得多。您必须将每个解决方案的总成本加起来，才能知道哪个实际上更便宜。加上MCU，连接器，收发器，无源组件，PCB，电缆等的成本。

恩智浦的LPC11C24还集成了CAN收发器，并且在ROM中支持CANOpen（不会消耗32 K数据闪存）。LPCXpresso 11c24板为20欧元（已为DB9连接器提供了空间），因此您实际上只需添加电线即可：-)

从另一个类似的问题重新发布。 两个微控制器之间的低成本简单通信

TLDR：并不是特别便宜，但是在某些用例中很可靠。

从盒子外面看，这里可能还有其他解决方案，例如我最近碰到的以下芯片。当然，这完全取决于您要做什么。如果您将两个MCU放在同一块板上，或者甚至打算分开进行ESD静电保护，就会想到UART。

IO-Link应用程序的主设备解决方案

L6360   Master
L6362A  Device

您什么时候考虑这样的解决方案：

1. 前沿芯片受到全面保护，如果您将每个MCU放在单独的板上并处理裸露的引脚（例如螺钉端子），这将非常重要。
   • 反极性
   • 具有截止功能的过载
   • 过温
   • 欠压和过压
   • GND和VCC开路线
2. 互操作性。如果有人要设计另一面，他所需要知道的就是通过IO-Link传递数据。
3. 集成稳压器 Vcc(in) 7~30v, Vdd(out) 3.3/5v

这对我来说听起来很有趣，所以我想我把它放在那里。

这取决于您的应用程序和微控制器的规模。您提到了Atmel tiny / mega，它们很小。在这种情况下，I2C / SPI / UART具有以下优点：它们以硬件实现，因此易于使用。