Pybricks Code interface for EV3Brick (saving-lego-mindstorms)

[afarago]

Following up with the discussion let me share the current progress and also start a discussion to plan how the new Pybricks EV3 could be supported in pybricks code project.

I definitely do not have a full picture, but have some time, much more enthusiasm and interest to make it happen, so glad to contribute with code to this wonderful initiative from the Pybricks authors!

Firmware flashing

EV3 uses USB HID, and in modern browsers like Chrome we have WebHID API available.
Following the pattern of pybricksdev I have created a typescript implementation, already trying to group a library to be used instead of webdfu.
https://github.com/afarago/ev3hid-upgrader
https://ev3hid-upgrader.netlify.app/

Flow for Firmware install

1. opening the installPybricksDialog would add a new type in HubPicker dialog.
   
2. following up with the license
3. probably skipping hub name (?)
4. we would proceed to the standard src/firmware/sagas.ts and implement handleFlashUsbHid
   The mentioned webhid-ev3-upgrade component could handle the flashing process

(npm packages for @pybricks/images and @pybricks/firmware will need to be in place and updated, images are already in place)

Would be great to agree on the architecture and the generic flow to minimize rework. Also should be an agreement on the breath of tests created, to keep a proper quality balance and also release.

Flow for Restore install

To be decided if e.g. the original firmware of e.g. 1.10E with 16MB, is allowed here, and is a wise choice for restore.
Is there a need for restore above a link to https://ev3manager.education.lego.com ?
To be discussed.

Connection to Code IDE

I assume that BT or (BLE?) connection should be available to EV3Brick.
Is there a separate comm layer needed?

(This discussion ticket is far from being complete, yet is placed as a conversation starter here, @laurensvalk @dlech ).

[laurensvalk]

Thanks for opening this discussion here, and for your great progress on the web adaptation of the EV3 flasher!

Since EV3 installation will be quite different from download-and-run, I think we can look at this separately. For installation we can largely follow the pattern that is there for SPIKE.

To keep things simple, I propose that we ask the user to enter update mode manually by holding the right button and then booting. I am happy to make a similar video as we have for SPIKE.

To be decided if e.g. the original firmware of e.g. 1.10E with 16MB, is allowed here, and is a wise choice for restore.

It would be nice if we can ship one with the app that we know the license of. We can always provide instructions on our site with links to other official versions.

In principle it can also be restored with the original app, but I think that is only with the EV3-G (lab) app.

probably skipping hub name (?)

The firmware doesn't have an option for this yet, but I think we should give the EV3 brick a name just like we do for the other hubs. I would keep it in the UI and just ignore it until we have firmware support for it.

[dlech]

To keep things simple, I propose that we ask the user to enter update mode manually by holding the right button and then booting. I am happy to make a similar video as we have for SPIKE.

I think this is a good default, but we could also make it detect EV3s running official firmware and reboot into update mode quite easily. There are always people who don't read the instructions. 😄

It would be nice if we can ship one with the app that we know the license of. We can always provide instructions on our site with links to other official versions.

I don't think redistributing these should be a problem. Since it is Linux-based, it is pretty much all FOSS licenses. I would actually include 3 versions: 1.09H, 1.09E and 1.10E. The first two are the best versions for home and education respectively. 1.10E is needed for MakeCode users but has some known bugs, so isn't good for users of other software.

EV3-G hasn't run on Mac for many years already and https://ev3manager.education.lego.com/ may not be around forever (and requires users to download and install a background service). So having a firmware updater in general would be helpful for the community even for people who don't use Pybricks.

Also should be an agreement on the breath of tests created, to keep a proper quality balance and also release.

Aim for full coverage.

[laurensvalk]

To keep things simple, I propose that we ask the user to enter update mode manually by holding the right button and then booting. I am happy to make a similar video as we have for SPIKE.

I think this is a good default, but we could also make it detect EV3s running official firmware and reboot into update mode quite easily. There are always people who don't read the instructions. 😄

Would this require connecting via the Chrome dialog twice?

[afarago]

I think conceptually yes, as both the normal EV3 and the update mode use different identifiers.

Once connected it is easy to use a reconnect mechanism both for serial and also for bluetooth.
reference: https://ev3hid-upgrader.netlify.app

There is also an example/button for booting to update mode here.

[laurensvalk]

Thanks.

My vote would be for a single connection step that always works, regardless of which firmware is on the hub already.

Then the flow is the same as for SPIKE Prime, which has worked well.

There are always people who don't read the instructions. 😄

If this is the motivator, then there is another approach to achieve this. This is something we can now do for SPIKEv3 hubs, too:

When people try to connect to download-and-run programs, we could make it say "You have to install Pybricks on your hub first." when they connect to a hub with the wrong firmware. The info dialog could highlight or open the installer.

[erik-thompson-seattle]

@afarago Let me know if you would like any assisstance.

[afarago]

Yes, all help is more than welcome.
Here is my rough workplan, feel free to comment or pick any subtask.

I have a very early prototype of the pybricks-code just jotting down the first trial and error.

• here a proper UI design and agreement with David and Laurens is the next step
• then a proper implementation of the install dialog with complete test coverage
• it might me a first step to implement everything, except for the actual async update process (that could be mocked by a 2000 ms delay)
• also a restore step and implementation is due with complete test coverage

I have a typescript ev3 updater over hid

• a standalone library should be a logical next step, with proper tests in place
• I think a separate npm publish would be a great way to integrate

[drjuit]

to make

Any updates? Im really really interested, there a lot of groups in facebook that would love to see this happening