Comunicación sencilla y económica entre dos microcontroladores

Question

¿Qué compensaciones y opciones de conexión hay en bajo coste comunicación bidireccional entre sólo dos microcontroladores?

En este caso:

• Relación maestro/esclavo, flujo de datos bidireccional
• Distancia inferior a una pulgada
• El esclavo se conecta al maestro (por lo que es imprescindible la protección ESD en las conexiones).
• El micro esclavo es bastante tonto, pero se necesitan datos de velocidad media para la E/S de bloque desde una tarjeta SD. Aparte de la tarjeta SD, hay un poco de E/S de baja velocidad en la unidad esclava donde la velocidad no es un problema.
• Barato, barato, barato.
• El número de pines está restringido.
• Preferir una sobrecarga mínima de la pila de protocolos.

Las opciones obvias incluyen SPI, CAN, USB, Serie de nivel TTL. I2C y 1-Wire son probablemente demasiado lentos. Debido a la cuestión del número de pines modular la fuente de alimentación para los datos sería ideal, si hubiera un chipset a nivel de consumidor que lo hiciera, ahorrando dos pines sobre los métodos serie.

Answer 1

Dadas sus opciones disponibles, parece que do tienen algunos pines disponibles:

• SPI es full-duplex y requiere 1 reloj + 1 dato en cada dirección + 1 chip select opcional = 3 pines
• CAN es semidúplex y requiere 2 datos para comunicaciones bidireccionales = 2 pines
• USB es half-duplex y requiere 2 datos para comunicaciones bidireccionales = 2 pins
• TTL Serial es lo que quieras, pero la mayoría de la gente utiliza un UART para ello, requiere 1 datos en cada dirección = 2 pines full duplex o 1 pin con algún truco
• UART es full-duplex y requiere 1 dato en cada dirección = 2 pines o 1 pin con algún truco
• I2C es half-duplex y requiere 1 reloj + 1 dato = 2 pines

Así que parece que el consenso es de 2 pines si quieres comunicación bidireccional, o posiblemente 3 para SPI. A igualdad de número de pines, yo optaría por la UART si hay una disponible en ambos chips. Asumiendo una conexión 1:1, puedes simplemente lanzar datos sin tener en cuenta el tiempo o las colisiones, y el hardware es realmente fácil.

En cuanto a la sobrecarga de la pila, hay muchos protocolos diferentes que pueden operar desde una UART, pero probablemente sea mejor en este caso definir el tuyo propio. Desde el punto de vista de las comunicaciones, sólo estás enviando bytes y recibiéndolos en el otro extremo. El hardware se sincronizará automáticamente con cada byte, pero todavía tienes que saber qué byte es qué. Tendrás ese problema independientemente de la opción que elijas.

Si eres listo con una UART (y estoy a punto de darte la respuesta), puedes conectar los dos pines TX juntos con dos resistencias en serie, luego tener un comparador en cada extremo que maneje el pin RX basado en el TX local y la derivación central de las dos resistencias. Esto permite full-duplex en un solo cable. Ver abajo para un esquema.

Para ESD, añada una resistencia en serie dentro de ambas cajas para cada pin y coloque algunos diodos de sujeción en el lado exterior de la resistencia. Hay diodos especialmente fabricados para esto.

---

simular este circuito - Esquema creado con CircuitLab

• Las resistencias "bajas" son para proteger los diodos ESD. Las hojas de datos pueden o no afirmar que son innecesarias, pero yo las usaría de todos modos. Hazlas lo suficientemente grandes para que cumplan su función; tienen que parecer un cortocircuito comparadas con las resistencias "altas".
• Las resistencias "altas" son para mezclar las dos señales TX en el cable común.
• Las resistencias de 10k y 5k son para tomar la señal TX de rango completo de alimentación y proporcionar el umbral apropiado para los comparadores.
• Si los dos dispositivos se alimentan de forma independiente, probablemente no debería tener la "Conexión opcional", dejándole con 2 cables en lugar de 3. No veo cómo se puede comunicar en absoluto con menos pines que esto, a menos que vaya inalámbrica.

Así es como funciona:

• Si ambos TX están altos, la línea común estará alta y ambos comparadores tendrán salida alta.
• Si ambos TX están bajos, la línea común estará baja y ambos comparadores tendrán salida baja.
• Si un TX es alto y el otro bajo, la línea común será de rango medio y cada comparador tendrá un umbral diferente basado en su TX local. Así, el que tenga un TX alto tendrá un umbral más alto que el común de rango medio y su salida será baja, y el que tenga un TX bajo tendrá un umbral más bajo que el común de rango medio y su salida será alta.

