search

jeelabs / el-client

Arduino client for esp-link's REST, MQTT, and command interface
BSD 2-Clause "Simplified" License
85 stars 47 forks source link

el-client port stops working (POST demo) #24

Closed rnunes closed 7 years ago

rnunes commented 8 years ago

I'm porting el-client to STM32 and to test it I'm making one POST per second with 512 bytes of the exact same character, incremented every POST ('0' to '9').

First I reset ESP and MCU and in that case I can do 10-30 POST until it fails. After that if I reset MCU I can only do 1, sometimes 2 or 3 POSTs. In order to continue I have to reset ESP and MCU.

I'm trying to understand if it's a porting related problem or if some of you have it as well. I'm using esp-link v2.2.3 and my Debug log is below. The endpoint is /ecg_mm_fixe and everything is ok until the last line (88POST /ecg_mm_fixe000) and from there on it never recovers, unless I reset the MCU. Is this related to SLIP synchronization?

UART baudrate is 9600 (started at 115200 but lowered down to see if it solved) and my response timeout is 5 seconds.

SYNC!
ELC: got 14 @200042F4: 3 200042D0 1 1 0 5 0 8D AC
RESP_CB: 536888016 1
WIFI CONNECTED
ELC: got 10 @200042F4: 2 0 0 6F B
RESP_V: 0
(...)
ELC: got 14 @200042F4: 3 2000437C 1 2 0 C8 0 37 2A
RESP_CB: 536888188 1
REST code 200
ELC: got 14 @200042F4: 3 2000437C 1 2 0 C8 0 37 2A
RESP_CB: 536888188 1
REST code 200
ELC: got 14 @200042F4: 3 2000437C 1 2 0 C8 0 37 2A
RESP_CB: 536888188 1
REST code 200
88POST/ecg_mm_fixe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000�g99POST/ecg_mm_fixe1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111C00POST/ecg_mm_fixe2222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222r�11POST/ecg_mm_fixe3333333333...
tve commented 7 years ago

Is this still an issue with the newer versions? And did you turn off the UART debug output? It seems to steal too much time and cause issues, sigh.

rnunes commented 7 years ago

Forgot to update this but it was an error in my UART driver implementation. I was using an asynchronous UART driver that doesn't wait to flush TX before waiting for RX and that brought a lot of problems. Polling for TX empty buffer before waiting for RX solved the problem.

tve commented 7 years ago

thanks for the update!