Adafruit Web IDE

Update: With the IDE installed on two separate pi using the same bit bucket account it seems to share the source code back and forth OK as long as you don't try to use both of them at the same time.

Having tried the manual instructions and failed (see below), I checked the "easy install" shell script and found it had provisions to use port 3000 if port 80 was already in use (e.g. by apache) so I just ran:

curl https://raw.github.com/adafruit/Adafruit-WebIDE/alpha/scripts/install.sh | sudo sh


[verbosity...]
**** Create webide user and group ****
**** Adding webide user to sudoers ****
/etc/sudoers.tmp: parsed OK
/etc/sudoers.d/README: parsed OK
**** Adding default .bashrc file for webide user ****
**** Installing the WebIDE as a service ****
**** (to uninstall service, execute: 'sudo update-rc.d -f adafruit-webide.sh remove') ****
update-rc.d: using dependency based boot sequencing
OK
**** WARNING: PORT 80 IN USE. FALLING BACK TO 3000. ****
**** TO CHOOSE A DIFFERENT PORT USE THE FOLLOWING COMMAND: ****
**** redis-cli HMSET server port 3000 ****
**** AND RESTART THE SERVER ****
**** Starting the server...(please wait) ****
**** The Adafruit WebIDE is installed and running! ****
**** Commands: sudo service adafruit-webide.sh {start,stop,restart} ****
**** Navigate to http://rwspi.local:3000 to use the WebIDE

Then I created a bitbucket account for sellensr based on my google id. I created a couple of files, then did a reboot on the Pi. The apache server still works with rwspi.local and the webIDE with rwspi.local:3000. The files are stored at:

/usr/share/adafruit/webide/repositories

and belong to user and group webide, thus I can't copy files over to there as pi on a vnc file manager screen. Oddly the easy way to move files from ~/pi into the ide is to enable the samba share, then upload the files from the share through the IDE. Odd, but works really well.

I've been doing all this in Safari, which isn't explicitly supported, but seemed to be working OK until I left the IDE and some other stuff broke. Probably best to run the IDE in a supported Chrome window and other things in Safari.

Some of the assumptions I made about directory structure are no longer valid if I move .py files to the IDE, but that shouldn't be a surprise.

webide added itself to the /etc/sudoers file and takes over the hardware. As a result, www-data couldn't use the serial port until I put it back in the /etc/sudoers file.

Trying to do the manual version was a bad plan

Building New Pi Base Images

So what happens if I brick the rwspi SD card? I want to be able to get back to somewhere like where I was, and also to be able to help others get the the same place. So I set out to make a clean install with all the good stuff I've added to rwspi so far, and none of my mistakes or personal data. I got really vexed in the process, because I couldn't get the hardware to work the way it did the first time I set up. The wifi was not behaving. It looks like the upgraded firmware was somehow not working with the old Occidentalis distribution, which shouldn't be a surprise once you get to it. 

So I eventually followed these steps to make a clean image on a 4 GB SD. The wifi worked when it was done. The processing took several hours to complete processing, so I have saved the unpersonalized image as OcciGen130219.img and a personalized version as FreshPi130219.img with my networks and passwords in it. Part of the time was consumed by figuring out that the errors were a result of the Raspbian site being down this morning rather than anything I was doing.

Update: A different wifi adapter requires a reconfig from start, so I repeated the process to create blink130305.img that runs with the B-LINK all black USB wifi dongle.

Also created an OcciClean130304.img image with no wifi installed.

Started from 2013-02-09-wheezy-raspbian.img to create RaspiClean130323.img with all the services below, but no wifi, no wpa file edits. Had to run sudo apt-get install git-core before the firmware update would run properly. Initialized a new blink image from there and added wireless from config utility on desktop. Did the same for an rwspi image.

Feel free to step through the same process to build a copy. I'd share, but I don't have an easy way to share something that big without writing it to an SD.

# make the raw image on SD by running this on the mac (the rest is on the Pi)
# sudo dd bs=1m if=Occidentalis_v02.img of=/dev/rdisk2

# boot with net cable attached and use raspi-config to expand the file system
#      set the keyboard, timezone, enable ssh and desktop, then finish and reboot

