Category: ARM

raspian pixel

whbeebe

Just a quick entry about Raspian Pixel, the latest Debian-based distribution for the Raspberry Pi. In this entry, I have it running off of a 32GB microSDHC card, a Sandisk Ultra Extreme with an 80MB write speed, plugged into the Raspberry Pi 3. The Pixel desktop is something of a minor wonder, a reasonable graphical desktop that isn’t glacially slow. This entry is being written on the Pixel desktop within Chromium “Version 51.0.2704.91 Built on Ubuntu 14.04, running on Raspbian 8.0” according to the about screen. I’ve been dabbling with some of the more current distributions lately, specifically Raspbian and Fedora 25 for ARM.

Raspbian Pixel is a nice, clean, reasonably fast distribution for the Raspberry Pi 3. My only real complaint is that Raspbian, like Arch Linux ARM and Fedora 25, is still compiled for 32-bit ARM, not 64-bit. Other than that I can’t really complain. If anything, I have high praise for Pixel, especially its inclusion of Chromium/Chrome. Everything on the web I’ve attempted to view on Chromium renders as well as a regular Chrome on Windows, macOS, and Ubuntu. It handles multiple tabs, although with the limited memory on the RPi 3 I make sure to have as absolutely few open as possible.

I won’t be able to do anything of significance until after Christmas. But with a decent version of Raspbian on one of my RPi boxen, I now have a reference installation that will allow me to check to see if any of my more esoteric projects failures are due to me or the fact that Arch Linux doesn’t fully support what I’m trying to do.

Unfortunately, Fedora 25 has taken the place of the older versions of Raspian as the slowest, least usable distribution you can install on the Raspberry Pi 3. “Glacial” doesn’t even begin to describe how slow it is. After 30 frustrating minutes of dealing with “did it crash or is it just that slow,” I installed Raspbian Pixel over the top of it and moved on. I’ll admit Fedora looks pretty, but that’s no reason to keep it around. Ugly but highly functional will always beat pretty but slow as molasses in a New England winter. If you’re reading this and trying to make a decision, take my advice, and install Raspbian Pixel. Don’t even waste bandwidth and diskspace on Fedora 25 for ARM.

blinkin blue leds with ruby

whbeebe
#!/usr/bin/env rubyrequire 'rpi_gpio'def initRPi::GPIO.set_numbering :bcm[17,18,27,22].each do |pin|RPi::GPIO.setup pin, :as => :outputRPi::GPIO.set_low pinendenddef cycle[17,18,27,22,27,18].each do |pin|RPi::GPIO.set_high pinsleep (0.25)RPi::GPIO.set_low pinendendinit(1..9).each{ cycle }RPi::GPIO.reset

This is the Ruby version of my Cylon LED test cycler that I’ve written in various languages on Arch Linux and the Raspberry Pi. This time it was Ruby’s turn to see if I could use it to manipulate the various I/O subsystems on the Pi. Since setting output pins to drive LEDs is the easiest place for me to start, I wrote the code you see above. Before I could make it work I had to install the rpi_gpio gem. To get some idea of how to use it I looked at the GitHub repository for rpi_gpio. The reason for this is to be able to bridge between the Ruby on Rails work I started earlier this week with both input and output I/O. The only other comment I will make is to make sure that the udev rules have been set up to manipulate the I/O as a regular user. Trying to run the code shown above as root will fail, as the installation of rpi_gpio was local to a regular account, not globally installed.

My only comment on rpi_gpio so far is this: I discovered I had to code a set_low immediately after every enabling of a pin as an output, as the pin was enabled high. I consider this a bug, and as it stands it may not be suitable for what I need. If even a microsecond pulse goes out from those pins after being enabled by Ruby then that’s enough to cause a false start on that pin. The Ruby code isn’t something to write home about, just something to do some very basic testing.