Mike Hewner's Homepage

Even though I really don’t play with my hardware toys much anymore, I keep an eye on the hardware hacker blogs. So when I heard rumors of the CUI32, I admit that I was salivating a little. I told myself it might be a good platform to teach a summer workshop to some high school students. This is like a star-wars fan telling you the $45 Bobba Fett miniature he just bought is “for his kids”.

But the is pretty hot. Designed for USB. Built in BASIC. Plus there seems to be a built-in bootloader so you don’t need an external programmer.

There is not a ton of documentation for this device. In particular, I had a heck of a time figuring out how to get Linux to communicate with its serial BASIC tty interface. By doing a “ls /dev/tty*” I could see there was a serial device called “/dev/ttyUSB0”. But how to talk to it. I tried minicom but it kept giving me errors. I was wondering if there was some mysterious undocumented setting about party, flow control, or some other madness that I never really understood.

Then I tried putty.

putty -serial /dev/ttyUSB0

Worked like a charm.

I’m staying home sick today so I’ve had time post a few things that have been in my blogging backlog.

So a few weeks ago I gave a talk about IO and subroutines in the introductory architecture course I was observing. This is the sort of course that CS survivors have nightmares about. The course consists of:

1. lecture – 90 minutes of agony in which the professor describes breathlessly how exciting interrupt driven IO is and you consider stabbing yourself in the eye with a pencil
2. lab – a frenzied rush to finish the lab assignment and get out before the TAs get in lecturing mode and you have to hear about interrupt driven IO again
3. and homework – in which you realize you don’t understand interrupt driven IO after all at 4am in a darkened lab attempting to understand a textbook that seems to have been translated from the original Latvian by babelfish

Now the regular professor is a great speaker who can make even the most mind-freezingly boring topic seem hilarious and interesting. Seriously, this guy went on for 15 minutes on the PDP-8 and while it was going on I completely believed it was exciting and extremely relevant to my life. He also has a grizzled war-vet kinda aura about him that suggests he takes no crap; if he was my professor I would live in mortal fear that if I don’t learn assembly he would one day swoop down upon me like batman and leave my bloodied body hanging from the Klaus rafters as a warning to the other slackers.

But education psychology research has long shown that funny lectures and the occasional beating can only get you so far, especially in this modern age where every laptop provides an infinite supply of funny cats. More to the point, expecting students to remember 8 different details about the way memory mapped IO and subroutines are implemented in assembly is just asking for sadness at exam time unless you’ve built in a little bit of practice and reinforcement.

What was most gratifying about the lecture was the fact that students really seemed to enjoy the activity I had them do. I was pretty concerned that since their regular instructor basically runs a straight-up lecture, they would be resistant to doing anything. Apparently there were a few slackers in the back not working but in general people seemed to do the activity, talk about what sounded like the right stuff after they did the activity, and rate the activity highly on my student feedback forms. Look here if you’re curious on the feedback I got http://bit.ly/aiElj0.

I chose the activities I did (fill-in code blocks and finding bugs in existing code), partly because they were easy, partly because I think students think of coding as a very authentic activity, and partly because I could have specific right answers to hold students accountable and give them feedback. I worry a bit that if I were to teach several consecutive lectures, keeping activities like these fresh could be a problem.

What worked less well was my complex datapath handout. I upped the ante on myself here, because this was something not really covered in the professor’s initial lecture notes. Even the book didn’t really explain this very well: I had to go in and look at a really obtuse and scary state diagram to figure out what was going on. And I have had theory courses, so I assure you that if I say a state diagram is scary, it absolutely is. But I felt understanding the connection between memory mapped io and the hardware was important, and I felt that it would help reinforce the datapath analysis they did in the previous chapter.

So I made a complex diagram. And it took me a very long time. And then in the end, I felt it was confusing. Next time I’m going to put my complex diagram on the fancy overhead box and take some highlighters to it. That will help I think.

My handouts

My slides for IO (annoyingly google docs won’t preview this one)

My slides for subroutines

Video of me (part 1 & 2)
http://play.media.gatech.edu/v/public/buzzbox/cetl.gatech.edu/CETL_Practicum/mhewner3-2010-02-23A.mp4
http://play.media.gatech.edu/v/public/buzzbox/cetl.gatech.edu/CETL_Practicum/mhewner3-2010-02-23B.mp4

Awesome is my favorite window manager. It just warms your heart to see it running there in the process list whenever you do a ps –wwaux. And the fact that it is a very nice, flexible tiling window manager is just icing on the proverbial cake.

But it always annoyed me that it didn’t integrate with gnome. I like my drop down application list, complete with wireless control panels and shiny point-and-click applets. Maybe it’s a sign that I’m comfortable enough with my geek-cred that I can admit that. Of course I set all that stuff to autohide so no one looking over my shoulder can can know that I have wimped out.

Now I’ve figured out how to get it working properly. The details are all here: http://awesome.naquadah.org/wiki/Quickly_Setting_up_Awesome_with_Gnome