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

18

¿Cuál es el protocolo general para enviar información de un sistema a otro? Por ejemplo, supongamos que tenemos cierta información recopilada del microcontrolador durante un período de tiempo que queremos enviar a otro microcontrolador. He oído hablar de las interfaces SPI e I2C, pero no estoy claro cuando usa un método sobre otro y cómo lo implementa. ¿Existen otros métodos además de SPI e I2C que sean comunes? ¿El proceso de implementación es similar para diferentes microcontroladores? ¿Está básicamente analizando bytes de datos que estoy haciendo en el microcontrolador receptor?

i2c spi data

— O_O
fuente

44

¿Qué es lo concreto que quieres hacer?

— starblue

Solo pensando en cómo hacer que diferentes partes de un sistema pasen datos entre sí en una caja pequeña, por lo que se puede suponer que la distancia es muy corta. La razón de tener diferentes piezas en una caja es simplificar las funciones de modo que cada pieza tiene su propia función (es de esperar que tenga sentido ..)

— O_O

2

eso no es lo que la gente normalmente llama un sistema. Esos son más de lo que yo definiría como subsistemas. Forman parte de lo que podría considerarse un sistema único que realiza un solo conjunto de tareas. Es semántica, pero creo que muchas de sus respuestas son muy amplias porque no tienen una idea perfecta de lo que está buscando en la pregunta.

— Kortuk

1

siguiendo las líneas de lo que dijo Kortuk, ayuda a definir el problema. Una pregunta importante que debe hacerse es si tiene la intención de reemplazar subsistemas individuales con diferentes implementaciones de la misma función, o si este es un diseño único tal como está. Si usa un bus real y expone los detalles de implementación de los subsistemas a su CPU, entonces un cambio de subsistema requiere un cambio / w para su controlador, mientras que si usa una interfaz de comunicación, no importa cómo implemente un (reemplazo ) subsistema, siempre que cumpla con el mismo protocolo de mensaje.

— JustJeff

No es más sencillo dividir la funcionalidad en múltiples dispositivos sin más motivo que la separación de tareas. Las comunicaciones y la sincronización son más complejas que tener dos procesos en el mismo micro. Ahora, si estos procesos tienen perfiles de latencia particularmente incompatibles (uno debe actualizarse rápidamente mientras que el otro puede tomar un tiempo para completar un fragmento), entonces PUEDE haber una razón válida para dividirlos. Incluso entonces, la solución más común es usar interrupciones o encontrar una manera de desglosar aún más la tarea más larga. Con lo que has descrito, me inclino a pensar que deberías repensar esto.

— Darron

10

SPI e I2C son algo similares, ya que realmente se usan más para conectar dispositivos periféricos a un controlador o CPU que para transferir datos entre sistemas. USB es otra interfaz que las personas parecen querer tratar como un sistema de comunicación, que de hecho 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 que el procesador golpee directamente los registros en un dispositivo, mientras que una interfaz de comunicación le permite enviar / recibir flujos de datos. Un dispositivo conectado en 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 más peligroso todo el tiempo. Cosas como PCI e ISA son indiscutiblemente autobuses; I2C, SPI, USB son posiblemente 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 trata de mover datos, pero de una manera muy complicada.

— JustJeff
fuente

¿CANbus está muy involucrado y Ethernet no? CAN es muy simple para trabajar para mensajes simples de ida y vuelta. Son chips dedicados y la mayoría de las familias admiten soporte interno para sus microcontroladores.

— Kortuk

@Kortuk: en la medida en que algo así como 232 tiene una especie de simetría entre pares, mientras que 1553 o PUEDEN imponer una relación maestro / esclavo, sí. No creo haber dicho que Ethernet sea simple, solo que no impone una distinción controlador de dispositivo / dispositivo de bus en los puntos finales.

— JustJeff

también, divulgación completa: mi opinión sobre CAN es totalmente de exposición tangencial; ha sido un periférico opcional no utilizado en varios sistemas en los que he trabajado, pero después de cientos de pases a través de la documentación, absorbe un poco sobre las opciones no utilizadas solo por ósmosis. Así que estoy trabajando bajo el supuesto de que CAN es un tipo de arquitectura de controlador / dispositivo controlado.

