Comunicación simple de bajo costo entre dos microcontroladores

¿Qué compensaciones y opciones de conexión existen en la comunicación bidireccional de bajo costo entre solo dos microcontroladores?

En este caso:

  • Relación maestro/esclavo, flujo de datos bidireccional
  • Distancia por debajo de una pulgada
  • El esclavo se conecta al maestro (por lo que la protección ESD en las conexiones es imprescindible).
  • El micro esclavo es bastante tonto, pero se necesitan datos de velocidad media para bloquear E/S 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 conteo de pines está restringido.
  • Prefiere la sobrecarga mínima de la pila de protocolos.

Las opciones obvias incluyen SPI, CAN, USB, TTL Level Serial. I2C y 1-Wire probablemente sean demasiado lentos. Debido al problema del conteo de pines, modular la fuente de alimentación para datos sería ideal, si hubiera un conjunto de chips de nivel de consumidor que lo hiciera, ahorrando dos pines sobre los métodos en serie.

¿Qué quiere decir con "datos de velocidad media"? ¿Tienes un orden de magnitud en mente? 100kb/s? 1 Mb/s? ¿Tiene restricciones sobre qué MCU quiere/necesita usar? Cuando dice maestro/esclavo, ¿quiere admitir la transmisión bidireccional? ¿O simplemente quiere "lanzar" datos al esclavo tonto sin ningún tipo de esquema de corrección de errores o retroalimentación?
"bajo costo" y "simple" y "modulando la fuente de alimentación" no van juntos. He trabajado en datos seriales codificados en Manchester diferencial a través de una conexión de fuente de alimentación de 12 V y GND, y no es divertido tanto en software como en hardware, ¡así que ni se moleste con esa vía!
@LorenzoDonati Por "datos de velocidad media" me refiero a guardar video codificado en una tarjeta SD, quizás 5 MB/s.
@KyranF que modula la fuente de alimentación solo funcionaría si existiera algún IC Made in China que manejara todo.
Me parece bien. Probablemente haya uno que lo haga parcialmente, pero aún dependería de muchos circuitos externos personalizados

Respuestas (6)

Dadas las opciones disponibles, parece que tiene algunos pines disponibles:

  • SPI es full-duplex y requiere 1 reloj + 1 datos en cada dirección + 1 selección de chip opcional = 3 pines
  • CAN es semidúplex y requiere 2 datos para comunicaciones bidireccionales = 2 pines
  • USB es semidúplex y requiere 2 datos para comunicaciones bidireccionales = 2 pines
  • TTL Serial es cualquier cosa que desee, pero la mayoría de las personas usan un UART para ello, requiere 1 dato en cada dirección = 2 pines full dúplex o 1 pin con algunos trucos
  • UART es full-duplex y requiere 1 dato en cada dirección = 2 pines o 1 pin con algunos trucos
  • I2C es semidúplex y requiere 1 reloj + 1 datos = 2 pines

Entonces, parece que el consenso es de 2 pines si desea una comunicación bidireccional, o posiblemente 3 para SPI. Dado el mismo número de pines, elegiría el UART si hay uno disponible en ambos chips. Suponiendo una conexión 1:1, puede simplemente enviar 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 un UART, pero probablemente sea mejor en este caso definir el suyo propio. Desde la perspectiva de las comunicaciones, solo estás lanzando bytes y recibiéndolos en el otro extremo. El hardware se sincronizará automáticamente con cada byte, pero aún debe saber qué byte es qué. Tendrás ese problema independientemente de la opción que elijas.

Si eres inteligente con un UART (y estoy a punto de darte la respuesta), puedes conectar los dos pines TX junto con dos resistencias en serie, luego tener un comparador en cada extremo que impulsa el pin RX basado en el TX local y la derivación central de las dos resistencias. Esto permite full-duplex en un cable. Vea a continuación un esquema.

Para ESD, agregue una resistencia en serie dentro de ambas cajas para cada pin y coloque algunos diodos de sujeción en el lado externo de la resistencia. Hay diodos hechos especialmente para esto.


esquemático

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 las usaría de todos modos. Hágalos lo suficientemente grandes para hacer su trabajo; deben verse como cortos en comparación 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 deben tomar la señal de TX de rango de suministro completo y proporcionar el umbral adecuado para los comparadores.
  • Si los dos dispositivos se alimentan de forma independiente, probablemente no debería tener la "Conexión opcional", dejándolo con 2 cables en lugar de 3. No veo cómo puede comunicarse con menos pines que esto, a menos que vaya inalámbrico .

Así es como funciona:

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

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

Si no le gusta la complejidad del hardware dentro de la caja, puede usar un pin discreto para cada dirección y mantener solo las resistencias "alta" y "baja" y los diodos ESD, una copia separada para cada pin.

Nunca he usado el bus CAN, así que no puedo comentar sobre eso. Lo que deja SPI, I2C, serie TTL y USB.

La serie TTL generalmente tiene una frecuencia de 115,200 baudios, pero muchos microcontroladores pueden ejecutarla a 1 Mb/s o más. Tendrá que consultar las hojas de datos de su microcontrolador y ver si puede ejecutarlo tan rápido. Obviamente ambos extremos deben coincidir. La ventaja de la serie TTL es que requiere solo dos cables.

