ESP8266 Community Forum

- Sat Oct 24, 2020 11:40 pm #89203 For mass production you can preload the flash before putting it on the board, if that's the only thing you're worried about. There are many companies that will sell modules in bulk with the flash already loaded with whatever image you give them - this is what they do with NodeMCU units.

If you're doing smaller batches then the other thing to consider of course is that with UART flashing, you can flash maybe 12-16 units at a time max (I do 8 at a time), whereas OTA you'll be able to do over a hundred at a time if you have the power supplies for them.

But if I were mass producing then I would just get the flash pre-loaded - very simple

- Sun Oct 25, 2020 4:45 am #89204

In fact wee are just considering about how to speed up the image flashing for mass production. The traditional flash-burning via UART is too time-consuming, so we are trying to burn flash via an OTA. It saves time obviously, but is still time-consuming, and we are trying to save more. This is the first, as well as the primary reason, why we are considering about the OTA time consumption.

In what way it UART flashing too time consuming? Because it by far is the fastest way to flash a chip, almost no overhead. Maybe you are using a too slow baud rate? The flash can be done at 1 Mbps with reasonable cabling, I bet you could get to 2 Mbps with real proper cabling, but the question is whether the flash operation speed wil still benefit from that speed change. In other words, at any baudrate above 1 Mbps, the delay is caused by the writing of the flash (which is inherently a slow process) and invariable.

BTW I am always a bit worried when people write they're using the ESP8266 for commercial purposes. The hardware of the ESP8266 will probably be quite ok, also can't judge that, but the software in the SDK, the code, is really not high quality. Therefore I tend to use SDK code as little as possible and replace it by my own code (unfortunately I can't ditch it all).

- Sun Oct 25, 2020 4:56 am #89205

Is there any reason you want to speed it up? Is it just a worry about power consumption?
Also @eriksl - would love to see more on your benchmarks - very interested to know more on top sustained transfer speeds and how they can be achieved

How do you mean exactly?

I referred to my OTA mechanism, in dummy read or dummy write operation mode. It does take checksums (RC and SHA) here and there, it compares sectors to see if a sector really needs to be written and does a verify read, so it might not be the fastest possible. So, if you're simply sending or receiving data and discard it, you may get a higher througput, but I guess that would be kind of useless information.

I am quite satisfied (even if I say it myself ) with my OTA mechanism. Even though I get bogus data passed from the SDK code (wlan driver) every now and then (possibly AMPDU concatenated frames or simply a bug), it won't bend and always yields a completely correctly written image. The drawback is that it needs a host-side utility, that feeds the sectors in an interactive way, no http here! I've been thinkiing about that, but it's complex. One of the issues is that you can't do a per-sector checksum, or you might have to resolve to something like javascript and implement the protocol I am using now, there.

- Sun Oct 25, 2020 8:27 am #89208

Is there any reason you want to speed it up? Is it just a worry about power consumption?
Also @eriksl - would love to see more on your benchmarks - very interested to know more on top sustained transfer speeds and how they can be achieved

How do you mean exactly?

/quote]
I mean your wifi rate in general - I have a side project that will need to stream data and I want to know how fast I can get it in steady state