La comunicación entre varios microcontroladores

Question

Me gustaría empezar la implementación de un sistema que consta de N microcontroladores (N >= 2 Mcu), pero me gustaría saber las posibilidades para que puedan comunicarse uno con el otro.

Idealmente, (N-1) los microcontroladores se colocan en el interior de la casa, actuando como clientes, mientras que el último (el "servidor") se conecta a una PC a través de USB. Los problemas que tengo ahora mismo es cómo conectar estos (N-1) microcontroladores para el "servidor". Los clientes Mcu realizar muy simple de tareas, por lo que puede no ser una buena solución para el uso de las Armas para hacer esos trabajos simples, sólo porque proporcionan PUEDEN / PHY-MAC.

La comunicación no va a suceder más de una vez cada pocos minutos para la mayoría de los dispositivos y en la demanda de los demás. La velocidad no es muy crítico (mensaje corto): 1 Mbit/s creo que es excesivo para mis propósitos.

El Mcu pienso usar son los siguientes.

• Atmel AVR Pequeño / Mega
• TI MSP430
• ARM Cortex M3/M4
• (Posiblemente Atmel AVR UC3 - 32-bit)

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

Sé que algunos Brazos proporcionar PUEDE funcionalidad y no estoy tan seguro acerca de los demás.

Ahora mismo me ocurrió con estas posibilidades:

1. Simple GPIO para enviar datos (por ejemplo > 16 bits en ALTO para indicar el inicio de mensaje, > 16 bits a la BAJA para indicar el final del mensaje). Sin embargo, en un nivel de frecuencia << (frequency_client, frequency_server) para ser capaz de detectar todos los bits. Sólo se necesita un cable por cliente MCU.
2. RS-232: creo que este es por lejos el más utilizado protocolo de comunicación, pero no sé cómo se las escalas. Me estoy planteando hasta 64 cliente Mcu ahora (probablemente más tarde)
3. USB: AFAIK esto es principalmente del tipo RS-232, pero no creo que se escala muy bien en este caso (a pesar de que el USB es compatible con muchos de los dispositivos - 255 si recuerdo correctamente - puede ser demasiado complicado para esta aplicación)
4. RJ45 / Ethernet: esto es lo que realmente me encantaría usar, ya que permite la transmisión a través de largas distancias sin problemas (al menos con blindados >Cat 6 cable). El problema es el costo (PHY, MAC, transformador, ...). No sé si en realidad se puede soldar bien en casa, aunque. De esta manera yo no se necesita un cliente de MCU
5. Inalámbrico / ZigBee: los módulos son muy caros, aunque puede ser el camino a seguir a fin de evitar los "spaghetti", detrás de la mesa
6. Los módulos de RF / transceptores: estoy hablando de aquellos en los 300 MHz - 1 GHz, por lo que debe ser difícil para soldadura en casa. Los módulos están construidos, pero son tan caros como los ZigBee (al menos la de RF módulos en Mouser, en Sparkfun no parecen ser los más baratos).
7. Se PUEDE? Parece ser muy robusto. Incluso aunque yo no los va a utilizar en aplicaciones de automoción, todavía puede ser una buena alternativa.
8. I2C / SPI / UART? De nuevo - mejor evitar los "spaghetti", con los cables, si es posible
9. Los plc no son realmente una opción. El rendimiento se degradan muy rápido como los aumentos de longitud y depende de la capacitancia de la carga de la red de energía. Creo que en cuanto al precio es casi el mismo como Ethernet.

