I/o mechanism – Comtrol eCos User Manual
Page 724
Testing
intfill
The buffer will be treated as an array of 32-bit integers, and will be filled with the same integer repeated the
appropriate number of times. If the buffer size is not a multiple of four bytes then the last few bytes will be
set to 0.
byteseq
The buffer will be filled with a sequence of bytes, generated by a linear congruential generator. If the first byte
in the buffer is filled with the value
x
, the next byte will be
(m*x)+i
. For example a sequence of slowly incre-
menting bytes can be achieved by setting both the multiplier and the increment to 1. Alternatively a pseudo-
random number sequence can be achieved using values 1103515245 and 12345, as per the standard C library
rand
function. For convenience these two constants are available as Tcl variables
usbtest::MULTIPLIER
and
usbtest::INCREMENT
.
wordseq
This acts like
byteseq
, except that the buffer is treated as an array of 32-bit integers rather than as an array
of bytes. If the buffer is not a multiple of four bytes then the last few bytes will be filled with zeroes.
The above requires three additional parameters
data1
,
data*
and
data+
.
data1
specifies the value to be used
for byte or word fills, or the first number when calculating a sequence. The default value is
0
.
data*
and
data+
specify the multiplier and increment for a sequence, and have default values of
1
and
0
respectively. For example,
to perform a bulk transfer of a pseudo-random sequence of integers starting with 42 the following code could be
used:
bulktest 2 IN 1000 data=wordseq data1=42 \
data* $usbtest::MULTIPLIER data+ $usbtest::INCREMENT
The above parameters define what data gets transferred for the first transfer, but a test can involve multiple transfers.
The data format will be the same for all transfers, but it is possible to adjust the current value, the multiplier, and
the increment between each transfer. This is achieved with parameters
data1*
,
data1+
,
data**
,
data*+
,
data+*
, and
data++
, with default values of 1 for each multiplier and 0 for each increment. For example, if the
multiplier for the first transfer is set to
2
using
data*
, and arguments
data** 2
and
data*+ -1
are also supplied,
then the multiplier for subsequent transfers will be
3
,
5
,
9
, . . . .
Note: Currently it is not possible for a test script to send specific data, for example a specific sequence of bytes
captured by a protocol analyser that caused a problem. If the transfer was from host to target then the target
would have to know the exact sequence of bytes to expect, which means transferring data over the USB bus
when that data is known to have caused problems in the past. Similarly for target to host transfers the target
would have to know what bytes to send. A possible future extension of the USB testing support would allow for
bounce operations, where a given message is first sent to the target and then sent back to the host, with only
the host checking that the data was returned correctly.
I/O Mechanism
On the target side USB transfers can happen using either low-level USB calls such as
usbs_start_rx_buffer
,
or by higher-level calls which go through the device table. By default the target-side code will use the low-level
calls. If it is desired to test the higher-level calls instead, for example because those are what the application uses,
then that can be achieved with an argument
mechanism=devtab
.
620