¿Cuál es el protocolo general para enviar información de un sistema a otro? Por ejemplo, digamos que tenemos alguna información recogida del microcontrolador durante un tiempo que queremos enviar a otro microcontrolador. He oído hablar de las interfaces SPI e I2C, pero no tengo claro cuándo se utiliza un método sobre otro y cómo se implementa. ¿Hay otros métodos además de SPI e I2C que sean comunes? ¿Es el proceso de implementación similar para diferentes microcontroladores? ¿Es básicamente el análisis de bytes de datos lo que estoy haciendo en el microcontrolador receptor?
Respuestas
¿Demasiados anuncios?
reconbot
Puntos
1670
No hay una sola forma de enviar datos, hay muchas formas diferentes de comunicarse en función de la distancia, la velocidad de datos, el entorno, la aplicación...
La capa más baja es la capa física que realmente 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 utilizan señales diferenciales de mayor distancia, por ejemplo en RS-485. Para una transmisión de datos más rápida está Ethernet, que cada vez es más popular.
-
También hay varios estándares inalámbricos.
Por encima 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, el enrutamiento en una red y muchas otras cosas. Por ejemplo, el protocolo de Internet es una pila bastante compleja de varias capas, normalmente sobre el protocolo Ethernet.
jason saldo
Puntos
5036
Una simple serie UART (una línea de Tx y otra de Rx sin reloj discreto) y puede adaptarse fácilmente para cruzar entre diferentes potenciales (incluso circuitos primarios y secundarios) con optoaisladores o aislantes magnéticos .
En cuanto a los protocolos, cualquier cosa con bytes de comando definidos y algún tipo de esquema de suma de comprobación funcionará bien. Realmente no hay un protocolo estándar que lo cubra todo y que se adapte a todos los tipos de comunicación. I2C tiene unos estándares de señalización (que definen el direccionamiento, las paradas, los arranques, etc.) pero el protocolo de lo que realmente se comunica depende exclusivamente del desarrollador.
PMBus , por ejemplo, es un protocolo de comunicación de fuentes de alimentación que utiliza I2C como medio físico.
kender
Puntos
18446
Realmente no hay un protocolo "general", lo que se acabe utilizando depende en gran medida de la aplicación. Para que podamos darle una respuesta mejor, necesitamos entender un poco mejor sus requisitos. 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? ¿A qué velocidad debe llegar la información y con qué frecuencia envía/recibe datos?
Si ha respondido NO a la pregunta 1:
Si sólo hay 2 micrco-controladores en este proyecto, definitivamente puedes usar UART entre ellos. Si ambos necesitan iniciar la comunicación, usa el control de flujo, de lo contrario debería ser trivial enviar datos en una dirección. En la mayoría de los casos debería ser "suficientemente rápido" dado que seleccionas una de las tasas de baudios más altas. I2C y SPI son típicamente buenos sólo para la arquitectura maestro/esclavo.
Si ha respondido SÍ (más de 2 controladores) a la pregunta 1:
- Si hay más de 2 microcontroladores en tu proyecto, ¿cuál inicia las comunicaciones? ¿Será sólo un controlador maestro (es decir, la arquitectura maestro-esclavo)? ¿O cualquiera de los subsistemas podrá 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 necesitas algo más escalable en el que puedas colocar dispositivos direccionables en un bus común. La respuesta a estas preguntas te ayudará a decidir entre I2C y SPI (maestro-esclavo) o algo como CAN (multimaestro).
Lo más probable es que tu microcontrolador tenga un periférico UART, los otros (especialmente CAN) puede que sólo estén disponibles en chips de gama más alta. En cualquier caso, debería haber mucha documentación sobre cómo utilizar estos periféricos para mover bytes.
SPI e I2C son algo similares, en el sentido de que se utilizan más para conectar dispositivos periféricos a un controlador o cpu, que para transferir realmente datos entre sistemas. 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 de periféricos.
La comunicación entre sistemas no es exactamente como conectar un dispositivo a un bus. La conexión al bus permite que el procesador se abalance directamente sobre los registros de un dispositivo, mientras que una interfaz de comunicación 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 qué está conectado en el otro extremo, en lo que respecta al ordenador central.
Por supuesto, este límite es cada vez más difuso. Cosas como PCI e ISA son indiscutiblemente buses; I2C, SPI, USB son posiblemente buses; mientras que RS232, RS485 y ethernet son definitivamente interfaces de comunicación. Pero luego hay cosas como el bus CAN y el 1553, que definitivamente son para mover datos, pero de una manera muy involucrada.
Alex Andronov
Puntos
178
Como ha señalado @Jon, una cuestión a la hora de seleccionar una interfaz de comunicaciones es si una entidad será siempre responsable de iniciar las comunicaciones, o si pueden serlo más de una. Una cuestión relacionada es si una entidad estará siempre preparada para recibir comunicaciones no solicitadas. La SPI se utiliza con frecuencia en aplicaciones en las que una de las partes siempre estará preparada para recibir comunicaciones. Algo como un registro de desplazamiento 74HC595, por ejemplo, nunca está "ocupado". Mientras que SPI es bueno para la comunicación entre un microcontrolador y el hardware que el micro debe controlar, no es realmente bueno para la comunicación entre dos microcontroladores. Cuando dos procesadores con hardware I2C lo utilizan para comunicarse, el software puede tomarse todo el tiempo que quiera (dentro de unas limitaciones muy generosas) para ocuparse de lo que está pasando, sin causar pérdida de datos. Si un procesador se tomara 100 microsegundos para procesar cada byte entrante, eso limitaría mucho el rendimiento, pero el emisor se ralentizaría lo suficiente para que el receptor pudiera seguir el ritmo. La única forma en que esto puede ocurrir con SPI es si se tiene un cable separado para el handshaking.
I2C es realmente un protocolo maravilloso. Las mayores limitaciones que le impiden ser el protocolo más perfecto imaginable son
- Su velocidad es algo limitada; SPI puede ir mucho más rápido, e incluso UARTs pueden ir a veces un poco más rápido
- (2) Aunque es muy conveniente que I2C sólo 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 que los vendedores de controladores soportaran una variante de SPI de tres hilos que incluyera el handshaking. Sin embargo, no conozco ningún controlador que lo haga.
