ULX3S micro python remote programming speeds

It was pointed out to me that ecppack has a compress option and it has quite the impact on programming speeds, so I thought I’d do a simple test and try a few different compression combinations and see what impact they have (you never quite know with these things till you try)

File nameSize (bytes)Time 1Time 2Time 3Time 4Time 5Ave Time(ms)
blink.bit1032325205919441928216023932097
blink.bit.gz6112496750105074471047644905
blinkc.bit162070394343315306332338
blinkc.bit.gz2856198218241838187018951882

blinkc.* has been compressed by ecppack –compress, all the tests were carried out from a laptop running lighttpd, the network connection is 5Ghz WIFI to the router from the laptop, with the esp32 connected via 2Ghz WIFI. The following command was used from the webrepl console to program the bitstream into SRAM (not flash).

ecp5.prog("http://192.168.0.40/blink.bit")

While ecppack’s compress option isn’t amazing (in this case just over 15% of the original size) it has a marked impact on programming speed taking only 16% of the time it takes to program a vanilla bit stream. Simply gzipping the file gives the worst speed, presumably its the esp32 that’s decompressing gz files… Using both compression methods has the best effect on file size and the price paid in speed doesn’t rule it out…

As I’m storing my bitstreams on my laptop and programming from there, I don’t really care about file size, but its well worth using ecppack’s compression as the speed of programming really stella ! (…and no thats not a load of typo’s, 300ms not 3000ms !)

This is my main use case, but at a later date I may do the same tests on the esp32 internal flash vs from the onboard SD card….

Leave a Reply

Your email address will not be published. Required fields are marked *