— JustJeff

Creo que el autobús tiene diferentes significados en diferentes contextos. Desde un nivel esquemático, cualquier interfaz con múltiples señales puede considerarse un bus. A medida que avanza a niveles más altos con más abstracción, el autobús cambia de significado. Un poco más alto, el bus generalmente significa que hay o pueden haber múltiples dispositivos involucrados. RS485 multipunto es definitivamente un bus, por ejemplo. Mucho más arriba, desde el punto de vista de un dispositivo Linux, RS485 se convierte nuevamente en una interfaz de comunicación y pasa a ser un bus ... hasta que agrega su propia capa de protocolo encima y la vuelve a convertir en un bus. En cada nivel tiene diferentes significados.

— Darron

11

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 algunas 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 usan 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.

Además 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, enrutamiento en una red y muchas otras cosas. Por ejemplo, el protocolo de Internet es una pila bastante compleja de varias capas, generalmente por encima del protocolo Ethernet.

— starblue
fuente

7

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

En cuanto 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 hay un protocolo estándar de cobertura que se adapte a todos los tipos de comunicaciones. I2C tiene estándares de señalización (definición de direccionamiento, paradas, inicios, 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.

— Adam Lawrence
fuente

6

Realmente no hay un protocolo "general", lo que terminas usando depende en gran medida de la aplicación. Para que podamos darle una mejor respuesta, necesitamos entender sus requisitos un poco mejor. Usted menciona que le gustaría tener microcontroladores separados que se comuniquen entre sí como subsistemas.

Algunas preguntas sobre esta aplicación:

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

Si respondió NO a la pregunta 1:

Si solo hay 2 micrcocontroladores en este proyecto, definitivamente puede usar UART entre ellos. Si ambos necesitan iniciar la comunicación, use el control de flujo, de lo contrario, debería ser trivial enviar datos en una dirección. En su mayor parte, debe ser "lo suficientemente rápido" dado que selecciona una de las velocidades de transmisión más altas. I2C y SPI generalmente 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? ¿Será solo un controlador maestro (es decir, arquitectura maestro-esclavo)? ¿O alguno de los subsistemas podría hablar en cualquier momento?
¿Es necesario que alguno de los subsistemas se comunique entre ellos? 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.

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

Lo más probable es que su microcontrolador tenga un periférico UART, los otros (especialmente CAN) solo pueden estar disponibles 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.

— Jon L
fuente

5

Como señaló @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. Una cuestión relacionada es si una entidad siempre estará lista para recibir comunicaciones no solicitadas. SPI se usa con frecuencia en aplicaciones donde 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 un hardware que el micro debe controlar, en realidad no es bueno para la comunicación entre dos microcontroladores. Cuando dos procesadores con hardware I2C lo usan para comunicarse, el software puede tardar todo el tiempo que quiera (dentro de limitaciones muy generosas) para lidiar con lo que está sucediendo, sin causar pérdida de datos. Si un procesador tomara 100 microsegundos para procesar cada byte entrante, eso limitaría severamente el rendimiento, pero el emisor reduciría la velocidad lo suficiente como para que el receptor pueda mantener el ritmo. La única forma en que generalmente puede suceder con SPI es si uno tiene un cable separado para el apretón de manos.

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

Su velocidad es algo limitada; El SPI puede ir mucho más rápido e incluso los UART a veces pueden ir un poco más rápido
(2) Si bien es muy conveniente que I2C solo necesite dos cables, ambos cables 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 vendedores de controladores admitan una variante de tres hilos de SPI que incluye el apretón de manos. Sin embargo, no conozco ningún controlador que lo haga.

— Super gato
fuente

Es curioso que debas mencionar esto ... Tengo que convertir una interfaz SPI en una interfaz no bidireccional tipo I2C (el primer byte es una dirección) para permitir que participen muchos más dispositivos en el bus de los que tengo seleccionados para el chip. . Funciona si sus dispositivos esclavos son todos FPGA. :) Yo también he deseado que hubiera algo entre esos dos estándares síncronos principales.

— Darron

