Page 1 of 1

Advantages of Interrupt-In vs polling via Control-Transfers?

Posted: Sun Nov 09, 2008 3:29 pm
by Alloc
Hi,

I'm currently looking at the RemoteSensor example because I want to create a device which should send data to the host "itself".
I'm wondering where the advantages of an Interrupt-In are compared to simply polling the device through Control-Transfers.

Looking at the host-code in the example:

Code: Select all

        /* wait for interrupt, set timeout to more than a week */
        nBytes = usb_interrupt_read(handle, USB_ENDPOINT_IN | 1 , (char *)buffer, sizeof(buffer), 700000 * 1000);
        if(nBytes < 0){
            logPrintf("error in USB interrupt read: %s\n", usb_strerror());
            goto usbErrorOccurred;
        }

Couldn't I simply use a controltransfer instead of usb_interrupt_read and get the same result?

Regards,
Chris

Posted: Wed Nov 12, 2008 3:44 pm
by christian
The interrupt-in blocks until the device sends interrupt data. This is an advantage for the host side software because no CPU time is used for polling.

Posted: Fri Nov 14, 2008 1:04 am
by Alloc
Thanks christian, that explains why it's there at all :D
But because of USB's single-master architecture "someone" still has to do the polling... Is that done by the host-controller or does the OS have to do this (which in turn would basically mean it's using some CPU-time, just better organized?)?

Regards,
Chris

Posted: Fri Nov 14, 2008 12:43 pm
by christian
I don't know. At least for bulk endpoints, it's done by the controller hardware. The polling is so fast that it would block the CPU otherwise. Interrupt endpoints might be implemented in the kernel driver's timer interrupt. This is still VERY efficient, compared to polling from user space.

Posted: Sat Nov 15, 2008 3:53 am
by Alloc
Thanks =)