More Zmodem tweaks

This commit is contained in:
Gregory Nutt 2013-07-16 08:26:59 -06:00
parent 076e67df24
commit b7f15de193
2 changed files with 15 additions and 34 deletions

View File

@ -1241,37 +1241,17 @@ Where <subdir> is one of the following:
the previously received data to the file and the serial driver's RX 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 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 a result, when it reads the next buffer of data, a few bytes may be
missing (maybe 10). The symptom of this missing data is a CRC check missing. The symptom of this missing data is a CRC check failure.
failure.
Either (1) we need a more courteous host application, or (2) we Either (1) we need a more courteous host application, or (2) we
need to greatly improve the target side buffering capability! need to greatly improve the target side buffering capability!
My thought now is to implement the NuttX sz and rz commands as We might get better behavior if we use the NuttX rz/sz commands
PC side applications as well. Matching both sides and obeying on the host side (see apps/system/zmodem/README.txt).
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 2013-7-16: I have verified that with debug off and at lower serial
alleviate these problems. But as of yet, I have not found a BAUD (2400), the transfers of large succeed without errors. I do
combination of options that does so: not consider this a "solution" to the problem. I also found that
the LPC17xx hardware flow control causes strange hangs; Zmodem
works better with hardware flow control disabled.
-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 (2400), 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. I do not consider this a "solution"
to the problem.

View File

@ -371,14 +371,14 @@ CONFIG_UART0_2STOP=0
# #
CONFIG_UART1_RXBUFSIZE=256 CONFIG_UART1_RXBUFSIZE=256
CONFIG_UART1_TXBUFSIZE=256 CONFIG_UART1_TXBUFSIZE=256
CONFIG_UART1_BAUD=9600 CONFIG_UART1_BAUD=2400
CONFIG_UART1_BITS=8 CONFIG_UART1_BITS=8
CONFIG_UART1_PARITY=0 CONFIG_UART1_PARITY=0
CONFIG_UART1_2STOP=0 CONFIG_UART1_2STOP=0
CONFIG_UART1_IFLOWCONTROL=y # CONFIG_UART1_IFLOWCONTROL is not set
CONFIG_UART1_OFLOWCONTROL=y # CONFIG_UART1_OFLOWCONTROL is not set
CONFIG_SERIAL_IFLOWCONTROL=y # CONFIG_SERIAL_IFLOWCONTROL is not set
CONFIG_SERIAL_OFLOWCONTROL=y # CONFIG_SERIAL_OFLOWCONTROL is not set
# CONFIG_USBDEV is not set # CONFIG_USBDEV is not set
# CONFIG_USBHOST is not set # CONFIG_USBHOST is not set
# CONFIG_WIRELESS is not set # CONFIG_WIRELESS is not set
@ -802,7 +802,8 @@ CONFIG_SYSTEM_ZMODEM_MOUNTPOINT="/mnt/sdcard"
# CONFIG_SYSTEM_ZMODEM_SENDATTN is not set # CONFIG_SYSTEM_ZMODEM_SENDATTN is not set
CONFIG_SYSTEM_ZMODEM_ALWAYSSINT=y CONFIG_SYSTEM_ZMODEM_ALWAYSSINT=y
# CONFIG_SYSTEM_ZMODEM_SENDBRAK is not set # CONFIG_SYSTEM_ZMODEM_SENDBRAK is not set
CONFIG_SYSTEM_ZMODEM_RESPTIME=10 CONFIG_SYSTEM_ZMODEM_RESPTIME=20
CONFIG_SYSTEM_ZMODEM_CONNTIME=30
CONFIG_SYSTEM_ZMODEM_SERIALNO=0 CONFIG_SYSTEM_ZMODEM_SERIALNO=0
CONFIG_SYSTEM_ZMODEM_MAXERRORS=20 CONFIG_SYSTEM_ZMODEM_MAXERRORS=20
CONFIG_SYSTEM_ZMODEM_WRITESIZE=512 CONFIG_SYSTEM_ZMODEM_WRITESIZE=512