Documentation: migrate apps/example/README.md

Documentation/applications/examples/abntcodi/index.rst

@@ -0,0 +1,4 @@
+``abntcodi`` ABNT CODI example
+==============================
+
+ABNT CODI example

Documentation/applications/examples/adc/index.rst

@@ -0,0 +1,22 @@
+``adc`` Read from ADC
+=====================
+
+A mindlessly simple test of an ADC devices. It simply reads from the ADC device
+and dumps the data to the console forever.
+
+This test depends on these specific ADC/NSH configurations settings (your
+specific ADC settings might require additional settings).
+
+- ``CONFIG_ADC`` – Enabled ADC support.
+- ``CONFIG_NSH_BUILTIN_APPS`` – Build the ADC test as an NSH built-in function.
+  Default: Built as a standalone program.
+
+Specific configuration options for this example include:
+
+- ``CONFIG_EXAMPLES_ADC_DEVPATH`` – The default path to the ADC device. Default:
+  ``/dev/adc0``.
+- ``CONFIG_EXAMPLES_ADC_NSAMPLES`` – This number of samples is collected and the
+  program terminates. Default: Samples are collected indefinitely.
+- ``CONFIG_EXAMPLES_ADC_GROUPSIZE`` – The number of samples to read at once.
+  Default: ``4``.
+

Documentation/applications/examples/adjtime/index.rst

@@ -0,0 +1,6 @@
+``adjtime`` Ajdtime function example
+====================================
+
+This application demonstrates the usage of adjtime() interface used to
+synchronize system clock time if its value varies from real time (usually get by
+external RTC).

Documentation/applications/examples/adxl372_test/index.rst

@@ -0,0 +1,4 @@
+``adxl372_test`` ADXL372 test program
+=====================================
+
+ADXL372 test program

Documentation/applications/examples/ajoystick/index.rst

@@ -0,0 +1,16 @@
+``ajoystick`` Analog Joystick
+=============================
+
+This is a simple test of the analog joystick driver. See details about this
+driver in ``nuttx/include/nuttx/input/ajoystick.h``.
+
+Configuration Pre-requisites:
+
+- ``CONFIG_AJOYSTICK`` – The analog joystick driver.
+
+Example Configuration:
+- ``CONFIG_EXAMPLES_AJOYSTICK`` – Enabled the analog joystick example.
+- ``CONFIG_EXAMPLES_AJOYSTICK_DEVNAME`` – Joystick device name. Default: ``/dev/adjoy0``.
+- ``CONFIG_EXAMPLES_AJOYSTICK_SIGNO`` – Signal used to signal the test
+application. Default: ``32``.
+

Documentation/applications/examples/alarm/index.rst

@@ -0,0 +1,20 @@
+``alarm`` RTC Alarm
+===================
+
+A simple example that tests the alarm IOCTLs of the RTC driver.
+
+Dependencies:
+
+- ``CONFIG_RTC_DRIVER`` –  RTC driver must be initialized to allow user space
+  access to the RTC.
+- ``CONFIG_RTC_ALARM`` – Support for RTC alarms must be enabled.
+
+Configuration:
+
+- ``CONFIG_EXAMPLES_ALARM`` – Enable the RTC driver alarm test.
+- ``CONFIG_EXAMPLES_ALARM_PROGNAME`` –  This is the name of the program that will
+  be used when the NSH ELF program is installed.
+- ``CONFIG_EXAMPLES_ALARM_PRIORITY`` – Alarm daemon priority.
+- ``CONFIG_EXAMPLES_ALARM_STACKSIZE`` – Alarm daemon stack size.
+- ``CONFIG_EXAMPLES_ALARM_DEVPATH`` – RTC device path (``/dev/rtc0``).
+- ``CONFIG_EXAMPLES_ALARM_SIGNO`` – Alarm signal.

Documentation/applications/examples/apa102/index.rst

@@ -0,0 +1,4 @@
+``apa102`` Rainbow on ``APA102`` LED Strip
+==========================================
+
+Rainbow example for ``APA102`` LED Strip.

Documentation/applications/examples/apds9960/index.rst

@@ -0,0 +1,5 @@
+``apds9960`` APDS-9960 test pplication
+======================================
+
+APDS-9960 Test Application.
+

Documentation/applications/examples/audio_rttl/index.rst

@@ -0,0 +1,4 @@
+``audio_rttl`` Audio tone generator
+===================================
+
+Audio tone generator example (RTTL player).

Documentation/applications/examples/bastest/index.rst

@@ -0,0 +1,16 @@
+``bastest`` Bas BASIC Interpreter
+=================================
+
+This directory contains a small program that will mount a ROMFS file system
+containing the BASIC test files extracted from the Bas ``2.4`` release. See
+``examples/bastest/README.md`` for licensing and usage information.
+
+- ``CONFIG_EXAMPLES_BASTEST_DEVMINOR`` – The minor device number of the ROMFS
+  block driver. For example, the ``N`` in ``/dev/ramN``. Used for registering the
+  RAM block driver that will hold the ROMFS file system containing the BASIC
+  files to be tested. Default: ``0``.
+
+- ``CONFIG_EXAMPLES_BASTEST_DEVPATH`` – The path to the ROMFS block driver device.
+  This must match ``EXAMPLES_BASTEST_DEVMINOR``. Used for registering the RAM
+  block driver that will hold the ROMFS file system containing the BASIC files
+  to be tested. Default: ``/dev/ram0``.

Documentation/applications/examples/battery/index.rst

@@ -0,0 +1,4 @@
+``battery`` Battery monitor example
+===================================
+
+Battery monitor example.

Documentation/applications/examples/bme680/index.rst

@@ -0,0 +1,4 @@
+``bme680`` BME680 sensor example
+================================
+
+BME680 sensor example.

Documentation/applications/examples/bmi160/index.rst

@@ -0,0 +1,4 @@
+``bmi160`` BMI160 sensor example
+================================
+
+BMI160 sensor example.

Documentation/applications/examples/bmp180/index.rst

@@ -0,0 +1,4 @@
+``bmp180`` BMP180 Barometer sensor example
+==========================================
+
+BMP180 Barometer sensor example.

Documentation/applications/examples/bmp280/index.rst

@@ -0,0 +1,4 @@
+``bmp280`` BMP280 Barometer sensor example
+==========================================
+
+BMP280 Barometer sensor example.

Documentation/applications/examples/bridge/index.rst

@@ -0,0 +1,40 @@
+``bridge`` Network Bridge
+=========================
+
+A simple test of a system with multiple networks. It simply echoes all UDP
+packets received on network ``1`` and network ``2`` to network ``2`` and network ``1``,
+respectively. Interface ``1`` and interface may or may not lie on the same
+network.
+
+- ``CONFIG_EXAMPLES_BRIDGE`` – Enables the simple UDP bridge test.
+
+There identical configurations for each of the two networks, ``NETn`` where ``n``
+refers to the network being configured ``n={1,2}``. Let ``m`` refer to the other
+network.
+
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_IFNAME`` – The register name of the network ``n``
+  device. Must match the previously registered driver name and must not be the
+  same as other network device name, ``CONFIG_EXAMPLES_BRIDGE_NETm_IFNAME``.
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_RECVPORT`` – Network ``n`` listen port number.
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_SNDPORT`` – Network ``2`` send port number.
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_IOBUFIZE`` – Size of the network ``n`` UDP
+  send/receive I/O buffer.
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_STACKSIZE`` – Network ``n`` daemon stacksize.
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_PRIORITY`` – Network ``n`` daemon task priority.
+
+If used as a NSH add-on, then it is assumed that initialization of both networks
+was performed externally prior to the time that this test was started.
+Otherwise, the following options are available:
+
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_NOMAC`` – Select of the network ``n`` hardware does
+  not have a built-in MAC address. If selected, the MAC address. provided by
+  ``CONFIG_EXAMPLES_BRIDGE_NETn_MACADDR`` will be used to assign the MAC address
+  to the network n device.
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_DHCPC`` – Use DHCP Client to get the network n IP
+  address.
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_IPADDR`` – If ``CONFIG_EXAMPLES_BRIDGE_NETn_DHCPC``
+  is not selected, then this is the fixed IP address for network ``n``.
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_DRIPADDR`` – Network ``n`` default router IP address
+  (Gateway).
+- ``CONFIG_EXAMPLES_BRIDGE_NETn_NETMASK`` – Network ``n`` mask.
+

