I/o mechanism – Comtrol eCos User Manual

Page 724

Advertising

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

, 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

data*

and

data+

specify the multiplier and increment for a sequence, and have default values of

and

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

using

data*

, and arguments

data** 2

and

data*+ -1

are also supplied,

then the multiplier for subsequent transfers will be

, . . . .

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

Advertising