Comunicación entre múltiples microcontroladores.

Me gustaría comenzar a implementar un sistema que consta de N microcontroladores (N> = 2 MCU), pero me gustaría saber las posibilidades para permitirles comunicarse uno con el otro.

Idealmente, los microcontroladores (N-1) se colocan dentro de la casa actuando como clientes, mientras que el último (el "servidor") está conectado a una PC a través de USB. El problema que tengo ahora es cómo conectar estos microcontroladores (N-1) al "servidor". Las MCU de los clientes realizan tareas muy simples, por lo que puede que no sea una buena solución utilizar ARM para realizar trabajos tan simples simplemente porque proporcionan CAN / PHY-MAC .

La comunicación no se realizará más de una vez cada pocos minutos para la mayoría de los dispositivos y a pedido de otros. La velocidad no es muy crítica (el mensaje es corto): 1 Mbit / s, creo que es una forma excesiva para mis propósitos.

Las MCU que planeo usar son las siguientes.

• Atmel AVR Tiny / Mega
• TI MSP430
• BRAZO Cortex M3 / M4
• (Posiblemente Atmel AVR UC3 - 32 bits)

Me gustaría evitar los PIC si es posible (elección personal), simplemente porque hay menos posibilidades de programarlos (todos los anteriores tienen más o menos herramientas de código abierto, así como algunas herramientas oficiales).

Sé que algunos ARM proporcionan la funcionalidad CAN y no estoy tan seguro de los demás.

En este momento se me ocurrieron estas posibilidades:

1. GPIO simple para enviar datos (digamos> 16 bits en ALTO para indicar el inicio del mensaje,> 16 bits en BAJO para indicar el final del mensaje). Sin embargo, tiene que estar en una frecuencia estándar << (frecuencia_cliente, frecuencia_servidor) para poder detectar todos los bits. Solo necesita un cable por cliente MCU.
2. RS-232 : Creo que este es, con mucho, el protocolo de comunicación más utilizado, pero no sé qué tan bien se escala. Estoy considerando hasta 64 MCU de cliente en este momento (probablemente más tarde)
3. USB: AFAIK, esto es principalmente como RS-232, pero no creo que se adapte muy bien en este caso (aunque USB admite muchos dispositivos, 255 si recuerdo bien, puede ser demasiado complicado para esta aplicación)
4. RJ45 / Ethernet: esto es lo que realmente me encantaría usar, porque permite la transmisión a largas distancias sin problemas (al menos con cable blindado> Cat 6 ). El problema es el costo (PHY, MAC, transformador, ...). Sin embargo, no sé si realmente puedes soldarlo bien en casa. De esta manera no necesitaría un cliente MCU
5. Inalámbrico / ZigBee : los módulos son muy caros, aunque puede ser el camino a seguir para evitar "spaghetti" detrás del escritorio
6. Módulos / transceptores de RF: estoy hablando de aquellos en la banda de 300 MHz - 1 GHz, por lo que deberían ser difíciles de soldar en casa. Todos los módulos están integrados, pero son bastante caros como el ZigBee (al menos los módulos de RF en Mouser, en Sparkfun parecen ser más baratos).
7. ¿LATA? Parece ser muy robusto. Aunque no planeo usarlo en aplicaciones automotrices, aún puede ser una buena alternativa.
8. I²C / SPI / UART ? Una vez más, mejor evitar "espagueti" con los cables si es posible
9. Los PLC no son realmente una opción. El rendimiento se degrada bastante rápido a medida que aumenta la longitud y depende de la carga de capacitancia de la red eléctrica. Creo que el precio es casi lo mismo que Ethernet.