Documentation/applications/examples/buttons/index.rst

@@ -0,0 +1,4 @@
+``buttons`` Read GPIO Buttons
+=============================
+
+Buttons driver example.

Documentation/applications/examples/calib_udelay/index.rst

@@ -0,0 +1,4 @@
+``calib_udelay`` Calibration tool for udelay
+=============================================
+
+Calibration tool for udelay.

Documentation/applications/examples/camera/index.rst

@@ -0,0 +1,40 @@
+``camera`` Camera Snapshot
+==========================
+
+This sample is implemented as ``camera`` command on NuttX Shell. The synopsis of
+the command is as below.::
+
+  nsh> camera ([-jpg]) ([capture num])
+
+  -jpg        : this option is set for storing JPEG file into a strage.
+              : If this option isn't set capturing raw RGB565 data in a file.
+              : raw RGB565 is default.
+
+  capture num : this option instructs number of taking pictures.
+              : 10 is default.
+
+Storage will be selected automatically based on the available storage option.
+
+Execution example::
+
+  nsh> camera
+  nximage_listener: Connected
+  nximage_initialize: Screen resolution (320,240)
+  Take 10 pictures as RGB file in /mnt/sd0 after 5 seconds.
+  After finishing taking pictures, this app will be finished after 10 seconds.
+  Expier time is pasted.
+  Start capturing...
+  FILENAME:/mnt/sd0/VIDEO001.RGB
+  FILENAME:/mnt/sd0/VIDEO002.RGB
+  FILENAME:/mnt/sd0/VIDEO003.RGB
+  FILENAME:/mnt/sd0/VIDEO004.RGB
+  FILENAME:/mnt/sd0/VIDEO005.RGB
+  FILENAME:/mnt/sd0/VIDEO006.RGB
+  FILENAME:/mnt/sd0/VIDEO007.RGB
+  FILENAME:/mnt/sd0/VIDEO008.RGB
+  FILENAME:/mnt/sd0/VIDEO009.RGB
+  FILENAME:/mnt/sd0/VIDEO010.RGB
+  Finished capturing...
+  Expier time is pasted.
+  nximage_listener: Lost server connection: 117
+

Documentation/applications/examples/can/index.rst

@@ -0,0 +1,29 @@
+``can`` CAN Device Test
+=======================
+
+If the CAN device is configured in loopback mode, then this example can be used
+to test the CAN device in loop back mode. It simple sinces a sequence of CAN
+messages and verifies that those messages are returned exactly as sent.
+
+This test depends on these specific CAN/NSH configurations settings (your
+specific CAN settings might require additional settings).
+
+- ``CONFIG_CAN`` – Enables CAN support.
+- ``CONFIG_CAN_LOOPBACK`` – A CAN driver may or may not support a loopback mode
+  for testing. The STM32 CAN driver does support loopback mode.
+- ``CONFIG_NSH_BUILTIN_APPS`` – Build the CAN test as an NSH built-in function.
+  Default: Built as a standalone program.
+
+Specific configuration options for this example include:
+
+- ``CONFIG_EXAMPLES_CAN_DEVPATH`` – The path to the CAN device. Default:
+  ``/dev/can0``.
+- ``CONFIG_EXAMPLES_CAN_NMSGS`` – This number of CAN message is collected and the
+  program terminates. Default: messages are sent and received indefinitely.
+
+The default behavior assumes loopback mode. Messages are sent, then read and
+verified. The behavior can be altered for other kinds of testing where the test
+only sends or received (but does not verify) can messages.
+
+- ``CONFIG_EXAMPLES_CAN_READONLY`` – Only receive messages.
+- ``CONFIG_EXAMPLES_CAN_WRITEONLY`` – Only send messages.

Documentation/applications/examples/capture/index.rst

@@ -0,0 +1,4 @@
+``capture`` PWM Capture example
+===============================
+
+PWM Capture example.

Documentation/applications/examples/cbortest/index.rst

@@ -0,0 +1,4 @@
+``cbortest`` TinyCBOR Test Example
+==================================
+
+TinyCBOR Test Example

Documentation/applications/examples/cctype/index.rst

@@ -0,0 +1,4 @@
+``cctype`` Verify C++ cctype operations
+=======================================
+
+Verifies all possible inputs for all functions defined in the header file ``cctype``.

Documentation/applications/examples/chat/index.rst

@@ -0,0 +1,16 @@
+``chat`` AT over TTY
+====================
+
+Demonstrates AT chat functionality over a TTY device. This is useful with AT
+modems, for example, to establish a ``pppd`` connection (see the related ``pppd``
+example). Moreover, some AT modems – such as ones made by u-blox – have an
+internal TCP/IP stack, often with an implementation of TLS/SSL. In such cases
+the chat utility can be used to configure the internal TCP/IP stack, establish
+socket connections, set up security (e.g., download base64-encoded certificates
+to the modem), and perform data exchange through sockets over the TTY device.
+
+Useful configuration parameters:
+
+- ``CONFIG_EXAMPLES_CHAT_PRESET[0..3]`` – preset chat scripts.
+- ``CONFIG_EXAMPLES_CHAT_TTY_DEVNODE`` – TTY device node name.
+- ``CONFIG_EXAMPLES_CHAT_TIMEOUT_SECONDS`` – default receive timeout.

Documentation/applications/examples/chrono/index.rst

@@ -0,0 +1,4 @@
+``chrono`` Chronometer example to use with STM32LDiscover
+=========================================================
+
+Chronometer example to use with STM32LDiscover.

Documentation/applications/examples/configdata/index.rst

@@ -0,0 +1,4 @@
+``configdata`` Config Data example / unit test
+==============================================
+
+This is a Unit Test for the MTD configuration data driver.

Documentation/applications/examples/cordic/index.rst

@@ -0,0 +1,4 @@
+``cordic`` CORDIC driver example
+================================
+
+A simple test of the CORDIC character driver.

Documentation/applications/examples/cpuhog/index.rst

@@ -0,0 +1,6 @@
+``cpuhog`` Keep CPU Busy
+========================
+
+Attempts to keep the system busy by passing data through a pipe in loop back
+mode. This may be useful if you are trying run down other problems that you
+think might only occur when the system is very busy.

Documentation/applications/examples/cromfs/index.rst

@@ -0,0 +1,4 @@
+``cromfs`` CROMFS Example
+=========================
+
+CROMFS Example.

Documentation/applications/examples/dac/index.rst

@@ -0,0 +1,4 @@
+``dac`` Write to DAC
+====================
+
+This is a tool for writing values to DAC device.

Documentation/applications/examples/dhcpd/index.rst

