Alan Stern wrote:
On Fri, 10 Dec 2004, Toralf Lund wrote:
I think I've mentioned this before; I have this custom USB on which I've programmed the firmware myself, that I'm using the Linux USB drivers to talk to. No specific device driver, just libusb (usb_bulk_read(), usb_bulk_write())
Now, I've eventually got this working mostly right, but there is one (minor?) issue remaining:
I sometimes get a "missed start of frame" error on the device side. It seems like this happens on (some) occasion when the device uses longer than usual on its "end of frame" handling - it stays longer in the associated IRQ handler. My host software is *not* trying to write data when this happens, as it will wait for feedback from the device before it sends more data. (and the current transfer is complete, right?)
Can anyone here explain what is going on? For instance, where did this frame that I'm supposed to have missed come from?
Every millisecond, at the start of a new USB frame, the host controller will broadcast a Start of Frame (SOF) packet. That's true even when there's no other activity on the bus. Among other things, receiving this packet causes devices to see that the bus hasn't been suspended. It sounds like your handler is causing the device to miss the SOF.
I see. This really explains a lot!
OK. I guess I'll try to read the fine print... I must admit I was being lazy this time, and didn't check the spec again before I posted to the mailing list. Actually, I've never thoroughly read the 2.0 spec, as I mainly used the 1.1 one while developing.
I know asking about this here is a somewhat long shot, but I though perhaps you could tell me more about the real-time requirements of the driver, the retry mechanisms etc.
The real-time requirements are spelled out in the USB 2.0 specification, if you know where to look for them.
Many of them are handled automatically by hardware in many device controllers. The same goes for retries (most of this is done in the host anyway, not in the device).Yes. Mine definitely handles most of these things. I concluded earlier, however, that it gets rather confused unless the software "acknowledges" certain events (by clearing register status bits) as and when they are received, even when no software intervention is actually necessary. In other words, masking the associated interrupts to the processor appears to be a bad idea.
The actual requirements for your driver depend very much on the particular hardware you are using.Of course. I haven't fond a lot about timing in its spec... From what you are saying above, it seems obvious that my EOT handler has to finish in less than 1ms, though - or it might block the SOF one for too long. Or I need to allow one USB ISR to interrupt another, but I'm not sure I want to go there... The system will queue the SOF event, of course, but receiving another before the first is handled leads to problems - that's what the "missed SOF" interrupt indicates.
I'm not sure missing the SOF is really a problem, though, since the software doesn't really do anything when its received, but like I said, it seems like the controller might get confused if the "SOF" status flag isn't reset properly.
I can't help you with that.
You've already helped a lot. Thanks.
- Toralf
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
