Ports and Interfaces > USB
usb interruptions, I think?
ulao:
This does make sense to me but correct me if I'm wrong? The host in this case is windows 7, is the OS not the host? I could try a 10ms poll but from what I have seen windows ignores that and does 8 anyways. I tend to doubt windows has a bug that has gone unseen.
If I can rule out a host bug, the only possible issue then, is that the device is, as you said, not ready. My only guess is during the transfer of the control data the device is incapable of replying to the interrupt transfer. I guess ill try to debug that.
Bret:
I'm not sure if this will help or not, but here goes. Remember that the USB bus is a master/slave architecture. The Host is the master, and the device (in this case, your device) is the slave. You must do what the host tells you to do, when the host tells you to do it. Period.
As Jan eluded to earlier, when the host sends you a packet requesting something, you must respond immediately with something, even if it is simply a NAK. The host will only send one packet at a time down the bus. The packet could be an interrupt packet, one of the control packets (control transactions always involve more than one packet), or something else. The host cannot send you a control packet and an interrupt packet at the same time -- it is a serial bus (it only sends one bit at a time).
Also, exactly when you are sent each packet is not consistent. A packet can be sent to you any time within a frame (frames are 1 ms long in USB 1). You can get it at the beginning, middle, or end of the frame, and you have to respond appropriately and quickly no matter what. The host decides exactly which packets get sent when inside each frame.
ulao:
ret is does help but there is one issue.
--- Quote ---The host cannot send you a control packet and an interrupt packet at the same time -- it is a serial bus (it only sends one bit at a time).
--- End quote ---
I know studding screen shots is no fun... but if you take a closer look at mine you will see this issue.
channel 4 are my frames
channel 2 are my data (small data is the interrupt longer the control transfer)
channel 3 is just debug
Based on our collective knowledge, we all agree, it can not happen. The Host can not send a control transfer if the interrupt transfer is scheduled. It "seems" to be doing just that. If the host knows it has a interrupt scheduled, why would it send the control transfer?
Outside this issue yes, this does help. I didn't know why the 1 ms interrupts were on the line. So this is the frames. The more I learn the better I will be at figuring this out.
Correct me if I'm wrong, but the host is software, the USB OS driver, yes? My software tells the host to send a control transfer and the host should know better then to send it out when an interrupt transfer is scheduled.
Bret:
--- Quote from: ulao on September 07, 2017, 02:45:53 pm ---Correct me if I'm wrong, but the host is software, the USB OS driver, yes?
--- End quote ---
No, that's not right. It's a combination of hardware and software.
The software places transactions in memory that it wants the hardware to perform. The hardware reads those transactions from memory and sends them across the bus in an autonomous fashion, and then the hardware places the results of the transaction into memory (and generates hardware interrupts if the software wants it to) to notify the software of what happened. The software builds a queue of transactions it wants the hardware to perform. The hardware starts at the top of the queue, sends the packet it needs to out across the bus, waits for the device to send a return packet across the bus, and then tells the software what the device sent back (using memory and hardware interrupts). Then, the hardware goes to the next transaction in the queue and does the same thing again.
Exactly what happens behind the scenes in memory between the host hardware and software is very complicated, and even varies significantly depending on the type of host it is (UHCI, OHCI, EHCI, xHCI, WHCI, ...). There is also a priority mechanism inherent to the queuing process to make sure isochronous and interrupt transactions get precedence over control and bulk transactions. But the basic concept of the software queuing transactions in memory and the hardware issuing the transactions one at a time across the bus doesn't change.
ulao:
So my software does need to "not" send two transfer at once? This was clearly my misunderstanding. I figure the HID API I'm using was taking care of that. I'll follow up though angle. Thx.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version