@@ -0,0 +1,23 @@
+``dhcpd`` DHCP Server
+=====================
+
+This examples builds a tiny DHCP server for the target system.
+
+**Note**: For test purposes, this example can be built as a host-based DHCPD
+server. This can be built as follows::
+
+  cd examples/dhcpd
+  make -f Makefile.host TOPDIR=<nuttx-directory>
+
+NuttX configuration settings:
+
+- ``CONFIG_NET=y`` – of course.
+- ``CONFIG_NET_UDP=y`` – UDP support is required for DHCP (as well as various
+  other UDP-related configuration settings).
+- ``CONFIG_NET_BROADCAST=y`` – UDP broadcast support is needed.
+- ``CONFIG_NETUTILS_NETLIB=y`` – The networking library is needed.
+- ``CONFIG_EXAMPLES_DHCPD_NOMAC`` – (May be defined to use software assigned MAC)
+
+See also ``CONFIG_NETUTILS_DHCPD_*`` settings described elsewhere and used in
+``netutils/dhcpd/dhcpd.c``. These settings are required to described the behavior
+of the daemon.

Documentation/applications/examples/discover/index.rst

@@ -0,0 +1,21 @@
+``discover`` UDP Discover Daemon
+================================
+
+This example exercises ``netutils/discover`` utility. This example initializes and
+starts the UDP discover daemon. This daemon is useful for discovering devices in
+local networks, especially with DHCP configured devices. It listens for UDP
+broadcasts which also can include a device class so that groups of devices can
+be discovered. It is also possible to address all classes with a kind of
+broadcast discover.
+
+This example will automatically be built as an NSH built-in if
+``CONFIG_NSH_BUILTIN_APPS`` is selected. Otherwise, it will be a standalone
+program with entry point ``discover_main``.
+
+NuttX configuration settings:
+
+- ``CONFIG_EXAMPLES_DISCOVER_DHCPC`` – DHCP Client.
+- ``CONFIG_EXAMPLES_DISCOVER_NOMAC`` – Use canned MAC address.
+- ``CONFIG_EXAMPLES_DISCOVER_IPADDR`` – Target IP address.
+- ``CONFIG_EXAMPLES_DISCOVER_DRIPADDR`` – Router IP address.
+- ``CONFIG_EXAMPLES_DISCOVER_NETMASK`` – Network Mask.

Documentation/applications/examples/djoystick/index.rst

@@ -0,0 +1,17 @@
+``djoystick`` Discrete Joystick
+===============================
+
+This is a simple test of the discrete joystick driver. See details about this
+driver in ``nuttx/include/nuttx/input/djoystick.h``.
+
+Configuration Pre-requisites:
+
+- ``CONFIG_INPUT_DJOYSTICK`` – The discrete joystick driver.
+
+Example Configuration:
+
+- ``CONFIG_EXAMPLES_DJOYSTICK`` – Enabled the discrete joystick example.
+- ``CONFIG_EXAMPLES_DJOYSTICK_DEVNAME`` – Joystick device name. Default
+  ``/dev/djoy0``.
+- ``CONFIG_EXAMPLES_DJOYSTICK_SIGNO`` – Signal used to signal the test
+  application. Default ``32``.

Documentation/applications/examples/dronecan/index.rst

@@ -0,0 +1,4 @@
+``dronecan`` DroneCAN example
+=============================
+
+DroneCAN example.

Documentation/applications/examples/elf/index.rst

@@ -0,0 +1,61 @@
+``elf`` ELF loader
+==================
+
+This example builds a small ELF loader test case. This includes several test
+programs under ``examples/elf`` tests. These tests are build using the relocatable
+ELF format and installed in a ROMFS file system. At run time, each program in
+the ROMFS file system is executed. Requires ``CONFIG_ELF``. Other configuration
+options:
+
+- ``CONFIG_EXAMPLES_ELF_DEVMINOR`` – The minor device number of the ROMFS block
+  driver. For example, the ``N`` in ``/dev/ramN``. Used for registering the RAM
+  block driver that will hold the ROMFS file system containing the ELF
+  executables to be tested. Default: ``0``.
+
+- ``CONFIG_EXAMPLES_ELF_DEVPATH`` – The path to the ROMFS block driver device.
+  This must match ``EXAMPLES_ELF_DEVMINOR``. Used for registering the RAM block
+  driver that will hold the ROMFS file system containing the ELF executables to
+  be tested. Default: ``/dev/ram0``.
+
+**Notes**:
+
+1. ``CFLAGS`` should be provided in ``CELFFLAGS``. RAM and FLASH memory regions may
+   require long allcs. For ARM, this might be::
+
+     CELFFLAGS = $(CFLAGS) -mlong-calls
+
+   Similarly for C++ flags which must be provided in ``CXXELFFLAGS``.
+
+2. Your top-level ``nuttx/Make.defs`` file must also include an appropriate
+   definition, ``LDELFFLAGS``, to generate a relocatable ELF object. With GNU LD,
+   this should include ``-r`` and ``-e main`` (or ``_main`` on some platforms).::
+
+     LDELFFLAGS = -r -e main
+
+   If you use GCC to link, you make also need to include ``-nostdlib``.
+
+3. This example also requires ``genromfs``. ``genromfs`` can be build as part of the
+   nuttx toolchain. Or can built from the ``genromfs`` sources that can be found
+   in the NuttX tools repository (``genromfs-0.5.2.tar.gz``). In any event, the
+   ``PATH`` variable must include the path to the genromfs executable.
+
+4. ELF size: The ELF files in this example are, be default, quite large because
+   they include a lot of build garbage. You can greatly reduce the size of the
+   ELF binaries are using the ``objcopy --strip-unneeded`` command to remove
+   un-necessary information from the ELF files.
+
+5. Simulator. You cannot use this example with the NuttX simulator on Cygwin.
+   That is because the Cygwin GCC does not generate ELF file but rather some
+   Windows-native binary format.
+
+   If you really want to do this, you can create a NuttX x86 buildroot toolchain
+   and use that be build the ELF executables for the ROMFS file system.
+
+6. Linker scripts. You might also want to use a linker scripts to combine
+   sections better. An example linker script is at
+   ``nuttx/binfmt/libelf/gnu-elf.ld``. That example might have to be tuned for
+   your particular linker output to position additional sections correctly. The
+   GNU LD ``LDELFFLAGS`` then might be::
+
+     LDELFFLAGS = -r -e main -T$(TOPDIR)/binfmt/libelf/gnu-elf.ld
+

Documentation/applications/examples/embedlog/index.rst

@@ -0,0 +1,4 @@
+``embedlog`` embedlog example
+=============================
+
+embedlog example.

Documentation/applications/examples/esp32_himem/index.rst

@@ -0,0 +1,4 @@
+``esp32_himem`` ESP32 HIMEM Example
+===================================
+
+ESP32 HIMEM Example.

Documentation/applications/examples/etl/index.rst

@@ -0,0 +1,4 @@
+``etl`` Embedded Template Library (ETL) C++ example
+===================================================
+
+Embedded Template Library (ETL) C++ example

Documentation/applications/examples/fb/index.rst

@@ -0,0 +1,4 @@
+``fb`` Framebuffer
+==================
+
+A simple test of the framebuffer character driver.

Documentation/applications/examples/fboverlay/index.rst

@@ -0,0 +1,4 @@
+``fboverlay`` Framebuffer overlay test tool
+===========================================
+
+Framebuffer overlay test tool.

Documentation/applications/examples/flash_test/index.rst

@@ -0,0 +1,29 @@
+``flash_test`` SMART Flash test
+===============================
+
+Author: Ken Pettit, Date: April 24, 2013
+
+This example performs a SMART flash block device test. This test performs a
+sector allocate, read, write, free and garbage collection test on a SMART MTD
+block device.
+
+- ``CONFIG_EXAMPLES_FLASH_TEST=y`` – Enables the FLASH Test.
+
+Dependencies:
+
+- ``CONFIG_MTD_SMART=y`` – SMART block driver support.
+- ``CONFIG_BUILD_PROTECTED=n`` and ``CONFIG_BUILD_KERNEL=n`` – This test uses
+  internal OS interfaces and so is not available in the NUTTX kernel builds.
+
+This application performs a SMART flash block device test. This test performs a
+sector allocate, read, write, free and garbage collection test on a SMART MTD
+block device. This test can be built only as an NSH command
+
+**Note**: This test uses internal OS interfaces and so is not available in the
+NUTTX kernel build::
+
+  Usage:
+    flash_test mtdblock_device
+
+  Additional options:
+    --force                     to replace existing installation

