Archives For February 2014

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.

I’ve been working with Node.js on the Raspberry Pi, particularly with regards to the web application framework Express and the page template engine Jade. My past experiences with web tools like these goes back to the late 1990s with Microsoft’s early IIS and ASP pages, IE 4, msxml 0.8 and Microsoft’s initial Dynamic HTML implemention, through plain old Apache 1.0 with Perl, to Tomcat and JSP pages and Ruby on Rails to Node.js and Express and Jade with a side trip to EJS.

I’ve been following a tutorial titled “Creating a basic site with Node.js and Express” to create an initial application. Interestingly enough, even though the tutorial was written back in April 2011, it was still reasonably up to date. I had one deprecated call in app.js (replacing “app.use(express.bodyParser())” with “app.use(express.json())” and “app.use(express.urlencoded())”) and one error in a Jade template file (replace “!!! 5” with “doctype html” in views/layout.jade). Once those minor fixes were in place I was able to start up my very simple Node web server and have it deliver the sample page (see below) to my various home devices on my internal home network. You see a screen capture on the Nexus 7 2012 running Opera. If I’m going to use Node on my R-Pi, then I’m going to make full use of it. The screen capture above shows the system resources via htop in the upper left window, and the simple Node application with logging running in the upper right window.

As usual everything is behind a firewall.

My reason for digging into this part of Node is to build a web interface into the i2c and onoff Node modules, and thus the Raspberry Pi’s I/O capabilities. My next release of my Arch Linux image will contain all of this (though not necessarily the final web interface into the Raspberry Pi’s I/O), hopefully this weekend. I will only update the graphic image, not the base image.

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.

latest twm configuration

February 17, 2014

My (near) final twm desktop. I promise. Desktop is tiled with a paisley grey pattern to give it a subtle texture and depth, and to make it easier on the eyes over long periods of time. It’s better than a pure black or even a pure gray color. I’m using Saddle Brown and Sienna everywhere else (those are real X11 colors). What follows is my .twmrc file, complete with comments. Yes, it’s old school (how about 20 years old school?). For the full details check the twm(1) man page.

Here’s some of the features I’ve enabled so far:

  • Default icons on the title bar are gone now (via NoDefaults). I use my own icons, and now have a close window directly on the title bar.
  • The resize icon is now on the far left corner of the titlebar, the kill window on the far right. There’s also a minimize and maximize button now. This makes window control a bit more contemporary.
  • The titlebar highlight is gone (NoTitleHighlight)
  • The titlebar looks like BeOS window decorations (SqueezeTitle)
  • Cursor movement now pops the window up to the top automatically (AutoRaise)
  • Borders are much larger and the whole looks a lot like Microsoft’s Windows 8 Metro (BorderWidth 4)
  • When you move any window, the contents move as well instead of the nearly invisible outline (OpaqueMove)
  • The desktop menus make more sense, especially left mouse button click on the desktop (see screen capture above)

And here’s my .twmrc

# Modified wbeebe 16 February 2014

