After months of anticipation my Raspberry Pi (RasPi) arrived last week. So I spent a little bit of time putting it through its paces. After waiting for the last couple of months I had a short list of things I wanted to test immediately:
First order of business was to boot up and try out the various distributions currently offered. On first boot I was a little disappointed to find the RasPi had a few issues with my SD card. When booting the Debian distribution I saw lots of errors when booting. The errors were “
mmc0: Too large timeout requested for CMD38!” which I believe are to do with the time the card takes to erase blocks. The card was one I bought very cheaply at a market when I was on holiday in Italy a few years ago so I wasn’t that surprised to see it fail. When I switched to a newer card it behaved normally and the errors disappeared. The SD card images are available from the Raspbery Pi downloads page via bit-torrent.
This is the recommended install and comes with an X-Windows GUI using a fast, light-weight desktop environment (called LXDE). The image booted into the standard text mode login prompt. After logging in I started the GUI by typing
startx. I was a little surprised to find the ssh server not running by default but that was easily fixed. As I don’t have any HD TVs around, the composite video output works fine but its not ideal to do command-line work. By starting up ssh I’m able to login and develop on the RasPi using my laptop or other computer.
To start the ssh server for the current session you can type the following into the command prompt via a USB keyboard:
sudo service ssh start
To ensure this service is started every time the RasPi is powered up type the following:
sudo update-rc.d -f ssh defaults 20
I also installed a couple of utilities for later testing out the RasPi:
sudo apt-get install screen sudo apt-get install minicom
Other than the ssh daemon not being run at boot and having to login and manually start the GUI this distribution behaved as I expected. It’s standard Debian and behaves as such, being able to apt-get anything I tried from the repositories without problems.
Arch Linux ARM
I’ve not worked with this distribution before so didn’t do much more than boot up and see what was installed. As expected this booted into text mode as there is no GUI installed at all. As ssh was running and the Ethernet interface was working out of the box I was able to log in remotely and poke about without any problems.
This is a very basic install, without even another user other than root. I like this cut down system as it seemed very fast with a low memory (both RAM and SD card) footprint. It looks like it will be a good starting point for an embedded server project. Having no experience with the pacman package management system I didn’t investigate very much at all, but think I think I will have another look at this distribution in the near future.
The QtonPi image was the largest of the three images to download, but that is because as well as an image for the SD card it also contains the cross-compilers needed to develop for embedded Qt on ARM via your standard x86 Linux machine. In addition to the compilers and Qt libraries it also contains tools for making new SD card images.
This image is based on Fedora 14 and booted into the console as with the previous two images. This distribution also didn’t have an ssh server running by default. To get ssh working on I needed to bring up the ethernet interface by typing:
After getting this sorted I was able to ssh into the RasPi. To ensure this happens every boot I edited the file
/etc/sysconfic/network-scripts/ifcfg-eth0, changing the
ONBOOT option to
I also changed my timezone by doing the following:
mv /etc/locatime /etc/locatime.original ln -sf /usr/share/zoneinfo/Europe/London /etc/locatime
This is helpful when looking through logs or trying to figure out what files you just changed.
Like the Arch Linux image previously mentioned this distribution also had no X-Windows GUI installed. This image is designed to use the Qt libraries to draw direct to the framebuffer. This is great for embedded systems as you don't have the overhead of a full X-Windows installation.
After following the QtonPi "getting started" instructions from here I could not get the Qt5 "Hello World" example to do any more than produce a white screen. Poking about the system I found some examples already on the card. Some of these "segfaulted" when run while others appeared to have the framebuffer off-centre and while displaying a little text, would not operate as intended.
The workflow for this project seems very nice and well thought through. Developing on the host and then automatically running on the target seemed very slick from within the QtCreator IDE. I look forward to working with it as the Qt5 platform matures.
NOTE: the QtonPi wiki pages seem to be moving about so here is a link to the Google cache version of instructions I followed.
The second order of business now that I had an operating system was to get a case printed. I chose v12 of "thing" 16104 with the large Raspberry Pi themed ventilation holes. It printed okay but it took a couple of attempts with slic3r to get it to slice the thin walls correctly.
I also needed to move a couple of the connectors to make things fit nicely. I did this the old fashioned way with a file and knife but altering the OpenSCAD model looks pretty straight forward, so I'll probably do that before I print more cases for other people.
USB Serial Drivers
Third on my hit list was to check the drivers are present to talk to my RepRap 3D printer and other serial bits and pieces I have lying about. Both prolific USB to serial (PL2303) and FTDI seem to work fine. I didn't test the devices thoroughly, I simply noted that the drivers was installed and new
/dev/ttyUSBx device was created when I plugged them in. I'll probably look at using the GPIO to control my RepRap and other electronics directly but for the immediate future, serial comms to an Arduino will do just fine.
General Purpose I/O (GPIO)
Last on my list was GPIO. I would like to use the RasPi as a real-time controller in embedded systems so I am quite curious to see if I can do anything useful with the GPIO. Later I plan to use it to drive the RepRap directly so I can repurpose my Linux machine in the workshop to do greater things without interrupting the printing process.
While using the information from http://elinux.org/Rpi_Low-level_peripherals I wasn't able to get anything to happen on the GPIO but as this was a late night investigation I'll assume there was something simple I overlooked.