4 ms·

There's something very satisfying about modern techniques walking into the old way of doing things for orders of magnitude gains.

pjc50 11y ago
Yes, although this isn't quite that; this is a simple matter of turning the serial link speed way, way up over the normal levels. It's probably dependent on having a nice short cable, and since RS232 is single-ended rather than differential there might be more EMI.
- ithkuil 11y ago
  it's not only that; this story is also about using a more robust checksumming so that you can know whether the transmission was actually successful. But if latency is what you care about the checksumming has to be done on the receiving end, and that's the device you're actually flashing. So, the trick is to upload a short program on the target device and let it take over the flashing process. This way you can go beyond what's provided by the default flashing protocol shipped on the device's ROM.
- rojer9 11y ago
  plus making it work w/o hw flow control and using better digests for integrity checks and (in case of F&C implementation) minimizing the amount of data to be written. it's all pretty common. the most difficult part was figuring out the "stub environment" and reverse-engineering existing rom to find the necessary parts of functionality. e.g. how to reboot into fw correctly after flashing.
- cushychicken 11y ago
  Mmm, sort of doubt this. EMI would only be causing serious problems with a return path - in this case the RX line, which wouldn't have much of an effect on the transmitted byte stream since relatively little is coming back over the UART_RX. Since this is all at 3.3V logic levels, I doubt there'd be much crosstalk anyway. If by "EMI" you mean some sort of signal quality issue due to transmission line effects, I'd say that's probably closer to the truth, but still not likely to be the case. At 1MBaud, your UART Tx will be switching in the range of 12-15MHz. As long as your physical UART connection is under six inches or so (and it probably would be if you were using a USB FTDI cable or something like that), it'd be pretty hard to get seriously bad transmission line effects at that frequency or most of the important harmonics in that square wave. This sounds a little more like an additive error from a baud clock mismatch. At some point, the FTDI is going to be generating a clock at some frequency that isn't compatible with the ESP's receive oversampler. I'm inclined to believe his explanation if he was able to show JTAG captures of the ESP's UART error register.
  - rojer9 11y ago
    at 1MBaud UART Tx will be switching at max of 512 KHz (if transmitting 0x55).
    - deleted 11y ago
      [deleted]
    - cushychicken 11y ago
      The fact only enhances my point. You have to either be running a really high speed signal or over a very long distance. I doubt either is happening in this case.
      - rojer9 11y ago
        yes, agreed.
cushychicken 11y ago
I wouldn't sound too satisfied on their behalf. The Cesanta guys really just implemented a well known flasher feature (on chip digesting) that speeds the process up a lot. Don't get me wrong - they deserve recognition for it. But their work here is a case of the open source community finishing an incomplete tool from the manufacturer rather than generating something really new.

pjc50 11y ago

Yes, although this isn't quite that; this is a simple matter of turning the serial link speed way, way up over the normal levels. It's probably dependent on having a nice short cable, and since RS232 is single-ended rather than differential there might be more EMI.

ithkuil 11y ago
it's not only that; this story is also about using a more robust checksumming so that you can know whether the transmission was actually successful. But if latency is what you care about the checksumming has to be done on the receiving end, and that's the device you're actually flashing. So, the trick is to upload a short program on the target device and let it take over the flashing process. This way you can go beyond what's provided by the default flashing protocol shipped on the device's ROM.
rojer9 11y ago
plus making it work w/o hw flow control and using better digests for integrity checks and (in case of F&C implementation) minimizing the amount of data to be written. it's all pretty common. the most difficult part was figuring out the "stub environment" and reverse-engineering existing rom to find the necessary parts of functionality. e.g. how to reboot into fw correctly after flashing.
cushychicken 11y ago
Mmm, sort of doubt this. EMI would only be causing serious problems with a return path - in this case the RX line, which wouldn't have much of an effect on the transmitted byte stream since relatively little is coming back over the UART_RX. Since this is all at 3.3V logic levels, I doubt there'd be much crosstalk anyway. If by "EMI" you mean some sort of signal quality issue due to transmission line effects, I'd say that's probably closer to the truth, but still not likely to be the case. At 1MBaud, your UART Tx will be switching in the range of 12-15MHz. As long as your physical UART connection is under six inches or so (and it probably would be if you were using a USB FTDI cable or something like that), it'd be pretty hard to get seriously bad transmission line effects at that frequency or most of the important harmonics in that square wave. This sounds a little more like an additive error from a baud clock mismatch. At some point, the FTDI is going to be generating a clock at some frequency that isn't compatible with the ESP's receive oversampler. I'm inclined to believe his explanation if he was able to show JTAG captures of the ESP's UART error register.
- rojer9 11y ago
  at 1MBaud UART Tx will be switching at max of 512 KHz (if transmitting 0x55).
  - deleted 11y ago
    [deleted]
  - cushychicken 11y ago
    The fact only enhances my point. You have to either be running a really high speed signal or over a very long distance. I doubt either is happening in this case.
    - rojer9 11y ago
      yes, agreed.

cushychicken 11y ago

I wouldn't sound too satisfied on their behalf. The Cesanta guys really just implemented a well known flasher feature (on chip digesting) that speeds the process up a lot. Don't get me wrong - they deserve recognition for it. But their work here is a case of the open source community finishing an incomplete tool from the manufacturer rather than generating something really new.