Third-Level Geek Stuff

[ArfinGreebly]

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.

[Firethorn]

I'm a Level-Three geek.

Also a Level 3 here.  Though currently stuck in a non-programming position.

After reading your rant, I have to say that it has to be one of those dead simple tricks that nobody ever bothers to explain, like what I tended to run into when I was first learning programming.  It's a new language.

After all, USB keyboards and mice are also interrupt based, non-scheduled input devices.

[Brad Johnson]

We've all thought you were a level three something, but "geek" wasn't it. 

Brad

[BrokenPaw]

The one I'm banging my head on at the moment is "asynchronous interrupt endpoint polling."

Ouch.  I don't have a solution for you.  I just wanted to say 'ouch'.

I'm a level-3 geek myself, and I just threw up in the back of my mouth a little.

Why didn't they call them something like "ready states" instead of "interrupts"?  Semantic hair-splitting it may be, but you check a ready state, whereas an interrupt...well, interrupts stuff.

-BP

[Brad Johnson]

Pardon me for not being the uber-geek you fellers are but it seems you're trying to combine things that shouldn't be.  I see endpoint polling as the task and asychronous interrupt meing the method.  I split the phrase into "endpoint polling" and "asynchronous interrupt" and googled both.  I got a ton of hits back.  To me it interprets as "endpoint polling via non-synchronized interrupt".

Or do I need to go back to Remedial Geek class and never comment on this again?

Brad

[RevDisk]

http://lwn.net/images/pdf/LDD3/ch13.pdf

There ya go. 


And more or less, you're correct Brad.  Sorta.   

[Harold Tuttle]

i would de-construct a USB scanner protocol

[ctdonath]

it seems you're trying to combine things that shouldn't be.

Welcome to USB programming. I had the joy of implementing USB2, both hardware & software, for Kodak just as USB2 was being released as an approved standard.

Indeed, there is much about the protocol that "shouldn't be" but is 'cuz that's the only way you're gonna make it work thanks to the underlying paradigm, which is "speak only when spoken to." Imagine a movie where the Alpha Male father insists the Good Child stay silent until invited to speak, which is long delayed out of spite, only to discover the thus-delayed news is "the house is on fire" or some such super-critical message.

[ArfinGreebly]

I see I'm not the only one who appreciates the oxymoron.

USB devices, as described above, can't originate a communication, they can only respond to requests.

You can send them commands, send them data, send them status queries, and so on.

But, recognizing that the world typically has data that won't wait or which, if forced to wait, will result in data loss, they cleverly provided a way for programmers to "tickle" the device, kind of a "ping" of sorts, whispering to the device, "so, got anything I should know about?" 

This, of course, is the equivalent of -- instead of waiting for the phone to ring -- picking up the phone handset every minute or so and saying, "Hello?" just in case someone might have called.

Software guys get cross-eyed at this prospect, because they know what that kind of thing can do to CPU overhead usage.

So, most of the USB frameworks seem to have this implemented as an internal, so you simply post a request to the core code, saying in effect, "here, I'm busy, so you check on this guy for me every few milliseconds, and call this number* if he has anything to say."  (* this number = a callback function somewhere in your code)

It happens that, if you want to use the Linux "user space" library (libusb) rather than hacking kernel code for your driver, this little piece of functionality seems to be missing.

That means I have to simulate it, basically doing the kind of thing the kernel does, only outside the kernel.

*Sigh*

I keep hoping I'll find someone who can say, "oh, dude, all you have to do is do a fill_urb() with this kind of value, and then write a scheduling loop that does a submit_urb() every [n] iterations, and you're good to go."

Which I'm pretty sure is what I'll wind up doing.  Given that I can figure out the proper values for that URB.

Did I already say *Sigh* ?

Yeah, I guess I did.

[RoadKingLarry]

Have you tried hitting it with a big hammer yet? That is always my favorite solution to problems like that if giving it a good kick or whack doesn't solve  the trouble first.

[Physics]

I suck at programming.  Maybe I should take some classes while they're free.

[taurusowner]

Now I remember why I switched majors from computer engineering to law enforcement 2 years into my schooling.  I hated this stuff.

[Jim147]

You got me thinking.
It's been almost 25 years since I wrote code. (I started young)
if/then goto
Not much different then Linux. But it took forever to get very little done.

I've stayed up a little bit. Even building a little Linux system a "few" years back.
I pulled out my old books to see what it had to say about USB drivers and didn't find much.

USB support is being developed. Links to projects are on linux.org under projects.

Sorry I can't help. But I might just pull that old system out and do a little playing.
Give me something to do when I can't get out to go shooting.

[2swap]

Ouch,seems as if you have quite a challenging task! I feel for you!

[ArfinGreebly]

: spin
  92 47 124 45 45 58 emit dup emit emit
  begin 8 emit dup emit swap 2swap key? until ;

Hmm . . .

C:\Forth83\f83 spin <enter>

:-
: -
: /
: -
: \
: |
: /
<keypress>

C:\Forth83>_

. . . or words to that effect.

2swap - pleased to meet ya.