Not Everything is Easy in the Land of Raspberry Pi
I had the chance to work with my Raspberry Pi some more late last night and this morning. Quite a lot of stuff works, given that the board design is essentially at a state of “ready for the software developers to do their thing”. But some things are not quite there, or behave oddly.
My first boot-up that I talked about was on a bench without networking. That turns out to be significant. When I tried to run my RasPi with the full load of peripherals in the USB hub and also have the wired Ethernet on, I got a lot of “kevent 4 may have been dropped” error messages and no network connection. The canonical answer on the RasPi forum is that this is a power supply issue, where marginal power to the board means there isn’t enough to properly run the Ethernet circuitry. Some respondents have noted that their circumstances don’t fit into that neatly. I suspect that I may be joining them, but I have some more experimentation to do before saying so categorically. My get-it-working solution so far is to run the RasPi off a dedicated power supply and have all the peripherals on a powered hub. This isn’t ideal for something I hope to deploy remotely. I need to figure out really reliable, comes-up-on-power-on every time configurations.
I spent entirely too much time dealing with something that I should have caught early. The RasPi is a UK invention, and its default settings are convenient for people in the UK. I have a firewall here, and I set my RasPi to enable SSHD so I could login over the net. I logged in from an Ubuntu box and changed the “pi” user password to something approaching a strong password, you know, one with odd case, numbers, and symbols. That’s all to the good, but then I rebooted and ran into the network interface being offline. Fine, I thought, I’ll login directly. But I couldn’t, because no matter what I did, I could not generate one of the symbols in the new password from the directly-connected keyboard, not even with alt-codes. Stripping the RasPi down to just power and network allowed it to boot and establish the network interface, and I could login once again from a remote computer. I changed the password to avoid the bad symbol and worked on localization. The involves “dpkg-reconfigure” applied with three different targets, the keyboard, the locale, and the timezone.
I’ve been able to install a batch of additional software. I installed Cmake and libncurses5, then tried building Avida on the RasPi. The Avida build doesn’t get far. tcmalloc apparently is known to have build issues on ARMv6, plus multiple classes got an “out of virtual memory” error. That still holds with the boot switched to the 224MB main memory setting. But python-scipy and python-gps installed without issues. I even installed VLC to check if the final piece of a media center was anywhere close to done. While the VLC and its dependencies went on without complaint, plugging in a USB DVD drive and pointing VLC at it did not go much of anywhere. There was no continuous playback, and if I changed the media pointer, it would display a single frame. I think that the color rendition was off, but I had plugged in a movie that I hadn’t watched yet, so it is just possible that the cinematographer thought a strange palette would be a good thing.
I tried out my USB GPS dongle. I installed “gpsd-clients” and ran cgps, which reported … absolutely nothing. That was disappointing. I plugged the GPS into my Ubuntu box, and cgps happily displayed a fix and chatter from the dongle. I went back to the RasPi, stopped gpsd, then used gpsmon. That displayed a fix and messages from the dongle. So I’m not sure why gpsd on the RasPi is doing things differently than on the Ubuntu box.
For those pulling up “Geany” to do some Python scripting, you’ll need to change the preferences so that the terminal of choice is not “xterm”, but rather “lxterminal” (this is for Debian Squeeze).
That’s it for now. I’m expecting to have to repeat this process whenever a new version of the operating system is released, so a set of notes on what gets done seems in order.
Notes on RasPi
sudo nano /etc/resolv.conf
sudo dpkg-reconfigure keyboard-configuration
sudo dpkg-reconfigure locales
sudo dpkg-reconfigure tzdata
Additional python modules:
sudo apt-get install python-scipy
sudo apt-get install python-gps
WiFi dongle —————————————–
Add to /etc/apt/sources.list:
deb http://ftp.us.debian.org/debian squeeze non-free
sudo aptitude update
sudo aptitude install firmware-atheros
sudo wget http://wireless.kernel.org/download/htc_fw/1.3/htc_9271.fw
sudo wget http://wireless.kernel.org/download/htc_fw/1.3/htc_7010.fw
One thought on “Not Everything is Easy in the Land of Raspberry Pi”
I came across a discussion thread that clarified the GPSD issue. GPSD on the Debian Squeeze platform needs configuration. This can be done with
sudo dpkg-reconfigure gpsd
Plug in the device name for the attached GPS device and accept the defaults elsewhere, then reboot. CGPS comes up with data for me now.
A fly in the ointment is that GPSD is something of a CPU hog. I’m getting values of 12 to 30 percent of CPU time being used by GPSD while CGPS is running. Maybe this is compatible with audio recording and maybe it isn’t. If not, I may reconfigure GPSD to not autostart and just plan to grab strings from the GPS directly.
Comments are closed.