Oh, supongo que debería aclarar que la salida habilitada en los esclavos no se confirma hasta que se recibe su byte de dirección y permanecen activados hasta que se desascribe la selección de un solo chip ... por lo que obviamente es ligeramente diferente del nivel alto SPI + normal protocolo. Sin embargo, es totalmente compatible con SPI estándar desde el punto de vista del dispositivo maestro. (como un microprocesador)

— darron

@darron: Genial. Me pregunto qué tendría que pasar para que la industria comience a usar un bus de comunicaciones de tres hilos de estándar abierto donde los cables se activan de manera activa. Supongo que hay un pequeño conflicto entre evitar las dominadas pasivas y permitir que cualquier dispositivo señale una interrupción, aunque eso podría remediarse agregando un pin de interrupción que podría conectarse al maestro o no a conveniencia de los esclavos (mi implementación actual de el protocolo solo tiene un esclavo, por lo que puede usar el cable de retorno de datos para indicar asincrónicamente cuándo desea recibir servicio).

— supercat

@darron: para evitar tener que usar un pin de selección de chip, el maestro señala el inicio del comando enviando dos bordes ascendentes en el cable de datos mientras el reloj está bajo; los esclavos pueden indicar si su último byte de datos fue válido emitiendo un valor de estado cuando el reloj y los datos están bajos (inactivo); de lo contrario, indican que quieren atención cuando el reloj está bajo y los datos están altos. Si estuviera diseñando hardware maestro para este protocolo, agregaría la capacidad de enviar pulsos de 8 relojes donde el reloj reflejado del cable de datos, y en el hardware esclavo incluiría un recuento asíncrono del número de flancos ascendentes durante ...

— supercat

@darron: ... un byte de datos. Si cinco o más, el byte sería ignorado (el esclavo asumiría que el maestro estaba interesado en recibir un byte de datos, pero no tenía nada que realmente quisiera decir). Sin embargo, eso no sería tan significativo como hacer que el esclavo informe el estado del último byte cuando el reloj estaba bajo (lo que, si el dispositivo esclavo fuera un procesador, permitiría al maestro saber que el esclavo no estaba listo y había perdido la última 'oportunidad de transacción'.

— supercat

3

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

SPI en cadena (como el utilizado por JTAG)
select-wire-per-slave SPI
"Nivel TTL RS-232", también conocido como "comunicación serie asíncrona de arranque-parada" (conectando 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 del puerto de impresora IEEE 1284)
memoria compartida (solo una CPU maneja el bus de dirección / datos / 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 reescribir algunas funciones para alimentar su flujo de bytes de salida al hardware y leer de nuevo una secuencia de bytes del hardware, y todo el protocolo de nivel superior continúa 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:

preámbulo
encabezamiento
(posiblemente escapado) datos serializados
remolque

Algunas personas parecen disfrutar creando protocolos totalmente nuevos, personalizados e incompatibles al mezclar (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 los muchos tipos de escapar 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:

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

Hay una larga lista de protocolos en

Puede disfrutar leyendo "Folklore de diseño de protocolo" de Radia Perlman, que describe cómo puede fallar el diseño de protocolo.

— davidcary
fuente

3

No hay un protocolo 'general' único. 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 distinguir 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, capas inferiores de 2 ..4). Las posibles capas físicas son, por ejemplo:

simple 5V o 3.3V o incluso 1.8V TTL
cualquiera de los anteriores pero de colector abierto en lugar de push-pull
señalización de voltaje lov balanceado (a menudo usado con FPGA's)
Voltaje más alto equilibrado (RS485, RS432)
Tensión más alta de un solo extremo (RS232)
equilibrado trafo-acoplado (varias versiones de ethernet, audio PDIF)
óptico (ethernet óptico, toslink)

Puede usar una línea para transportar datos e información del reloj, o dividir esto en varias líneas. Este último solía ser popular, pero hoy en día 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 sola).

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

En resumen: hay miles de millones de formas de comunicación entre sistemas. Y ni siquiera he mencionado conectores o aspectos de nivel superior como detección y recuperación de errores, codificación de datos, compresión y encriptación ...

— Wouter van Ooijen
fuente