# get the latest upgrades
sudo apt-get update
sudo apt-get upgrade

# get the latest firmware, then reboot (needs to be repeated for new Pis)
sudo wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update -O /usr/bin/rpi-update
sudo chmod +x /usr/bin/rpi-update
sudo rpi-update

# use raspi-config to update raspi-config, then set GPU split to 32 MB and reboot


# install samba for file sharing on the network
sudo apt-get update
sudo apt-get install samba
sudo apt-get install samba-common-bin
# set password as 'raspberry'
sudo smbpasswd -a pi
sudo nano /etc/samba/smb.conf
#   Uncomment or change these lines in /etc/samba/smb.conf
#   security = user
#   socket options = TCP_NODELAY
#   [homes]
#   readonly = no
#   valid users = pi

# install the tightvncserver if not already there

sudo apt-get install tightvncserver

# install the apache web server -- it will occupy port 80
sudo apt-get install apache2 php5 libapache2-mod-php5
# mysql password set to 'raspberry'
sudo apt-get install mysql-server mysql-client php5-mysql
sudo service apache2 restart

sudo nano /etc/inittab

# comment out the ttyAMA0 line at the end of /etc/inittab
# T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
# make tty devices available to the web server to use serial port

sudo adduser www-data tty

# install the Adafruit WebIDE -- it will go on port 3000 since 80 is taken
curl https://raw.github.com/adafruit/Adafruit-WebIDE/alpha/scripts/install.sh | sudo sh

# install some python -- some of this may be redundant
sudo apt-get install python-dev
sudo apt-get install python-rpi.gpio
sudo apt-get install python-smbus
sudo apt-get install i2c-tools
sudo apt-get install python-pip
sudo pip install feedparser
sudo easy_install -U distribute
sudo pip install RPi.GPIO
sudo apt-get install python-serial

# get the latest upgrades just to check all up to date
sudo apt-get update
sudo apt-get upgrade

# shutdown and back to the mac to run
# sudo dd if=/dev/rdisk2 of=OcciGen130219.img bs=1m
# then create a new SD with 
# sudo dd bs=1m if=OcciGen130219.img of=/dev/rdisk2

# then back to the Pi and personalize the installation as freshpi.local
# network files copied from rwspi to work with 165 Bagot networks
sudo smbpasswd -a pi
sudo nano /etc/network/interfaces
sudo nano /etc/wpa_supplicant.conf
sudo nano /etc/hostname
sudo nano /etc/hosts
#reboot to be freshpi
passwd 
sudo passwd mysql
tightvncserver :1


# all works, so shutdown and back to the mac to run
# sudo dd if=/dev/rdisk2 of=FreshPi130219.img bs=1m

Pi Progress Tidbits and Serial Communications

Installed the Pi Store App. All went smoothly, but nothing very exciting to be found there... at least for me.

Configured the keyboard using the raspi-config program. Find the layout, then hit return to change the locations of the tilde and get the dollar sign instead of pounds sterling.

Apparently there is no root password created by default, so no root access except via sudo from pi.

Added www-data to the /etc/sudoers file. I'm not sure that's a great idea from a security point of view but it does let php run sudo tasks ;-)     sudo adduser www-data dialout didn't make the serial port available, even though /dev/ttyAMA0 belongs to root and group dialout, but sudo adduser www-data tty did let www-data use the serial port without sudo. This means that the web server can run a program that sends data to and from the serial port to control something else external, like an Arduino. It also means I can take www-data out of the /etc/sudoers file and sudo deluser www-data dialout.

Still have problems with the network dropping overnight. Pi was still running and responding to button pushes. Could it be an overnight timeout thing? Failing to renew DHCP? It was more than just dropping an idle terminal session because I couldn't log back in. It didn't repeat the next night, or the next.

sudo apt-get install libi2c-dev to install the I2C support and then installed WiringPi for the familiar Arduino type interface and the ability to run without root privileges. Installed WiringPi-python for the wrapper. Unfortunately the export process is not getting me control of the pins. I'll need linux geek help with this one I think.

Serial Communications: 

