Buenas nuevas! Me he puesto con este tema y he progresado
En concreto he podido implementar el control de flujo por hardware en la prueba de test19_multi_uart de mcleod. (La cual he portado hacia el test23_uart_control_flujo)
También he podido activar en mi chip ESP8266 el control de flujo en los comandos AT usando el siguiente comando (gracias a Óscar Hernández, @Gatuso464 en Twitter):
AT+UART_DEF=115200,8,1,0,2
El último parámetro (2) indica que se quiere usar CTS en el ESP. 0 es para no control de flujo, 1 es para activar sólo el RTS, 2 para el CTS, y 3 para ambos.
Por lo que he investigado, el CTS siempre es de entrada y el RTS siempre es de salida, cuando se conectan dos ordenadores (cuando se conecta un ordenador y un modem es diferente, pero no es este caso). Y el RTS es por nivel bajo, es decir si un dispositivo pone RTS a 0 está diciendo que no le envíen más bytes de momento.
En las pruebas sólo he usado RTS del ZX-Uno y CTS del ESP8266. Pero se puede hacer control de flujo en ambas direcciones (está implementado en el ZX-Uno), sólo hay que añadir el cable necesario, y usar como último parámetro el 3 en el comando UART_DEF.
Por cierto si se está haciendo las primeras pruebas es útil usar el comando UART_CUR, que cambia la configuración del puerto serie pero no la graba en la flash, revirtiéndose tras un reset. El comando UART_DEF sí graba en flash la configuración.
Hago notar que tuve que actualizar el firmware de mi ESP8266 porque lo compré hace mucho y aún no tenía entre sus comandos AT el comando UART_DEF.
En el ZX-Uno he añadido las dos líneas uart_cts y uart_rts, y la lógica necesaria para el control de flujo. He añadido un nuevo estado de espera en el módulo de recepción, que espera a que el módulo superior zxunouart le indique que la cpu ya ha leído el byte de dato recibido para continuar la recepción.
Os pongo un esquema de las conexiones, porque el chip ESP necesita algunas líneas a masa y otras a 3V3.
El pulsador con su resistencia de pull-up sólo es necesario para actualizar el firmware del ESP (se pulsa durante el reset para que entre en modo programación) Pero obviamente el ESP se conecta al PC para la grabación, no al ZX-Uno. Si no os hace falta, sustituid la resistencia de GPIO_0 por un cable.
El resto de las resistencias son opcionales, se pueden sustituir también por cables, por lo que he leído. Esto os irá bien si queréis usar la placa addon hdmi+esp8266 que ya se hizo (yo he usado protoboards y cables)
El resultado de todo esto es que consigo recibir bytes a 115200 baudios sin perder ni uno.
El primer soft que he hecho (aparte de las primeras pruebas claro) es un programa de terminal "tonto" en el ZX-Uno, para poder enviar comandos al ESP.
Posteriormente quiero hacer un cliente de ftp que sea capaz de descargar ficheros y grabarlos en la SD, usando la rutina asm para grabar en SD que publicó Haplo
Momento histórico de la primera recepción por WiFi de una petición GET desde el ZX-Uno:
Montaje de las pruebas:
Os pongo los fuentes y el TAP del terminal en ficheros adjuntos.
Los fuentes .v son del test23 pero puede que ya estén obsoletos. Me explico:
Podéis coger zxuno.v y zxunouart.v tal cual, son los que tienen más modificaciones. De los otros tres ficheros, está el de los pines (que podéis poner los pines que os vengan bien), y los otros dos sólo tienen añadida la definición del módulo zxunouart y los dos pines nuevos cts_uart y rts_uart. Como estos dos ficheros estarán más nuevos en el repositorio, no los copiéis ciegamente, sólo pasad los cambios.
Edito: he actualizado uart_control_flujo.zip, que había subido una versión anterior con un bug.