I'm a Level-Three geek.
First-level geeks design and build hardware, circuitry, BIOS, stuff like that.
Second-level geeks design and write operating systems, compilers, assemblers, stuff like that.
Third-level geeks write applications, drivers, firmware, stuff like that.
There is some overlap. I've written a language interpreter, but mostly for myself, just to prove I could. I've written an assembler -- in a database language -- just because . . . But mostly I write applications and firmware, with the occasional device driver.
Currently, I'm writing a USB device driver for a vendor-specific set of devices, and the driver is running on Linux. It's a "user space" driver, as opposed to a "kernel space" driver. The library that supports this is called libusb 1.0 and the 0.9.3 release candidate just came out at the end of August.
I've spent the last few weeks looking for anything in the way of a decent book (like O'Reilly for example) that explains a couple of ticklish concepts.
The one I'm banging my head on at the moment is "asynchronous interrupt endpoint polling."
If you are a medium-to-hardcore programmer, that's going to sound like a software oxymoron.
Anyone who's ever written a serial port driver can tell you: one does not "poll" interrupts; rather interrupts "happen" and it's your job to catch them.
Not so in USB.
USB is a fully polled protocol. The "host" (usually the PC) has to ask the device if it has any interrupt data to transmit. At this point, the device, which has been dancing from one foot to the other with its knees together, gets to relieve itself of its high-priority "interrupt" data. It's not allowed, under the protocol standards, to actually interrupt the host, it has to wait to be polled.
Here's the deal.
I need to "tickle" the interrupt endpoint every 50ms or so to see if it has anything important to say.
Imagine an ATM. The computer in the ATM has a screen, keypad, printer, and a card reader. You come along and stick your card in. This isn't scheduled, you just walk up and do it. If the card reader is a serial device, it can just transmit the card information to the host CPU, and the host has to have a routine in place to "catch" the data, which will interrupt whatever the host was doing. This initiates a session, and various transactions can take place. If, on the other hand, the card reader is a USB device, it will not be allowed to tell the host that it just got your card until it's asked.
Because of some interesting quirks in USB, it's possible for a device to "take itself off the bus" and lose its device number, then reappear on the bus with a new USB device address.
It can be prudent for the host to keep track of the state of a USB device from which its expecting data.
This is accomplished -- at least in theory -- by "tickling" the USB device interrupt endpoint (polling it to "invite" interrupt data).
Trouble is, in all the documentation and books I've been able to lay hands on, nobody discusses the nuts and bolts of asynchronous interrupt pollng.
Arrrggghhh!
So, here I am, days later, doing trial and error. trying to get the right response, without knowing if I'm asking the right question.
Anyway.
Just had to vent.