io-serial-testing-with-serfilter.html

来自「ecos3.0 beta 的官方文档,html格式」· HTML 代码 · 共 712 行 · 第 1/2 页

><P
>This tests the duplex send and receive capabilities of the
      serial driver. </P
></DD
></DL
></DIV
><P
>All tests should complete in less than 30 seconds.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="IO-SERFILTER-USAGE"
>Serial Filter Usage</A
></H2
><P
>Running the ser_filter program with no (or wrong) arguments results in
the following output:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>Usage: ser_filter [-t -S] TcpIPport SerialPort BaudRate 
or: ser_filter -n [-t -S] SerialPort BaudRate 
-t: Enable tracing. 
-S: Output data read from serial line. 
-c: Output data on console instead of via GDB. 
-n: No GDB. </PRE
></TD
></TR
></TABLE
><P
>The normal way to use it with GDB is to start the filter:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ <KBD
CLASS="USERINPUT"
>ser_filter -t 9000 com1 38400</KBD
></PRE
></TD
></TR
></TABLE
><P
>In this case, the filter will be listening on port 9000 and connect to the
target via the serial port <TT
CLASS="LITERAL"
>COM1</TT
> at 38400 baud. On a UNIX
host, replace "<TT
CLASS="LITERAL"
>COM1</TT
>" with a device such as 
"<TT
CLASS="FILENAME"
>/dev/ttyS0</TT
>".</P
><P
>The <CODE
CLASS="OPTION"
>-t</CODE
> option enables tracing which will cause the
filter to describe its actions on the console.</P
><P
>Now start <SPAN
CLASS="APPLICATION"
>GDB</SPAN
> with one of the tests as an
argument:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ <KBD
CLASS="USERINPUT"
>mips-tx39-elf-gdb -nw install/tests/io_serial/serial3</KBD
></PRE
></TD
></TR
></TABLE
><P
>Then connect to the filter:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>(gdb) <KBD
CLASS="USERINPUT"
>target remote localhost:9000</KBD
></PRE
></TD
></TR
></TABLE
><P
>This should result in a connection in exactly the same way as if you
had connected directly to the target on the serial line.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>(gdb) <KBD
CLASS="USERINPUT"
>c</KBD
></PRE
></TD
></TR
></TABLE
><P
>Which should result in output similar to the below:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>Continuing. 
INFO: &lt;BINARY:16:1!&gt; 
PASS: &lt;Binary test completed&gt;
INFO: &lt;BINARY:128:1!&gt; 
PASS: &lt;Binary test completed&gt;
INFO: &lt;BINARY:256:1!&gt; 
PASS: &lt;Binary test completed&gt;
INFO: &lt;BINARY:1024:1!&gt; 
PASS: &lt;Binary test completed&gt;
INFO: &lt;BINARY:512:0!&gt;
PASS: &lt;Binary test completed&gt;
... 
PASS: &lt;Binary test completed&gt;
INFO: &lt;BINARY:16384:0!&gt;
PASS: &lt;Binary test completed&gt;
PASS: &lt;serial13 test OK&gt;
EXIT: &lt;done&gt;</PRE
></TD
></TR
></TABLE
><P
>If any of the individual tests fail the testing will terminate with a 
<SAMP
CLASS="COMPUTEROUTPUT"
>FAIL</SAMP
>.</P
><P
>With tracing enabled, you would also see the filter's status output:</P
><P
>The <TT
CLASS="LITERAL"
>PING</TT
> command sent from the target to determine the
presence of the filter:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>[400 11:35:16] Dispatching command PING 
[400 11:35:16] Responding with status OK</PRE
></TD
></TR
></TABLE
><P
>Each of the binary commands result in output similar to:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>[400 11:35:16] Dispatching command BINARY 
[400 11:35:16] Binary data (Size:16, Flags:1). 
[400 11:35:16] Sending CRC: '170231!', len: 7. 
[400 11:35:16] Reading 16 bytes from target. 
[400 11:35:16] Done. in_crc 170231, out_crc 170231. 
[400 11:35:16] Responding with status OK 
[400 11:35:16] Received DONE from target.</PRE
></TD
></TR
></TABLE
><P
>This tracing output is normally sent as O-packets to <SPAN
CLASS="APPLICATION"
>GDB</SPAN
> which will display the tracing text. By using the
<CODE
CLASS="OPTION"
>-c </CODE
> option, the tracing text can be redirected to the
console from which ser_filter was started.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="IO-SERFILTER-FAILURES"
>A Note on Failures</A
></H2
><P
>A serial connection (especially when driven at a high baud rate) can garble the
transmitted data because of noise from the environment. It is not the job of
the serial driver to ensure data integrity - that is the job of protocols
layering on top of the serial driver. </P
><P
>In the current implementation the serial tests and the serial filter are
not resilient to such data errors. This means that the test may crash or hang
(possibly without reporting a <SAMP
CLASS="COMPUTEROUTPUT"
>FAIL</SAMP
>). It also
means that you should be aware of random errors - a <SAMP
CLASS="COMPUTEROUTPUT"
>FAIL</SAMP
> is not necessarily caused by a bug in the serial driver.</P
><P
>Ideally, the serial testing infrastructure should be able to distinguish
random errors from consistent errors - the former are most likely due to noise
in the transfer medium, while the latter are more likely to be caused by faulty
drivers. The current implementation of the infrastructure does not have this
capability.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="IO-SERFILTER-DEBUGGING"
>Debugging</A
></H2
><P
>If a test fails, the serial filter's output may provide some hints about
what the problem is. If the option <CODE
CLASS="OPTION"
>-S</CODE
> is used when starting
the filter, data received from the target is printed out: </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>[400 11:35:16] 0000 50 41 53 53 3a 3c 42 69 'PASS:&lt;Bi'
[400 11:35:16] 0008 6e 61 72 79 20 74 65 73 'nary.tes' 
[400 11:35:16] 0010 74 20 63 6f 6d 70 6c 65 't.comple' 
[400 11:35:16] 0018 74 65 64 3e 0d 0a 49 4e 'ted&gt;..IN' 
[400 11:35:16] 0020 46 4f 3a 3c 42 49 4e 41 'FO:&lt;BINA'
[400 11:35:16] 0028 52 59 3a 31 32 38 3a 31 'RY:128:1' 
[400 11:35:16] 0030 21 3e 0d 0a 40 42 49 4e '!..@BIN' 
[400 11:35:16] 0038 41 52 59 3a 31 32 38 3a 'ARY:128:' 
[400 11:35:16] 0040 31 21 .. .. .. .. .. .. '1!' </PRE
></TD
></TR
></TABLE
><P
>In the case of an error during a testing command the data received by the
filter will be printed out, as will the data that was expected. This allows
the two data sets to be compared which may give some idea of what the problem
is.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="io-how-to-write-a-driver.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="devapi-device-driver-interface-to-the-kernel.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>How to Write a Driver</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="io-how-to-write-a-driver.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Device Driver Interface to the Kernel</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>