Documentation/applications/examples/flowc/index.rst

@@ -0,0 +1,18 @@
+``flowc`` Serial Hardware Flow Control
+======================================
+
+A simple test of serial hardware flow control.
+
+General Usage Instructions:
+
+1. The receiver side enter, start the receiver program. The receiver is now
+   waiting to receive data on the configured serial port.
+2. On the sender side start the sender program. This will send data to the
+   receiver which will verify that no data is lost.
+
+On Linux, you can alternatively do::
+
+  $ stty -F /dev/ttyACM0 crtscts
+  $ cat testdata.dat >/dev/ttyACM0
+
+where you need to replace ``/dev/ttyACM0`` with your selected serial device.

Documentation/applications/examples/fmsynth/index.rst

@@ -0,0 +1,4 @@
+``fmsynth`` FM Synthesizer examples
+===================================
+
+FM Synthesizer examples.

Documentation/applications/examples/foc/index.rst

@@ -0,0 +1,83 @@
+``foc`` FOC motor controller example
+====================================
+
+The main purpose of this example is to provide a universal template to
+implement the motor controller based on the kernel-side FOC device and
+the application-side FOC library.
+
+At the moment, this example implements a simple open-loop velocity controller.
+
+Hardware setup
+--------------
+
+This example has not yet implemented any mechanism to protect the
+powered device. This means that there is no overtemeprature
+protection, no overcurrent protection and no overvoltage protection.
+
+Make sure that you power the device properly and provide current
+limits on your own so as not to break your hardware.
+
+Configuration
+-------------
+
+The FOC PI current controller parameters can be obtained from the given
+equations::
+
+  Kp = ccb * Ls;
+  pp = Rs / Ls;
+  Ki = pp * Kp * T;
+
+where:
+  - Kp  - PI proportional coefficient
+  - Ki  - PI integral coefficient
+  - Rs  - average phase serial resistance
+  - Ls  - average phase serial inductance
+  - pp  - pole plant
+  - ccb - current control bandwidth
+  - T   - sampling period
+
+Sample parameters for some commercially available motors
+--------------------------------------------------------
+
+========================== == ========== ========= ======= =====
+Motor model                p  Rs         Ls        i_max   v_max
+========================== == ========== ========= ======= =====
+Odrive D6374 150KV         7  0.0254 Ohm 8.73 uH   ?       ?
+Linix 45ZWN24-40           2  0.5 Ohm    0.400 mH  2.34A   24V
+Bull-Running BR2804-1700   7  0.11 Ohm   0.018 mH  1.2A    12V
+iPower GBM2804H-100T       7  5.29 Ohm   1.05 mH   0.15A   12V
+========================== == ========== ========= ======= =====
+
+* Odrive D6374 150KV
+
+====== =========== ===== ======== ======
+f_PWM  f_notifier  ccb   Kp       Ki
+====== =========== ===== ======== ======
+20kHz  10kHz       1000  0.0087   0.0025
+====== =========== ===== ======== ======
+
+
+* Linix 45ZWN24-40 (PMSM motor dedicated for NXP FRDM-MC-LVMTR kit)
+
+====== =========== ===== ======== ======
+f_PWM  f_notifier  ccb   Kp       Ki
+====== =========== ===== ======== ======
+10kHz  5kHz        1000  0.4      0.1
+====== =========== ===== ======== ======
+
+* Bull-Running BR2804-1700 kV (motor provided with the ST P-NUCLEO-IHM07 kit)
+
+====== =========== ===== ======== ======
+f_PWM  f_notifier  ccb   Kp       Ki
+====== =========== ===== ======== ======
+20kHz  10kHz       200   0.036    0.022
+====== =========== ===== ======== ======
+
+
+* iPower GBM2804H-100T (gimbal motor provided with the ST P-NUCLEO-IHM03 kit)
+
+====== =========== ===== ======== ======
+f_PWM  f_notifier  ccb   Kp       Ki
+====== =========== ===== ======== ======
+20kHz  10kHz       TODO  TODO     TODO
+====== =========== ===== ======== ======

Documentation/applications/examples/ft80x/index.rst

@@ -0,0 +1,6 @@
+``ft80x`` FT80x GUI Chip
+========================
+
+This examples has ports of several FTDI demos for the FTDI/BridgeTek FT80x GUI
+chip. As an example configuration, see
+``nuttx/boards/arm/stm32/viewtool-stm32f107/configs/ft80x/defconfig``.

Documentation/applications/examples/ftpc/index.rst

@@ -0,0 +1,40 @@
+``ftpc`` FTP Client
+===================
+
+This is a simple FTP client shell used to exercise the capabilities of the FTPC
+library (``apps/netutils/ftpc``).
+
+From NSH, the startup command sequence is as follows. This is only an example,
+your configuration could have different mass storage devices, mount paths, and
+FTP directories::
+
+  nsh> mount -t vfat /dev/mmcsd0 /tmp  # Mount the SD card at /tmp
+  nsh> cd /tmp                         # cd into the /tmp directory
+  nsh> ftpc <host> <port>              # Start the FTP client
+  nfc> login <name> <password>         # Log into the FTP server
+  nfc> help                            # See a list of FTP commands
+
+where ``<host>`` is the IP address or hostname of the FTP server and ``<port>`` is
+an optional port number.
+
+**Note**: By default, FTPC uses ``readline`` to get data from ``stdin``. So your
+defconfig file must have the following build path::
+
+  CONFIG_SYSTEM_READLINE=y
+
+**Note**: If you use the ftpc task over a telnet NSH connection, then you should
+set the following configuration item::
+
+  CONFIG_EXAMPLES_FTPC_FGETS=y
+
+By default, the FTPC client will use ``readline()`` to get characters from the
+console. Readline includes and command-line editor and echos characters received
+in stdin back through ``stdout``. Neither of these behaviors are desire-able if
+Telnet is used.
+
+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_FEATURES=y
+  CONFIG_DEBUG_INFO=y
+  CONFIG_DEBUG_FTPC=y

Documentation/applications/examples/ftpd/index.rst

