¿Por qué usar UART para comunicarse entre Arduino y el módulo Wi-Fi ESP?

He estado aprendiendo sobre los diferentes protocolos de comunicación utilizados entre Arduino y otros componentes/sensores, a saber, SPI, UART e I2C. Quiero agregar Wi-Fi a mi proyecto Arduino UNO usando ESP8266 (por ahora, y tal vez luego actualice a un ESP32 ya que es más poderoso).

Pero me pregunto por qué en todos los esquemas que he visto en mi investigación en línea, Arduino siempre está conectado al módulo ESP8266 a través de UART. ¿Por qué no usar SPI o I2C? ¿Por qué UART (aparentemente) se considera superior para la comunicación ESP con Arduino sobre los otros dos protocolos de comunicación?

Gracias de antemano por la ayuda.

Los módulos ESP8266 comunes solo tienen interfaz serial.
¿Qué quieres decir con 'común'? Creo que todos los módulos ESP8266 comparten las mismas funcionalidades básicas, a menos que me equivoque. En realidad, acabo de encontrar una guía en la que se usó la comunicación I2C entre Arduino y ESP8266, ¡así que esto hace que todo sea aún más confuso! medium.com/@krukmat/arduino-esp8266-through-i2c-49b78e697b7a
El ESP-01 utilizado en ese enlace solo tiene pines UART de acuerdo con la documentación que pude encontrar. No entiendo lo que se describe allí. Supongo que un poco golpeando los pines GPIO desde el lado ESP. Por lo tanto, el bit-banging es una solución intrínsecamente peor que usar un periférico de hardware dedicado.
Bueno, una cosa es que entre los tres, UART es el único donde la interfaz es dúplex completo Y los datos que van en una dirección pueden comenzar y detenerse independientemente de los datos en la otra línea, lo cual es útil si el ESP quiere enviar datos al MCU por su propia voluntad. El principal beneficio de I2C es el direccionamiento y el multimaestro, ninguno de los cuales es necesario aquí.
FWIW, github.com/esp8266/Arduino/pull/5226 ESP8266 can never be a compliant I2C slave; there is no hardware support, and a bit-by-bit software solution isn't going to be fast enough for the standard I2C speed of 100kHz because 1) the interrupt won't arrive fast thought and 2) the GPIO bus clock is slower than 100kHz. That's why this solution can handle 14kHz max, which is useless since most other devices run at 100kHz. Try ESP32, it has I2C hardware.

Respuestas (1)

UART ofrece comunicación bidireccional con solo 2 cables.

I2C es una comunicación unidireccional para 2 hilos. Se puede hacer de dos maneras implementando un mecanismo de notificación personalizado en el que el esclavo envía una señal cada vez que tiene datos para enviar mediante una conexión GPIO. Esto requiere otro pin y, por lo tanto, 3 cables para la comunicación bidireccional en comparación con los dos en UART. Otra alternativa es el sondeo, como se indica en los comentarios a continuación. Personalmente, prefiero el flujo impulsado por interrupciones sobre el sondeo. Sin embargo, si está de acuerdo con el sondeo, 2 cables pueden hacer el trabajo.

SPI requiere un mínimo de 4 cables. (Tal vez 3 cables en caso de un solo esclavo como comentó Elliot)

Dada la cantidad limitada de pines disponibles en los módulos esp, supongo que la comunidad podría haber elegido usar UART como mecanismo principal de transferencia de datos. Además, UART es más simple de implementar que otras contrapartes. (Esta línea podría estar basada en una opinión, así que discúlpeme si tiende a estar en desacuerdo)

Es posible usar módulos esp como una MCU independiente para proyectos generales. Puede usar expansores de puertos en caso de que se necesiten más GPIO. Usé una arquitectura similar en uno de mis proyectos. Usé esp-arduino para desarrollar el firmware dentro del propio IDE de arduino.

I2C tiene solo dos cables (SCL y SDA) pero UART es mucho más simple de implementar como usted indicó
Para un solo esclavo, es posible que pueda hacer SPI con tres cables.
@select: he editado mi respuesta para explicar el requisito de 3 cables. Por favor echa un vistazo.
@Elliot: actualicé mi respuesta. Gracias por mencionarlo.
Incluso si I2C convencional requiriera sondeo, vale la pena tener en cuenta que muchos firmwares simples solo pueden actuar sobre los datos entrantes en un punto particular de su ejecución de bucle de todos modos. Dado que el ESP8266 tiene un poco más de RAM que un ATmega, en realidad hay un argumento válido para que el ESP almacene en búfer los datos hasta que el ATmega esté listo para solicitarlos. Por supuesto, esa misma diferencia en los recursos puede apuntar a la ejecución de toda la aplicación en el ESP.
Además, debería poder simplemente leer un registro I2C para determinar si hay datos como parte del ciclo de sondeo. Esto eliminaría la necesidad de una tercera línea solo para indicar que los datos están listos.
¿Por qué usar UART para comunicarse entre Arduino y el módulo Wi-Fi ESP?
RespuestasAquíPolítica de privacidad1y, 0v