Archives For Parallax

new bits for the raspberry pi

February 26, 2014

Some inexpensive Raspberry Pi supporting components were delivered today from Amazon. They included a pair of Kootek 5V 2A universal micro USB chargers to provide power to the R-Pi boards, a pair of Edimax EW-7811 150 Mbps 11n WiFi USB adapters, and a pair of clear SB Raspberry Pi cases. I also picked up a pair of Samsung PRO SDHC UHS-I cards. I hate to say it, but the Samsung SDHC cards provide the best read and write performance of any SDHC card I’ve used so far (Sandisk and Toshiba are the other two brands I’ve tried). Those other cards are fine in my cameras, but for this use case, Samsung wins hands down. I’m also happy with the Edimax WiFi adapters. They worked first time and allowed me to move off the wired network cable I’d been using (into a hub and WiFi repeater).

I thought I was also going to get some newer and better connecting wires, but Amazon said, basically, they couldn’t ship the parts. I got on Amazon tonight and ordered a different vender’s (along with some more bits and pieces). Hopefully they’ll be in by Friday (the whole order qualified for Amazon Prime).

Before putting the R-Pi cards in their new enclosures, I’d tried the much larger and looser red Bud enclosure. While it certainly gave a lot of room, it didn’t hold the card stable, and this was a problem, especially when removing the SDHC card from the bottom edge.

The Bud case was great for using clips on the connector, but in the end I’ve decided to use the better fitting SB case and use a better way to connect to the on-card connector. Live and learn.

One other lesson learned: never buy from Radio Shack again. I went there for the clips and wires, but they charged far more than I thought it was worth. The store staff were nice and the service was nice, but The Shack can’t compete against Amazon, unfortunately. There’s two other on-line stores that sell Arduino and R-Pi components, and I’ll be trying them out in April. Along with Parallax. Especially Parallax.

One Reason Why I’m Doing This

I have all sorts of reasons for doing this, from the noble to the ridiculous, but one very good reason can be summed up as performing “miracles with minimals,” a phrase I hadn’t heard in a long time until I ran across it while reading an article on The Space Review (Rocket science on a shoestring). Over the decades we’ve gotten so spoiled by ever increasing processing power, and unfortunately, power consumption. Right now, for $35, I have on a credit-card-sized circuit board a computer that rivals what I had back around 1996, an SGI Indigo2. The Indigo2 I had was the first generation in the teal case. It came equipped with a 200MHz R4400 MIPS, 256MB of very expensive memory, and a 36GB hard drive (which was and still is a reasonable amount of storage). It ran IRIX, SGI’s version of Unix. It cost thousands. The case was as big as a desktop IBM PC. I loved it.

Here I am, nearly 20 years later, working with a computer that is a fraction of the size, cost, and power consumption of that SGI machine. It’s an ARMv6 architecture RISC (the R4400 MIPS is a RISC chip), with 512MB of memory, a video processor with resolution that matches, if not exceeds, what was in the case, an 8 GB SDHC drive, wireless networking, 1920 x 1080 resolution with 32-bit color, etc, etc, etc. And it runs cool to the touch. And I love it, for the same essential reason I loved that SGI.

The fact that it runs at room temperature and is cool to the touch is mind boggeling.

We take so much in resources these days. We’ve become so fat and spoiled (present company included). It’s good to be reminded I don’t need a kilowatt computer to do interesting work. And it’s good to be reminded just how far technology has advanced over the last 20 years. And why you shouldn’t spend too much (in some cases, way too much) on them. Our software, like ourselves, is way too bloated, having grown fat on massive diets of transistors in the form of memory and transistor budgets that are now in the billions/chip. We really need to back up and rethink how we want to build computers and write software, before we run out of energy to power them and resources to build them. This little R-Pi, with its ARM chip, shows a better way for the future.

Today was a pretty good day playing around with the Raspberry Pi. First thing I was able to do was fix my problem with the SDHC flash file system. That was fixed with fsck. See the updates from 16 February.

The second was to test the node.js module onoff. I ran the straightforward tests using my Parallax Propeller Professional Development Board. I flashed a few LEDs and pressed a button on the board simply wired into the Raspberry Pi’s GPIO header. You can see the run above.

One interesting issue seems to be the switch inputs (GPIO 18/pin 12). The switch inputs need debouncing, either in hardware or software.

But those are issues for another time, another experiment. Right now I’ve regained confidence in the overall board and its software. And for me that’s a very good thing.

My Arch Linux Raspberry Pi images were updated and uploaded to Sourceforge this weekend. The lead-in image is a screenshot of the TWM desktop running a colorized VM in an xterm and emacs. You’ll note that the colors and general look and feel are tweaked a bit.

