Open leodesigner opened 6 years ago
It probably to be better to wait some time when new data is still arriving from the UART to be able to send them all at once via TCP. Like to wait 1ms and see if some new bytes till it it will be enougth for one packet at least. What do you think guys ?
The RX interrupt already waits for a few idle character times before firing. So the delay is handled at the HW level. Also, due to the limited buffering in the Espressif TCP stack, you might send the first packet with just a few chars but thereafter packets are essentially clocked by the returning TCP ACKs.
The idea was to have a bigger tcp packets if it's possible. I see a lot of small packets during serial transmission. Making them bigger we can avoid some packet overhead. From the other side for some use cases 1ms delay may be not desirable. Need to test it probably.
You can easily play with the interrupt setting... I tried to document it: https://github.com/jeelabs/esp-link/blob/master/serial/uart.c#L72-L87
Ahh, thanks, I had no idea about ESP8266 UART is so flexible :)
Here is the final solution to remove "espbuffsend: cannot alloc tx buffer" error.
https://github.com/leodesigner/esp-link/commit/afa649d10f3a01d3708b53204c2b3aa97c1af4fc (ring-for-all branch - will merge to my master later.) Edit: merged with few new features.
There is a static shared buffer (console) in serbridge.c. It is used for all connections. So no more memory allocation errors at all. I am commented about all the logic behind the new algorithm in the code. Now it is perfectly stable and I hope it will be merged to the master branch of esp-link as well as the other improvements in my fork. Any questions are welcome. @tve please take a look to this. Thanks.
Here is the final solution to remove "espbuffsend: cannot alloc tx buffer" error.
leodesigner@afa649d (ring-for-all branch - will merge to my master later.) Edit: merged with few new features.
There is a static shared buffer (console) in serbridge.c. It is used for all connections. So no more memory allocation errors at all. I am commented about all the logic behind the new algorithm in the code. Now it is perfectly stable and I hope it will be merged to the master branch of esp-link as well as the other improvements in my fork. Any questions are welcome. @tve please take a look to this. Thanks.
Dont build https://github.com/leodesigner/esp-link
SDK is VERSION is v3.2.76-g59c3941-dirty CC socket/socket.c socket/socket.c: In function 'socketclient_sent_cb': socket/socket.c:104:3: error: implicit declaration of function 'vPortFree' [-Werror=implicit-function-declaration] if (client->data) os_free(client->data); ^ socket/socket.c: In function 'SOCKET_Setup': socket/socket.c:283:2: error: implicit declaration of function 'pvPortZalloc' [-Werror=implicit-function-declaration] socket_host = (uint8_t*)os_zalloc(len + 1); ^ cc1: all warnings being treated as errors Makefile:511: recipe for target 'build/socket/socket.o' failed make: *** [build/socket/socket.o] Error 1
I didn't test the build with the latest SDK.
Hi, Had a couple hours to get deeper to the serial sending reliability issues. Seems like conn->txbuffer was reallocated each time when some bytes arrives from UART. ESP8266 is not very happy from this :) Here is the patch to allocate TX buffer only once at the connection time, not at every byte as it was. https://github.com/leodesigner/esp-link/commit/3e68fa11ea740dc30bada0e7b436e3b44cdb2950 It would be nice to test it and merge to the original project. My local ESP-Link-STM32 setup is working much better now. Thanks.