User manual

Code Mercenaries
10
II
II
OO
OO
--
--
WW
WW
aa
aa
rr
rr
rr
rr
ii
ii
oo
oo
rr
rr
55
55
66
66
5.Device Operation
Due to the fact that all current operating systems
offer an especially easy access to devices in the
HID class, IO-Warrior was designed as a generic
HID device.
By identifying as a generic HID class device IO-
Warrior avoids being controlled by any of the
higher level system drivers, which makes it
possible to access IO-Warrior from application
level.
5.1 Accessing IO-Warrior
A common misconception with USB is to think
you can "talk to the USB port". The truth is that
you do that as likely as you are going to directly
talk to your Ethernet port or PCI bus.
Communication on the USB is always with a
specific device attached to the USB. The USB
itself is only the medium through which you
communicate.
To get access to a certain device you have to look
for the VendorID and ProductID of that device.
The specific mechanisms for doing so depend on
the individual operating system.
For details please refer to our sample code in the
SDK.
5.2 IO-Warrior communication
IO-Warrior56 has five USB endpoints. Endpoints
are like virtual communication ports into or out of
the device.
An endpoint can be assigned to an interface.
Interfaces are like virtual devices or subsystems
within a device. IO-Warrior uses interface 0 to talk
to the pins directly and interface 1 to talk to the
special mode functions.
Endpoint 0 is a standard endpoint that is present on
all USB devices. It does use the control transfer
mode and is used by the system to get information
about the device and to configure the device.
Endpoint zero can also be used to send data to the
devices functions. The low speed IO-Warrior chips
use Endpoint zero for output data, IO-Warrior56
has dedicated Endpoints for the output data to
achieve a higher performance.
For input data IO-Warrior is using endpoint 1 as an
interrupt-in endpoint. "Interrupt" is a bit
misleading in this case. For USB "interrupt" means
that data is sent when there is new data available.
The host computer is periodically asking the device
for new data. The device itself can not initiate the
data transfer. IO-Warrior sends a new report any
time it detects a change to the input pin status.
Output data to the I/O pins is send to Endpoint 2
which is also an interrupt type endpoint. A seven
byte report directly sets the status of the port pins.
Special mode functions receive their commands
via Endpoint 4, also interrupt mode. The report
size for the special mode functions is 63 bytes plus
the report ID. This enables a single IOW56 special
mode command to transport ten times more data
than on the low speed IO-Warrior chips.
Reactions to commands to the special mode
functions are sent via endpoint 3, also in interrupt
transfer mode.
Since IO-Warrior56 uses interrupt out endpoints it
can not be used with USB 1.0 hosts (i.e. Win98),
USB 1.1 is required as the minimum.
5.3 IO-Warrior input behaviour
IO-Warrior checks the status of all pins once every
millisecond. If it detects a change from the last
status a new report via endpoint 1 is issued. Pins
which are currently used by a special mode
function are not checked. Reports are send to the
computer in 1msec intervals.
The worst case latency from a status change to
sending off the report is 2 ms unless the operating
system adds additional latency.
5.4 IO-Warrior output behaviour
Upon receiving the report IO-Warrior writes the
new data to the output pins in groups of eight pins
each. Pins 0.0 to 0.7 get the new data first, then 1.0
to 1.7, 2.0 to 2.7, and last 6.0/ 6.7.
The time between the individual ports is about
1sec.
5.5 Using pins as inputs or outputs
All I/O pins on IO-Warrior can be used as input or
output pins.
All pins act as inputs all of the time. When
receiving an input report from IO-Warrior you
always get the current input status on all pins
except for those currently used by special mode
functions..
Writing a 0 as output value to any pin causes it to
drive the pin low with an open drain driver.
Usually this will result in this pin being read as a
zero input as well, unless so much current has to be
drained by the pin that the voltage remains above
the threshold level.
Writing a 1 to a pin causes the open drain driver to
be turned off. The pin will be pulled high by an
internal pull up resistor. Now the pin acts either as
an output with a high level, or can be used as an
input.
V 1.0.3, November 6nd 2012 for chip version V1.1.0.1