This weekend I added additional functionality to my Raspberry Pi; the ability to manipulate the GPIO through RPi.GPIO. This meant updating the base image with more development tools as well as downloading and installing RPi.GPIO from its Sourceforge repository. I’ve had very little time to test it; the only test I’ve conducted so far is using that’s part of the RPi.GPIO source bundle.

The base image started with the Groundhog Day base image had the following actions performed:

  • removal of regular vi and its replacement with vim via softlink;
  • update of system to Arch Linux for Raspberry Pi as of 8 Feb 2014;
  • addition of git;
  • addition of more development tools, especially for Python 3;
  • addition of RPi.GPIO 0.5.4.

That running image was copied back and compressed (zipped) into where it was uploaded to the Rubus Project on Sourceforge.

I then took the base image and duplicated it on another card where I installed Xorg and TWM. This installation was meant to be cleaner than the Groundhog Day image release, having learned a bit over the past week. In particular I did not install lxde.

The graphical system consisted of the base image plus:

  • xorg
  • xorg-xinit
  • xorg-twm
  • xterm
  • xorg-oclock
  • xorg-xlogo
  • xorg-xeyes
  • xorg-xload
  • xv
  • medit

The pi account also has proper local .twmrc, .xinitrc, and .Xresources files. The system X files under /etx/X11 are no longer being hacked. I finally remembered the proper syntax for just about everything that matters. The .vimrc has been edited to enable line numbering and syntax highlighting for vi/vim. There is a .emacs file to configure Emacs to my tastes. You should check this and modify to suit your tastes.

After testing the image was compressed (zipped) as and moved up to Sourceforge.

The usual root and pi accounts are on both images. As always, change the root and pi passwords if you plan on using these images on networks you do not have absolute control of.

I’m now moving on to tying hardware into the RPi. I have a Parallax Propeller Professional Development Board that’s been sitting around in its anti-static bag for years now, purchased when Parallax had a sale on them for less than $100, waiting for me to pull that board out and put it to work. I’ll be using the Parallax board with the RPi to begin my hardware integration. It has a large breadboard, lots of switches, lots of single blue LEDs, and size blue 16 segment displays on the board. It’s for developing the 8 core Propeller Chip, and I have every intention of buying one and integrating that with the RPi. I got lots of crazy ideas…

Oh, two other little things.

  1. I’ve joined the wayland-devel mailing list and I’m lurking at the moment. I want to get Wayland/Weston up and running on my RPi, either through packages, building from sources, or some combination of the two. I’m well aware of the fork of Wayland/Weston to Northfield/Norwood that occured last year, but when I went looking at the Northfield and Norwood git repositories I discovered that nothing has been done on either for nearly a year. I may just give up on Wayland and follow Canonical’s lead with Ubuntu and adopt Mir. Or maybe not. But somehow, some way, I want optimized native support of the RPi’s built-in on-chip graphics hardware.
  2. I’ve switched to using Samsung 16GB micro SDHC I 1, class 10 cards. Why 16GB? Because that’s the smallest I can find locally that doesn’t cost an outrageous amount ($17 + tax). I’ve been using SanDisk and Toshiba 8GB regular cards. Of all the cards I have, I prefer the Samsung for their performance. I’m debating whether the next release will be a 16GB image compressed. I’m already pushing the 1GB upload limit as it is with my current compressed images.

How to Use Either Image

  1. Download either image from Sourceforge (see links in this post or at the top of my blog)
  2. Unzip on your OS of choice. They’re zipped up on Ubuntu.
  3. Plug in an SDHC card of 8GB or larger capacity into your primary computer or notebook.
  4. Copy the unzipped image directly to the flash card. For Linux, use dd.
  5. When finished copying plug the SDHC into a Raspberry Pi. With the RPi connected to a monitor/TV, keyboard and mouse, turn it on. The RPi should boot. Note that a wireless mouse, such as the Logitech M305 or later, will work with the RPi.
  6. At the console login, either login as pi (password pi) or root (password root). You should login as pi and use sudo to work rootly commands.
  7. If you’ve flashed with the TWM image, start TWM by typing ‘startx’ at the command prompt.
  8. Once in the desktop environment, a right mouse button on the desktop will bring up the long command menu (see screenshot above). A left mouse button will bring up a short menu of applications.
  9. The xterms have menus bound to the <Ctrl>Left Mouse and <Ctrl>Right Mouse.
  10. Remember that TWM was chosen for its relatively small footprint. There are absolutely no games or productivity applications. There is no browser. It’s purely a developer’s environment (i.e. editors + development tools and languages).
  11. For further details read the README and wiki on the Rubus Project at Sourceforge.