Breaking News
Product News

USBTMC Unwrapped

More Related Links
View Comments: Newest First | Oldest First | Threaded View
User Rank
Re: A question about the interrupt endpoint
coldwell   4/14/2016 2:25:53 PM
The idea is that on a GPIB bus, one of the devices pulls down the SRQ line (which is a bussed, open-collector signal shared by all devices), but the controller does not know which device pulled it.  So it polls every device on the bus sequentially ("serial poll") retrieving the status bytes to figure out who rang the bell.

On USB, there's no ambiguity about which device is requesting service: it is the one that sent a packet (containing the status byte) on the Interrupt-IN endpoint.  So the semantics are a bit twisted, but you could say the device "polled itself" when it identified itself to the controller as requesting service (as opposed to the controller identifying the device by reading its status byte).

User Rank
A question about the interrupt endpoint
roebu   2/6/2016 10:09:54 AM
The article states....

To work around the long first-byte latency of USB, USBTMC devices automatically serial-poll themselves when they need to request service, and return both the SRQ line and the status byte in a single transmission. The advantage is that the host can receive the status byte without generating another USB transaction.

I do not understand what "serial-polling themselfs" could mean. I understood, that all transmissions are initiated by the host. Self-polling does not fit into this picture.

Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed