Fix an error in the ordering of fields in zm_transition_s structure; update documentation

4 files changed, 123 insertions, 62 deletions

diff --git a/apps/system/zmodem/README.txt b/apps/system/zmodem/README.txt
index 63d15cecb..ebde16c1d 100755
--- a/apps/system/zmodem/README.txt
+++ b/apps/system/zmodem/README.txt
@@ -4,6 +4,8 @@ README
 Using NuttX Zmodem with a Linux Host
 ====================================
 
+    Sending Files from the Target to the Linux Host PC
+    --------------------------------------------------
     The NuttX Zmodem commands have been verified against the rzsz programs
     running on a Linux PC.  To send a file to the PC, first make sure that
     the serial port is configured to work with the board:
@@ -11,7 +13,7 @@ Using NuttX Zmodem with a Linux Host
       $ sudo stty -F /dev/ttyS0 57600
       $ sudo stty -F /dev/ttyS0
 
-    start rz on the Linux host:
+    Start rz on the Linux host:
 
       $ sudo rz </dev/ttyS0 >/dev/ttyS0
 
@@ -38,4 +40,31 @@ Using NuttX Zmodem with a Linux Host
     Where filename is the full path to the file to send (i.e., it begins
     with the '/' character).
 
- 
\ No newline at end of file
+    Receiving Files on the Target from the Linux Host PC
+    ----------------------------------------------------
+    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 57600
+      $ sudo stty -F /dev/ttyS0
+
+    Start rz on the on the target:
+
+      nsh> rz -d /dev/ttyS1
+
+    Then use the sz command on Linux to send the file to the target:
+
+      $ sudo sz <filename> t </dev/ttyS0 >/dev/ttyS0
+
+    Where <filename> is the file that you want to send.
+
+    The resulting file will be found where you have configured the Zmodem
+    "sandbox" via CONFIG_SYSTEM_ZMODEM_MOUNTPOINT.
+
+    You can add the az -v option multiple times, each increases the level
+    of debug output.  If you want to capture the Linux rz output, then
+    re-direct stderr to a log file by adding 2>az.log to the end of the
+    rz command.
+
+    If you don't have the az command on your Linux box, the package to
+    install rzsz (or possibily lrzsz).
diff --git a/apps/system/zmodem/zm.h b/apps/system/zmodem/zm.h
index 60be71ff4..10f4640c5 100644
--- a/apps/system/zmodem/zm.h
+++ b/apps/system/zmodem/zm.h
@@ -287,8 +287,8 @@ typedef int (*action_t)(FAR struct zm_state_s *pzm);
 struct zm_transition_s
 {
   uint8_t    type;           /* Event (Frame type) */
-  uint8_t    next;           /* Next state */
   bool       bdiscard;       /* TRUE: discard buffered input */
+  uint8_t    next;           /* Next state */
   action_t   action;         /* Transition action */
 };
 
diff --git a/apps/system/zmodem/zm_receive.c b/apps/system/zmodem/zm_receive.c
index 132257a23..12589886f 100644
--- a/apps/system/zmodem/zm_receive.c
+++ b/apps/system/zmodem/zm_receive.c
@@ -81,14 +81,14 @@
  *                <---- ZRINIT        ZMR_START
  *   ZSINIT       ---->
  *                <---- ZACK          ZMR_INITWAIT
- *   ZFILE        ----> 
+ *   ZFILE        ---->
  *                <---- ZRPOS         ZMR_FILEINFO
  *   ZDATA        ---->
  *                <---- ZCRC          ZMR_CRCWAIT
  *   ZCRC         ---->               ZMR_READREADY
  *   Data packets ---->               ZMR_READING
  *   Last packet  ---->
- *   ZEOF         ----> 
+ *   ZEOF         ---->
  *                <---- ZRINIT
  *   ZFIN         ---->
  *                <---- ZFIN          ZMR_FINISH
@@ -955,7 +955,7 @@ static int zmr_zfin(FAR struct zm_state_s *pzm)
    * meaning that we are all done.
    */
 
