User manual
Code Mercenaries
12
II
II
OO
OO
--
--
WW
WW
aa
aa
rr
rr
rr
rr
ii
ii
oo
oo
rr
rr
5.0 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. While this does not exactly fit the
device it makes using it a lot easier.
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 people new to the
USB is that they think they 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 refer to our sample code.
5.2 IO-Warrior communication
IO-Warrior has three 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. IO-Warrior is using endpoint
zero for the output data and to send commands to
the special mode functions.
A SetReport request sending a four byte output
report (two bytes for IOW24) to interface 0 sets the
port pins. SetReport requests to interface 1 with a
length of 8 bytes are used to control the special
mode functions.
For input data IO-Warrior is using endpoint 1 as an
interrupt-in endpoint. Interrupt in this case is a bit
misleading. 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.
Reactions to commands to the special mode
functions are sent via endpoint 2, also in interrupt
transfer mode.
5.3 IO-Warrior input behaviour
IO-Warrior scans 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.
Some care must be taken to not input signals with
frequencies too high for IO-Warrior to handle
properly.
Should the signal return to its former status before
the new report is send off this report gets
overwritten by the next one indicating the original
status. So it will look like nothing happened.
Due to the protocol specifics of USB it is only
possible to send one report every 10msec. Though
most OSes implement their USB in a way that
results in one report every 8msec.
5.5 IO-Warrior output behaviour
Upon receiving a SetReport request 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 3.0 to 3.7.
The time between the individual output chunks is
about 1.5sec.
5.6 Using pins as inputs or outputs
All I/O pins on IO-Warrior can be used as input or
output pins.
Basically all pins act as inputs all of the time.
When receiving an input report from IO-Warrior
you always get the current status on the pins.
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 at it gets above
the threshold level (you will see this when driving
the LEDs on the starter kit).
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.1.0, December 2nd 2013, for chip revision V1.0.3.0 and up