Andaba dando vueltas al problema de por qué uno de los micros ESP32 no podía conectarse a la wifi, así que se me ocurrió quitar el firmware de MicroPython por si fuese ese el problema y meter alguno del fabricante. Para ello fui a la página de Espressif y busqué un firmware y di con uno que me llamó mucho la atención, ya que está preparado para trabajar con comandos AT. Lo saqué de esta página de descargas del fabricante. Para quien no haya oído hablar de los comandos AT o comandos Hayes (por su inventor Dennis Hayes) son instrucciones codificadas que sirven para comunicar un ordenador con un módem. No se parecen mucho un módem y un micro, por eso me llamó la atención su originalidad. Leyendo vi que con estos comandos AT se puede conectar este micro a la wifi, que ya sería casi la prueba definitiva ya que había probado con Arduino y ocurría el mismo problema.
Ahora viene la chapa abuelto cebolleta. Me pegué con los comandos AT a principios de los noventa porque teníamos un proyecto con una empresa situada en Belfast y nos mandaba el software por módem, utilizando el protocolo kermit (sí, la rana Gustavo). También me tocó pegarme un poco después, en la época prehistórica de Internet cuando utilizaba Infovía para conectarme a internet, en aquellos tiempos que si navegabas por internet no te podían llamar por teléfono. Años más tarde desarrollé en mi empresa un programa de envío de alarmas por SMS utilizando un módem GSM. Y cuando ya casi me había olvidado del señor Hayes hete aquí que aparece el micro ESP32 y su curioso firmware preparado para trabajar con estos comandos. No podía dejar de probar este invento después de tan largo bagaje hayesiano.
Bajé el firmware, la versión 2.4.0.0 para la serie ESP32-WROOM-32 y las instrucciones son claras para poder flashear los binarios, ya que con la herramienta esptool.py es muy sencillo. También hay una herramienta para hacerlo desde Windows y las instrucciones también parecen evidentes. Ya sólo quedaba probar con comandos AT con los que también se puede conectar a la wifi, aunque primero hay que conectarse al micro y ver si responde a los comandos AT más sencillos. Junto a los binarios también se incluye un PDF llamado Guía de Usuario donde te vienen todos los comandos AT que admite el micro.
El micro ESP32 tiene tres UARTs o puertos series, para entendernos. Uno lo utiliza para conectarlo al PC por USB y poder enviarle el código, bien en Python, bien el código C compilado. Otro puerto serie lo utiliza el micro para conectase con la memoria flash, por lo que esa UART no se puede tocar y luego tiene una tercera UART que es la que nos va a servir para enviar esos comandos AT. Dice la guía de usuario que la serie ESP32-WROOM-32 tiene dos UARTs y la UART0 (con la que se conecta al ordenador para descargarse el código) utiliza el GPIO3 como recepción (RX) y el GPIO1 como transmisión (TX). Y que la UART1 utiliza el GPIO16 como RX, GPIO17 como TX, GPIO15 como CTS y GPIO14 como RTS. Aquí viene lo primero que no tuve claro. Por un lado las especificaciones hablan de tres UARTs, las que he explicado, y en la guía de usuario hablan de dos UARTs olvidándose de la UART que conecta con la memoria. Por lo que había leído la nomenclatura era clara: UART0 para descarga del código, UART1 para acceso a la memoria y UART2 la restante y que además en la placa se puede ver que el GPIO16 viene etiquetado como RX2 y el GPIO17 como TX2, obviamente, haciendo referencia a esa UART2 y no a la UART1 como dice la guía de usuario. El caso es que como lo que yo llamo UART1 es inaccesible supuse que lo que ellos llaman UART1 es lo que yo llamo UART2 (menudo trabalenguas) y que por tanto debo utilizar los pines RX2 y TX2 de la placa. Me olvido del GPIO15 (CTS) y GPIO14 (RTS) porque esos sirven para hacer un control hardware de lo que se envía y se recibe, pero que no se van a utilizar.
Lo primero que hice fue comprar una plaquita que sirviera para pasar del USB del ordenador a puerto serie y compré en Amazon dos plaquitas por 11 €, las que se pueden ver en la imagen. Esas plaquitas me gustaron porque tienen un jumper en el que puedes elegir que el voltaje de salida sea de 5 V o de 3,3 V que son los necesarios para el micro ESP32. Tienen la pega de que el conector de la plaquita es mini USB, que es ya algo antiguo, pero todavía me quedan algunos de hace años y me pareció una buena manera de aprovecharlos.
En cuanto llegaron las dos plaquitas me llevé la sorpresa de que los seis pines aunque estaban etiquetados, no se veía bien la serigrafía, así que anduve buscando por internet y vi uno que me sacó de dudas.
Lo conecté al Mac y lo reconoció sin problemas, creando en el directorio /dev los ficheros tty.usbserial-A95TOHMV y cu.usbserial-A95TOHMV. Así que todo feliz conecté el pin RX de la plaquita con el GPIO17 (TX2) y el pin TX de la plaquita con el GPIO16 (RX2) tal como puede verse en la imagen.
Arranqué el emulador de terminal minicom con la velocidad de 115200 como dice el fabricante…
$ minicom -b 115200 -D /dev/cu.usbserial-A95TOHMVY una vez dentro ejecuté el comando más simple y que me debería responder OK
ATY no vi nada, ni lo que escribía y ni siquieran parpadeaban los leds de la plaquita de RX y TX. Tampoco se veía ningún mensaje al resetear el micro. Algo estaba haciendo mal.
Lo primero que se me ocurrió fue poner un cable del GND de la plaquita del conversor USB al GND de la plaquita del micro, pero no solucionó nada.
Lo siguiente fue utilizar otro emulador de terminal, en concreto picocom:
$ picocom -b 115200 --flow n /dev/cu.usbserial-A95TOHMVY aunque seguía sin funcionar, la cosa empezó a gustarme porque veía lo que escribía y los leds de recepción y transmisión se encendían. Además al hacer reset con el botón de la plaquita podía ver un ready en la pantalla. ¡Ya estaba más cerca!
Buscando por internet por qué el ESP32 no respondía a los comandos AT vi una información que se me había pasado por alto y que en la guía de usuario no lo daba demasiada importancia y decía así: Enter the command «AT+GMR» with a new line (CR LF). Y esa era la clave, el micro necesita que le llegue el comando acabado en CR y LF y el programa sólo manda CR cuando se pulsa la tecla Enter. Como al micro no le llega el LF no contesta nunca al comando AT. Por lo tanto, sólo hay que buscar la manera de enviar CR y LF al dar la tecla Enter y con picocom es muy sencillo, sólo hay que ejecutarlo con el switch –omap y el valor crcrlf:
$ picocom -b 115200 --flow n --omap crcrlf /dev/cu.usbserial-A95TOHMVY así, por fin, pude enviar comandos AT al micro y que éste me respondiera. Envié también el comando AT+GMR que me indicó la versión del firmware:
Ya sólo quedaba ejecutar el comando que me había traído a todo esto, el comando AT para conectarse a la wifi.
AT+CWJAP="mi SSID","mi password"Si funcionase, debía ver una respuesta del tipo:
WIFI CONNECTED
WIFI GOT IP
OKPero no, sólo vi un mensaje de error:
+CWJAP:2
ERRORAsí que voy a dejar de dar más vueltas y que se me meta en la cabeza de una vez, que la wifi no funciona en esta plaquita haga lo que haga, ya que también lo probé con Arduino para ejecutar el script que conecta a la wifi… Y no funcionó. Probé con otro micro ESP32 haciendo la misma operación ¡y funcionó! Así que cada vez es más claro que la wifi no funciona en ese micro en concreto por algún motivo hardware.
Por si estaba haciendo algo mal, probé con la otra plaquita y los mismos comandos y se conectó sin problemas y además pude ver la IP que le da el DHCP:
AT+CIPSTA?
+CIPSTA:ip:"192.168.1.34"
+CIPSTA:gateway:"192.168.1.1"
+CIPSTA:netmask:"255.255.255.0"
OKY, por supuesto, respondía al ping, aunque con unos tiempos de respuesta un poco malos.:
$ ping -c 10 192.168.1.34
PING 192.168.1.34 (192.168.1.34): 56 data bytes
64 bytes from 192.168.1.34: icmp_seq=0 ttl=255 time=169.977 ms
64 bytes from 192.168.1.34: icmp_seq=1 ttl=255 time=99.051 ms
64 bytes from 192.168.1.34: icmp_seq=2 ttl=255 time=30.814 ms
64 bytes from 192.168.1.34: icmp_seq=3 ttl=255 time=229.639 ms
64 bytes from 192.168.1.34: icmp_seq=4 ttl=255 time=148.929 ms
64 bytes from 192.168.1.34: icmp_seq=5 ttl=255 time=94.109 ms
Request timeout for icmp_seq 6
64 bytes from 192.168.1.34: icmp_seq=7 ttl=255 time=381.832 ms
64 bytes from 192.168.1.34: icmp_seq=8 ttl=255 time=138.935 ms
64 bytes from 192.168.1.34: icmp_seq=9 ttl=255 time=64.781 ms
--- 192.168.1.34 ping statistics ---
10 packets transmitted, 9 packets received, 10.0% packet loss
round-trip min/avg/max/stddev = 30.814/150.896/381.832/98.765 msCuando se utilizan los comandos AT para conectarse a la Wifi, el micro lo almacena en la flash, de tal modo que si se reinicia el chisme, se vuelve a conectar a la wifi. Bueno, lo almacena en la flash si está habilitado el modo de almacenamiento: AT+SYSTORE=1 que creo que por defecto está activado.
Siempre lo he pensado cuando algo no funciona y tratas de adivinar qué está pasando es cuando más se aprende.