Arduino Cloud Editor and Web Serial API on Chromebooks
If you have ever heard about the Arduino platform, you know for sure that one of our goals here at Arduino is to democratize technology, and specifically electronics, so that the broadest possible audience can benefit from it, in an accessible and easy way.
This means also, among other things, that we try to support as many operating systems as possible, since our users — be they makers, students or professionals — come from different backgrounds and use different tech setups.
In this post I will focus specifically on Chromebook users, which are forced to use a slightly different way to access the Arduino platform. Let’s see why.
Can I use the Arduino platform on a Chromebook?
Of course you can. Chromebooks and Chrome OS — the underlying operating system — have by design some limitations, but, hey, we’re here to help!
So, first of all, a few key questions:
- Can I program an Arduino board from a Chromebook, today?
Yes, you can! Check the Arduino documentation site for some technical insights. - Can I use the glorious Arduino IDE for that?
Unfortunately no. - What else can I use, then?
The Arduino Cloud Editor. It’s a web app with an extensive feature set similar to the desktop IDE.
The magic of Arduino can begin on Chromebooks too!
Arduino Cloud Editor on Chromebooks: a quick intro
The Arduino Cloud Editor, being a regular web app, is available on all operating systems with a modern browser (I’m sorry, IE9, you’re not a modern browser anymore). It’s ideal for beginners and students who just want to start programming Arduinos right away, without too much hassle. Oh, and it comes with a generous free plan. Oftentimes I use it myself for quick prototyping; my sketches are saved online and I can access them from different computers. I can also easily share a sketch with a colleague, if needed.
There’s a little difference between Chrome OS and other operating systems, though.
On non-Chrome OS computers, you have to install a lightweight background software (called Arduino Create Agent, based on the Arduino CLI) which will take care of everything you need to upload your code from your browser to the Arduino board connected to your computer. This Agent acts as a bridge between the browser and the board via the serial port on your computer.
On the other hand, on Chromebooks, you can not install software the “traditional way”, so you can’t install the Arduino Create Agent. This is one of the limitations I was referring to above. On Chromebooks, you can extend the functionalities of your computer using Chrome Extensions and Chrome Apps.
Chrome Extensions run in the browser itself. You may be familiar with Extensions already, even on non-Chrome OS systems. E.g. you may have installed an Ad Blocker in Chrome. That Ad Blocker is very likely implemented as a Chrome Extension.
Chrome Apps instead run at a lower level, in a stand-alone mode, with specific API to interact with the underlying operating system. In fact, Chrome Apps have more capabilities than Extensions.
A few years ago we implemented the counterpart of the Arduino Create Agent as a Chrome app. Internally it was using a very powerful library called browser-serialport, which, at that time, was the only way to access the serial port on Chrome OS.
Enter the Web Serial API
A few things are changing these days, in the Chromebook ecosystem. Google — the creator and maintainer of Chrome OS — is deprecating Chrome Apps (but not Extensions). Starting from June 2022, the Google Web Store doesn’t accept new private and unlisted apps. But no worries, the Arduino Chrome App will still be available and updated, if necessary. Chrome apps will be supported on Chrome OS until January 2025.
Someone is thinking this is the right move from Google. E.g. theverge.com has an article mentioning “finally killing off Chrome apps, which nobody really used anyhow”. Well, our Chrome OS users were using at least one of them!
Now, Chrome Apps developers are warmly suggested to migrate to something different “as soon as possible”. Depending on the functionalities of your app, there are a few different options, but the one that best suits our needs is to build a Progressive Web App, or PWA in short.
It’s not the purpose of this post to describe what a PWA is. What’s relevant for us is that a few years ago the Google Chrome team started a programme, called Project Fugu, whose purpose is to enrich the current web technologies (HTML, JavaScript, etc) with extra capabilities to close the gap between web and native applications.
One of the extra capabilities provided by Project Fugu is the Web Serial API, available since Chrome 89. Apparently, this is exactly what we need to continue to support serial communication with Arduino boards. That’s why we decided to add, initially as an experimental feature, support for Web Serial API on Chromebooks.
If you are a lucky owner of a Chromebook, you can try it yourself here:
https://play.google.com/store/apps/details?id=cc.arduino.create_editor
Please take into account that this version is still in development and the number of supported boards is limited, at the moment. If you have one of these boards, you can give it a try today:
- Arduino UNO
- Arduino MKR WiFi 1010
- Arduino RP2040 Connect
- Arduino Nano 33 IoT
The troubled journey to Web Serial API support
At the moment we’re still working on the beta version. We’re also adding support to the Web Serial API in the Arduino IoT Cloud app, but we’re not there yet. I would love to write another blog post once this migration is completed.
I want to highlight, since it will be useful to understand the rest of the chapter, that we’re using the serial port for two different purposes:
- read and write user data to the board (e.g. to read messages sent by the board in the serial monitor)
- upload a binary compiled sketch on the board (something that happens under the hood when you click the “Upload” button in the editor). This second task turned out to be the a little bit tricky
We’re working with Google to report some of the issues we have found. Some of them can be fixed, some of them are “by design”. The reality is that the Web Serial API still has some missing bits, compared to the capabilities of Chrome Apps, which made our migration path a little bit harder than expected.
Here’s a list of the main issues we have encountered:
- First and foremost, with the “legacy” Chrome App we could interact with the serial port completely programmatically, without requiring any user intervention. Once you plug in a board, the system is able to detect it and connect to it right away.
On the other hand, with the Web Serial API, for security reasons the browser has to ask the user to grant permission to access the serial port. Any interaction with the serial port must be initiated by a user gesture. This is nice, generally speaking. It’s very good that a web browser, which may load a malicious web site, has to ask the user to grant permission to access their peripherals. But we had to review our user experience a little bit. Now, before uploading on the Arduino board, we have to present a dialog asking the user to grant their permissions. And since the user can, at any time, revoke any of them, we can not rely on the initial permission. We have to check, internally, any single time, if the serial port can be safely accessed. This had, in my opinion, a bad effect on the user experience. It’s working anyway, but honestly, it used to be better. - Whenever the browser is asking the required permissions to the user, a native dialog is displayed.
And since this action must be user initiated (e.g. clicking on a button), this means that the user has to click around at least three or four times before starting the upload:
1. Click on the “Upload” button in the app
2. We have decided to present an additional dialog to the user as a “rationale”, just to explain why we’re requesting this permission. This step is optional, but it’s considered a best practice. User has to click also on this confirm button.
3. Click on one of the serial ports presented in the dialog above
4. Click on the “Connect” button at the bottom of the dialog
- At the moment the Web Serial API is not detecting the serial number of the device, not allowing us to univocally identify the connected board. It can detect only the ProductID and VendorID via the getInfo function. This means that if a user connects two boards of the same kind, we can’t exactly determine which board is which. This is kind of an edge case, of course, but the fact is that we were able to do it before, with the legacy Chrome app.
- Arduino SAMD boards (e.g. the Arduino MKR WiFi 1010) work in a dual mode: bootloader mode (to upload a program) and application mode (to run a program). Traditionally, a user can switch to bootloader mode by double tapping the Reset button on the board. This can be done also programmatically with an operation called “touch”. So far, so good. The point is that when the board is in bootloader mode, the ProductID of the board is different from the one in application mode. This is causing the Web Serial API to think they are two different boards. For this reason, for the security policies mentioned above, we’re asking the user to start the whole request process twice, once for the board in bootloader mode, once for the application mode. This is working but is far from ideal. We have asked advice to Google, they are thinking to add some heuristic to determine when the board is the same, just with a different ProductID (actually, the ProductID is different just by the most significant bit). Thanks to the ticket linked above, I learned that devices have double personality problems too!
- Reading user data sent via a serial port is one of the basic operation you can do with a board. Somehow this was affected as well. Let’s imagine you have a board already executing some code which writes some data to the serial port. But it’s the first time you connect it to your browser. You would expect to open the serial monitor and just read some messages coming out from the board. But this will not happen, unless you explicitly grant (via a user gesture, typically a click) the permission to do it. Again, this is working, but it’s a little bit worse than before. You can’t tell if the board is not sending data at all, or you just forgot to grant permission to it. Or you forgot that you revoked the permission just a few minutes before.
It’s worth mentioning that our app has to deal with different boards with different protocols, e.g. AVR for the most classic Arduino boards (like the UNO), SAMD for Atmel’s SAMD21 chips, UF2 for the RP2040 Connect, and so on. This is very convenient for our users, they can just use the app regardless the type of board they have plugged in. But it makes things more complex for us to implement.
Other nice projects using the Web Serial API exist out there, e.g. the Espruino Web IDE or the amazing Duino App (which, by the way, is open source and served me as an inspiration with some issues I had). I might be wrong, but these projects have the luxury to take care of one single protocol at a time, allowing them to use a single consistent approach.
Is Web Serial API the future of Arduino programming on the Web?
In our team in Arduino we started a discussion about the possible future adoption of Web Serial API for all our web based apps, also for non Chrome OS users.
To be honest, at the moment, we think that the limitations imposed by the Web Serial API can negatively affect our users’ experience. The native Arduino Create Agent has one prominent advantage over any other solution. It’s based on the Arduino CLI, which is constantly updated and supports more and more boards at any new release. For this reason, we don’t think we will migrate to a pure Web Serial API version on non Chrome OS systems.
On the other hand, on Chromebook it seems we don’t have other options, since the end of life for Chrome Apps is coming soon.
Are there any better alternatives to overcome the UX issues I mentioned above? Probably yes. It will be worth exploring the usage of Chromebooks as Linux machines. But this is the topic for an upcoming dedicated blog post.
