Dado un sistema integrado que tiene múltiples CPU, ¿cómo podemos diseñar un sistema para la comunicación entre procesadores?

Probablemente no quiera usar TCP / IP.

TCP / IP está diseñado para la comunicación a través de enlaces poco confiables. Hay una gran cantidad de gastos generales integrados diseñados para manejar paquetes perdidos, reensamblaje fuera de servicio, retransmisión, etc.

Si estás en la misma placa, o incluso en el mismo chasis, o posiblemente incluso en el mismo piso, nada de eso debería estar en juego y quieres las comunicaciones más rápidas más ligeras posibles.

NO use Ethernet: para sistemas integrados, desea redes repetibles, confiables y reproducibles. Use algo como un token ring, o un token bus, o una topología de centro de estrella para evitarlo, NUNCA tenga que lidiar con la pérdida de paquetes por colisión. Tengo una historia sobre un escenario de “matar a todos y hacer volar la construcción” de un sistema de control de procesos basado en Ethernet en Argentina que te perdonaré, solo confía en mí en esto …

Bueno, esto es extraño. Voy a estar completamente en desacuerdo con Stan Hanks. Eso simplemente no sucede. Bueno, hay una primera vez para todo …

He usado Ethernet como el plano de control de interconexión en MUCHOS proyectos diferentes, sin ningún efecto negativo. Es barato, conveniente y funciona. Sí, está bien, deja caer paquetes, pero luego puede ocurrir corrupción en cualquier capa de enlace, por lo que debe tener la capacidad de lidiar con los problemas independientemente. Sí, todos los sistemas que he construido son en tiempo real ‘blandos’, por lo que la retransmisión no es un problema.

Del mismo modo, he tenido muy buen éxito con el uso de TCP como IPC. Esto se combina bien con un plano de control de Ethernet poco confiable. Sí, tiene algunos gastos generales, pero a lo largo de los años, probamos muchos, muchos, diferentes mecanismos de IPC y todo lo que hicimos fue recrear efectivamente TCP. Mal. Dado un sistema distribuido, necesita:

• Fiabilidad (implica retransmisiones)
• Control de flujo
• Secuencia

Si los núcleos están en el mismo dado, usa lo que proporciona el proveedor de chips. Típicamente, esto es algún tipo de disposición de memoria compartida. La implementación real puede ser verdadera RAM multipuerto, o más comúnmente algún tipo de acceso arbitrado a RAM estándar.

Para procesadores cercanos, es decir, en la misma PCB, lo más simple es usar SPI; PCI Express es típico para un mayor rendimiento.

Para recorrer gabinetes, las opciones son muchas: ad-hoc RS-485, CAN, EtherCAT, Ethernet estándar, Infiniband, etc.

¿Ves lo que está pasando aquí? Su consulta está poco restringida. Debe profundizar más en los requisitos del problema: costo, rango, potencia, complejidad, inmunidad al ruido, latencia, fluctuación de fase, topología, etc.

Realmente depende de lo que pretendes lograr a través de la comunicación. Si la intención es la invocación de método remoto (RMI), cree su propio mecanismo de IPC para ordenar / descomponer las interfaces en la memoria compartida. Si desea transferir datos, pero no es crítico en el tiempo, puede usar Ethernet virtual entre los procesadores.

Los he usado todos de vez en cuando. Generalmente trabajando con procesadores de señal digital, el DSP particular tiene uno de estos incorporado. Usas eso. Depende principalmente de los requisitos y el tiempo de desarrollo. Por ejemplo, un UART es simple de desarrollar pero muy lento. TCP o UDP es más rápido, pero es mejor comprar el software para la CPU que escribirlo usted mismo: modifíquelo si es necesario, pero no reinvente la rueda a menos que sea necesario.

A decir verdad, para cuando yo, el programador, obtenga el proyecto, el ingeniero eléctrico ya ha especificado el IPC, porque esa persona tiene que conectar la maldita cosa. Por lo general, estoy bien con eso. Esta persona me consultará a veces, pero en su mayoría no necesitan mi consejo y puedo trabajar con cualquier cosa que me den.

Esta es una pregunta demasiado complicada sin saber mucho acerca de su sistema embebido y la cantidad de comunicaciones necesarias entre los componentes. He visto utilizar la mayoría de los métodos que describe, por razones que eran apropiadas para los tipos de CPU utilizados y las necesidades del sistema. He visto el uso de TCP / IP, y según lo implica Thirumal Vencat, me pareció una exageración considerable (el sistema tenía un núcleo Linux incorporado en cada una de varias PCB que se comunicaban a través de una Ethernet local).

El problema con todos los sistemas en serie que menciona es que tienden a ser de dos terminales o maestro / esclavo, o ambos. Lo que podría no ser un desastre si tiene exactamente dos CPU, pero de lo contrario requiere ingeniería. Incluso si tuviera un Ethernet local, estaría tentado de ver si podría considerarlo como un canal de comunicaciones confiable en orden (no es cierto para una red), y optar por un protocolo mucho más ligero que TCP / IP.

SPI es la mejor y más rápida opción para arquitecturas de procesador maestro / esclavo. Multimaster I2C es mucho más lento, pero tiene la ventaja de que todos los procesadores son simétricos y cualquiera de ellos puede iniciar una transferencia a cualquier otro. También necesita menos pines y cables con I2C. Si solo tiene 2 procesadores, también puede considerar UART. Aunque es lento y viejo, pero es simétrico.

Todo depende de los requisitos de velocidad, confiabilidad, latencia, tamaño de bloque y tiempo. Si necesita la velocidad máxima, necesita una interfaz de bus paralelo. La mayoría de las veces, los requisitos son más modestos y se pueden cumplir con I2C o SPI. Incluso puedes ir a la vieja escuela y usar UARTS. Si tiene espacio para pilas TCP / IP en ambos extremos, puede usar TCP / IP o UDP, claro. Por lo general, es exagerado, pero es muy hábil, puede tener tantas conexiones virtuales separadas en cada sentido como desee.

Lea conceptos simples de subprocesamiento múltiple y sincronización e intente implementar ejemplos simples utilizando las API POSIX en Linux. Internet lo guiará con este consejo.

No estoy familiarizado con el IPC disponible en los sistemas embebidos, pero el TCP es demasiado pesado para cualquier comunicación dentro de un sistema. Esto es cierto para los servidores, creo que esto también debería ser cierto para los sistemas integrados.