So the user is always expected to have the IDE installed because of the drivers… might as well use that instead of bundling it?
late to the party - apologies! The Arduino IDE’s compiler is called Arduino Builder and it’s here: https://github.com/arduino/arduino-builder
It’s written in Go so the binary is cross platform. I have successfully gotten this compiling code on a VM pretty reliably. It might be easier than having to recreate the ‘magic’. That said, you’re only having to worry about the Leonardo compilation toolchain rather than everything supported in the IDE. I’ll try to stick around in here and help if you decide to go down the Builder route.
As for Avrgirl not being super stable with the Arduboy - I totally am aware and I’m sorry about that. What I need is more manual testers and a couple of folks to loop in so we can identify what might be going on. The Arduboy is very close to being a Leonardo board but I have run into dramas getting my software to pull out of reset status and reconnect with the board once in bootloader mode. So it sometimes works, and sometimes doesn’t. It’s a bug I’d like to fix so let me know if anyone would like to go spelunking with me on the possible causes.
All of this work is amazing, I’m glad Arduboy will have a non Arduino IDE solution standardised from everyone’s ideas very soon!
That’s strange. The Arduboy is wired the same as the Leonardo and uses the actual Leonardo bootloader. It’s hard to imagine what the bug could be.
I guess by “being very close” I mean that something in the AVR109 package is behaving differently for the Arduboy compared to any other AVR109 board I have tested avrgirl with. Major shrugs but I’ll need to dig into it.
EDIT: just to be clear, I mean behaving differently on my end. I’m aware the Arduino IDE / avrdude works perfectly with the Arduboy.
I actually tried going the Electron+avrgirl route at first, but it just wouldn’t work reliably. I ended up writing my own flasher.
I would love to see the flasher that you wrote, is it open source? It might help me debug avrgirl. Thanks so much!
It might be less flexible but it makes matters easier.
It also allows you to make educated guesses about where certain files are (like /Arduino/libraries).
Although if the files aren’t found in the usual places, and there’s no registry entry specifying the location (which there might be, I don’t know) then you might have to get the user to manually provide the location.
EDIT: It’s based on avrgirl, the main difference being the serialport is chrome’s instead of node’s and this:
IIRC, avrgirl does the reset and waits for a “close” event before connecting. For some reason this never happens. I modified it to close and connect after a timeout (tried a bunch of different values). At this point, it would work sometimes.
ChromeSerial does this, instead: Poll available serial ports every 15ms. Whenever it finds a VID/PID it can reset, it does that. When it finds a VID/PID it can upload to, it uploads.
Yes they do. They purchased it or was assigned to them by becomming an USB-IF member. If using their VID is a problem. Then you have to pull out 5K and purchase your own
The driver isn’t a problem the .inf is just an text file telling that the USB VID/PID is a CDC serial device and should use windows usbser.sys driver. The inf file is digitally signed by the accompanying .cat file. Without the .cat file you’ll get the warning that the driver is not digitally signed when you install it.
The bootloader is not a problem the licence allowes you to sell it without a fee.
Your own VID /PID can be easily used with Arduino by adding it to the boards.txt file
There are companies that give out free USB id’s if you’ve got an open source project.
But then it would lose compatibility with Arduino without custom board files and then there is still the issue of rolling your own drivers.
We came pretty close to doing that at launch and packaging new drivers with Codebender but at the last minute just decided it was easiest to let it stay a Leonardo for “ease of use”.
So I think we will still need the user to install Arduino to get the drivers? Because if we created our own drivers that recognize the leonardo usb id’s then that’s tantamount to trademark infringement?
I’ll have to look into this more.
bunnie has been writing some driver agnostic DFU bootloaders for the ARM m0 platform and I think that’s the way to go in the future.
Would you correct URL of the light blue “Arduboy Utility” button, please?
Yeah, done. Sorry it took a while. On the final leg of my journey home.
Thank you verrrrrrrrrrrrrrrrry much!!
Whoah, how did I miss this whole thread?
I have a module for this in Clouduboy, called clouduboy-platforms. This will be hosted with the rest of Clouduboy on compiler.clouduboy.org as an open (but rate limited) API, any tool like the above could use their own API keys (just need to request one) to use, or host it on their own servers (it’s open source, like the rest of Clouduboy). In a way,
compiler.clouduboy.org is similar to Suz’ avr.pizza, but it focuses on Clouduboy-supported platforms (currently the Arduboy and experimental support for the Tiny Arcade and the BBC Micro:Bit), and it also can deal with the JS->C++ translation in one go (if one uses MicroCanvas JS files as their input). It spits out a ready-to-use HEX file in the end.
compiler.clouduboy.org is not online yet - it will go online next month, with the (spoiler alert) official announcement.
clouduboy-platforms uses PlatformIO installed on the system, which would be a pain locally but it works just fine for hosted, linux-based services, on a Raspberry Pi or even or a VM. It does all the “magic” too while compiling.
Yeah this bit me too last month.
The clouduboy-flasher is an Electron app that uses
node-serialport via @noopkat’s’
avrgirl-arduino, I’ve been trying to fix the reliability issues in a local fork before last month’s workshop, and I thought I did - but they resurfaced in the worst possible time (on the workshop itself).
Interestingly the issues rarely manifest on my linux (Arch) machine, but completely bork flashing on Mac OSX. I’ll bee looking into this more, Suz, once I got the compiler and the other bits up & running, though, so expect me to bugger you about these (probably late March or early April, I don’t want to bug you too much before your talk at JSConf AU )
Chrome Serial is such a pain to work with
WebUSB might be a savior here, but I haven’t had a chance to run any experiments on this.
Currently, in my eyes, WebBluetooth is the go-to king-of-the hill when it comes to seamless browser-to-IoT device connectivity - I have ongoing experiments with a tiny BLE-enabled external module that hooks up to the arduboy and lets you flash it from any BLE supporting browser (mobile OR desktop).
This does require external hardware but yeah…
Totally worth it. No dealing with native modules and electron version incompatibilities. And it works on OS X.
I was referring to ProjectABE’s flasher, though, which is a total rewrite of avrgirl based on chrome.serial. Pardon the unimaginative name causing a confusion.
I do wish we could just use WebUSB.