- Fri Dec 12, 2014 7:19 pm
#4715
I am not sure if this is a bug or an undocumented feature.
uart.on responds with a > prompt after each line sent to the uart, even with echo off.
I am not sure if this means that it is necessary to wait for the prompt before sending more data (perhaps the writing to flash is that slow), or if I can continue to send at high speed and disregard the > and newline characters coming back at least up until some buffer length. An Xon Xoff protocol would be good, but perhaps that is what this > is about.
Please clarify.
Otherwise, transfers seems to be totally reliable at 921600 baud, which is encouraging.
It would also be useful to know the buffer size.
Sending more than the unknown buffer length causes lost data and makes me wonder if the lost data might be corrupting the code or other data, as buffer overruns tend to do in C.
This is why we like to see the source...
uart.on responds with a > prompt after each line sent to the uart, even with echo off.
I am not sure if this means that it is necessary to wait for the prompt before sending more data (perhaps the writing to flash is that slow), or if I can continue to send at high speed and disregard the > and newline characters coming back at least up until some buffer length. An Xon Xoff protocol would be good, but perhaps that is what this > is about.
Please clarify.
Otherwise, transfers seems to be totally reliable at 921600 baud, which is encouraging.
It would also be useful to know the buffer size.
Sending more than the unknown buffer length causes lost data and makes me wonder if the lost data might be corrupting the code or other data, as buffer overruns tend to do in C.
This is why we like to see the source...
ESP8266 for dummies, LuaLoader and project updates: http://benlo.com/esp8266