The Pi is 3.3V and other serial ports can be 5 V or more. Be careful. For a simple start I edited /etc/inittab to comment out the console getty near the end of the file.

#Spawn a getty on Raspberry Pi serial line
#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

minicom -b 57600 -o -D /dev/ttyAMA0

Making a direct, 3 wire (TX/RX/GND) connection to the DUE works bidirectionally at 57600 with minicom and echoing back.  It also works over an XBee link if the XBee is not powered from the Pi. The 3.3V on the Pi is not strong enough to sustain the Nokia display and transmit on the XBee.

sudo apt-get install python-serial to get the serial library for python (API). This code will then read and write stuff to the serial port.

import serial

p = serial.Serial('/dev/ttyAMA0',57600)
while 1:
  s = p.readline()
  print s
  p.write("this is what I think\n")

Connecting with I2C

This is the newly configured breadboard, a bamboo
cutting board for $3 from the dollar store with holes and
zip ties to hold the processors in place and self adhesive
mounting tape for the solderless plug-in breadboards
and the USB hub. All the power (except to the processors
through USB) is coming from the Arduino DUE
in the top corner, as it is good for up to 800 mA of 3V3.

I already installed a bunch of stuff for software support so it should be plug and go on the breadboard... and it was as simple as hoped for. The breakout boards are wired to power and connected to the I2C pins of the Pi through the green (SCL) and yellow (SDA) leads.

sudo i2cdetect -y 1

Shows an ADS1115 16 Bit ADC at 0x48 and a MPL115A2 Barometric Temperature / Pressure sensor at 0x60. The DAC Note seems to be out of date on the library as the version I've got already had the links to Adafruit_I2C.py created and there was code to check the revision number automatically. Still, the link is a tidy way to get the libraries in without setting the path variable.

Switching to the ADS1x15 directory got me an example already set up for the 1115, but you would need to edit for the 12 bit version, the ADS1015, that behaves almost identically. With pins floating I get:

sudo python ads1015_example.py 
Channel 0 = 0.598 V
Channel 1 = 0.591 V

A close up of the breakout boards with the I2C boards
lower and the analog accelerometer board in the top left.

There's no library code for the MPL115A2 so I will ignore it for now. A little modification to the example program allows ads1115.py to read all 4 channels once a second and put the output on a single line. Attaching the analog outputs from the +/-16 G Accelerometer breakout board gives the kind of results you would expect. Pin 0 is connected to the supply voltage.

With this sort of addition to the Pi you get a high resolution reading of analog voltages so you can respond to an analog world. It adds a little price and complexity over a microcontroller with built in ADC capabilities and it won't read the data as fast over I2C as you can get it from the integrated ADC ports.

sudo python ads1115.py

Channel 0 = 3.275 V Channel 1 = 1.637 V Channel 2 = 1.625 V Channel 3 = 1.711 V

Channel 0 = 3.275 V Channel 1 = 1.637 V Channel 2 = 1.625 V Channel 3 = 1.710 V

Pi Power Dance

Do it this way, really!

