- Sat Jan 10, 2015 6:38 am
#6886
pvvx wrote:Necromant wrote:Okay, folks. I'm somewhat back after a lengthy timeout. Merged all the pull requests, and have done a little bit of bugfixes, binaries updated.
- Buildsystem now only uses esptool.py (recent esptool.py with elf2image is a must).
- esptool.py is now a 'deployment' method consistent with the rest of antares.
- New command baud (modify serial port(s) speed on the go).
That's part of news. The other part is I've tried running esp8266 and a serial2tcp bridge. To make the long story short - it sucks. lwip is compiled in a weird way that assembles data in big packets, so you when you send a single character via telnet you have to wait for a second or so for it to appear. Working on lwip now.
ESP8266: Lwip + HTTP-WEB-server + TCP-UART.
UART 3Mbits/s:
I fixed that one already(sort off), it was magically gone as soon as recompiled espressif's lwip with stock lwipopts.h. Been working on web update, however a totally different problem popped in:
If you spend too much time in tcp_recv callback of lwip, something inside the blobs overflows (blind guess), and an exception pops in. It's okay if you process data fast, but erasing and writing to flash takes time. So updating over http will not likely work in a simplest way possible. I now implemented tftp for firmware update, since tftp is udp-based and server waits for acks on each packet. Needs a little testing and cleanup, will post an update today.
Same applies to tcp2uart bridge. If you're running at, say, 9600 and will just send a huge load of bytes over TCP you're likely to get an exception and a reboot. Or your only option is just drop some payload bytes if your buffer overflows.