Job Posting: Chrome Plugin Developer

Not my iPhone! (Having chrome preinstalled)

I’d expect something like that too but all examples I’ve seen are/behave the same.
The code to select a port is:

const port = await navigator.serial.requestPort();

Only options that are possible are vid pid filters

Okay I just tried it on my W10 laptop and it seems it will detect live port changes. So it’s probably my old W8.1 desktop thats the issue.


AFAIK ‘Chrome’ on OSX runs on webkit and not real chromium. Might as well stick with safari :stuck_out_tongue:

I actually run Firefox on my phone too so I can share the bookmarks across devices. I don’t mind Safari on a phone but not really on the desktop.

1 Like

So back to the real question … can that code be used to flash from the Cart web site?

If it can definitely flash a .hex file without issue, there’s no reason (as far as I can see) that it shouldn’t be able to be adapted to work with the FX chip. As I mentioned before, it’s just a matter of sending commands to the bootloader - the ‘knocking’ is the difficult bit.

The FX model bootloader (Cathy3K? I’m terrible at keeping track of these bootloader versions) uses a modified version of AVR109 with a few additional commands. It’s documented in a thread somewhere.

Here’s the thread with the extended commands:

I can assist with the Cart side of the project but I am not sure I know enough to do the flashing part.

A session that uploads data to the FX chip might look like:

  • 'P'/80/0x50 - Enter programming mode
  • 'B'/66/0x42 - Begin block command
  • <High byte of a page address>
  • <Low byte of a page address>
  • 'C/67/0x43 - Specify that the block is to be written to the FX chip
  • <A page worth of data to be written to the FX chip>
  • 'L'/76/0x4C - Leave programming mode
  • 'E'/69/0x45 - Exit bootloader

At least I presume a ‘block’ for the FX chip is a page.
I don’t recall how many bytes are in a page though.
I think it’s either 256B, 1KB or 4KB.

I could give you a copy of my command-line uploader (written in C++) if it’ll help, but I abstracted the commands away so you’d have to do a bit of digging to see the full extent of what’s going on.

As for the ‘knocking’, you have to:

  • Connect on the active port with settings of:
    • 1200 baud
    • A byte size of 8
    • No parity bit(s)
    • 1 stop bit
  • Then close the connection

After which, another port will become available (for Windows it’s usually the next numbered COM port) and that will be an open connection to the device in bootloader mode.

I can’t remember who it was that termed this ritual ‘knocking’, but the idea is that the first connection is like the secret knock that gets you into the masonic lodge of the bootloader.

Hold onto the C++ code … the example JS code is probably much closer to what the end product will look like. If it is doing pretty much what your C++ code is doing, it will make an excellent starting point for someone to use.

But unfortunately, probably not me!

Nicely worded!

1 Like

I’ve made a few little changes to that avr109 webserial and managed to upload a hex file now (Chrome and Edge). Looks promising :slight_smile:



I cannot wait to see this work.

No real work today?

I’ll see if I can play around with it some more.


Shout out when its time to integrate into the cart site :slight_smile:

Another thing to consider is what O/Ss need to be supported. Arduino supports Win, iOS, Linux.

Something built using WebSerial would run on whatever OS supporting browsers would run on.

Apparently it is actually possible to run Chrome on Linux, and it seems that Chromium also runs on Linux.

Do you mean macOS (formerly OS X)? iOS (formerly iPhone OS) is the phone version.

Sorry, yes. I get the Apple systems mixed up. Windows has always been Windows and Linux has always been Linux.

1 Like

Note that Mozilla have declared that they have no intent to support WebSerial, they consider it to be harmful. Still, according to, the amount of people using a compatible browser (Chrome, Opera, Edge) is a significant chunk, so it’ll be useful even if a lot the regulars are on Firefox.

I played a bit more with that WebSerial example and it seems we can forget to have a simple upload button. Each new browser session we need pair/ approve the com port again twice! once for the port that appearswhen a USB enabled game is running on Arduboy) and 2nd for the actual bootloader port. only when both ports are paired / approved we could do an automatic upload. example:

Arduboy is connected to PC and a USB enabled game is running:

  1. click upload button
  2. a pop up will appear to connect to Arduboys port.
  3. select the port and click connect.
  4. Arduboy is ‘trickled’ into bootloader mode
  5. another pop up will appreat to select the bootloader port
  6. select the port and click connect.
  7. file can now be uploaded

For the classic Arduboy you’ll have to be fast at step 6 as the classic bootloader will only be active for ~8 seconds.

1 Like

What do you mean by ‘pop up’ here - another browser window or some sort of dialogue. Can we direct that activity to an iFrame or something so it looks OK?

It’ll likely be one of those “this webpage would like to access your microphone” sort of pop-ups because access to a serial port is a potential security risk. Odds are it’s entirely controlled be the browser and the JavaScript engine can’t even ‘see’ it due to sandboxing.