Además, el protocolo que sería "mejor" en el caso de las transmisiones simultáneas (supongamos el caso raro de que, en el mismo instante dos dispositivos de empezar a transmitir: el protocolo que proporciona la mejor "gestión de conflictos del sistema" / "la colisión de sistema de gestión"?

Para resumir: me gustaría saber cuál puede ser la mejor solución para un cliente distribuida sistema que hace muy poquito de la comunicación de datos, teniendo en cuenta tanto la flexibilidad (número máximo de dispositivos, conflicto / colisión, sistema de gestión, ...), precio, fáciles de hacer en casa (soldadura), ... me gustaría evitar el gasto de$ 20 en el módulo de comunicación, pero al mismo tiempo tener 30 cables de detrás de la mesa sería un asco.

La solución que estoy de imagen ahora mismo sería hacer la comunicación básica entre cerca de Mcu por GPIO o RS-232 (barato!) y el uso de Ethernet / ZigBee / Wi-Fi en un MCU por "zona" para comunicarse con el servidor (caro, pero todavía es mucho más barato que un módulo Ethernet por cada cliente MCU).

En lugar de cables puede ser posible el uso de la fibra óptica / fibras ópticas. A pesar de conversiones adicionales son necesarios, y no estoy seguro de si sería la mejor solución en este caso. Me gustaría conocer detalles adicionales sobre ellos.

Answer 1

PUEDEN sonidos de la más aplicable en este caso. Las distancias dentro de una casa puede ser manejado por PUEDE a 500 kbit/s, que suena como un montón de ancho de banda para sus necesidades. El último nodo puede ser un fuera de la plataforma USB a la interfaz CAN. Que permite que el software en el ordenador PUEDE enviar mensajes y ver todos los mensajes en el bus. El resto es software si desea presentar esto al mundo exterior como un servidor TCP o algo.

PODEMOS es el único medio de comunicación que usted ha mencionado que es en realidad un autobús, excepto para rodar su propio con las líneas de e/S. Todos los demás son de punto a punto, incluyendo ethernet. Ethernet puede ser hecho de forma lógica parecerse a un bus con interruptores, pero las conexiones son punto a punto y llegar a la lógica topología de bus será caro. El firmware de sobrecarga en cada procesador también es considerablemente más de lo que PUEDE.

Lo bueno acerca de PUEDE es que el menor de unos niveles de protocolo se manejan en el hardware. Por ejemplo, varios nodos puede tratar de transmitir al mismo tiempo, pero el hardware que se encarga de la detección y el tratamiento de las colisiones. El hardware se encarga de enviar y recibir todo los paquetes, incluyendo la suma de comprobación CRC de generación y validación.

Sus razones para evitar Fotos no tiene ningún sentido. Hay muchos diseños para los programadores que hay para la construcción de su propio. Uno de ellos es mi LProg, con el esquema disponibles en la parte inferior de la página. Sin embargo, la construcción de su propio no ser rentable, a menos que el valor de su tiempo en centavos/hora. Es también más que el programador. Tendrá algo que ayuda a la depuración. El Microchip PicKit 2 o 3 son de muy bajo costo a los programadores y depuradores. Aunque yo no tengo ninguna experiencia personal con ellos, he oído de otros que utilizan de manera rutinaria.

Añadió:

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

Así que se PUEDE y RS-485 tienen casi las mismas ventajas eléctricamente. La gran ventaja de poder está por encima de esa capa. Con RS-485 no hay nada por encima de esa capa. Usted está en sus el propio. Es posible diseñar un protocolo que se ocupa de autobús de arbitraje, paquete de verificación, tiempos de espera, reintentos, etc, pero para obtener este derecho es mucho más complicado de lo que la mayoría de la gente piensa.

El protocolo CAN define paquetes, las sumas de comprobación, la colisión de manejo, reintentos, etc. No sólo es que ya existe y pensado y probado, pero la gran ventaja es que es aplicado directamente en el silicio en muchos de los microcontroladores. El firmware de interfaces PUEDE periférico en el nivel de envío y recepción de paquetes. Para el envío, el hardware hace la colllision de detección, el retroceso, volver a intentar, y la suma de comprobación CRC generación. Para recibir, no el paquete de detección, desfase de reloj de ajuste, y la suma de comprobación CRC de validación. Sí la PUEDE periférico tomará más de firmware para la unidad de la UART tal como se utiliza a menudo con RS-485, pero se tarda mucho menos código general desde el silicio se ocupa de lo que gran parte de la baja protocolo de nivel de detalles.

En definitiva, RS-485 es de una época pasada y tiene poco sentido para los nuevos sistemas de hoy en día. El principal problema parece ser que la gente que utiliza la interfaz RS-485 en el pasado aferran a ella y el pensamiento es "complicado" de alguna manera. Los niveles bajos de la CAN es complicado, pero así es competente RS-485 aplicación. Tenga en cuenta que varios bien conocidos protocolos basados en RS-485 han sido reemplazados por versiones más recientes basados en PUEDE. NMEA2000 es un ejemplo de una nueva PUEDE basada en el estándar. Hay otro J-algo de automoción RS-485 estándar que es bastante obsoleto en la actualidad con una base de OBD-II y otros.

Answer 2

Yo recomendaría controlador PUEDE ya que esta característica se decir exactamente para el controlador de red de propósito.

RS232 puede ser implementado fácilmente, pero lo hará real desafiante si intenta implementar la comunicación de más de 2 nodos (causa no es construir para este propósito).

Ethernet puede ser una dulce opción demasiado ya que usted menciona algunos host y clientes interconexiones que es natural para Ethernet de la aplicación.

Answer 3

Yo elegiría un bus RS-485 de trabajo con la Codificación Manchester de datos.

RS-485, porque:

• Es barato
• Es fácil de implementar
• Es usos de baja potencia
• Permite largas distancias (hasta 1200 metros)
• Altas velocidades de datos de hasta 10 Mbps)
• Alta inmunidad a interferencias
• Hay transceptores que permite hasta 256 dispositivos en el mismo bus
• Parte baja contar

