ESP8266 Community Forum

- Sat Jan 10, 2015 11:52 am #6907 I wonder one thing. Can we use your tftp update method with other SDK like freertos?

ESP8266.com Moderator
Lets get the party started and +1

[url=https://www.banggood.com/custlink/KvGGhGF4wG[/url]

I like ESP8266 and ESP8285 and ESP32

- Sat Jan 10, 2015 1:51 pm #6923

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.

https://www.youtube.com/watch?v=chDagawOva8
UART tx - Manual update the TCP window (Lwip).
This can be used to throttle data reception (e.g. when received data is programmed to flash and data is received faster than programmed).
UART rx - RTC/CTS.
Do not need to invent new protocols. Do not need to reinvent the wheel... TCP/IP has all the necessary tools.

- Sat Jan 10, 2015 3:26 pm #6931

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.

https://www.youtube.com/watch?v=chDagawOva8
UART tx - Manual update the TCP window (Lwip).
This can be used to throttle data reception (e.g. when received data is programmed to flash and data is received faster than programmed).
UART rx - RTC/CTS.
Do not need to invent new protocols. Do not need to reinvent the wheel... TCP/IP has all the necessary tools.

I'm not inventing any new protocols, if you haven't noticed. Just prefer to do things in a clean way.

In lwip, as far as I understood, the only way to actually throttle incoming data - write to a buffer, and don't call tcp_recved() when it's full, so that the callback will fire again and update TCP window respectively. In the unbuffered scenario you'll do all the work in the callback and if the callback takes too long to complete - you'll get an exception from somewhere out of the blobs.
That's why I want to implement proper IO buffering. When that's done - proper double-ways uart2tcp bridge is a minor side-effect.

Giving your link a quick look again (code this time) - looks only tx is unbuffered, while rx (from the net) is buffered. And they're still using espconn apis, which I ditched in most places, save for 'listen' and 'send'. I'll fix it soon and ditch espconn forever from frankenstein.

Blog|github

- Sat Jan 10, 2015 3:47 pm #6934

I wonder one thing. Can we use your tftp update method with other SDK like freertos?

Yep, when you're running frankenstein you can flash _any_ firmware file, if it starts at 0x0000. In fact, it will even flash whatever random garbage you supply it. Ofcourse it won't boot if it's garbage instead of firmware
If something you've flashed can't do tftp or doesn't boot at all... Well, you have to resort to UART and esptool.py to reflash.

Yeah, and if your firmware is more than SPI_FLASH_SIZE/2 (e.g. 256KiB for 512KiB flash) - this is a no-go as well. We need to buffer full firmware somewhere before actually writing it. Concatenating that with a RAM buffer might be helpful, though utter hackery.

Blog|github