Power seems to be at the root of almost all Raspberry Pi problems. I refused to believe what I read and you probably will too. The experience could be a valuable relearning of the basic high school physics of electricity or it could just be frustrating. You can avoid this learning experience by hooking power up like in the picture above. (Yes, there may also be HDMI and network cable connections to the Pi, but they shouldn't be carrying power.)

What I Learned (after much dancing about)

Most power supplies are OK: not great, but OK, meaning they can supply something close to their rated power while still providing a voltage greater than 4.75 volts at the power supply outlet. There are certainly some really crummy power supplies out there -- avoid counterfeit Apple stuff.

USB Micro B cables have thin wires: thin enough to have relatively high resistance, and thin enough that the voltage at the micro B plug on an operating Raspberry Pi can be 4.65 volts even when the voltage at the power supply is still 5.02 volts. V=IR and these cables were really not intended to be used as extension cords.

Tiny WiFi dongles use big power: Sending radio signals requires power and too low a supply voltage will cause the communication to fail. The power draw may pull the supply voltage even lower and cause erratic behaviour from low power devices like a keyboard or mouse.

CAUTION! You may be able to power the Pi from the Hub: but only Maybe! The hub will need to be one that provides charging ports capable of supplying more than the usual 500 mA of current. You will have to be lucky, and stay lucky. If the hub power supply provides 5V it will drop before it gets to the hub due to resistance in the power cord, then it will drop across the circuitry in the hub, then it will drop some more in the USB cable to the Pi. In my case that gets it down to about 4.5 to 4.6 V on the Pi, depending on what the Pi is doing at the time. That seems to be OK if there is nothing expecting any power at all from the Pi USB ports -- the hub is only getting its signals from the Pi USB and the second port on the Pi is empty. Anything hooked to the GPIO 5V pins will also see this reduced voltage and may not work as expected. Go back to two separate plugs in the wall at the first sign of trouble. CAUTION!

5.25 Volts is within spec: You could solve most of these problems by using a 5.25V like the one Adafruit sells, but they are currently out of stock and not expecting more for weeks.

Back Up the Pi

Easiest to do, with the samba share working, was copy the contents of the pi user directory to a directory on my mac, which gets backed up by time machine. That still leaves backing up an image of the full system, with all the permissions and everything. I put the card in the reader did the "About This Mac" thing again. This time the card reader was listed as disk2s1 instead of disk3s1 (probably because I didn't have the USB key connected) so I typed:


mkdir RaspberryPi
cd RaspberryPi
sudo dd if=/dev/rdisk2 of=rwspi20120207.img bs=1m

in the mac terminal window. There were lots of disk noises, but no other response to the terminal for a long time. (1050 seconds is 17 1/2 minutes but it seemed longer)


15271+0 records in
15271+0 records out
16012804096 bytes transferred in 1050.493195 secs (15243130 bytes/sec)

resulted in a 16 GB .img file on my mac for the 16 GB card size. I ejected the card and put in another 16 GB card. I erased the partition that existed on the card, then reversed the if/of arguments to produce a copy:

sudo dd of=/dev/rdisk2 if=rwspi20120207.img bs=1m

15271+0 records in

15271+0 records out

16012804096 bytes transferred in 1123.638986 secs (14250844 bytes/sec)

took less time to write than I expected. I ejected the SD, put it in the Pi and it booted just like the original. 

Dropbox would be cool to have, but a little googling suggests it would be difficult.

Hammer vs Screw Driver

What's better for your project, a Raspberry Pi or an Arduino? Linux or a microcontroller? I'm not an expert by far, but some people have been asking me this question and I've been asking it myself for a couple of projects, so here's a short answer from my perspective:

A Raspberry Pi (or other general purpose computer) is good for doing multiple things at a time and interacting with people, especially people at a distance, even multiple people at the same time. It can also interact with hardware attached to it and switch things on and off, make some measurements, etc. There are no guarantees about how quickly everything will happen and response will slow down as you ask it to do more things. That's fine if you don't care if your sprinkler goes on right now, or just really soon. For things that are really time critical, your Pi may not be watching at just the right moment and might miss something. (WiringPi incorporates interrupts on the Pi.) (Latency data below.) Without additional hardware your Pi will only read on/off (digital) signals so you can tell the difference between dark and light, but not between a sunny day and a cloudy day (analog).

An Arduino (or other microcontroller) runs only one program at a time, so your program will always be in control and will only miss something if your program ignored it for too long. If it's really important to catch it, you can set one of the hardware interrupts to run a function whenever something happens. This will let you update whatever you're trying to control much faster than 100 times a second. It directly supports both analog and digital signals to measure things like how bright it is outside.

If your project needs to talk to people and be network friendly, include a Raspberry Pi.

If your project needs to read analog data and react to inputs right away, 100 times a second, include a microcontroller.

If it needs to do both, then maybe you need both and there is certainly room for both in most boxes and budgets. There are lots of different ways to interface them so that the Pi can concentrate on UI, communications and data storage while the microcontroller concentrates on making everything happen at exactly the right time. If space or budget are really tight you may be able to cover both with a single unit, but it may be more difficult. Other details to consider include:

Memory: A general purpose computer usually has more volatile memory (e.g. 512MB RAM on the Pi) where you can store programs, or data that change often and have them vanish when you turn off the power. A microcontroller usually has less volatile memory (e.g. 2KB on the UNO) combined with some non-volatile memory where you can store programs that won't vanish when you turn off the power.

Booting: A general purpose computer has to load programs into volatile memory and initialize them before anything useful happens. (This can take about a minute for a Pi from and SD card.) A microcontroller already has a program in memory and starts doing useful things almost immediately. (a few seconds on an UNO with the bootloader, or less.)

It's important to pick the right tools for the job. I found these hemostats from Pakistan at Princess Auto for a few bucks each. Very useful for fine work and clamping! Lousy for driving screws or nails. The little board getting the power leads soldered on is a Teensy 3.0 microcontroller with processing power similar to a Raspberry Pi and much faster than an Arduino UNO.

Pinging from one pi to another over wireless on the same wifi network shows it can be quite fast, except when it's not. If latency of less than 1/4 second is important, you may want another solution.


64 bytes from rwspi.local (192.168.2.24): icmp_req=1421 ttl=64 time=225 ms
64 bytes from rwspi.local (192.168.2.24): icmp_req=1422 ttl=64 time=28.2 ms
64 bytes from rwspi.local (192.168.2.24): icmp_req=1423 ttl=64 time=223 ms
64 bytes from rwspi.local (192.168.2.24): icmp_req=1424 ttl=64 time=25.1 ms
64 bytes from rwspi.local (192.168.2.24): icmp_req=1425 ttl=64 time=12.9 ms
64 bytes from rwspi.local (192.168.2.24): icmp_req=1426 ttl=64 time=203 ms

Pinging google.com is reliably faster over a much longer path:

PING google.com (74.125.226.66) 56(84) bytes of data.

64 bytes from yyz06s07-in-f2.1e100.net (74.125.226.66): icmp_req=1 ttl=54 time=18.8 ms

64 bytes from yyz06s07-in-f2.1e100.net (74.125.226.66): icmp_req=2 ttl=54 time=15.1 ms

64 bytes from yyz06s07-in-f2.1e100.net (74.125.226.66): icmp_req=3 ttl=54 time=20.5 ms

64 bytes from yyz06s07-in-f2.1e100.net (74.125.226.66): icmp_req=4 ttl=54 time=14.0 ms

More Pi? First Python, Web Server, More Wifi

Getting a Web Server Running

JM again. He makes a recommendation to change the memory split between the GPU and the CPU, which I tested out before doing other things. A 24 bit HDMI screen takes about 6MB just to hold the data, so you probably need a bunch more to manage overlays and stuff. So I used raspi-config to let the GPU have 32 MB of memory.

I ran through the rest of the steps and the upgrade ran quickly this time with only a couple of packages... The rpi-update failed on it's first few connection attempts to github, but auto retried and eventually succeeded. I made no changes to the apache config and voila... I moved a copy of the Made in the Shade web site on to the Pi and it works just fine, except for some hard coded absolute links that jump it out to the real site.

Multiple wifi options

It would be nice to get the Pi to automatically join whichever wifi it can find from a list, or even to allow roaming like a phone...  I followed the approach in that link and it will pick up the BELL989 network from the DSL modem, the "165 Bagot" network on the AirPort Express and the "165 Bagot Street" network running on the LinkSys EA3500. I'm not sure how it chooses which one, but it can be forced by commenting out lines. It refused to pick up "165 Bagot" when it didn't have a link to the internet.

Looking like I'm Working

Press the button and all the lights go on, otherwise they just
flash on and off randomly at 1/4 second intervals.

In the seventies I worked in a department that had a Data General minicomputer. The Boss knew that computer time was highly valuable and didn't want to see it sit idle, so we wrote a program to blink its console lights at random. Just wrote the same program for the Pi in Python, but I had to build the console lights first ;-)

This is my first ever program in Python:

#!/usr/bin/env python

import RPi.GPIO as GPIO, feedparser, time, random

DEBUG = 1

GPIO.setmode(GPIO.BCM)
GREEN_LED = 27
RED_LED = 4
YELLOW_LED = 25
BUTTON = 24

GPIO.setup(GREEN_LED, GPIO.OUT)
GPIO.setup(RED_LED, GPIO.OUT)
GPIO.setup(YELLOW_LED, GPIO.OUT)
GPIO.setup(BUTTON, GPIO.IN)

while True:
    if GPIO.input(BUTTON): 
        n = random.getrandbits(32)

        if n % 2 == 0:
                GPIO.output(GREEN_LED, True)
        else:
                GPIO.output(GREEN_LED, False)
        if n % 3 == 0:
                GPIO.output(RED_LED, True)
        else:
                GPIO.output(RED_LED, False)
        if n % 3 == 1:
                GPIO.output(YELLOW_LED, True)
        else:
                GPIO.output(YELLOW_LED, False)
        
        time.sleep(0.25)
    else:
        GPIO.output(GREEN_LED,True)
        GPIO.output(RED_LED,True)
        GPIO.output(YELLOW_LED,True)


The LEDs are red, green and yellow tied to pins 4,  27, and 25 respectively and grounded through 560 ohm resistors. The result is dim lighting, but keeps the current down well below the 16 mA max per pin that I've seen posted multiple places. I pulled pin 24 high through an 18K resistor and added a button to ground it when it's pushed. (4, 24 and 25 were geometrically convenient on the Adafruit Pi Plate and 27 can do PWM. None of them are earmarked for I2C, SPI etc.)

More Raspberry Flavoured KoolAid... Upgrading

Completing some more Adafruit lessons meant :

sudo apt-get update

git clone https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code.git
sudo apt-get install python-dev
sudo apt-get install python-rpi.gpio

sudo apt-get install python-smbus
sudo apt-get install i2c-tools

sudo apt-get install python-pip
sudo pip install feedparser
sudo easy_install -U distribute
sudo pip install RPi.GPIO

Some of that appeared to be doing nothing, gracefully not installing the stuff that was already there.

sudo apt-get update && sudo apt-get upgrade

goes looking for upgrades to the distribution. Make sure the sudo commands are directed against the Raspberry Pi and not against your base system like my iMac. Yet another good reason not to use the same passwords for different machines. It took a fair amount of time to go and get a ton of stuff. Then it failed on connecting to an archive (possibly because I was poking at it, or maybe something to do with the VNC session?), so I ran it again and it appeared to start up where it left off, ignoring the stuff it had already completed. That fair bit of time begins to look like it might be measured in hours... about two of them eventually ;-) Reboot with sudo shutdown now -r and the connection is lost, but returns with a new ssh.

Setting up Samba for File Sharing

Jeremy Morgan seems to have a bunch of useful materials for such things. /etc/samba/smb.conf exists and I see rwspi showing in the finder, so I assume there's just some config to do, but smbpasswd is not found, so I start at the beginning.

The rwspi near the bottom has been
there all along, but no joy connecting

sudo apt-get update
sudo apt-get install samba
sudo apt-get install samba-common-bin
sudo smbpasswd -a pi
sudo nano /etc/samba/smb.conf
   security = user         these were uncommented/changed
   socket options = TCP_NODELAY
   [homes]
   readonly = no
   valid users = pi

   [RWSRoot]                           this was added
   path = /
   comment = Root Access
   valid users = pi
   writeable = yes
   browseable = yes


Then I followed the instructions to restart the samba demons, but the link in the finder still did nothing useful. Reboot all round. Still no joy. Tried opening the pi share on a windows machine and it worked, so this must be a mac issue. Enabling SMB sharing for the user didn't fix it. The mac seems to think rwspi is another mac.

Solution: Finder/Go/Connect to Server... smb://rwspi.local/ and hit + to add it to the favourites list. Log in as pi with the appropriate password. Now there's an rwspi.local entry at the top of the shared list and I can see both the root and the pi home directories.

Pi Shaped Box at the door...

The Raspberry Pi config process seems to be a slow one, so I might as well document my steps. Because I wanted easy access to Adafruit code for hardware, I went with the Adafruit Pi lesson 1 and downloaded v02 of the Occidentalis distro, which unzipped itself to Occidentalis_v02.img in my iMac's downloads folder. I thought I followed the mostly graphical interface directions when I typed:

sudo dd if=Downloads/Occidentalis_v02.img of=/dev/disk3s1 bs=1m
2479+1 records in
2479+1 records out
2600000000 bytes transferred in 1353.109465 secs (1921500 bytes/sec)

in the iMac terminal to create the SD card file system. I got a huge warning about careless use of sudo, supplied my password and it looked like it worked, but it didn't. There were no signs of life from the Pi no matter how I connected it, except that the little red light came on. Then I noticed that the command line version of the instructions had a different form with rdisk3 instead of disk3s1. (Apparently about the raw disk, rather than the partition...) Trying it that way lead to a way faster write speed indicated in the activity monitor (14 MB/sec vs 2 MB/sec) but the output report looked much the same.

sudo dd bs=1m if=Downloads/Occidentalis_v02.img of=/dev/rdisk3

2479+1 records in

2479+1 records out

2600000000 bytes transferred in 180.307686 secs (14419796 bytes/sec)

So I was pleasantly surprised when I plugged in SD card, mouse and keyboard, HDMI, then power and it got me to the first blue screen. I followed the basic steps in that config, plus enabling SSH, then rebooted. It took 15 minutes or so to resize the blocks in the file system, then booted to the GUI. Yay!

Now I have a linux machine that runs like a slug! Make no mistake, the pi is not going to make you happy compared to the GUI you're used to unless you have been using really old hardware. The wired network worked right off, and the wifi works using the USB plug-in from Adafruit after appropriate edits in /etc/network/interfaces. I followed that success with a lot of messing about with XQuartz X11 on the iMac, iSSH on the iPad, and never really got a satisfactory result. I had trouble with X back in the 90's too... An ssh login with 

export DISPLAY=192.168.2.12:0
scratch &

allowed me to start an X session on iSSH on the iPad, which was really slow, but the equivalent didn't work on X11 on the iMac. Based on http://elinux.org/RPi_Remote_Access I ran:

sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server

to reset the RSA keys, but only after compromising the security of my iMac. So I took the offending RSA key out of ~/sellensr/.ssh/known_hosts on the iMac. (It looks like this was unnecessary: watching first boot of a fresh copy shows it generating a new set of keys that don't match the old keys.)

On the Pi I changed my pi password and edited /etc/hostname and etc/hosts to make the machine rwspi instead of raspberrypi and rebooted everything a few times until it took. I followed lesson 7 in hopes of a simpler path and typed:

sudo apt-get install tightvncserver
   [much verbiage ignored]
tightvncserver

in the terminal and supplied a password for the vnc server. Once everything was configured and safely shut down, I powered up the pi with nothing attached, except the wireless dongle in the USB port, and started a terminal session with the vanilla terminal program. I ssh'd into the pi and started the server like this:

ssh pi@rwspi.local
pi@rwspi.local's password: 
Linux rwspi 3.1.9adafruit+ #10 PREEMPT Thu Aug 30 20:07:05 EDT 2012 armv6l
[...]
Last login: Sat Feb  2 18:30:34 2013 from ricks-imac-3.local
pi@rwspi ~ $ tightvncserver :1

New 'X' desktop is rwspi:1

Starting applications specified in /home/pi/.vnc/xstartup
Log file is /home/pi/.vnc/rwspi:1.log


Then, I just ignored the terminal and ran the RealVNC VNC Viewer app to connect to rwspi.local:1 and got a window like this on the iMac screen.

I adjusted the settings to get a little better view at the expense of a a slower response. When I was done, I went back to the terminal and typed sudo shutdown now to kill everything gracefully. Apparently adding the -r option would get it to reboot.

So now I think I have a Raspberry Pi arrangement that allows me to sit comfortably at my desk and get the console on a top notch screen and keyboard. Somewhere in the middle there I was having problems with the cheap USB mouse and keyboard skipping and/or repeating, quite possibly due to low power, so I spent some time playing with a powered hub, which was also flake inducing, before finding out that there's an official approved hardware list. This saves me from all that hassle...