¿Protocolo general para la transferencia de datos de un sistema a otro?

SPI e I2C son similares, ya que en realidad se usan más para conectar dispositivos periféricos a un controlador o CPU que a la transferencia de datos entre sistemas. El USB es otra interfaz que la gente parece querer tratar como un sistema de comunicación, que en realidad es un bus de conexión periférico.

La comunicación entre sistemas no es exactamente como conectar un dispositivo a un bus. La conexión de bus permite al procesador golpear directamente los registros en un dispositivo, mientras que una interfaz de comunicación le permite enviar / recibir flujos de datos. Un dispositivo conectado a un bus generalmente necesita un controlador de dispositivo, mientras que con las comunicaciones, realmente no importa lo que esté conectado en el otro extremo, en lo que respecta a la computadora host.

Por supuesto, esto se está convirtiendo en un límite cada vez más nublado. Cosas como PCI e ISA son indiscutiblemente autobuses; I2C, SPI, USB son discutiblemente buses; mientras que RS232, RS485 y Ethernet son definitivamente interfaces de comunicaciones. Pero luego hay cosas como el bus CAN y 1553, que definitivamente se refieren a mover datos, pero de una manera muy complicada.

No hay una única forma de enviar datos, hay muchas formas diferentes de comunicarse según la distancia, la velocidad de datos, el entorno, la aplicación ...

La capa más baja es la capa física , que en realidad mueve los bits.

• SPI e I²C son para distancias cortas dentro de un dispositivo, donde no hay mucho ruido que pueda perturbar la transmisión.

• Para una comunicación no demasiado rápida en distancias de hasta decenas de metros, la comunicación en serie a través de RS-232 es una buena opción.

• Si hay más ruido o se utilizan señales diferenciales de mayor distancia, por ejemplo, en RS-485. Para una transmisión de datos más rápida, existe Ethernet, que se está volviendo cada vez más popular.

• Luego también hay varios estándares inalámbricos.

En la parte superior de la capa física hay más capas que organizan cómo se envían los datos, para detectar y corregir errores en la transmisión, enrutar en una red y muchas otras cosas. Por ejemplo, el protocolo de Internet es una pila bastante compleja de varias capas, generalmente encima del protocolo de Ethernet.

Se puede usar un simple UART (una Tx y una línea Rx sin reloj discreto) y se puede usar ser fácilmente adaptado para cruzar entre diferentes potenciales (incluso circuitos primarios y secundarios) con optoaisladores o Aisladores magnéticos .

En lo que respecta a los protocolos, cualquier cosa con bytes de comando definidos y algún tipo de esquema de suma de verificación funcionará bien. Realmente no existe un protocolo estándar que cubra todo y que se adapte a todos los tipos de comunicaciones. I2C tiene estándares de señalización (definición de direccionamiento, paradas, inicio, etc.) pero el protocolo de lo que realmente se está comunicando depende exclusivamente del desarrollador.

PMBus , por ejemplo, es un protocolo de comunicación de fuente de alimentación que utiliza I2C como medio físico.

Realmente no hay un protocolo "general", lo que terminas usando depende mucho de la aplicación. Para que podamos darle una mejor respuesta, necesitamos entender un poco mejor sus necesidades. Menciona que le gustaría tener microcontroladores separados que se comunican entre sí como subsistemas.

Algunas preguntas sobre esta aplicación:

1. ¿Habrá más de 2 microcontroladores en este proyecto?
2. ¿Cuáles son sus requisitos de velocidad y rendimiento? ¿Qué tan rápido necesita llegar la información y con qué frecuencia está enviando / recibiendo datos?

Si respondió NO a la pregunta 1:

Si solo hay 2 microcontroladores en este proyecto, definitivamente puedes usar UART entre ellos. Si ambos necesitan iniciar la comunicación, use el control de flujo; de lo contrario, debería ser trivial enviar los datos en una dirección. En su mayor parte, debería ser "lo suficientemente rápido" dado que selecciona una de las velocidades de transmisión más altas. I2C y SPI normalmente solo son buenos para la arquitectura maestro / esclavo.

Si respondió SÍ (más de 2 controladores) a la pregunta 1:

• Si hay más de 2 microcontroladores en su proyecto, ¿cuál inicia las comunicaciones? ¿Solo será un controlador maestro (es decir, la arquitectura maestro-esclavo)? ¿O podría alguno de los subsistemas hablar en cualquier momento?
• ¿Es necesario que alguno de los subsistemas se comunique entre sí? por ejemplo: para los dispositivos A, B y C: A puede enviar a B y C, y B puede enviar a A y C, etc.

Así que ahora necesita algo más escalable donde pueda colocar dispositivos direccionables en un bus común. La respuesta a estas preguntas de seguimiento te ayudará a decidir entre I2C y SPI (maestro-esclavo) o algo así como CAN (maestro múltiple).

Lo más probable es que su microcontrolador tenga un periférico UART, los otros (especialmente CAN) pueden estar disponibles solo en chips de gama más alta. En cualquier caso, debería haber mucha documentación sobre cómo usar estos periféricos para mover bytes.