Así que en todos los casos, la salida del comparador de recepción es igual a la TX de envío.

Si no te gusta la complejidad del hardware dentro de la caja, entonces puedes usar un pin discreto para cada dirección y mantener sólo las resistencias "alta" y "baja" y los diodos ESD - una copia separada para cada pin.

Answer 2

Nunca he utilizado CAN bus, así que no puedo opinar al respecto. Lo que deja SPI, I2C, TTL serie y USB.

El puerto serie TTL suele funcionar a 115.200 baudios, pero muchos microcontroladores pueden hacerlo a 1 Mb/s o más. Tendrás que comprobar las hojas de datos de tu microcontrolador y ver si puede funcionar a esa velocidad. Obviamente, ambos extremos deben coincidir. La ventaja de la serie TTL es que sólo requiere dos cables.

Al principio, I2C estaba limitado a 100 Kb/s, y después a 400 Kb/s. El estándar más reciente es de 1 Mb/s. Pero es posible que tu microcontrolador tenga una velocidad superior. De nuevo, consulta las hojas de datos. Al igual que la serie TTL, I2C sólo requiere dos cables.

SPI es una raza completamente diferente. En teoría, puede funcionar a 50 Mb/s más o menos. He utilizado uno con una tarjeta SD en un producto comercial a 25 Mb/s sin problemas. El inconveniente es que la interfaz SPI requiere cuatro cables. En realidad, con sólo un esclavo en el bus, no se necesita la línea de selección de chip a menos que sea requerido por la interfaz de hardware. Si sólo estás enviando datos al esclavo, también podrías deshacerte de la línea MISO, si el microcontrolador te permite reasignarla como un pin GPIO. En el caso de que usted está abajo a dos cables, como los demás.

La sobrecarga de firmware para las tres primeras es mínima; la serie TTL es probablemente la más sencilla. I2C y SPI son más o menos lo mismo.

Puedes olvidarte del USB, aunque es potencialmente el más rápido si ejecutas USB 2.0. (USB 1.1 sólo tiene 12 Mb/s, así que ni siquiera se puede comparar favorablemente con SPI en cuanto a velocidad). El primer problema con USB es que necesitas implementar un anfitrión en un lado y un esclavo en el otro. Para ello se necesitan microcontroladores que dispongan de las interfaces, y las interfaces de host USB sólo suelen encontrarse en chips de gama bastante alta. Varios kB de firmware. La buena noticia es que, por lo general, se puede obtener una biblioteca del fabricante. La mala noticia es que tardarás semanas en hacerlo funcionar.

Tendrás que proporcionar tu propia protección ESD en las interfaces. Hay un montón de chips baratos que realizan esta función, como el TPD4E1B06 para 61ȼ en Digi-Key.

Answer 3

¿Ha pensado en la UART? Para la comunicación unidireccional, sólo se necesita un cable. Si vas a enviar grandes cantidades de datos, puedes ser inteligente y hacer que el único cable alterne entre TX y RX de acuerdo con algunas reglas inventadas. Puedes crear tu propio protocolo para gestionar la corrección de errores, la contención del bus y demás. Lo bueno es que incluso los MCUs más baratos tienen UART integrada (no se puede decir lo mismo de USB o CAN).

Si buscas, probablemente puedas encontrar esquemas de modulación de la fuente de alimentación, pero es probable que sus velocidades de datos sean mucho más lentas.

Answer 4

Basado en su declaración "Debido a la cuestión de la cantidad de pines modulación de la fuente de alimentación para los datos sería ideal, si había un chipset de nivel de consumo que lo hizo, el ahorro de dos pines sobre los métodos de serie", suena como 1 hilo sin embargo, proporciona datos a baja velocidad y no indica cuál podría ser su requisito de velocidad.

Answer 5

No le veo mucho sentido a un sistema maestro/esclavo con sólo dos µC que ambos sean programados por ti mismo.

El pinout más pequeño que puedes conseguir es probablemente UART (2pins). Como estás programando ambos µC, puedes elegir una velocidad arbitraria. Un µC AVR podría ejecutar UART a 1Mbps, y suponiendo que elijas 1 bit de parada, sin paridad, y 9 bits de datos puedes obtener un 82% de utilización del ancho de banda.

Siempre puedes crear un protocolo personalizado similar a 1-Wire (pero mucho más rápido). Sin embargo, es un enfoque bastante tonto, ya que consumiría toda su capacidad de procesamiento en el mantenimiento del protocolo.