Comunicación entre múltiples microcontroladores

CAN suena más aplicable en este caso. Las distancias dentro de una casa pueden ser manejadas por CAN a 500 kbits/s, lo que suena como un ancho de banda suficiente 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 bus, a excepción del suyo propio con líneas de E/S. Todos los demás son punto a punto, incluido ethernet. Se puede hacer que Ethernet se vea lógicamente como un bus con conmutadores, pero las conexiones individuales aún son punto a punto y obtener la topología de bus lógico 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 tratar las colisiones. El hardware se encarga de enviar y recibir paquetes completos, incluida la generación y validación de la suma de verificación CRC.

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

Adicional:

Veo algunas recomendaciones para RS-485, pero 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 suele implementarse como un bus diferencial. Algunos argumentan que RS-485 es fácil de interconectar eléctricamente. 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.

Entonces, 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., pero hacerlo bien es mucho más complicado de lo que la mayoría de la gente piensa.

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 interactúa con el periférico CAN en el nivel de envío y recepción de paquetes. Para el envío, el hardware realiza la detección de colisiones, el retroceso, el reintento y la generación de la suma de verificación CRC. Para la recepción, realiza la detección de paquetes, el ajuste de la desviación del reloj y la validación de la suma de comprobación CRC. Sí, el periférico CAN necesitará más firmware para manejar que un UART como el que se usa a menudo con RS-485, pero en general requiere mucho menos código ya que el silicio maneja gran parte de los detalles del protocolo de bajo nivel.

En resumen, RS-485 pertenece a una era pasada y tiene poco sentido para los nuevos sistemas actuales. El problema principal parece ser que las personas que usaron RS-485 en el pasado se aferran a él y piensan que CAN es "complicado" de alguna manera. Los niveles bajos de CAN son complicados, pero también lo es cualquier implementación competente de RS-485. Tenga en cuenta que varios protocolos bien 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 ahora está bastante obsoleto con OBD-II y J-1939 basados ​​en CAN.

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

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

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

Elegiría un bus RS-485 que funcione con datos de codificación Manchester .

RS-485 porque:

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

Codificación Manchester porque:

• Es fácil de implementar
• Es autosincronizable

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 campos de longitud y CRC:

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

Si, por ejemplo, se usa con un cable de red tradicional de categoría 5e, 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 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 económicos que CAN y Ethernet y el límite de cable es de 1200 m. La desventaja es que tendrás que hacer tu 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í, llévelo alto y comience a comunicarse y si es así, espere un período de tiempo aleatorio. Todavía no estoy seguro de qué tan bien funcionaría esto en largas distancias.

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 barata. Sume el costo de la MCU, conectores, transceptores, componentes pasivos, PCB, cables, etc.

LPC11C24 de NXP también tiene el transceptor CAN integrado y CANOpen compatible en ROM (sin consumir su Flash de datos de 32 K). La placa LPCXpresso 11c24 cuesta 20 EUR (ha proporcionado espacio para el conector DB9), por lo que realmente solo agrega cables :-)

Repost de otra pregunta similar. Comunicación simple de bajo costo entre dos microcontroladores

TLDR : ajuste no particularmente económico pero confiable en algunos casos de uso.

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

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

L6360   Master
L6362A  Device

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

1. Los chips fronterizos vienen completamente 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
   • Cable abierto GND y VCC
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 integradoVcc(in) 7~30v, Vdd(out) 3.3/5v

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 están implementados en hardware y, por lo tanto, son fáciles de usar.