Además, ¿qué protocolo sería "mejor" en caso de transmisiones simultáneas (supongamos el raro caso de que en el mismo instante dos dispositivos comiencen a transmitir: ¿qué protocolo proporciona el mejor "sistema de gestión de conflictos" / "sistema de gestión de colisiones"?

En resumen : me gustaría saber cuál puede ser la mejor solución para un sistema de cliente distribuido que realiza una comunicación de datos muy ligera, teniendo en cuenta tanto la flexibilidad (número máximo de dispositivos, sistema de gestión de conflictos / colisiones, ...), precio , fácil de hacer en casa (soldar), ... Me gustaría evitar gastar 20 $ solo en el módulo de comunicación, pero al mismo tiempo tener 30 cables detrás del escritorio sería una mierda.

La solución que estoy imaginando en este momento sería hacer una comunicación básica entre las MCU cercanas por GPIO o RS-232 ( ¡ barato !) Y usar Ethernet / ZigBee / Wi-Fi en una MCU por "zona" para comunicarse con el servidor ( costoso , pero sigue siendo mucho más barato que un módulo Ethernet por cada MCU de cliente).

En lugar de cables, también es posible utilizar fibras ópticas / fibra óptica. Aunque son necesarias conversiones adicionales, y no estoy seguro de si sería la mejor solución en este caso. Me gustaría escuchar detalles adicionales sobre ellos.

CAN suena más aplicable en este caso. CAN puede manejar las distancias dentro de una casa a 500 kbits / s, lo que suena como un gran ancho de banda para sus necesidades. El último nodo puede ser una interfaz USB a CAN lista para usar. Eso permite que el software en la computadora envíe mensajes CAN y vea todos los mensajes en el bus. El resto es software si desea presentar esto al mundo exterior como un servidor TCP o algo así.

CAN es el único medio de comunicación que mencionó que en realidad es un autobús, excepto para rodar el suyo con líneas de E / S. Todos los demás son punto a punto, incluido ethernet. Se puede hacer que Ethernet parezca lógicamente un bus con conmutadores, pero las conexiones individuales siguen siendo punto a punto y obtener la topología lógica del bus será costoso. La sobrecarga de firmware en cada procesador también es considerablemente mayor que CAN.

Lo bueno de CAN es que las pocas capas de protocolo más bajas se manejan en el hardware. Por ejemplo, varios nodos pueden intentar transmitir al mismo tiempo, pero el hardware se encarga de detectar y lidiar con las colisiones. El hardware se encarga de enviar y recibir paquetes completos, incluida la generación y validación de suma de verificación CRC.

Sus razones para evitar los PIC no tienen ningún sentido. Hay muchos diseños para programadores para construir el suyo propio. Uno es mi LProg , con el esquema disponible en la parte inferior de esa página. Sin embargo, construir el suyo propio no será rentable a menos que valore su tiempo en centavos / hora. También se trata de algo más que el programador. Necesitará algo que ayude con la depuración. Microchip PicKit 2 o 3 son programadores y depuradores de muy bajo costo. Aunque no tengo experiencia personal con ellos, escucho que otros los usan de manera rutinaria.

Adicional:

Veo algunas recomendaciones para RS-485, pero esa no es una buena idea en comparación con CAN. RS-485 es un estándar solo eléctrico. Es un bus diferencial, por lo que permite múltiples nodos y tiene buena inmunidad al ruido. Sin embargo, CAN también tiene todo eso, y mucho más. CAN también se implementa generalmente como un bus diferencial. Algunos argumentan que RS-485 es fácil de conectar a la electricidad. Esto es cierto, pero también lo es CAN. De cualquier manera, un solo chip lo hace. En el caso de CAN, el MCP2551 es un buen ejemplo.

Por lo tanto, CAN y RS-485 tienen prácticamente las mismas ventajas eléctricamente. La gran ventaja de CAN está por encima de esa capa. Con RS-485 no hay nada por encima de esa capa. Estas por tu cuenta. Es posible diseñar un protocolo que se ocupe del arbitraje de bus, la verificación de paquetes, los tiempos de espera, los reintentos, etc.

El protocolo CAN define paquetes, sumas de verificación, manejo de colisiones, reintentos, etc. No solo ya está ahí, pensado y probado, sino que la gran ventaja es que se implementa directamente en silicio en muchos microcontroladores. El firmware se conecta al periférico CAN a nivel de envío y recepción de paquetes. Para el envío, el hardware realiza la detección de colisión, retroceso, reintento y generación de suma de verificación CRC. Para recibir, realiza la detección de paquetes, el ajuste de la desviación del reloj y la validación de la suma de verificación CRC. Sí, el periférico CAN necesitará más firmware para conducir que un UART, como se usa a menudo con RS-485, pero requiere mucho menos código en general, ya que el silicio maneja gran parte de los detalles del protocolo de bajo nivel.

En resumen, RS-485 es de una época pasada y tiene poco sentido para los nuevos sistemas de hoy. El problema principal parece ser las personas que usaron RS-485 en el pasado aferrándose a él y pensando que CAN es "complicado" de alguna manera. Los bajos niveles de CAN son complicados, pero también lo es cualquier implementación competente de RS-485. Tenga en cuenta que varios protocolos conocidos basados ​​en RS-485 han sido reemplazados por versiones más nuevas basadas en CAN. NMEA2000 es un ejemplo de un nuevo estándar basado en CAN. Hay otro estándar automotriz J-J1708 (basado en RS-485) que está bastante obsoleto ahora con el OBD-II y J-1939 basados ​​en CAN.

Recomendaría el controlador con CAN ya que esta función está diseñada exactamente para el propósito de la red del controlador.

RS232 se puede implementar fácilmente, pero se volverá un verdadero desafío si intenta implementar la comunicación en más de 2 nodos (porque no está diseñada para este propósito).

Ethernet también puede ser una buena opción, ya que mencionó algunas interconexiones de host y clientes, lo cual es natural para la implementación de Ethernet.

RS-485 usando múltiples cables podría funcionar bien aquí, si existe la posibilidad de conectar la misma línea a todos los dispositivos.

Si, por ejemplo, se usa con el cable de red de categoría 5e tradicional, podría tener dos pares para trabajar para la transmisión de datos en ambas direcciones (usando un módulo dúplex completo), tener un par o incluso un solo cable como conexión a tierra común y el resto para negociar qué dispositivo va a transmitir en qué momento. Es un poco más complicado que RS-232, pero los módulos son más baratos que CAN y Ethernet y el límite de cable es de 1200 m. La desventaja es que tendrá que hacer su propio protocolo de resolución de conflictos. Tal vez haga que el dispositivo que quiere transmitir verifique un cable dedicado y vea si es alto. Si no es así, colóquelo alto y comience a comunicarse y, si es así, espere un período de tiempo aleatorio. Aún así, no estoy seguro de qué tan bien funcionaría esto en largas distancias.

Elegiría un bus RS-485 que trabaje con datos de Manchester Encoding .

RS-485 porque:

• Es barato
• Es fácil de implementar
• Se usa lo power
• Permite largas distancias (hasta 1200 metros)
• Altas velocidades de datos (hasta 10 Mbps)
• Alta inmunidad a interferencias.
• Hay transceptores que permiten hasta 256 dispositivos en el mismo bus
• Bajo recuento de piezas

Codificación Manchester porque:

• Es fácil de implementar
• Es auto-sincronizable

Para la integridad de los datos, el mensaje puede incluir una longitud y un campo CRC.

Ejemplo de una función 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_INITy CRC_POLYson valores arbitrarios que se utilizan para calcular el CRC.

Ejemplo de un mensaje con longitud y campos CRC:

Permítame comparar su opción preferida, Ethernet, con mi opción preferida, CAN.

Componentes requeridos:

• Ethernet: conector RJ45, magnetismo, chip Phy (a menos que esté integrado en MCU). También necesita interruptores y un cable desde el interruptor a cada nodo. Cada PCB necesita bastantes condensadores y resistencias de terminación, posiblemente también ferritas. Necesita un buen diseño de PCB.
• CAN: chip transceptor (barato), cualquier conector, cable barato puede saltar de un nodo al siguiente en un bucle alrededor del sitio. Solo necesita un condensador para el transceptor y una resistencia de terminación en cada extremo del bus.

Estás hablando de microcontroladores de $ 1. Hay mucho más en el costo del autobús que el MCU. Tendrá que sumar el costo total de cada solución para saber cuál es realmente más barato. Sume el costo de la MCU, conectores, transceptores, componentes pasivos, PCB, cables, etc.

LPC11C24 de NXP también tiene un transceptor CAN integrado, y CANOpen es compatible con ROM (no elimina su memoria flash de 32 K). La placa LPCXpresso 11c24 cuesta 20 EUR (ha proporcionado espacio para el conector DB9), por lo que realmente solo agrega cables :-)

