Adam, you’ve put your finger on a couple of things. I’ll try to answer a couple of them:
It’s the differences between programming a computer and programming a microcontroller that make up the bulk of the problem. Not just the differences between a CPU and an MPU, but the differences in what you want to do with them. The AVR coding I’ve done so far is a lot less like the traditional exercises I got in my CS classes (data structures, data sorting, etc.) and closer to writing a device driver for a funky piece of hardware.
But as for them being able to program it? Shoot, I’d start now. My guess is they could’ve been playing around with the AVRs in parallel with their classes, and the knowledge transfer would’ve been great.
As for code re-write, that’s probably not 100% necessary. There are only a handful of compilers/assemblers that’ll build AVR code. Almost all of them are commercial. The one big huge exception is also the most platform-independent: gcc. I know this leaves out ImageCraft users, but if you cast all the examples in terms of AVR Studio / WinAVR (the Windows port of avr-gcc), you’ve covered 90% of the ground. And since this is the IDE/compiler used for the bulk of the application notes from Atmel, it’s a good choice to use in a manual as well.
What examples to include? Now that’s tough. It really is, because you don’t know what someone’s going to want to plug into one of these things. Blinking LEDs is good, and lends itself well to the Orangutan because they all have onboard LEDs. Spinning motors is another good choice because they all include a dual H-bridge. (Ok, so it’s an option on the X2.)
Past that? The cynical side of me says it all boils down to bit-fiddling, so the more examples that cover bit-fiddling, the better. (I swear, I see |= (1 << ?) and &= ~(1 << ?) in my sleep now.) But it helps to have more examples.
For the most part what’s left leans a lot less on programming and a lot more on how you view the world around you and tackle the tasks at hand. Good case in point: Making a motor spin at a particular speed. Simple enough. To tie this back to the whole device driver analogy, you’d expect there to be a motor(rpm) command. But on a micro there’s not. This one example would touch on speed control, pulse width modulation (and why you’d want to do that rather than simply varying the supply voltage or current for the motor), the concept of encoders, how to take the blinking LED example and turn it around to tack a counter onto an input pin to count pulses (the encoder), how to take the counter and a free-running system counter and turn it into a frequency, and how to go from that frequency to an RPM value for the motor. THEN the example would have to launch off into some sort of control loop theory so that the RPM reading from the motor could be used as feedback to the routine that’s generating the pulse width modulation for the motor. It stops being simple in a hurry.
One could take the easy way out and say this is all part of any good class on control loop theory, with some sensing thrown in for good measure. But at that point you’re left with a manual that essentially does what Joe was talking about: something that requires the user to go look up the textbooks for each of these fields.
Which is all my long-winded way of saying this isn’t easy, by any stretch of the imagination. Even Joe Pardue’s book stopped at reading the motor’s RPMs, and didn’t dive into control theory. So far his book is one of the better ones I’ve seen, and keep in mind it’s a book on programming microcontrollers, not a manual for the AVR Butterfly.
Tom