Como se señaló en @Jon, un problema al seleccionar una interfaz de comunicaciones es si una entidad siempre será responsable de iniciar las comunicaciones, o si más de una entidad puede ser tan responsable. Un asunto relacionado es si una entidad siempre estará lista para recibir comunicaciones no solicitadas. SPI se usa frecuentemente en aplicaciones en las que un lado siempre estará listo para recibir comunicación. Algo así como un registro de desplazamiento 74HC595, por ejemplo, nunca está "ocupado". Si bien SPI es bueno para la comunicación entre un microcontrolador y el hardware que se supone que debe controlar el micro, realmente no es bueno para la comunicación entre dos microcontroladores. Cuando dos procesadores con hardware I2C lo utilizan para comunicarse, el software puede tomar todo el tiempo que quiera (dentro de restricciones muy generosas) para hacer frente a lo que está sucediendo, sin causar la pérdida de datos. Si un procesador tomara 100 microsegundos para procesar cada byte entrante, eso limitaría severamente el rendimiento, pero el remitente se ralentizaría lo suficiente para que el receptor se mantuviera al día. La única forma en que generalmente puede suceder con SPI es si uno tiene un cable separado para el protocolo de enlace.

I2C es realmente un protocolo maravilloso. Las mayores limitaciones que impiden que sea el protocolo más perfecto que se pueda imaginar son

1. Su velocidad es algo limitada; SPI puede ir mucho más rápido, e incluso los UART a veces pueden ir un poco más rápido
2. (2) Si bien es muy conveniente que I2C solo necesite dos cables, ambos deben ser capaces de comunicación bidireccional de colector abierto. Esto dificulta el envío de I2C a través de repetidores.

Personalmente, me gustaría ver que los proveedores de controladores admitan una variante de tres hilos de SPI que incluyó el protocolo de enlace. Sin embargo, no conozco ningún controlador que lo haga.

Sin ningún orden en particular, las instancias de capa física más populares para 2 CPU en el mismo cuadro parecen ser:

• SPI en cadena de margaritas (como la utilizada por JTAG)
• SPI de selección de cable por esclavo
• "Comunicación RS-232 asíncrona de arranque-parada asíncrono" TTL a nivel "(que conecta directamente el pin UART TX de una CPU al pin UART RX de otra CPU)
• I2C
• datos de 8 bits + luz estroboscópica (como el puerto paralelo de la impresora IEEE 1284)
• memoria compartida (solo una CPU controla la dirección / datos / bus de control a la vez)

Estas instancias de capa física (así como otras instancias de capa física para 2 CPU en cajas separadas) generalmente proporcionan una secuencia de bytes al software que implementa los niveles más altos del sistema de comunicación.

Los programadores inteligentes escriben el software de tal manera que cuando el tipo de hardware decide arrancar una instancia de capa física y reemplazarla con una instancia de capa física completamente diferente, solo necesitan volver a escribir algunas funciones para alimentar su flujo de salida de bytes al hardware y leer un flujo de bytes del hardware, y todo lo relacionado con el protocolo de nivel superior sigue funcionando sin cambios.

El protocolo para enviar información de una CPU a otra CPU casi siempre implica interpretar el flujo de bytes como una serie de paquetes:

1. preámbulo
2. encabezado
3. datos serializados (posiblemente escapados)
4. tráiler

Algunas personas parecen disfrutar creando protocolos totalmente nuevos, personalizados e incompatibles al mezclar y combinar (2) uno de los muchos tipos de estructura de encabezado con (3a) uno de los muchos tipos de datos de serialización con (3b) uno de muchos tipos de escape de esos datos serializados con (4) uno de los muchos tipos de tráiler.

Algunos de los protocolos más simples para encapsular datos en un paquete incluyen:

• el protocolo Mini SSC de tres bytes
• formato de cadena de red

Los protocolos ligeramente más complicados para encapsular datos en un paquete incluyen:

• vscp - Protocolo de control muy simple
• IP sobre conexiones serie

Hay una larga lista de protocolos en

• protocolos comunes utilizados en sistemas integrados
• Programación en serie: formación de paquetes de datos

Puedes disfrutar leyendo "Protocol Design Folklore" por Radia Perlman que describe cómo el diseño del protocolo puede ir mal.

No hay un único protocolo 'general'. La elección puede (por ejemplo) depender de:

• distancia
• rendimiento requerido
• disponibilidad de periféricos especiales
• nivel de ruido
• necesidad de aislamiento óptico
• criticidad (tasa de falla tolerable)
• potencia de CPU disponible en ambos extremos
• pines de E / S disponibles en ambos extremos

En muchos casos, debe desactivar la capa física (niveles de señal) de la capa de enlace de datos (+/- la forma en que se codifican los datos) (verifique el modelo OSI, más abajo 2 ..4 capas). Las posibles capas de phyiscal son, por ejemplo:

• simple 5V o 3.3V o incluso 1.8V TTL
• cualquiera de los anteriores, pero el colector abierto en lugar de push-pull
• señalización de voltaje lov balanceada (a menudo utilizada con FPGA)
• volatge higer balanceado (RS485, RS432)
• voltaje superior de un solo extremo (RS232)
• acoplado de trafo equilibrado (varias versiones de Ethernet, audio PDIF)
• óptico (ethernet óptico, enlace de enlace)

Puede usar una línea para llevar datos e información de reloj, o dividir esto en varias líneas. Este último solía ser popular, pero en la actualidad la mayoría de los protocolos nuevos / rápidos tienden a usar una línea (o un par de líneas que actúan como una).

Hay muchas formas de codificar datos y reloj en una línea. RS232 tradicionalmente usa NRZ, hay codificación Machester, y varios usos de formato en discos duros con nombres curiosos en la línea 2.7 RLL.

Para resumir: hay miles de maneras de hacer la comunicación entre sistemas. Y ni siquiera he mencionado conectores o aspectos de alto nivel como detección y recuperación de errores, codificación de datos, compresión y encriptación ...