I2C originalmente estaba limitado a 100 Kb/s, luego a 400 Kb/s. El último estándar es 1 Mb/s. Pero es posible que su microcontrolador pueda tener un reloj más alto que eso. Nuevamente, verifique sus hojas de datos. Al igual que la serie TTL, I2C solo requiere dos cables.

SPI es una raza completamente diferente. Teóricamente, puede funcionar hasta 50 Mb/s más o menos. He ejecutado uno con una tarjeta SD en un producto comercial a 25 Mb/s sin ningún problema. La desventaja es que la interfaz SPI requiere cuatro cables. En realidad, con solo un esclavo en el bus, no necesita la línea de selección de chip a menos que la interfaz de hardware lo requiera. Si solo está enviando datos al esclavo, también podría deshacerse de la línea MISO, si el microcontrolador le permite reasignarlo como un pin GPIO. En el caso de que te quedes con dos cables, como los demás.

La sobrecarga de firmware para los tres primeros es mínima; La serie TTL es probablemente la más simple. I2C y SPI son casi lo mismo.

Puede olvidarse del USB, aunque es potencialmente el más rápido si ejecuta USB 2.0. (USB 1.1 es de solo 12 Mb/s, por lo que ni siquiera se compara favorablemente con SPI en cuanto a velocidad). El primer problema con USB es que necesita implementar un host en un lado y un esclavo en el otro. Esto requiere microcontroladores que tengan las interfaces, y las interfaces de host USB generalmente solo se encuentran en chips bastante avanzados. Luego está el firmware requerido. Varios kB de firmware. La buena noticia es que, por lo general, puede obtener una biblioteca del fabricante. La mala noticia es que aún le llevará semanas hacerlo funcionar.

Deberá proporcionar su única protección ESD en las interfaces. Hay muchos chips baratos que realizan esta función, como el TPD4E1B06 para 61ȼ en Digi-Key.

ingrese la descripción de la imagen aquí

Acerca de CAN: Es un sistema de bus como I²C. Mientras que I²C está hecho para la comunicación en una PCB, CAN permite distancias de hasta 2 km. Por lo tanto, tiene mucha sobrecarga de protocolo, ya que un mensaje CAN contiene hasta 64 bits de datos, pero también alrededor de 50 bits para la identificación del mensaje, la dirección, el CRC, etc. I²C también "desperdicia" algunos bits para el direccionamiento, pero no tanto. También puede agregar algunos gastos generales de programación. Entonces, definitivamente, ¡no CAN aquí!
61 centavos no es barato al nivel requerido. Con elegir y colocar, los zenders individuales comienzan a parecer baratos.

¿Has considerado UART? Para la comunicación unidireccional, solo se necesita un cable. Si va a enviar grandes cantidades de datos, puede ser inteligente y hacer que el cable único alterné entre TX y RX de acuerdo con algunas reglas inventadas. Puede crear su propio protocolo para gestionar la corrección de errores, la contención de bus, etc. Lo bueno es que incluso los MCU más baratos tendrán UART incorporado (no se puede decir lo mismo de USB o CAN).

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

Según su declaración "Debido al problema del conteo de pines, modular la fuente de alimentación para datos sería ideal, si hubiera un conjunto de chips de nivel de consumidor que lo hiciera, ahorrando dos pines sobre los métodos en serie", suena como comunicaciones de 1 cable sin embargo proporciona datos de baja velocidad y no indica cuál podría ser su requisito de velocidad.

Se agregó el requisito de velocidad anterior, que está controlado por el requisito de la tarjeta SD.

No le veo mucho sentido a un sistema maestro/esclavo con solo dos µC que ambos los programa uno mismo.

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

Siempre puede usar un protocolo personalizado similar a 1-Wire (pero mucho más rápido). Sin embargo, ese es un enfoque bastante tonto, ya que consumiría toda su potencia de procesamiento para mantener el protocolo.

TLDR: ajuste no particularmente económico pero confiable en algunos casos de uso.

Mirando fuera de la caja, podría haber otras soluciones aquí, como el siguiente chip con el que me topé últimamente. Por supuesto, todo depende de lo que quieras hacer. Algo como UART viene a la mente si tiene ambos MCU en la misma placa o incluso planea protegerlos manualmente contra ESD si se separan.

Solución maestra y de dispositivo para aplicaciones IO-Link

L6360   Master
L6362A  Device

ingrese la descripción de la imagen aquí

¿Cuándo consideraría una solución como esta:

  1. Los chips fronterizos vienen completamente protegidos, lo que sería importante si tiene cada MCU en una placa separada y se ocupa de pines expuestos, por ejemplo, terminal de tornillo.
    • Polaridad inversa
    • Sobrecarga con función de corte
    • Exceso de temperatura
    • Subtensión y sobretensión
    • Cable abierto GND y VCC
  2. Interoperabilidad. Si alguien más va a diseñar el otro lado, todo lo que necesita saber es canalizar los datos a través de IO-Link.
  3. Regulador integradoVcc(in) 7~30v, Vdd(out) 3.3/5v

Me pareció interesante, así que pensé en publicarlo.