ESP8266 Community Forum

kolban wrote: If that's the case then we are fixed at 115200.

You're right that the bootloader is in ROM.

However it does dynamic baud rate detection. The initial comms transmitted to the bootloader are a 'sync' with a payload of 0x55s to train the esp UART to the sender's baud rate. I believe this auto baud rate feature is also available in the SDK.

I have it working up to 1 Mbaud, but sometimes it fails to detect the proper baudrate and I need to try again. Testing my firmware, which is quite large now, is no fun at anything less.

I've had it running at up to 921600 baud but I did get the occasional error and it would fail to bootload. At that baud rate it takes no time at all! My FTDI converter could handle this rate.

However, even faster than this is to use the OtA flashing which I've found only takes a second or so to reflash, of course you do need to build this in to your firmware and have a way of being able to choose which section you want to be flashing. Bit more complex, but it does speed it up!

kenn wrote:As far as I know you can't simply compile and upload small parts because you're uploading full, packed bin file(s) every time,

I've been able to successfully update individual parts of Flash. For example, I was able to re-flash a SPIFFS block with different data and the existing app correctly used the updated information.

As for faster flashing, instead of using a monolithic image file with 0xff padding in the empty space I now use a sparse combined image file. That way, none of the inter-image padding needs to be sent to the device thus reducing the time required. I wrote a new tool that combines aspects of esptool-ck and esptool.py and also supports the sparse combined images. The C++ source code, standard Linux makefile, MSVC makefile, and pre-built Windows command line app are available on github: esp_tool