testing gpio with node.js and onoff

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.

raspberry pi, weekend edition for 9 feb

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 test.py 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 ArchLinuxARM-2014.02.08-rpi-base08G.zip 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 rchLinuxARM-2014.02.09-rpi-twm08G.zip 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.