Galago: Make things better. A hardware prototyping platform.
kickstarter.com
kickstarter.com
"72 MHz 32-bit ARM CPU with 32KB of flash ROM and 8KB of RAM"
The reason is that I've been playing with an ST Micro STM32F4 which an ARM Cortex-M4 chip [1] which on the $15 demo board has both an on-board debugging system 192K of RAM and 1MB of Flash. Granted that is a $12 chip but still.
The development infrastructure of 'shields' is a pretty decent win, all three of the Arduino, the Netduino, the Beaglebone do this. I'm also a big fan of open expansion boards. The inkshield I got for the Arduino, way cool.
Something I miss though is an on-chip development environment. I know that sounds silly but I really think it would rock if you could just connect this to a serial port and start coding on it without the 'host' running the terminal software knowing anything.
[1] http://www.mouser.com/ProductDetail/STMicroelectronics/STM32...
For some reason I can't explain, I would really love a single chip with an MMU/enough RAM to run linux in a QFP/QFN package so I could hand solder it. I doubt there's a business case for such a part, but I want one darn it.
I wonder if there will be CAD jockeys I can find to turn my design into production ready files. Someone up to speed on the tools can probably save me a lot of pain over learning them myself.
Can you talk about any details on how you implemented the debugger and how it's going to work in terms of software tools?
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!
You really need to put "GDB debugging" front and center in the sales copy instead of buried in http://outbreak.co/galago#coding That's going to be the major deciding feature for someone looking to choose between Teensy 3.0 and the Galago. I know which one I'm choosing for my next project. :)