April 2008 Archives
Writing GUI applications in Objective-C is easy thanks to Cocoa. It takes care of a lot of mundane things like setting up the standard main function, running the event loop, and handling preferences. If you write a command line application in Objective-C, though, you don’t get very much help. You’ve got to remember to setup an NSAutoreleasePool (assuming you’re not using garbage collection) and parsing command line options is left up to you. This is unfortunate, as handling options “properly” is one of the more important aspects of a command line application. This means handling long options (those with a double dash) and short options (those with a single dash).
Thankfully, you do get some support for parsing command line options from the FreeBSD layer in the form of getopt_long(3). But using getopt_long is a bit of a pain: you’ve got to setup a structure of options, then repeatedly call it, followed by a switch statement. See the example in the man page. Yuck!
In order to simplify all aspects of writing command line applications I’ve written ddcli, a framework for writing command line applications in Objective-C, released under the MIT license, of course. The meat of it is an Objective-C wrapper around getopt_long that (ab)uses Key-Value Coding to simplify parsing options. But it also does things like setup the autorelease pool and provide handy wrappers around printf that work with the %@ format. Check out the extensive Doxygen documentation for examples and API reference. I think it makes writing command line applications a lot more painless.
Whether distributing Mac OS X software as a disk image (DMG) or a zip file is “better” (or “easier”) for the user is still an open debate. However, there’s one technical difference to be aware of: the permissions of the installed application are slightly different. They aren’t different enough to affect anything, but it is still interesting to know for Unix geeks like myself.
Not one to let sleeping dogs lie, I wanted to know why the MOSI pin was only being pulled down to 2.8 V with the 1.5K Ohm resistor on R6 in my previous post. The resulting schematic is this fairly simple transistor circuit:
Seeing schematics with transistors in them brings back a flood of memories to my college days when I was taking EE classes and I used to know how to do this stuff in my sleep. Unfortunately, that was about 15 years ago, and now a schematic like that looks like gibberish. It was bugging me that I used to be able to figure this stuff out, so I pulled out my old textbooks. Those were nearly as incomprehensible as the schematic, unfortunately.
Luckily we have teh internets these days, and I found instructions on transistor circuit analysis that I could actually understand on the website for EECS 312 at the University of Kansas. Kudos to Prof. Stiles for making this understandable. This transistor is in saturation mode, and I calculated the emitter voltage to be about 2.7 V. I measured the voltage drop to be 2.72 V with the scope, which you can see on the right side of the scope’s screen in this picture. It’s nice when theory and practice align. It’s even nicer when I don’t have to show my work.
In my post about the STK500 and USBtinyISP, I linked to a thread about how to fix a design error in version 2.0 of the USBtinyISP. It mentioned shorting out R6 and R7 to fix communications errors during programming. I did this, but I was still having trouble programming over ISP while I had the LEDs connected. bbum mentioned that he was able to program with LEDs attached, so I suspected something about my setup. At first, I thought it was specific to the STK500, but it turns out the problem was with the USBtinyISP itself. The STK500 just tweaked the right conditions to expose it.
The thread mentions shorting out R6 and R7, but that was in reference to the v2.0 schematic where R6 and R7 are in series with the MOSI and SCK signals. Unfortunately, the v2.0 circuit board has R6 and R4 mislabeled on the silkscreen: they’re swapped! So if you followed the instructions and shorted out what’s labeled as R6, you really shorted out R4. This not only doesn’t fix the MOSI signal, it also connects the red LED up to an I/O port without a current limiting resistor. Now you’ve got two problems.
The proper fix is to short out what’s labeled on the PCB as R4 and R7. Once I did this, it fixed my avrdude communications errors with LEDs connected. If you did short out what’s labeled as R6, I suggest you put a 1.5K Ohm resistor back to properly limit current through the red LED. Hopefully ladyada will update the official instructions about this, and even build a v2.1 version of the PCB without the 1.5K resistors on MOSI and SCK.
Here’s a picture of the final result. Read on for details and more pictures about the problem.
