ci: deploy to Github Pages

[igrr]

Similar to espressif/esp-launchpad#4, adds a CI job to deploy the latest version from main branch to Github Pages. With this PR, we don't need to maintain gh-pages branch manually.

Have tested this workflow in a fork, deployment was successful: https://igrr.github.io/esptool-js/.

[balloob]

You forgot the step to build bundle.js causing the JavaScript from ESPLoader to not be loaded.

[igrr]

@balloob thanks for noticing this! I have updated the workflow to run npm run rollup.

The new version still doesn't work quite as well as the one in gh-pages branch, though.

With this version, connecting to an ESP32-C3:

esptool.js v0.1-dev
Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting..._connect_attempt default_reset false

Sync
Sync err Error: Timeout

.Sync
538052359

Error: Timeout

With the version in gh-pages:

esptool.js v0.1-dev
Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting....
Detecting chip type... ESP32-C3
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 7c:df:a1:b3:8e:b8
Uploading stub...
Running stub...
Stub running...
Changing baudrate to 115200
Changed

@brianignacio5 are you seeing any similar issue in the main branch, or does it work okay for you?

[balloob]

Hm we just had 2 PRs that made changes to the C3. 813e33a and eb5ba6b. One of those might have broken it.

Can you try out with a different board?

[brianignacio5]

@balloob thanks for noticing this! I have updated the workflow to run npm run rollup.

The new version still doesn't work quite as well as the one in gh-pages branch, though.

With this version, connecting to an ESP32-C3:

esptool.js v0.1-dev
Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting..._connect_attempt default_reset false

Sync
Sync err Error: Timeout

.Sync
538052359

Error: Timeout

With the version in gh-pages:

esptool.js v0.1-dev
Serial port WebSerial VendorID 0x10c4 ProductID 0xea60
Connecting....
Detecting chip type... ESP32-C3
Chip is ESP32-C3 (revision 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 7c:df:a1:b3:8e:b8
Uploading stub...
Running stub...
Stub running...
Changing baudrate to 115200
Changed

@brianignacio5 are you seeing any similar issue in the main branch, or does it work okay for you?

I've tried with ESP32-C3 but I couldn't also connect. I suspect is something related with the esploader.ts's command function on line 215 trying to read the command response and no response is given

[igrr]

I'm getting the same with ESP32 connected over an FT2232-H USB bridge

esptool.js v0.1-dev
Serial port WebSerial VendorID 0x403 ProductID 0x6010
Connecting..._connect_attempt default_reset false

Sync
Sync err Error: Timeout

.Sync
Sync err Error: Timeout

.Sync
1431642130

Error: Timeout

The version in the gh-pages branch works fine for the same board.

[igrr]

Hm we just had 2 PRs that made changes to the C3. 813e33a and eb5ba6b. One of those might have broken it.

I think these PRs look okay, the changes will affect only the flashing stage and not the initial connection/sync stage.

Might be a regression from the typescript rewrite? I guess we need to compare the data set to/from the chip by the version in gh-pages and by the version in main branch.

[brianignacio5]

I'm trying to find the reason why the TS rewrite fails. I think it's because timeout error handling and MD5 calculation error but it is hard to understand the issue because I don't know about expected data. Can someone help to test to record the data from gh-pages to compare with main branch ?

[balloob]

Since the package is currently in a broken state, can we revert the TypeScript rewrite until the issue is found?

[Jason2866]

Is there a time line when will be worked on the known bugs?
Currently it is completely broken :-(

[domagojk]

The issue was calling flush_input() in connect function.
In gh-pages, flush_input is calling this.transport.readRaw which is a typo but since it was try/catched, the error didn't show up. In typescript update this was correctly changed to this.transport.rawRead but it then caused the timeout issue.

I then just removed calling flush_input() and it worked. Not sure if there is a better way to do it, but this is now basically the same as in gh-pages. Here is a pull request: #62

[igrr]

Seems to work okay now with the fix from @domagojk (thanks again! 🙏 ), so I'll merge this.

There are still a few minor issues compared to the gh-pages branch, like slightly messier logs, but we can fix that in a separate PR.