feat: improve flashing speed

[raphaelcoeffic]

This PR improves the flashing speed by ignoring the pollTimeout returned by ST's DFU bootloader, which is way too long and just polls the status continuously.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.

Project coverage is 39.53%. Comparing base (21b749c) to head (3952cc3).
Report is 1 commits behind head on main.

Files	Patch %	Lines
src/shared/dfu/index.ts	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #88      +/-   ##
==========================================
- Coverage   39.54%   39.53%   -0.01%     
==========================================
  Files         103      103              
  Lines       12006    12009       +3     
  Branches      645      645              
==========================================
  Hits         4748     4748              
- Misses       7251     7254       +3     
  Partials        7        7              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

EdgeTX Buddy has been automatically deployed to Cloudflare.
✅ Preview: https://de537542.buddy-7a6.pages.dev
✅ Storybook: https://de537542.buddy-7a6.pages.dev/storybook

[pfeerick]

Writing EdgeTX 2.10.3 to TX16S on Windows:

With https://6c6314e7.buddy-7a6.pages.dev
55s Overall
23s Erase
32s Write

With buddy.edgetx.org
55s Overall
24s Erase
31s Write

Taking into account rounding error, and observer error/lag, basically no difference here atm yet.

dfu-util is a hell of a lot slower...
still around 24s to erase, but 2m39s - 3m02s overall - to DFU flash same firmware (as configured by Companion).

For a while now on Linux, I have been using pyfu-usb do DFU tx flashing, and that took exactly 52.74sec to DFU erase and flash... (so lets just call it 55s also... )...

So is the problem actually just dfu-util, and all the other tools don't have the arbitrary delay?
btw, have you seen this? Fast mode is coming to dfu-util, it seems... https://sourceforge.net/p/dfu-util/tickets/195/

Please join me in saying "WTAF" when you read the table of results... and see how blindingly fast dfu-util 0.11 is vs STM32CubeProgrammer or dfu-util preview with fast option i.e.

[raphaelcoeffic]

Taking into account rounding error, and observer error/lag, basically no difference here atm yet.

It seems the PR has been deployed to buddy.edgetx.org as well...

Edit: I rolled back to the previous deployment so you can really compare.

[pfeerick]

Ok, that was more like it... Buddy now took about 24s to erase, 2m37s to write, for a total of 3m01s (on Linux) vs the (still) 55s overall with the preview build... T12MAX was ~18-19 seconds to erase and flash... at these speeds... I'll be DFU flashing instead of uploading to SD and bootloader flashing from now on 🤣

[freshollie]

Nice! Not sure what configuration has been made for the pages to deploy to production 🤔

[pfeerick]

Nice! Not sure what configuration has been made for the pages to deploy to production 🤔

That was probably me in #83 - the branch: ${{ github.head_ref || github.ref_name }} line that I had to drop when changing the actions from cloudflare/pages-action to cloudflare/wrangler-action apparently didn't just tell it what branch to build, but also controlled whether the action thought the build is for production or preview... 🤦 Adding - uses: actions/checkout@v4 to that step matches the example they have for dual preview/production deployment, so that must give it the same information. 🤷

[pfeerick]

Given I have been flashing with pyfu-usb in this way for over a year now for all the various targets... I consider this DFU timing change (from dumb timeout to polling) stable/reliable for production... I have had no issues to date arising from it ;)

edit: further, and more relevantly, I have now been using the preview version of this for flashing various handsets and have had no issues at all.