I am using STM32F4 (bare metal with HAL library) as an HTTP Server. I don't implement TCP layer, because that is done for me by the WiFi232 D2 module - all I receive in the uC through UART is a string with pure HTML request (and all I send is a string with pure HTML response). The requirement of the application is to send one large response with SPA web page (almost 300k characters) and several tiny responses as AJAX (~200 chars). With 57600bps all works fine, but the big response takes 50s to load on the client, so obviously I have to raise the baud rate.
That was the scenery introduction, now the main play, where the problem begins: with everything above 57600bps, I loose message characters on the way to the browser. I loose them randomly - it's usually a row of contiguous characters; sometimes several, sometimes above hundred of them. Initially I played with blocking UART transceiving. When I noticed the problem, I changed for DMA and it made absolutely no change. I tested both cases sending through UART to FTDA -> USB -> Termite terminal instead of the WiFi module, and saw the same symptoms. Since every single simulation lead to the aftermath of lost data, I went to the extent of even crossing STM Tx with Rx and checking if everything works okay on the shortest of possible circuits and... it of course worked perfectly :) So the uC is excluded from the suspects.
So is it even possible to achieve reliable UART transmission? Do you have any clue for how to send HTTP msgs by UART at high baud rates? I feel that I exhausted all the possibilities, but it seems unprobable that 115kbps is to much, not even mentioning Mbps... Maybe I'm missing something simple? Applying hardware flow control corrects the transmission only a tiny bit, I still get errors on 115kbps (although less frequently then without it).
*Note, that I keep talking about HTTP msgs, because of their particular nature - I can't implement any framing nor software flow control algorithm, because I don't have power on the browser side of this communication chain.
EDIT: Some more observations:
- With RST/CST flow control I can see a pattern in transmission (@230kbps): contiguous ~45056 OR ~28672 characters are sent correctly, then I loose a couple of characters, and then again - ~45056 OR ~28672, then loose couple of chars etc. Note, that the number of contiguous correct characters is always one of the two mentioned (+/- a couple).
- Without flow control I (as anticipated) get the following pattern: transmit EXACTLY 8191@115kbps or 4095@230kbps contiguous correct characters and then loose around 90@115kbps or 110@230kbps characters. What is strange though, is that I don't loose characters in any other spot...
In accordance to those observations, I prefer to use no hwfc and simply add some delay at the well-known spots (after every 8191st or 4095th char, depending on the baud rate). However this is very hackish, I hate this solution and I hope there still is some better way to solve that problem.