-  zmdbg("PSTATE %d:%d->%d.%d:  send ZFIN\n",
+  zmdbg("PSTATE %d:%d->%d.%d:  Send ZFIN\n",
          pzm->pstate, pzm->psubstate, PSTATE_IDLE, PIDLE_ZPAD);
   zmdbg("ZMR_STATE %d\n", pzm->state);
 
diff --git a/nuttx/configs/olimex-lpc1766stk/README.txt b/nuttx/configs/olimex-lpc1766stk/README.txt
index 0978fdeca..5ca4a9504 100644
--- a/nuttx/configs/olimex-lpc1766stk/README.txt
+++ b/nuttx/configs/olimex-lpc1766stk/README.txt
@@ -137,7 +137,7 @@ Olimex LPC1766-STK development board
   But, referring to a different Olimex board, "Nokia 6100 LCD Display
   Driver," Revision 1, James P. Lynch ("Nokia 6100 LCD Display Driver.pdf")
   says:
-  
+
   "The major irritant in using this display is identifying the graphics
    controller; there are two possibilities (Epson S1D15G00 or Philips
    PCF8833). The LCD display sold by the German Web Shop Jelu has a Leadis
@@ -158,11 +158,11 @@ Olimex LPC1766-STK development board
 
   The LCD connects to the LPC1766 via SPI and two GPIOs.  The two GPIOs are
   noted above:
-  
+
     P1.21 is the SPI chip select, and
     P3.25 is the LCD reset
     P3.26 is PWM1 output used to control the backlight intensity.
-  
+
   MISO0 and MOSI0 are join via a 1K ohm resistor so the LCD appears to be
   write only.
 
@@ -239,7 +239,7 @@ IDEs
   NuttX is built using command-line make.  It can be used with an IDE, but some
   effort will be required to create the project (There is a simple RIDE project
   in the RIDE subdirectory).
-  
+
   Makefile Build
   --------------
   Under Eclipse, it is pretty easy to set up an "empty makefile project" and
@@ -334,7 +334,7 @@ NXFLAT Toolchain
   tools -- just the NXFLAT tools.  The buildroot with the NXFLAT tools can
   be downloaded from the NuttX SourceForge download site
   (https://sourceforge.net/projects/nuttx/files/).
- 
+
   This GNU toolchain builds and executes in the Linux or Cygwin environment.
 
   1. You must have already configured Nuttx in <some-dir>/nuttx.
@@ -398,7 +398,7 @@ LEDs
 
   LED1    LED2      Meaning
   ------- --------  --------------------------------------------------------------------
-   OFF    OFF      Still initializing and there is no interrupt activity. 
+   OFF    OFF      Still initializing and there is no interrupt activity.
                     Initialization is very fast so if you see this, it probably means
                     that the system is hung up somewhere in the initialization phases.
    OFF     Glowing  Still initializing (see above) but taking interrupts.
@@ -408,7 +408,7 @@ LEDs
    OFF     Flashing Ooops!  We crashed before finishing initialization (or, perhaps
                     after initialization, during an interrupt while the LPC17xx was
                     sleeping -- see below).
- 
+
    ON      OFF      The system has completed initialization, but is apparently not taking
                     any interrupts.
    ON      Glowing  The OS successfully initialized and is taking interrupts (but, for
@@ -426,7 +426,7 @@ LEDs
   NOTE: In glowing/glowing case, you get some good subjective information about the
   behavior of your system by looking at the level of the LED glow (or better, by
   connecting O-Scope and calculating the actual duty):
-  
+
   1. The intensity of the glow is determined by the duty of LED on/off toggle --
      as the ON period becomes larger with respect the OFF period, the LED will
      glow more brightly.
@@ -442,7 +442,7 @@ LEDs
 
   When my LPC1766 sits IDLE -- doing absolutely nothing but processing timer interrupts --
   I see the following:
-  
+
   1. LED1 glows dimly due to the timer interrupts.
   2. But LED2 is even more dim!  The LED ON time excludes the time processing the
      interrupt that re-awakens the processing.  So this tells me that the LPC1766 is
@@ -471,24 +471,24 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
   Downloading OpenOCD
-  
+
     You can get information about OpenOCD here: http://openocd.berlios.de/web/
     and you can download it from here. http://sourceforge.net/projects/openocd/files/.
     To get the latest OpenOCD with more mature lpc17xx, you have to download
     from the GIT archive.
-    
+
       git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
 
     At present, there is only the older, frozen 0.4.0 version.  These, of course,
     may have changed since I wrote this.
- 
+
   Building OpenOCD under Cygwin:
 
     You can build OpenOCD for Windows using the Cygwin tools.  Below are a
     few notes that worked as of November 7, 2010.  Things may have changed
     by the time you read this, but perhaps the following will be helpful to
     you:
-    
+
     1. Install Cygwin (http://www.cygwin.com/).  My recommendation is to install
        everything.  There are many tools you will need and it is best just to
        waste a little disk space and have everthing you need.  Everything will
@@ -505,23 +505,23 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator
        CDM20802 WHQL Certified.zip
        $ mkdir ftd2xx
        $ cd ftd2xx
-       $ unzip ..CDM20802\ WHQL\ Certified.zip 
+       $ unzip ..CDM20802\ WHQL\ Certified.zip
        Archive:  CDM20802 WHQL Certified.zip
        ...
 
     3. Get the latest OpenOCD source
-    
+
        $ pwd
        /home/OpenOCD
        $ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
- 
+
        You will then have the source code in /home/OpenOCD/openocd
 
     4. Build OpenOCD for the FT22322 interface
 
        $ pwd
        /home/OpenOCD/openocd
-       $ ./bootstrap 
+       $ ./bootstrap
 
        Jim is a tiny version of the Tcl scripting language.  It is needed
        by more recent versions of OpenOCD.  Build libjim.a using the following
@@ -557,7 +557,7 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator
     I have been using the Olimex ARM-USB-OCD JTAG debugger with the
     LPC1766-STK (http://www.olimex.com).  OpenOCD requires a configuration
     file.  I keep the one I used last here:
-    
+
       configs/olimex-lpc1766stk/tools/olimex.cfg
 
     However, the "correct" configuration script to use with OpenOCD may
@@ -571,13 +571,13 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator
       flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME ...
 
     To:
- 
+
       flash bank $_FLASHNAME lpc2000 0x0 0x40000 0 0 $_TARGETNAME ...
-    
+
     There is also a script on the tools/ directory that I use to start
     the OpenOCD daemon on my system called oocd.sh.  That script will
     probably require some modifications to work in another environment:
-  
+
     - Possibly the value of OPENOCD_PATH and TARGET_PATH
     - It assumes that the correct script to use is the one at
       configs/olimex-lpc1766stk/tools/olimex.cfg
@@ -623,11 +623,11 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator
        FLASH.
     3. The MCU must be halted prior to loading code using 'mon reset'
        as described below.
- 
+
     OpenOCD will support several special 'monitor' commands.  These
     GDB commands will send comments to the OpenOCD monitor.  Here
     are a couple that you will need to use:
-  
+
      (gdb) monitor reset
      (gdb) monitor halt
 
@@ -710,7 +710,7 @@ Olimex LPC1766-STK Configuration Options
        the delay actually is 100 seconds.
 
     Individual subsystems can be enabled:
-    
+
       CONFIG_LPC17_MAINOSC=y
       CONFIG_LPC17_PLL0=y
       CONFIG_LPC17_PLL1=n
@@ -799,7 +799,7 @@ Olimex LPC1766-STK Configuration Options
   LPC17xx USB Device Configuration
 
     CONFIG_LPC17_USBDEV_FRAME_INTERRUPT
-      Handle USB Start-Of-Frame events. 
+      Handle USB Start-Of-Frame events.
       Enable reading SOF from interrupt handler vs. simply reading on demand.
       Probably a bad idea... Unless there is some issue with sampling the SOF
       from hardware asynchronously.
@@ -898,7 +898,7 @@ Where <subdir> is one of the following:
     1. Support for FAT long file names is built-in but can easily be
        removed if you are concerned about Microsoft patent issues (see the
        section "FAT Long File Names" in the top-level COPYING file).
-       
+
        CONFIG_FS_FAT=y
        CONFIG_FAT_LCNAMES=y <-- Long file name support
        CONFIG_FAT_LFN=y
@@ -908,7 +908,7 @@ Where <subdir> is one of the following:
 
     2. You may also want to define the following in your configuration file.
        Otherwise, you will have not feedback about what is going on:
- 
+
        CONFIG_DEBUG=y
        CONFIG_DEBUG_VERBOSE=y
        CONFIG_DEBUG_FTPC=y
@@ -918,7 +918,7 @@ Where <subdir> is one of the following:
     HID keyboard class driver using the test logic in apps/examples/hidkbd.
 
     NOTES:
- 
+
     1. This configuration uses the mconf-based configuration tool.  To
        change this configuration using that tool, you should:
 
@@ -954,7 +954,7 @@ Where <subdir> is one of the following:
     Configuration Notes:
 
     NOTES:
- 
+
     1. This configuration uses the mconf-based configuration tool.  To
        change this configuration using that tool, you should:
 
@@ -1003,15 +1003,15 @@ Where <subdir> is one of the following:
     1. Configure and build the slip-httpd configuration.
     2. Connect to a Linux box (assuming /dev/ttyS0)
     3. Reset on the target side and attach SLIP on the Linux side:
-    
+
        $ modprobe slip
        $ slattach -L -p slip -s 57600 /dev/ttyS0 &
- 
+
        This should create an interface with a name like sl0, or sl1, etc.
        Add -d to get debug output.  This will show the interface name.
 
        NOTE: The -L option is included to suppress use of hardware flow
-       control.  This is necessary because I haven't figured out how to 
+       control.  This is necessary because I haven't figured out how to
        use the UART1 hardware flow control yet.
 
        NOTE: The Linux slip module hard-codes its MTU size to 296.  So you
@@ -1038,7 +1038,7 @@ Where <subdir> is one of the following:
 
     NOTE: This configurat only works with VERBOSE debug disabled.  For some
     reason, certain debug statements hang(?).
-    
+
     NOTE: This example does not use UART1's hardware flow control.  UART1
     hardware flow control is partially implemented but does not behave as
     expected.  It needs a little more work.
@@ -1097,35 +1097,67 @@ Where <subdir> is one of the following:
        Hmmm.. I probably should set up an NSH script to just mount /dev/mmcsd0
        at /mnt/sdcard each time the board boots.
 
-    This program has been verified against the rzsz programs running on a
-    Linux PC.  To send a file to the PC, first make sure that the serial
-    port is configured to work with the board:
+    3. Sending Files from the Target to the Linux Host PC
+
+      This program has been verified against the rzsz programs running on a
+      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 57600
+        $ sudo stty -F /dev/ttyS0
+
+      Start rz on the Linux host:
+
+        $ sudo rz </dev/ttyS0 >/dev/ttyS0
+
+      You can add the rz -v option multiple times, each increases the level
+      of debug output.
+
+      NOTE: The NuttX Zmodem does sends rz\n when it starts in compliance with
+      the Zmodem specification.  On Linux this, however, seems to start some
+      other, incompatible version of rz.  You need to start rz manually to
+      make sure that the correct version is selected.  You can tell when this
+      evil rz/sz has inserted itself because you will see the '^' (0x5e)
+      character replacing the standard Zmodem ZDLE character (0x19) in the
+      binary data stream.
+
+      If you don't have the rz command on your Linux box, the package to
+      install rzsz (or possibily lrzsz).
+
+      Then on the target:
+
+        > sz -d /dev/ttyS1 <filename>
+
+      Where filename is the full path to the file to send (i.e., it begins
+      with the '/' character).
+
+    4. Receiving Files on the Target from the Linux Host PC
+
+       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 57600
+          $ sudo stty -F /dev/ttyS0
 
-      $ sudo stty -F /dev/ttyS0 57600
-      $ sudo stty -F /dev/ttyS0
+       Start rz on the on the target:
 
-    start rz on the Linux host:
+         nsh> rz -d /dev/ttyS1
 
-      $ sudo rz </dev/ttyS0 >/dev/ttyS0
+       Then use the sz command on Linux to send the file to the target:
 
-    You can add the rz -v option multiple times, each increases the level
-    of debug output.
+         $ sudo sz <filename> t </dev/ttyS0 >/dev/ttyS0
 
-    NOTE: The NuttX Zmodem does sends rz\n when it starts in compliance with
-    the Zmodem specification.  On Linux this, however, seems to start some
-    other, incompatible version of rz.  You need to start rz manually to
-    make sure that the correct version is selected.  You can tell when this
-    evil rz/sz has inserted itself because you will see the '^' (0x5e)
-    character replacing the standard Zmodem ZDLE character (0x19) in the
-    binary data stream.
+       Where <filename> is the file that you want to send.
 
-    If you don't have the rz command on your Linux box, the package to
-    install rzsz (or possibily lrzsz).
+       The resulting file will be found where you have configured the Zmodem
+       "sandbox" via CONFIG_SYSTEM_ZMODEM_MOUNTPOINT, in this case at
+       /mnt/sdcard.
 
-    Then on the target:
+       You can add the az -v option multiple times, each increases the level
+       of debug output.  If you want to capture the Linux rz output, then
+       re-direct stderr to a log file by adding 2>az.log to the end of the
+       rz command.
 
-      > sz -d /dev/ttyS1 <filename>
+       If you don't have the az command on your Linux box, the package to
+       install rzsz (or possibily lrzsz).
 
-    Where filename is the full path to the file to send (i.e., it begins
-    with the '/' character).
- 
\ No newline at end of file