Raspberry Pi er en liten datamaskin utviklet av Raspberry Pi Foundation. Maskinen har USB-porter, Ethernet-port, HDMI-utgang for lyd og bilde, analog video-utgang og analog lyd-utgang (1-bit PWM). Raspberry Pi har også lignende pin-tilkoblingene som en Arduino Uno (men trenger en del ekstra elektronikk som beskyttelse og har ingen analoge inputs), og det finnes muligheter for å programmere den ved å bruke en arduino-lignende framework. Det er også planer for å støtte Python som hovedspråk.
Raspberry Pi ble i utgangspunktet tenkt som et utdanningsverktøy. Det er planlagt to versjoner av Raspberry Pi. Versjonen med Ethernet og 2 USB-porter koster 35 USD og er i produksjon. Den planlagte 25 USD-versjonen kommer ikke til å ha Ethernet og vil ha kun én USB-port.
Hvis du er i Sonen og leker med Raspberry Pi, så kom med dine erfaringer her!
Review by Jonny
After finishing a project with the RBPi & raspbian, here are some of my thoughts. I got a Model B, and I'm running it off a 2GiB MicroSD card (using an adapter.) After playing around with it for a while, I've stripped down raspbian to a 200 megabyte size, in order to use it as a NAS (network attached storage) running a samba and ftp server in conjunction with a 2TiB USB harddrive.
The rbpi adheres to RoHS, FCC, CTick, CSA, WEEE and follows the CE recommendations. The board looks fairly sturdy, with the main SoC chip being a double-stacked PoP BGA package. The SoC is a Broadcom BCM2835 licensing a ARM1176JZF-S core, and it does almost everything on-chip, except for networking, which is controlled by a smsc LAN9512-JZX PHY controller. A few mechanical design choices stand out:
- The SD card projects very far out from under the board, wasting a lot of space if you wish to use the rbpi in a completely enclosed case (with the SD card not accessible)
- The s-video output sticks very far out, you basically have to solder it out if you want to put the rbpi into a reasonably small enclosed case and you don't want to use s-video.
- The board is powered using a microusb connector. It's somewhat mysterious why it doesn't use a more standard power connector like the arduino in particular because the microusb connector is very brittle compared to the arduinos, it doesn't have any logic attached to it, so it's technically not a valid USB device, and because it draws more power than the USB spec would actually allow you to use. The microusb connector is smaller, but seeing how far the SD card extrudes over the board, no space is saved either way.
- Lack of a real-time clock. Adding a realtime clock requires a lot of space (for the battery), and its lack is probably not an issue for most users, but you probably want to be aware of it. If you are running services that rely on precise timings and the clock behaving linearly at all times, you probably want to connect your own RTC. For all other purposes, using ntpd is probably just fine.
The broadcomm chip allows you to divide the 256MiB of memory between the ARM and the videocore, and can hardware-accelerate OpenGL ES2.0, OpenVG 1.1 and playback of h264 high-profile video (1080p32).
It should be noted that neither PCB layouts nor basic information about things like the pin layout of the broadcomm chip are disclosed, hindering an in-depth analysis of the PCB design and circuit parameters.
The rbpi can be powered using a cellphone-type microusb charger which should have at least 750mA. You can power the rbpi from a USB port in a pinch, but because of the aforementioned problems, it's not a good long-term solution. If you want to connect any USB devices to your rbpi whatsoever, you definitely need to power it from an external supply, as every connected USB device is allowed to draw up to 140mA.
Heat & overclocking
The raspberry pi dissipates up to 3.5W of heat, so it can get decently hot. It's probably not much of a problem in most cases, but if you put it in a completely enclosed case along with other components (especially harddrives), you might want to make some provisions for airflow. You can also put some heatsinks on the SoC and PHY chip, both can get pretty hot during intensive file transfers/encryption/video playback et cetera, in particular if you've overclocked or even overvolted your rbpi. The voltage regulator can get warm, but doesn't seem to produce a whole lot of excessive heat.
The rbpi can be overclocked on raspbian by editing /boot/config.txt, setting the values arm_freq, gpu_freq, core_freq, h264_freq, isp_freq, v3d_freq, sdram_freq, over_voltage, over_voltage_sdram, over_voltage_sdram_c, over_voltage_sdram_i and over_voltage_sdram_p.
By overvolting, the rbpi can be pushed up to 1GHz, but notice that overvolting voids your warranty. Without overvolting, the rbpi can be run stable at 800MHz. It's safe to experiment with overclocking as long as you don't also overvolt; the worst thing that can happen is that it runs unstable. See http://www.senab.co.uk/2012/05/29/raspberry-pi-overclocking/ and http://elinux.org/RPi_config.txt for more details.
The rbpis specs are not open, so programming it is very difficult. The easiest option is to just run linux on it, and then proceed to use the POSIX API, as raspbian ships with some drivers for the peripherals. Writing drivers, however, has to be done through reverse-engineering, rendering the rbpi to be fairly impractical to use as microcontroller. Since the specs are not open (especially the videocore interface), a lot of capabilities of the chip have to go un-used or emulated by other means (such as the on-board CSI and DSI connectors for HD video cameras and video output.) The best bet for programming the rbpi is to simply stay away from the hardware and program normal POSIX-level programs, using APIs provided by linux/raspbian such as alsa et cetera. They will then become better as the drivers start to suck less and less. The raspbian ABI exposes the ARM1176JZF-S vfp natively, so powerful hardware-accelerated floating-point operations can be used directly from any program. Note that this renders raspbian incompatible with debians ARM port (and most of its packages), which per default uses softfloats.
Networking using the raspbian ethernet driver seems to work fine, with high-speed transfers not saturating the CPU too much. Raspbian comes with an openssh server pre-configured, so you can simply connect your device and log in. All other networking services should work as expected. Unfortunately the SMSC (usb-to-ethernet chip) is wired up wrong, having its external bypass capacitor pin connected to the power-supply, causing it to heat up considerably. Temperatures of up to 65°C are to be expected.
The rbpis sound capabilities are extremely limited. It does not have a DAC chip on-board (or, if the SoC chip has one, it cannot be used for legal reasons), so it has to use PWM on a pin with a sigma-delta filter, resulting in horrible amounts of white noise and clipping. Playing notification and system sounds through the jack audio works, but listening to music through it without constantly grinding your teeth is pretty much out of question. HDMI audio did not work out-of-the-box with raspbian, and I did not make any effort to get it working (as I don't need sound for my use-case), but other people have reported it to work fine. Unfortunately, adapters that can extract the sound out of HDMI are extremely expensive (way more expensive than the rbpi itself) since they require complex high-speed logic inside them, as well as DAC chips (HDMI transmits the audio in periodic packages interrupting the video stream, so any converter has to run at very high speeds and be able to parse the actual video stream in order to demux the audio. So if you are planning to use the rbpi as some sort of jukebox, the only practical option is to buy an external USB soundcard.
Previous versions of the rbpi exposed I²S which could be used to connect external sound DACs, but it has been removed in current versions.
Using the rbpi with openbox through the HDMI port works fine, but as mentioned previously, HDMI audio did not work out-of-the-box with raspbian.
The rbpi model B has two USB ports, and each is apparently able to provide up to 140mA (though, again, no official documentation is available on anything, so no definite specs on anything) The USB host controller seems to be completely unaware of that, however, and gladly selects USB configurations that require it to provide up to 500mA, leaving devices like external harddrives that aren't self-powered in a constant state of crashing-ness. If you're planning on connecting anything to the USB ports beyond mouse and keyboard, you definitely want to provide a powered hub. Don't attempt to connect anything to the USB ports when you power the rbpi from another USB port.
The GPIO pins are programmable from user-land using a few ugly hacks (helpfully encapsulated into libraries for python & co), so for low-speed application you can simply bitbang them from any python program. If you need reliable timings, you probably won't get around either patching your kernel to have real-time support, use the hardware-timer or write a kernel driver. This way, the VideoCore accessing memory, interrupts et cetera can still stall your code, but the preemption overhead & interrupts will go away, making your timings significantly more precise. The rbpi has a double pinheader connector with 26 pins, of which 8 can be used for GPIO. The rest exposes I²C, SPI, a generic UART as well as 3.3V, 5V and GND. The most notable property is that the GPIO pins are not 5V tolerant and have no ADCs; so a lot of extra circuitry for protection as well as ADC chips are required to achieve setups that can be done without any using arduinos. Don't try to connect a load or a relay (inductive load) directly to it, that will blow the rbpi up immediately. The safest and easiest route if you don't want to blow up your rbpi is probably to just connect an atmega (or arduino) chip to your rbpi and let it handle the low-level communication -- that also has the advantage that you have precise control over timing and latency, without writing a driver.
The rbpi has a lot of problems both on the hardware and software-side, but for the low price there's pretty much no reason not to get one, even if you'll just end up using it as torrentbox, storage device, webserver or somesuch. For serious projects, the BeagleBone is pretty much superior in all respects, and it doesn't restrict what kind of functionality you can look at and use; but the price-tag is a bit harsh. Another option could be the Cubieboard, which has a 1GHz CPU and 1GiB of RAM, 96GPIO pins and an SATA port in addition to (apparently) all the features the rpi also has, with a pricetag at $50 -- but it isn't out yet, so there isn't really a lot of data on the quality of the various parts like the DAC. The rbpi is not very well-suited as arduino replacement because of it's weak GPIO/ADC capabilities, but if you really need the processing-power/ethernet port/usb host/etc, a raspberry pi can triple as as cheap replacement for an arduino ethernet-shield, power-supply, usb host shield, etc simultaneously.
If you are planning to use the rbpi as jukebox, gaming console or desktop PC, you definitely want to supply it with an external sound-card, a powered USB hub and some usb mass storage device, as SDHC cards with high storage capacity are fairly expensive.
Things I'd like to see added in the next revisions:
- A proper DAC for sound, anything is better than 1-bit PWM sound!
- (and/or) getting back I²S
- power-over-ethernet would be nice to have
- more power for the USB ports, USB host controller needs to be less stupid about power mgmt
- revamped PCB layout with less protruding parts. Maybe drop the SD card in favour of microSD or so
- Is the s-video connector really necessary? I'd prefer to get rid of it, it's a bitch to unsolder...
- Use an TI OMAP SoC rather than a broadcomm BCM so that the rbpi can be properly programmed and used as MCU