Vuelva a publicar de otra pregunta similar. Comunicación simple de bajo costo entre dos microcontroladores

TLDR : no es particularmente barato pero es confiable en algunos casos de uso.

Mirando fuera de la caja, podría haber algunas otras soluciones aquí, como el siguiente chip con el que me topé últimamente. Por supuesto, todo depende de lo que quieras hacer. Me viene a la mente algo como UART si tiene ambos MCU en la misma placa o incluso planea ESD protegerlos manualmente si están separados.

Solución maestra y de dispositivo para aplicaciones IO-Link

L6360   Master
L6362A  Device

¿Cuándo consideraría una solución como esta?

1. Los chips fronterizos vienen totalmente protegidos, lo que sería importante si tiene cada MCU en una placa separada y se ocupa de pines expuestos, por ejemplo, terminal de tornillo.
   • Polaridad inversa
   • Sobrecarga con función de corte
   • Exceso de temperatura
   • Subtensión y sobretensión
   • GND y VCC cable abierto
2. Interoperabilidad. Si alguien más va a diseñar el otro lado, todo lo que necesita saber es canalizar los datos a través de IO-Link.
3. Regulador integrado Vcc(in) 7~30v, Vdd(out) 3.3/5v

A mí me pareció interesante, así que pensé en publicarlo.

Depende de la escala de su aplicación y sus microcontroladores. Mencionaste Atmel tiny / mega, son bastante pequeños. En su caso, I2C / SPI / UART tienen la ventaja de que se implementan en hardware y, por lo tanto, son fáciles de usar.