This is an automated email from the ASF dual-hosted git repository.
xiaoxiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/nuttx-apps.git
commit 7e918964e444575a8b096eaeb360850ad69860d1
Author: raiden00pl <raide...@railab.me>
AuthorDate: Tue Oct 24 14:05:33 2023 +0200
remove examples/xxx/README.md. Migrated to
Documentation/applications/examples
part of examples/bastest is moved to examples/bastest.testcases.md
---
examples/README.md | 2187 --------------------------
examples/bastest/{README.md => testcases.md} | 46 -
examples/camera/README.md | 42 -
examples/flash_test/README.md | 23 -
examples/flowc/README.md | 17 -
examples/foc/README.md | 82 -
examples/json/README.md | 298 ----
examples/mcuboot/swap_test/README.md | 138 --
examples/mqttc/README.md | 25 -
examples/pdcurses/README.md | 17 -
examples/tcp_ipc_client/README.md | 26 -
examples/tcp_ipc_server/README.md | 28 -
examples/tcpblaster/README.md | 43 -
examples/telnetd/README.md | 7 -
14 files changed, 2979 deletions(-)
diff --git a/examples/README.md b/examples/README.md
deleted file mode 100644
index ed91792be..000000000
--- a/examples/README.md
+++ /dev/null
@@ -1,2187 +0,0 @@
-# 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:
-
-```conf
-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).
-
-## `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`.
-
-## `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`.
-
-## `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.
-
-## `apa102` Rainbow on `APA102` LED Strip
-
-Rainbow example for `APA102` LED Strip.
-
-## `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`.
-
-## `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.
-
-## `buttons` Read GPIO Buttons
-
-To be provided.
-
-## `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.
-
-## `canard`
-
-Example application for `canutils/libcarnard`.
-
-## `cctype`
-
-Verifies all possible inputs for all functions defined in the header file
-`cctype`.
-
-## `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.
-
-## `configdata`
-
-This is a Unit Test for the MTD configuration data driver.
-
-## `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.
-
-## `cordic`
-
-A simple test of the CORDIC character driver.
-
-## `dac` Write to DAC
-
-This is a tool for writing values to DAC device.
-
-## `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:
-
-```bash
-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.
-
-## `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.
-
-## `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`.
-
-## `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:
-
- ```makefile
- 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).
-
- ```makefile
- 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:
-
- ```makefile
- LDELFFLAGS = -r -e main -T$(TOPDIR)/binfmt/libelf/gnu-elf.ld
- ```
-
-## `fb` Framebuffer
-
-A simple test of the framebuffer character driver.
-
-## `flash_test` SMART Flash
-
-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.
-
-## `foc` FOC motor controller
-
-A FOC motor controller based on the NuttX FOC driver and the NuttX FOC library.
-See `apps/foc/README.md` for more information.
-
-## `flowc` Serial Hardware Flow Control
-
-A simple test of serial hardware flow control.
-
-## `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`.
-
-## `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:
-
-```conf
-CONFIG_SYSTEM_READLINE=y
-```
-
-**Note**: If you use the ftpc task over a telnet NSH connection, then you
should
-set the following configuration item:
-
-```conf
-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:
-
-```conf
-CONFIG_DEBUG_FEATURES=y
-CONFIG_DEBUG_INFO=y
-CONFIG_DEBUG_FTPC=y
-```
-
-## `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:
-
-```conf
-CONFIG_NETUTILS_NETLIB=y
-CONFIG_NETUTILS_FTPD=y
-```
-
-## `gpio` GPIO Read and Write
-
-A simple `test/example` of the NuttX GPIO driver.
-
-## `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.
-
-## `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.
-
-## `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`.
-
-## `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.
-
-## `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.
-
-## `ina219` Current/Power Monitor `INA219`
-
-This is a simple infinite loop that polls the `INA219` sensor and displays the
-measurements.
-
-## `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.
-
-## `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.
-
-## `leds` Toggle LEDs
-
-This is a simple test of the board LED driver at
-`nuttx/drivers/leds/userled_*.c`.
-
-## `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
-E XTRA_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.
-
-## `luamod_hello` Hello World Lua module
-
-A Lua C module showing how to add built-in modules to the Lua interpreter.
-Usage:
-
-```lua
-> hello.say_hello()
-"Hello World!"
-```
-
-## `lis2csh_reader` `LIS3DSH` Accelerometer
-
-A simple reader example for the `LIS3DSH` acceleration sensor as found on
-STM32F4Discovery rev. C.
-
-## `hts221_reader` `HTS221` Humidity Sensor
-
-A simple reader example for the `HTS221` humidity sensor.
-
-## `lsm303_reader` `LSM303` Accelerometer/Magnetometer
-
-A simple reader example for the `LSM303` acc-mag sensor.
-
-## `lsm6dsl_reader` `LSM6DSL` Accelerometer/Gyroscope
-
-A simple reader example for the `LSM6DSL` acc-gyro sensor.
-
-## `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.
-
-## `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`)
-
-```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:
-
-```c
-int ret = ftl_initialize(<N>, mtd);
-ret = bchdev_register(/dev/mtdblock<N>, <path-to-character-driver>,
- false);
-```
-
-## `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:
-
- ```makefile
- 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>`.
-
- ```makefile
- 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:
-
- ```makefile
- LDMODULEFLAGS = -r -e module_initialize -T$(TOPDIR)/libc/modlib/gnu-elf.ld
- ```
-
-## `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.
-
-## `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).
-
-## `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.
-
-## `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.
-
-## `netpkt` `AF_PACKET` _Raw_ Sockets
-
-A test of `AF_PACKET`, _raw_ sockets. Contributed by Lazlo Sitzer.
-
-## `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.
-
-## `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`.
-
-## `nrf24l01_term` NRF24L01 Wireless Connection
-
-These is a simple test of NRF24L01-based wireless connectivity. Enabled with:
-
-- `CONFIG_EXAMPLES_NRF24L01TERM`
-
-Options:
-
-- `CONFIG_NSH_BUILTIN_APPS` – Built as an NSH built-in applications.
-
-## `nx`
-
-This directory contains a simple test of a subset of the NX APIs defined in
-`include/nuttx/nx/nx.h`. The following configuration options can be selected:
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the NX example as a _built-in_ that can be
- executed from the NSH command line
-- `CONFIG_EXAMPLES_NX_BGCOLOR` – The color of the background. Default depends
on
- `CONFIG_EXAMPLES_NX_BPP`.
-- `CONFIG_EXAMPLES_NX_COLOR1` – The color of window 1. Default depends on
- `CONFIG_EXAMPLES_NX_BPP`.
-- `CONFIG_EXAMPLES_NX_COLOR2` – The color of window 2. Default depends on
- `CONFIG_EXAMPLES_NX_BPP`.
-- `CONFIG_EXAMPLES_NX_TBCOLOR` – The color of the toolbar. Default depends on
- `CONFIG_EXAMPLES_NX_BPP`.
-- `CONFIG_EXAMPLES_NX_FONTID` – Selects the font (see font ID numbers in
- `include/nuttx/nx/nxfonts.h`).
-- `CONFIG_EXAMPLES_NX_FONTCOLOR` – The color of the fonts. Default depends on
- `CONFIG_EXAMPLES_NX_BPP`.
-- `CONFIG_EXAMPLES_NX_BPP` – Pixels per pixel to use. Valid options include
`2`,
- `4`, `8`, `16`, `24` and `32`. Default is `32`.
-- `CONFIG_EXAMPLES_NX_RAWWINDOWS` – Use raw windows; Default is to use pretty,
- framed NXTK windows with toolbars.
-- `CONFIG_EXAMPLES_NX_STACKSIZE` – The stacksize to use when creating the NX
- server. Default `2048`.
-- `CONFIG_EXAMPLES_NX_CLIENTPRIO` – The client priority. Default: `100`
-- `CONFIG_EXAMPLES_NX_SERVERPRIO` – The server priority. Default: `120`
-- `CONFIG_EXAMPLES_NX_LISTENERPRIO` – The priority of the event listener
thread.
- Default `80`.
-
-The example also has the following settings and will generate an error if they
-are not as expected:
-
-```conf
-CONFIG_DISABLE_MQUEUE=n
-CONFIG_DISABLE_PTHREAD=n
-CONFIG_NX_BLOCKING=y
-CONFIG_BOARDCTL=y
-```
-
-## `nxterm` Display NuttShell (NSH) as NX Console
-
-This directory contains yet another version of the NuttShell (NSH). This
version
-uses the NX console device defined in `include/nuttx/nx/nxterm.h` for output.
-the result is that the NSH input still come from the standard console input
-(probably a serial console). But the text output will go to an NX winbdow.
-Prerequisite configuration settings for this test include:
-
-- `CONFIG_NX=y` – NX graphics must be enabled
-- `CONFIG_NXTERM=y` – The NX console driver must be built
-- `CONFIG_DISABLE_MQUEUE=n` – Message queue support must be available.
-- `CONFIG_DISABLE_PTHREAD=n` – pthreads are needed
-- `CONFIG_NX_BLOCKING=y` – pthread APIs must be blocking
-- `CONFIG_NSH_CONSOLE=y` – NSH must be configured to use a console.
-
-The following configuration options can be selected to customize the test:
-
-- `CONFIG_EXAMPLES_NXTERM_BGCOLOR` – The color of the background. Default
- Default is a darker royal blue.
-- `CONFIG_EXAMPLES_NXTERM_WCOLOR` – The color of the window. Default is a light
- slate blue.
-- `CONFIG_EXAMPLES_NXTERM_FONTID` – Selects the font (see font ID numbers in
- `include/nuttx/nx/nxfonts.h`).
-- `CONFIG_EXAMPLES_NXTERM_FONTCOLOR` – The color of the fonts. Default is
black.
-- `CONFIG_EXAMPLES_NXTERM_BPP` – Pixels per pixel to use. Valid options include
- `2`, `4`, `8`, `16`, `24` and `32`. Default is `32`.
-- `CONFIG_EXAMPLES_NXTERM_TOOLBAR_HEIGHT` – The height of the toolbar. Default:
- `16`.
-- `CONFIG_EXAMPLES_NXTERM_TBCOLOR` – The color of the toolbar. Default is a
- medium grey.
-- `CONFIG_EXAMPLES_NXTERM_MINOR` – The NX console device minor number. Default
- is `0` corresponding to `/dev/nxterm0`.
-- `CONFIG_EXAMPLES_NXTERM_DEVNAME` – The quoted, full path to the NX console
- device corresponding to `CONFIG_EXAMPLES_NXTERM_MINOR`. Default:
- `/dev/nxterm0`.
-- `CONFIG_EXAMPLES_NXTERM_PRIO` – Priority of the NxTerm task. Default:
- `SCHED_PRIORITY_DEFAULT`.
-- `CONFIG_EXAMPLES_NXTERM_STACKSIZE` – Stack size allocated for the NxTerm
task.
- Default: `2048`.
-- `CONFIG_EXAMPLES_NXTERM_STACKSIZE` – The stacksize to use when creating the
NX
- server. Default: `2048`.
-- `CONFIG_EXAMPLES_NXTERM_CLIENTPRIO` – The client priority. Default: `100`.
-- `CONFIG_EXAMPLES_NXTERM_SERVERPRIO` – The server priority. Default: `120`.
-- `CONFIG_EXAMPLES_NXTERM_LISTENERPRIO` – The priority of the event listener
- thread. Default: `80`.
-
-## `nxflat` NXFLAT Binary
-
-This example builds a small NXFLAT test case. This includes several test
-programs under `examples/nxflat` tests. These tests are build using the NXFLAT
-format and installed in a ROMFS file system. At run time, each program in the
-ROMFS file system is executed. Requires `CONFIG_NXFLAT`.
-
-## `nxhello`
-
-A very simple graphics example that just says _Hello, World!_ in the center of
-the display.
-
-The following configuration options can be selected:
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the `NXHELLO` example as a _built-in_ that
- can be executed from the NSH command line
-- `CONFIG_EXAMPLES_NXHELLO_VPLANE` – The plane to select from the frame- buffer
- driver for use in the test. Default: `0`.
-- `CONFIG_EXAMPLES_NXHELLO_DEVNO` – The LCD device to select from the LCD
driver
- for use in the test. Default: `0`.
-- `CONFIG_EXAMPLES_NXHELLO_BGCOLOR` – The color of the background. Default
- depends on `CONFIG_EXAMPLES_NXHELLO_BPP`.
-- `CONFIG_EXAMPLES_NXHELLO_FONTID` – Selects the font (see font ID numbers in
- include/nuttx/nx/nxfonts.h).
-- `CONFIG_EXAMPLES_NXHELLO_FONTCOLOR` – The color of the fonts used in the
- background window. Default depends on `CONFIG_EXAMPLES_NXHELLO_BPP`.
-- `CONFIG_EXAMPLES_NXHELLO_BPP` – Pixels per pixel to use. Valid options
include
- `2`, `4`, `8`, `16`, `24` and `32`. Default: `32`.
-
-## `nximage` Display NuttX Logo
-
-This is a simple example that just puts the NuttX logo image in the center of
-the display. This only works for `RGB23` (`888`), `RGB16` (`656`), `RGB8`
-(`332`), and 8-bit greyscale for now.
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the `NXIMAGE` example as a _built-in_ that
- can be executed from the NSH command line.
-- `CONFIG_EXAMPLES_NXIMAGE_VPLANE` – The plane to select from the frame- buffer
- driver for use in the test. Default: `0`.
-- `CONFIG_EXAMPLES_NXIMAGE_DEVNO` – The LCD device to select from the LCD
driver
- for use in the test: Default: `0`.
-- `CONFIG_EXAMPLES_NXIMAGE_BPP` – Pixels per pixel to use. Valid options
include
- `8`, `16` and `24`. Default is `16`.
-- `CONFIG_EXAMPLES_NXIMAGE_XSCALEp5`, `CONFIG_EXAMPLES_NXIMAGE_XSCALE1p5` or
- `CONFIG_EXAMPLES_NXIMAGE_XSCALE2p0` – The logo image width is 160 columns.
One
- of these may be defined to rescale the image horizontally by .5, 1.5 or 2.0.
-- `CONFIG_EXAMPLES_NXIMAGE_YSCALEp5`, `CONFIG_EXAMPLES_NXIMAGE_YSCALE1p5` or
- `CONFIG_EXAMPLES_NXIMAGE_YSCALE2p0` – The logo image height is 160 rows. One
- of these may be defined to rescale the image vertically by .5, 1.5 or 2.0.
-- `CONFIG_EXAMPLES_NXIMAGE_GREYSCALE` – Grey scale image. Default: `RGB`.
-
-How was that run-length encoded image produced?
-
-1. I used GIMP output the image as a `.c` file.
-2. I added some C logic to palette-ize the RGB image in the GIMP `.c` file.
-3. Then I add some simple run-length encoding to palette-ized image.
-
-But now there is a tool that can be found in the NxWidgets package at
-`NxWidgets/tools/bitmap_converter.py` that can be used to convert any graphics
-format to the NuttX RLE format.
-
-**Note**: As of this writing, most of the pixel depth, scaling options, and
-combinations thereof have not been tested.
-
-## `nxlines` NX Line Drawing
-
-A very simple graphics example that just exercised the NX line drawing logic.
-
-The following configuration options can be selected:
-
-- `CONFIG_EXAMPLES_NXLINES_VPLANE` – The plane to select from the frame- buffer
- driver for use in the test. Default: `0`.
-- `CONFIG_EXAMPLES_NXLINES_DEVNO` – The LCD device to select from the LCD
driver
- for use in the test: Default: `0`.
-- `CONFIG_EXAMPLES_NXLINES_BGCOLOR` – The color of the background. Default
- depends on `CONFIG_EXAMPLES_NXLINES_BPP`.
-- `CONFIG_EXAMPLES_NXLINES_LINEWIDTH` – Selects the width of the lines in
pixels
- (default: `16`).
-- `CONFIG_EXAMPLES_NXLINES_LINECOLOR` – The color of the central lines drawn in
- the background window. Default depends on `CONFIG_EXAMPLES_NXLINES_BPP`
(there
- really is no meaningful default).
-- `CONFIG_EXAMPLES_NXLINES_BORDERWIDTH` – The width of the circular border
drawn
- in the background window. (default: `16`).
-- `CONFIG_EXAMPLES_NXLINES_BORDERCOLOR` – The color of the circular border
drawn
- in the background window. Default depends on `CONFIG_EXAMPLES_NXLINES_BPP`
- (there really is no meaningful default).
-- `CONFIG_EXAMPLES_NXLINES_CIRCLECOLOR` – The color of the circular region
- filled in the background window. Default depends on
- `CONFIG_EXAMPLES_NXLINES_BPP` (there really is no meaningful default).
-- `CONFIG_EXAMPLES_NXLINES_BORDERCOLOR` – The color of the lines drawn in the
- background window. Default depends on `CONFIG_EXAMPLES_NXLINES_BPP` (there
- really is no meaningful default).
-- `CONFIG_EXAMPLES_NXLINES_BPP` – Pixels per pixel to use. Valid options
include
- `2`, `4`, `8`, `16`, `24`, and `32`. Default is `16`.
-- `CONFIG_NSH_BUILTIN_APPS` – Build the NX lines examples as an NSH built-in
- function.
-
-## `nxtext` Display NX Text
-
-This directory contains another simple test of a subset of the NX APIs defined
-in `include/nuttx/nx/nx.h`. This text focuses on text displays on the display
-background combined with pop-up displays over the text. The text display will
-continue to update while the pop-up is visible.
-
-**Note**: This example will **only** work with FB drivers and with LCD drivers
-that support reading the contents of the internal LCD memory **unless** you
-define `CONFIG_EXAMPLES_NXTEXT_NOGETRUN`. If you notice garbage on the display
-or a failure at the point where the display should scroll, it is probably
-because you have an LCD driver that is write-only.
-
-The following configuration options can be selected:
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the `NXTEXT` example as a _built-in_ that
- can be executed from the NSH command line.
-- `CONFIG_EXAMPLES_NXTEXT_BGCOLOR` – The color of the background. Default
- depends on `CONFIG_EXAMPLES_NXTEXT_BPP`.
-- `CONFIG_EXAMPLES_NXTEXT_BGFONTID` – Selects the font to use in the background
- text (see font ID numbers in `include/nuttx/nx/nxfonts.h`).
-- `CONFIG_EXAMPLES_NXTEXT_BGFONTCOLOR` – The color of the fonts used in the
- background window. Default depends on `CONFIG_EXAMPLES_NXTEXT_BPP`.
-- `CONFIG_EXAMPLES_NXTEXT_PUCOLOR` – The color of the pop-up window. Default
- depends on `CONFIG_EXAMPLES_NXTEXT_BPP`.
-- `CONFIG_EXAMPLES_NXTEXT_PUFONTID` – Selects the font to use in the pop-up
- windows (see font ID numbers in `include/nuttx/nx/nxfonts.h`).
-- `CONFIG_EXAMPLES_NXTEXT_PUFONTCOLOR` – The color of the fonts used in the
- background window. Default depends on `CONFIG_EXAMPLES_NXTEXT_BPP`.
-- `CONFIG_EXAMPLES_NXTEXT_BPP` – Pixels per pixel to use. Valid options include
- `2`, `4`, `8`, `16`, `24` and `32`. Default is `32`.
-- `CONFIG_EXAMPLES_NXTEXT_NOGETRUN` – If your display is read-only OR if
reading
- is not reliable, then select this configuration to avoid reading from the
- display.
-- `CONFIG_EXAMPLES_NXTEXT_BMCACHE` – The maximum number of characters that can
- be put in the background window. Default is `128`.
-- `CONFIG_EXAMPLES_NXTEXT_GLCACHE` – The maximum number of pre-rendered fonts
- that can be retained for the background window.
-- `CONFIG_EXAMPLES_NXTEXT_STACKSIZE` – The stacksize to use when creating the
NX
- server. Default `2048`.
-- `CONFIG_EXAMPLES_NXTEXT_CLIENTPRIO` – The client priority. Default: `100`.
-- `CONFIG_EXAMPLES_NXTEXT_SERVERPRIO` – The server priority. Default: `120`.
-- `CONFIG_EXAMPLES_NXTEXT_LISTENERPRIO` – The priority of the event listener
- thread. Default: `80`.
-- `CONFIG_EXAMPLES_NXTEXT_NOTIFYSIGNO` – The signal number to use with
- `nx_eventnotify()`. Default: `32`.
-
-The example also expects the following settings and will generate an error if
-they are not as expected:
-
-```conf
-CONFIG_DISABLE_MQUEUE=n
-CONFIG_DISABLE_PTHREAD=n
-CONFIG_NX_BLOCKING=y
-```
-
-## `null`
-
-This is the do nothing application. It is only used for bringing up new NuttX
-architectures in the most minimal of environments.
-
-## `obd2`
-
-A simple test of `apps/canutils/libobd2`.
-
-## `oneshot` Oneshot Timer
-
-Simple test of a oneshot driver.
-
-## `pca9635` `PCA9635PW` LED
-
-A simple test of the `PCA9635PW` LED driver.
-
-## `pdcurses`
-
-This directory contains the `demo/test` programs that accompany the public
-domain cursors package (`pdcurses`) that can be found at
-`apps/graphics/pdcurs34`.
-
-## `pipe`
-
-A test of the `mkfifo()` and `pipe()` APIs. Requires `CONFIG_PIPES`
-
-- `CONFIG_EXAMPLES_PIPE_STACKSIZE` – Sets the size of the stack to use when
- creating the child tasks. The default size is `1024`.
-
-## `poll`
-
-A test of the `poll()` and `select()` APIs using FIFOs and, if available,
-`stdin`, and a TCP/IP socket. In order to use the TCP/IP select test, you must
-have the following things selected in your NuttX configuration file:
-
-- `CONFIG_NET` – Defined for general network support.
-- `CONFIG_NET_TCP` – Defined for TCP/IP support.
-- `CONFIG_NET_NTCP_READAHEAD_BUFFERS` – Defined to be greater than zero.
-- `CONFIG_EXAMPLES_POLL_NOMAC` – (May be defined to use software
assigned
- MAC)
-- `CONFIG_EXAMPLES_POLL_IPADDR` – Target IP address.
-- `CONFIG_EXAMPLES_POLL_DRIPADDR` – Default router IP address.
-- `CONFIG_EXAMPLES_POLL_NETMASK` – Network mask.
-
-In order to for select to work with incoming connections, you must also select:
-
-- `CONFIG_NET_TCPBACKLOG` – Incoming connections pend in a backlog until
- `accept()` is called.
-
-In additional to the target device-side example, there is also a host-side
-application in this directory. It can be compiled under Linux or Cygwin as
-follows:
-
-```makefile
-cd examples/usbserial
-make -f Makefile.host TOPDIR=<nuttx-directory> TARGETIP=<target-ip>
-```
-
-Where `<target-ip>` is the IP address of your target board.
-
-This will generate a small program called 'host'. Usage:
-
-1. Build the `examples/poll` target program with TCP/IP poll support and start
- the target.
-
-2. Then start the host application:
-
- ```bash
- ./host
- ```
-
-The host and target will exchange are variety of small messages. Each message
-sent from the host should cause the select to return in target. The target
-example should read the small message and send it back to the host. The host
-should then receive the echo'ed message.
-
-If networking is enabled, applications using this example will need to provide
-the following definition in the `defconfig` file to enable the networking
-library:
-
-- `CONFIG_NETUTILS_NETLIB=y`
-
-## `posix_spawn`
-
-This is a simple test of the `posix_spawn()` API. The example derives from
-`examples/elf`. As a result, these tests are built using the relocatable ELF
-format installed in a ROMFS file system. At run time, the test program in the
-ROMFS file system is spawned using `posix_spawn()`.
-
-Requires:
-
-- `CONFIG_BINFMT_DISABLE=n` – Don't disable the binary loader.
-- `CONFIG_ELF=y` – Enable ELF binary loader.
-- `CONFIG_LIBC_EXECFUNCS=y` – Enable support for posix_spawn.
-- `CONFIG_EXECFUNCS_SYMTAB_ARRAY="g_spawn_exports"` – The name of the symbol
- table created by the test.
-- `CONFIG_EXECFUNCS_NSYMBOLS_VAR="g_spawn_nexports"` – Name of variable holding
- the number of symbols.
-- `CONFIG_POSIX_SPAWN_STACKSIZE=768` – This default setting.
-
-Test-specific configuration options:
-
-- `CONFIG_EXAMPLES_POSIXSPAWN_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_POSIXSPAWN_DEVPATH` – The path to the ROMFS block driver
- device. This must match `EXAMPLES_POSIXSPAWN_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:
-
- ```makefile
- 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).
-
- ```makefile
- 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:
-
- ```makefile
- LDELFFLAGS = -r -e main -T$(TOPDIR)/binfmt/libelf/gnu-elf.ld
- ```
-
-## `powerled`
-
-This is a powerled driver example application. This application support three
-operation modes which can be selected from NSH command line:
-
-1. Demo mode.
-2. Continuous mode.
-3. Flash mode.
-
-## `pty_test` Pseudo-Terminals
-
-A test of NuttX pseudo-terminals. Provided by Alan Carvalho de Assis.
-
-## `pwfb`
-
-A graphics example using pre-window frame buffers. The example shows three
-windows containing text moving around, crossing each other from _above_ and
from
-_below_. The example application is NOT updating the windows any anyway! The
-application is only changing the window position. The windows are being updated
-from the per-winidow framebuffers automatically.
-
-This example is reminiscent of Pong: Each window travels in straight line until
-it hits an edge, then it bounces off. The window is also raised when it hits
the
-edge (gets _focus_). This tests all combinations of overap.
-
-**Note**: A significant amount of RAM, usually external SDRAM, is required to
-run this demo. At 16bpp and a 480x272 display, each window requires about 70Kb
-of RAM for its framebuffer.
-
-## `pwm` General PWM
-
-A test of a PWM device driver. It simply enables a pulsed output for a
specified
-frequency and duty for a specified period of time. This example can ONLY be
-built as an NSH built-in function.
-
-This test depends on these specific PWM/NSH configurations settings (your
-specific PWM settings might require additional settings).
-
-- `CONFIG_PWM` – Enables PWM support.
-- `CONFIG_PWM_PULSECOUNT` – Enables PWM pulse count support (if the hardware
- supports it).
-- `CONFIG_NSH_BUILTIN_APPS` – Build the PWM test as an NSH built-in function.
-
-Specific configuration options for this example include:
-
-- `CONFIG_EXAMPLES_PWM_DEVPATH` – The path to the default PWM device. Default:
- `/dev/pwm0`.
-- `CONFIG_EXAMPLES_PWM_FREQUENCY` – The initial PWM frequency. Default: `100`
Hz
-- `CONFIG_EXAMPLES_PWM_DUTYPCT` – The initial PWM duty as a percentage.
Default:
- `50`%.
-- `CONFIG_EXAMPLES_PWM_DURATION` – The initial PWM pulse train duration in
- seconds. Used only if the current pulse count is zero (pulse count is only
- supported if `CONFIG_PWM_PULSECOUNT` is defined). Default: `5` seconds.
-- `CONFIG_EXAMPLES_PWM_PULSECOUNT` – The initial PWM pulse count. This option
is
- only available if `CONFIG_PWM_PULSECOUNT` is non-zero. Default: `0` (i.e.,
use
- the duration, not the count).
-
-## `qencoder` Quadrature Encoder
-
-This example is a simple test of a Quadrature Encoder driver. It simply reads
-positional data from the encoder and prints it.,
-
-This test depends on these specific QE/NSH configurations settings (your
-specific PWM settings might require additional settings).
-
-- `CONFIG_SENSORS_QENCODER` – Enables quadrature encoder support (upper-half
- driver).
-- `CONFIG_NSH_BUILTIN_APPS` – Build the QE test as an NSH built-in function.
- Default: Built as a standalone program.
-
-Additional configuration options will mostly likely be required for the board-
-specific lower-half driver. See the `README.txt` file in your board
-configuration directory.
-
-Specific configuration options for this example include:
-
-- `CONFIG_EXAMPLES_QENCODER_DEVPATH` – The path to the QE device. Default:
- `/dev/qe0`.
-- `CONFIG_EXAMPLES_QENCODER_NSAMPLES` – This number of samples is collected and
- the program terminates. Default: Samples are collected indefinitely.
-- `CONFIG_EXAMPLES_QENCODER_DELAY` – This value provides the delay (in
- milliseconds) between each sample. Default: `100` milliseconds.
-
-## `random` Random Numbers
-
-This is a very simply test of `/dev/random`. It simple collects random numbers
-and displays them on the console.
-
-Prerequistes:
-
-- `CONFIG_DEV_RANDOM` – Support for `/dev/random` must be enabled in order to
- select this example.
-
-Configuration:
-
-- `CONFIG_EXAMPLES_RANDOM` – Enables the `/dev/random` test.
-- `CONFIG_EXAMPLES_MAXSAMPLES` – This is the size of the `/dev/random` I/O
- buffer in units of 32-bit samples. Careful! This buffer is allocated on the
- stack as needed! Default `64`.
-- `CONFIG_EXAMPLES_NSAMPLES` – When you execute the `rand` command, a number of
- samples ranging from `1` to `EXAMPLES_MAXSAMPLES` may be specified. If no
- argument is specified, this is the default number of samples that will be
- collected and displayed. Default `8`.
-
-## `relays` Relays
-
-Requires `CONFIG_ARCH_RELAYS`. Contributed by Darcy Gong.
-
-**Note**: This test exercises internal relay driver interfaces. As such, it
-relies on internal OS interfaces that are not normally available to a
user-space
-program. As a result, this example cannot be used if a NuttX is built as a
-protected, supervisor kernel (`CONFIG_BUILD_PROTECTED` or
-`CONFIG_BUILD_KERNEL`).
-
-## `rfid_readuid` RFID
-
-RFID `READUID` example.
-
-## `rgbled` RGB LED Using PWM
-
-This example demonstrates the use of the RGB led driver to drive an RGB LED
with
-PWM outputs so that all color characteristcs of RGB LED can be controlled.
-
-## `romfs` File System
-
-This example exercises the romfs filesystem. Configuration options include:
-
-- `CONFIG_EXAMPLES_ROMFS_RAMDEVNO` – The minor device number to use for the ROM
- disk. The default is `1` (meaning `/dev/ram1`).
-- `CONFIG_EXAMPLES_ROMFS_SECTORSIZE` – The ROM disk sector size to use. Default
- is `64`.
-- `CONFIG_EXAMPLES_ROMFS_MOUNTPOINT` – The location to mount the ROM disk.
- Default: `/usr/local/share`.
-
-## `sendmail` SMTP Client
-
-This examples exercises the uIP SMTP logic by sending a test message to a
-selected recipient. This test can also be built to execute on the Cygwin/Linux
-host environment:
-
-```bash
-cd examples/sendmail
-make -f Makefile.host TOPDIR=<nuttx-directory>
-```
-
-Settings unique to this example include:
-
-- `CONFIG_EXAMPLES_SENDMAIL_NOMAC` – May be defined to use software
assigned
- MAC (optional)
-- `CONFIG_EXAMPLES_SENDMAIL_IPADDR` – Target IP address (required)
-- `CONFIG_EXAMPLES_SENDMAIL_DRIPADDR` – Default router IP address (required)
-- `CONFIG_EXAMPLES_SENDMAILT_NETMASK` – Network mask (required)
-- `CONFIG_EXAMPLES_SENDMAIL_RECIPIENT` – The recipient of the email (required)
-- `CONFIG_EXAMPLES_SENDMAIL_SENDER` – Optional. Default:
- `nuttx-test...@example.com`
-- `CONFIG_EXAMPLES_SENDMAIL_SUBJECT` – Optional. Default: `Testing SMTP from
- NuttX`
-- `CONFIG_EXAMPLES_SENDMAIL_BODY` – Optional. Default: `Test message sent
- by NuttX`
-
-**Note 1**: This test has not been verified on the NuttX target environment. As
-of this writing, unit-tested in the Cygwin/Linux host environment.
-
-**Note 2**: This sendmail example only works for the simplest of environments.
-Virus protection software on your host may have to be disabled to allow you to
-send messages. Only very open, unprotected recipients can be used. Most will
-protect themselves from this test email because it looks like SPAM.
-
-Applications using this example will need to enable the following netutils
-libraries in their defconfig file:
-
-```conf
-CONFIG_NETUTILS_NETLIB=y
-CONFIG_NETUTILS_SMTP=y
-```
-
-## `serialblaster`
-
-Sends a repeating pattern (the alphabet) out a serial port continuously. This
-may be useful if you are trying run down other problems that you think might
-only occur when the serial port usage is high.
-
-## `serialrx`
-
-Constant receives serial data. This is the complement to `serialblaster`. This
-may be useful if you are trying run down other problems that you think might
-only occur when the serial port usage is high.
-
-## `serloop` Serial Loopback
-
-This is a mindlessly simple loopback test on the console. Useful for testing
new
-serial drivers. Configuration options include:
-
-- `CONFIG_EXAMPLES_SERLOOP_BUFIO` – Use C buffered I/O (`getchar`/`putchar`)
vs.
- raw console I/O (read/read).
-
-## `slcd` Alphanumeric Segment LCD
-
-A simple test of alphanumeric, segment LCDs (SLCDs).
-
-- `CONFIG_EXAMPLES_SLCD` – Enable the SLCD test
-
-## `smps` Switched-Mode Power Supply
-
-This is a SMPS (Switched-mode power supply) driver example application.
-
-## `sotest` Shared Library Module Test
-
-This example builds a small shared library module test case. The test shared
-library is built using the relocatable ELF format and installed in a ROMFS file
-system. At run time, the shared library is installed and exercised. Requires
-`CONFIG_LIBC_DLFCN`. Other configuration options:
-
-- `CONFIG_EXAMPLES_SOTEST_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_SOTEST_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:
-
- ```makefile
- 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>`.
-
- ```makefile
- 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:
-
-```makefile
-LDMODULEFLAGS = -r -e module_initialize -T$(TOPDIR)/libc/modlib/gnu-elf.ld
-```
-
-## `stat`
-
-A simple test of `stat()`, `fstat()`, and `statfs()`. This is useful primarily
-for bringing up a new file system and verifying the correctness of these
-operations.
-
-## `sx127x_demo` `SX127X` Radio
-
-This example demonstrates the use of the `SX127X` radio.
-
-## `system`
-
-This is a simple test of the `system()` command. The test simply executes this
-`system` command:
-
-```c
-ret = system("ls -Rl /");
-```
-
-## `tcpblaster` TCP Performance Test
-
-The `tcpblaster` example derives from the `nettest` example and basically
-duplicates that example when the `nettest` PERFORMANCE option is selected.
-`tcpblaster` has a little better reporting of performance stats, however.
-
-## `tcpecho` TCP Echo Server
-
-Simple single threaded, poll based TCP echo server. This example implements the
-TCP Echo Server from W. Richard Stevens _UNIX Network Programming_ Book.
-Contributed by Max Holtberg.
-
-See also `examples/nettest`
-
-- `CONFIG_EXAMPLES_TCPECHO=y` – Enables the TCP echo server.
-- `CONFIG_XAMPLES_TCPECHO_PORT` – Server Port, default `80`.
-- `CONFIG_EXAMPLES_TCPECHO_BACKLOG` – Listen Backlog, default `8`.
-- `CONFIG_EXAMPLES_TCPECHO_NCONN` – Number of Connections, default `8`.
-- `CONFIG_EXAMPLES_TCPECHO_DHCPC` – DHCP Client, default `n`.
-- `CONFIG_EXAMPLES_TCPECHO_NOMAC` – Use Canned MAC Address, default `n`.
-- `CONFIG_EXAMPLES_TCPECHO_IPADDR` – Target IP address, default `0x0a000002`.
-- `CONFIG_EXAMPLES_TCPECHO_DRIPADDR` – Default Router IP address (Gateway),
- default `0x0a000001`.
-- `CONFIG_EXAMPLES_TCPECHO_NETMASK` – Network Mask, default `0xffffff00`.
-
-## `telnetd` Simple Telnet Shell
-
-This directory contains a functional port of the tiny uIP shell. In the NuttX
-environment, the NuttShell (at `apps/nshlib`) supersedes this tiny shell and
-also supports `telnetd`.
-
-- `CONFIG_EXAMPLES_TELNETD` – Enable the Telnetd example.
-- `CONFIG_NETUTILS_NETLIB`, `CONFIG_NETUTILS_TELNETD` – Enable netutils
libraries
- needed by the Telnetd example.
-- `CONFIG_EXAMPLES_TELNETD_DAEMONPRIO` – Priority of the Telnet daemon.
Default:
- `SCHED_PRIORITY_DEFAULT`.
-- `CONFIG_EXAMPLES_TELNETD_DAEMONSTACKSIZE` – Stack size allocated for the
- Telnet daemon. Default: `2048`.
-- `CONFIG_EXAMPLES_TELNETD_CLIENTPRIO` – Priority of the Telnet client.
Default:
- `SCHED_PRIORITY_DEFAULT`.
-- `CONFIG_EXAMPLES_TELNETD_CLIENTSTACKSIZE` – Stack size allocated for the
- Telnet client. Default: `2048`.
-- `CONFIG_EXAMPLES_TELNETD_NOMAC` – If the hardware has no MAC address of its
- own, define this `=y` to provide a bogus address for testing.
-- `CONFIG_EXAMPLES_TELNETD_IPADDR` – The target IP address. Default `10.0.0.2`.
-- `CONFIG_EXAMPLES_TELNETD_DRIPADDR` – The default router address. Default
- `10.0.0.1`.
-- `CONFIG_EXAMPLES_TELNETD_NETMASK` – The network mask. Default:
- `255.255.255.0`.
-
-Also, make sure that you have the following set in the NuttX configuration file
-or else the performance will be very bad (because there will be only one
-character per TCP transfer):
-
-- `CONFIG_STDIO_BUFFER_SIZE` – Some value `>= 64`
-- `CONFIG_STDIO_LINEBUFFER=y`
-
-## `termios` Simple Termios interface test
-
-This directory contains a simple application that uses the termios interface
-to change serial parameters. Just import a `nsh` config and enable the
-following symbols:
-
-- `CONFIG_SERIAL_TERMIOS` – Enable the termios support.
-- `CONFIG_EXAMPLES_TERMIOS` – Enable the example itself.
-
-## `thttpd` THTTPD server
-
-An example that builds `netutils/thttpd` with some simple NXFLAT CGI programs.
-See `boards/README.txt` for most THTTPD settings. In addition to those, this
-example accepts:
-
-- `CONFIG_EXAMPLES_THTTPD_NOMAC` – (May be defined to use software assigned
- MAC)
-- `CONFIG_EXAMPLES_THTTPD_DRIPADDR` – Default router IP address.
-- `CONFIG_EXAMPLES_THTTPD_NETMASK` – Network mask.
-
-Applications using this example will need to enable the following `netutils`
-libraries in the `defconfig` file:
-
-```conf
-CONFIG_NETUTILS_NETLIB=y
-CONFIG_NETUTILS_THTTPD=y
-```
-
-## `tiff`
-
-This is a simple unit test for the TIFF creation library at
`apps/graphic/tiff`.
-It is configured to work in the Linux user-mode simulation and has not been
-tested in any other environment.
-
-At a minimum, to run in an embedded environment, you will probably have to
-change the configured paths to the TIFF files defined in the example.
-
-- `CONFIG_EXAMPLES_TIFF_OUTFILE` – Name of the resulting TIFF file. Default is
- `/tmp/result.tif`.
-- `CONFIG_EXAMPLES_TIFF_TMPFILE1/2` – Names of two temporaries files that will
- be used in the file creation. Defaults are `/tmp/tmpfile1.dat` and
- `/tmp/tmpfile2.dat`.
-
-The following must also be defined in your `apps/` configuration file:
-
-```conf
-CONFIG_EXAMPLES_TIFF=y
-CONFIG_GRAPHICS_TIFF=y
-```
-
-## `timer`
-
-This is a simple test of the timer driver (see `include/nuttx/timers/timer.h`).
-
-Dependencies:
-
-- `CONFIG_TIMER` – The timer driver must be selected
-
-Example configuration:
-
-- `CONFIG_EXAMPLES_TIMER_DEVNAME` – This is the name of the timer device that
- will be tested. Default: `/dev/timer0`.
-- `CONFIG_EXAMPLES_TIMER_INTERVAL` – This is the timer interval in
microseconds.
- Default: `1000000`.
-- `CONFIG_EXAMPLES_TIMER_DELAY` – This is the delay between timer samples in
- microseconds. Default: `10000`.
-- `CONFIG_EXAMPLES_TIMER_STACKSIZE` – This is the stack size allocated when the
- timer task runs. Default: `2048`.
-- `CONFIG_EXAMPLES_TIMER_PRIORITY` – This is the priority of the timer task:
- Default: `100`.
-- `CONFIG_EXAMPLES_TIMER_PROGNAME` – This is the name of the program that will
- be used when the NSH ELF program is installed. Default: `timer`.
-
-## `timer_gpio`
-
-This example uses the timer interrupt to periodically change the state of a
-digital output. The digital output may be a relay, a led or anything else.
-This example can be very useful to validate timer drivers by using a logic
-analyzer connected to the digital output. This example mainly differs from
-the timer example because it waits on a sigwaitinfo() instead of using a
-signal handler. This approach ensures a deterministic wake-up time when the
-signal occurs.
-
-Dependencies:
-
-- `CONFIG_TIMER` – The timer driver must be selected.
-- `CONFIG_DEV_GPIO` – The GPIO driver must be selected.
-
-Note: You should also select one timer instance and have the gpio driver
-properly configured in your board logic.
-
-Example configuration:
-
-- `EXAMPLES_TIMER_GPIO_TIM_DEVNAME` – This is the name of the timer device
- that will be used.
- Default: `/dev/timer0`.
-- `EXAMPLES_TIMER_GPIO_GPIO_DEVNAME` – This is the name of the gpio device
- that will be used.
- Default: `/dev/gpio0`.
-- `EXAMPLES_TIMER_GPIO_INTERVAL` – This is the timer interval in
- microseconds.
- Default: `1000000`.
-- `EXAMPLES_TIMER_GPIO_SIGNO` – This is the signal number that is used to
- notify that a timer interrupt occurred.
- Default: `32`.
-- `EXAMPLES_TIMER_GPIO_STACKSIZE` – This is the stack size allocated when the
- timer task runs.
- Default: `2048`.
-- `EXAMPLES_TIMER_GPIO_PRIORITY` – This is the priority of the timer task.
- Default: `255`.
-- `EXAMPLES_TIMER_GPIO_PROGNAME` – This is the name of the program that will
- be used from the nsh.
- Default: `timer_gpio`.
-
-## `touchscreen` Touchscreen Events
-
-This configuration implements a simple touchscreen test at
-`apps/examples/touchscreen`. This test will create an empty X11 window and will
-print the touchscreen output as it is received from the simulated touchscreen
-driver.
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the touchscreen test as an NSH built-in
- function. Default: Built as a standalone program.
-- `CONFIG_EXAMPLES_TOUCHSCREEN_MINOR` – The minor device number. Minor `N`
- corresponds to touchscreen device `/dev/inputN`. Note this value must with
- `CONFIG_EXAMPLES_TOUCHSCREEN_DEVPATH`. Default `0`.
-- `CONFIG_EXAMPLES_TOUCHSCREEN_DEVPATH` – The path to the touchscreen device.
- This must be consistent with `CONFIG_EXAMPLES_TOUCHSCREEN_MINOR`. Default:
- `/dev/input0`.
-- `CONFIG_EXAMPLES_TOUCHSCREEN_NSAMPLES` – This number of samples is collected
- and the program terminates. Default: Samples are collected indefinitely.
-- `CONFIG_EXAMPLES_TOUCHSCREEN_MOUSE` – The touchscreen test can also be
- configured to work with a mouse driver by setting this option.
-
-The following additional configurations must be set in the NuttX configuration
-file:
-
-- `CONFIG_INPUT=y` (plus any touchscreen-specific settings)
-
-The following must also be defined in your apps configuration file:
-
-- `CONFIG_EXAMPLES_TOUCHSREEN=y`
-
-This example code will call `boardctl()` to setup the touchscreen driver for
-texting. The implementation of `boardctl()` will require that board- specific
-logic provide the following interfaces that will be called by the `boardctl()`
-in order to initialize the touchscreen hardware:
-
-```c
-int board_tsc_setup(int minor);
-```
-
-## `udp` Client/Server Over UDP
-
-This is a simple network test for verifying client- and server- functionality
-over UDP.
-
-Applications using this example will need to enabled the following `netutils`
-libraries in the `defconfig` file:
-
-- `CONFIG_NETUTILS_NETLIB=y`
-
-Possible configurations:
-
-- Server on target hardware; client on host.
-- Client on target hardware; Server on host.
-- Server and Client on different targets.
-
-## `udpblaster`
-
-This is a simple network test for stressing UDP transfers. It simply sends UDP
-packets from both the host and the target and the highest possible rate.
-
-## `unionfs` Union File System
-
-This is at trivial test of the Union File System. See
-`nuttx/fs/unionfs/README.txt`. Dependencies:
-
-- `CONFIG_DISABLE_MOUNTPOINT` – Mountpoint support must not be
- disabled.
-- `CONFIG_FS_ROMFS` – ROMFS support is required.
-- `CONFIG_FS_UNIONFS` – Union File System support is required.
-
-Configuration options. Use the defaults if you are unsure of what you are
doing:
-
-- `CONFIG_EXAMPLES_UNIONFS` – Enables the example.
-- `CONFIG_EXAMPLES_UNIONFS_MOUNTPT` – Mountpoint path for the Union File
- System.
-- `CONFIG_EXAMPLES_UNIONFS_TMPA` – Temporary mount point for file system
- `1`.
-- `CONFIG_EXAMPLES_UNIONFS_TMPB` – Temporary mount point for file system
- `2`.
-- `CONFIG_EXAMPLES_UNIONFS_RAMDEVNO_A` – ROMFS file system `1` RAM disk device
- number.
-- `CONFIG_EXAMPLES_UNIONFS_RAMDEVNO_B` – ROMFS file system `2` RAM disk device
- number.
-- `CONFIG_EXAMPLES_UNIONFS_SECTORSIZE` – ROM disk sector size.
-
-See the `README.txt` file at `nuttx/boards/sim/sim/sim/README.txt` for a
-walk-through of the output of this text.
-
-## `usbserial` USB Serial Hello World
-
-### Target configuration
-
-This is another implementation of _Hello, World_ but this one uses a USB serial
-driver. Configuration options can be used to simply the test. These options
-include:
-
-- `CONFIG_EXAMPLES_USBSERIAL_INONLY` – Only verify IN (device-to-host) data
- transfers. Default: both.
-- `CONFIG_EXAMPLES_USBSERIAL_OUTONLY` – Only verify OUT (host-to-device) data
- transfers. Default: both.
-- `CONFIG_EXAMPLES_USBSERIAL_ONLYSMALL` – Send only small, single packet
- messages. Default: Send large and small.
-- `CONFIG_EXAMPLES_USBSERIAL_ONLYBIG` – Send only large, multi-packet
messages.
- Default: Send large and small.
-
-If `CONFIG_USBDEV_TRACE` is enabled (or `CONFIG_DEBUG_FEATURES` and
-`CONFIG_DEBUG_USB`), then the example code will also manage the USB trace
-output. The amount of trace output can be controlled using:
-
-- `CONFIG_EXAMPLES_USBSERIAL_TRACEINIT` – Show initialization events.
-- `CONFIG_EXAMPLES_USBSERIAL_TRACECLASS` – Show class driver events.
-- `CONFIG_EXAMPLES_USBSERIAL_TRACETRANSFERS` – Show data transfer events.
-- `CONFIG_EXAMPLES_USBSERIAL_TRACECONTROLLER` – Show controller events.
-- `CONFIG_EXAMPLES_USBSERIAL_TRACEINTERRUPTS` – Show interrupt-related events.
-
-Error results are always shown in the trace output.
-
-### Host-side test program
-
-In additional to the target device-side example, there is also a host-side
-application in this directory. This host side application must be executed on a
-Linux host in order to perform the `USBSERIAL` test. The host application can
be
-compiled under Linux (or Cygwin?) as follows:
-
-```bash
-cd examples/usbserial
-make -f Makefile.host TOPDIR=<nuttx-directory>
-```
-
-### Running the test
-
-This will generate a small program called `host`. Usage:
-
-1. Build the `examples/usbserial` target program and start the target.
-
-2. Wait a bit, then do enter:
-
- ```shell
- dmesg
- ```
-
- At the end of the dmesg output, you should see the serial device was
- successfully idenfied and assigned to a tty device, probably `/dev/ttyUSB0`
- or `/dev/ttyACM0` (depending on the configured USB serial driver).
-
-3. Then start the host application:
-
- ```bash
- ./host [<tty-dev>]
- ```
-
- Where:
-
- - `<tty-dev>` is the USB TTY device to use. The default is `/dev/ttyUSB0`
- (for the PL2303 emulation) or `/dev/ttyACM0` (for the CDC/ACM serial
- device).
-
-The host and target will exchange are variety of very small and very large
-serial messages.
-
-## `userfs` UserFS File System
-
-A simple test of the UserFS file system.
-
-## `ustream` Unix Datagram Sockets
-
-This is the same test as `examples/udp` and similar to `examples/ustream`, but
-using Unix domain datagram sockets.
-
-Dependencies:
-
-- `CONFIG_NET_LOCAL` – Depends on support for Unix domain sockets.
-
-Configuration:
-
-- `CONFIG_EXAMPLES_UDGRAM` – Enables the Unix domain socket example.
-- `CONFIG_EXAMPLES_UDGRAM_ADDR` – Specifics the Unix domain address. Default:
- `/dev/fifo`.
-
-## `ustream` Unix Stream Sockets
-
-This is the same test as `examples/udp` and similar to `examples/udgram`, but
-using Unix domain stream sockets.
-
-Dependencies:
-
-- `CONFIG_NET_LOCAL` – Depends on support for Unix domain sockets.
-
-Configuration:
-
-- `CONFIG_EXAMPLES_USTREAM` – Enables the Unix domain socket example.
-- `CONFIG_EXAMPLES_USTREAM_ADDR` – Specifics the Unix domain address. Default:
- `/dev/fifo`.
-
-## `watchdog` Watchdog Timer
-
-A simple test of a watchdog timer driver. Initializes starts the watchdog
timer.
-It pings the watchdog timer for a period of time then lets the watchdog timer
-expire... resetting the CPU is successful. This example can ONLY be built as an
-NSH built-in function.
-
-This test depends on these specific Watchdog/NSH configurations settings (your
-specific watchdog hardware settings might require additional settings).
-
-- `CONFIG_WATCHDOG` – Enables watchdog timer support support.
-- `CONFIG_NSH_BUILTIN_APPS` – Build the watchdog time test as an NSH built-in
- function.
-
-Specific configuration options for this example include:
-
-- `CONFIG_EXAMPLES_WATCHDOG_DEVPATH` – The path to the Watchdog device.
Default:
- `/dev/watchdog0`.
-- `CONFIG_EXAMPLES_WATCHDOG_PINGTIME` – Time in milliseconds that the example
- will ping the watchdog before letting the watchdog expire. Default: `5000`
- milliseconds.
-- `CONFIG_EXAMPLES_WATCHDOG_PINGDELAY` – Time delay between pings in
- milliseconds. Default: `500` milliseconds.
-- `CONFIG_EXAMPLES_WATCHDOG_TIMEOUT` – The watchdog timeout value in
- milliseconds before the watchdog timer expires. Default: `2000` milliseconds.
-
-## `watcher` Watcher & Watched
-
-The watcher and watched examples are designed to work together. The watched
-example will only appear after watcher is selected.
-The watcher is a task that will monitor other tasks that subscribe to be
watched.
-If a watched task doesn't signal the watcher during the watchdog time period,
-the watchdog timer will expire and the watcher will print the tasks that did
-not signal and the ones that signaled. The tasks that did not signal will be
printed
-as the tasks that starved the dog and the tasks that signaled will be printed
as
-the tasks that fed the dog.
-The watcher task will only feed the watchdog timer when all subscribed tasks
have
-asked to feed dog.
-
-To start the watcher, just run:
-
-`watcher`
-
-The watched example is not required to use the watcher. The watched example is
simply
-a task that creates 4 tasks that will subscribe to be watched. The first and
fourth
-will not feed the dog to expose the functionality. This example will show the
user
-how to subscribe, to feed the dog and to unsubscribe.
-
-To start the watched, just run:
-
-`watched`
-
-P.S: This example will only be supported by the chips that support interrupt on
-timeout, i.e., which have the \"capture\" command implemented.
-
-This test depends on these specific configurations settings (your
-specific watchdog hardware settings might require additional settings).
-
-- `CONFIG_EXAMPLES_WATCHER` – Includes this example.
-- `CONFIG_WATCHDOG` – Enables watchdog timer support.
-- `CONFIG_NSH_BUILTIN_APPS` – Build this example an NSH built-in
- function.
-- `CONFIG_DRIVERS_NOTE` and `CONFIG_SCHED_INSTRUMENTATION` – Allows the watcher
- to get the tasks' names.
-- `CONFIG_FS_FAT` – Allows the creation of a FAT filesystem on the ramdisk
- to create a file with all the necessary info for the watched tasks.
-
-Specific configuration options for the `watcher` example include:
-
-- `CONFIG_EXAMPLES_WATCHER_PRIORITY` – Watcher Task Priority.
-- `CONFIG_EXAMPLES_WATCHER_STACKSIZE` – Watcher Task Stack Size.
-- `CONFIG_EXAMPLES_WATCHER_DEVPATH` – The path to the Watchdog device used by
- the Watcher. Default: `/dev/watchdog0`.
-- `CONFIG_EXAMPLES_WATCHER_TIMEOUT` – The watchdog timeout value in
- milliseconds.
-- `CONFIG_EXAMPLES_WATCHER_SIGNAL` – This is the Signal Number used for
- communication between the watcher task and the watched tasks.
-
-Specific configuration options for the `watched` example include:
-
-- `CONFIG_EXAMPLES_WATCHED_PRIORITY` – Watched Task Priority.
-- `CONFIG_EXAMPLES_WATCHED_STACKSIZE` – Watched Task Stack Size.
-
-## `webserver` Simple Webserver
-
-This is a port of uIP tiny webserver example application. Settings specific to
-this example include:
-
-- `CONFIG_EXAMPLES_WEBSERVER_NOMAC` (may be defined to use software assigned
- MAC)
-- `CONFIG_EXAMPLES_WEBSERVER_IPADDR` – Target IP address.
-- `CONFIG_EXAMPLES_WEBSERVER_DRIPADDR` – Default router IP address.
-- `CONFIG_EXAMPLES_WEBSERVER_NETMASK` – Network mask.
-- `CONFIG_EXAMPLES_WEBSERVER_DHCPC` – Select to get IP address via DHCP.
-
-If you use DHCPC, then some special configuration network options are required.
-These include:
-
-- `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_NET_ETH_PKTSIZE=650` or larger. Per RFC2131 (p. 9), the DHCP client
- must be prepared to receive DHCP messages of up to `576` bytes (excluding
- Ethernet, IP, or UDP headers and FCS). **Note** that the actual MTU setting
- will depend upon the specific link protocol. Here Ethernet is indicated.
-
-Other configuration items apply also to the selected `webserver` net utility.
-Additional relevant settings for the uIP `webserver` net utility are:
-
-- `CONFIG_NETUTILS_HTTPDSTACKSIZE`
-- `CONFIG_NETUTILS_HTTPDFILESTATS`
-- `CONFIG_NETUTILS_HTTPDNETSTATS`
-
-Applications using this example will need to enable the following `netutils`
-libraries in their `defconfig` file:
-
-```conf
-CONFIG_NETUTILS_NETLIB=y
-CONFIG_NETUTILS_DHCPC=y
-CONFIG_NETDB_DNSCLIENT=y
-CONFIG_NETUTILS_WEBSERVER=y
-```
-
-**Note**: This example does depend on the `perl` script at
-`nuttx/tools/mkfsdata.pl`. You must have `perl` installed on your development
-system at `/usr/bin/perl`.
-
-## `wget` Web Client
-
-A simple web client example. It will obtain a file from a server using the HTTP
-protocol. Settings unique to this example include:
-
-- `CONFIG_EXAMPLES_WGET_URL` – The URL of the file to get
-- `CONFIG_EXAMPLES_WGET_NOMAC` – (May be defined to use software assigned MAC)
-- `CONFIG_EXAMPLES_WGET_IPADDR` – Target IP address
-- `CONFIG_EXAMPLES_WGET_DRIPADDR` – Default router IP address
-- `CONFIG_EXAMPLES_WGET_NETMASK` – Network mask
-
-This example uses `netutils/webclient`. Additional configuration settings apply
-to that code as follows (but built-in defaults are probably OK):
-
-- `CONFIG_WEBCLIENT_GETMIMETYPE`
-- `CONFIG_WEBCLIENT_MAXHTTPLINE`
-- `CONFIG_WEBCLIENT_MAXMIMESIZE`
-- `CONFIG_WEBCLIENT_MAXHOSTNAME`
-- `CONFIG_WEBCLIENT_MAXFILENAME`
-
-Of course, the example also requires other settings including `CONFIG_NET` and
-`CONFIG_NET_TCP`. The example also uses the uIP resolver which requires
-`CONFIG_UDP`.
-
-**Warning**: As of this writing, `wget` is untested on the target platform. At
-present it has been tested only in the host-based configuration described in
the
-following note. The primary difference is that the target version will rely on
-the also untested uIP name resolver.
-
-**Note**: For test purposes, this example can be built as a host-based `wget`
-function. This can be built as follows:
-
-```bash
-cd examples/wget
-make -f Makefile.host
-```
-
-Applications using this example will need to enable the following `netutils`
-libraries in the `defconfig` file:
-
-```conf
-CONFIG_NETUTILS_NETLIB=y
-CONFIG_NETDB_DNSCLIENT=y
-CONFIG_NETUTILS_WEBCLIENT=y
-```
-
-## `wgetjson` GET JSON Using `wget`
-
-Uses `wget` to get a JSON encoded file, then decodes the file.
-
-- `CONFIG_EXAMPLES_WDGETJSON_MAXSIZE` – Max. JSON Buffer Size.
-- `CONFIG_EXAMPLES_EXAMPLES_WGETJSON_URL` – `wget` URL
-
-## `xmlrpc` XML-RPC Server
-
-This example exercises the _Embeddable Lightweight XML-RPC Server_ which is
-discussed at:
-
-http://www.drdobbs.com/web-development/an-embeddable-lightweight-xml-rpc-server/184405364
-
-Configuration options:
-
-- `CONFIG_EXAMPLES_XMLRPC_BUFFERSIZE` – HTTP buffer size. Default `1024`
-- `CONFIG_EXAMPLES_XMLRPC_DHCPC` – Use DHCP Client. Default `n`. Ignored if
- `CONFIG_NSH_NETINIT` is selected.
-- `CONFIG_EXAMPLES_XMLRPC_NOMAC` – Use Canned MAC Address. Default `n`. Ignored
- if `CONFIG_NSH_NETINIT` is selected.
-- `CONFIG_EXAMPLES_XMLRPC_IPADDR` – Target IP address. Default `0x0a000002`.
- Ignored if `CONFIG_NSH_NETINIT` is selected.
-- `CONFIG_EXAMPLES_XMLRPC_DRIPADDR` – Default Router IP address (Gateway).
- Default `0x0a000001`. Ignored if `CONFIG_NSH_NETINIT` is selected.
-- `CONFIG_EXAMPLES_XMLRPC_NETMASK` – Network Mask. Default `0xffffff00`.
Ignored
- if `CONFIG_NSH_NETINIT` is selected.
-
-## `zerocross` Zero Crossing Device
-
-A simple test of the Zero Crossing device driver.
diff --git a/examples/bastest/README.md b/examples/bastest/testcases.md
similarity index 90%
rename from examples/bastest/README.md
rename to examples/bastest/testcases.md
index b4c0bafb0..3e3875714 100644
--- a/examples/bastest/README.md
+++ b/examples/bastest/testcases.md
@@ -1,49 +1,3 @@
-# Examples / `bastest` Bas BASIC Tests
-
-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.
-
-## Background
-
-Bas is an interpreter for the classic dialect of the programming language
BASIC.
-It is pretty compatible to typical BASIC interpreters of the 1980s, unlike some
-other UNIX BASIC interpreters, that implement a different syntax, breaking
-compatibility to existing programs. Bas offers many ANSI BASIC statements for
-structured programming, such as procedures, local variables and various loop
-types. Further there are matrix operations, automatic LIST indentation and many
-statements and functions found in specific classic dialects. Line numbers are
-not required.
-
-The interpreter tokenises the source and resolves references to variables and
-jump targets before running the program. This compilation pass increases
-efficiency and catches syntax errors, type errors and references to variables
-that are never initialised. Bas is written in ANSI C for UNIX systems.
-
-## License
-
-BAS `2.4` is released as part of NuttX under the standard 3-clause BSD license
-use by all components of NuttX. This is not incompatible with the original BAS
-`2.4` licensing
-
-Copyright (c) 1999-2014 Michael Haardt
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of
-this software and associated documentation files (the "Software"), to deal in
-the Software without restriction, including without limitation the rights to
-use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of
-the Software, and to permit persons to whom the Software is furnished to do so,
-subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS
-FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
-COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
-IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
# Test Overview
## `test01.bas`
diff --git a/examples/camera/README.md b/examples/camera/README.md
deleted file mode 100644
index 3c6750311..000000000
--- a/examples/camera/README.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# Examples / `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
-```
diff --git a/examples/flash_test/README.md b/examples/flash_test/README.md
deleted file mode 100644
index 9fb2fdf3f..000000000
--- a/examples/flash_test/README.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Examples / `flash_test` SMART Flash Device Test
-
-```
-Author: Ken Pettit
- Date: April 24, 2013
-```
-
-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
-```
diff --git a/examples/flowc/README.md b/examples/flowc/README.md
deleted file mode 100644
index 6f3d23280..000000000
--- a/examples/flowc/README.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Examples / `flowc`
-
-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:
-
-```bash
-$ stty -F /dev/ttyACM0 crtscts
-$ cat testdata.dat >/dev/ttyACM0
-```
-
-where you need to replace `/dev/ttyACM0` with your selected serial device.
diff --git a/examples/foc/README.md b/examples/foc/README.md
deleted file mode 100644
index a3489bb2c..000000000
--- a/examples/foc/README.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# FOC 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
-
-* Odrive D6374 150KV
- p = 7
- Rs = 0.0254 Ohm
- Ls = 8.73 uH
- i\_max = ?
- v\_max = ?
-
- Example configuration for f\_PWM = 20kHz, f\_notifier = 10kHz, ccb=1000:
- Kp = 0.0087
- Ki = 0.0025
-
-* Linix 45ZWN24-40 (PMSM motor dedicated for NXP FRDM-MC-LVMTR kit)
- p = 2
- Rs = 0.5 Ohm
- Ls = 0.400 mH
- i\_max = 2.34 A
- v\_max = 24 V
-
- Example configuration for f\_PWM = 10kHz, f\_notifier = 5kHz, ccb=1000:
- Kp = 0.4
- Ki = 0.1
-
-* Bull-Running BR2804-1700 kV (motor provided with the ST P-NUCLEO-IHM07 kit)
- p = 7
- Rs = 0.11 Ohm
- Ls = 0.018 mH
- i\_max = 1.2A
- v\_max = 12V
-
- Example configuration for f\_PWM = 20kHz, f\_notifier = 10kHz, ccb=200:
- Kp = 0.036
- Ki = 0.022
-
-* iPower GBM2804H-100T (gimbal motor provided with the ST P-NUCLEO-IHM03 kit)
- p = 7
- Rs = 5.29 Ohm
- Ls = 1.05 mH
- i\_max = 0.15A
- v\_max = 12V
-
- Example configuration for f\_PWM = 10kHz, f\_notifier = 5kHz, ccb=TODO:
- Kp = TODO
- Ki = TODO
diff --git a/examples/json/README.md b/examples/json/README.md
deleted file mode 100644
index 047b6c150..000000000
--- a/examples/json/README.md
+++ /dev/null
@@ -1,298 +0,0 @@
-# Examples / `json` cJSON JSON Parser
-
-This directory contains logic taken from the cJSON project:
-
-http://sourceforge.net/projects/cjson/
-
-This 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.
-
-# Contents
-
-- License
-- Welcome to cJSON
-
-# License
-
-Copyright (c) 2009 Dave Gamble
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of
-this software and associated documentation files (the "Software"), to deal in
-the Software without restriction, including without limitation the rights to
-use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of
-the Software, and to permit persons to whom the Software is furnished to do so,
-subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS
-FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
-COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
-IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-# Welcome to cJSON
-
-cJSON aims to be the dumbest possible parser that you can get your job done
-with. It's a single file of C, and a single header file.
-
-JSON is described best here: http://www.json.org/ It's like XML, but fat-free.
-You use it to move data around, store things, or just generally represent your
-program's state.
-
-First up, how do I build? Add `cJSON.c` to your project, and put `cJSON.h`
-somewhere in the header search path. For example, to build the test app:
-
-```bash
-gcc cJSON.c test.c -o test -lm
-./test
-```
-
-As a library, cJSON exists to take away as much legwork as it can, but not get
-in your way. As a point of pragmatism (i.e. ignoring the truth), I'm going to
-say that you can use it in one of two modes: Auto and Manual. Let's have a
quick
-run-through.
-
-I lifted some JSON from this page: http://www.json.org/fatfree.html That page
-inspired me to write cJSON, which is a parser that tries to share the same
-philosophy as JSON itself. Simple, dumb, out of the way.
-
-Some JSON:
-
-```json
-{
- "name": "Jack (\"Bee\") Nimble",
- "format": {
- "type": "rect",
- "width": 1920,
- "height": 1080,
- "interlace": false,
- "frame rate": 24
- }
-}
-```
-
-Assume that you got this from a file, a webserver, or magic JSON elves,
-whatever, you have a `char *` to it. Everything is a cJSON struct.
-
-Get it parsed:
-
-```c
-cJSON *root = cJSON_Parse(my_json_string);
-```
-
-This is an object. We're in C. We don't have objects. But we do have structs.
-
-What's the framerate?
-
-```c
-cJSON *format = cJSON_GetObjectItem(root,"format");
-int framerate = cJSON_GetObjectItem(format,"frame rate")->valueint;
-```
-
-Want to change the framerate?
-
-```c
-cJSON_GetObjectItem(format,"frame rate")->valueint = 25;
-```
-
-Back to disk?
-
-```c
-char *rendered = cJSON_Print(root);
-```
-
-Finished? Delete the root (this takes care of everything else).
-
-```c
-cJSON_Delete(root);
-```
-
-That's AUTO mode. If you're going to use Auto mode, you really ought to check
-pointers before you dereference them. If you want to see how you'd build this
-struct in code?
-
-```c
-cJSON *root,*fmt;
-root = cJSON_CreateObject();
-
-cJSON_AddItemToObject(root, "name", cJSON_CreateString("Jack (\"Bee\")
Nimble"));
-cJSON_AddItemToObject(root, "format", fmt = cJSON_CreateObject());
-cJSON_AddStringToObject(fmt,"type", "rect");
-cJSON_AddNumberToObject(fmt,"width", 1920);
-cJSON_AddNumberToObject(fmt,"height", 1080);
-cJSON_AddFalseToObject (fmt,"interlace");
-cJSON_AddNumberToObject(fmt,"frame rate", 24);
-```
-
-Hopefully we can agree that's not a lot of code? There's no overhead, no
-unnecessary setup. Look at test.c for a bunch of nice examples, mostly all
-ripped off the json.org site, and a few from elsewhere.
-
-What about manual mode? First up you need some detail.
-Let's cover how the cJSON objects represent the JSON data.
-cJSON doesn't distinguish arrays from objects in handling; just type.
-Each cJSON has, potentially, a child, siblings, value, a name.
-
-The root object has: Object Type and a Child
-The Child has name "name", with value "Jack ("Bee") Nimble", and a sibling:
-Sibling has type Object, name "format", and a child.
-That child has type String, name "type", value "rect", and a sibling:
-Sibling has type Number, name "width", value 1920, and a sibling:
-Sibling has type Number, name "height", value 1080, and a sibling:
-Sibling hs type False, name "interlace", and a sibling:
-Sibling has type Number, name "frame rate", value 24
-
-Here's the structure:
-
-```c
-typedef struct cJSON {
- struct cJSON *next,*prev;
- struct cJSON *child;
-
- int type;
-
- char *valuestring;
- int valueint;
- double valuedouble;
-
- char *string;
-} cJSON;
-```
-
-By default all values are 0 unless set by virtue of being meaningful.
-
-next/prev is a doubly linked list of siblings. next takes you to your sibling,
-prev takes you back from your sibling to you. Only objects and arrays have a
-"child", and it's the head of the doubly linked list. A "child" entry will have
-`prev==0`, but next potentially points on. The last sibling has `next=0`. The
-type expresses Null/True/False/Number/String/Array/Object, all of which are
-`#define`d in `cJSON.h`.
-
-A Number has `valueint` and `valuedouble`. If you're expecting an `int`, read
-`valueint`, if not read `valuedouble`.
-
-Any entry which is in the linked list which is the child of an object will have
-a "string" which is the "name" of the entry. When I said "name" in the above
-example, that's "string". "string" is the JSON name for the 'variable name' if
-you will.
-
-Now you can trivially walk the lists, recursively, and parse as you please. You
-can invoke `cJSON_Parse` to get cJSON to parse for you, and then you can take
-the root object, and traverse the structure (which is, formally, an N-tree),
and
-tokenise as you please. If you wanted to build a callback style parser, this is
-how you'd do it (just an example, since these things are very specific):
-
-```c
-void parse_and_callback(cJSON *item, const char *prefix)
-{
- while (item)
- {
- size_t len = strlen(prefix) + strlen(item->name) + 2;
- char *newprefix = malloc(len);
- snprintf(newprefix, len, "%s/%s", prefix, item->name);
- int dorecurse = callback(newprefix, item->type, item);
- if (item->child && dorecurse) parse_and_callback(item->child,
newprefix);
- item = item->next;
- free(newprefix);
- }
-}
-```
-
-The prefix process will build you a separated list, to simplify your callback
-handling. The `dorecurse` flag would let the callback decide to handle
-sub-arrays on it's own, or let you invoke it per-item. For the item above, your
-callback might look like this:
-
-```c
-int callback(const char *name,int type, cJSON *item)
-{
- if (!strcmp(name,"name")) { /* populate name */ }
- else if (!strcmp(name,"format/type") { /* handle "rect" */ }
- else if (!strcmp(name,"format/width") { /* 800 */ }
- else if (!strcmp(name,"format/height") { /* 600 */ }
- else if (!strcmp(name,"format/interlace") { /* false */ }
- else if (!strcmp(name,"format/frame rate") { /* 24 */ }
- return 1;
-}
-```
-
-Alternatively, you might like to parse iteratively.
-
-You'd use:
-
-```c
-void parse_object(cJSON *item)
-{
- int i; for (i=0; i < cJSON_GetArraySize(item); i++)
- {
- cJSON *subitem = cJSON_GetArrayItem(item, i);
- // handle subitem.
- }
-}
-```
-
-Or, for PROPER manual mode:
-
-```c
-void parse_object(cJSON *item)
-{
- cJSON *subitem = item->child;
-
- while (subitem)
- {
- // handle subitem
- if (subitem->child) parse_object(subitem->child);
-
- subitem = subitem->next;
- }
-}
-```
-
-Of course, this should look familiar, since this is just a stripped-down
version
-of the callback-parser.
-
-This should cover most uses you'll find for parsing. The rest should be
possible
-to infer.. and if in doubt, read the source! There's not a lot of it! ;)
-
-In terms of constructing JSON data, the example code above is the right way to
-do it. You can, of course, hand your sub-objects to other functions to
populate.
-Also, if you find a use for it, you can manually build the objects. For
-instance, suppose you wanted to build an array of objects?
-
-```c
-cJSON *objects[24];
-
-cJSON *Create_array_of_anything(cJSON **items,int num)
-{
- int i;cJSON *prev, *root=cJSON_CreateArray();
- for (i=0;i<24;i++)
- {
- if (!i) root->child=objects[i];
- else prev->next=objects[i], objects[i]->prev=prev;
- prev=objects[i];
- }
- return root;
-}
-```
-
-and simply: `Create_array_of_anything(objects,24)`;
-
-cJSON doesn't make any assumptions about what order you create things in. You
-can attach the objects, as above, and later add children to each of those
-objects.
-
-As soon as you call `cJSON_Print`, it renders the structure to text.
-
-The test.c code shows how to handle a bunch of typical cases. If you uncomment
-the code, it'll load, parse and print a bunch of test files, also from
json.org,
-which are more complex than I'd care to try and stash into a `const char
-array[]`.
-
-Enjoy cJSON!
-
-_Dave Gamble, Aug 2009_
diff --git a/examples/mcuboot/swap_test/README.md
b/examples/mcuboot/swap_test/README.md
deleted file mode 100644
index b78a3cd9f..000000000
--- a/examples/mcuboot/swap_test/README.md
+++ /dev/null
@@ -1,138 +0,0 @@
-# Examples / MCUboot / `swap_test`
-
-## Description
-
-MCUboot Swap Image is an application to demostrate firmware upgrade using
-internal flash memory. It simulate MCUboot API steps to switch between two
-valid images.
-
-This application add 3 Builtin Apps to NuttX NSH: version, set_img and confirm.
-After application is build and `nuttx.bin` be generated, the binary must be
-signed. Consult your board README file to get instructions how to do it.
-
-## How to build and flash
-
-First step is build your board configuraton using `mcuboot-loader` as target.
-That create the bootloader itself. The `nuttx.bin` must be flash as usual.
-
-After that, clean up environment and set `mcuboot-swap-test` as target. The
-build output will generate the `nuttx.bin` file. You should execute the MCUboot
-script called `imgtool.py` and sign the binary file two times.
-
-The first time you will use `--version 1.0.0` and `signedv1.bin` as output
file.
-Then, the second sign you need change to `--version 2.0.0` and `signedv2.bin`
-as output file.
-
-The `signedv1.bin` file must be at MCUboot Slot-0 partition and `signedv2.bin`
-at Slot-1.
-
-More instructions about how to sign and flash can be found at board README
file.
-
-## Running swap image test
-
-Open you terminal and reboot your board. You can see a similar output as below.
-You can check builtin apps using command `?`.
-
-```bash
-*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
-NuttShell (NSH) NuttX-10.2.0
-nsh> ?
-help usage: help [-v] [<cmd>]
-
- . cd echo hexdump mv rmdir true xd
- [ cp exec kill printf set truncate
- ? cmp exit ls ps sleep uname
- basename dirname false mkdir pwd source umount
- break dd free mkrd reboot test unset
- cat df help mount rm time usleep
-
-Builtin Apps:
- mcuboot_set_img mcuboot_confirm sh
- mcuboot_version ramtest nsh
-nsh>
-```
-
-First step (check version):
-
-```bash
-nsh> mcuboot_version
-Image version 1.0.0.0
-nsh>
-```
-
-Second step (mark image as good because it is running). This is an optional
-step that must be executed if you ran `imgtool.py` without optional parameter
-`--confirm`.
-
-```bash
-nsh> mcuboot_confirm
-Application Image successfully confirmed!
-nsh>
-```
-
-Third step (let's reboot and see whats happen):
-
-```bash
-nsh> reboot
-*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
-NuttShell (NSH) NuttX-10.2.0
-nsh> mcuboot_version
-Image version 1.0.0.0
-nsh>
-```
-
-Fourth step (let's switch image):
-
-```bash
-nsh> mcuboot_set_img
-Requested update for next boot. Restarting...
-*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
-NuttShell (NSH) NuttX-10.2.0
-nsh> mcuboot_version
-Image version 2.0.0.0
-nsh>
-```
-
-Now, we switched from image version 1.0.0 to image 2.0.0. However, we
intentionaly
-will not run `mcuboot_confirm` app.
-
-```bash
-nsh> reboot
-*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
-NuttShell (NSH) NuttX-10.2.0
-nsh> mcuboot_version
-Image version 1.0.0.0
-nsh>
-```
-
-This means that if for any reason App reboot, have a malfunctioning or not
boot,
-MCUboot will switch back to old `good` image! Remember that we executed
-`mcuboot_confirm` at step two.
-
-Fifth step (switch to image version 2 and mark as permanent):
-
-```bash
-nsh> mcuboot_set_img
-Requested update for next boot. Restarting...
-*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
-NuttShell (NSH) NuttX-10.2.0
-nsh> mcuboot_confirm
-Application Image successfully confirmed!
-nsh> mcuboot_version
-Image version 2.0.0.0
-nsh>
-```
-
-Sixth step (Reboot and confirm V2 image):
-
-```bash
-nsh> reboot
-*** Booting MCUboot build 7c890f4b075aed73e4c825ccf875b2fb9ebf2ded ***
-NuttShell (NSH) NuttX-10.2.0
-nsh> mcuboot_version
-Image version 2.0.0.0
-nsh>
-```
-
-Conclusion, once we boot a newer image and confirm it MCUboot always run that
-image, unless you instruct it to swap again!
diff --git a/examples/mqttc/README.md b/examples/mqttc/README.md
deleted file mode 100644
index 28f562a0f..000000000
--- a/examples/mqttc/README.md
+++ /dev/null
@@ -1,25 +0,0 @@
-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".
diff --git a/examples/pdcurses/README.md b/examples/pdcurses/README.md
deleted file mode 100644
index 2bce03f9c..000000000
--- a/examples/pdcurses/README.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Examples / `pdcurses` PDCurses Demos
-
-This directory contains demonstration programs to show and test the
capabilities
-of `pdcurses` libraries. Some of them predate PDCurses, PCcurses or even
-`pcurses`/`ncurses`. Although some PDCurses-specific code has been added, all
-programs remain portable to other implementations (at a minimum, to `ncurses`).
-
-## Building
-
-The demos are built by the platform-specific makefiles, in the platform
-directories. There are no dependencies besides curses and the standard C
-library, and no configuration is needed.
-
-## Distribution Status
-
-Public Domain, except for `rain_main.c` and `worm_main.c`, which are under the
-ncurses license (MIT-like).
diff --git a/examples/tcp_ipc_client/README.md
b/examples/tcp_ipc_client/README.md
deleted file mode 100644
index 70dc8c149..000000000
--- a/examples/tcp_ipc_client/README.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Client TCP
-
-## What's this?
-
-This program consists of a client socket & custom messages that send data
(hex-string formatted data) to a server (tcp_ipc_server).
-Then, tcp_ipc_server send this data over LoraWAN (using Radioenge LoRaWAN
module). It means using TCP/IP sockets as IPC channel to ensure controlled
access to LoRaWAN connectivity.
-The goals of using this approach to send LoRaWAN data are:
-
-* Having a solid and reliable infrastructure to ensure IPC works fine for
multiple applications simultaneously
-* Having the possibility to host different IoT projects and solutions that use
LPWAN in a single ESP32
-* Having the possibility to validate, test and debug multiple IoT projects and
solutions at the same time, under the same connectivity conditions (same signal
strength, same antenna, same modem/transceiver, etc.)
-
-Both client and server work on local network scope.
-
-
-## How do I use this?
-
-In order to test tcp_ipc_client & tcp_ipc_server together, there are two ways
to proceed:
-
-1) Init server manually (command: SERVER &), and after successfull server
init, also init client manually (CLIENT 127.0.0.1)
-2) init server automatically after boot using NuttShell start up scripts
(check:
https://nuttx.apache.org/docs/latest/applications/nsh/installation.html#nuttshell-start-up-scripts
)
-
-## Additional info
-
-Both tcp_ipc_client and tcp_ipc_server examples have been full covered in
NuttX International Workshop 2022. You can watch the full presentation here:
https://www.youtube.com/watch?v=hr0OfTt1KeY
-The tcp_ipc_server and tcp_ipc_client examples have been developed by Flavio
Ipirranga and Pedro Bertoleti from Instituto de Pesquisas Eldorado (IPE) in
Brazil.
\ No newline at end of file
diff --git a/examples/tcp_ipc_server/README.md
b/examples/tcp_ipc_server/README.md
deleted file mode 100644
index 73019242e..000000000
--- a/examples/tcp_ipc_server/README.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Server TCP
-
-## What's this?
-
-This program consists of a server socket & custom messages to establish IPC
for multiple applications (client_tcp) and one process that controls LoRaWAN
connectivity (server_tcp).
-For more details about client side, please see client_tcp example.
-
-This approach using TCP/IP sockets as IPC channel ensures controlled access to
LoRaWAN connectivity.
-The goals of using this approach are:
-
-* Having a solid and reliable infrastructure to ensure IPC works fine for
multiple applications simultaneously
-* Having the possibility to host different IoT projects and solutions that use
LPWAN in a single ESP32
-* Having the possibility to validate, test and debug multiple IoT projects and
solutions at the same time, under the same connectivity conditions (same signal
strength, same antenna, same modem/transceiver, etc.)
-
-Both client and server work on local network scope.
-
-
-## How do I use this?
-
-In order to test client_tcp & server_tcp together, there are two ways to
proceed:
-
-1) Init server manually (command: SERVER &), and after successfull server
init, also init client manually (CLIENT 127.0.0.1)
-2) init server automatically after boot using NuttShell start up scripts
(check:
https://nuttx.apache.org/docs/latest/applications/nsh/installation.html#nuttshell-start-up-scripts
)
-
-## Additional info
-
-Both client_tcp and server_tcp examples have been full covered in NuttX
International Workshop 2022. You can watch the full presentation here:
https://www.youtube.com/watch?v=hr0OfTt1KeY
-The server_tcp and client_tcp examples have been developed by Flavio Ipirranga
and Pedro Bertoleti from Instituto de Pesquisas Eldorado (IPE) in Brazil.
\ No newline at end of file
diff --git a/examples/tcpblaster/README.md b/examples/tcpblaster/README.md
deleted file mode 100644
index 1ad0e3f3d..000000000
--- a/examples/tcpblaster/README.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# Examples / `tcpblaster` TCP Performance Test
-
-To set up, do `make menuconfig` and select the _Apps_ → _Examples_ →
-_tcpblaster_. By default, nuttx will the be the client which sends data; and
the
-host computer (Linux, macOS, or Windows) will be the server.
-
-Set up networking so the nuttx computer can ping the host, and the host can
ping
-nuttx. Now you are ready to run the test.
-
-On host:
-
-```
-$ ./tcpserver
-Binding to IPv4 Address: 00000000
-server: Accepting connections on port 5471
-```
-
-On nuttx:
-
-```
-nsh> tcpclient
-Connecting to IPv4 Address: 0100000a
-client: Connected
-[2014-07-31 00:16:15.000] 0: Sent 200 4096-byte buffers: 800.0 KB (avg
4.0 KB) in 0.18 seconds (4444.4 KB/second)
-```
-
-Now on the host you should see something like:
-
-```
-$ ./tcpserver
-Binding to IPv4 Address: 00000000
-server: Accepting connections on port 5471
-server: Connection accepted -- receiving
-[2020-02-22 16:17:07.000] 0: Received 200 buffers: 502.9 KB (buffer average
size: 2.5 KB) in 0.12 seconds (4194.8 KB/second)
-[2020-02-22 16:17:07.000] 1: Received 200 buffers: 393.1 KB (buffer average
size: 2.0 KB) in 0.09 seconds (4299.4 KB/second)
-```
-
-This will tell you the link speed in KB/sec – kilobytes per second. If you want
-kilobits, multiply by `8`.
-
-You can use the `make menuconfig` to reverse the setup, and have nuttx be the
-server, and the host be the client. If you do that, start the server first
-(nuttx), then start the client (host).
diff --git a/examples/telnetd/README.md b/examples/telnetd/README.md
deleted file mode 100644
index 28cd2e12e..000000000
--- a/examples/telnetd/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Examples / `telnetd` Telnet Daemon
-
-This directory contains a functional port of the tiny uIP shell. In the NuttX
-environment, the NuttShell (at `apps/nshlib`) supersedes this tiny shell and
-also supports telnetd.
-
-This example is retained here for reference purposes only.
