Pi-radigm

Although the boards look vaguely similar at first glance, Raspberry Pi is quite different from Arduino. The difference is not in functionality (although it has that, too); the difference is in paradigm.

Arduino is at heart an AVR chip. Imbedded micro-computer designed for physical computing; reading knobs, controlling LEDs and servos. When you work with an AVR you are working practically on the bare metal (as the old computer people would call it). Although the Arduino IDE (programming environment) offers some slight distancing, you are basically throwing together straight C code which is compiled right into the chip.

I don't know how I can express the visceral sense of this on the non-programmer. When you write "sudo apt-get install mpg123" on a Linux command line you are passing on a general idea to a host of smaller programs which check your bona-fides, look to see what is installed already, talk to yet other programs which help them get online and look for the materials they need to fulfill your request, etc. When you write "DDRA = (1 << 7);" you put -- after a trivial bit of math -- voltage on the selected pin.

The AVRs are tough. Nominally 5v (or 3.3v) devices, you can run them from under two volts to six or seven volts before they start getting buggy. You can abuse the inputs the same way, and the outputs are beefy enough to drive high-intensity LEDs. Anti-static measures are pretty much extraneous. They would like to see a nice steady clock signal as well but if your application is brute force and ignorance (like flashing a couple of LEDs) then the internal clock is close enough. Same for protecting the chip from power fluctuations or holding down unused inputs; although the Arduino does all of this, it isn't unusual to find an AVR with nothing attached to it but batteries and a load.

Raspberry Pi is a computer. That means it has a whole operating system in there, with GUI if you want it. It is generally expected to be connected to the internet, and it is fitted out with standard USB (host) ports and HDMI output and even a little headphones driver. Doing any one of these tasks will practically cripple a poor AVR.

But with that operating system comes overhead, and the pitfalls. Raspberry Pi's do crash, sometimes corrupting the OS in the process. They are sensitive to what happens at their general-purpose input/outputs. And when you program, even though you are generally working at just a coat of paint (X-windows) from the Linux core, and even though you are frequently at the command line (so much so that command line forms an integral part of the interface window for many programs), you are still at several layers of abstraction as your commands are invoking various helper programs which are accessing several libraries which are eventually calling on built-in functions within the Linux kernel.

And which means you aren't going to be seeing the same kind of documentation from me about Raspberry Pi as I've given on the AVRs. Because it is a computer, meaning every installation is subtly different and every experience becomes different. What worked for me in setting up the Adafruit PiTFT touch-screen and SSH from my MacBook may or may not work for someone else, even if they have a seemingly identical setup.