sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix file write loop

Browse Source
This commit is contained in:
Gregory Nutt 2013-07-15 16:21:20 -06:00
parent 6153cfea56
commit b9220fc118
1 changed files with 29 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
configs/olimex-lpc1766stk/README.txt
View File

@ -1163,6 +1163,7 @@ Where <subdir> is one of the following:
Linux PC. To send a file to the PC, first make sure that the serial
port is configured to work with the board:
$ sudo stty -F /dev/ttyS0 raw # Puts the TTY in raw transfer mode
$ sudo stty -F /dev/ttyS0 9600 # Select 9600 BAUD
$ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking
$ sudo stty -F /dev/ttyS0 # Show the TTY configuration
@ -1202,6 +1203,7 @@ Where <subdir> is one of the following:
To send a file to the target, first make sure that the serial port on
the host is configured to work with the board:
$ sudo stty -F /dev/ttyS0 raw # Puts the TTY in raw transfer mode
$ sudo stty -F /dev/ttyS0 9600 # Select 9600 BAUD
$ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking
$ sudo stty -F /dev/ttyS0 # Show the TTY configuration
@ -1241,12 +1243,36 @@ Where <subdir> is one of the following:
the previously received data to the file and the serial driver's RX
buffer is overrun by a few bytes while the write is in progress. As
a result, when it reads the next buffer of data, a few bytes may be
missing (maybe 10). Either (1) we need a more courteous host
application, or (2) we need to greatly improve the target side
buffering capability!
missing (maybe 10). The symptom of this missing data is a CRC check
failure.
Either (1) we need a more courteous host application, or (2) we
need to greatly improve the target side buffering capability!
My thought now is to implement the NuttX sz and rz commands as
PC side applications as well. Matching both sides and obeying
the handshaking will solve the issues. Another option might be
to fix the serial driver hardware flow control somehow.
sz has several command line options which one would think would
alleviate these problems. But as of yet, I have not found a
combination of options that does so:
-L N, --packetlen N
Use ZMODEM sub-packets of length N. A larger N (32 <= N <= 1024)
gives slightly higher throughput, a smaller N speeds error
recovery. The default is 128 below 300 baud, 256 above 300 baud,
or 1024 above 2400 baud.
-l N, --framelen N
Wait for the receiver to acknowledge correct data every N
(32 <= N <= 1024) characters. This may be used to avoid network
overrun when XOFF flow control is lacking.
-w N, --windowsize N
Limit the transmit window size to N bytes (ZMODEM).
UPDATE: I have verified that with debug off and at lower serial
BAUD (1200), the transfers of large fails succeed without errors.
You may need the Linux sz -O option to keep it from timing out
in these low BAUD transfers.