Raspberry Pi and America,

On Jun 29, 2012, at 6:15 PM, Tony Duell wrote: They're definitely used by the Linux distro involved. I don't recall if the driver is source or binary, but the video processing is, like most modern GPUs, a separate processor with its own firmware. The specs are certainly closed (and Broadcom will probably give the Swift Sword of Death to anyone caught distributing them), but certainly at least enough of the kernel code to establish a memory-mapped framebuffer is available (or the console wouldn't display). The proprietary stuff is the access to the 3D acceleration and the video decoding stuff, which is at least supplied via libraries with public APIs. Not perfect, but not totally unusable. Only runs under Linux, though, so if you were trying to do something on bare metal, you'd be out of luck. There is a 26-pin GPIO port available of which 17 pins can be used for I/O (the rest are power, ground or NC). The GPIO pins are the standard bidirectional, tristatable things you would expect. Some of the in functions are muxed with SPI, UART, I2C and I2S so that you can use more advanced devices without bit-banging. Almost all of these are accessible through standard Linux APIs, though the support is not 100% there in all of the distributions currently extant for the device (they're catching up fast, though). This page gives a good overview: http://elinux.org/Rpi_Low-level_peripherals There's no buffering, and everything is 3.3v, so for a lot of real world applications you'd need to at least give it some buffers to keep the ESD demons away. For a lot, though, you can get away with taking chances (especially for a $25/$35 board). Pretty much all of the Linux distros offered as canned SD images have a standard GCC toolchain installed, and those that don't have it installed as stock probably make it fairly easy to get it on there. The point, after all, is to get kids programming. :-) - Dave