PORTS Forum
Ports and Interfaces => USB => Topic started by: Jan Andersson on March 20, 2012, 05:35:06 am
-
Hello folks,
After struggling a long time with USB Devices I am now into developing software for an embedded host(NXP LPC2387). I am basing the work on NXP's library nxpUSBlib and I am currently trying to implement isochronous transfers to transfer audio. I have faced a problem which I don't know how to categorize, so maybe this isn't the right place to ask about it, though I hope I will get some clue what to do.
The problem is that the transfers must happen every frame(1 ms) and I seem unable to make that happen. In a PC it works that way. The library seems to do what I think is the right thing to do when queuing an IN-ITD, i.e getting the current frame number + 1 so that the IN transfer should be sent the following frame. But that is not what is happening, instead there is a frame in between before the IN transfer takes place, i.e it looks like it would be scheduled for current frame number + 2, not + 1. So when the data arrives one ms to late I repeat the ITD queuing and so the process is repeated resulting in one data transfer every 2nd transfer instead of every.
I have tried to change the code so it uses current frame number instead of current frame number + 1, but then no transfers at all take place, which I think is OK since the HC then sees the transfer as outdated. Also using current frame number + 2 gives just another frame in delay, i.e the transfer happens on the 3rd future frame.
I have also tried to queue two ITDs at the same time, using current frame number + 1 and +2. Doing so causes the first transfer to occur like before, after the 2nd frame, while the 2nd transfer then happens as expected in the next frame.
-
>I have also tried to queue two ITDs at the same time, using current frame number + 1 and +2. Doing so causes the first transfer to occur like before, after the 2nd frame, while the 2nd transfer then happens as expected in the next frame.
From here can you continue to schedule transactions every frame?
Jan
-
>I have also tried to queue two ITDs at the same time, using current frame number + 1 and +2. Doing so causes the first transfer to occur like before, after the 2nd frame, while the 2nd transfer then happens as expected in the next frame.
From here can you continue to schedule transactions every frame?
Jan
No, initializing a new transaction will repeat the mentioned behavior with the one-frame-delayed first "packet".
-
I have no answer, but it does seem to be a timing issue where a request for a transaction doesn't reach the controller in time to schedule it in the next frame.
Jan
-
Sounds like you're falling inside the isochronous scheduling threshold for the controller. OHCI doesn't have a formal definition for IST, but if you're to close to the current time, a controller might not touch a transaction. On our desktop systems, we always advise people to start their isoc scheduling several frames (like 10 say) frames ahead of the current time. I could imagine this would be even more critical for an embedded system as the CPU might take longer about actually scheduling something.
I'd try starting your Isoc several frames in front of current time, and scheduling more frames at once.
-
Aha! That was indeed valuable information! Seems to be exactly what is happening! I have now modified my code/the USB stack so that it always stays ahead, i.e it never let the queue of IN requests become empty, and that works.
Thanks!!