I'm the other co-founder and I designed the Galago.
The USB connector you see on the board connects directly to the on-board debugger. It's not a virtual serial port like the Arduino nor does it connect to the ARM chip directly. The debugger is therefore the main paradigm when developing on this board, which is consistent and leads to a good user experience.
The debugger itself is the world's smallest and least expensive ARM hardware debugger, and it was designed so (someday) every prototyping board can have one. Galago is the first step in that direction. To keep it simple, much of the high-level debugging logic occurs in a driver that works between GDB and the device's firmware. This obviously allows you to use GDB on the command-line or through e.g. Eclipse.
At a high level, a browser-based IDE is used that connects down to a locally-running web server (on a high-numbered local port) that manages building, flashing and debugging your projects. I showed a glimpse of this in the video. All components run (or will run) on Mac, Linux and Windows.
For convenience and consistency, new firmware is loaded through GDB and thus through the debug interface, without having to reset the chip. This is why no button is needed.
We didn't want to stress these implementation details too much because not everyone who uses it can (or should) care about that, but the HN crowd can certainly appreciate the design.
The USB connector you see on the board connects directly to the on-board debugger. It's not a virtual serial port like the Arduino nor does it connect to the ARM chip directly. The debugger is therefore the main paradigm when developing on this board, which is consistent and leads to a good user experience.
The debugger itself is the world's smallest and least expensive ARM hardware debugger, and it was designed so (someday) every prototyping board can have one. Galago is the first step in that direction. To keep it simple, much of the high-level debugging logic occurs in a driver that works between GDB and the device's firmware. This obviously allows you to use GDB on the command-line or through e.g. Eclipse.
At a high level, a browser-based IDE is used that connects down to a locally-running web server (on a high-numbered local port) that manages building, flashing and debugging your projects. I showed a glimpse of this in the video. All components run (or will run) on Mac, Linux and Windows.
For convenience and consistency, new firmware is loaded through GDB and thus through the debug interface, without having to reset the chip. This is why no button is needed.
We didn't want to stress these implementation details too much because not everyone who uses it can (or should) care about that, but the HN crowd can certainly appreciate the design.
I hope this answered your question!