Ok, since Robert has answered my inquiry here before, I'll copy his
comments on my follow up questions :
I was asking about the IOWarrior.
Not sure what you mean by 8 msec is used by Windows ? Is this a time
restriction Windows imposes on USB devices ?
USB is a polled bus. No device can initiate a drata transfer of its
own. The host controller polls the devices in hardware. Each device
tells how often it wants to be polled. The IOWarrior tells it wants
10 msecs. Windows then polls with the nearest power of two = 8 msecs.
So a short pulse change of the inout logic state could be missed ?
Only a second change. The microcontroller detects the change and keeps
the info until the host controller calls for the data. Any changes in
that period get lost (i will ask if that is true).
I thought that devices that fire events into a program would be easier
to work with instead of my having to poll them continuously. I didn't
realize their drivers are actually polling anyway and generating the
event. Or is there some way to not have to poll ?
I think the above explanation tells that there is already enough
polling
If that's the case, I could use say a multimedia timer within my own
code to periodically poll the device's IO states. I've found the
multimedia timer to be very immune to other tasks such as minimizing a
window, dragging a scrollbar, etc.
No real reason for that. The delays on USB are mainly hardware
induced. USB is not real-time anyway. it is a serial bus not a serial
line.
Best tell which frequency of input alterations you want to detect.
From there on it is possible to decide if you need a microcontroller
to handle it on its own. Windows is definitely not usable below 1
msec.
Robert Marquardt