@@ -0,0 +1,55 @@
+``ftpd`` FTP daemon
+===================
+
+This example exercises the FTPD daemon at ``apps/netutils/ftpd``. Below are
+configurations specific to the FTPD example (the FTPD daemon itself may require
+other configuration options as well).
+
+- ``CONFIG_EXAMPLES_FTPD`` – Enable the FTPD example.
+- ``CONFIG_EXAMPLES_FTPD_PRIO`` – Priority of the FTP daemon. Default:
+  ``SCHED_PRIORITY_DEFAULT``.
+- ``CONFIG_EXAMPLES_FTPD_STACKSIZE`` – Stack size allocated for the FTP daemon.
+  Default: ``2048``.
+- ``CONFIG_EXAMPLES_FTPD_NONETINIT`` – Define to suppress configuration of the
+  network by ``apps/examples/ftpd``. You would need to suppress network
+  configuration if the network is configuration prior to running the example.
+
+NSH always initializes the network so if ``CONFIG_NSH_NETINIT`` is defined, so is
+``CONFIG_EXAMPLES_FTPD_NONETINIT`` (se it does not explicitly need to be defined
+in that case):
+
+- ``CONFIG_NSH_BUILTIN_APPS`` – Build the FTPD daemon example test as an NSH
+  built-in function. By default the FTPD daemon will be built as a standalone
+  application.
+
+If ``CONFIG_EXAMPLES_FTPD_NONETINIT`` is not defined, then the following may be
+specified to customized the network configuration:
+
+- ``CONFIG_EXAMPLES_FTPD_NOMAC`` – If the hardware has no MAC address of its own,
+  define this ``=y`` to provide a bogus address for testing.
+- ``CONFIG_EXAMPLES_FTPD_IPADDR`` – The target IP address. Default ``10.0.0.2``.
+- ``CONFIG_EXAMPLES_FTPD_DRIPADDR`` – The default router address. Default:
+  ``10.0.0.1``.
+- ``CONFIG_EXAMPLES_FTPD_NETMASK`` – The network mask. Default: ``255.255.255.0``.
+
+TCP networking support is required. So are pthreads so this must be set to 'n':
+
+- ``CONFIG_DISABLE_PTHREAD`` – ``pthread`` support is required.
+
+Other FTPD configuration options they may be of interest:
+
+- ``CONFIG_FTPD_VENDORID`` – The vendor name to use in FTP communications.
+  Default: ``NuttX``.
+- ``CONFIG_FTPD_SERVERID`` – The server name to use in FTP communications.
+  Default: ``NuttX FTP Server``.
+- ``CONFIG_FTPD_CMDBUFFERSIZE`` – The maximum size of one command. Default: ``512``
+  bytes.
+- ``CONFIG_FTPD_DATABUFFERSIZE`` – The size of the I/O buffer for data transfers.
+  Default: ``2048`` bytes.
+- ``CONFIG_FTPD_WORKERSTACKSIZE`` – The stacksize to allocate for each FTP daemon
+  worker thread. Default: ``2048`` bytes.
+
+The following netutils libraries should be enabled in your ``defconfig`` file: ::
+
+  CONFIG_NETUTILS_NETLIB=y
+  CONFIG_NETUTILS_FTPD=y

Documentation/applications/examples/fxos8700cq_test/index.rst

@@ -0,0 +1,4 @@
+``fxos8700cq_test``
+===================
+
+TODO

Documentation/applications/examples/gpio/index.rst

@@ -0,0 +1,4 @@
+``gpio`` GPIO Read and Write
+----------------------------
+
+A simple ``test/example`` of the NuttX GPIO driver.

Documentation/applications/examples/gps/index.rst

@@ -0,0 +1,4 @@
+``gps`` GPS example
+===================
+
+GPS example.

Documentation/applications/examples/hall/index.rst

@@ -0,0 +1,4 @@
+``hall`` Hall effect sensor example
+===================================
+
+Hall effect sensor example.

Documentation/applications/examples/hdc1008_demo/index.rst

@@ -0,0 +1,4 @@
+``hdc1008_demo`` HDC1008 driver example
+=======================================
+
+HDC1008 driver example.

Documentation/applications/examples/hello/index.rst

@@ -0,0 +1,9 @@
+``hello`` Hello World
+=====================
+
+This is the mandatory, "Hello, World" example. It is little more than
+``examples/null`` with a single ``printf`` statement. Really useful only for
+bringing up new NuttX architectures.
+
+- ``CONFIG_NSH_BUILTIN_APPS`` – Build the "Hello, World" example as an NSH
+  built-in application.

Documentation/applications/examples/hello_nim/index.rst

@@ -0,0 +1,4 @@
+``hello_nim`` Hello World in Nim
+================================
+
+Hello World in Nim.

Documentation/applications/examples/hello_rust/index.rst

@@ -0,0 +1,4 @@
+``hello_rust`` Hello World in Rust
+==================================
+
+Hello World in Rust.

Documentation/applications/examples/hello_wasm/index.rst

@@ -0,0 +1,4 @@
+``hello_wasm`` Hello World in WASM
+==================================
+
+Hello World in WASM.

Documentation/applications/examples/hello_zig/index.rst

@@ -0,0 +1,4 @@
+``hello_zig`` Hello World in Zig
+================================
+
+Hello World in Zig.

Documentation/applications/examples/helloxx/index.rst

@@ -0,0 +1,35 @@
+``helloxx`` Hello World in C++
+==============================
+
+This is C++ version of the "Hello, World" example. It is intended only to
+verify that the C++ compiler is functional, that basic C++ library support is
+available, and that class are instantiated correctly.
+
+NuttX configuration prerequisites:
+
+- ``CONFIG_HAVE_CXX`` – Enable C++ Support.
+
+Optional NuttX configuration settings:
+
+- ``CONFIG_HAVE_CXXINITIALIZE`` – Enable support for static constructors (may not
+  be available on all platforms).
+
+NuttX configuration settings specific to this example:
+
+- ``CONFIG_NSH_BUILTIN_APPS`` – Build the helloxx example as a built-in that can
+  be executed from the NSH command line.
+
+Also needed:
+
+- ``CONFIG_HAVE_CXX=y``
+
+And you may have to tinker with the following to get libxx to compile properly:
+
+- ``CCONFIG_ARCH_SIZET_LONG=y`` or ``=n``.
+
+The argument of the ``new`` operators should take a type of ``size_t``. But ``size_t``
+has an unknown underlying. In the nuttx ``sys/types.h`` header file, ``size_t`` is
+typed as ``uint32_t`` (which is determined by architecture-specific logic). But
+the C++ compiler may believe that ``size_t`` is of a different type resulting in
+compilation errors in the operator. Using the underlying integer type Instead of
+``size_t`` seems to resolve the compilation issues.

Documentation/applications/examples/hidkbd/index.rst

@@ -0,0 +1,17 @@
+``hidkbd`` USB Host HID keyboard
+================================
+
+This is a simple test to ``debug/verify`` the USB host HID keyboard class driver.
+
+- ``CONFIG_EXAMPLES_HIDKBD_DEFPRIO`` – Priority of waiter thread. Default: ``50``.
+- ``CONFIG_EXAMPLES_HIDKBD_STACKSIZE`` – Stacksize of waiter thread. Default
+  ``1024``.
+- ``CONFIG_EXAMPLES_HIDKBD_DEVNAME`` – Name of keyboard device to be used.
+  Default: ``/dev/kbda``.
+- ``CONFIG_EXAMPLES_HIDKBD_ENCODED`` –  Decode special key press events in the
+  user buffer. In this case, the example coded will use the interfaces defined
+  in ``include/nuttx/input/kbd_codec.h`` to decode the returned keyboard data.
+  These special keys include such things as up/down arrows, home and end keys,
+  etc. If this not defined, only 7-bit printable and control ASCII characters
+  will be provided to the user. Requires ``CONFIG_HIDKBD_ENCODED`` and
+  ``CONFIG_LIBC_KBDCODEC``.

Documentation/applications/examples/hts221_reader/index.rst

@@ -0,0 +1,4 @@
+``hts221_reader`` ``HTS221`` Humidity Sensor
+============================================
+
+A simple reader example for the ``HTS221`` humidity sensor.

Documentation/applications/examples/i2cchar/index.rst

