I'm trying to poll my device to see if EP6 Out is armed, just to check if it is armed, not to actually transfer anything. I want to use EP0 to check that and get a response in my host. Any clues? Gabriel Camiro
I believe you are talking about Cypress EZ-USB FX2(LP). Aren't you?
a) What is the USB class implemented on the device?
b) Is EP6 declared in any endpoint descriptor?
c) Can you replace the firmware on the FX2, for the customization of this task? Or, you have to do this job without any customization on the FX firmware, just on the host app (or device driver) side?
Tsuneo
It is FX2. What I want to know is if there is a register in the FX2 that would determine if and en endpoint is armed. EP6 is configured as IN endpoint and Bulk. I want only to Read from the host if the endpoint is armed. I figured that if I send a vendor command that would return via EP0 an answer byte to the host to know if EP6 is armed or not. My question is, if there is a register within FX2 that can determine that.
"EP6 is configured as IN endpoint and Bulk. I want only to Read from the host if the endpoint is armed. ... My question is, if there is a register within FX2 that can determine that."
See this chapter of EZ-USB Technical Reference Manual (TRM) 8.6.2.3 EP2CS, EP4CS, EP6CS, EP8CS
EP6 has multiple buffers. Then, single ready flag is not enough to show the state of these buffers. NPAK[2:0] on EP6CS indicates the number of ready buffers. When EMPTY bit of EP6CS is set to '1', there is no ready buffer. On the TRM, they often use the ambiguous word "armed" to mean data is ready on the endpoint. But I don't think this is a good expression. It will be misunderstood as "configured". Just Cypress uses this word, no other one on this field. "The endpoint is ready" or "loaded" is the common expression. "I figured that if I send a vendor command that would return via EP0 an answer byte to the host to know if EP6 is armed or not."
Are you calling ReadFile synchronously on your host app? Then, learn about asynchronous (OVERLAPPED) call. It is the must on USB programming on the host app.
Synchronous ReadFile blocks the thread on your host app, until the endpoint is ready and the transfer finishes. In this reason, you need to know if it is ready or not. However, OVERLAPPED ReadFile doesn't block the thread. It completes when the transfer finishes, and your app is notified by the completion callback (ReadFileEx) or the OVERLAPPED event or Wait-API (WaitForSingleObject, etc). For USB programming, there is no difference from usual OVERLAPPED file access.
Tsuneo, Thanks a lot for this response. It has been indeed helpful. Regards, Gabriel Camiro