summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rwxr-xr-xapps/system/zmodem/Makefile.host4
-rwxr-xr-xapps/system/zmodem/README.txt62
-rw-r--r--apps/system/zmodem/host/debug.h1
-rw-r--r--apps/system/zmodem/host/nuttx/compiler.h1
-rw-r--r--apps/system/zmodem/host/nuttx/config.h9
-rw-r--r--apps/system/zmodem/zm_send.c2
-rw-r--r--apps/system/zmodem/zm_state.c2
-rw-r--r--nuttx/Documentation/NuttX.html9
-rw-r--r--nuttx/configs/olimex-lpc1766stk/README.txt67
9 files changed, 116 insertions, 41 deletions
diff --git a/apps/system/zmodem/Makefile.host b/apps/system/zmodem/Makefile.host
index 04862b3b2..288bb0a16 100755
--- a/apps/system/zmodem/Makefile.host
+++ b/apps/system/zmodem/Makefile.host
@@ -94,10 +94,10 @@ $(HOSTAPPS)/zmodem.h: $(APPSINC)/zmodem.h
$(Q) cp $(APPSINC)/zmodem.h $(HOSTAPPS)/zmodem.h
$(RZBIN): $(HOSTAPPS)/zmodem.h $(RZOBJS) $(CMNOBJS)
- $(Q) $(HOSTCC) $(HOSTCFLAGS) -o $@ $(RZOBJS) $(CMNOBJS)
+ $(Q) $(HOSTCC) $(HOSTCFLAGS) -o $@ $(RZOBJS) $(CMNOBJS) -lrt
$(SZBIN): $(HOSTAPPS)/zmodem.h $(SZOBJS) $(CMNOBJS)
- $(Q) $(HOSTCC) $(HOSTCFLAGS) -o $@ $(SZOBJS) $(CMNOBJS)
+ $(Q) $(HOSTCC) $(HOSTCFLAGS) -o $@ $(SZOBJS) $(CMNOBJS) -lrt
clean:
ifneq ($(OBJEXT),)
diff --git a/apps/system/zmodem/README.txt b/apps/system/zmodem/README.txt
index d0cbc33f2..a9dd7ef10 100755
--- a/apps/system/zmodem/README.txt
+++ b/apps/system/zmodem/README.txt
@@ -79,9 +79,11 @@ Using NuttX Zmodem with a Linux Host
overruns):
$ sudo stty -F /dev/ttyS0 9600 # Select 9600 BAUD
- $ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking
+ $ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking *
$ sudo stty -F /dev/ttyS0 # Show the TTY configuration
+ * Only is hardware flow control is enabled.
+
Start rz on the Linux host (using /dev/ttyS0 as an example):
$ sudo rz </dev/ttyS0 >/dev/ttyS0
@@ -113,15 +115,21 @@ Using NuttX Zmodem with a Linux Host
Receiving Files on the Target from the Linux Host PC
----------------------------------------------------
+ NOTE: There are issues with using the Linux sz command with the NuttX
+ rz command. See "Status" below. It is recommended that you use the
+ NuttX sz command on Linux as described in the next paragraph.
+
To send a file to the target, first make sure that the serial port on the
host is configured to work with the board (Assuming that you are using
9600 baud for the data transfers -- high rates may result in data
overruns):
- $ sudo stty -F /dev/ttyS0 9600 # Select 9600 BAUD
- $ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking
+ $ sudo stty -F /dev/ttyS0 9600 # Select 9600 (or other) BAUD
+ $ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking *
$ sudo stty -F /dev/ttyS0 # Show the TTY configuration
+ * Only is hardware flow control is enabled.
+
Start rz on the on the target. Here, in this example, we are using
/dev/ttyS1 to perform the transfer
@@ -169,20 +177,24 @@ Building the Zmodem Tools to Run Under Linux
2. Add CONFIG_DEBUG=1 to the make command line to enable debug output
3. Make sure to clean old target .o files before making new host .o files.
- This build is untested as of 2013-7-16.
+ This build is has been verified as of 2013-7-16 using Linux to transfer
+ files with an Olimex LPC1766STK board. It works great and seems to solve
+ all of the problems found with the Linux sz/rz implementation.
Status
======
- 2013-7-15: I have tested with the configs/olimex-lpc1766stk
- configuration. I have been able to send large and small files with
- the sz command. I have been able to receive small files, but there
- are problems receiving large files: The Linux SZ does not obey the
- buffering limits and continues to send data while rz is writing
- 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. The symptom of this missing data is a CRC check
- failure.
+ 2013-7-15: Testing against the Linux rz/sz commands.
+
+ I have tested with the configs/olimex-lpc1766stk configuration. I
+ have been able to send large and small files with the target sz
+ command. I have been able to receive small files, but there are
+ problems receiving large files using the Linux sz command: The
+ Linux SZ does not obey the buffering limits and continues to send
+ data while rz is writing 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. 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!
@@ -194,8 +206,26 @@ Status
the handshaking will solve the issues. Another option might be
to fix the serial driver hardware flow control somehow.
- 2013-7-16: I have verified that with debug off and at lower serial
- BAUD (2400), the transfers of large succeed without errors. I do
+ 2013-7-16. More Testing against the Linux rz/sz commands.
+
+ I have verified that with debug off and at lower serial BAUD
+ (2400), the transfers of large files succeed without errors. I do
not consider this a "solution" to the problem. I also found that
the LPC17xx hardware flow control caused strange hangs; Zmodem
works better with hardware flow control disabled on the LPC17xx.
+
+ At this lower BAUD, RX buffer sizes could probably be reduced; Or
+ perhaps the BAUD coud be increased. My thought, however, is that
+ tuning in such an unhealthy situation is not the approach: The
+ best thing to do would be to use the matching NuttX sz on the Linux
+ host side.
+
+ 2013-7-16. More Testing against the NuttX rz/sz on Both Ends.
+
+ The NuttX sz/rz commands have been modified so that they can be
+ built and executed under Linux. In this case, there are no
+ transfer problems at all in either direction and with large or
+ small files. This configuration could probably run at much higher
+ serial speeds and with much smaller buffers (although that has not
+ been verified as of this writing).
+
diff --git a/apps/system/zmodem/host/debug.h b/apps/system/zmodem/host/debug.h
index de9194f79..1db58d339 100644
--- a/apps/system/zmodem/host/debug.h
+++ b/apps/system/zmodem/host/debug.h
@@ -41,6 +41,7 @@
****************************************************************************/
#include <nuttx/config.h>
+#include <nuttx/compiler.h>
/****************************************************************************
* Pre-processor Definitions
diff --git a/apps/system/zmodem/host/nuttx/compiler.h b/apps/system/zmodem/host/nuttx/compiler.h
index ed80571e2..fc029063e 100644
--- a/apps/system/zmodem/host/nuttx/compiler.h
+++ b/apps/system/zmodem/host/nuttx/compiler.h
@@ -121,6 +121,7 @@
/* Unknown compiler *********************************************************/
#else
+# warning Unknown Compiler
# undef CONFIG_CPP_HAVE_VARARGS
# undef CONFIG_CPP_HAVE_WARNING
diff --git a/apps/system/zmodem/host/nuttx/config.h b/apps/system/zmodem/host/nuttx/config.h
index 002a60d55..c86f4e05a 100644
--- a/apps/system/zmodem/host/nuttx/config.h
+++ b/apps/system/zmodem/host/nuttx/config.h
@@ -53,15 +53,20 @@
#define FAR
#define DEBUGASSERT assert
+#define _GNU_SOURCE 1
+
/* Configuration */
+#define CONFIG_SYSTEM_ZMODEM 1
#define CONFIG_SYSTEM_ZMODEM_DEVNAME "/dev/ttyS0"
#define CONFIG_SYSTEM_ZMODEM_RCVBUFSIZE 512
#define CONFIG_SYSTEM_ZMODEM_PKTBUFSIZE 1024
#define CONFIG_SYSTEM_ZMODEM_SNDBUFSIZE 512
#define CONFIG_SYSTEM_ZMODEM_MOUNTPOINT "/tmp"
-#undef CONFIG_SYSTEM_ZMODEM_RCVSAMPLE
-#undef CONFIG_SYSTEM_ZMODEM_SENDATTN
+#undef CONFIG_SYSTEM_ZMODEM_RCVSAMPLE
+#undef CONFIG_SYSTEM_ZMODEM_SENDATTN
+#define CONFIG_SYSTEM_ZMODEM_ALWAYSSINT 1
+#undef CONFIG_SYSTEM_ZMODEM_SENDBRAK
#define CONFIG_SYSTEM_ZMODEM_RESPTIME 10
#define CONFIG_SYSTEM_ZMODEM_CONNTIME 30
#define CONFIG_SYSTEM_ZMODEM_SERIALNO 1
diff --git a/apps/system/zmodem/zm_send.c b/apps/system/zmodem/zm_send.c
index df8e8414f..7ddd4d5db 100644
--- a/apps/system/zmodem/zm_send.c
+++ b/apps/system/zmodem/zm_send.c
@@ -496,6 +496,8 @@ static int zms_zrinit(FAR struct zm_state_s *pzm)
else
# endif
{
+ zmdbg("ZMS_STATE %d->%d\n", pzm->state, );
+ pzm->state = ZMS_DONE;
return ZM_XFRDONE;
}
#endif
diff --git a/apps/system/zmodem/zm_state.c b/apps/system/zmodem/zm_state.c
index 3aaa461b7..c67213e13 100644
--- a/apps/system/zmodem/zm_state.c
+++ b/apps/system/zmodem/zm_state.c
@@ -832,7 +832,7 @@ static int zm_parse(FAR struct zm_state_s *pzm, size_t rcvlen)
if (ret != OK)
{
- zmdbg("Aborting: %d\n", ret);
+ zmdbg("%s: %d\n", ret < 0 ? "Aborting" : "Done", ret);
return ret;
}
}
diff --git a/nuttx/Documentation/NuttX.html b/nuttx/Documentation/NuttX.html
index e448977b2..77dd48b33 100644
--- a/nuttx/Documentation/NuttX.html
+++ b/nuttx/Documentation/NuttX.html
@@ -8,7 +8,7 @@
<tr align="center" bgcolor="#e4e4e4">
<td>
<h1><big><font color="#3c34ec"><i>NuttX RTOS</i></font></big></h1>
- <p>Last Updated: June 27, 2013</p>
+ <p>Last Updated: July 16, 2013</p>
</td>
</tr>
</table>
@@ -501,6 +501,13 @@
<tr>
<td><br></td>
<td>
+ <p>
+ <li>File transfers via TFTP and FTP (<code>get</code> and <code>put</code>), HTML (<code>wget</code>), and Zmodem (<code>sz</code> and <code>rz</code>).</li>
+ </p>
+</tr>
+<tr>
+ <td><br></td>
+ <td>
<p><small>
<sup>1</sup>
FAT long file name support may be subject to certain Microsoft patent restrictions if enabled.
diff --git a/nuttx/configs/olimex-lpc1766stk/README.txt b/nuttx/configs/olimex-lpc1766stk/README.txt
index f6cd75211..4e85a2c80 100644
--- a/nuttx/configs/olimex-lpc1766stk/README.txt
+++ b/nuttx/configs/olimex-lpc1766stk/README.txt
@@ -1072,9 +1072,9 @@ Where <subdir> is one of the following:
CONFIG_LPC17XX_UART1=y
CONFIG_UART1_ISUART=y
- CONFIG_UART1_RXBUFSIZE=512
+ CONFIG_UART1_RXBUFSIZE=1024
CONFIG_UART1_TXBUFSIZE=256
- CONFIG_UART1_BAUD=9600
+ CONFIG_UART1_BAUD=2400
CONFIG_UART1_BITS=8
CONFIG_UART1_PARITY=0
CONFIG_UART1_2STOP=0
@@ -1163,10 +1163,13 @@ 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 9600 # Select 9600 BAUD
- $ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking
+ $ sudo stty -F /dev/ttyS0 2400 # Select 2400 BAUD
+ $ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking *
$ sudo stty -F /dev/ttyS0 # Show the TTY configuration
+ * Only is hardware flow control is enabled. It is *not* in this
+ default configuration.
+
Start rz on the Linux host:
$ sudo rz </dev/ttyS0 >/dev/ttyS0
@@ -1199,13 +1202,20 @@ Where <subdir> is one of the following:
5. Receiving Files on the Target from the Linux Host PC
+ NOTE: There are issues with using the Linux sz command with the NuttX
+ rz command. See "STATUS" below. It is recommended that you use the
+ NuttX sz command on Linux as described in the next paragraph.
+
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 9600 # Select 9600 BAUD
- $ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking
+ $ sudo stty -F /dev/ttyS0 2400 # Select 2400 BAUD
+ $ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking *
$ sudo stty -F /dev/ttyS0 # Show the TTY configuration
+ * Only is hardware flow control is enabled. It is *not* in this
+ default configuration.
+
Start rz on the on the target:
nsh> rz -d /dev/ttyS1
@@ -1234,14 +1244,17 @@ Where <subdir> is one of the following:
install rzsz (or possibily lrzsz).
STATUS
- 2013-7-15: I have been able to send large and small files with the
- sz command. I have been able to receive small files, but there are
- problems receiving large files: The Linux SZ does not obey the
- buffering limits and continues to send data while rz is writing
- 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. The symptom of this missing data is a CRC check failure.
+ 2013-7-15: Testing against the Linux rz/sz commands.
+
+ I have been able to send large and small files with the target sz
+ command. I have been able to receive small files, but there are
+ problems receiving large files using the Linux sz command: The
+ Linux SZ does not obey the buffering limits and continues to send
+ data while rz is writing 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. 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!
@@ -1249,9 +1262,25 @@ Where <subdir> is one of the following:
We might get better behavior if we use the NuttX rz/sz commands
on the host side (see apps/system/zmodem/README.txt).
- 2013-7-16: I have verified that with debug off and at lower serial
- BAUD (2400), the transfers of large succeed without errors. I do
- 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.
+ 2013-7-16: More Testing against the Linux rz/sz commands.
+
+ I have verified that with debug off and at lower serial
+ BAUD (2400), the transfers of large files succeed without errors. I
+ do not consider this a "solution" to the problem. I also found that
+ the LPC17xx hardware flow control causes strange hangs; Zmodem works
+ much better with hardware flow control disabled.
+
+ At this lower BAUD, RX buffer sizes could probably be reduced; Or
+ perhaps the BAUD coud be increased. My thought, however, is that
+ tuning in such an unhealthy situation is not the approach: The
+ best thing to do would be to use the matching NuttX sz on the Linux
+ host side.
+
+ 2013-7-16. More Testing against the NuttX rz/sz on Both Ends.
+ The NuttX sz/rz commands have been modified so that they can be
+ built and executed under Linux. In this case, there are no
+ transfer problems at all in either direction and with large or
+ small files. This configuration could probably run at much higher
+ serial speeds and with much smaller buffers (although that has not
+ been verified as of this writing).
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-29 03:28:08 +0000