Category: Arch Linux

new raspberry pi computers and other news

whbeebe


When the Raspberry Pi foundation announced the release of the new Raspberry Pi 3 Model B+, I ordered two from element 14 (element14.com). They were the only vendors at the time who had them in stock for the standard price of $35. When I received them I discovered that when they say the 3B+ needs 5V/2.5A, they really mean 2.5A, not 2.4A like I’d been using before. So I went back online and order a pair of new power supplies, along with two Samsung PRO Plus microSDHC 32GB cards. I also discovered via the dreaded red flashing power LED (four flashes) that the older Samsung EVO+ 32GB microSDHC cards would not boot the 3B+ fully. I don’t know why as they work just fine on every other earlier Raspberry Pi I own, up to and including the prior 3 Model B. Interestingly I didn’t have boot issues with any of the SanDisks I was using, just that particular card brand and model.

I also ran into an issue updating all my Arch Linux ARM Raspberry Pi systems. They all failed to update (pacman -Suy), and they all failed when attempting to get the catalog from the community repository. A bit of checking on the official Arch wikis turned up nothing. This isn’t the first time I’ve faced this update failure and been forced to reinstall Arch as a consequence. This time, rather than reinstall Arch, I decided to switch completely to the “official” Raspberry Pi distribution, Raspbian.

Raspbian has undergone considerable polish over the last 12 months, to the point where I can easily live within the Raspbian graphical desktop. The desktop has a very nice file browser, terminal, and the Chromium browser is now up-to-date with equivalents across all operating systems. I installed Raspbian by pulling down the image file and using Etcher, all of this on my Ubuntu 16.04 notebook. It’s extremely easy to load-and-go with both Raspbian and Etcher. Before I wiped and reloaded, I made full backups of the older /home/alarm home directories to pick up all my earlier work, then copied them back to the pi account home directory via a separate folder.

With Raspbian everything seems to be working just fine. I was even able to start this post on the older Raspberry Pi 3 Model B using Chromium, although I finished the post on my Mac. I had to transfer a photo I took using my iPhone via Google Drive, and I could have done it on the Pi, but I’m a Mac addict, and I wanted to run something undisturbed on the Pi.

One test I ran was using the tools I wrote in Python for the Sense HAT. I won’t go into the details of how I got the Arch Linux ARM set up to work, but I will say that Raspbian was already set up out-of-the-box to run my Python code unmodified with the Sense HAT plugged into the board, and without installing and/or configuring any other Raspbian packages. I look forward to moving my C++ based Pi code over.

One other observation: The 3B+ runs warm, much warmer than any other Raspberry Pi. I’ve done nothing to tweak the operating frequency of the board. My advice is to buy the heat sink kit for the Raspberry Pi and attach it to the board.

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.