AutoRaise {


TitleFont "10x20"
ResizeFont "9x15"
MenuFont "10x20"
IconFont "10x20"
IconManagerFont "9x15"

BorderWidth 4
MenuBorderWidth 3
# Show window contents as you move the window. This does not
# have the same effect on resizing.
# Show the icon manager on the desktop. It's size and location
# are defined in .Xresources.

# Define which desktop applications won't have
# title bars. Remember that without a titlebar
# you can't easily close it,resize it, or iconize
# it.
NoTitle {

# Now define which cursor will appear as the the mouse
# cursor passes over different parts of the X-window
# The cursors are all part of the cursor font and can
# be displayed with the command:
# xfd -fn cursor
# The list of cursor names can be accessed by looking at
# /usr/X11R6/include/X11/cursorfont.h on Spiffy
# /usr/lpp/X11/include/X11/cursorfont.h on morgana
    Frame   "left_ptr"
    Title   "left_ptr"
    Icon    "left_ptr"
    Iconmgr "left_ptr"
    Menu    "left_ptr"
    Button  "hand"
# This hand feature moves the cursor into the center of
# a window that has been de-iconified.

# Add buttons to a window's titlebars
# First, remove the defaults from the window titlebars.
# And get rid of the annoying titlebar hightlighting effect.
TitleButtonBorderWidth 2
# I like SqueezeTitle. The titlebar only occupies as much space as needed.
# Reminds me of BeOS.
# If you want to have standard titlebars, remove or comment out this line.
# Now add our buttons.
LeftTitleButton     "~/twm/icons/resize.xbm" = f.resize
# Note that declarations are from left to right in the order they'll
# be displayed on the right upper corner.
RightTitleButton    "~/twm/icons/minimize.xbm" = f.iconify
RightTitleButton    "~/twm/icons/maximize.xbm" = f.fullzoom
RightTitleButton    "~/twm/icons/close.xbm" = f.delete

Color {
    # Colors that I've experimented with
    # 305030 - green
    # 203020 - darker green - unselected border
    # 406040 - another green

    BorderColor          "Sienna"
    BorderTileBackground "SaddleBrown"
    BorderTileForeground "SaddleBrown"

    DefaultBackground   "#E6E6E6"
    DefaultForeground   "#000000"

    TitleBackground     "Sienna"
    TitleForeground     "#e6e6e6"

    MenuTitleBackground "#ff4500"
    MenuTitleForeground "#e6e6e6"

    MenuBackground      "#C0C0C0"
    MenuForeground      "#414D5B"

    MenuBorderColor     "#ff4500"
    MenuShadowColor     "Gray"

    IconBackground        "Firebrick"
    IconForeground        "White"
    IconBorderColor       "Firebrick"

    IconManagerBackground "Sienna"
    IconManagerForeground "#e6e6e6"
    IconManagerGeometry   "=300x250-0+0"

# Define some useful functions for motion-based actions.
MoveDelta 3
Function "move-or-lower" { f.move f.deltastop f.lower }
Function "move-or-raise" { f.move f.deltastop f.raise }
Function "move-or-iconify" { f.move f.deltastop f.iconify }

# Mouse button bindings. Button 1 is the left button,
# Button 3 is the right mouse button.
Button1 = : root : "applications"
Button3 = : root : "desktop_ops"

Button1 = m : window|icon : f.fuction "move-or-lower"
Button3 = m : window|icon : f.function "move-or-raise"

Button1 = : title : f.function "move-or-raise"
Button3 = : title : f.raiselower

Button1 = : icon : f.function "move-or-iconify"
Button3 = : icon : f.iconify

Button1 = : iconmgr : f.iconify
Button3 = : iconmgr : f.iconify

# Desktop Operations menu
menu "desktop_ops" {
"TWM Functions"	f.title
"Force Move"    f.forcemove
"Raise"         f.raise
"Lower"         f.lower
"Zoom"          f.zoom
"Full Zoom"     f.fullzoom
"Identify"      f.identify
""              f.nop
"Kill"          f.destroy
""              f.nop
"Swap Screen"   f.warptoscreen "next"
"Focus"         f.focus
"Unfocus"       f.unfocus
""              f.nop
"Refresh"       f.refresh
"Restart"       f.restart
"Read twmrc"    f.twmrc
"Version"       f.version
""              f.nop
"Exit"          f.quit

# Application menu
menu "applications" {
"Applications"  f.title
"Terminal"	!"xterm &"
"MEdit"         !"medit &"
"Xload"         !"xload &"
"Oclock"        !"oclock &"
"Xlogo"         !"xlogo &"
"Xeyes"         !"xeyes &"
""              f.nop
"Show Icon Manager"  f.showiconmgr
"Hide Icon Manager"  f.hideiconmgr
""              f.nop
"Raise"         f.raise
"Lower"         f.lower
"Iconify"       f.iconify
"Resize"        f.resize
"Move"          f.move
"Delete"        f.delete
""              f.nop
"Exit"          f.quit

My .Xresources file:

XTerm*local: true
XTerm*foreground: white
XTerm*background: black
XTerm*font: 9x15
XTerm*scrollBar: true
XTerm*rightScrollBar: true
XLogo*geometry: 150x150
oclock*geometry: 150x150-0-0
oclock*background: Gold
XEyes*geometry: 250x135
XLoad*geometry: 250x140
XLoad*foreground: white
XLoad*background: black

And my .xinitrc file:



# merge in defaults and keymaps

if [ -f $sysresources ]; then
    xrdb -merge $sysresources

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap

if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"

# Look for default system-wide applications to
# start. This is left as an historical reference.
# You should start programs in the local .xinitrc
if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 unset f

# Set default desktop cursor to arrow instead of 'X'
xsetroot -cursor_name left_ptr
# Set the desktop background, either a solid color
# or a tiled image.
# xsetroot -solid steelblue4 &
xv ~/twm/tiles/black_mosaic.jpg -root -quit
# Switch off default beeps
xset -b

# Start some default applications.
exec xterm -geometry 80x20+0-0 &
exec xterm -geometry 80x40+0+0 &
exec oclock &
# Launch twm. This should be the last thing you do,
# and it should be execed. This allows f.quit in
# the TWM menus to work, instead of using something
# crude like 'pkill x'
exec twm

I have not included my icons directory or their files. I’ll probably check all those into Sourceforge along with the images in the near future. But I have reached a point of diminished returns. It works and looks pretty much the way I want, and is reasonably fast, much faster than a contemporary desktop environment.

I’ve been working to get my Raspberry Pi’s Arch Linux software fully configured for the last three weeks. This past week I worked to find either a better solution for twm, or a better configuration for twm. I also worked to add more software to manipulated and control the I2C and GPIO peripherals.

I upgraded Arch Linux for Raspberry Pi to the current repository release as of 16 February 2014.

I tried a number of light-weight window managers, two of which were fvwm and gnustep. In the end I went back to twm and started to find ways to configure that environment. Pi’s twm environment now has simple icons and background tiling, as well as colors other than dark red and black. The color styling is now around blues and greens, with very small primary colors to pick out important information (see vi above). I’ve spent enough time configuring twm and installing a few more X applications.

I have too many icons on the window bar. I need to dig a little deeper to trim off the ones I don’t want and keep the ones I like. That’s the last task before I declare victory and move on.

This week I installed node.js native bindings for I2C and GPIO. The packages were i2c and onoff. The largest window shows the installation of onoff (npm install onoff). I’m now to the point where I’m beginning to do simple wiring of devices (LEDs, switches, and FETs) to the various digital inputs and outputs. I’m looking for an inexpensive I2C device that I can use for later projects to test that.

I’m also looking at picking up a pair of BeagleBoard Black cards. Arch Linux supports those cards as well.

I’ve run into a problem with using SDHC cards. The file systems on two cards are beginning to behave oddly. What follows is the output captured via dmesg after the event was noticed by me.

[   30.078810] EXT4-fs error (device mmcblk0p5): ext4_mb_generate_buddy:755: group 19, 18079 clusters in bitmap, 18080 in gd
[   30.106892] JBD2: Spotted dirty metadata buffer (dev = mmcblk0p5, blocknr = 0). There's a risk of filesystem corruption in case of system crash.
[  303.846051] EXT4-fs (mmcblk0p5): error count: 4
[  303.846092] EXT4-fs (mmcblk0p5): initial error at 1392587916: ext4_mb_generate_buddy:755
[  303.846114] EXT4-fs (mmcblk0p5): last error at 30: ext4_mb_generate_buddy:755

This concerns me because I don’t fully understand what is happening. This is the second time I’ve seen this. I saw it first while using a Samsung 16 GB microSDHC UHS-I Pro card. The second time was with an older Toshiba 8 GB SDHC UHS-I card. I have concerns using SDHC cards as file systems with a Linux system, especially ext4. This is the limitation of a $35 computer card. They’re great and they’re certainly inexpensive, but no matter how advance the technology, you get what you pay for.

I may be time for me to investigate the use of Android for Raspberry Pi.

Update 17 February

Checking online, it looks like this might be a kernel bug as much as a problem with SDHC cards. Kernel version currently being used for ARM Arch is 3.10.


Look towards the bottom of the bug report. I didn’t start to see this until the latest Arch update, which included a new kernel and firmware. Maybe it’s time for me to start building kernels again, moving to the latest, which is 3.13. I know that 3.10 is labeled as long-term, but still.

In any event I won’t release a new image until I’m sure the problem is fixed one way or the other. At least, not a new image with kernel updates. I’m planning on reflashing today with the 9 February image and adding all my changes to that, in particular the node.js i2c and onoff extensions.

Update 2, 17 February

Looks like file system error was self inflicted. Plugged the card back into the Ubuntu notebook and ran fsck on /dev/mmcblk0p5 (/dev/sdb5 under Ubuntu). There was a reported bitmap difference of -127301, a free block wrong count for group #3 (651, counted=652) and a free block wrong count for group #19 (17504, counted=17503). Once those were fixed Arch booted just fine on the card. I am assuming this miscount occurred when I expanded the original 2 GB file system to 8 GB with gparted. I think in the future I need to run fsck on any file system I modify in that way. It means that every other image I’ve pushed up to Sourceforge also has this flaw. Once I finish testing node.js with i2c and onoff (GPIO) on this latest image I’ll push up the latest compressed image and replace the two currently there. It’s not a fatal problem, but it needs to be corrected none-the-less.