Estoy usando STM32F4 (sin información con la biblioteca HAL) como un servidor HTTP. No implemento la capa TCP, porque eso lo hago para mí con el módulo WiFi232 D2; todo lo que recibo en la unidad de usuario a través de UART es una cadena con solicitud de HTML puro (y todo lo que envío es una cadena con respuesta de HTML puro). El requisito de la aplicación es enviar una respuesta grande con la página web de SPA (casi 300k caracteres) y varias respuestas pequeñas como AJAX (~ 200 caracteres). Con 57600bps, todo funciona bien, pero la gran respuesta tarda 50 en cargarse en el cliente, así que obviamente tengo que aumentar la velocidad de transmisión.
Esa fue la introducción del escenario, ahora el juego principal, donde comienza el problema: con todo por encima de 57600bps, pierdo los caracteres de los mensajes en el camino hacia el navegador. Los suelto al azar, generalmente es una fila de caracteres contiguos; A veces varias, a veces más de cien. Inicialmente jugué con bloqueo de transcepción de UART. Cuando noté el problema, cambié por DMA y no hizo ningún cambio. Probé ambos casos enviando a través de UART a FTDA - > USB - > Terminal de termitas en lugar del módulo WiFi, y vio los mismos síntomas. Dado que cada simulación condujo a la pérdida de datos, llegué al punto de cruzar incluso STM Tx con Rx y comprobar si todo funciona bien en el circuito más corto posible y ... por supuesto, funcionó perfectamente :) queda excluido de los sospechosos.
Entonces, ¿es incluso posible lograr una transmisión UART confiable? ¿Tiene alguna pista sobre cómo enviar mensajes HTTP por UART a altas velocidades en baudios? Siento que he agotado todas las posibilidades, pero parece improbable que 115 kbps sea demasiado, ni siquiera mencionar Mbps ... ¿Tal vez me esté perdiendo algo simple? La aplicación del control de flujo de hardware corrige la transmisión solo un poquito, aún obtengo errores a 115 kbps (aunque con menos frecuencia que sin él).
* Tenga en cuenta que sigo hablando de mensajes HTTP, debido a su naturaleza particular: no puedo implementar ningún algoritmo de control de flujo de software ni de marcos, porque no tengo poder en el lado del navegador de esta comunicación. cadena.
EDITAR: Algunas observaciones más:
- Con el control de flujo RST / CST puedo ver un patrón en la transmisión (@ 230 kbps): contiguos ~ 45056 O ~ 28672 caracteres se envían correctamente, luego pierdo un par de caracteres y luego otra vez - ~ 45056 O ~ 28672, luego suelte un par de caracteres, etc. Tenga en cuenta que el número de caracteres correctos contiguos es siempre uno de los dos mencionados (+/- un par).
- Sin el control de flujo, obtengo el siguiente patrón (según lo previsto): transmita EXACTAMENTE 8191 @ 115kbps o 4095 @ 230kbps caracteres correctos contiguos y luego suelte alrededor de 90 @ 115kbps o 110 @ 230kbps caracteres. Lo extraño, sin embargo, es que no pierdo caracteres en ningún otro lugar ...
De acuerdo con esas observaciones, prefiero no usar hwfc y simplemente agregar un poco de retraso en los puntos conocidos (después de cada 8191st o 4095th char, dependiendo de la velocidad en baudios). Sin embargo, esto es muy hackish , odio esta solución y espero que todavía haya una mejor manera de resolver ese problema.