@@ -0,0 +1,52 @@
+``i2cchar`` Transfer Through I2C
+================================
+
+A mindlessly simple test of an I2C driver. It reads an write garbage data to the
+I2C transmitter and/or received as fast possible.
+
+This test depends on these specific I2S/AUDIO/NSH configurations settings (your
+specific I2S settings might require additional settings).
+
+- ``CONFIG_I2S`` – Enabled I2S support.
+- ``CONFIG_AUDIO`` – Enabled audio support.
+- ``CONFIG_DRIVERS_AUDIO`` – Enable audio device support.
+- ``CONFIG_AUDIO_I2SCHAR`` – Enabled support for the I2S character device.
+- ``CONFIG_NSH_BUILTIN_APPS`` – Build the I2S test as an NSH built-in function.
+  Default: Built as a standalone program.
+
+Specific configuration options for this example include:
+
+- ``CONFIG_EXAMPLES_I2SCHAR`` – Enables the I2C test.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_DEVPATH`` – The default path to the ADC device.
+  Default: ``/dev/i2schar0``.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_TX`` – This should be set if the I2S device supports a
+  transmitter.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_TXBUFFERS`` – This is the default number of audio
+  buffers to send before the TX transfers terminate. When both TX and RX
+  transfers terminate, the task exits (and, if an NSH builtin, the ``i2schar``
+  command returns). This number can be changed from the NSH command line.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_TXSTACKSIZE`` – This is the stack size to use when
+  starting the transmitter thread. Default ``1536``.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_RX`` – This should be set if the I2S device supports a
+  transmitter.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_RXBUFFERS`` – This is the default number of audio
+  buffers to receive before the RX transfers terminate. When both TX and RX
+  transfers terminate, the task exits (and, if an NSH builtin, the ``i2schar``
+  command returns). This number can be changed from the NSH command line.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_RXSTACKSIZE`` – This is the stack size to use when
+  starting the receiver thread. Default ``1536``.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_BUFSIZE`` – The size of the data payload in one audio
+  buffer. Applies to both TX and RX audio buffers.
+
+- ``CONFIG_EXAMPLES_I2SCHAR_DEVINIT`` – Define if architecture-specific I2S device
+  initialize is available. If defined, the platform specific code must provide a
+  function ``i2schar_devinit()`` that will be called each time that this test
+  executes. Not available in the kernel build mode.

Documentation/applications/examples/i2sloop/index.rst

@@ -0,0 +1,4 @@
+``i2sloop`` I2S loopback test
+=============================
+
+I2S loopback test.

Documentation/applications/examples/igmp/index.rst

@@ -0,0 +1,13 @@
+``igmp`` Trivial IGMP
+=====================
+
+This is a trivial test of the NuttX IGMP capability. It present it does not do
+much of value – Much more is needed in order to verify the IGMP features!
+
+- ``CONFIG_EXAMPLES_IGMP_NOMAC`` – Set if the hardware has no MAC address; one
+  will be assigned.
+- ``CONFIG_EXAMPLES_IGMP_IPADDR`` – Target board IP address.
+- ``CONFIG_EXAMPLES_IGMP_DRIPADDR`` – Default router address.
+- ``CONFIG_EXAMPLES_IGMP_NETMASK`` – Network mask.
+- ``CONFIG_EXAMPLES_IGMP_GRPADDR`` – Multicast group address.
+- ``CONFIG_EXAMPLES_NETLIB`` – The networking library is needed.

Documentation/applications/examples/ina219/index.rst

@@ -0,0 +1,5 @@
+``ina219`` Current/Power Monitor INA219
+=======================================
+
+This is a simple infinite loop that polls the ``INA219`` sensor and displays the
+measurements.

Documentation/applications/examples/ina226/index.rst

@@ -0,0 +1,4 @@
+``ina226``
+==========
+
+TODO

Documentation/applications/examples/index.rst