La codificación Manchester porque:

• Es fácil de implementar
• Es la auto-synchronizable

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

Ejemplo de un CRC de la función:

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 y CRC_POLY son valores arbitrarios que se utilizan para calcular el CRC.

Ejemplo de un mensaje con la longitud y el CRC campos:

Answer 4

RS-485 con múltiples cables que podría funcionar bien aquí, si hay una posibilidad de alambre de la misma línea para todos los dispositivos.

Si por ejemplo se usa con el tradicional categoría 5e, cable de red, usted podría tener dos pares de trabajar para la transmisión de datos en ambas direcciones (la utilización de un completo módulo dúplex), tienen un par o tal vez incluso de un solo alambre como el terreno común y el resto a negociar el dispositivo que se va a transmitir en qué momento. Es un poco más complicado de lo que RS-232, pero los módulos son más baratos que se PUEDEN, y de Ethernet y el cable de límite es de 1200 m. La desventaja es que usted tendrá que hacer su propio protocolo de resolución de conflictos. Tal vez tener el dispositivo con el que quiere transmitir marque uno dedicado alambre y ver si es alto. Si no lo es, traer de alta y empezar a comunicarse y si es así, espere un período de tiempo aleatorio. Todavía no estoy seguro de lo bien que esto iba a funcionar en largas distancias.

Answer 5

Voy a comparar su opción preferida, Ethernet, con mi opción preferida, PUEDE.

Componentes necesarios:

• Ethernet: RJ45 conector, magnetismo, física (Phy) chip (a menos integrado en MCU). También se necesitan interruptores y un cable desde el interruptor a cada nodo. Cada PCB necesita un par de condensadores y resistencias de terminación, posiblemente ferritas. Es necesario el diseño de PCB.
• PUEDE: Transceptor chip (barato), cualquier conector, cable barato pueden saltar de un nodo a otro en un bucle alrededor del sitio. Solo se necesita un condensador para el transceptor, y una resistencia de terminación en cada extremo del bus.

Estamos hablando de alrededor de $1 microcontroladores. Hay mucho más que el costo de los autobuses de la MCU. Usted tendrá que agregar el costo total de cada solución para saber que en realidad es más barato. Agregar el costo de la MCU, los conectores, los transceptores, componentes pasivos, PCB, cables, etc.