In January 1975, Popular Electronics ran a cover story about a new computer for hobbyists. The Altair 8800 came as a kit and cost $439 (the equivalent of $1,778.58 in today's dollars). It came with no on-board memory. You programmed it by entering Intel 8080 opcodes by hand via a series of switches on the front panel. Buying 4k of memory, the ability to read in programs from paper tape, and a teletype interface would increase the price 6 fold. You had to solder the thing together by hand. By comparison with the big university and corporate mainframes it was basically useless.
But Popular Electronics was the Make Magazine of its day and engineering schools had begun to require their graduates to learn some programming, so Forest Mims and Ed Roberts, the two guys in Albuquerque who'd put the Altair together, figured they could probably sell a few hundred in the first year to this emerging group of hackers avant la lettre.
They took 1,000 orders in the first month. Six months after the release they'd sold 5,000. By October of that year their company had 90 employees.
Why was the Altair such a runaway success? After all, by comparison to the cutting edge computers of its day, it was underpowered and extremely difficult to work with. The answer is ownership. The Altair offered bourgeoning hackers their first chance at a computer that would be fully and completely theirs. They could take it home, throw it up on their work bench, take it apart, put it back together and try to get it to do totally new unimagined things. They could program their Altairs to play Fool on the Hill through a transistor radio. They could build a board to let the Altair drive a color TV in Times Square. They could start a small company to sell programming languages for it. They could get together with their fellow Altair owners to share programs and cool hacks.
This last point can't be emphasized enough. The Altair crystallized growing local groups of DIY computer enthusiasts like the Homebrew Computer Club in Silicon Valley. It gave them an outlet for their energies and an example of what could be done. It made them believe that their incredible fantasy of having their own computers might really come true.
And after that, there was no stopping them. This new generation of hackers dedicated itself with an almost religious zeal to spreading the idea of computer ownership across the world. They invented the personal computer — a whole industry dedicated to the notion that computers could make life better and work easier for everyone, not just huge institutions. The Homebrew Computer club alone included the founders of Apple, Ozborne (builders of the first portable), and a raft of other industry pioneers.
Today, the world of physical computing closely resembles the personal computer industry circa 1975. We've been around for a few years struggling around the edges with tools and products that were designed, priced, and packaged for serious industry, but we haven't made any money and we haven't moved the world. That's about to change.
Recently, our Altair arrived. It's called the Arduino. This is 2009 so instead of being built by two engineers in Albuquerque, it was built by an open source international cabal of programmers and professors.
A lot of people complain that it's underpowered and overpriced (even though it only costs $8.64 in 1975 dollars). But you don't need special hardware to program it. It lets you do all the basic tasks with just a line or two of perfectly comprehensible code. And there's a thriving community of people busily using it to do all the useless, fun, creative things they'd always dreamed of if only they could get their hands on a computer that could sense and control the world around it. They're using it to teach houseplants to call for help if they need watering. And they're using it to play music on glasses of water.
If the Arduino is the Altair of physical computing then what will be its VisiCalc? What will be the killer application that makes the physical computer of the future a necessity for business. If the Arduino is the Altair, what will physical computing's Mac look like? I don't think anyone today knows the answers to these questions.
But the answers are coming. In the next few years, physical computing has as much of a shot at changing the world as technologies ever get. And this is the time to get involved. Unlike the web, personal computer, and green energy industries, physical computing is a space where two guys in a garage can come along and invent something that will touch billions of people around the world without anyone else's permission. That's because what's needed in physical computing is not advanced research, massive infrastructure investment, or huge production facilities. What's needed is close attention to applying the existing technology to solving human-scale problems. Microcontrollers and sensors, CNC milling machines and laser cutters, GPS devices and accelerometers need to be transformed into tools that regular people can use to improve their daily lives: to make themselves more connected to the people and places around them, to entertain, educate, and distract them.
In 30 years, when people tell the story of the Physical Computing Revolution and how it changed the world, what will they say about you?
Everyone who's ever played with an Arduino has seen the following sketch:
It's the classic physical computing 'hello world': blink the onboard LED on and off every 500ms. But how does it really work? How does this code actually translate into the Arduino's AVR microcontroller sending the right electrical signals to turn the LED on and off?
This question turns out to be a great entryway into learning about the architecture of the AVR chip as well as the Arduino software itself. In this post, I'll explain how the AVR actually controls the pins on the Arduino and then walk through the implementation of each of the Arduino functions used for hello world (pin_mode, digital_write, and delay) to show how the Arduino software uses the AVR's capabilities to implement them.
AVRchitecture: Registers, PORTs, PINs, and DDRs
Like every processor, the AVR microcontroller is organized as a series of registers. Like tiny digital cubby holes, registers are little slots that the AVR can stick data into or grab data from.
Different registers can be used for different tasks. Some are meant for temporarily stashing data you're in the midst of working with just like you'd put your ipod and headphones down on a shelf so you could have your hands free to tie your shoes. Other registers are actually connected to peripheral devices — like the EEPROM, serial port, and analog and digital pins — and reading and writing from those registers is how you communicate with those devices just like dropping an envelope full of cash in your landlord's mail slot to pay your rent.
Each pin on the Arduino is hooked up to three registers: a Data Direction Register (DDR), a PORT register, and a PIN register. The AVR uses all three registers in concert to control each pin. The DDR is how the AVR configures the pin for either input or output (this is the heart of the Arduino's pinMode function). If the pin is setup for output then the AVR uses the PORT register to send values to it (think digitalWrite); if it's setup for input, the AVR uses the PIN register to read its value (digitalRead).
Each register on the AVR is 8-bits wide, which means that each cubby hole has eight individual sub-slots which can each store either a 1 or a 0. On the DDR, PORT, and PIN registers each of these sub-slots corresponds to exactly one of the Arduino's physical pins. Hence, in order to have enough slots to control all of the Arduino's pins, the AVR has 4 sets of these registers labeled 'A' through 'D' as in: DDRA, PORTA, PINA, DDRB, PORTB, PINB, etc.
In our hello world sketch, the LED is plugged into pin 13 which happens to be connected to the B set of registers. Since we're only outputting to our pin and not reading from it, blinking the LED involves the use of only two registers: DDRB and PORTB. First, we'll have to turn on the bit in DDRB corresponding to pin 13 to configure it for output. Then we'll send alternating 1s and 0s to the correct bit in PORTB to turn pin 13 on and off.
Halt and Ponder the Magic of Electricity!
Before we move on to the Arduino software itself, it's worth stopping to ponder this last step in a little more depth because it is truly a magical moment. Up until this last step of outputting to PORTB, we've been thinking of the bits in the AVR's registers as having logical meaning. That is, the bits represent data, whether settings for our pins (as in the DDR) or other data we're using for calculations (as in the working registers where you leave stuff while you tie your shoes).
However, since this is an electrical digital computer, whatever the bits might represent, they are stored and transmitted as electrical signals. In other words, when we talk about individual bits in a given register being set to 1 or 0 what we really mean is that there either is or isn't electricity flowing through them. And so, when we send a 1 to the bit in PORTB corresponding to pin 13, we are in fact sending not just a logical value, but electricity as well, 5 volts of the stuff, enough to light up the attached LED.
This moment represents the heart of physical computing: electrical circuits representing logical values and conducting digital computation suddenly transmute into a change in the actual world. This is where the magic happens.
Arduino Software: pinMode()
Now that we've seen how the AVR chip controls the Arduino's pins, let's take a look at how the Arduino library tells the AVR itself what to do. To do that, I'll walk you through the implementation of each of the functions used in our hello world example above to see how they work.
We'll start by diving into the implementation of pinMode defined in arudino-0015/hardware/cores/arduino/wiring_digital.c thusly:
We already know the overall goal of this code. It takes as input an integer representing a pin on the Arduino and another integer representing the mode into which we want to set the pin (in practice, we tend to pass the constants INPUT and OUTPUT, but if we look in arduino-0015/hardware/cores/arduino/wiring.h (lines 38 and 39) we can see that these constants are defined to be 1 and 0 respectively). From our discussion of the AVR architecture we know that in order to configure a pin, we'll want to set the corresponding bit on the right DDR. So, this code will need to do two things: it'll need to figure out which bit on which DDR corresponds to the given pin and it'll need to set that bit high or low as appropriate given the desired mode.
Let's walk through this code line by line to see how it accomplishes these things.
The first thing pinMode does is call the function digitalPinToBitMask, which is defined as a macro in arduino-0015/hardware/cores/arduino/pins_arduino.h:
A macro is a kind of magic inline function that gets expanded at the time your program is compiled rather than when it's already running on the AVR. Even though they can make things harder to understand, macros are used widely throughout the Arduino source (and even more so in the avr-gcc code it depends on) because of the extremely limited program space available on the AVR and to help with performance.
(Note: while unpacking this first function call, I'm going to be extremely thorough, following all sub-routine calls back through to their definition in both the Arduino source and its dependencies. This may make the flow of things hard to follow, but I want to give you a taste for how this stuff is really implemented all the way to the metal and also, hopefully, provide a little bit of a map that will help with your own future explorations into other parts of the internals. For subsequent steps, I'll stay at more of a summary level of abstraction, trusting that you can follow this example to dive into the actual source if it suits your fancy.)
Now, let's unpack this macro. This function is going to create a special byte that will be set to 0 at seven of its eight bits and 1 at only the bit corresponding to our pin's location in DDRB. This byte is called a "bit mask" because when you combine it with another byte using the logical OR operator, it only sets the one slot where your mask had a 1, leaving all other slots at their pre-existing values. Once we've got that mask, our pinMode function will use it to make sure we only set the mode on the desired pin.
So, how do we construct the bit mask we're going to use to make sure we only turn on pin 13? Let's proceed through the macro in execution order starting at the center of the nested parentheses with: digital_pin_to_bit_mask_PGM + (P). Even though it may look like an addition, this is actually an array indexing operation. We're looking up the 14th element in an array called digital_pin_to_bit_mask_PGM (C arrays start counting their indices at 0). That array is defined in arduino-0015/hardware/cores/arduino/pins_arduino.c like so:
I've elided some array elements for the sake of brevity, but the numbering system is well indicated by the comments; the 14th element in this array, the one corresponding to our 13th pin is the element that reads: _BV( 7 ).
What, for goodness' sake is _BV( 7 )? It's another macro. But this time, instead of being defined in the Arduino library itself, it's defined in one of its dependencies, avr-gcc, specifically arduino-0015/hardware/tools/avr/avr/include/avr/sfr_defs.h:
_BV returns the result of shifting the number 1 the given places to the left. In other words, _BV takes a byte that looks like this: 0b00000001 and moves that sole 1 to the left by the number of places indicated, in our specific case seven, to return: 0b10000000. (This 0b-a-bunch-of-zeros-and-ones notation is meant to indicate a single byte with 8 bits set to the values given to the right of the 'b'.)
Jumping back to our macro, we can now see that digital_pin_to_bit_mask_PGM + (P) returns a byte with the leftmost bit set to 1 and all the other bits set to zero: 0b10000000. The macro then takes this value and passes it to pgm_read_byte, another function defined inside the avr-gcc library, this time in arduino-0015/hardware/tools/avr/avr/include/avr/pgmspace.h:
Understanding pgm_read_byte is going to be the most challenging part of this whole exercise. In order to explain it clearly, I need to first give you a little more background on the architecture of the AVR.
Programs, Data, and Harvard vs. von Neumann Architectures
In normal processors (like the one in the computer you're probably using to read this post) program instructions and data are both stored side-by-side in the same kind of memory. In other words, your computer has one big bank of memory (you probably remember seeing it in the spec when you bought your computer: 1GB or 2GB of RAM, most likely) and it stores both the programs you run (for example, the Arduino IDE or iTunes) and the data your run them on (your mp3s) all in that same bank of memory. This design is called a von Neumann architecture and a lot of the more advanced things your computer can do come from the interchangeability it provides between programs and data.
The AVR does not have a von Neumann architecture. Instead, it's built with an alternative design called the Harvard Architecture. In this design, programs and data live separately in different chunks of memory. Program instructions live in Program Memory and the data these instructions operate on live in Data Memory. The advantage of this divide is that it makes the AVR both dramatically simpler and more reliable: once loaded onto the chip, programs can't be changed by the data on which they operate. The disadvantage is that programs become more rigid, losing the ability to change and transform themselves as they encounter new data in the way allowed by the von Neumann architecture. For embedded devices expected to operate with high reliability for long periods of time doing relatively simple tasks, this is a great trade.
What does all of this have to do with understanding pgm_read_byte? Well, if you look a little more closely at the digital_to_pin_to_bit_mask_PGM array we visited earlier, you'll uncover the answer.
Notice the declaration of this array. It's declared as being "const uint8_t PROGMEM". The first two of these types are familiar: "const" means that it won't change in the course of running the program and "uint8_t" means that it will be an array of 8-bit integers, but what's "PROGMEM"? Reading, the avr-gcc documentation on the subject reveals that PROGMEM is a macro that allows you to store data in Program Memory.
But wait! Didn't I just spend two paragraphs telling you all about how the AVR's Harvard Architecture kept a rigid separation between Program and Data Memory in order to ensure stability and performance? I did. But here's the thing: on most AVR processors, the amount of Data Memory is miniscule compared to the Program Memory. For example, the ATMega168 that comes standard on Arduinos these days has 16K of Program Memory and only 1024 bytes of Data Memory (albeit supplemented by an addtional 0.5K of external EEPROM). If the core Arduino and avr-gcc code went around filling up these paltry 1024 bytes with the data structures they need to do their job, pretty soon there'd be none left for your code to use. Hence, avr-gcc provides the PROGMEM macro so they can store data in Program Memory and pgm_read_byte (and some sibling functions for other data types) to pull it back out again.
How is pgm_read_byte actually implemented, then? If we follow the chain of macros begun in the define I showed earlier, we discover that the heart of pgm_read_byte is a macro that uses inline assembly code to read a byte that corresponds to the location we calculated above (0b10000000) out of the AVR's Program Memory ('lpm' is the assembly instruction for Load Program Memory) (arduino-0015/hardware/tools/avr/avr/include/avr/pgmspace.h line 298):
Don't worry too much if you don't understand every single character of this macro. It's the deepest darkest part of the internals we're going to look at and as long as you followed the core of the Program Memory v. Data Memory story, you'll know what you need to follow along as we proceed.
Back to pinMode
We're finally at the point where we can pop back up the stack and continue plugging through the rest of pinMode! As I promised earlier, now that we've gotten a flavor for how this stuff works all the way down to the metal, I'm going to keep things at a higher, more comprehensible level from here on in.
So, in case your memory doesn't stretch back more than a couple thousand words, here was the full implementation of pinMode:
We've seen how that first line works. "bit" is now set to be a bit mask that selects just the bit on any given register corresponding to Arduino pin 13. Now the next thing we've got to do is find the PORT register our pin lives on. Remember, to configure a pin for output, we need to set the correct bit in the correct Data Direction Register and there's a different DDR for each PORT, eg. DDRA for PORTA and DDRB for PORTB, etc. Therefore, before we can figure out which DDR we need to work with to configure out pin for output we need to figure out which PORT it's on.
The second line of this function calls digitalPinToPort. This function is a macro just like digitalPinToBitMask, but instead of creating a bit mask, it composes a byte with the address of the correct PORT for the given pin, in our case this will be the address of PORTB since that's where pin 13 lives.
The next line of the function initializes a pointer called "reg" that we're going to aim at the DDR once we find it. But first, what if the pin number that got passed in was crazy? What if some nutso user tried to configure pin 97 for input? pinMode protects against that by checking the return value of the digitalPinToPort macro against the NOT_A_PIN constant (defined to be 0 in arduino0015/hardware/cores/arduino/pins_arduino.h, if you're curious). If digitalPinToPort returned 0, meaning it failed to find a PORT corresponding to the given pin, then pinMode just returns without going any further. No DDRs are altered.
However, if the given pin matched a real PORT, then we go ahead and call another macro, portModeRegister, to look up its corresponding DDR. Again since our pin is on PORTB the result from this will be a byte representing the address of DDRB. (As far as the comment there from "JWS", I'm not actually sure how avr-gcc's optimizer could possibly know to pull the correct DDR address out for you; this is one piece of this function I don't fully understand).
Now we've got all the data that we need in order to go ahead and actually set the right bit on our DDR. Obviously, we'll have to do something different depending on if we're configuring our pin for input or output: we'll have to set the bit high if we're doing output and low if we're doing input. The last two lines of this function use C's logic functions to do just that.
The first case (if val == LOW) is when we're configuring the pin for input (remember, LOW == 0 which, in the DDR means input). Working from right to left, the first thing we do is take the inverse of the bit mask. So, in our example for pin 13 where we had 0b10000000, the inverse comes out to 0b01111111. Since reg was set to be the address of our DDR, dereferencing that pointer gives us the actual value of the DDR. The &= operator set the DDR to be the result of a logical AND between the current value of the DDR and the inverse of our bit mask. In other words, it will leave the DDR the same for every bit set to one in our inverse bit mask and it will turn the DDR off at any bit set to zero. The result? The most significant bit, the one in DDRB corresponding to pin 13 is turned off and hence pin 13 is configured for input.
If mode was set to OUTPUT (i.e. 1), we do a different logical operation. We don't invert our bit mask, so it's remains 0b10000000. But then, instead of &= we combine it with the DDR via |=, logical OR. As opposed to logical and, this operation leaves the DDR alone for any bit where our mask is set to 0 and turns it on anywhere the mask is set to one. Since our mask is set to be 1 at only the bit representing pin 13, the corresponding bit in DDRB will be turned on and pin 13 will be configured for output.
Whew. We've made it all the way through pinMode! Now we only have two more Arduino library functions we need to understand before we'll have seen all of what makes hello world tick. Thankfully these other two functions reuse concepts we've already learned from our deep dive into pinMode so the rest of this will go rather rapidly, especially our next function: digitalWrite
Arduino Software: digitalWrite()
One of the most commonly used functions in the Arduino library, digitalWrite turns on a given digital pin, i.e. it makes the Arduino send 5V out to the pin. Translating that into the register vocabulary we learned above: digitalWrite turns on one bit on one PORT register corresponding to the desired pin. In the case of pin 13, we know that will be PORTB. Let's take a look at the implementation of digitalWrite (arduino-0015/hardware/cores/arduino/wiring_digital.c):
Most of this is exactly parallel to pinMode. We use digitalPinToBitMask again to find the bit corresponding to our target pin (remember that will return 0b10000000) and digitalPinToPort to find the correct port value (PORTB), again just like last time. This time, instead of using the port value to go ahead and detect the DDR, we use it to get the address of the PORT register itself. And then, once we've got those things, we use the same bit operations to turn on the right bit in the PORT register to send 5V out to our pin.
In addition to all of this parallel code, though, there's another strain running through this function that seems to have to do with something called timers. In addition to calling digitalPinToBitMask and digitalPinToPort, we also invoke another macro called digitalPinToTimer. And a few lines later we do some logic to figure out if we should call the function turnOffPWM with that timer as an argument. What's going on here?
As you know, each pin on the Arduino can be used for either digital or analog input and output. In addtion to this digitalWrite function which can send only 5V or 0V, the Arduino library provides a parallel method, analogWrite, that can send a range of values. You've probably used that function to dim LEDs or control the speed of motors.
Now that we've seen how the AVR chip is actually connected to the output pins via registers, you might find this ability to output analog values somewhat surprising. After all, at a hardware level we only have the ability to turn each bit in each register on and off. We didn't mention any tiny dials on any of those registers that can be set to a range of values. How does the Arduino use this purely digital hardware to achieve analog output?
The answer is a trick you may have heard of before called Pulse Width Modulation. Basically, the scheme works like this: say you want to output an analog value of 50% using a pin that can only be on or off. In order to output that analog value, you'll have to use the only other variable axis available to you: time. If you turned your digital pin on and off very rapidly, keeping it on the same amount of time it was off over a given period then someone on the other end could sample the signal you were sending out, discover the percentage of on time you were demonstrating and interpret that as an analog value. If you then varied the ratio of on-time to off-time you could express different analog values, communicating any percentage you chose.
But doesn't this scheme require the part plugged into our flickering signal to be smart, to sample the signal and interpret it as an analog value? How can this work with a dumb little LED in the dimmer example so commonly used to demonstrate analogWrite? Thankfully, our eyes are a great example of a device capable of converting a flickering digital signal into a smooth analog one. Using analogWrite to fade the intensity of an LED works exactly this way: it flickers the LED on and off so fast that we perceive it as a smooth fade. The same thing goes for using analogWrite to drive a speaker to produce different tones. And the same scheme works in reverse in analogRead to convert a continuous signal into a digital one via rapid sampling.
But what does all of this have to do with understanding these last few lines of digitalWrite? Well, the timer we saw that code referring to is exactly how the Arduino keeps track of time in order to accomplish Pulse Width Modulation or analog-to-digital conversion for its analog functions.
The timer is a built-in function on the AVR. At a basic level, you can think of it as a simple number that the AVR increases by one as fast as it can manage. In other words with each instruction that the AVR executes (technically, at each clock-cycle) it also increments the timer. Depending on the chip's clock speed, this incrementing can happen anywhere from a few thousand to millions of times per second (the ATMega168, the typical Arduino chip, is usually clocked at either 8Mhz or 16Mhz, i.e. 8 or 16 millions of ticks per second).
If we were looking at the implementation of analogRead or analogWrite (something I'd like to do in a future post), this timer would come into play significantly. However, since we're only looking at digitalWrite in this example, all we have to do is make sure that the timer doesn't get in our way. Since the Arduino library lets us use some of the AVR's pins for either digital or analog operations, there might be a timer setup to correspond to the digital pin we're trying to operate. Hence the two timer-related lines in this function which find the associated timer and turn it off.
And that's digitalWrite. In plain English: find the correct bit and PORT register for the pin we're trying to turn on; make sure there's no timer attached to that pin; send a byte to the PORT register that leaves all the other bits the same and turns on or off the bit corresponding to our pin: 5V go out to an LED or solenoid or whatever and things blink or move in the real world.
Arduino Sofrware: delay()
We've very nearly accomplished our goal. We know exactly how the Arduino software uses the AVR's built-in capabilities to do two of the three essential tasks for 'hello world': we've configured pins and we've turned them on and off. All that we've got left now is delay. Without delay, no matter how elegantly we turned the LED on and off, it would just appear solidly dark or lit, rather than blinking in such a satisfactory manner. Let's take a look at the implementation (arduino-0015/hardware/cores/arduino/wiring.c):
This seems exceedingly straightforward. We call a function, millis, which returns the "current time" in milliseconds and then we loop repeatedly, checking the amount of time that has passed (the difference between the new "current time" and start, the time when we first checked it) until it is equal or greater to the amount of time we were trying to delay. (It's interesting to note that this greater or equal to means that delay only guarantees that it waits the given number of milliseconds as a minimum, rather than a precise duration.)
In light of our previous discussion about timers, though, we can see that something subtle must be happening inside of that millis function. It is somehow managing to convert the movement of the AVR's clock (those 8 or 16 millions ticks per second) into milliseconds of real world time. In order to explain how millis accomplishes this trick, we have to introduce our last new concept of this post: interrupts.
Interrupts
So far, every example of functionality we've examined so far has found the Arduino actively taking action: twiddling register bits to configure pins, sending around electrical signals to light up pins, etc. But sometimes instead we want the Arduino to respond dynamically to sudden changes in its environment. To accomplish this, calling normal functions in our regular code won't be sufficient, we need a mechanism that lets us declare what kind of changes we want to respond to and then indicate what should happen when those changes come. Thankfully, the AVR has just such a mechanism: interrupts.
Imagine Interrupts thusly: some kind of sudden event takes place, for example a new serial message arrives; the AVR sends out a signal announcing the event; if any part of our code cares to respond to that particular kind of event, it declares itself as a "handler" for that signal; if there's a matching handler for the given interrupt signal, the AVR stops whatever it was doing, temporarily putting aside whatever work was already underway, and the chunk of code declared to handle the present signal gets run; finally, after our code is done handling the interrupt, the AVR picks up back up on the original work that had been interrupted and continues on where it left off.
The whole process is very similar to what might happen if I threw football at you while you were in the midst of tying your shoes. Your dangerous-flying-object handler would trigger; you'd drop your shoes on the spot and either catch or deflect the incoming football; then, once the danger was past, you'd pick your lacing back up where you'd left it with the possible side effect of being marginally angrier or more paranoid.
On the AVR, the interrupts are actual hardware components that can be triggered by various different events including the completion of an analog-to-digital conversion, the availability of a signal on the SPI or UART serial communication lines, or one of timers reaching various given values.
Aha! This last interrupt trigger points us strongly in the direction for how interrupts will be relevant for the delay method we're in the process of examining. A timer-based interrupt is essential for the process of converting clock ticks into real world milliseconds. Here's why.
The AVR is an 8-bit architecture. Hence, the largest number it can comfortably store, an "unsigned long" which stretches over four bytes for a total of 32-bits, has a range of 0 to 4,294,967,296. As we mentioned above, a typical Arduino normally runs at a clock rate of 16Mhz. At that rate, we could store a running tick count in an unsigned long for 0.001024 seconds before reaching the maximum value we can store in an unsigned long. In other words, we run out of space in our largest variable for counting ticks after about 1 millisecond. Obviously, this is woefully inadequate for even the brief delay of 500ms we need in this sketch let alone the much longer ones we might want for other applications.
So, what's the solution? An interrupt, by jove! Whenever the timer reaches its maximum value, the AVR triggers an interrupt and we get a chance to bring another variable into play. That second variable, rather than simply counting ticks, instead counts how often our timer has overflowed. In other words, every increment of that variable represents 1ms of elapsed time. And if we use another unsigned long we'll suddenly have bootstrapped ourselves up to a whopping 48.54 days that we can count-off before overflowing. A dramatic improvement. And it's easy to imagine how we could repeat the whole process again to deal with even longer durations.
In fact, the Arduino code for handling the interrupt generated by timer overflows does exactly that (arduino-0015/hardware/cores/arduino/wiring.c):
This code is, more or less, an implementation of exactly the scheme we just described. SIGNAL() is avr-gcc's syntax for defining interrupt handlers. The argument that gets passed to it, "TIMER0_OVF_vect", stands for Timer 0 Overflow Vector, which is just a very precise way of indicating the exact interrupt flag that gets set when Timer 0 overflows (there are a series of timers on the AVR that get used for different purposes).
So, this handler will trigger whenever Timer 0 overflows, just as I described above. And what does it do at that point? First, it increments timer0_overflow_count, which is an unsigned long keeping track of how often this timer has overflowed just like we expected. Then, it does some other complicated stuff with timer0_clock_cycles, clockCyclesPerMicrosecond(), and some multiples of something called "UL". Basically, what's happening here is scaling. The relationship between clock cycles and real world time is different depending on a number of different hardware-specific factors ranging from clock speed to the size of an unsigned long (remember, the ATMega168 that I'm treating as typical is actually in the middle of the family in terms of capacity, supported chips range down to the ATMega8 with its slower clock and 8-bit longs all the way up to the ATMega1280 on the new Arduino Megas). The rest of this interrupt handler just uses the values of those variables to correctly convert clock ticks into milliseconds (saved into timer0_millis, which it increments at the heart of the while loop).
To summarize, this interrupt handler gets triggered every time timer0 overflows the chip's unsigned long variable size and then it does the proper math to keep a series of other unsigned longs that represent real clock time properly updated. Now that we've got that down, let's jump back into the implementation of millis to see how it pulls this back out to provide the easy-to-use value that made the implementation of delay that we saw above so clear (arduino-0015/hardware/cores/arduino/wiring.c):
First off, millis configures an unsigned long called "m" that it will use to hold the result once it's been calculated. Next, something funky happens. We store the value of something called "SREG" into a variable called "old_SREG". SREG stands for Status Register. The Status Reigister is a special register the AVR uses for holding the results of various different operations on the chip.
Remember that an interrupt breaks right into the flow of the executing program. Any code that deals with interrupts has a special responsibility to put things back just how it found them after it finishes it work, otherwise pre-existing parts of the program that depended on those values would be totally hosed, having had the rug pulled out from under them in mid operation. In order to fulfill this responsibility, millis saves the contents of the Status Register before it starts doing anything funny. That way, upon completion, it can put things back just how it found them and the rest of the program will resume smoothly, none-the-wiser of the interruption.
Having saved out the Status Register, millis goes ahead and calls cli(), "clear interrupts", a function that suspends the operation of any other interrupts. Since millis is going to read timer0_millis, a value we've just seen being updated in an interrupt handler, it needs to make sure that it has exclusive access to that variable, that it doesn't get grabbed by the interrupt handler itself right in the middle of things. If we don't disable them, interrupt handlers can fire at any time even while we're right in the midst of working with values that they modify!
Now, we've read out timer0_millis which has the "current time" so all we've got to do is restore the Status Register to its value from before we started monkeying with the interrupts and return the value we read out. But wait! We disabled the interrupts, but never re-enabled them. How come this code doesn't break all subsequent Arduino functionality that depends on them? The answer is that we did actually re-enable the interrupts when we restored the Status Register. One of the bits in the Status Register is the interrupt enable, which is set to allow interrupts to take place. Since that bit was set when we first arrived in this function, restoring the SREG to the value at which we originally found it has the very important side effect of re-enabling the interrupts and leaving everything hunky-dory.
Summary and Conclusion
We're done! We've now seen how every single step of the physical computing hello world on the Arduino actually works. Let's summarize it really quickly to make sure we've got everything straight. First, we configure pin 13 for output by setting a bit in Data Direction Register B. Then we turn pin 13 by setting its bit in PORTB. Then we delay 500 milliseconds by marking the current value of timer0, converted into milliseconds, and letting the counter be incremented repeatedly at each clock cycle and overflowed into ever larger holders until the new value of timer0 represents an elapsed time of 500ms. Next we set the bit for pin 13 in PORTB low to turn the LED off. We do the delay dance again and we're home.
All-in-all the process isn't that complicated, especially once you've gotten the hang of the basic architecture of the AVR and how to navigate the Arduino and avr-gcc source code. Granted, it took me about a year to grok both of those things, but that's why I've made it a point to set things down here for other people who don't want to spend quite the full 365.
I'm planning on making this post the first of a series. Next up, I'll tackle the digital-to-analog conversion functionality by diving into analogRead and analogWrite. After that I might try some of the more advanced topics like serial communication and maybe the bootloader. If you've got any suggestions or requests for topics, I'd love to hear them.
And finally, if you made it this far, definitely drop me a line to let me know if all of this made sense to you and if you found any mistakes or bugs in my write-up.
For awhile now, I've been very excited about _why's Bloopsaphone. Written as part of the coming Real Soon Now, new Hackety Hack, Bloopsaphone is a Ruby library for making 8-bit music and sound effects. _why intends it to be used by the kids to enhance their video games and what not. The code's been available on the Github for a while now and a few weeks back, I finally got a chance to install it, build it, and start playing around.
Bloopsaphone is built on top of Portaudio which is a cross-platform library for doing sound stuff. It provides a nice DSL for configuring sounds and giving them notes to play. The instructions for installing and building it are available in the Bloopsaphone README.
That same document also explains the design of the notation system, which works by consuming a series of letters and numbers separated by spaces. The numbers represent note values (8 = an eighth note, 4 = a quarter note, etc.) and the letters represent pitches in the tempered scale (A, B, C, etc). If you have a number next to a pitch that means play that pitch for the given time; if you have a number by itself that means rest for the given time.
The README has a couple of short examples (and the repo has a few other more extended ones), but no actual mp3s. Unless you go to the effort of actually installing Portaudio and building Bloopsaphone, you can't hear what it sounds like. So, I thought I'd record some of _why's examples and some of my early experiments and link them up here for interested parties to hear.
Our first selection is The Simpson's Theme as transcribed for Bloopsaphone in the README. I've included a gist of the code and an mp3 of the output below that:
The other code snippet in the README itself is the: Bloopsaphone Theme Song, which I think would make an awfully nice (though potentially homicide inducing) ringtone.
Digging around a little bit more in the repo I found a series of sound definition files, which I've transcribed to Bloopsaphone sounds and concatenated into the following mp3: Sound Effects Sampler. In the order they appear here, these are: jump, dart, error, ice, pogo, and stun. You can see how this sucker would be great for making sound effects for old-school games.
The last hidden treasure lurking in the repo turns out to be an entire piece of music that _why seems to have commissioned to demonstrate Bloopsaphone's capabilities: Cheeky Drat by freQvibez (I'm not sure if the crunchiness that happens towards the end of that mp3 is how the song is supposed to go or an artifact of it rendering badly on my machine; I think it's the latter).
The last couple of mp3s I've got for you are the results of my first experiments with Bloopsaphone. The first was inspired by a tweet of Andy's mentioning his search for chiptune jazz covers. It turns out that tweet was part of the run-up to Andy's awesome project, Kind of Bloop to commission chiptune covers of the the entirety of Miles Davis's masterpiece. I spent an hour or so transcribing the first 8-ish bars of So What: So What Intro in Bloops, which was a great way to really learn the Bloopsaphone notation system.
Since then, I've been working some on a piece of my own. Even though I've never made music in anything like this style, I've always greatly admired the insanely detailed non-repeating rhythmic programming in Aphex Twin's work. I thought Bloopsaphone would be a great medium to explore that style. I'm calling the very early results of that effort: longs.
In the last few weeks, I've spoken at two different conferences in two very different cities. The first, GoGaRuCo, was an intimate, one-track affair down in beautiful San Francisco. The second, RailsConf, was a giant behemoth in hideously surreal Vegas. What follows is a quick rundown on my experiences at each of the conferences and a summary of my presentations.
GoGaRuCoGoGaRuCo (the Golden Gate Ruby Conference) was one of the most satisfying conferences I've ever attended. It was relatively small (about 200 attendees) and was single track which created a great communal feeling of shared conversation in the halls between talks.
Now, if you read Ruby blogs, you might think that the most striking moment of the conference was the presentation of the pr0n slides. This could not have been further from the truth. In fact, I think one of the greatest tragedies of that whole incident was that it obscured a conference program that showcased, maybe better than any other I've seen, the incredible diversity of exciting things people are doing with Ruby.
If you judged solely by online conversation, you might think that the only thing people do with Ruby is build and try to scale web applications. GoGaRuCo blew that perception wide open with amazing talks on incredible developments in a new native OSX Ruby implementation, the use of Ruby in medical record keeping to fight AIDS in Malawi, the use of Ruby in open source voting technology to safeguard democracy, and many others. A hallmark of these talks was that they challenged the community to use the power of Ruby to make a real difference in the world outside of the web, something we don't advocate enough.
I'd like to think that my talk would be counted in this trend as well. I gave my traditional RAD presentation but with a few new demos (slides here: RAD at GoGaRuCo). I showed off The Git Bell (though I had a minor technical snafu in that one) and did some Archaeopteryx integration, playing MIDI generated by Arx out of a drum machine in Reason and then on an actual snare drum using a solenoid (video coming soon). Of course the drum demo which I was much more worried about went totally smoothly.
I want to specifically thank the organizers of GoGaRuCo, Josh Susser and Leah Silber, for putting on such a fun and broadening event. As the web application-based Ruby community grows and suffers the related pains, events like this are so important for reminding the community about all the other quirky, surprising, and meaningful things you can do with Ruby and people who put such dramatic effort into organizing them deserve our gratitude.
RailsConf
This year's RailsConf was bittersweet for me. Since I start grad school in the fall, this looks to be my last RailsConf for the foreseeable future. With my technical interests shifting away from the web towards physical computing, I feel less engaged in keeping up-to-date on new developments in the Rails world. Even though I think Rails 3.0 is exciting and heading in all the right directions, it's just less relevant to my technical life going forward than it would have been a year or two ago.
While I'm excited about this transition from a technical point of view, I feel melancholy at the prospect that it will separate me from all the great people I've come to know in the Ruby and Rails community in the last three or four years. It's a cliche that the most important moments in conferences take place outside the talks, but for me in Vegas it was overwhelmingly true: from hacking with Adam Keys on an AVR backend for LLVM, eating lunch in the Eiffel Tower restaurant with Eric Mill, planning the Remote Bike Mountain with Chad Fowler, comparing indie music concerts with Dan Dofter, talking UAVs with Ron Evans, debating music perception with Adam Wiggins, conspiring with Matt Amonetti on ways I can help out with MacRuby, to chatting about journalism, drawing, and programming languages with Yehuda Katz and Leah Silber.
I'm definitely planning on staying involved in the Ruby community in lots of ways, but the simple fact of no longer being a professional Rails developer will mean that I get to see all these great people a little less and that prospect makes me get all sentimental. Maybe I'm just a sap, but that's how it goes.
Anyway, my talk went pretty smoothly. I've put the slides up here: Giving Rails the Big 'F': Surviving Facebook Itegration unscarred. About half the audience had built Facebook apps before so I was glad I didn't dive too deeply into the details of the API in an introductory kind of way. People had some interesting questions, one of which I bungled kind of badly: I said that the Terms of Service prohibit you from placing ads or payment links anywhere in apps when it turns out that's only true for Pages. So, for anyone there, I apologize for the confusion. Other than that things went pretty well. Giving a talk without hardware demos seems almost like cheating!
In a recent post, Twitter API Lead and frequent unwilling flamewar spark, Alex Payne, called for the "reintroduction [of] logical thought and civil society" to online technical debate. In addition to the usual lamentations over the substitution of Language Wars and political polemics for hard-evidence, reasoned argument, and sympathetic dialog, Payne also made an usual call for programmers to acquire better tools for dealing with the softer, more subjective side of the debate:
Some technical discussions veer towards the purely aesthetic. Thankfully, the humanities have provided us tools for reasoning about that which hard science may not be able to measure. Spend some time with art and theater criticism and you'll find intellectual instruments aplenty for the comparative evaluation of seemingly intangible qualities such as beauty, theme, and emotion.
This struck me as both a great fresh idea and an area in which I might be able to help out. Before my recent life as a Rails programmer and startup founder I was an Art History major with a focus on 19th and 20th century art criticism and theory. I wrote my undergraduate thesis on a comparison of the Academy Awards to the art policy of Louis XIV's France and I worked for years at the Museum of Jurassic Technology.
While I definitely agree with Alex that programmers could greatly benefit from increased aesthetic literacy, the body of literature on the topic is immense and intimidating. As Alex himself mentioned in a recent tweet, Aesthetics stretches "as far back as the Poetics, as recent as Eco's 'History of Beauty'". It also covers texts of such divergent degrees of difficulty as Kant's Critique of Judgement and Leonard Maltin's 2009 Movie Guide.
So, as an aide to programmers looking to improve their ability to produce and critique aesthetic arguments, I've put together a short reading list of items I find both accessible and helpful. These texts vary from actual art criticism to art history and theory. They also vary in vintage — from the very recent to more than 100 years old — and in format — from serious book-length essays to short art criticism and reportage.
This list is by no means meant as a comprehensive survey but merely as a stimulating starting point comprised of ideas and voices I've found especially formative or provocative in my own aesthetic judgement. In an attempt to be a friendly and welcoming host, I've placed a high preference on works that are short and readable.
James Elkins
James Elkins is a professor of Art History, Theory, and Criticism at the School of the Art Institute of Chicago. He specializes in applying the visual analysis tools of art history and theory to a broad range of images (from popular culture to scientific imagery) and also in analyzing the history and difficulties of art institutions. His writing is clear, direct, and often quite funny.
How to Use Your Eyes is a book meant for a popular audience. It focuses on training the reader in the careful observation of their own reactions to visual phenomena in the natural, technological, and aesthetic worlds. It is a tour-de-force in the powers of observation and description that form the core of aesthetic judgement and communication.
Stories of Art is an eccentric survey of art history in all of its diverse forms of practice. Elkins starts with a series of drawings meant to tease out his own unique perspective and to invite the reader to do the same (see my in-depth post about this here: James Elkins' Idea Mapping Method). He then proceeds to look at a series of different art historical text from around the world, using their different focuses to denaturalize the traditional western narrative of art and to examine the usefulness of wildly other approaches. It's a great book for knocking art history off of the high pillar of importance and inevitability on which art historians tend to place the discipline. A fun read designed to greatly empower the reader to pursue their own course through the history of art and interesting objects.
Clement Greenberg
Clement Greenberg was probably the most influential and certainly the most controversial art critic of the 20th Century. He was closely associated with the Abstract Expressionist school of painters based in New York in the 40s and 50s (Jackson Pollock, Willem de Kooning, Hans Hoffman, et al). He rose to prominence as the school's advocate and then fell out of favor when he forcibly opposed the Minimalist and Pop Art movements that replaced it in the early 60s.
Greenberg is known for tying his aesthetic judgements of individual artists and artworks to a proposed linear narrative of the history of art. More specifically, he argued that the history of art represented a process of artists reducing each medium to the essential properties that were specific to that medium. In the case of painting this meant flatness and therefore abstraction. His arguments were forceful and based solely on the aesthetic qualities of the work he wrote about (rather than explicitly taking into account any political or social factors). He strongly advocated the importance of a small 'avant-garde' in advancing this march of aesthetic progress.
These views are closely associated with the idea of "Modernism" in art and opposed in a variety of different ways by a broad group labeled "Post-Modernist".
However we might now judge their conclusions, Greenberg's classic essays, especially "Avant-Garde and Kitsch", are models of clarity and compelling argument. He is especially expert at linking his judgements of specific works to a larger narrative or thematic argument. Also, Greenberg is required reading because much art writing in the second half of the 20th Century is, in one way or another, a response to his work.
Elaine Scarry
Elaine Scarry is a Philosophy professor at Harvard University. Her diverse work, on topics ranging from torture to aesthetics, covers the relationship of the physical world to the ethical lives of people. On Beauty and Being Just is a short, gorgeously written essay in which Scarry argues that our perception of beauty is the root of our sense of justice. For Scarry, beauty is the strongest mechanism for our surroundings to compel us towards empathy and action.
Scarry's writing effortlessly moves between the kind of intimate observation of personal perception in which Elkins specializes to a grand sense of perspective stretching back to Athenian political philosophy. This book is a powerful example of the interdisciplinary power of aesthetics and a rare example of clarity, poetry, and specificity in writing on such a potentially abstract topic.
Charles Baudelaire
Charles Baudelaire was a poet, art critic, and essayist in mid 19th Century Paris. He was the foremost champion of the emerging modern arts and a trenchant observer of contemporary popular life, especially Parisian street and cafe culture. In his epochal essay, The Painter of Modern Life, Baudelaire coined the term "modernity" and redefined the role of the artist as capturing the essence of the modern age, "its own carriage, its expression, its gestures". For an art world that had been bent on emulating the glory of the classical and renaissance worlds for hundreds of years, this was a revolutionary idea and Baudelaire's own writing (and life as a highly-visible dandy), lively beyond the usual bounds of civilized propriety, exemplified the radical change he proposed.
Baudelaire is the ultimate example of capturing a zeitgeist, articulating its aims, and enshrining it in history.
Roland Barthes
Roland Barthes was a French Philosopher in the middle of the 20th Century best known for his work on semiotics (Mythologies). Semiotics (and its related successor fields, Structuralism and Post-Structuralism) is an attempt to study the relationship between representations of the world and the things represented. At its worst, the field is often highly technical verging on obscurantist, but Barthes brought a profoundly personal engagement to his topics and a poet's ear to his arguments.
The best and most pleasurable of his books is also the one most relevant to a developing Aesthetician: Camera Lucida. Here, Barthes teases out what makes photographs (and snapshots particularly) so directly affecting to us in a way that is rare in the arts. It's an amazing combination of the personal and the general and a truly moving and poignant book that's also filled with distinctions (such as the studium vs. the punctum) that remain useful in discussing all kinds of potential objects of aesthetic delectation.
Other Critics
Obviously, any list such as this can barely scratch the surface. For example, I've left off two of my favorite more straightforward ciritics: Dave Hickey (the Hunter S. Thompson of art criticism), Peter Schjeldahl (art critic for the New Yorker) as well as a number of my favorite historians/theorists: Geoffrey Batchen and Jonathan Crary, just to name two.
One of the most important things to keep in mind when starting a survey of a field as immense as Aesthetics is that it's okay, even encouraged, for your knowledge of the field to be eccentric, personal, and full of gaps. Think of your reading in this area like your music collection: your goal isn't to listen to and love everything but to stay curious and wide-ranging enough find things that most delight and surprise you. This isn't Electronics or Compiler Theory. There isn't a linear progression of beginner to advanced texts and there are few universally accepted right answers. There is just appreciation (or the lack thereof) and its cogent articulation.
It is with great regret that I have to announce that Grabb.it will be shutting down operations at the end of this month. After almost two years of operation, we've simply run out of resources and can no longer keep the site online in its current form.
Even as we shut down, we are committed to avoiding simply vanishing into the digital ether and to preserving all of the amazing blog posts written by our thousands of users. In that spirit, we have decided to leave archived versions of the Grabb.it blogs in place permanently at their current urls. At the end of the month, we will turn off the searchable and listenable core of the site and publish each blog with all of its current posts on its own a single page (at its already existing URL; for example, mine is: http://grabb.it/users/greg). If you wish to export your blog posts into another service, the RSS feed on your blog will contain all of your posts and should make that transition relatively easy.
In addition, we will be making publicly available a significant chunk of the data Grabb.it gathered in two years of spidering the internet for music. While this data will not contain mp3s or other audio files, it will contain everything we learned about what sites were talking about what songs and artists. We hope this information will be useful to cultural historians of the early 21st century, internet technologists hoping to figure out how to improve the experience of music on the web, and many others. We will publish the data in SQL and CouchDB formats. More details as things are finalized.
On behalf of Jem and Chris, I'd like to thank everyone who supported Grabb.it from our investors to our users to our fellow geeks and musicians. While this was not the outcome any of us were hoping for when we began this project, it doesn't diminish the joy we got out of you and out of the music while it lasted.
Bit delayed compiling this month, but here ya go...
Waltz with Bashir (Movie)
Waking Life meets Shoah. (Note: there are some valid moral criticisms of this film.)
08 February 2009
Nightwatching (Movie)
It's consistently shocking that a director with Greenaway's visual pre-occupation and presentational aesthetic manages to make movies that are such convincing and moving character studies. This one features Martin Freeman from The Office in a surprisingly strong turn as a fleshy Rembrandt who struggles to navigate the political battlefield of golden age Amsterdam. The sets feel especially theatrical and the lighting is dead-on Rembrandt. The story turns out to be an especially heartwarming one of Rembrandt's devotion to his dying wife and then a series of other women. It's simultaneously a sad story of intimate personal loss and a deep exploration of the overwhelmingly rich Dutch material culture and their yet more overwhelming passion for intrigue.
15 February 2009
The Reader (Movie)
Highly faithful adaptation of Oprah's Book Club novel about the post-Holocaust generation of Germans coming to grips with their past told through the story of one teen's affair with a woman who turns out to have been an Aushwitz guard. The movie, like the book, is powerful and evocative while remaining strongly emotionally confusing along pretty much every available axis. Ralph Fiennes and Kate Winslet both give austere, quiet performances that live up to a standard of dignity and restraint that is vitally necessary for this kind of story but far beyond the reach of lesser actors. The kid playing the main character for most of the movie is great as well, providing a sensitive counterpoint to his surroundings and giving real potency to the film's sexual and sensual contexts.
16 February 2009
Coraline (Movie)
Stop motion animation is all about the physical presence of its materials — the magic of inanimate objects transforming into living, moving, flowing, flying, breathing, biting, burning things. Its art is the poetry of the similarities and differences between the materials of models and backgrounds and what they're used to represent. On this level, Coraline excels. It's astonishing, palpably beautiful and haunting, especially in 3D. Unfortunately, it stumbles slightly on basic bread and butter story telling issues: the pacing is leaden, the characterizations are generic (the wonderful John Hodgman is especially under used), and the structure is undramatic. Regardless of all this, it's worth seeing, if only to luxuriate in the materiality.
19 February 2009
Watchmen (Movie)
Despite mild doses of comic book-movie characterlessness, Watchmen managed to retain enough narrative momentum and lightness of touch that it didn't drag too badly, even at a midnight showing and a nearly three hour running time. It peaks with the opening credits: a stylized retelling of a super hero-filled 20th century america. A shame to see an actor like Billy Crudup vanish into another anonymous animated stiff. Walks an interesting stylistic line halfway between Sunshine and Sin City.
09 March 2009
The Steel Remains (Book)
First sword and sorcery epic from hard-boiled SF-head, Richard K. Morgan. Filled with Morgan's signature hyper-violence and hyper-sex (though homosexual for the first time in this case, which alters it not at all). As usual for Morgan it's a tale of veterans and scars. New violence acting to repress older, de-virginizing, violence. The main character is Morgan's most compelling since the Takeshi Kovacs books; you could imagine wanting to spend more time with him after this book's end despite its somewhat sagging, unfulfilling plot. Morgan takes to the fantasy element with gusto, inventing silly names with relish and a few really lasting images — like decapitated heads which are magically joined with tree stumps and only come to life when watered. An encouraging book from him after a few shapeless efforts.
09 March 2009
tUnE-yArDs - "BiRd-BrAiNs" (Music)
Intriguing new Marriage Records band. Sound on some songs like Karl Blau with a stronger African influence and on some like a junk-amplified version of Per Se. The second and third thirds of this record are better than the first.
13 March 2009
I'm proud to announce that I've been accepted at NYU ITP for this coming fall. I've been dreaming of going to ITP since I first heard Clay Shirky tell the story of Dodgeball and Pac Manhattan in 2005. Before discovering ITP, I didn't know anyone else shared my combination of interests in art, technology, and physical computing/motion control/miniatures/MJT/whatnot. Now, I'm incredibly excited to be joining a community dedicated to these pursuits and their various intersections.
While I can't wait to get started at ITP, I'm also sad to be leaving Portland where I've lived happily for more than 10 tumultuous action-packed years. There are more creative, interesting people here than any city this size has any right to expect and I'll miss them. Before that happens though, I've got a whole summer to fill with hanging out and things-we-always-planned-to-do. So, if you're in Portland and want to hang out or do some kind of project, come tell me and let's get to it!
I found out yesterday that my proposal for RailsConf 2009 was accepted. My talk is: Giving Rails the Big 'F': Surviving Facebook Integration Unscarred. Here's the description:
"If you want a vision of the [Facebook], imagine a boot stamping on a human face - forever."--George Orwell
Sooner or later, someone will ask you to write a Facebook app.
Scrabulous. Free Rice. Whopper Sacrifice. Some of the most wildly successful web apps of the last few years have been built on the Facebook development platform. With its enormous built-in audience and rich API for accessing its users' info and helping them communicate, startups and giant multi-national corporations alike see Facebook as an enormous opportunity.
For developers, it looks more like a screaming nightmare. Their APIs shift with little notice and are often broken. They offer a series of nearly indistinguishable API options (a "Canvas App" or a "Page App"?) that each have different gotchas. Their use of proprietary markup languages (FBML and FBJS) and (shall we say) unusual use of HTTP verbs present a challenge to maintaining a productive local development environment.
In this session, I'll lead you on a humorous romp through some of the more frightening corners of this nightmare world before showing how to make your way back to the calm and beautiful idyll you've come to expect from Rails development. I'll impart the hard-won lessons, I've learned building Facebook applications with Rails for big national brands including techniques for removing the worst pain points in the Facebook development process by letting you actually run your app locally. I'll also cover how to prevent the problems with Facebook from infecting the rest of your application. I'll survey the current state-of-play in Facebook libraries for Rails and present some of the recipes that have been most successful.
Many prospective thanks to my coworkers at StepChange for their help with the content of the talk.
See you in Vegas!
At first, I wasn't sure about the Tumblr Dashboard. Why would a blogging site re-implement a feed reader as an internal service? Why would I want my blogging software to encourage me to repeat other people, to be less original?
But as I started following more people, cool stuff started showing up there: beautiful random things I would never have seen otherwise; awesome links and quotes that were right up my alley. Heck, even just now opening up my Dashboard to grab the url for this post, I found and reblogged this story about last.fm handing over listener data to the RIAA, something right smack in the middle of my interests.
I even started wishing the Dashboard was richer. Why doesn't it recommend additional people for me to follow? Why doesn't it tell me who reblogs the things I post?
Hence rtumblr.
Built with the Google AJAX Search API, rtumblr is a one-page mashup that helps you find out who's reblogging you. You simply enter your tumblr subdomain and it'll give you a full list of which tumblr users have reblogged your posts along with links to each of their rebloggings. For example, here's the (somewhat skimpy) list of who's reblogged idfdz.tumblr.com. (Pro tip: it works with tumblrs with their own domains as well, just type your full domain name in the box; example: who's reblogged kungfugrippe.com)
I'm pretty psyched about the way the code behind this app came out. I think I've come up with an interesting pattern for doing single page javascript-intensive apps like this that have no server-side component but still have cool features like permanent urls and multiple screens. I already mentioned Srender, the tempating plugin that I built for jQuery, and I'll have more to say about the system I'm using for the routing and multiple screens shortly.
In the meantime, if you like rtumblr (or if you enjoy strange rube goldbergian mechanisms, stuff that glows, or pessimism about the state online music), follow me on Tumblr: idfdz.tumblr.com.