@@ -0,0 +1,38 @@
+Examples
+========
+
+Selecting Examples
+------------------
+
+The examples directory contains several sample applications that can be linked
+with NuttX. The specific example is selected in the
+``boards/<arch-name>/<chip-name>/<board-name>/configs/<config>/defconfig`` file
+via the ``CONFIG_EXAMPLES_xyz`` setting where ``xyz`` is the name of the example.
+For example::
+
+  CONFIG_EXAMPLES_HELLO=y
+
+Selects the ``examples/hello`` "Hello, World!" example.
+
+Built-In Functions
+------------------
+
+Some of the examples may be built as built-in functions that can be executed
+at run time (rather than as NuttX main programs). These built-in examples
+can be also be executed from the NuttShell (NSH) command line. In order to
+configure these built-in NSH functions, you have to set up the following:
+
+- ``CONFIG_NSH_BUILTIN_APPS`` – Enable support for external registered, named
+  applications that can be executed from the NSH command line (see
+  ``apps/README.md`` for more information).
+
+
+Supported examples
+------------------
+
+.. toctree::
+   :glob:
+   :maxdepth: 3
+   :titlesonly:
+   
+   */*

Documentation/applications/examples/ini_dumper/index.rst

@@ -0,0 +1,4 @@
+``ini_dumper``
+==============
+
+TODO

Documentation/applications/examples/ipcfg/index.rst

@@ -0,0 +1,4 @@
+``ipcfg``
+=========
+
+TODO

Documentation/applications/examples/ipforward/index.rst

@@ -0,0 +1,6 @@
+``ipforward`` IP Forwarding Using TUN
+=====================================
+
+A simple test of IP forwarding using TUN devices. This can be used on any
+platform, but was intended for use on the simulation platform because it
+performs a test of IP forwarding without the use of hardware.

Documentation/applications/examples/json/index.rst

@@ -0,0 +1,12 @@
+``json`` cJSON
+==============
+
+This example exercises the cJSON implementation at ``apps/netutils/json``. This
+example contains logic taken from the cJSON project:
+
+http://sourceforge.net/projects/cjson/
+
+The example corresponds to SVN revision ``r42`` (with lots of changes for NuttX
+coding standards). As of ``r42``, the SVN repository was last updated on
+``2011-10-10`` so I presume that the code is stable and there is no risk of
+maintaining duplicate logic in the NuttX repository.

Documentation/applications/examples/keyboard/index.rst

@@ -0,0 +1,4 @@
+``keyboard``
+============
+
+TODO

Documentation/applications/examples/leds/index.rst

@@ -0,0 +1,5 @@
+``leds`` Toggle LEDs
+====================
+
+This is a simple test of the board LED driver at
+``nuttx/drivers/leds/userled_*.c``.

Documentation/applications/examples/libtest/index.rst

@@ -0,0 +1,18 @@
+``libtest`` Static Library Test
+===============================
+
+This example illustrates how you may create a static library. It does the
+following:
+
+It creates a static library called libtest.a that contains an object that provides
+the symbol library_test().
+
+At adds the library as an EXTRA_LIB in the build::
+
+  EXTRA_LIBS += -ltest
+  EXTRA_LIBPATHS += -L$(APPDIR)/examples/libtest
+
+And optionally, it can be configured to:
+
+Generate a built-in command that can be executed by NSH. This command logic links
+with the symbol library_test() that will provided by the libtest.a static library.

Documentation/applications/examples/lis3dsh_reader/index.rst

@@ -0,0 +1,5 @@
+``lis3dsh_reader`` ``LIS3DSH`` Accelerometer
+============================================
+
+A simple reader example for the ``LIS3DSH`` acceleration sensor as found on
+STM32F4Discovery rev. C.

Documentation/applications/examples/lp503x/index.rst

@@ -0,0 +1,4 @@
+``lp503x`` 
+===========
+
+TODO

Documentation/applications/examples/lsm303_reader/index.rst

@@ -0,0 +1,4 @@
+``lsm303_reader`` ``LSM303`` Accelerometer/Magnetometer
+=======================================================
+
+A simple reader example for the ``LSM303`` acc-mag sensor.

Documentation/applications/examples/lsm6dsl_reader/index.rst

@@ -0,0 +1,4 @@
+``lsm6dsl_reader`` ``LSM6DSL`` Accelerometer/Gyroscope
+======================================================
+
+A simple reader example for the ``LSM6DSL`` acc-gyro sensor.

Documentation/applications/examples/ltr308/index.rst

@@ -0,0 +1,4 @@
+``ltr308`` 
+===========
+
+TODO

Documentation/applications/examples/lua_module/index.rst

@@ -0,0 +1,10 @@
+``lua_module`` Hello World Lua module
+=====================================
+
+A Lua C module showing how to add built-in modules to the Lua interpreter.
+Usage:
+
+.. code-block:: lua
+
+    > hello.say_hello()
+    "Hello World!"

Documentation/applications/examples/lvgldemo/index.rst

@@ -0,0 +1,4 @@
+``lvgldemo``
+============
+
+TODO

Documentation/applications/examples/lvglterm/index.rst

@@ -0,0 +1,13 @@
+``lvglterm`` LVGL Terminal for NuttShell (NSH)
+==============================================
+
+LVGL application that executes NuttShell (NSH) commands entered with a
+Touchscreen Keyboard and displays the NSH output. Prerequisite configuration
+settings:
+
+- ``CONFIG_NSH_ARCHINIT=n`` – NSH architecture initialization must be disabled.
+- ``CONFIG_NSH_CONSOLE=y`` – NSH must be configured to use a console.
+- ``CONFIG_LIBC_EXECFUNCS=y`` – posix_spawn() must be enabled.
+- ``CONFIG_PIPES=y`` – Pipes must be enabled.
+- ``CONFIG_GRAPHICS_LVGL=y`` – LVGL graphics must be enabled.
+- ``CONFIG_LV_FONT_UNSCII_16=y`` – LVGL font UNSCII 16 must be enabled.

Documentation/applications/examples/max31855/index.rst

@@ -0,0 +1,4 @@
+``max31855``
+============
+
+TODO

Documentation/applications/examples/mcuboot/index.rst

@@ -0,0 +1,4 @@
+``mcuboot``
+===========
+
+TODO

Documentation/applications/examples/media/index.rst

@@ -0,0 +1,25 @@
+``media``
+=========
+
+The media test simply writes values onto the media hidden behind a character
+driver and verifies that the media can be successfully written and read. This
+low level test is useful in the early phases of the bringup of a new block or
+mtd driver because it avoids the complexity of a file system.
+
+This test uses a character driver and cannot directly access block or mtd
+drivers. This test is suitable for use EEPROM character drivers (see
+``nuttx/drivers/eeprom``), or with block drivers wrapped as character drivers (see
+``nuttx/drivers/bch``)
+
+.. code-block:: C
+
+  int ret = bchdev_register(<path-to-block-driver>, <path-to-character-driver>,
+                            false);
+
+MTD drivers need an additional wrapper layer, the FTL wrapper must first be used
+to convert the MTD driver to a block device:
+
+.. code-block:: C
+
+  int ret = ftl_initialize(<N>, mtd);
+  ret = bchdev_register(/dev/mtdblock<N>, <path-to-character-driver>, false);

Documentation/applications/examples/mld/index.rst

@@ -0,0 +1,4 @@
+``mld``
+=======
+
+TODO

Documentation/applications/examples/mlx90614/index.rst

@@ -0,0 +1,4 @@
+``mlx90614``
+============
+
+TODO

Documentation/applications/examples/mml_parser/index.rst

@@ -0,0 +1,4 @@
+``mml_parser``
+==============
+
+TODO

Documentation/applications/examples/modbus/index.rst

@@ -0,0 +1,18 @@
+``modbus`` FreeModbus
+=====================
+
+This is a port of the FreeModbus Linux demo. It derives from the demos/LINUX
+directory of the FreeModBus version ``1.5.0`` (June 6, 2010) that can be
+downloaded in its entirety from
+http://developer.berlios.de/project/showfiles.php?group_id=6120.
+
+- ``CONFIG_EXAMPLES_MODBUS_PORT``, Default ``0`` (for ``/dev/ttyS0``).
+- ``CONFIG_EXAMPLES_MODBUS_BAUD``, Default B``38400``.
+- ``CONFIG_EXAMPLES_MODBUS_PARITY``, Default ``MB_PAR_EVEN``.
+- ``CONFIG_EXAMPLES_MODBUS_REG_INPUT_START``, Default ``1000``.
+- ``CONFIG_EXAMPLES_MODBUS_REG_INPUT_NREGS``, Default ``4``.
+- ``CONFIG_EXAMPLES_MODBUS_REG_HOLDING_START``, Default ``2000``.
+- ``CONFIG_EXAMPLES_MODBUS_REG_HOLDING_NREGS``, Default ``130``.
+
+The FreeModBus library resides at ``apps/modbus``. See ``apps/modbus/README.txt``
+for additional configuration information.

Documentation/applications/examples/modbusmaster/index.rst

@@ -0,0 +1,4 @@
+``modbusmaster``
+================
+
+TODO

Documentation/applications/examples/module/index.rst

@@ -0,0 +1,61 @@
+``module`` Loadable Module
+==========================
+
+This example builds a small loadable module test case. This includes a character
+driver under ``examples/module/drivers``. This driver is built using the
+relocatable ELF format and installed in a ROMFS file system. At run time, the
+driver module is loaded and exercised. Requires ``CONFIG_MODULE``. Other
+configuration options:
+
+- ``CONFIG_EXAMPLES_ELF_DEVMINOR`` – The minor device number of the ROMFS block
+  driver. For example, the ``N`` in ``/dev/ramN``. Used for registering the RAM
+  block driver that will hold the ROMFS file system containing the ELF
+  executables to be tested. Default: ``0``.
+
+- ``CONFIG_EXAMPLES_ELF_DEVPATH`` – The path to the ROMFS block driver device.
+  This must match ``EXAMPLES_ELF_DEVMINOR``. Used for registering the RAM block
+  driver that will hold the ROMFS file system containing the ELF executables to
+  be tested. Default: ``/dev/ram0``.
+
+**Notes**:
+
+1. ``CFLAGS`` should be provided in ``CMODULEFLAGS``. RAM and FLASH memory regions
+   may require long allcs. For ARM, this might be::
+
+     CMODULEFLAGS = $(CFLAGS) -mlong-calls
+
+   Similarly for C++ flags which must be provided in ``CXXMODULEFLAGS``.
+
+2. Your top-level ``nuttx/Make.defs`` file must also include an appropriate
+   definition, LDMODULEFLAGS, to generate a relocatable ELF object. With GNU LD,
+   this should include ``-r`` and ``-e <entry point>``.::
+
+     LDMODULEFLAGS = -r -e module_initialize
+
+   If you use GCC to link, you make also need to include ``-nostdlib``.
+
+3. This example also requires ``genromfs``. ``genromfs`` can be build as part of the
+   nuttx toolchain. Or can built from the ``genromfs`` sources that can be found
+   in the NuttX tools repository (``genromfs-0.5.2.tar.gz``). In any event, the
+   PATH variable must include the path to the ``genromfs`` executable.
+
+4. ELF size: The ELF files in this example are, be default, quite large because
+   they include a lot of build garbage. You can greatly reduce the size of the
+   ELF binaries are using the ``objcopy --strip-unneeded`` command to remove
+   un-necessary information from the ELF files.
+
+5. Simulator. You cannot use this example with the NuttX simulator on Cygwin.
+   That is because the Cygwin GCC does not generate ELF file but rather some
+   Windows-native binary format.
+
+   If you really want to do this, you can create a NuttX x86 ``buildroot``
+   toolchain and use that be build the ELF executables for the ROMFS file
+   system.
+
+6. Linker scripts. You might also want to use a linker scripts to combine
+   sections better. An example linker script is at
+   ``nuttx/libc/modlib/gnu-elf.ld``. That example might have to be tuned for your
+   particular linker output to position additional sections correctly. The GNU
+   LD ``LDMODULEFLAGS`` then might be::
+
+     LDMODULEFLAGS = -r -e module_initialize -T$(TOPDIR)/libc/modlib/gnu-elf.ld

Documentation/applications/examples/mount/index.rst

@@ -0,0 +1,18 @@
+``mount`` Mount Filesystem
+==========================
+
+This contains a simple test of filesystem mountpoints.
+
+- ``CONFIG_EXAMPLES_MOUNT_DEVNAME`` – The name of the user-provided block device
+  to mount. If ``CONFIG_EXAMPLES_MOUNT_DEVNAME`` is not provided, then a RAM disk
+  will be configured.
+
+- ``CONFIG_EXAMPLES_MOUNT_NSECTORS`` – The number of sectors in the RAM disk
+  used when ``CONFIG_EXAMPLES_MOUNT_DEVNAME`` is not defined.
+
+- ``CONFIG_EXAMPLES_MOUNT_SECTORSIZE`` – The size of each sectors in the RAM disk
+  used when ``CONFIG_EXAMPLES_MOUNT_DEVNAME`` is not defined.
+
+- ``CONFIG_EXAMPLES_MOUNT_RAMDEVNO`` – The RAM device minor number used to mount
+  the RAM disk used when ``CONFIG_EXAMPLES_MOUNT_DEVNAME`` is not defined. The
+  default is zero (meaning that ``/dev/ram0`` will be used).

Documentation/applications/examples/mqttc/index.rst

@@ -0,0 +1,25 @@
+``mqttc``
+=========
+
+This is a simple MQTT publisher example using MQTT-C
+
+By default it publishes to the "test" topic and exits.  Default behaviour
+including, host, port, topic, message and loop count can be changed through
+different arguments.
+
+To test:
+From the host start an MQTT broker and subscribe to the "test" topic.  Here
+mosquitto is used::
+
+  mosquitto&
+  mosquitto_sub -t test
+
+Make sure that mosquitto is not configured in local mode only.
+
+From the nsh:
+
+Launch the built-in app ``mqttc_pub`` specifying the host::
+
+  mqttc_pub -h HOST
+
+The target will publish the message "test".

Documentation/applications/examples/mtdpart/index.rst

@@ -0,0 +1,28 @@
+``mtdpart`` MTD Partition Test
+==============================
+
+This examples provides a simple test of MTD partition logic.
+
+- ``CONFIG_EXAMPLES_MTDPART`` – Enables the MTD partition test example.
+
+- ``CONFIG_EXAMPLES_MTDPART_ARCHINIT`` – The default is to use the RAM MTD device
+  at ``drivers/mtd/rammtd.c``. But an architecture-specific MTD driver can be used
+  instead by defining ``CONFIG_EXAMPLES_MTDPART_ARCHINIT``. In this case, the
+  initialization logic will call ``mtdpart_archinitialize()`` to obtain the MTD
+  driver instance.
+
+- ``CONFIG_EXAMPLES_MTDPART_NPARTITIONS`` – This setting provides the number of
+  partitions to test. The test will divide the reported size of the MTD device
+  into equal-sized sub-regions for each test partition. Default: ``3``.
+
+When ``CONFIG_EXAMPLES_MTDPART_ARCHINIT`` is not defined, this test will use the
+RAM MTD device at ``drivers/mtd/rammtd.c`` to simulate FLASH. The size of the
+allocated RAM drive will be: ``CONFIG_EXMPLES_RAMMTD_ERASESIZE *
+CONFIG_EXAMPLES_MTDPART_NEBLOCKS``.
+
+* ``CONFIG_EXAMPLES_MTDPART_ERASESIZE`` – This value gives the size of one erase
+  block in the MTD RAM device. This must exactly match the default configuration
+  in ``drivers/mtd/rammtd.c``!
+
+* ``CONFIG_EXAMPLES_MTDPART_NEBLOCKS`` – This value gives the number of erase
+  blocks in MTD RAM device.

Documentation/applications/examples/mtdrwb/index.rst

@@ -0,0 +1,24 @@
+``mtdrwb`` MTD Read-ahead and Write Buffering
+=============================================
+
+This examples provides a simple test of MTD Read-Ahead/Write buffering logic.
+
+- ``CONFIG_EXAMPLES_MTDRWB`` – Enables the MTD R/W buffering test example.
+
+- ``CONFIG_EXAMPLES_MTDRWB_ARCHINIT`` – The default is to use the RAM MTD device
+  at ``drivers/mtd/rammtd.c``. But an architecture-specific MTD driver can be used
+  instead by defining ``CONFIG_EXAMPLES_MTDRWB_ARCHINIT``. In this case, the
+  initialization logic will call ``mtdrwb_archinitialize()`` to obtain the MTD
+  driver instance.
+
+When ``CONFIG_EXAMPLES_MTDRWB_ARCHINIT`` is not defined, this test will use the
+RAM MTD device at ``drivers/mtd/rammtd.c`` to simulate FLASH. The size of the
+allocated RAM drive will be: ``CONFIG_EXMPLES_RAMMTD_ERASESIZE *
+CONFIG_EXAMPLES_MTDRWB_NEBLOCKS``
+
+- ``CONFIG_EXAMPLES_MTDRWB_ERASESIZE`` – This value gives the size of one erase
+  block in the MTD RAM device. This must exactly match the default configuration
+  in ``drivers/mtd/rammtd.c``!
+
+- ``CONFIG_EXAMPLES_MTDRWB_NEBLOCKS`` – This value gives the number of erase
+  blocks in MTD RAM device.

Documentation/applications/examples/netlink_route/index.rst

@@ -0,0 +1,4 @@
+``netlink_route``
+=================
+
+TODO

Documentation/applications/examples/netloop/index.rst

@@ -0,0 +1,17 @@
+``netloop`` Network loopback device
+===================================
+
+This is a simple test of the netwok loopback device. ``examples/nettest`` can also
+be configured to provide (better) test of local loopback transfers. This version
+derives from ``examples/poll`` and is focused on testing ``poll()`` with loopback
+devices.
+
+- ``CONFIG_EXAMPLES_NETLOOP=y`` – Enables the nettest example.
+
+Dependencies:
+
+- ``CONFIG_NET_LOOPBACK`` – Requires local loopback support.
+- ``CONFIG_NET_TCP`` – Requires TCP support with the following:
+   - ``CONFIG_NET_TCPBACKLOG``
+   - ``CONFIG_NET_TCP_WRITE_BUFFERS``
+- ``CONFIG_NET_IPv4`` – Currently supports only IPv4.

Documentation/applications/examples/netpkt/index.rst

@@ -0,0 +1,4 @@
+``netpkt`` ``AF_PACKET`` Raw Sockets
+====================================
+
+A test of ``AF_PACKET``, raw sockets. Contributed by Lazlo Sitzer.

Documentation/applications/examples/nettest/index.rst

@@ -0,0 +1,17 @@
+``nettest`` Client/Server Over TCP
+==================================
+
+This is a simple network test for verifying client- and server- functionality in
+a TCP/IP connection.
+
+- ``CONFIG_EXAMPLES_NETTEST=y`` – Enables the nettest example.
+- ``CONFIG_EXAMPLES_NETLIB=y`` – The networking library in needed.
+
+Configurations:
+
+- Server on target hardware; client on host.
+- Client on target hardware; server on host.
+- Server and Client on different targets.
+- Loopback configuration with both client and server on the same target.
+
+See also ``examples/tcpecho``.

Documentation/applications/examples/nimble/index.rst

@@ -0,0 +1,4 @@
+``nimble``
+==========
+
+TODO

Documentation/applications/examples/nng_test/index.rst

@@ -0,0 +1,4 @@
+``nng_test``
+============
+
+TODO