📄 usbs-testing.html
字号:
</P></DD><DT><TTCLASS="VARNAME">control()</TT></DT><DD><P> This array holds information about the control endpoint. It contains two fields, <TTCLASS="LITERAL">min_size</TT> and <TTCLASS="LITERAL">max_size</TT>. Note that there is no variable <TTCLASS="VARNAME">control_endpoints</TT> because a USB target always supports a single control endpoint <TTCLASS="LITERAL">0</TT>. Similarly the <TTCLASS="VARNAME">control</TT> array does not use an endpoint number as the first index because that would be redundant. </P></DD><DT><TTCLASS="VARNAME">isochronous_in_endpoints</TT> and <TTCLASS="VARNAME">isochronous_in()</TT></DT><DD><P> These variables provide the same information as <TTCLASS="VARNAME">bulk_in_endpoints</TT> and <TTCLASS="VARNAME">bulk_in</TT>, but for endpoints that support isochronous IN transfers. </P></DD><DT><TTCLASS="VARNAME">isochronous_out_endpoints</TT> and <TTCLASS="VARNAME">isochronous_out()</TT></DT><DD><P> These variables provide the same information as <TTCLASS="VARNAME">bulk_out_endpoints</TT> and <TTCLASS="VARNAME">bulk_out</TT>, but for endpoints that support isochronous OUT transfers. </P></DD><DT><TTCLASS="VARNAME">interrupt_in_endpoints</TT> and <TTCLASS="VARNAME">interrupt_in()</TT></DT><DD><P> These variables provide the same information as <TTCLASS="VARNAME">bulk_in_endpoints</TT> and <TTCLASS="VARNAME">bulk_in</TT>, but for endpoints that support interrupt IN transfers. </P></DD><DT><TTCLASS="VARNAME">interrupt_out_endpoints</TT> and <TTCLASS="VARNAME">interrupt_out()</TT></DT><DD><P> These variables provide the same information as <TTCLASS="VARNAME">bulk_out_endpoints</TT> and <TTCLASS="VARNAME">bulk_out</TT>, but for endpoints that support interrupt OUT transfers. </P></DD></DL></DIV></DIV><DIVCLASS="REFSECT1"><ANAME="AEN17142"></A><H2>Testing Bulk Transfers</H2><P>The main function for initiating a bulk test is<TTCLASS="FUNCTION">usbtest::bulktest</TT>. This takes three compulsoryarguments, and can be given a number of additional arguments tocontrol the exact behaviour. The compulsory arguments are:</P><P></P><DIVCLASS="VARIABLELIST"><DL><DT>endpoint</DT><DD><P> This specifies the endpoint to use. It should correspond to one of the entries in <TTCLASS="VARNAME">usbtest::bulk_in_endpoints</TT> or <TTCLASS="VARNAME">usbtest::bulk_out_endpoints</TT>, depending on the transfer direction. </P></DD><DT>direction</DT><DD><P> This should be either <TTCLASS="LITERAL">in</TT> or <TTCLASS="LITERAL">out</TT>. </P></DD><DT>number of transfers</DT><DD><P> This specifies the number of transfers that should take place. The testing software does not currently support the concept of performing transfers for a given period of time because synchronising this on both the host and a wide range of targets is difficult. However it is relatively easy to work out the approximate time a number of bulk transfers should take place, based on a typical bandwidth of 1MB/second and assuming say a 1ms overhead per transfer. Alternatively a test script could perform a small initial run to determine what performance can actually be expected from a given target, and then use this information to run a much longer test. </P></DD></DL></DIV><P>Additional arguments can be used to control the exact transfer. Forexample a <TTCLASS="PARAMETER"><I>txdelay+</I></TT> argument can be used toslowly increase the delay between transfers. All such arguments involvea value which can be passed either as part of the argument itself,for example <TTCLASS="LITERAL">txdelay+=5</TT>, or as a subsequentargument, <TTCLASS="LITERAL">txdelay+ 5</TT>. The possible arguments fallinto a number of categories: data, I/O mechanism, transmit size,receive size, transmit delay, and receive delay.</P><DIVCLASS="REFSECT2"><ANAME="AEN17167"></A><H3>Data</H3><P>An obvious parameter to control is the actual data that gets sent.This can be controlled by the argument <TTCLASS="PARAMETER"><I>data</I></TT>which can take one of five values: <TTCLASS="LITERAL">none</TT>,<TTCLASS="LITERAL">bytefill</TT>, <TTCLASS="LITERAL">intfill</TT>,<TTCLASS="LITERAL">byteseq</TT> and <TTCLASS="LITERAL">wordseq</TT>. The defaultvalue is <TTCLASS="LITERAL">none</TT>.</P><P></P><DIVCLASS="VARIABLELIST"><DL><DT><TTCLASS="LITERAL">none</TT></DT><DD><P> The transmit code will not attempt to fill the buffer in any way, and the receive code will not check it. The actual data that gets transferred will be whatever happened to be in the buffer before the transfer started. </P></DD><DT><TTCLASS="LITERAL">bytefill</TT></DT><DD><P> The entire buffer will be filled with a single byte, as per <TTCLASS="FUNCTION">memset</TT>. </P></DD><DT><TTCLASS="LITERAL">intfill</TT></DT><DD><P> 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. </P></DD><DT><TTCLASS="LITERAL">byteseq</TT></DT><DD><P> 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 <TTCLASS="LITERAL">x</TT>, the next byte will be <TTCLASS="LITERAL">(m*x)+i</TT>. For example a sequence of slowly incrementing 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 <TTCLASS="FUNCTION">rand</TT> function. For convenience these two constants are available as Tcl variables <TTCLASS="VARNAME">usbtest::MULTIPLIER</TT> and <TTCLASS="VARNAME">usbtest::INCREMENT</TT>. </P></DD><DT><TTCLASS="LITERAL">wordseq</TT></DT><DD><P> This acts like <TTCLASS="LITERAL">byteseq</TT>, 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. </P></DD></DL></DIV><P>The above requires three additional parameters<TTCLASS="PARAMETER"><I>data1</I></TT>, <TTCLASS="PARAMETER"><I>data*</I></TT> and<TTCLASS="PARAMETER"><I>data+</I></TT>. <TTCLASS="PARAMETER"><I>data1</I></TT> specifiesthe value to be used for byte or word fills, or the first number whencalculating a sequence. The default value is <TTCLASS="LITERAL">0</TT>.<TTCLASS="PARAMETER"><I>data*</I></TT> and <TTCLASS="PARAMETER"><I>data+</I></TT> specifythe multiplier and increment for a sequence, and have default valuesof <TTCLASS="LITERAL">1</TT> and <TTCLASS="LITERAL">0</TT> respectively. Forexample, to perform a bulk transfer of a pseudo-random sequence ofintegers starting with 42 the following code could be used:</P><TABLEBORDER="5"BGCOLOR="#E0E0F0"WIDTH="70%"><TR><TD><PRECLASS="PROGRAMLISTING">bulktest 2 IN 1000 data=wordseq data1=42 \ data* $usbtest::MULTIPLIER data+ $usbtest::INCREMENT</PRE></TD></TR></TABLE><P>The above parameters define what data gets transferred for the firsttransfer, but a test can involve multiple transfers. The data formatwill be the same for all transfers, but it is possible to adjust thecurrent value, the multiplier, and the increment between eachtransfer. This is achieved with parameters <TTCLASS="PARAMETER"><I>data1*</I></TT>,<TTCLASS="PARAMETER"><I>data1+</I></TT>, <TTCLASS="PARAMETER"><I>data**</I></TT>,<TTCLASS="PARAMETER"><I>data*+</I></TT>, <TTCLASS="PARAMETER"><I>data+*</I></TT>, and<TTCLASS="PARAMETER"><I>data++</I></TT>, with default values of 1 for eachmultiplier and 0 for each increment. For example, if the multiplierfor the first transfer is set to <TTCLASS="LITERAL">2</TT> using<TTCLASS="PARAMETER"><I>data*</I></TT>, and arguments<TTCLASS="LITERAL">data** 2</TT> and <TTCLASS="LITERAL">data*+ -1</TT> are alsosupplied, then the multiplier for subsequent transfers will be<TTCLASS="LITERAL">3</TT>, <TTCLASS="LITERAL">5</TT>, <TTCLASS="LITERAL">9</TT>,….</P><DIVCLASS="NOTE"><BLOCKQUOTECLASS="NOTE"><P><B>Note: </B>Currently it is not possible for a test script to send specific data,for example a specific sequence of bytes captured by a protocol analyserthat caused a problem. If the transfer was from host to target thenthe target would have to know the exact sequence of bytes to expect,which means transferring data over the USB bus when that data is knownto have caused problems in the past. Similarly for target to hosttransfers the target would have to know what bytes to send. A possiblefuture extension of the USB testing support would allow for bounceoperations, where a given message is first sent to the target and thensent back to the host, with only the host checking that the data wasreturned correctly.</P></BLOCKQUOTE></DIV></DIV><DIVCLASS="REFSECT2"><ANAME="AEN17237"></A><H3>I/O Mechanism</H3><P>On the target side USB transfers can happen using either low-levelUSB calls such as <TTCLASS="FUNCTION">usbs_start_rx_buffer</TT>, or byhigher-level calls which go through the device table. By default thetarget-side code will use the low-level calls. If it is desired totest the higher-level calls instead, for example because those arewhat the application uses, then that can be achieved with anargument <TTCLASS="PARAMETER"><I>mechanism=devtab</I></TT>.</P></DIV><DIVCLASS="REFSECT2"><ANAME="AEN17242"></A><H3>Transmit Size</H3><P>The next set of arguments can be used to control the size of thetransmitted buffer: <TTCLASS="PARAMETER"><I>txsize1</I></TT>,<TTCLASS="PARAMETER"><I>txsize>=</I></TT>, <TTCLASS="PARAMETER"><I>txsize<=</I></TT><TTCLASS="PARAMETER"><I>txsize*</I></TT>, <TTCLASS="PARAMETER"><I>txsize/</I></TT>,and <TTCLASS="PARAMETER"><I>txsize+</I></TT>.</P><P><TTCLASS="PARAMETER"><I>txsize1</I
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -