configs/: Remove dangline space at the end of lines in .txt files.

configs/esp32-core/README.txt

@@ -572,7 +572,7 @@ OpenOCD for the ESP32
     esp32.cpu0: Target halted, pc=0x400835BF
     187 g_tick_divisor = divisor;
     (gdb) ...
-  
+
 Configurations
 ==============
 

configs/freedom-k64f/README.txt

@@ -56,7 +56,7 @@ OpenSDAv2
   HDK-compatible debug interface preloaded with the open-source CMSIS-DAP
   Interface firmware (mbed interface) for rapid prototyping and product
   development.
-  
+
   To use set raw binary output for nuttx.bin
 
 Serial Console

configs/lincoln60/README.txt

@@ -478,7 +478,7 @@ Where <subdir> is one of the following:
 
   netnsh:
     Configures the NuttShell (nsh) located at apps/examples/nsh.  This
-    configuration is similar to the nsh configuration except that network 
+    configuration is similar to the nsh configuration except that network
     upport is enabled.
 
     NOTES:

configs/nr5m100-nexys4/README.txt

@@ -30,7 +30,7 @@ on the FPGA board. Those peripherals include:
   - 3-Axis accelerometer
   - Temperature sensor
 
-See http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommended-for-ece-curriculum/ 
+See http://store.digilentinc.com/nexys-4-ddr-artix-7-fpga-trainer-board-recommended-for-ece-curriculum/
 or http://store.digilentinc.com/nexys-4-artix-7-fpga-trainer-board-limited-time-see-nexys4-ddr/
 for more information about these boards.
 
@@ -53,25 +53,25 @@ Contents
 
 Development Environment
 =======================
-  The NR5M100 RISC-V core was designed as a low gate count / low performance micro controller 
+  The NR5M100 RISC-V core was designed as a low gate count / low performance micro controller
   for inclusion in an ASIC.  It is based on a Verilog RISC-V called picorv32, but has many
-  additions beyond that baseline.  The design running on the Digilent Nexys4 FPGA is a 
+  additions beyond that baseline.  The design running on the Digilent Nexys4 FPGA is a
   validation platform for the core and is presented as an open source project.
 
   The reason NR5M100 is "low performance" is that it is a state machine based core (like the
   picorv32) and not a multi-stage pipeline core.  This means that it requires an average of
   4.5 clock cycles to execute each instruction.  On a multi-stage pipeline architecure, this
-  average would be closer to 1 clock cycle per instruction (though a bit higher due to 
+  average would be closer to 1 clock cycle per instruction (though a bit higher due to
   pipeline branch misses).  The tradeoff for lower performance is a simpler design.  There
   is a single memory bus interface for both instructions and data.  Multi-stage pipeline
   cores require a separate I and D bus with cache SRAM and an external memory cache controller,
   etc.  This in addition to the pipeline registers adds additional gate count.
 
   The nr5m100-nexys4 core runs at 83.333 Mhz which provides about 18 Mhz effective operating
-  speed with the multi-clock per instruction architecture.  If you are looking for a higher 
+  speed with the multi-clock per instruction architecture.  If you are looking for a higher
-  performance platform, you should check out the PULP Platform ( http://www.pulp-platform.org ).  
+  performance platform, you should check out the PULP Platform ( http://www.pulp-platform.org ).
-  That is an FPGA design with a 4-stage pipeline RISC-V core, though not currently supported 
+  That is an FPGA design with a 4-stage pipeline RISC-V core, though not currently supported
-  by NuttX.  The NR5M100 project will likely pull in the RISC-V core from that design next, 
+  by NuttX.  The NR5M100 project will likely pull in the RISC-V core from that design next,
   though this will probably not be available soon.  With a bit of work, it is possible to
   run the nr5m100-nexys4 core at 170 Mhz with a 6.5 clocks-per-instruction state machine.
   This would give an effective performance of about 26Mhz.
@@ -87,8 +87,8 @@ RISC-V GNU Toolchain
 ====================
 
   To compile the code, you must first build a RISC-V GNU Toolchain from the sources at
-  https://github.com/riscv/riscv-gnu-toolchain.  I don't know of any sources for pre-compiled 
+  https://github.com/riscv/riscv-gnu-toolchain.  I don't know of any sources for pre-compiled
-  toolchains (though there may be some out there). 
+  toolchains (though there may be some out there).
 
   To build this toolchain, follow these instructions (tested on Ubuntu 12.04):
 
@@ -118,16 +118,16 @@ RISC-V GNU Toolchain
 
   Windows based toolchain
   -----------------------
-  May be possible to compile the GNU toolchain described above using Cygwin, but havne't tried it.  
+  May be possible to compile the GNU toolchain described above using Cygwin, but havne't tried it.
 
 Debugger
 ========
-  The Debug Module within the NR5M100 RISC-V has been designed to work with the RISC-V gdb 
+  The Debug Module within the NR5M100 RISC-V has been designed to work with the RISC-V gdb
   debugger interfaced with the SiFive implementation of OpenOCD.  The interface has been tested
-  with a J-LINK JTAG probe connected to PMOD header B on the FPGA using an adapter board 
+  with a J-LINK JTAG probe connected to PMOD header B on the FPGA using an adapter board
   that I designed and fabbed at OSHPark.  I will update this README.txt file soon with a link
   to the shared project for anyone who wishes to build one.
-  
+
   To build OpenOCD, perform the following:
 
   1. Ensure the proper packages are installed:
@@ -139,7 +139,7 @@ Debugger
      cd ~/riscv
      git clone --recursive https://github.com/sifive/openocd.git
 
-  3. Configure and build OpenOCD.  The x86_64 GCC compilers will give errors because of 
+  3. Configure and build OpenOCD.  The x86_64 GCC compilers will give errors because of
      shadowed variable warnings, so diable the -Werror flag also:
 
      cd openocd

configs/nucleo-f072rb/README.txt

@@ -237,7 +237,7 @@ Configurations
          reconfiguration process.
 
     2. Unless stated otherwise, all configurations generate console
-       output on USART2, as described above under "Serial Console".  The 
+       output on USART2, as described above under "Serial Console".  The
        elevant configuration settings are listed below:
 
          CONFIG_STM32_USART2=y
@@ -319,7 +319,7 @@ Configurations
          CONFIG_NSH_ARCHINIT=y
          CONFIG_NSH_BUILTIN_APPS=y
 
-       Support for NSH built-in applications is enabled for future use. 
+       Support for NSH built-in applications is enabled for future use.
        However, no built applications are enabled in this base configuration.
 
     2. C++ support for applications is NOT enabled.  That could be enabled

configs/nucleo-f091rc/README.txt

@@ -223,7 +223,7 @@ Configurations
          reconfiguration process.
 
     2. Unless stated otherwise, all configurations generate console
-       output on USART2, as described above under "Serial Console".  The 
+       output on USART2, as described above under "Serial Console".  The
        elevant configuration settings are listed below:
 
          CONFIG_STM32_USART2=y
@@ -305,7 +305,7 @@ Configurations
          CONFIG_NSH_ARCHINIT=y
          CONFIG_NSH_BUILTIN_APPS=y
 
-       Support for NSH built-in applications is enabled for future use. 
+       Support for NSH built-in applications is enabled for future use.
        However, no built applications are enabled in this base configuration.
 
     2. C++ support for applications is NOT enabled.  That could be enabled

configs/nucleo-l452re/README.txt

@@ -229,7 +229,7 @@ Configurations
          reconfiguration process.
 
     2. Unless stated otherwise, all configurations generate console
-       output on USART2, as described above under "Serial Console".  The 
+       output on USART2, as described above under "Serial Console".  The
        elevant configuration settings are listed below:
 
          CONFIG_STM32_USART2=y

configs/nucleo-l496zg/README.txt

@@ -76,7 +76,7 @@ NUCLEO-L496ZG Features:
   Microprocessor: STM32L496ZGT6 Core: ARM 32-bit Cortex®-M4 CPU with FPU,
                   80 MHz, MPU, and DSP instructions.
   Memory:         1024 KB Flash 320KB of SRAM (including 64KB of SRAM2)
-  ADC:            3×12-bit: up to 24 channels 
+  ADC:            3×12-bit: up to 24 channels
   DMA:            2 X 7-stream DMA controllers with FIFOs and burst support
   Timers:         Up to 13 timers: (2x 16-bit lowpower), two 32-bit timers,
                   2x watchdogs, SysTick

configs/olimex-stm32-h407/README.txt

@@ -1,8 +1,8 @@
 README
 ======
 
-The Olimex STM32-H407 configuration is based on 
+The Olimex STM32-H407 configuration is based on
-stm32Fdiscovery and Olimex STM32-H405. 
+stm32Fdiscovery and Olimex STM32-H405.
 
 The H407 was programmed with ST-LINK/V2 from both Win8.1 and Ubuntu 14.04
 This release provides baseline for H407 12MHZ clock in include/board.h

configs/photon/README.txt

@@ -49,7 +49,7 @@ Configuring NuttX to use your Wireless Router (aka Access Point)
 
   Browser the menus this way:
 
-  Application Configuration  ---> 
+  Application Configuration  --->
       NSH Library  --->
           Networking Configuration  --->
               WAPI Configuration  --->

configs/sam4s-xplained-pro/README.txt

@@ -580,7 +580,7 @@ Configuration sub-directories
     1. The configuration configuration can be modified to include support
        for the on-board SRAM (1MB).
 
-       System Type -> External Memory Configuration       
+       System Type -> External Memory Configuration
          CONFIG_SAM34_EXTSRAM0=y              : Select SRAM on CS0
          CONFIG_SAM34_EXTSRAM0SIZE=1048576    : Size=1MB
 
@@ -589,7 +589,7 @@ Configuration sub-directories
        a)  To enable the NuttX RAM test that may be used to verify the
            external SRAM:
 
-           System Type -> External Memory Configuration       
+           System Type -> External Memory Configuration
              CONFIG_SAM34_EXTSRAM0HEAP=n      : Don't add to heap
 
            Application Configuration -> System NSH Add-Ons
@@ -623,7 +623,7 @@ Configuration sub-directories
         b) To add this RAM to the NuttX heap, you would need to change the
            configuration as follows:
 
-           System Type -> External Memory Configuration       
+           System Type -> External Memory Configuration
              CONFIG_SAM34_EXTSRAM0HEAP=y     : Add external RAM to heap
 
            Memory Management

configs/sama5d3x-ek/Using-NxPlayer.txt

@@ -24,7 +24,7 @@ Procedure:
 5. NSH shouls start
 
     NuttShell (NSH) NuttX-7.3
-    nsh> 
+    nsh>
 
 6. Mount the SD card at /music
 

configs/sama5d4-ek/README.txt

@@ -359,7 +359,7 @@ Creating and Using DRAMBOOT
        cd tools
        ./configure.sh sama5d4-ek/dramboot
        cd -
- 
+
      Before building, make sure that the PATH environment variable includes
      the correct path  to the directory than holds your toolchain binaries.
 

configs/sama5d4-ek/RunningNxWM.txt

@@ -104,7 +104,7 @@ the following icons will be visible:
    pause, fast forward, rewind, and adjust the volume.
 
    Unfortunately in this version, the WM8904 audio CODEC is stubbed out so
-   you will not actually be able to heard any of the .WAV files that you 
+   you will not actually be able to heard any of the .WAV files that you
 
 Telnet access:
 ==============

configs/saml21-xplained/README.txt

@@ -478,7 +478,7 @@ Serial Consoles
 Atmel Studio 6.1
 ================
 
-  NOTE: These instructions are old. The SAML21 requires Atmel Studio 6.2. 
+  NOTE: These instructions are old. The SAML21 requires Atmel Studio 6.2.
   They may still prove useful to you, however.
 
   Loading Code into FLASH:

configs/samv71-xult/README.txt

@@ -2369,7 +2369,7 @@ Configuration sub-directories
      2106-04-23:  The NxImage test was selected because it is a very simple
         graphics test.  Continued testing, however, requires a more complex
         configuration.  Hence, the vnxwm configuration was created.
-        
+
         A memory clobber error was fixed and this probably corrects some of
         the reliability problems noted on 2016-04-21.
 

configs/sim/NETWORK-LINUX.txt

@@ -7,7 +7,7 @@ routed case no special configuration is necessary, but by default the
 simulation will only be accessible to the host on which it runs.
 
 Bridge mode is recommended where possible.  It requires slightly more effort
-to set up, but is much more flexible, and is likely to be easier to maintain 
+to set up, but is much more flexible, and is likely to be easier to maintain
 in the end.
 
 
@@ -27,7 +27,7 @@ able to see it until the simulation is stopped.  The host route will force all
 traffic destined for that IP to be sent to the tap interface.
 
 NOTE:  If you configure an IP address that is not on the same subnet as your
-       host, additional manual setup will be required.  This is not 
+       host, additional manual setup will be required.  This is not
        recommended; you should use bridge mode instead.
 
 
@@ -90,22 +90,22 @@ network as your eth1 interface.  Note that your bridge will generally not need
 an IP address in this case.
 
 If you only have a single interface, you can configure your system so that eth0
-(or other primary interface) is on the bridge.  To do this, you would execute 
+(or other primary interface) is on the bridge.  To do this, you would execute
 commands like the following from the system console:
 
   # brctl addbr nuttx0
   # brctl addif nuttx0 eth0
   # ifconfig nuttx0 <host-ip-address/netmask>
   # route add -net default gw ...
-  
+
 The rest of your network configuration would remain the same; your host's IP
 address has simply moved from being assigned directly to the ethernet interface,
-to being assigned to the bridge that contains that interface.  The connection 
+to being assigned to the bridge that contains that interface.  The connection
 will operate as normal.  NuttX simulations will join the bridge as with the
 previous example.
 
 In either of the live access scenarios presented here, the default gateway you
-configure in your simluation should be the normal one for the network you're 
+configure in your simluation should be the normal one for the network you're
 accessing, whether or not the bridge has an IP address.  The bridge is acting
 as an ethernet hub; your simluation has direct access to the normal gateway as
 if the simluation were a device physically connected to the network.
@@ -113,7 +113,7 @@ if the simluation were a device physically connected to the network.
 
 CONFIGURING AT STARTUP
 ----------------------
-Most Linux distributions have a mechanism for configuring a bridge at startup. 
+Most Linux distributions have a mechanism for configuring a bridge at startup.
 See your distribution's documentation for more information.
 
 
@@ -122,7 +122,7 @@ NOTES
 
   o Users of VMware ESXi should be aware that the bridge will place the contained
     ethernet interface into promiscuous mode (don't ask me why).  ESXi will
-    reject this by default, and nothing will work.  To fix this, edit the 
+    reject this by default, and nothing will work.  To fix this, edit the
     properties of the relevant vSwitch or VLAN, select the Security tab, and
     set "Promiscuous Mode" to "Accept".
 

configs/stm3210e-eval/README.txt

@@ -361,7 +361,7 @@ Temperature Sensor
     bytesread = read(fd, buffer, 8*sizeof(b16_t));  /* Read temperature samples */
 
   More complex temperature sensor operations are also available.  See the
-  IOCTL commands enumerated in include/nuttx/sensors/lm75.h.  Also read the 
+  IOCTL commands enumerated in include/nuttx/sensors/lm75.h.  Also read the
   descriptions of the stm32_lm75initialize() and stm32_lm75attach()
   interfaces in the arch/board/board.h file (sames as
   configs/stm3210e-eval/include/board.h).

configs/stm32f103-minimum/README.txt

@@ -356,15 +356,15 @@ Nokia 5110 LCD Display support:
   After compiling and flashing the nuttx.bin inside the board, reset it.
   You should see it:
 
-  NuttShell (NSH)                                                              
+  NuttShell (NSH)
   nsh> ?
-  help usage:  help [-v] [<cmd>]                                               
+  help usage:  help [-v] [<cmd>]
 
-    [           dd          free        mb          sh          usleep      
+    [           dd          free        mb          sh          usleep
-    ?           echo        help        mh          sleep       xd          
+    ?           echo        help        mh          sleep       xd
-    cat         exec        hexdump     mw          test        
+    cat         exec        hexdump     mw          test
-    cd          exit        kill        pwd         true        
+    cd          exit        kill        pwd         true
-    cp          false       ls          set         unset       
+    cp          false       ls          set         unset
 
   Builtin Apps:
     nxhello

configs/stm32f3discovery/README.txt

@@ -416,10 +416,10 @@ https://github.com/texane/stlink
 --------------------------------
 This is an open source server for the ST-Link that I have never used.
 
-It is also possible to use an external debugger such as the Segger JLink 
+It is also possible to use an external debugger such as the Segger JLink
 (EDU or commercial models) provided:
 
-1) The CN4 jumpers are removed to disconnect the on-board STLinkV2 from 
+1) The CN4 jumpers are removed to disconnect the on-board STLinkV2 from
    the STM32F3.
 
 2) The appropriate (20 pin connector to flying wire) adapter is used to connect
@@ -433,7 +433,7 @@ It is also possible to use an external debugger such as the Segger JLink
 
 The signals used with external (SWD) debugging are:
 
-   VREF (3V) 
+   VREF (3V)
    GROUND (GND)
    SWCLK (PA14)
    SWIO (PA13)

configs/stm32f746g-disco/README.txt

@@ -2,7 +2,7 @@ README
 ======
 
 This README discusses issues unique to NuttX configurations for the
-STMicro STM32F746G-DISCO development board featuring the STM32F746NGH6 
+STMicro STM32F746G-DISCO development board featuring the STM32F746NGH6
 MCU. The STM32F746NGH6  is a 216MHz Cortex-M7 operation with 1024Kb Flash
 memory and 300Kb SRAM. The board features:
 

configs/tm4c123g-launchpad/README.txt

@@ -88,7 +88,7 @@ AT24 Serial EEPROM
   ----------------
 
   A AT24C512 Serial EEPPROM was used for tested I2C.  There are no I2C
-  devices on-board the Launchpad, but an external serial EEPROM module 
+  devices on-board the Launchpad, but an external serial EEPROM module
   module was used.
 
   The Serial EEPROM was mounted on an external adaptor board and connected

configs/twr-k64f120m/README.txt

@@ -68,19 +68,19 @@ Micro-USB            K64_MICRO_USB_DN          USB0_DN
 Pushbuttons          SW1 (LLWU_P10)            PTC6     PTC6
                      SW2 (RSTIN_B_R)           RSTIN    RESET
                      SW3 (NMI B)               PTA4     PTA4
-LEDs                 D5 / Green LED            PTE6     PTE6 
+LEDs                 D5 / Green LED            PTE6     PTE6
-                     D6 / Yellow LED           PTE7     PTE7 
+                     D6 / Yellow LED           PTE7     PTE7
-                     D7 / Orange LED           PTE8     PTE8 
+                     D7 / Orange LED           PTE8     PTE8
-                     D9 / Blue LED             PTE9     PTE9 
+                     D9 / Blue LED             PTE9     PTE9
 Potentiometer        Potentiometer (R526)      ?        ADC1_SE18
 Accelerometer        I2C SDA                   PTC11    I2C1_SDA
                      I2C SCL                   PTC10    I2C1_SCL
                      INT1                      PTA6     PTA6
                      INT2                      PTA8     PTA8
-                     
+
 SDHC important notice: on TWR-K64F120M, R521 (close to the SD card holder) is not placed,
 hence WRPROTEC is always ON. Either place a 4.7KOhm resistor or change PIN config
-to PULLDOWN, loosing Write Protect function. See twrk64.h.                     
+to PULLDOWN, loosing Write Protect function. See twrk64.h.
 
 Connections via the General Purpose Tower Plug-in (TWRPI) Socket
 -------------------- ------------------------- -------- -------------------
@@ -265,7 +265,7 @@ Networking Support
 
   From the target side, you may should also be able to ping the host
   (assuming it's IP is 192.168.0.1):
-  
+
     nsh> ping 192.168.0.1
     PING 192.168.0.1 56 bytes of data
     56 bytes from 192.168.0.1: icmp_seq=1 time=0 ms
@@ -279,7 +279,7 @@ Networking Support
     56 bytes from 192.168.0.1: icmp_seq=9 time=0 ms
     56 bytes from 192.168.0.1: icmp_seq=10 time=0 ms
     10 packets transmitted, 10 received, 0% packet loss, time 10100 ms
-    nsh> 
+    nsh>
 
   You can also log into the NSH from the host PC like this:
 
@@ -409,7 +409,7 @@ as follows:
   * If LED1, LED2, LED3 are statically on, then NuttX probably failed to boot
     and these LEDs will give you some indication of where the failure was
  ** The normal state is LED1 ON and LED2 faintly glowing.  This faint glow
-    is because of timer interrupts and signal that result in the LED being 
+    is because of timer interrupts and signal that result in the LED being
     illuminated on a small proportion of the time.
 *** LED3 may even glow faintlier then LED2 while signals are processed.
 
@@ -798,18 +798,18 @@ Where <subdir> is one of the following:
       CONFIG_SCHED_WORKQUEUE=y             : Enable the NuttX workqueue
 
       CONFIG_NSH_ARCHINIT=y                : Provide NSH initializeation logic
-    
+
   netnsh:
   ------
     This is the same config then nsh, but it adds Ethernet support with the
     TWR-SER card. It includes telnetd in order to access nsh from Ethernet.
     IP address defaults to 192.168.0.233/24.
- 
+
     NOTES:
 
     1. See networking support for application and especially for jumper setting.
        In this config, this is TWR-SER that clocks the MCU.
-    
+
     2. The PHY link negotiation is done at boot time only. If no link is then
        available, a fallback mode is used at 10Mbs/half-duplex. Please make sure
        your ethernet cable and switches are on before booting.

configs/xmc4500-relax/README.txt

@@ -19,7 +19,7 @@ Serial Console
 
   Be default, UART0 (aka, USIC0, channel 0) is used as the serial console.
   The RX and TX pins is available:
-  
+
     RX     - P1.4, Connector X2, pin 17
     TX     - P1.5, Connector X2, pin 16
     GND    -       Available on pins 1-4 of either connector X1 or X2
@@ -47,7 +47,7 @@ LEDs
   defined.  In that case, the usage by the board port is defined in
   include/board.h and src/sam_autoleds.c. The LEDs are used to encode
   OS-related events as follows:
- 
+
     SYMBOL              Meaning                  LED state
                                                 LED1   LED2
     ------------------ ------------------------ ------ ------