You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by xi...@apache.org on 2023/10/30 02:00:06 UTC
(nuttx-apps) branch master updated (292b0cbc2 -> 532bcc506)
This is an automated email from the ASF dual-hosted git repository.
xiaoxiang pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/nuttx-apps.git
from 292b0cbc2 examples/foc: change the velocity ramp parameters scale to x1
new 4acad717f remove system/xxx/README.md. Migrated to Documentation/applications/system
new 0f57c3256 remove wireless/xxx/README.md. Migrated to Documentation/applications/wireless
new 14f19f0e7 remove testing/xxx/README.md. Migrated to Documentation/applications/testing
new 7e918964e remove examples/xxx/README.md. Migrated to Documentation/applications/examples
new d313bbad9 remove graphics/xxx/README.md. Migrated to Documentation/applications/graphics
new 008aba12d remove netuitls/xxx/README.md. Migrated to Documentation/applications/netutils
new 24338bb47 remove tools/README.md. Migrated to Documentation/applications/tools
new 4dfd474ae remove industry/xxx/README.md and modbus/README.md. Migrated to Documentation/applications/industry
new 26f1b0795 remove interpreters/xxx/README.md. Migrated to Documentation/applications/interpreters
new 397da8f75 remove audioutils/xxx/README.md. Migrated to Documentation/applications/audioutils
new 2fac780f3 remove boot/xxx/README.md. Migrated to Documentation/applications/boot
new a6d30540f remove crypto/xxx/README.md. Migrated to Documentation/applications/crypto
new a0b34e89d remove fsutils/xxx/README.md. Migrated to Documentation/applications/fsutils
new 532bcc506 remove logging/xxx/README.md. Migrated to Documentation/applications/logging
The 14 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
audioutils/mml_parser/README.md | 211 ---
boot/mcuboot/README.md | 54 -
crypto/wolfssl/README.md | 92 --
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 -
fsutils/inifile/README.md | 144 --
graphics/lvgl/README.md | 23 -
graphics/nxwidgets/Doxygen/README.md | 68 -
graphics/nxwidgets/README.md | 68 -
graphics/nxwidgets/UnitTests/README.md | 259 ---
graphics/nxwm/Doxygen/README.md | 68 -
graphics/nxwm/README.md | 27 -
graphics/tiff/README.md | 12 -
graphics/twm4nx/README.md | 386 -----
industry/abnt_codi/README.md | 27 -
interpreters/README.md | 37 -
interpreters/bas/README.md | 59 -
interpreters/ficl/README.md | 39 -
logging/nxscope/README.md | 38 -
modbus/README.md | 120 --
netutils/README.md | 138 --
netutils/discover/README.md | 8 -
netutils/ftpc/README.md | 81 -
netutils/iperf/README.md | 94 --
netutils/netcat/README.md | 75 -
netutils/telnetd/README.md | 3 -
system/cdcacm/README.md | 36 -
system/cfgdata/README.md | 22 -
system/composite/README.md | 69 -
system/flash_eraseall/README.md | 15 -
system/i2c/README.md | 387 -----
system/libuv/README.md | 17 -
system/nsh/README.md | 50 -
system/nxplayer/README.md | 18 -
system/psmq/README.md | 61 -
system/spi/README.md | 246 ---
system/termcurses/README.md | 50 -
system/trace/README.md | 4 -
system/usbmsc/README.md | 85 -
system/ymodem/README.md | 51 -
system/zmodem/README.md | 280 ----
testing/README.md | 165 --
testing/arch_libc/README.md | 13 -
testing/cxxtest/README.md | 27 -
testing/fopencookie/README.md | 13 -
testing/fstest/README.md | 25 -
testing/mtd_config_fs/README.md | 16 -
testing/nxffs/README.md | 6 -
testing/smart/README.md | 23 -
testing/smart_test/README.md | 26 -
tools/README.md | 30 -
wireless/bluetooth/btsak/README.md | 140 --
wireless/bluetooth/nimble/README.md | 75 -
wireless/ieee802154/i8sak/README.md | 189 ---
66 files changed, 7249 deletions(-)
delete mode 100644 audioutils/mml_parser/README.md
delete mode 100644 boot/mcuboot/README.md
delete mode 100644 crypto/wolfssl/README.md
delete mode 100644 examples/README.md
rename examples/bastest/{README.md => testcases.md} (90%)
delete mode 100644 examples/camera/README.md
delete mode 100644 examples/flash_test/README.md
delete mode 100644 examples/flowc/README.md
delete mode 100644 examples/foc/README.md
delete mode 100644 examples/json/README.md
delete mode 100644 examples/mcuboot/swap_test/README.md
delete mode 100644 examples/mqttc/README.md
delete mode 100644 examples/pdcurses/README.md
delete mode 100644 examples/tcp_ipc_client/README.md
delete mode 100644 examples/tcp_ipc_server/README.md
delete mode 100644 examples/tcpblaster/README.md
delete mode 100644 examples/telnetd/README.md
delete mode 100644 fsutils/inifile/README.md
delete mode 100644 graphics/lvgl/README.md
delete mode 100644 graphics/nxwidgets/Doxygen/README.md
delete mode 100644 graphics/nxwidgets/README.md
delete mode 100644 graphics/nxwidgets/UnitTests/README.md
delete mode 100644 graphics/nxwm/Doxygen/README.md
delete mode 100644 graphics/nxwm/README.md
delete mode 100644 graphics/tiff/README.md
delete mode 100644 graphics/twm4nx/README.md
delete mode 100644 industry/abnt_codi/README.md
delete mode 100644 interpreters/README.md
delete mode 100644 interpreters/bas/README.md
delete mode 100644 interpreters/ficl/README.md
delete mode 100644 logging/nxscope/README.md
delete mode 100644 modbus/README.md
delete mode 100644 netutils/README.md
delete mode 100644 netutils/discover/README.md
delete mode 100644 netutils/ftpc/README.md
delete mode 100644 netutils/iperf/README.md
delete mode 100644 netutils/netcat/README.md
delete mode 100644 netutils/telnetd/README.md
delete mode 100644 system/cdcacm/README.md
delete mode 100644 system/cfgdata/README.md
delete mode 100644 system/composite/README.md
delete mode 100644 system/flash_eraseall/README.md
delete mode 100644 system/i2c/README.md
delete mode 100644 system/libuv/README.md
delete mode 100644 system/nsh/README.md
delete mode 100644 system/nxplayer/README.md
delete mode 100644 system/psmq/README.md
delete mode 100644 system/spi/README.md
delete mode 100644 system/termcurses/README.md
delete mode 100644 system/trace/README.md
delete mode 100644 system/usbmsc/README.md
delete mode 100644 system/ymodem/README.md
delete mode 100644 system/zmodem/README.md
delete mode 100644 testing/README.md
delete mode 100644 testing/arch_libc/README.md
delete mode 100644 testing/cxxtest/README.md
delete mode 100644 testing/fopencookie/README.md
delete mode 100644 testing/fstest/README.md
delete mode 100644 testing/mtd_config_fs/README.md
delete mode 100644 testing/nxffs/README.md
delete mode 100644 testing/smart/README.md
delete mode 100644 testing/smart_test/README.md
delete mode 100644 tools/README.md
delete mode 100644 wireless/bluetooth/btsak/README.md
delete mode 100644 wireless/bluetooth/nimble/README.md
delete mode 100644 wireless/ieee802154/i8sak/README.md
(nuttx-apps) 07/14: remove tools/README.md. Migrated to Documentation/applications/tools
Posted by xi...@apache.org.
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 24338bb477860ef7fdd8ce2f16fe9eeb357ef9eb
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:06:54 2023 +0200
remove tools/README.md. Migrated to Documentation/applications/tools
---
tools/README.md | 30 ------------------------------
1 file changed, 30 deletions(-)
diff --git a/tools/README.md b/tools/README.md
deleted file mode 100644
index d7045ee9c..000000000
--- a/tools/README.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# Tools
-
-## NxWidgets `bitmap_converter.py`
-
-This script converts from any image type supported by Python imaging library to
-the RLE-encoded format used by NxWidgets.
-
-RLE (Run Length Encoding) is a very simply encoding that compress quite well
-with certain kinds of images: Images that that have many pixels of the same
-color adjacent on a row (like simple graphics). It does not work well with
-photographic images.
-
-But even simple graphics may not encode compactly if, for example, they have
-been resized. Resizing an image can create hundreds of unique colors that may
-differ by only a bit or two in the RGB representation. This _color smear_ is the
-result of pixel interpolation (and might be eliminated if your graphics software
-supports resizing via pixel replication instead of interpolation).
-
-When a simple graphics image does not encode well, the symptom is that the
-resulting RLE data structures are quite large. The palette structure, in
-particular, may have hundreds of colors in it. There is a way to fix the graphic
-image in this case. Here is what I do (in fact, I do this on all images prior to
-conversion just to be certain):
-
-- Open the original image in GIMP.
-- Select the option to select the number of colors in the image.
-- Pick the smallest number of colors that will represent the image faithfully.
- For most simple graphic images this might be as few as 6 or 8 colors.
-- Save the image as PNG or other lossless format (NOT jpeg).
-- Then generate the image.
(nuttx-apps) 01/14: remove system/xxx/README.md. Migrated to Documentation/applications/system
Posted by xi...@apache.org.
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 4acad717fe14e2846fb1847916f78d05be88230a
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:04:46 2023 +0200
remove system/xxx/README.md. Migrated to Documentation/applications/system
---
system/cdcacm/README.md | 36 ----
system/cfgdata/README.md | 22 ---
system/composite/README.md | 69 -------
system/flash_eraseall/README.md | 15 --
system/i2c/README.md | 387 ----------------------------------------
system/libuv/README.md | 17 --
system/nsh/README.md | 50 ------
system/nxplayer/README.md | 18 --
system/psmq/README.md | 61 -------
system/spi/README.md | 246 -------------------------
system/termcurses/README.md | 50 ------
system/trace/README.md | 4 -
system/usbmsc/README.md | 85 ---------
system/ymodem/README.md | 51 ------
system/zmodem/README.md | 280 -----------------------------
15 files changed, 1391 deletions(-)
diff --git a/system/cdcacm/README.md b/system/cdcacm/README.md
deleted file mode 100644
index 61fc9cab6..000000000
--- a/system/cdcacm/README.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# System / `cdcacm` USB CDC/ACM serial
-
-This very simple add-on allows the USB CDC/ACM serial device can be dynamically
-connected and disconnected from a host. This add-on can only be used as an NSH
-built-in command. If built-in, then two new NSH commands will be supported:
-
-1. `sercon` – Connect the CDC/ACM serial device
-2. `serdis` – Disconnect the CDC/ACM serial device
-
-Configuration prerequisites (not complete):
-
-- `CONFIG_USBDEV=y` – USB device support must be enabled
-- `CONFIG_CDCACM=y` – The CDC/ACM driver must be built
-
-Configuration options specific to this add-on:
-
-- `CONFIG_SYSTEM_CDCACM_DEVMINOR` – The minor number of the CDC/ACM device,
- i.e., the `x` in `/dev/ttyACMx`.
-
-If `CONFIG_USBDEV_TRACE` is enabled (or `CONFIG_DEBUG_FEATURES` and
-`CONFIG_DEBUG_USB`, or `CONFIG_USBDEV_TRACE`), then the add-on code will also
-initialize the USB trace output. The amount of trace output can be controlled
-using:
-
-- `CONFIG_SYSTEM_CDCACM_TRACEINIT` – Show initialization events.
-- `CONFIG_SYSTEM_CDCACM_TRACECLASS` – Show class driver events.
-- `CONFIG_SYSTEM_CDCACM_TRACETRANSFERS` – Show data transfer events.
-- `CONFIG_SYSTEM_CDCACM_TRACECONTROLLER` – Show controller events.
-- `CONFIG_SYSTEM_CDCACM_TRACEINTERRUPTS` – Show interrupt-related events.
-
-**Note**: This add-on is only enables or disable USB CDC/ACM via the NSH
-`sercon` and `serdis` command. It will enable and disable tracing per the
-settings before enabling and after disabling the CDC/ACM device. It will not,
-however, monitor buffered trace data in the interim. If `CONFIG_USBDEV_TRACE` is
-defined (and the debug options are not), other application logic will need to
-monitor the buffered trace data.
diff --git a/system/cfgdata/README.md b/system/cfgdata/README.md
deleted file mode 100644
index f3768019f..000000000
--- a/system/cfgdata/README.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# System / `cfgdata`
-
-```
-Author: Ken Pettit
- Date: 18 December 2018
-```
-
-This application provides a command line interface for managing platform
-specific configdata within the `/dev/config` device.
-
-**Usage**:
-
-```shell
-config <cmd> [arguments]
-```
-
-Where `<cmd>` is one of:
-
-- `all` – show all config entries
-- `print` – display a specific config entry
-- `set` – set or change a config entry
-- `unset` – delete a config entry
diff --git a/system/composite/README.md b/system/composite/README.md
deleted file mode 100644
index 6e4d89bb8..000000000
--- a/system/composite/README.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# System / `composite` USB Composite
-
-This logic adds a NSH command to control a USB composite device. The only
-supported devices in the composite are CDC/ACM serial and a USB mass storage
-device. Which devices are enclosed in a composite device is configured with an
-array of configuration-structs, handed over to the function
-`composite_initialize()`.
-
-Required overall configuration:
-
-Enable the USB Support of your Hardware / Processor e.g. `SAMV7_USBDEVHS=y`
-
-- `CONFIG_USBDEV=y` – USB device support.
-- `CONFIG_USBDEV_COMPOSITE=y` – USB composite device support.
-- `CONFIG_COMPOSITE_IAD=y` – Interface associate descriptor needed.
-- `CONFIG_CDCACM=y` – USB CDC/ACM serial device support.
-- `CONFIG_CDCACM_COMPOSITE=y` – USB CDC/ACM serial composite device support.
-
-The interface-, string-descriptor- and endpoint-numbers are configured via the
-configuration-structs as noted above. The CDC/ACM serial device needs three
-endpoints; one interrupt-driven and two bulk endpoints.
-
-- `CONFIG_USBMSC=y` – USB mass storage device support.
-- `CONFIG_USBMSC_COMPOSITE=y` – USB mass storage composite device support.
-
-Like the configuration for the CDC/ACM, the descriptor- and endpoint-numbers are
-configured via the configuration struct.
-
-Depending on the configuration struct you need to configure different vendor-
-and product-IDs. Each `VID`/`PID` is unique to a device and thus to a dedicated
-configuration.
-
-Linux tries to detect the device types and installs default drivers if the
-`VID`/`PID` pair is unknown.
-
-Windows insists on a known and installed configuration. With an Atmel hardware
-and Atmel-Studio or the Atmel-USB-drivers installed, you can test your
-configuration with Atmel Example Vendor- and Product-IDs.
-
-If you have a USBMSC and a CDC/ACM configured in your combo, then you can try to
-use
-
-- `VID = 0x03EB` (ATMEL)
-- `PID = 0x2424` (ASF Example with MSC and CDC)
-
-If for example you try to test a configuration with up to seven CDCs, then
-
-- `VID = 0x03EB` (ATMEL)
-- `PID = 0x2426` (ASF Example with up to seven CDCs)
-
-This add-on can be built as two NSH _built-in_ commands:
-
-- `CONFIG_NSH_BUILTIN_APPS` – if this option is selected: `conn` will connect
- the USB composite device; `disconn` will disconnect the USB composite device.
-
-Configuration options unique to this add-on:
-
-- `CONFIG_SYSTEM_COMPOSITE_DEBUGMM` – Enables some debug tests to check for
- memory usage and memory leaks.
-
-If `CONFIG_USBDEV_TRACE` is enabled (or `CONFIG_DEBUG_FEATURES` and
-`CONFIG_DEBUG_USB`), then the add-on code will also manage the USB trace output.
-The amount of trace output can be controlled using:
-
-- `CONFIG_SYSTEM_COMPOSITE_TRACEINIT` – Show initialization events.
-- `CONFIG_SYSTEM_COMPOSITE_TRACECLASS` – Show class driver events.
-- `CONFIG_SYSTEM_COMPOSITE_TRACETRANSFERS` – Show data transfer events.
-- `CONFIG_SYSTEM_COMPOSITE_TRACECONTROLLER` – Show controller events.
-- `CONFIG_SYSTEM_COMPOSITE_TRACEINTERRUPTS` – Show interrupt-related events.
diff --git a/system/flash_eraseall/README.md b/system/flash_eraseall/README.md
deleted file mode 100644
index 64d485def..000000000
--- a/system/flash_eraseall/README.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# System / `flash_eraseall` Flash Erase-All
-
-```
-Author: Ken Pettit
- Date: 5 May 2013
-```
-
-This application erases the FLASH of an MTD flash block. It is simply a wrapper
-that calls the NuttX `flash_eraseall` interface.
-
-**Usage**:
-
-```shell
-flash_eraseall <flash_block_device>
-```
diff --git a/system/i2c/README.md b/system/i2c/README.md
deleted file mode 100644
index 0d005664c..000000000
--- a/system/i2c/README.md
+++ /dev/null
@@ -1,387 +0,0 @@
-# System / `i2c` I2C Tool
-
-The I2C tool provides a way to debug I2C related problems. This README file will
-provide usage information for the I2C tools.
-
-## Contents
-
-- System Requirements
- - I2C Driver
- - Configuration Options
-- Help
-- Common Line Form
-- Common Command Options
- - _Sticky_ Options
- - Environment variables
- - Common Option Summary
-- Command summary
- - `bus`
- - `dev`
- - `get`
- - `set`
- - `verf`
-- I2C Build Configuration
- - NuttX Configuration Requirements
- - I2C Tool Configuration Options
-
-## System Requirements
-
-The I2C tool is designed to be implemented as a NuttShell (NSH) add-on. Read the
-`apps/nshlib/README.md` file for information about add-ons.
-
-### Configuration Options
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the tools as an NSH built-in command.
-- `CONFIG_I2CTOOL_MINBUS` – Smallest bus index supported by the hardware
- (default `0`).
-- `CONFIG_I2CTOOL_MAXBUS` – Largest bus index supported by the hardware
- (default `3`).
-- `CONFIG_I2CTOOL_MINADDR` – Minimum device address (default: `0x03`).
-- `CONFIG_I2CTOOL_MAXADDR` – Largest device address (default: `0x77`).
-- `CONFIG_I2CTOOL_MAXREGADDR` – Largest register address (default: `0xff`).
-- `CONFIG_I2CTOOL_DEFFREQ` – Default frequency (default: `4000000`).
-
-## Help
-
-First of all, the I2C tools supports a pretty extensive help output. That help
-output can be view by entering either:
-
-```
-nsh> i2c help
-```
-
-or
-
-```
-nsh> i2c ?
-```
-
-Here is an example of the help output. I shows the general form of the command
-line, the various I2C commands supported with their unique command line options,
-and a more detailed summary of the command I2C command options.
-
-```
-nsh> i2c help
-
-Usage: i2c <cmd> [arguments]
-Where <cmd> is one of:
-
- Show help : ?
- List buses : bus
- List devices : dev [OPTIONS] <first> <last>
- Read register : get [OPTIONS] [<repetitions>]
- Show help : help
- Write register: set [OPTIONS] <value> [<repetitions>]
- Verify access : verf [OPTIONS] <value> [<repetitions>]
-
- Where common _sticky_ OPTIONS include:
- [-a addr] is the I2C device address (hex). Default: 03 Current: 03
- [-b bus] is the I2C bus number (decimal). Default: 1 Current: 1
- [-r regaddr] is the I2C device register address (hex). Default: 00 Current: 00
- [-w width] is the data width (8 or 16 decimal). Default: 8 Current: 8
- [-s|n], send/don't send start between command and data. Default: -n Current: -n
- [-i|j], Auto increment|don't increment regaddr on repetitions. Default: NO Current: NO
- [-f freq] I2C frequency. Default: 100000 Current: 100000
-```
-
-**Notes**:
-
-- An environment variable like `$PATH` may be used for any argument.
-- Arguments are _sticky_. For example, once the I2C address is specified, that
- address will be re-used until it is changed.
-
-**Warning**:
-
-- The I2C dev command may have bad side effects on your I2C devices. Use only at
- your own risk.
-
-## Command Line Form
-
-The I2C is started from NSH by invoking the `i2c` command from the NSH command
-line. The general form of the `i2c` command is:
-
-```shell
-i2c <cmd> [arguments]
-```
-
-Where `<cmd>` is a _sub-command_ and identifies one I2C operations supported by
-the tool. `[arguments]` represents the list of arguments needed to perform the
-I2C operation. Those arguments vary from command to command as described below.
-However, there is also a core set of common `OPTIONS` supported by all commands.
-So perhaps a better representation of the general I2C command would be:
-
-```shell
-i2c <cmd> [OPTIONS] [arguments]
-```
-
-Where `[OPTIONS]` represents the common options and and arguments represent the
-operation-specific arguments.
-
-## Common Command Options
-
-### _Sticky_ Options
-
-In order to interact with I2C devices, there are a number of I2C parameters that
-must be set correctly. One way to do this would be to provide to set the value
-of each separate command for each I2C parameter. The I2C tool takes a different
-approach, instead: The I2C configuration can be specified as a (potentially
-long) sequence of command line arguments.
-
-These arguments, however, are _sticky_. They are sticky in the sense that once
-you set the I2C parameter, that value will remain until it is reset with a new
-value (or until you reset the board).
-
-### Environment Variables
-
-**Note** also that if environment variables are not disabled (by
-`CONFIG_DISABLE_ENVIRON=y`), then these options may also be environment
-variables. Environment variables must be preceded with the special character
-`$`. For example, `PWD` is the variable that holds the current working directory
-and so `$PWD` could be used as a command line argument. The use of environment
-variables on the I2C tools command is really only useful if you wish to write
-NSH scripts to execute a longer, more complex series of I2C commands.
-
-### Common Option Summary
-
-- `[-a addr]` is the I2C device address (hex). Default: `03` Current: `03`
-
- The `[-a addr]` sets the I2C device address. The valid range is `0x03` through
- `0x77` (this valid range is controlled by the configuration settings
- `CONFIG_I2CTOOL_MINADDR` and `CONFIG_I2CTOOL_MAXADDR`). If you are working
- with the same device, the address needs to be set only once.
-
- All I2C address are 7-bit, hexadecimal values.
-
- **Note 1**: Notice in the `help` output above it shows both default value of the
- I2C address (`03` hex) and the current address value (also `03` hex).
-
- **Note 2**: Sometimes I2C addresses are represented as 8-bit values (with bit zero
- indicating a read or write operation). The I2C tool uses a 7-bit
- representation of the address with bit 7 unused and no read/write indication
- in bit 0. Essentially, the 7-bit address is like the 8-bit address shifted
- right by 1.
-
- **Note 3**: Most I2C bus controllers will also support 10-bit addressing. That
- capability has not been integrated into the I2C tool as of this writing.
-
-- `[-b bus]` is the I2C bus number (decimal). Default: `1` Current: `1`
-
- Most devices support multiple I2C devices and also have unique bus numbering.
- This option identifies which bus you are working with now. The valid range of
- bus numbers is controlled by the configuration settings
- `CONFIG_I2CTOOL_MINBUS` and `CONFIG_I2CTOOL_MAXBUS`.
-
- The bus numbers are small, decimal numbers.
-
-- `[-r regaddr]` is the I2C device register address (hex). Default: `00`
- Current: `00`
-
- The I2C set and get commands will access registers on the I2C device. This
- option selects the device register address (sometimes called the sub-address).
- This is an 8-bit hexadecimal value. The maximum value is determined by the
- configuration setting `CONFIG_I2CTOOL_MAXREGADDR`.
-
-- `[-w width] `is the data width (8 or 16 decimal). Default: `8` Current: `8`
-
- Device register data may be 8-bit or 16-bit. This options selects one of those
- two data widths.
-
-- `[-s|n]`, send/don't send start between command and data. Default: `-n`
- Current: `-n`
-
- This determines whether or not there should be a new I2C START between sending
- of the register address and sending/receiving of the register data.
-
-- `[-i|j]`, Auto increment|don't increment `regaddr` on repetitions. Default:
- `NO` Current: `NO`
-
- On commands that take a optional number of repetitions, the option can be used
- to temporarily increment the `regaddr` value by one on each repetition.
-
-- `[-f freq]` I2C frequency. Default: `400000` Current: `400000`
-
- The `[-f freq]` sets the frequency of the I2C device.
-
-## Command Summary
-
-We have already seen the I2C help (or `?`) commands above. This section will
-discuss the remaining commands.
-
-### List buses: `bus [OPTIONS]`
-
-This command will simply list all of the configured I2C buses and indicate which
-are supported by the driver and which are not:
-
-```
-BUS EXISTS?
-Bus 1: YES
-Bus 2: NO
-```
-
-The valid range of bus numbers is controlled by the configuration settings
-`CONFIG_I2CTOOL_MINBUS` and `CONFIG_I2CTOOL_MAXBUS`.
-
-### List devices: `dev [OPTIONS] <first> <last>`
-
-The `dev` command will attempt to identify all of the I2C devices on the
-selected bus. The `<first>` and `<last>` arguments are 7-bit, hexadecimal I2C
-addresses. This command will examine a range of addresses beginning with
-`<first>` and continuing through `<last>`. It will request the value of register
-address zero from each device.
-
-The register address of zero is always used by default. The previous _sticky_
-register address is ignored. Some devices may not respond to ergister address
-zero, however. To work around this, you can provide a new _sticky_ register
-address on the command as an option to the 'dev' command. Then that new _sticky_
-register address will be used instead of the address zero.
-
-If the device at an I2C address responds to the read request, then the `dev`
-command will display the I2C address of the device. If the device does not
-respond, this command will display `--`. The resulting display looks like:
-
-```shell
-nsh> i2c dev 03 77
-```
-
-```
- 0 1 2 3 4 5 6 7 8 9 a b c d e f
-00: -- -- -- -- -- -- -- -- -- -- -- -- --
-10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-40: -- -- -- -- -- -- -- -- -- 49 -- -- -- -- -- --
-50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-70: -- -- -- -- -- -- -- --
-```
-
-Warnings:
-- The I2C dev command may have bad side effects on certain I2C devices. For
- example, if could cause data loss in an EEPROM device.
-- The I2C dev command also depends upon the underlying behavior of the I2C
- driver. How does the driver respond to addressing failures?
-
-### Read register: `get [OPTIONS]`
-
-This command will read the value of the I2C register using the selected I2C
-parameters in the common options. No other arguments are required.
-
-This command with write the 8-bit address value then read an 8- or 16-bit data
-value from the device. Optionally, it may re-start the transfer before obtaining
-the data.
-
-An optional `<repetitions>` argument can be supplied to repeat the read
-operation an arbitrary number of times (up to 2 billion). If auto-increment is
-select (`-i`), then the register address will be temporarily incremented on each
-repetitions. The increment is temporary in the since that it will not alter the
-_sticky_ value of the register address.
-
-On success, the output will look like the following (the data value read will be
-shown as a 4-character hexadecimal number if the 16-bit data width option is
-selected).
-
-```
-READ Bus: 1 Addr: 49 Subaddr: 04 Value: 96
-```
-
-All values (except the bus numbers) are hexadecimal.
-
-### Write register: `set [OPTIONS] <value>`
-
-This command will write a value to an I2C register using the selected I2C
-parameters in the common options. The value to write must be provided as the
-final, hexadecimal value. This value may be an 8-bit value (in the range
-`00`-`ff`) or a 16-bit value (in the range `0000`-`ffff`), depending upon the
-selected data width.
-
-This command will write the 8-bit address value then write the 8- or 16-bit data
-value to the device. Optionally, it may re-start the transfer before writing the
-data.
-
-An optional `<repetitions>` argument can be supplied to repeat the write
-operation an arbitrary number of times (up to 2 billion). If auto-increment is
-select (`-i`), then the register address will be temporarily incremented on each
-repetitions. The increment is temporary in the since that it will not alter the
-_sticky_ value of the register address.
-
-On success, the output will look like the following (the data value written will
-be shown as a 4-character hexadecimal number if the 16-bit data width option is
-selected).
-
-```
-WROTE Bus: 1 Addr: 49 Subaddr: 04 Value: 96
-```
-
-All values (except the bus numbers) are hexadecimal.
-
-### Verify access: `verf [OPTIONS] <value> [<repetitions>]`
-
-
-This command combines writing and reading from an I2C device register. It will
-write a value to an will write a value to an I2C register using the selected I2C
-parameters in the common options just as described for tie `set` command. Then
-this command will read the value back just as described with the `get` command.
-Finally, this command will compare the value read and against the value written
-and emit an error message if they do not match.
-
-If no value is provided, then this command will use the register address itself
-as the data, providing for a address-in-address test.
-
-An optional `<repetitions>` argument can be supplied to repeat the verify
-operation an arbitrary number of times (up to 2 billion). If auto-increment is
-select (`-i`), then the register address will be temporarily incremented on each
-repetitions. The increment is temporary in the since that it will not alter the
-`sticky` value of the register address.
-
-On success, the output will look like the following (the data value written will
-be shown as a 4-character hexadecimal number if the 16-bit data width option is
-selected).
-
-```
-VERIFY Bus: 1 Addr: 49 Subaddr: 04 Wrote: 96 Read: 92 FAILURE
-```
-
-All values (except the bus numbers) are hexadecimal.
-
-## I2C Build Configuration
-
-### NuttX Configuration Requirements
-
-The I2C tools requires the following in your NuttX configuration:
-
-1. Application configuration.
-
- Using `make menuconfig`, select the i2c tool. The following definition should
- appear in your `.config` file:
-
- ```conf
- CONFIG_SYSTEM_I2C=y
- ```
-
-2. Device-specific I2C driver support must be enabled:
-
- ```conf
- CONFIG_I2C_DRIVER=y
- ```
-
- The I2C tool will then use the I2C character driver to access the I2C bus.
- These devices will reside at `/dev/i2cN` where `N` is the I2C bus number.
-
- **Note**: The I2C driver `ioctl` interface is defined in
- `include/nuttx/i2c/i2c_master.h`.
-
-### I2C Tool Configuration Options
-
-The default behavior of the I2C tool can be modified by the setting the options
-in the NuttX configuration. This configuration is the `defconfig` file in your
-configuration directory that is copied to the NuttX top-level directory as
-`.config` when NuttX is configured.
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the tools as an NSH built-in command.
-- `CONFIG_I2CTOOL_MINBUS` – Smallest bus index supported by the hardware
- (default `0`).
-- `CONFIG_I2CTOOL_MAXBUS` – Largest bus index supported by the hardware
- (default `3`).
-- `CONFIG_I2CTOOL_MINADDR` – Minimum device address (default: `0x03`).
-- `CONFIG_I2CTOOL_MAXADDR` – Largest device address (default: `0x77`).
-- `CONFIG_I2CTOOL_MAXREGADDR` – Largest register address (default: `0xff`).
-- `CONFIG_I2CTOOL_DEFFREQ` – Default frequency (default: `4000000`).
diff --git a/system/libuv/README.md b/system/libuv/README.md
deleted file mode 100644
index 9d853f207..000000000
--- a/system/libuv/README.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# `libuv`
-
-Most features of libuv are supported by current port, except SIGPROF relative function (loop_configure).
-
-Nearly full libuv's test suite avaliable on NuttX, but some known case can't run on sim:
-
-* loop_update_time
-* idle_starvation
-* signal_multiple_loops
-* signal_pending_on_close
-* metrics_idle_time
-* metrics_idle_time_thread
-* metrics_idle_time_zero
-
-And some will cause crash by some reason:
-
-* fs_poll_ref
diff --git a/system/nsh/README.md b/system/nsh/README.md
deleted file mode 100644
index 8d3998b01..000000000
--- a/system/nsh/README.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# System / `nsh` NuttShell (NSH)
-
-## Basic Configuration
-
-This directory provides an example of how to configure and use the NuttShell
-(NSH) application. NSH is a simple shell application. NSH is described in its
-own README located at `apps/nshlib/README.md`. This function is enabled with:
-
-```conf
-CONFIG_SYSTEM_NSH=y
-```
-
-Applications using this example will need to provide an `defconfig` file in the
-configuration directory with instruction to build the NSH library like:
-
-```conf
-CONFIG_NSH_LIBRARY=y
-```
-
-## Other Configuration Requirements
-
-**Note**: If the NSH serial console is used, then following is also required to
-build the `readline()` library:
-
-```conf
-CONFIG_SYSTEM_READLINE=y
-```
-
-And if networking is included:
-
-```conf
-CONFIG_NETUTILS_NETLIB=y
-CONFIG_NETUTILS_DHCPC=y
-CONFIG_NETDB_DNSCLIENT=y
-CONFIG_NETUTILS_TFTPC=y
-CONFIG_NETUTILS_WEBCLIENT=y
-```
-
-If the Telnet console is enabled, then the defconfig file should also include:
-
-```conf
-CONFIG_NETUTILS_TELNETD=y
-```
-
-Also if the Telnet console is enabled, 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`
diff --git a/system/nxplayer/README.md b/system/nxplayer/README.md
deleted file mode 100644
index a17730d53..000000000
--- a/system/nxplayer/README.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# System / `nxplayer` NXPlayer
-
-```
-Author: Ken Pettit
- Date: 11 Sept 2013
-```
-
-This application implements a command-line media player which uses the NuttX
-Audio system to play files (`mp3`, `wav`, etc.) from the file system.
-
-Usage:
-
-```shell
-nxplayer
-```
-
-The application presents an command line for specifying player commands, such as
-`play filename`, `pause`, `volume 50%`, etc.
diff --git a/system/psmq/README.md b/system/psmq/README.md
deleted file mode 100644
index 0e0d585a6..000000000
--- a/system/psmq/README.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# System / `psmq` Publish Subscribe Message Queue
-
-`psmq` is publish subscribe message queue. It's a set of programs and libraries
-to implement publish/subscribe way of inter-process communication on top of
-POSIX message queue.
-
-Manuals, source code and more info at: https://psmq.bofc.pl
-
-Little demo using `psmqd` broker, `psmq_pub` and `psmq_sub`:
-
-Start broker and make it log to file
-
-```
-nsh> psmqd -b/brok -p/sd/psmqd/psmqd.log &
-```
-
-Start subscribe thread that will read all messages send on `/can/*` and
-`/adc/*` topic, and dump all readings to file
-
-```
-nsh> psmq_sub -n/sub -b/brok -t/can/* -t/adc/* -o/sd/psmq-sub/can.log &
-n/connected to broker /brok
-n/subscribed to: /can/*
-n/subscribed to: /adc/*
-n/start receiving data
-n/reply timeout set 100
-```
-
-Publish some messages
-
-```
-nsh> psmq_pub -b/brok -t/can/engine/rpm -m50
-nsh> psmq_pub -b/brok -t/adc/volt -m30
-nsh> psmq_pub -b/brok -t/can/room/10/temp -m23
-nsh> psmq_pub -b/brok -t/pwm/fan1/speed -m300
-```
-
-Check out subscribe thread logs
-
-```
-nsh> cat /sd/psmq-sub/can.log
-```
-
-```
-[2021-05-23 17:53:59] p:0 l: 3 /can/engine/rpm 50
-[2021-05-23 17:53:59] p:0 l: 3 /adc/volt 30
-[2021-05-23 17:53:59] p:0 l: 3 /can/room/10/temp 23
-```
-
-As you can see `/pwm/fan1/speed` hasn't been received by subscribe thread,
-since we didn't subscribe to it.
-
-Content:
-
-- `psmqd` – broker, relays messages between clients.
-- `psmq_sub` – listens to specified topics, can be used as logger for
- communication (optional).
-- `psmq_pub` – publishes messages directly from shell. Can send binary data, but
- requires pipes, so on nuttx it can only send ASCII.
-- `libpsmq` – library used to communicate with the broker and send/receive
- messages.
diff --git a/system/spi/README.md b/system/spi/README.md
deleted file mode 100644
index 2e6e3c5af..000000000
--- a/system/spi/README.md
+++ /dev/null
@@ -1,246 +0,0 @@
-# System / `spi` SPI Tool
-
-The I2C tool provides a way to debug SPI related problems. This README file will
-provide usage information for the SPI tools.
-
-## Contents
-
-- System Requirements
- - SPI Driver
- - Configuration Options
-- Help
-- Common Line Form
-- Common Command Options
- - _Sticky_ Options
- - Environment variables
- - Common Option Summary
-- Command summary
- - `bus`
- - `dev`
- - `get`
- - `set`
- - `verf`
-- I2C Build Configuration
- - NuttX Configuration Requirements
- - I2C Tool Configuration Options
-
-## System Requirements
-
-The SPI tool is designed to be implemented as a NuttShell (NSH) add-on. Read the
-`apps/nshlib/README.md` file for information about add-ons.
-
-### Configuration Options
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the tools as an NSH built-in command.
-- `CONFIG_SPITOOL_MINBUS` – Smallest bus index supported by the hardware
- (default `0`).
-- `CONFIG_SPITOOL_MAXBUS` – Largest bus index supported by the hardware
- (default `3`).
-- `CONFIG_SPITOOL_DEFFREQ` – Default frequency (default: `40000000`).
-- `CONFIG_SPITOOL_DEFMODE` – Default mode, where
- ```
- 0 = CPOL=0, CPHA=0
- 1 = CPOL=0, CPHA=1
- 2 = CPOL=1, CPHA=0
- 3 = CPOL=1, CPHA=1
- ```
-- `CONFIG_SPITOOL_DEFWIDTH` – Default bit width (default `8`).
-- `CONFIG_SPITOOL_DEFWORDS` – Default number of words to exchange (default `1`).
-
-## Help
-
-The SPI tools supports some help output. That help output can be view by
-entering either:
-
-```
-nsh> spi help
-```
-
-or
-
-```
-nsh> spi ?
-```
-
-Here is an example of the help output. I shows the general form of the command
-line, the various SPI commands supported with their unique command line options,
-and a more detailed summary of the command SPI command options.
-
-```
-nsh> Usage: spi <cmd> [arguments]
-
-Where <cmd> is one of:
-
- Show help : ?
- List buses : bus
- SPI Exchange : exch [OPTIONS] [<hex senddata>]
- Show help : help
-
-Where common _sticky_ OPTIONS include:
- [-b bus] is the SPI bus number (decimal). Default: 0 Current: 2
- [-f freq] SPI frequency. Default: 4000000 Current: 4000000
- [-m mode] Mode for transfer. Default: 0 Current: 0
- [-u udelay] Delay after transfer in uS. Default: 0 Current: 0
- [-w width] Width of bus. Default: 8 Current: 8
- [-x count] Words to exchange. Default: 1 Current: 4
-```
-
-**Notes**:
-
-- An environment variable like $PATH may be used for any argument.
-- Arguments are _sticky_. For example, once the SPI address is specified, that
- address will be re-used until it is changed.
-
-**Warning**:
-
-- The SPI commands may have bad side effects on your SPI devices. Use only at
- your own risk.
-
-## Command Line Form
-
-The SPI is started from NSH by invoking the `spi` command from the NSH command
-line. The general form of the `spi` command is:
-
-```shell
-spi <cmd> [arguments]
-```
-
-Where `<cmd>` is a _sub-command_ and identifies one SPI operation supported by
-the tool. `[arguments]` represents the list of arguments needed to perform the
-SPI operation. Those arguments vary from command to command as described below.
-However, there is also a core set of common `OPTIONS` supported by all commands.
-So perhaps a better representation of the general SPI command would be:
-
-```shell
-i2c <cmd> [OPTIONS] [arguments]
-```
-
-Where `[OPTIONS]` represents the common options and and arguments represent the
-operation-specific arguments.
-
-## Common Command Options
-
-### _Sticky_ Options
-
-In order to interact with SPI devices, there are a number of SPI parameters that
-must be set correctly. One way to do this would be to provide to set the value
-of each separate command for each SPI parameter. The SPI tool takes a different
-approach, instead: The SPI configuration can be specified as a (potentially
-long) sequence of command line arguments.
-
-These arguments, however, are _sticky_. They are sticky in the sense that once
-you set the SPI parameter, that value will remain until it is reset with a new
-value (or until you reset the board).
-
-### Environment Variables
-
-**Note** also that if environment variables are not disabled (by
-`CONFIG_DISABLE_ENVIRON=y`), then these options may also be environment
-variables. Environment variables must be preceded with the special character
-`$`. For example, `PWD` is the variable that holds the current working directory
-and so `$PWD` could be used as a command line argument. The use of environment
-variables on the I2C tools command is really only useful if you wish to write
-NSH scripts to execute a longer, more complex series of SPI commands.
-
-### Common Option Summary
-
-- `[-b bus]` is the SPI bus number (decimal). Default: `0`
-
- Which SPI bus to commiuncate on. The bus must have been initialised as a
- character device in the config in the form `/dev/spiX` (e.g. `/dev/spi2`).
-
- The valid range of bus numbers is controlled by the configuration settings
- `CONFIG_SPITOOL_MINBUS` and `CONFIG_SPITOOL_MAXBUS`.
-
- The bus numbers are small, decimal numbers.
-
-- `[-m mode]` SPI Mode for transfer.
-
- Which of the available SPI modes is to be used. Options are;
-
- ```
- 0 = CPOL=0, CPHA=0
- 1 = CPOL=0, CPHA=1
- 2 = CPOL=1, CPHA=0
- 3 = CPOL=1, CPHA=1
- ```
-
-- `[-u udelay]` Delay after transfer in uS. Default: `0`
-
- Any extra delay to be provided after the transfer. Not normally needed from
- the command line.
-
-- `[-x count]` Words to exchange Default: `1`
-
- The number of words to be transited over the bus. For sanitys sake this is
- limited to a relatively small number (`40` by default). Any data on the
- command line is sent first, padded by `0xFF`'s while any remaining data are
- received.
-
-- `[-w width]` is the data width (varies according to target). Default: `8`
-
- Various SPI devices support different data widths. This option is untested.
-
-- `[-f freq]` I2C frequency. Default: `4000000` Current: `4000000`
-
- The `[-f freq]` sets the frequency of the SPI device. The default is very
- conservative.
-
-## Command Summary
-
-### List buses: `bus [OPTIONS]`
-
-This command will simply list all of the configured SPI buses and indicate which
-are supported by the driver and which are not:
-
-```
-BUS EXISTS?
-Bus 1: YES
-Bus 2: NO
-```
-
-The valid range of bus numbers is controlled by the configuration settings
-`CONFIG_SPITOOL_MINBUS` and `CONFIG_SPITOOL_MAXBUS`.
-
-### Exchange data: `exch [OPTIONS] <Optional TX Data>`
-
-This command triggers an SPI transfer, returning the data back from the far end.
-As an example (with MOSI looped back to MISO);
-
-```shell
-nsh> spi exch -b 2 -x 4 aabbccdd
-```
-
-```
-Received: AA BB CC DD
-```
-
-Note that the `TX Data` are always specified in hex, and are always two digits
-each, case insensitive.
-
-## I2C Build Configuration
-
-### NuttX Configuration Requirements
-
-The SPI tools requires the following in your NuttX configuration:
-
-1. Application configuration.
-
- Using `make menuconfig`, select the SPI tool. The following definition should
- appear in your `.config` file:
-
- ```conf
- CONFIG_SYSTEM_SPI=y
- ```
-
-2. Device-specific SPI driver support must be enabled:
-
- ```conf
- CONFIG_SPI_DRIVER=y
- ```
-
- The SPI tool will then use the SPI character driver to access the SPI bus.
- These devices will reside at `/dev/spiN` where `N` is the I2C bus number.
-
- **Note**: The SPI driver `ioctl` interface is defined in
- `include/nuttx/spi/spi.h`.
diff --git a/system/termcurses/README.md b/system/termcurses/README.md
deleted file mode 100644
index 9a23cf9b0..000000000
--- a/system/termcurses/README.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# System / `termcurses` Termcurses
-
-Terminal emulation library for NuttX
-
-```
-Author: Ken Pettit
- Date: 2018-2019
-```
-
-The Termcurses library provides terminal emulation support for performing common
-screen actions such as cursor movement, foreground / background color control
-and keyboard escape sequence mapping. The initial release supports only `vt100`
-/ `ansi` terminal types, but the library architecture has an extensible
-interface to allow support for additional emulation types if needed.
-
-The library can be used standalone or in conjunction with the
-`apps/graphics/pdcurses` libraries. The pdcurses libraries have been updated
-with a _termcurses_ config option which fully integrates the termcurses library
-automatically.
-
-## Usage
-
-To use the termcurses library, the routines must be initialized by calling the
-`termcurses_initterm()` function. This routine accepts a terminal type string
-identifying the type of terminal emulation support requested. If a `NULL`
-pointer is passed, then the routine will check for a `TERM` environment variable
-and set the terminal type based on that string. If the emulation type still
-cannot be determined, the routine will default to `vt100` emulation type.
-
-Upon successful initialization, the `termcurses_initterm()` function will
-allocate an new terminal context which must be passed with all future termcurses
-library functions. When this context is no longer needed, the
-`termcurses_deinitterm()` routine should be called for proper freeing and
-terminal teardown.
-
-## Use with `telnetd`
-
-When using termcurses with the telnet daemon, the telnet config option
-`CONFIG_TELNET_SUPPORT_NAWS` should be enabled. This option adds code to the
-telnet library for terminal size negotiation. Without this option, the telnet
-routines have no concept of the terminal size, and therefore the termcurses
-routines must default to `80x24` screen mode.
-
-## Use with `pdcurses`
-
-When using the pdcurses termcurses support (i.e you have enabled both the
-`CONFIG_PDCURSES` and `CONFIG_TERMCURSES` options),, the pdcurses input device
-should be selected to be `TERMINPUT` (i.e. set `CONFIG_PDCURSES_TERMINPUT=y`).
-This causes the pdcurses keyboard input logic to use `termcurses_getkeycode()`
-routine for curses input.
diff --git a/system/trace/README.md b/system/trace/README.md
deleted file mode 100644
index 3067cd046..000000000
--- a/system/trace/README.md
+++ /dev/null
@@ -1,4 +0,0 @@
-System / `trace` Task Tracer
-============================
-
-See https://nuttx.apache.org/docs/latest/guides/tasktraceuser.html
diff --git a/system/usbmsc/README.md b/system/usbmsc/README.md
deleted file mode 100644
index da85f8bbc..000000000
--- a/system/usbmsc/README.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# System / `usbmsc` USB storage driver
-
-This add-on registers a block device driver, then exports the block the device
-using the USB storage class driver. In order to use this add-on, your
-board-specific logic must provide the function:
-
-```c
-void board_usbmsc_initialize(void);
-```
-
-This function will be called by the `system/usbmsc` indirectly via the `boardctl`
-`BOARDIOC_USBDEV_CONTROL` command in order to do the actual registration of the
-block device drivers. For examples of the implementation of
-`board_usbmsc_initialize()` see
-`boards/arm/lpc214x/mcu123-lpc214x/src/up_usbmsc.c` or
-`boards/arm/stm32/stm3210e-eval/src/usbmsc.c`.
-
-Configuration options:
-
-- `CONFIG_NSH_BUILTIN_APPS` – This add-on can be built as two NSH _built-in_
- commands if this option is selected: `msconn` will connect the USB mass
- storage device; `msdis` will disconnect the USB storage device.
-
-- `CONFIG_BOARDCTL` – Enables the `boardctl()` interfaces.
-
-- `CONFIG_BOARDCTL_USBDEVCTRL` – Enables the `BOARDIOC_USBDEV_CONTROL`
- `boardctl()` command.
-
-- `CONFIG_SYSTEM_USBMSC_NLUNS` – Defines the number of logical units (LUNs)
- exported by the USB storage driver. Each LUN corresponds to one exported block
- driver (or partition of a block driver). May be `1`, `2`, or `3`. Default is
- `1`.
-
-- `CONFIG_SYSTEM_USBMSC_DEVMINOR1` – The minor device number of the block driver
- for the first LUN. For example, `N` in `/dev/mmcsdN`. Used for registering the
- block driver. Default is zero.
-
-- `CONFIG_SYSTEM_USBMSC_DEVPATH1` – The full path to the registered block
- driver. Default is `/dev/mmcsd0`
-
-- `CONFIG_SYSTEM_USBMSC_DEVMINOR2` and `CONFIG_SYSTEM_USBMSC_DEVPATH2`
- Similar parameters that would have to be provided if
- `CONFIG_SYSTEM_USBMSC_NLUNS` is `2` or `3`. No defaults.
-
-- `CONFIG_SYSTEM_USBMSC_DEVMINOR3` and `CONFIG_SYSTEM_USBMSC_DEVPATH3`
- Similar parameters that would have to be provided if
- `CONFIG_SYSTEM_USBMSC_NLUNS` is `3`. No defaults.
-
-- `CONFIG_SYSTEM_USBMSC_DEBUGMM` – Enables some debug tests to check for memory
- usage and memory leaks.
-
-If `CONFIG_USBDEV_TRACE` is enabled (or `CONFIG_DEBUG_FEATURES` and
-`CONFIG_DEBUG_USB`), then the code will also manage the USB trace output. The
-amount of trace output can be controlled using:
-
-- `CONFIG_SYSTEM_USBMSC_TRACEINIT` – Show initialization events.
-- `CONFIG_SYSTEM_USBMSC_TRACECLASS` – Show class driver events.
-- `CONFIG_SYSTEM_USBMSC_TRACETRANSFERS` – Show data transfer events.
-- `CONFIG_SYSTEM_USBMSC_TRACECONTROLLER` – Show controller events.
-- `CONFIG_SYSTEM_USBMSC_TRACEINTERRUPTS` – Show interrupt-related events.
-
-Error results are always shown in the trace output
-
-**Note 1**: When built as an NSH add-on command (`CONFIG_NSH_BUILTIN_APPS=y`),
-Caution should be used to assure that the SD drive (or other storage device) is
-not in use when the USB storage device is configured. Specifically, the SD
-driver should be unmounted like:
-
-```shell
-nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard # Card is mounted in NSH
-...
-nsh> umount /mnd/sdcard # Unmount before connecting USB!!!
-nsh> msconn # Connect the USB storage device
-...
-nsh> msdis # Disconnect USB storate device
-nsh> mount -t vfat /dev/mmcsd0 /mnt/sdcard # Restore the mount
-```
-
-Failure to do this could result in corruption of the SD card format.
-
-**Note 2**: This add-on used internal USB device driver interfaces. As such, it
-relies on internal OS interfaces that are not normally available to a user-space
-program. As a result, this add-on cannot be used if a NuttX is built as a
-protected, supervisor kernel (`CONFIG_BUILD_PROTECTED` or
-`CONFIG_BUILD_KERNEL`).
diff --git a/system/ymodem/README.md b/system/ymodem/README.md
deleted file mode 100644
index f7bf687de..000000000
--- a/system/ymodem/README.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Introduce
-
-This is [ymodem protocal](http://pauillac.inria.fr/~doligez/zmodem/ymodem.txt).
-According to it, the sb rb application is realized, which is used to send files and receive files respectively
-
-# Usage
-
-## Common Usage
-
-In the ubuntu system, lszrz needs to be installed, can use `sudo apt install lszrz`.
-Use minicom to communicate with the board.
-
-
-## Advanced Usage
-
-In order to achieve a faster transmission speed,
-I added a specific HEADER `STC` to the YMODEM protocol to represent the custom length.
-Using the `sb` and `rb` commands on the board, you can use the `-k` option to set the length
-of the custom packet, and the unit is KB. Therefore, you need to use `sbrb.py` for file transfer,
-and you need `sbrb.py` -k to set the same length as the board. According to my test,
-when using -k 32, it can reach 93% of the baud rate,
-and is fully compatible with the original ymodem protocol.
-First, you need to add a soft link to sbrb.py, for example `sudo ln -s /home/<name>/.../<nuttxwork>/apps/system/ymodem/sbrb.py /usr/bin`
-and then sbrb.py can be configured into minicom.`<Ctrl + a> z o` then chose `File transfer protocols` and
-crate two option cmd is 'sbrb.py -k 32'. like this
-
-| Name | Program | Name | U/D | FullScr | IO-Red. | Multi |
-| ---- | ------- | ---- | --- | ------- | ------- | ----- |
-| ymodem-k | sbrb.py -k 32 | Y | U | N | Y | Y |
-| ymodem-k | sbrb.py -k 32 | N | D | N | Y | Y |
-
-usb `sb -k 32` or `rb -k 32` for file transfer on board.
-
-## Sendfile to pc
-
-use sb command like this `nsh> sb /tmp/test.c ...`, this command support send multiple files together
-then use `<Ctrl + a> , r` chose `ymodem` to receive board file.
-
-## Sendfile to board
-
-use rb cmd like this `nsh> rb`, this command support receive multiple files together
-then use `<Ctrl + a> , s` chose `ymodem`, then chose what file need to send.
-
-## help
-
-can use `sb -h` or `rb -h` get help.
-
-# Debug
-
-Because the serial port is used for communication, the log is printed to the debug file
-you can use `CONFIG_SYSTEM_YMODEM_DEBUGFILE_PATH` set debug file path.
diff --git a/system/zmodem/README.md b/system/zmodem/README.md
deleted file mode 100644
index a48f67b8f..000000000
--- a/system/zmodem/README.md
+++ /dev/null
@@ -1,280 +0,0 @@
-# System / `zmodem`
-
-## Contents
-
-- Buffering Notes
- - Hardware Flow Control
- - RX Buffer Size
- - Buffer Recommendations
-- Using NuttX ZModem with a Linux Host
- - Sending Files from the Target to the Linux Host PC
- - Receiving Files on the Target from the Linux Host PC
-- Building the ZModem Tools to Run Under Linux
-- Status
-
-## Buffering Notes
-
-### Hardware Flow Control
-
-Hardware flow control must be enabled in serial drivers in order to prevent data
-overrun. However, in the most NuttX serial drivers, hardware flow control only
-protects the hardware RX FIFO: Data will not be lost in the hardware FIFO but
-can still be lost when it is taken from the FIFO. We can still overflow the
-serial driver's RX buffer even with hardware flow control enabled! That is
-probably a bug. But the workaround solution that I have used is to use lower
-data rates and a large serial driver RX buffer.
-
-Those measures should be unnecessary if buffering and hardware flow control are
-set up and working correctly.
-
-### Software Flow Control
-
-The ZModem protocol has `XON/XOFF` flow control built into it. The protocol
-permits `XON` or `XOFF` characters placed at certain parts of messages. If
-software flow control is enabled on the receiving end it will consume the `XON`s
-and `XOFF`s. Otherwise they will be ignored in the data by the ZModem logic.
-
-NuttX, however, does not implement `XON/XOFF` flow control so these do nothing.
-On NuttX you will have to use hardware flow control in most cases.
-
-The `XON`/`XOFF` controls built into ZModem could be used if you enabled
-software flow control in the host. But that would only work in one direction: If
-would prevent the host from overrunning the the target Rx buffering. So you
-should be able to do host-to-target software flow control. But there would still
-be no target-to-host flow control. That might not be an issue because the host
-is usually so much faster than that target.
-
-### RX Buffer Size
-
-The ZModem protocol supports a message that informs the file sender of the
-maximum size of data that you can buffer (`ZRINIT`). However, my experience is
-that the Linux sz ignores this setting and always sends file data at the maximum
-size (`1024`) no matter what size of buffer you report. That is unfortunate
-because that, combined with the possibilities of data overrun mean that you must
-use quite large buffering for ZModem file receipt to be reliable (none of these
-issues effect sending of files).
-
-### Buffer Recommendations
-
-Based on the limitations of NuttX hardware flow control and of the Linux sz
-behavior, I have been testing with the following configuration (assuming `UART1`
-is the ZModem device):
-
-1) This setting determines that maximum size of a data packet frame:
-
- ```conf
- CONFIG_SYSTEM_ZMODEM_PKTBUFSIZE=1024
- ```
-
-2) Input Buffering. If the input buffering is set to a full frame, then data
- overflow is less likely.
-
- ```conf
- CONFIG_UART1_RXBUFSIZE=1024`
- ```
-
-3) With a larger driver input buffer, the ZModem receive I/O buffer can be
- smaller:
-
- ```conf
- CONFIG_SYSTEM_ZMODEM_RCVBUFSIZE=256
- ```
-
-4) Output buffering. Overrun cannot occur on output (on the NuttX side) so there
- is no need to be so careful:
-
- ```conf
- CONFIG_SYSTEM_ZMODEM_SNDBUFSIZE=512
- CONFIG_UART1_TXBUFSIZE=256
- ```
-
-## Using NuttX ZModem with a Linux Host
-
-### Sending Files from the Target to the Linux Host PC
-
-The NuttX ZModem commands have been verified against the rzsz programs running
-on a Linux PC. To send a file to the PC, first make sure that the serial port is
-configured to work with the board (Assuming you are using 9600 baud for the data
-transfers - high rates may result in data overruns):
-
-```bash
-$ sudo stty -F /dev/ttyS0 9600 # Select 9600 BAUD
-$ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking *
-$ sudo stty -F /dev/ttyS0 raw # Puts the TTY in raw mode
-$ sudo stty -F /dev/ttyS0 # Show the TTY configuration
-```
-
-\* Only if hardware flow control is enabled.
-
-Start `rz` on the Linux host (using `/dev/ttyS0` as an example):
-
-```bash
-$ sudo rz < /dev/ttyS0 > /dev/ttyS0
-```
-
-You can add the `rz -v` option multiple times, each increases the level of debug
-output. If you want to capture the Linux `rz` output, then re-direct `stderr` to
-a log file by adding `2>rz.log` to the end of the `rz` command.
-
-**Note**: The NuttX ZModem does sends `rz\n` when it starts in compliance with
-the ZModem specification. On Linux this, however, seems to start some other,
-incompatible version of `rz`. You need to start `rz` manually to make sure that
-the correct version is selected. You can tell when this evil `rz`/`sz` has
-inserted itself because you will see the `^` (`0x5e`) character replacing the
-standard ZModem `ZDLE` character (`0x19`) in the binary data stream.
-
-If you don't have the `rz` command on your Linux box, the package to install
-`rzsz` (or possibly `lrzsz`).
-
-Then on the target (using `/dev/ttyS1` as an example).
-
-```
-nsh> sz -d /dev/ttyS1 <filename>
-```
-
-Where filename is the full path to the file to send (i.e., it begins with the
-`/` character). `/dev/ttyS1` or whatever device you select **must** support
-Hardware flow control in order to throttle therates of data transfer to fit
-within the allocated buffers.
-
-### Receiving Files on the Target from the Linux Host PC
-
-**Note**: There are issues with using the Linux `sz` command with the NuttX `rz`
-command. See _Status_ below. It is recommended that you use the NuttX `sz`
-command on Linux as described in the next paragraph.
-
-To send a file to the target, first make sure that the serial port on the host
-is configured to work with the board (Assuming that you are using `9600` baud
-for the data transfers - high rates may result in data overruns):
-
-```bash
-$ sudo stty -F /dev/ttyS0 9600 # Select 9600 (or other) BAUD
-$ sudo stty -F /dev/ttyS0 crtscts # Enables CTS/RTS handshaking *
-$ sudo stty -F /dev/ttyS0 raw # Puts the TTY in raw mode
-$ sudo stty -F /dev/ttyS0 # Show the TTY configuration
-```
-
-\* Only is hardware flow control is enabled.
-
-Start `rz` on the on the target. Here, in this example, we are using
-`/dev/ttyS1` to perform the transfer
-
-```shell
-nsh> rz -d /dev/ttyS1
-```
-
-`/dev/ttyS1` or whatever device you select **must** support Hardware flow
-control in order to throttle therates of data transfer to fit within the
-allocated buffers.
-
-Then use the `sz` command on Linux to send the file to the target:
-
-```bash
-$ sudo sz <filename> [-l nnnn] [-w nnnn] </dev/ttyS0 >/dev/ttyS0
-```
-
-Where `<filename>` is the file that you want to send. If `-l nnnn` and `-w nnnn`
-is not specified, then there will likely be packet buffer overflow errors.
-`nnnn` should be set to a value less than or equal to
-`CONFIG_SYSTEM_ZMODEM_PKTBUFSIZE`.
-
-The resulting file will be found where you have configured the ZModem
-**sandbox** via `CONFIG_SYSTEM_ZMODEM_MOUNTPOINT`.
-
-You can add the `sz -v` option multiple times, each increases the level of debug
-output. If you want to capture the Linux `sz` output, then re-direct `stderr` to
-a log file by adding `2>sz.log` to the end of the `sz` command.
-
-If you don't have the sz command on your Linux box, the package to install
-`rzsz` (or possibly `lrzsz`).
-
-## Building the ZModem Tools to Run Under Linux
-
-Build support has been added so that the NuttX ZModem implementation can be
-executed on a Linux host PC. This can be done by
-
-- Change to the `apps/systems/zmodem` directory
-- Make using the special makefile, `Makefile.host`
-
-**Notes**:
-
-1. `TOPDIR` and `APPDIR` must be defined on the make command line: `TOPDIR` is
- the full path to the `nuttx/` directory; `APPDIR` is the full path to the
- `apps/` directory. For example, if you installed nuttx at
- `/home/me/projects/nuttx` and apps at `/home/me/projects/apps`, then the
- correct make command line would be:
-
- ```bash
- make -f Makefile.host TOPDIR=/home/me/projects/nuttx APPDIR=/home/me/projects/apps
- ```
-
-2. Add `CONFIG_DEBUG_FEATURES=1` to the make command line to enable debug output
-3. Make sure to clean old target `.o` files before making new host `.o` files.
-
-This build is has been verified as of `2013-7-16` using Linux to transfer files
-with an Olimex LPC1766STK board. It works great and seems to solve all of the
-problems found with the Linux `sz`/`rz` implementation.
-
-## Status
-
-- `2013-7-15`: Testing against the Linux `rz`/`sz` commands.
-
- I have tested with the `boards/arm/lpc17xx_40xx/olimex-lpc1766stk`
- configuration. I have been able to send large and small files with the target
- `sz` command. I have been able to receive small files, but there are problems
- receiving large files using the Linux `sz` command: The Linux `sz` does not
- obey the buffering limits and continues to send data while `rz` is writing the
- previously received data to the file and the serial driver's RX buffer is
- overrun by a few bytes while the write is in progress. As a result, when it
- reads the next buffer of data, a few bytes may be missing. The symptom of this
- missing data is a CRC check failure.
-
- Either (1) we need a more courteous host application, or (2) we need to
- greatly improve the target side buffering capability!
-
- My thought now is to implement the NuttX `sz` and `rz` commands as PC side
- applications as well. Matching both sides and obeying the handshaking will
- solve the issues. Another option might be to fix the serial driver hardware
- flow control somehow.
-
-- `2013-7-16`. More Testing against the Linux `rz`/`sz` commands.
-
- I have verified that with debug off and at lower serial BAUD (`2400`), the
- transfers of large files succeed without errors. I do not consider this a
- _solution_ to the problem. I also found that the LPC17xx hardware flow control
- caused strange hangs; ZModem works better with hardware flow control disabled
- on the LPC17xx.
-
- At this lower BAUD, RX buffer sizes could probably be reduced; Or perhaps the
- BAUD could be increased. My thought, however, is that tuning in such an
- unhealthy situation is not the approach: The best thing to do would be to use
- the matching NuttX sz on the Linux host side.
-
-- `2013-7-16`. More Testing against the NuttX `rz`/`sz` on Both Ends.
-
- The NuttX `sz`/`rz` commands have been modified so that they can be built and
- executed under Linux. In this case, there are no transfer problems at all in
- either direction and with large or small files. This configuration could
- probably run at much higher serial speeds and with much smaller buffers
- (although that has not been verified as of this writing).
-
-- `2018-5-27`
-
- Updates to checksum calculations. Verified correct operation with hardware
- flow control using the `olimex-stm32-p407/zmodem` configuration. Only the
- host-to-target transfer was verified.
-
- This was using the Linux `sz` utility. There appears to still be a problem
- using the NuttX `sz` utility running on Linux.
-
-- `2018-5-27`
-
- Verified correct operation with hardware flow control using the
- `olimex-stm32-p407/zmodem` configuration with target-to-host transfers was
- verified. Again, there are issues remaining if I tried the NuttX `rz` utility
- running on Linux.
-
-- `2018-6-26`
-
- With `-w nnnn` option, the host-to-target transfer can work reliably without
- hardware flow control.
(nuttx-apps) 10/14: remove audioutils/xxx/README.md. Migrated to Documentation/applications/audioutils
Posted by xi...@apache.org.
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 397da8f752985b784b91ce64d45a038964abdd5e
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:08:10 2023 +0200
remove audioutils/xxx/README.md. Migrated to Documentation/applications/audioutils
---
audioutils/mml_parser/README.md | 211 ----------------------------------------
1 file changed, 211 deletions(-)
diff --git a/audioutils/mml_parser/README.md b/audioutils/mml_parser/README.md
deleted file mode 100644
index 95dde0126..000000000
--- a/audioutils/mml_parser/README.md
+++ /dev/null
@@ -1,211 +0,0 @@
-# Music Macro Language (MML) Parser library
-
-MML has often been used as a language for describing music in strings, for example,
-in the BASIC language. The mml_parser is a minimalistic Music Macro Language parser
-library written in pure C intended for resource-constrained platforms, especially
-microcontrollers and other embedded systems.
-
-## Supported Syntax on this library
-
-### Notes
-
-* **C** (Do)
-* **D** (Re)
-* **E** (Mi)
-* **F** (Fa)
-* **G** (Sol)
-* **A** (La)
-* **B** (Ti)
-
-### Sharp and Flat
-
-Add "#" or "+" after the note indicates Sharp. ex: ``"C#"`` ``"C+."``
-Add "-" after the note indicates Flat. ex: ``"C-"``
-
-### Length
-
-Length of the tone can be specified in two ways.
-One is to specify a length for each note. Add a number after the note in 1, 2, 4, 8, 16, 32 or 64.
-ex: ``"C8 C16 C#4."``
-
-The other is to use ``L`` . The ``L`` sets default length. If the note without length, the number which is
-indicated by the "L" is used. The number followed after the "L" can be in 1, 2, 4, 8, 16, 32 or 64.
-ex: ``"L4 A"`` means "A" with length 4.
-
-In addition, dot is supported. For example, length of "C4." is 4 + 8. Length of "C16.." is 4 + 8 + 16.
-
-### Rest
-
-Rest is represented by "R".
-Length of the rest is following after the "R" as the same as the note length. If no length is
-specified, the length specified by the ”L" is used.
-
-### Chord
-
-Chord is supported. If some notes are enclosed in parentheses by ``[`` and ``]``, they are interpreted as
-a chord. ex: ``"[CEG]"`` is a chord of Do, Mi and Sol.
-Chord's length can be put after ``]`` . ex: ``"[CEG]4"`` is a chord with 4 length.
-
-Note: Max notes in a chord is defined as MAX_CHORD_NOTES in ``mml_parser.h``.
-
-### Tuplet
-
-Tuplet is supported. If some notes and Chord are enclosed in parentheses by ``{`` and ``}``, they are
-interpreted as a tuplet. ex: ``"{C E G [CEG]}"`` is a tuplet with C, E, G and chord of CEG.
-Tuplet's length can be put after "}", and the length is divided equally among each note.
-ex: in ``"{C E G [CEG]}4"`` case, C, E, G and chord CEG has each a quarter of the L4 length.
-
-### Octave
-
-Octarve is controlled by "O", ">" or "<".
-When "O" is used, the O is followed by a number indicating the octave.
-When ">" is used, the value of the new octave is the current octave plus one.
-When "<" is used, the value of the new octave is the current octave minus one.
-ex: ``"CDEFGAB > C R C < BAGFEDC"``, ``"O4 CDEFGAB O5 C R C O4 BAGFEDC"``
-
-### Tempo
-
-Tempo is indicated as "T" and numter following after the "T".
-Tempo number decide a speed of the score. This value is used for culculating sample number for
-the note (or rest).
-ex: ``"T120"``
-
-### Volume
-
-Volume can be controlled by "V". And numter following after the "V".
-ex: ``"V4"``
-
-## Example of a score
-
-### The beginning of the Do Re Mi Song.
-
-Tempo 120, Voulume 10, Octave 4, Default length is 4.
-
-``"T120 V10 O4 L4 C. D8 E. C8 E C E2 D. E8 {FF} {ED} F2"``
-
-## Provided C Functions
-
-mml_parser is providing just 2 functions.
-
-### init_mml()
-
-Initialize an instance of mml parser.
-
-#### Synopsis
-
-```c
-#include <audioutils/mml_parser.h>
-
-int init_mml(FAR struct music_macro_lang_s *mml,
- int fs, int tempo, int octave, int length);
-```
-
-#### Description
-
-The function initializes `struct music_macro_lang_s` instance provided as 1st argument.
-The argument `fs` is a sampling frequency of target audio output system, and this value is used for
-calculating sample number in case of a tempo and length of note.
-`tempo`, `octave` and `length` specify initial values for tempo, octave, and length, respectively.
-
-#### Return value
-
-On success, init_mml() returns 0. On error, it returns an negative value.
-
-#### Errors
-
-Currently no error is happened.
-
-### parse_mml()
-
-Parse MML from given string.
-
-#### Synopsis
-
-```c
-#include <audioutils/mml_parser.h>
-
-int parse_mml(FAR struct music_macro_lang_s *mml,
- FAR char **score, FAR struct mml_result_s *result);
-```
-
-#### Description
-
-parse_mml() parses the first MML of the string given by the argument ``score`` and gives
-the result in the return value and the argument ``result``.
-The ``result`` is an instance of mml_result_s, which contains note_idx, length, and
-chord_notes as members. The meaning of the value of each member depends on the return value.
-
-#### Return value
-
-On error, a nevative value is returned.
-On success, following values can be returned. And those values are defined in ``mml_parser.h``.
-
-| Return values | Description |
-| -------------------- | ----------- |
-| MML_TYPE_EOF | This means that it have reached the end of the string. The content of the ``result`` has no meaning. |
-| MML_TYPE_NOTE | This indicates that some note has been parsed. The scale of the note is stored in ``note_idx[0]``. The length of the note is given by the ``length`` member as the number of samples. In the case of tuplet, this return value is returned at the time each note is parsed. In other words, a tuplet is parsed as a single note. |
-| MML_TYPE_REST | This indicates the ``rest`` has been parsed. The length of it is given by the ``length`` member as the number of samples. |
-| MML_TYPE_TEMPO | This indicates ``"T"`` is parsed. ``length`` member in ``result`` has the value of the tempo. But tempo value is kept in mml instance for calculating sample number for each notes. So basically, no need to handle this return value in your code. |
-| MML_TYPE_LENGTH | This indicates ``"L"`` is parsed. ``length`` member in ``result`` has the value of the parsed length. But current length value is kept in mml instance. So basically, no need to handle this return value in your code. |
-| MML_TYPE_OCTAVE | This indicates ``"O"``, ``">"``, or ``"<"`` is parsed. ``length`` member in ``result`` has the value of the octave. But the octave is encoded in ``note_idx`` in ``MML_TYPE_NOTE`` case. So basically, no need to handle this return value in your code. |
-| MML_TYPE_TUPLETSTART | This indicates tuplet is just started. And total length of the tuplet is stored in ``length`` of ``result`` members. |
-| MML_TYPE_TUPLETDONE | This indicates the tuplet is just finished. |
-| MML_TYPE_VOLUME | This indicates ``"V"`` is parsed. ``length`` member in ``result`` has the value of the parsed volume. |
-| MML_TYPE_TONE | T.B.D. |
-| MML_TYPE_CHORD | This indicates a chord is parsed. Chord has some notes, and how many notes is stored in ``chord_notes`` member of ``result``. And each notes are stored in ``note_idx[]``. Length of the chord is stored in ``length`` member of ``result``. |
-
-The value of ``note_idx[]`` is encoding octave, like
-
-| Octave | Note | node_idx value |
-| ------ | ---- |:--------------:|
-| O0 | C | 0 |
-| O0 | C# | 1 |
-| O0 | D | 2 |
-| O0 | D# | 3 |
-| O0 | E | 4 |
-| O0 | F | 5 |
-| O0 | F# | 6 |
-| O0 | G | 7 |
-| O0 | G# | 8 |
-| O0 | A | 9 |
-| O0 | A# | 10 |
-| O0 | B | 11 |
-| O1 | C | 12 |
-
-And so on.
-
-So for example, G# at Octave 4 is encoded as 56.
-
-#### Errors
-
-Following error code can be received as return value.
-
-| Error code | Description |
-| ------------------------------ | -------------- |
-| MML_TYPE_NOTE_ERROR | |
-| MML_TYPE_REST_ERROR | |
-| MML_TYPE_TEMPO_ERROR | |
-| MML_TYPE_LENGTH_ERROR | |
-| MML_TYPE_OCTAVE_ERROR | |
-| MML_TYPE_VOLUME_ERROR | |
-| MML_TYPE_TUPLET_ERROR | |
-| MML_TYPE_TONE_ERROR | |
-| MML_TYPE_CHORD_ERROR | |
-| MML_TYPE_ILLIGAL_COMPOSITION | |
-| MML_TYPE_ILLIGAL_TOOMANY_NOTES | |
-| MML_TYPE_ILLIGAL_TOOFEW_NOTES | |
-| MML_TYPE_ILLIGAL_DOUBLE_TUPLET | |
-
-
-## Running unit tests
-
-Please see examples/mml_parser
-
-## Bugs
-
-There are plenty. Report them on GitHub, or - even better - open a pull request.
-Please write unit tests for any new functions you add - it's fun!
-
-## Author
-
-mml_parser was written by Takayoshi Koizumi <takayoshi.koizumi@gmail.com>
(nuttx-apps) 09/14: remove interpreters/xxx/README.md. Migrated to Documentation/applications/interpreters
Posted by xi...@apache.org.
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 26f1b07955a18c55281f7de34e9aae29b67a21b1
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:07:48 2023 +0200
remove interpreters/xxx/README.md. Migrated to Documentation/applications/interpreters
---
interpreters/README.md | 37 ----------------------------
interpreters/bas/README.md | 59 ---------------------------------------------
interpreters/ficl/README.md | 39 ------------------------------
3 files changed, 135 deletions(-)
diff --git a/interpreters/README.md b/interpreters/README.md
deleted file mode 100644
index 0a1d1c66f..000000000
--- a/interpreters/README.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# Interpreters
-
-This `apps/` directory is set aside to hold interpreters that may be
-incorporated into NuttX.
-
-## Ficl
-
-This is DIY port of Ficl (the _Forth Inspired Command Language_). See
-http://ficl.sourceforge.net/. It is a _DIY_ port because the Ficl source is not
-in that directory, only an environment and instructions that will let you build
-Ficl under NuttX. The rest is up to you.
-
-## Lua
-
-Fetch and build a Lua interpreter. Versions 5.2 through 5.4 are supported. The
-`lua` command will be added to NSH. Lua can run a script for a given path,
-execute a string of code, or open a readline compatible REPL on the NSH console.
-The `<lua.h>` and `<lauxlib.h>` headers are available to start a new embedded
-interpreter or extend Lua with C modules. See the `luamod_hello` example for how
-to include a built-in module.
-
-A math library is required to build. Enable the `LIBM` config or use a
-toolchain provided math library.
-
-The following configs are recommended for a full featured Lua interpreter:
-- `LIBC_FLOATINGPOINT`
-- `SYSTEM_READLINE`
-
-## Mini Basic
-
-The Mini Basic implementation at `apps/interpreters` derives from version `1.0`
-by Malcolm McLean, Leeds University, and was released under the Creative Commons
-Attibution license. I am not legal expert, but this license appears to be
-compatible with the NuttX BSD license see:
-https://creativecommons.org/licenses/. I, however, cannot take responsibility
-for any actions that you might take based on my understanding. Please use your
-own legal judgement.
diff --git a/interpreters/bas/README.md b/interpreters/bas/README.md
deleted file mode 100644
index be3f431eb..000000000
--- a/interpreters/bas/README.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Interpreters / `bas` Bas BASIC
-
-## Introduction
-
-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.
-
-## Bas 2.4 Release Notes
-
-Changes compared to version `2.3`
-
-- Matrix inversion on integer arrays with option base 1 fixed.
-- `PRINT USING` behaviour for `!` fixed.
-- `PRINT`, separator should advance to the next zone, even if the current
- position is at the start of a zone.
-- Added `ip()`, `frac()`, `fp()`, `log10()`, `log2()`, `min()` and `max()`.
-- Fixed `NEXT` checking the variable case sensitive.
-- Use `terminfo` capability cr to make use of its padding.
-- `LET` segmentation fault fixed.
-- `PRINT` now uses print items.
-- `-r` for restricted operation.
-- `MAT INPUT` does not drop excess arguments, but uses them for the next row.
-- License changed to MIT.
diff --git a/interpreters/ficl/README.md b/interpreters/ficl/README.md
deleted file mode 100644
index 743a1ee63..000000000
--- a/interpreters/ficl/README.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Interpreters / `ficl` Ficl
-
-Ficl is a programming language interpreter designed to be embedded into other
-systems as a command, macro, and development prototyping language. Ficl is an
-acronym for _Forth Inspired Command Language_. See http://ficl.sourceforge.net/
-
-## Build Instructions
-
-Disclaimer: This installation steps have only been exercised using Ficl 4.1.0.
-With new versions you will likely have to make some adjustments to this
-instructtions or to the files within this directory. Think of this information
-as _recommendations_ - not necessarily proven instructions.
-
-1. `cd` to `interpreters/ficl`
-
-2. Download Ficl: http://sourceforge.net/projects/ficl/files/
-
-3. Uznip the Ficl compressed file.
-
- For example, `unzip ficl-4.1.0.zip` will leave the file
- `interpreters/ficl/ficl-4.1.0`.
-
-4. Configure to build Ficl in the `interpreters/ficl` directory using the
- `configure.sh` script.
-
- For example, `./configure.sh ficl-4.1.0` will leave the Makefile fragment
- `Make.srcs` in the ficl build directory.
-
-5. Create your NuttX configuration. Using the `make menuconfig`, you should
- select:
-
- ```conf
- CONFIG_INTERPRETERS_FICL=y
- ```
-
-6. Configure and build NuttX. On successful completion, the Ficl objects will be
- available in `apps/libapps.a` and that NuttX binary will be linked against
- that file. Of course, Ficl will do nothing unless you have written some
- application code that uses it!
(nuttx-apps) 08/14: remove industry/xxx/README.md and modbus/README.md. Migrated to Documentation/applications/industry
Posted by xi...@apache.org.
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 4dfd474ae934474d4db26161bf8a09b001ed8b4a
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:07:34 2023 +0200
remove industry/xxx/README.md and modbus/README.md. Migrated to Documentation/applications/industry
---
industry/abnt_codi/README.md | 27 ----------
modbus/README.md | 120 -------------------------------------------
2 files changed, 147 deletions(-)
diff --git a/industry/abnt_codi/README.md b/industry/abnt_codi/README.md
deleted file mode 100644
index 849e2dc96..000000000
--- a/industry/abnt_codi/README.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Industry / `abnt_codi` ABNT CODI
-
-The ABNT CODI is an old energy meter standard used in Brazil.
-
-This code interprets the end user serial output existent in the energy meter.
-That output externalizes its data blinking an LED as a serial protocol at the
-baudrate of `110 BPS` and uses `8` octects:
-
-| Octet | Bits | Description
-|:-----:|------:|-------------
-| `001` | `0-7` | Number of seconds to the end of current active demand (`LSB`)
-| `002` | `0-3` | Number of seconds to the end of current active demand (`MSB`)
-| | `4` | Bill indicator. It is inverted at each demand replenishment
-| | `5` | Reactive Interval Indicator. Inverted at end react interval
-| | `6` | If `1` means the reactive-capacitive is used to calculate `UFER`
-| | `7` | If `1` means the reactive-inductive is used to calculate `UFER`
-| `003` | `0-3` | Current seasonal segment: <br> `0001` – tip <br> `0010` – out of tip <br> `1000` – reserved
-| | `4-5` | Type of charging indicator (flag): <br> `00` – Blue <br> `01` – Green <br> `10` – Irrigators <br> `11` – Other
-| | `6` | Not used
-| | `7` | If equal `1` means reactive rate is enabled
-| `004` | `0-7` | Number of pulses for active energy of cur dem interv (`LSB`)
-| `005` | `0-6` | Number of pulses for active energy of cur dem interv (`MSB`)
-| | `7` | Not used
-| `006` | `0-7` | Number of pulses for reactive energy of cur dem interv (`LSB`)
-| `007` | `0-6` | Number of pulses for reactive energy of cur dem interv (`MSB`)
-| | `7` | Not used
-| `008` | `0-7` | Inverted bits of _xor_ from previous octects
diff --git a/modbus/README.md b/modbus/README.md
deleted file mode 100644
index 07bdc45dc..000000000
--- a/modbus/README.md
+++ /dev/null
@@ -1,120 +0,0 @@
-# Modbus
-
-This directory contains a port of last open source version of FreeModBus (BSD
-license). The code in this directory is a subset of 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.
-
-Includes extensions to support RTU master mode by Armink(383016632@qq.com):
-https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32. Ported to NuttX by
-Darcy Gong.
-
-## Directory Structure / Relation to freemodbus-v1.5.0
-
-The original FreeModBus download consists of several directories. This subset
-takes only the contents of one directory, `modbus/`, that implements the core
-modbus logic and integrates that directory into the NuttX build system. The
-mapping between `freemodbus-v1.5.0` and the nuttx directories is shown below:
-
-```
---------------------------- ----------------------------------------------
-freemodbus-v1.5.0 NuttX
---------------------------- ----------------------------------------------
-All top level .txt files Not included
-demo/ Not included. This directory contains demo
- and porting code for a variety of platforms.
- The NuttX demo was ported from the LINUX
- demo in this directory and can be found at
- apps/examples/modbus.
-doc/ Not included. This directory contains Doxygen
- support files.
-modbus/ Included in its entirety in various locations:
- ascii apps/modbus/ascii
- functions apps/modbus/functions
- include apps/include/modbus
- mb.c apps/modbus/mb.c
- rtu apps/modbus/rtu
- tcp apps/modbus/tcp
-tools/ Not included. This directory contains Doxygen
- tools.
---------------------------- ----------------------------------------------
-```
-
-So this directory is equivalent to the `freemodbus-v1.5.0/modbus` directory
-except that (1) it may include modifications for the integration with NuttX and
-(2) the modbus/include directory was moved to `apps/modbus`.
-
-The original, unmodified `freemodbus-v1.5.0` was checked in as SVN revision
-`4960`.
-
-The other directory here, `nuttx/`, implements the NuttX modbus interface. It
-derives from the `freemodbus-v1.5.0/demo/LINUX/port` directory.
-
-## Configuration Options
-
-In the original `freemodbus-v1.5.0` release, the FreeModBus configuration was
-controlled by the header file `mbconfig.h`. This header file was eliminated
-(post revision `4960`) and the FreeModBus configuration was integrated into the
-NuttX configuration system.
-
-The NuttX-named configuration options that are available include:
-
-- `CONFIG_MODBUS` – General ModBus support.
-- `CONFIG_MB_ASCII_ENABLED` – Modbus ASCII support.
-- `CONFIG_MB_ASCII_MASTER` – Modbus ASCII master support.
-- `CONFIG_MB_RTU_ENABLED` – Modbus RTU support.
-- `CONFIG_MB_RTU_MASTER` – Modbus RTU master support.
-- `CONFIG_MB_TCP_ENABLED` – Modbus TCP support.
-- `CONFIG_MB_ASCII_TIMEOUT_SEC` – Character timeout value for Modbus ASCII. The
- character timeout value is not fixed for Modbus ASCII and is therefore a
- configuration option. It should be set to the maximum expected delay time of
- the network. Default: `1`.
-- `CONFIG_MB_ASCII_TIMEOUT_WAIT_BEFORE_SEND_MS` – Timeout to wait in ASCII prior
- to enabling transmitter. If defined the function calls `vMBPortSerialDelay`
- with the argument `CONFIG_MB_ASCII_TIMEOUT_WAIT_BEFORE_SEND_MS` to allow for a
- delay before the serial transmitter is enabled. This is required because some
- targets are so fast that there is no time between receiving and transmitting
- the frame. If the master is too slow with enabling its receiver then it will
- not receive the response correctly.
-- `CONFIG_MB_FUNC_HANDLERS_MAX` – Maximum number of Modbus functions codes the
- protocol stack should support. The maximum number of supported Modbus
- functions must be greater than the sum of all enabled functions in this file
- and custom function handlers. If set too small, adding more functions will
- fail.
-- `CONFIG_MB_FUNC_OTHER_REP_SLAVEID_BUF` – Number of bytes which should be
- allocated for the Report Slave ID command. This number limits the maximum size
- of the additional segment in the report slave id function. See
- `eMBSetSlaveID()` for more information on how to set this value. It is only
- used if `CONFIG_MB_FUNC_OTHER_REP_SLAVEID_ENABLED` is set to `1`.
-- `CONFIG_MB_FUNC_OTHER_REP_SLAVEID_ENABLED` – If the Report Slave ID function
- should be enabled.
-- `CONFIG_MB_FUNC_READ_INPUT_ENABLED` – If the Read Input Registers function
- should be enabled.
-- `CONFIG_MB_FUNC_READ_HOLDING_ENABLED` – If the Read Holding Registers function
- should be enabled.
-- `CONFIG_MB_FUNC_WRITE_HOLDING_ENABLED` – If the Write Single Register function
- should be enabled.
-- `CONFIG_MB_FUNC_WRITE_MULTIPLE_HOLDING_ENABLED` – If the Write Multiple
- registers function should be enabled.
-- `CONFIG_MB_FUNC_READ_COILS_ENABLED` – If the Read Coils function should be
- enabled.
-- `CONFIG_MB_FUNC_WRITE_COIL_ENABLED` – If the Write Coils function should be
- enabled.
-- `CONFIG_MB_FUNC_WRITE_MULTIPLE_COILS_ENABLED` – If the Write Multiple Coils
- function should be enabled.
-- `CONFIG_MB_FUNC_READ_DISCRETE_INPUTS_ENABLED` – If the Read Discrete Inputs
- function should be enabled.
-- `CONFIG_MB_FUNC_READWRITE_HOLDING_ENABLED` – If the Read/Write Multiple
- Registers function should be enabled.
-
-See also other serial settings, in particular:
-
-- `CONFIG_SERIAL_TERMIOS` – Serial driver supports `termios.h` interfaces
- If this is not defined, then the terminal settings (baud, parity, etc.)
- are not configurable at runtime.
-
-## Note
-
-The developer of FreeModBus, Christian Walter, is still developing Modbus
-libraries, although they are now commercial. See
-http://www.embedded-solutions.at/ for further information.
(nuttx-apps) 12/14: remove crypto/xxx/README.md. Migrated to Documentation/applications/crypto
Posted by xi...@apache.org.
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 a6d30540fbc415614d5e00d627b4dee0a9e35271
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:08:32 2023 +0200
remove crypto/xxx/README.md. Migrated to Documentation/applications/crypto
---
crypto/wolfssl/README.md | 92 ------------------------------------------------
1 file changed, 92 deletions(-)
diff --git a/crypto/wolfssl/README.md b/crypto/wolfssl/README.md
deleted file mode 100644
index a5709ce1b..000000000
--- a/crypto/wolfssl/README.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# NuttX + wolfSSL
-
-## Installation
-
-### Installing from nuttx-apps
-
-Skip to step 6
-
-### Installing from wolfssl
-
-1) Create working directory (e.g. ~/nuttxspace):
- ```
- $ cd ~
- $ mkdir nuttxspace
- ```
-2) Install dependencies:
- ```
- $ cd ~/nuttxspace
- $ sudo apt install -y bison flex gettext texinfo libncurses5-dev libncursesw5-dev gperf automake libtool pkg-config build-essential gperf genromfs libgmp-dev libmpc-dev libmpfr-dev libisl-dev binutils-dev libelf-dev libexpat-dev gcc-multilib g++-multilib picocom u-boot-tools util-linux
- $ sudo apt install -y kconfig-frontends
- $ sudo apt install -y gcc-arm-none-eabi binutils-arm-none-eabi
- ```
-3) Clone nuttx and nuttx-apps into working directory:
- ```
- $ git clone https://github.com/apache/nuttx.git nuttx
- $ git clone https://github.com/apache/nuttx-apps apps
- ```
-4) Copy this directory into the working directory applications:
- ```
- $ cp -R RTOS/nuttx/wolfssl ~/nuttxspace/apps/crypto/wolfssl
- ```
-5) Setup wolfSSL in preparation for the build, `WOLFSSL_DIR` must be the path to the original wolfssl repo:
- ```
- $ cd ~/nuttxspace/apps/crypto/wolfssl
- $ WOLFSSL_DIR=<path-to-wolfssl-repo> ./setup-wolfssl.sh
- ```
-6) Setup baseline NuttX configuration (board + NuttX Shell):
- ```
- $ cd ~/nuttxspace/nuttx
- $ ./tools/configure.sh -l <board>:nsh
- ```
- If you are using wolfSSL for TLS you should use the `netnsh` target if your board supports it
- ```
- $ ./tools/configure.sh -l <board>:netnsh
- ```
-> **EXAMPLES:**
-> - For NuttX Simulator: `$ ./tools/configure.sh sim:nsh`
-> - For BL602 (RISC-V): `$ ./tools/configure.sh -l bl602evb:nsh`
-> - For NUCLEO-L552ZE-Q (Cortex-M33): `$ ./tools/configure.sh -l nucleo-l552ze:nsh`
-> - For NUCLEO-H753ZI: `$ ./tools/configure.sh -l nucleo-h743zi:nsh`
-> - For NUCLEO-F756ZG: `./tools/configure.sh -l nucleo-144:f746-nsh`
-
-7) Start custom configuration system:
- ```
- $ make menuconfig
- ```
-8) Configure NuttX to enable the wolfSSL crypto library test applications:
- - From main menu select: **Application Configuration > Cryptography Library Support**
- - Enable and then select **wolfSSL SSL/TLS Cryptography Library**
- - Enable and then select **wolfSSL applications**
- - Enable applications:
- - **wolfCrypt Benchmark application**
- - **wolfCrypt Test application**
- - **wolfSSL client and server example**
- - Select Save from bottom menu, saving to `.config` file
- - Exit configuration tool
-
- If you are using wolfSSL for TLS you should use the `netnsh` target and should enable an NTP or some for of system time keeping so that wolfSSL has the current date to check certificates. You will also need to set the right networking settings for NuttX to connect to the internet.
-9) Build NuttX and wolfSSL:
- ```
- $ make
- ```
-10) Flash the target
- ### Simulator
- ./nuttx
- ### STM32 Targets (address may vary)
- STM32_Programmer_CLI -c port=swd -d ./nuttx.bin 0x08000000
-11) Connect to the target with a serial monitoring tool, the device on linux is usually /dev/ttyACM0 but it may vary
- - minicom -D /dev/ttyACM0
-12) Run the wolfcrypt benchmark and/or test in the NuttX Shell:
- ```
- nsh> wolfcrypt_test
- nsh> wolfcrypt_benchmark
- nsh> wolfssl_client_server
- ```
-## Notes
-- Developed using the following targets:
- - STM NUCLEO-L552ZE-Q (Cortex-M33)
- - STM NUCLEO-H753ZI
- - STM NUCLEO-F756ZG
- - DT-BL10 / BL602 (RISC-V)
- - NuttX simulator
(nuttx-apps) 06/14: remove netuitls/xxx/README.md. Migrated to Documentation/applications/netutils
Posted by xi...@apache.org.
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 008aba12d4c479e1a1c264aac31b529ca39cc304
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:06:41 2023 +0200
remove netuitls/xxx/README.md. Migrated to Documentation/applications/netutils
---
netutils/README.md | 138 --------------------------------------------
netutils/discover/README.md | 8 ---
netutils/ftpc/README.md | 81 --------------------------
netutils/iperf/README.md | 94 ------------------------------
netutils/netcat/README.md | 75 ------------------------
netutils/telnetd/README.md | 3 -
6 files changed, 399 deletions(-)
diff --git a/netutils/README.md b/netutils/README.md
deleted file mode 100644
index 3ddf9a93f..000000000
--- a/netutils/README.md
+++ /dev/null
@@ -1,138 +0,0 @@
-# Network Utilities
-
-## Contents
-
-- uIP Applications
-- Other Network Applications
-- Tips for Using Telnetd
-- Tips for Using DHCPC
-
-## uIP Applications
-
-This directory contains most of the network applications contained under the
-`uIP-1.0` apps directory. As the uIP `apps/README.md` says, these applications
-_are not all heavily tested_. These uIP-based apps include:
-
-- `dhcpc` – Dynamic Host Configuration Protocol (DHCP) client. See
- `apps/include/netutils/dhcpc.h` for interface information.
-
-- `smtp` – Simple Mail Transfer Protocol (SMTP) client. See
- `apps/include/netutils/smtp.h` for interface information.
-
-- `webclient` – HTTP web client. See `apps/include/netutils/webclient.h` for
- interface information.
-
-- `webserver` – HTTP web server. See `apps/include/netutils/httpd.h` for
- interface information.
-
-You may find additional information on these apps in the uIP forum accessible
-through: http://www.sics.se/~adam/uip/index.php/Main_Page. Some of these (such
-as the uIP web server) have grown some additional functionality due primarily to
-NuttX user contributions.
-
-## Other Network Applications
-
-Additional applications that were not part of uIP (but which are highly
-influenced by uIP) include:
-
-- `dhcpd` – Dynamic Host Configuration Protocol (DHCP) server. See
- `apps/include/netutils/dhcpd.h` for interface information.
-
-- `discover` – 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.
- (Contributed by Max Holtzberg).
-
-- `esp8266` – An ESP8266 networking layer contributed by Pierre-Noel Bouteville.
-
-- `json` – cJSON is an ultra-lightweight, portable, single-file,
- simple-as-can-be ANSI-C compliant JSON parser, under MIT license. Embeddable
- Lightweight XML-RPC Server discussed at
- http://www.drdobbs.com/web-development/an-embeddable-lightweight-xml-rpc-server/184405364.
-
- This code was taken from http://sourceforge.net/projects/cjson/ and adapted
- for NuttX by Darcy Gong.
-
-- `tftpc` – TFTP client. See `apps/include/netutils/tftp.h` for interface
- information.
-
-- `telnetc` – This is a port of libtelnet to NuttX. This is a public domain
- Telnet client library available from
- https://github.com/seanmiddleditch/libtelnet modified for use with NuttX.
- Original Authors: Sean Middleditch <se...@sourcemud.org>, Jack Kelly
- <en...@gmail.com> and Katherine Flavel <ka...@elide.org>
-
-- `telnetd` – TELNET server. This is the Telnet logic adapted from uIP and
- generalized for use as the front end to any shell. The telnet daemon creates
- sessions that are _wrapped_ as character devices and mapped to `stdin`,
- `stdout` and `stderr`. Now the telnet session can be inherited by spawned
- tasks.
-
-- `ftpc` – FTP client. See `apps/include/netutils/ftpc.h` for interface
- information.
-
-- `ftpd` – FTP server. See `apps/include/netutils/ftpd.h` for interface
- information.
-
-- `ntpclient` – This is a fragmentary NTP client. It neither well-tested nor
- mature nor complete at this point in time.
-
-- `thttpd` – This is a port of Jef Poskanzer's THTTPD HTPPD server. See
- http://acme.com/software/thttpd/ for general THTTPD information. See
- `apps/include/netutils/thttpd.h` for interface information. Applications using
- this `thttpd` will need to provide the following definitions in the
- `defconfig` file to select the appropriate `netutils` libraries:
-
- ```conf
- CONFIG_NETUTILS_NETLIB=y
- CONFIG_NETUTILS_THTTPD=y
- ```
-
-- `xmlrpc` – The Embeddable Lightweight XML-RPC Server discussed at
- http://www.drdobbs.com/web-development/an-embeddable-lightweight-xml-rpc-server/184405364
-
-- `ping` – This is an unfinished implementation of ping and ping6 using raw
- sockets. It is not yet hooked into the configuration or build systems.
-
- Current `ping`/`ping6` logic in NSH makes illegal calls into the OS in order
- to implement `ping`/`ping6`. One correct implementation would be to use raw
- sockets to implement `ping`/`ping6` as a user application. This is a first cut
- at such an implementation.
-
-## Tips for Using Telnetd
-
-Telnetd is set up to be the front end for a shell. The primary use of Telnetd in
-NuttX is to support the NuttShell (NSH) Telnet front end. See
-`apps/include/netutils/telnetd.h` for information about how to incorporate
-Telnetd into your custom applications.
-
-To enable and link the Telnetd daemon, you need to include the following in in
-your defconfig file:
-
-```conf
-CONFIG_NETUTILS_NETLIB=y
-CONFIG_NETUTILS_TELNETD=y
-```
-
-Also if the Telnet console is enabled, 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` – Since Telnetd is line oriented, line buffering
- is optimal.
-
-## Tips for Using DHCPC
-
-If you use DHCPC/D, then some special configuration network options are
-required. These include:
-
-- `CONFIG_NET=y`
-- `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. The client must be prepared to receive
- DHCP messages of up to `576` bytes (excluding Ethernet, IP or UDP headers and
- FCS). **Note**: Note that the actual MTU setting will depend upon the specific
- link protocol. Here Ethernet is indicated.
diff --git a/netutils/discover/README.md b/netutils/discover/README.md
deleted file mode 100644
index f5516a7e3..000000000
--- a/netutils/discover/README.md
+++ /dev/null
@@ -1,8 +0,0 @@
-# Network Utilities / `discover`
-
-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.
-
-See `nuttx/tools/discover.py` for a client example.
diff --git a/netutils/ftpc/README.md b/netutils/ftpc/README.md
deleted file mode 100644
index b84980720..000000000
--- a/netutils/ftpc/README.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# Network Utilities / `ftpc` FTP Client
-
-## FTP Commands
-
-- `ABOR` – abort a file transfer
-- `ACCT` – send account information
-- `APPE` – append to a remote file
-- `CDUP` – CWD to the parent of the current directory
-- `CWD` – change working directory
-- `DELE` – delete a remote file
-- `HELP` – return help on using the server
-- `LIST` – list remote files
-- `MDTM` – return the modification time of a file
-- `MKD` – make a remote directory
-- `MLSD` – Standardized directory listing (instead of `LIST`)
-- `MLST` – Standardized object listing (instead of `LIST`)
-- `MODE` – set transfer mode
-- `NLST` – name list of remote directory
-- `NOOP` – do nothing
-- `PASS` – send password
-- `PASV` – enter passive mode
-- `PORT` – open a data port
-- `PWD` – print working directory
-- `QUIT` – terminate the connection
-- `REIN` – reinitialize the connection
-- `RETR` – retrieve a remote file
-- `REST` – Sets the point at which a file transfer should start
-- `RMD` – remove a remote directory
-- `RNFR` – rename from
-- `RNTO` – rename to
-- `SITE` – site-specific commands
-- `SIZE` – return the size of a file
-- `STOR` – store a file on the remote host
-- `STOU` – store a file uniquely
-- `STRU` – set file transfer structure
-- `STAT` – return server status
-- `SYST` – return system type
-- `TYPE` – set transfer type
-- `USER` – send username
-
-## FTP Replies
-
-- `110` – Restart marker reply.
-- `120` – Service ready in nnn minutes.
-- `125` – Data connection already open; transfer starting.
-- `150` – File status okay; about to open data connection.
-- `200` – Command okay.
-- `202` – Command not implemented, superfluous at this site.
-- `211` – System status, or system help reply.
-- `212` – Directory status.
-- `213` – File status.
-- `214` – Help message.
-- `215` – NAME system type.
-- `220` – Service ready for new user.
-- `221` – Service closing control connection.
-- `225` – Data connection open; no transfer in progress.
-- `226` – Closing data connection.
-- `227` – Entering Passive Mode (`h1`, `h2`, `h3`, `h4`, `p1`, `p2`).
-- `230` – User logged in, proceed.
-- `250` – Requested file action okay, completed.
-- `257` – `PATHNAME` created.
-- `331` – User name okay, need password.
-- `332` – Need account for login.
-- `350` – Requested file action pending further information.
-- `421` – Service not available, closing control connection.
-- `425` – Can't open data connection.
-- `426` – Connection closed; transfer aborted.
-- `450` – Requested file action not taken.
-- `451` – Requested action aborted: local error in processing.
-- `452` – Requested action not taken.
-- `500` – Syntax error, command unrecognized.
-- `501` – Syntax error in parameters or arguments.
-- `502` – Command not implemented.
-- `503` – Bad sequence of commands.
-- `504` – Command not implemented for that parameter.
-- `530` – Not logged in.
-- `532` – Need account for storing files.
-- `550` – Requested action not taken.
-- `551` – Requested action aborted: page type unknown.
-- `552` – Requested file action aborted.
-- `553` – Requested action not taken.
diff --git a/netutils/iperf/README.md b/netutils/iperf/README.md
deleted file mode 100644
index 89d95feb1..000000000
--- a/netutils/iperf/README.md
+++ /dev/null
@@ -1,94 +0,0 @@
-Overview
-================================================================
-
-This is a NuttX port of the ESP-IDF iperf example. [1]
-
-It doesn't support all features in standard iperf.
-It's supposed to be compatible with iperf version 2.x. [2]
-
-[1] https://github.com/espressif/esp-idf/tree/master/examples/wifi/iperf
-[2] https://sourceforge.net/projects/iperf2/
-
-Configuring NuttX to use your Wireless Router (aka Access Point)
-================================================================
-
- Since you are already in the root of NuttX/ repository, execute
- make menuconfig to define your Wireless Router and your password:
-
- $ make menuconfig
-
- Browser the menus this way:
-
- Application Configuration --->
- Network Utilities --->
- Networking Configuration --->
- WAPI Configuration --->
- (myApSSID) SSID
- (mySSIDpassphrase) Passprhase
-
- Replace the SSID from myApSSID with your wireless router name and
- the Passprhase with your WiFi password.
-
- Exit and save your configuration.
-
-iperf Test Example
-===================================
-
-To set up, do `make menuconfig` and select the Apps > netutils > iperf example. 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.
-
-If you are using a wireless network card, you must first connect to the router:
-
-On host:
-
- $ iperf -s -p 5471 -i 1 -w 416K
- ------------------------------------------------------------
- Server listening on TCP port 5471
- TCP window size: 416 KByte
- ------------------------------------------------------------
-
-On NuttX:
-
- nsh> iperf -c 192.168.1.181 -p 5471 -i 1 -t 10
- mode=tcp-client sip=192.168.1.198:5001, dip=192.168.1.181:5471, interval=1, time=10
-
- Interval Bandwidth
-
- 0- 1 sec, 0.39 Mbits/sec
- 1- 2 sec, 0.26 Mbits/sec
- 2- 3 sec, 0.39 Mbits/sec
- 3- 4 sec, 0.26 Mbits/sec
- 4- 5 sec, 0.26 Mbits/sec
- 5- 6 sec, 0.26 Mbits/sec
- 6- 7 sec, 0.26 Mbits/sec
- 7- 8 sec, 0.26 Mbits/sec
- 8- 9 sec, 0.26 Mbits/sec
- 9- 10 sec, 0.26 Mbits/sec
- 0- 10 sec, 0.28 Mbits/sec
-
-Now on the host you should see something like:
-
- $ iperf -s -p 5471 -i 1 -w 416K
- ------------------------------------------------------------
- Server listening on TCP port 5471
- TCP window size: 416 KByte
- ------------------------------------------------------------
- [ 5] local 192.168.1.181 port 5471 connected with 192.168.1.198 port 4210
- [ 5] 0.0- 1.0 sec 60.8 KBytes 498 Kbits/sec
- [ 5] 1.0- 2.0 sec 34.9 KBytes 286 Kbits/sec
- [ 5] 2.0- 3.0 sec 33.7 KBytes 276 Kbits/sec
- [ 5] 3.0- 4.0 sec 33.4 KBytes 274 Kbits/sec
- [ 5] 4.0- 5.0 sec 32.0 KBytes 262 Kbits/sec
- [ 5] 5.0- 6.0 sec 32.0 KBytes 262 Kbits/sec
- [ 5] 6.0- 7.0 sec 33.4 KBytes 274 Kbits/sec
- [ 5] 7.0- 8.0 sec 32.0 KBytes 262 Kbits/sec
- [ 5] 8.0- 9.0 sec 32.0 KBytes 262 Kbits/sec
- [ 5] 9.0-10.0 sec 33.4 KBytes 274 Kbits/sec
- [ 5] 0.0-10.3 sec 368 KBytes 292 Kbits/sec
-
-
-This will tell you the link speed in Kbits/sec – kilobits per second. If you want kilobytes, divide by 8.
-
diff --git a/netutils/netcat/README.md b/netutils/netcat/README.md
deleted file mode 100644
index 044a700f7..000000000
--- a/netutils/netcat/README.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# Network Utilities / `netcat` tool
-
-netcat TCP/IP Swiss army knife
-
-It was re-implemented from scratch for NuttX
-
-
-## DEMO ##
-
-[](
-https://mastodon.social/@rzr/105225153152922220#weboftwins-osvehicle-2020-rzr
-"weboftwins-osvehicle-2020-rzr")
-
- * https://purl.org/rzr/weboftwins
-
-## USAGE ##
-
-Usage is straightforward:
-
- nsh> help ; netcat
- Usage: netcat [-l] [destination] [port] [file]
-
- nsh> renew eth0 ; ifconfig
-
- eth0 Link encap:Ethernet HWaddr 52:13:FF:FF:FF:FF at UP
- inet addr:192.168.1.42 DRaddr:192.168.1.254 Mask:255.255.255.0
-
-In the following examples, following configuration is used:
-
-- target (nuttx) is 192.168.1.42
-- host (linux) is 192.168.1.55
-
-### Server ###
-
-As a server on NuttX and Linux's netcat as client
-
- nsh> netcat -l
-
- sh> cat /proc/version | netcat 192.168.1.42 31337
- Linux ...
-
-Default port is 31337 but it can changed.
-
- nsh> renew eth0 ; ifconfig ; netcat -l
- log: net: listening on :31337
- Linux ...
-
-### Client ###
-
-Start Server on GNU/Linux:
-
- sh> ip addr show && netcat -l 31337
-
-Client side on nuttx, we create
-
- nsh> help ; renew eth0 ; ifconfig
- nsh> netcat 192.168.1.55 31337 /proc/version
-
-### Using pipes ###
-
- mkfifo /dev/fifo
- netcat 192.168.1.55 31337 /proc/fifo
- help > /dev/fifo
-
- fxos8700cq > /dev/fifo &
- fxos8700cq [7:100]
- netcat 192.168.1.55 31337 /dev/fifo
-
-### Resources ###
-
- * <https://en.wikipedia.org/wiki/Netcat>
- * <https://purl.org/rzr/weboftwins>
- * <https://github.com/rzr/aframe-smart-home/issues/3>
\ No newline at end of file
diff --git a/netutils/telnetd/README.md b/netutils/telnetd/README.md
deleted file mode 100644
index 30135542e..000000000
--- a/netutils/telnetd/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Network Utilities / `telnetd` Telnet Daemon
-
-This directly contains a generic Telnet daemon.
(nuttx-apps) 05/14: remove graphics/xxx/README.md. Migrated to Documentation/applications/graphics
Posted by xi...@apache.org.
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 d313bbad9c7093ca24c0fe0d856f05c0dd3aa0a7
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:06:31 2023 +0200
remove graphics/xxx/README.md. Migrated to Documentation/applications/graphics
---
graphics/lvgl/README.md | 23 --
graphics/nxwidgets/Doxygen/README.md | 68 ------
graphics/nxwidgets/README.md | 68 ------
graphics/nxwidgets/UnitTests/README.md | 259 ----------------------
graphics/nxwm/Doxygen/README.md | 68 ------
graphics/nxwm/README.md | 27 ---
graphics/tiff/README.md | 12 -
graphics/twm4nx/README.md | 386 ---------------------------------
8 files changed, 911 deletions(-)
diff --git a/graphics/lvgl/README.md b/graphics/lvgl/README.md
deleted file mode 100644
index a3c846a8d..000000000
--- a/graphics/lvgl/README.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Graphics / `lvgl` LVGL
-
-## Usage
-
-Import with `#include <lvgl/lvgl.h>` or `#include <lvgl.h>`.
-
-Upstream example ported to NuttX is present at `examples/lvgldemo`.
-
-LVGL can be used with framebuffer device. To find example boards with this
-preconfigured, search for `CONFIG_GRAPHICS_LVGL=y` in `defconfig` files. All of
-them have also `CONFIG_VIDEO_FB=y` present.
-
-As a second option, LVGL can talk to a display driver and explicitly draw line
-by line. For this case, there is no preconfigured board present. Go to _Porting_
-section of upstream documentation for more hints.
-
-## Resources
-
-- [API documentation with examples](https://docs.lvgl.io/latest/en/html/index.html)
-- [GitHub / LVGL / LVGL library](https://github.com/lvgl/lvgl)
-- [GitHub / LVGL / Examples, tutorials, applications](https://github.com/lvgl/lv_examples)
-- [GitHub / LVGL / Desktop simulator](https://github.com/lvgl/lv_sim_eclipse_sdl)
-- [GitHub / LVGL / Web simulator](https://github.com/lvgl/lv_sim_emscripten)
diff --git a/graphics/nxwidgets/Doxygen/README.md b/graphics/nxwidgets/Doxygen/README.md
deleted file mode 100644
index dc38ed5da..000000000
--- a/graphics/nxwidgets/Doxygen/README.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# Graphics / `nxwidgets` NXWidgets / Doxygen
-
-This directory contains the documentation automatically generated by Doxygen.
-
-## Contents
-
-- Installing the necessary packages in Ubuntu
-- Generating documentation
-- References
-
-## Installing the Necessary Packages in Ubuntu
-
-1. Install the following packages.
-
- ```bash
- $ sudo aptitude install doxygen doxygen-doc doxygen-gui dot2tex graphviz
- ```
-
-2. (Optional) Install Doxygen from the latest sourcode.
-
- The Ubuntu package is outdated. The newer the version of Doxygen, the better
- the documentation looks.
-
- Place yourself in some temporary folder where you can download the source,
- and run [1]:
-
- ```bash
- $ svn co https://doxygen.svn.sourceforge.net/svnroot/doxygen/trunk doxygen-svn
- $ cd doxygen-svn
- $ ./configure
- $ make
- $ make install
- ```
-
-## Generating Documentation
-
-Two ways described here:
-
-1. Use the provided `gendoc.sh` script.
-
- ```bash
- trunk/NXWidgets/Doxygen/gendoc.sh
- ```
-
- The script only needs the argument to the absolute path where to place the
- generated documentation. I.e.:
-
- ```bash
- $ cd /path/to/nuttx/trunk/NXWidgets/Doxygen/
- $ mkdir doc
- $ ./gendoc.sh $PWD/doc
- ```
-
-2. Using the `Doxyfile` directly:
-
- The file `Doxyfile` contains the configuration of the Doxygen settings for
- the run, edit only if necessary.
-
- To generate the documentation type:
-
- ```bash
- $ cd /path/to/nuttx/trunk/NXWidgets/Doxygen/
- $ doxygen Doxyfile
- ```
-
-## References
-
-[1] http://www.stack.nl/~dimitri/doxygen/download.html
diff --git a/graphics/nxwidgets/README.md b/graphics/nxwidgets/README.md
deleted file mode 100644
index 5fc93f371..000000000
--- a/graphics/nxwidgets/README.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# Graphics / `nxwidgets` NXWidgets
-
-In order to better support NuttX based platforms, a special graphical user
-interface has been created called NXWidgets. NXWidgets is written in C++ and
-integrates seamlessly with the NuttX NX graphics subsystem in order to provide
-graphic objects, or _widgets_, in the NX Graphics Subsystem
-
-Some of the features of NXWidgets include:
-
-- Conservative C++
-
- NXWidgets is written entirely in C++ but using only selected _embedded
- friendly_ C++ constructs that are fully supported under NuttX. No additional
- C++ support libraries are required.
-
-- NX Integration
-
- NXWidgets integrate seamlessly with the NX graphics system. Think of the X
- server under Linux – the NX graphics system is like a tiny X server that
- provides windowing under NuttX. By adding NXWidgets, you can support graphics
- objects like buttons and text boxes in the NX windows and toolbars.
-
-- Small Footprint
-
- NXWidgets is tailored for use MCUs in embedded applications. It is ideally
- suited for mid- and upper-range of most MCU families. A complete NXWidgets is
- possible in as little as 40Kb of FLASH and maybe 4Kb of SRAM.
-
-- Output Devices
-
- NXWidgets will work on the high-end frame buffer devices as well as on LCDs
- connected via serial or parallel ports to a small MCU.
-
-- Input Devices
-
- NXWidgets will accept position and selection inputs from a mouse or a
- touchscreen. It will also support character input from a keyboard such as a
- USB keyboard. NXWidgets supports on very special widget called `CKeypad` that
- will provide keyboard input via an on-screen keypad that can be operated via
- mouse or touchscreen inputs.
-
-- Many Graphic Objects
-
- Some of the graphic objects supported by NXWidgets include labels, buttons,
- text boxes, button arrays, check boxes, cycle buttons, images, sliders,
- scrollable list boxes, progress bars, and more.
-
-**Note**: Many of the fundamental classed in NxWidgets derive from the Antony
-Dzeryn's _Woopsi_ project: http://woopsi.org/ which also has a BSD style
-license. See the `COPYING` file for details.
-
-## Directory Structure
-
-- `Kconfig`
-
- This is a `Kconfig` file that should be provided at `apps/NxWidgets/Kconfig`.
- When copied to that location, it will be used by the NuttX configuration
- systems to configure settings for NxWidgets and NxWM
-
-- `nxwidgets`
-
- The source code, header files, and build environment for NxWidgets is provided
- in this directory.
-
-- `UnitTests`
-
- Provides a collection of unit-level tests for many of the individual widgets
- provided by `nxwidgets`.
diff --git a/graphics/nxwidgets/UnitTests/README.md b/graphics/nxwidgets/UnitTests/README.md
deleted file mode 100644
index b96875485..000000000
--- a/graphics/nxwidgets/UnitTests/README.md
+++ /dev/null
@@ -1,259 +0,0 @@
-# Graphics / NXWidgets / Unit Tests
-
-This directory contains a collection of Unit Tests that can be used to verify
-NXWidgets.:
-
-## Contents
-
-**Installing and Building the Unit Tests**
-
-1. Setup NuttX
- 1. Configure NuttX
- 2. Enable C++ Support
- 3. Enable Debug Options
- 4. Special configuration requirements for the nxwm unit test
- 5. Other `.config` file changes – NSH configurations only
- 6. Other `.config` file changes – NON-NSH configurations only
-2. Adjust the Stack Size
-3. Build NuttX including the unit test and the NXWidgets library
-
-**Work-Arounds**
-
-1. Build Issues
-
-**Unit Test Directories**
-
-## Installing and Building the Unit Tests
-
-1. Setup NuttX
-
- 1. Configure NuttX
-
- Configure NuttX to run one of the target configurations. For example,
- let's assume that you are using the `sim/nsh2` configuration. The
- `sim/nsh2` configuration was specially created for use NXWidgets on the
- simulation platform. A similar, special configuration `stm3210e-eval/nsh2`
- is also for the `STM3210E-EVAL` available. However, the unit test can be
- run on other configurations (see steps d and e below).
-
- **Note**: There are some other special configurationsrecommended for
- unit-leveling testing of NxWM because the configuration is more complex in
- that case. These are:
-
- 1) `sim/nxwmm`, or the simulated platform (no touchscreen), and
- 2) `stm3240g-evel`, for the `STM3240G-EVAL` board (with the STMPE11
- touchscreen)
-
- We will assume the `sim/nsh2` configuration in this discussion. The
- `sim/nsh2` configuration is installed as follows:
-
- ```bash
- cd <nuttx-directory-path>
- make distclean
- tools/configure.sh sim:nsh2
- ```
-
- Where:
-
- `<nuttx-directory-path>` is the full, absolute path to the NuttX build
- directory
-
- If you are using the `sim/nsh2` or `stm3210e-eval` configurations, then
- skip to step 2 (Hmmm.. better check 1d) too).
-
- There may be certain requirements for the configuration that you select...
- for example, certain widget tests may require touchscreen support or
- special font selections. These test-specific requirements are addressed
- below under _Unit Test Directories_
-
- 2. Enable C++ Support
-
- If you are not using the `sim/nsh2` or `stm3210e-eval`, you will need to
- add the following definitions to the NuttX configuration at
- `nuttx/.config` to enable C++ support:
-
- ```conf
- CONFIG_HAVE_CXX=y
- ```
-
- Check first, some configurations already have C++ support enabled (As of
- this writing **ONLY** the `sim/nsh2` and `stm321-e-eval` configurations
- have C++ support pre-enabled).
-
- 3. Enable Debug Options
-
- If you are running on a simulated target, then you might also want to
- enable debug symbols:
-
- ```conf
- CONFIG_DEBUG_SYMBOLS=y
- ```
-
- Then you can run the simulation using GDB or DDD which is a very powerful
- debugging environment!
-
- 4. Special configuration requirements for the nxwm unit test.
-
- ```conf
- CONFIG_NXTERM=y
- ```
-
- 5. Other `.config` file changes – NSH configurations only.
-
- If the configuration that you are using supports NSH and NSH built-in
- tasks then all is well. If it is an NSH configuration, then you will have
- to define the following in your `nuttx/.config` file as well (if it is not
- already defined):
-
- ```conf
- CONFIG_NSH_BUILTIN_APPS=y
- ```
-
- `sim/nsh2` and `stm3210e-eval/nsh2` already has this setting. You do not
- need to change anything further in the `nuttx/.config` file if you are
- using either of these configurations.
-
- 6. Other `.config` file changes – NON-NSH configurations only.
-
- Entry Point. You will need to set the entry point in the .config file. For
- NSH configurations, the entry point will always be `nsh_main` and you will
- see that setting like:
-
- ```conf
- CONFIG_INIT_ENTRYPOINT="nsh_main"
- ```
-
- If you are not using in NSH, then each unit test has a unique entry point.
- That entry point is the name of the unit test directory in all lower case
- plus the suffix `_main`. So, for example, the correct entry for the
- `UnitTests/CButton` would be:
-
- ```conf
- CONFIG_INIT_ENTRYPOINT="cbutton_main"
- ```
-
- And the correct entry point for `UnitTests/nxwm` would be:
-
- ```conf
- CONFIG_INIT_ENTRYPOINT="nxwm_main"
- ```
-
- etc.
-
- For non-NSH configurations (such as the `sim/touchscreen`) you will have
- to remove the configuration setting that provided the `main` function so
- that you use the `main` in the unit test code instead. So, for example,
- with the `sim/touchscreen` configuration you need to remove the following
- from the NuttX configuration file (`.config`):
-
- ```conf
- CONFIG_EXAMPLES_TOUSCHCREEN=y ## REMOVE (provided "tc_main")
- ```
-
-2. Adjust the Stack Size
-
- If using an simulation configuration (like `sim/nsh2`) and your unit test
- uses X11 as its display device, then you would have to increase the size of
- unit test stack as described below under _Stack Size Issues with the X11
- Simulation_.
-
-3. Build NuttX including the unit test and the NXWidgets library
-
- ```bash
- cd <nuttx-directory-path>
- . ./setenv.sh
- make
- ```
-
-## Work-Arounds
-
-### Build Issues
-
-1. I have seen this error on Cygwin building C++ code:
-
- ```
- LD: nuttx.rel
- ld: skipping incompatible /home/patacongo/projects/nuttx/nuttx/trunk/nuttx/libxx//liblibxx.a when searching for -llibxx
- ld: cannot find -llibxx
- ```
-
- The problem seems to be caused because `gcc` build code for 32-bit mode and
- `g++` builds code for 64-bit mode. Add the `-m32` option to the `g++` command
- line seems to fix the problem. In `Make.defs`:
-
- ```makefile
- CXXFLAGS = -m32 $(ARCHWARNINGSXX) $(ARCHOPTIMIZATION) \
- $(ARCHCXXFLAGS) $(ARCHINCLUDESXX) $(ARCHDEFINES) $(EXTRADEFINES) -pipe
- ```
-
-2. Stack Size Issues with the X11 Simulation
-
- When you run the NuttX simulation, it uses stacks allocated by NuttX from the
- NuttX heap. The memory management model is exactly the same in the simulation
- as it is real, target system. This is good because this produces a higher
- fidelity simulation.
-
- However, when the simulation calls into Linux/Cygwin libraries, it will still
- use these small simulation stacks. This happens, for example, when you call
- into the system to get and put characters to the console window or when you
- make x11 calls into the system. The programming model within those libraries
- will assume a Linux/Cygwin environment where the stack size grows dynamically
-
- As a consequence, those system libraries may allocate large data structures
- on the stack and overflow the small NuttX stacks. X11, in particular,
- requires large stacks. If you are using X11 in the simulation, make sure that
- you set aside a "lot" of stack for the X11 system calls (maybe 8 or 16Kb).
- The stack size for the thread that begins with user start is controlled by
- the configuration setting `CONFIG_INIT_STACKSIZE`; you may need to
- increase this value to larger number to survive the X11 system calls.
-
- If you are running X11 applications as NSH add-on programs, then the stack
- size of the add-on program is controlled in another way. Here are the steps
- for increasing the stack size in that case:
-
- ```bash
- cd ../apps/namedapps # Go to the namedapps directory
- vi namedapps_list.h # Edit this file and increase the stack size of the add-on
- rm .built *.o # This will force the namedapps logic to rebuild
- ```
-
-## Unit Tests
-
-The following provide simple unit tests for each of the NXWidgets. In addition,
-these unit tests provide examples for the use of each widget type.
-
-- `CButton`
- - Exercises the `CButton` widget.
- - Depends on `CLabel`.
-- `CButtonArray`
- - Exercises the `CButtonArray` widget.
-- `CCheckBox`
- - Exercises the `CCheckBox` widget.
- - Depends on `CLabel` and `CButton`.
-- `CGlyphButton`
- - Exercises the `CGlyphButton` widget.
- - Depends on `CLabel` and `CButton`.
-- `CImage`
- - Exercises the `CImage` widget.
-- `CLabel`
- - Exercises the `CLabel` widget.
-- `CProgressBar`
- - Exercises the `CProgressBar` widget.
-- `CRadioButton`
- - Exercises the `CRadioButton` and `CRadioButtonGroup` widgets.
- - Depends on `CLabel` and `CButton`.
-- `CScrollBarHorizontal`
- - Exercises the `ScrollbarHorizontal`.
- - Depends on `CSliderHorizontal` and `CGlyphButton`.
-- `CScrollBarVertical`
- - Exercises the `ScrollbarHorizontal`.
- - Depends on `CSliderVertical` and `CGlyphButton`.
-- `CSliderHorizontal`
- - Exercises the `CSliderHorizontal`.
- - Depends on `CSliderHorizontalGrip`.
-- `CSliderVertical`
- - Exercises the `CSliderVertical`.
- - Depends on `CSliderVerticalGrip`.
-- `CTextBox`
- - Exercises the `CTextBox` widget.
- - Depends on `CLabel`.
diff --git a/graphics/nxwm/Doxygen/README.md b/graphics/nxwm/Doxygen/README.md
deleted file mode 100644
index cf4436347..000000000
--- a/graphics/nxwm/Doxygen/README.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# Graphics / `nxwm` NxWM / Doxygen
-
-This directory contains the documentation automatically generated by Doxygen.
-
-## Contents
-
-- Installing the necessary packages in Ubuntu
-- Generating documentation
-- References
-
-## Installing the necessary packages in Ubuntu
-
-1. Install the following packages.
-
- ```bash
- $ sudo aptitude install doxygen doxygen-doc doxygen-gui dot2tex graphviz
- ```
-
-2. (Optional) Install Doxygen from the latest sourcode.
-
- The Ubuntu package is outdated. The newer the version of Doxygen, the better
- the documentation looks.
-
- Place yourself in some temporary folder where you can download the source,
- and run [1]:
-
- ```bash
- $ svn co https://doxygen.svn.sourceforge.net/svnroot/doxygen/trunk doxygen-svn
- $ cd doxygen-svn
- $ ./configure
- $ make
- $ make install
- ```
-
-## Generating documentation
-
-Two ways described here:
-
-1. Use the provided `gendoc.sh` script.
-
- ```bash
- trunk/NXWidgets/Doxygen/gendoc.sh
- ```
-
- The script only needs the argument to the absolute path where to place the
- generated documentation. I.e.:
-
- ```bash
- $ cd /path/to/nuttx/trunk/NXWidgets/Doxygen/
- $ mkdir doc
- $ ./gendoc.sh $PWD/doc
- ```
-
-2. Using the `Doxyfile` directly:
-
- The file `Doxyfile` contains the configuration of the Doxygen settings for
- the run, edit only if necessary.
-
- To generate the documentation type:
-
- ```bash
- $ cd /path/to/nuttx/trunk/NXWidgets/Doxygen/
- $ doxygen Doxyfile
- ```
-
-## References
-
-[1] http://www.stack.nl/~dimitri/doxygen/download.html
diff --git a/graphics/nxwm/README.md b/graphics/nxwm/README.md
deleted file mode 100644
index 2578a46f2..000000000
--- a/graphics/nxwm/README.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Graphics / `nxwm` NxWM
-
-This directory holds a tiny desktop for small embedded devices with a
-touchscreen,. NxWM. NxWM is true multiple window manager but only one window is
-displayed at a time. This simplification helps performance on LCD based products
-(in the same way that a tiled window manager helps) and also makes the best use
-of small displays. It is awkward from a human factors point-of-view trying to
-manage multiple windows on a small display.
-
-The window manager consists of a task bar with icons representing the running
-tasks. If you touch the task's icon, it comes to the top. Each window has a
-toolbar with (1) a title, (2) a minimize button, and (3) a stop application
-button using the standard icons for these things.
-
-There is always a start window that is available in the task bar. When you touch
-the start window icon, it brings up the start window containing icons
-representing all of the available applications. If you touch an icon in the
-start window, it will be started and added to the task bar.
-
-There is a base class that defines an add-on application and an interface that
-supports incorporation of new application. The only application that is provided
-is NxTerm. This is an NSH session running in a window. You should be able to
-select the NX icon in the start menu and create as many NSH sessions in windows
-as you want. (keybard input still comes through serial).
-
-Note 1: NwWM requires `NuttX-7.19` or above to work with the current
-`NxWidgets-1.18` release.
diff --git a/graphics/tiff/README.md b/graphics/tiff/README.md
deleted file mode 100644
index dd4620715..000000000
--- a/graphics/tiff/README.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Graphics / `tiff` TIFF Creation Library
-
-This directory contains a library that can be used to create TIFF image files.
-This file was created for the purpose of supporting screen dumps from an LCD.
-Howeve, the logic is general and could be used for most any purpose.
-
-The only usage documentation is in the (rather extensive) comments in the file
-`apps/include/tiff.h`.
-
-## Unit Test
-
-See `apps/examples/tiff`.
diff --git a/graphics/twm4nx/README.md b/graphics/twm4nx/README.md
deleted file mode 100644
index 5c594b94d..000000000
--- a/graphics/twm4nx/README.md
+++ /dev/null
@@ -1,386 +0,0 @@
-# Graphics / `twm4nx` Tab Window Manager (TWM)
-
-Twm4Nx is a port of twm, Tab Window Manager (or Tom's Window Manager) version
-`1.0.10` to NuttX NX windows server. No, a port is not the right word. It is a
-re-design of TWM from the inside out to work with the NuttX NX server. The name
-Twm4Nx reflects this legacy. But Twm4Nx is more a homage to TWM than a port of
-TWM.
-
-The original TWM was based on X11 which provides a rich set of features. TWM
-provided titlebars, shaped windows, several forms of icon management,
-user-defined macro functions, click-to-type and pointer-driven keyboard focus,
-graphic contexts, and user-specified key and pointer button bindings, etc.
-
-Twm4Nx, on the other hand is based on the NuttX NX server which provides
-comparatively minimal support. Additional drawing support comes from the NuttX
-NxWidgets library (which necessitated the change to C++).
-
-Twm4Nx is greatly stripped down and targeted on small embedded systems with
-minimal resources. For example, no assumption is made about the availability of
-a file system; no `.twmrc` file is used. Bitmaps are not used (other than for
-fonts).
-
-The TWM license is, I believe compatible with the BSD license used by NuttX. The
-origin TWM license required notice of copyrights within each file and a full
-copy of the original license which you can find in the `COPYING` file. within
-this directory.
-
-## Status
-
-### Progress
-
-- `2019-04-28` This port was brutal. Much TWM logic was removed because it
- depended on X11 features (or just because I could not understand how to use
- it). The replacement logic is only mostly in place but more needs to be done
- to have a complete system (hence, it is marked `EXPERIMENTAL`). The kinds of
- things that need to done are:
-
- 1. Right click should bring up a window list (like the icon manager???)
- 2. For TWM-like behavior, a window frame and toolbar should be highlighted
- when the window has focus.
- 3. A right click on the toolbar should bring up a window-specific menu.
-
-- `2019-05-02` Some testing progress. The system comes up, connects to and
- initializes the VNC window. For some reason, the VNC client breaks the
- connection. The server is no longer connected so Twm4Nx constipates and and
- eventually hangs.
-
-- `2019-05-08` I abandoned the VNC interface and found that things are much
- better using a direct, hardware framebuffer. The background comes up properly
- and the Icon Manager appears properly in the upper right hand corner. The Icon
- Manager Window can be iconified or de-iconified. The Icon Manager window can
- be grabbed by the toolbar title and moved about on the window (the movement is
- not very smooth on the particular hardware that I am working with).
-
-- `2019-05-10` A left click on the background brings up the main menu. At
- present there are only two options: _Desktop_ which will iconify all windows
- and _Twm4Nx Icon Manager_ which will de-iconify and/or raise the Icon Manager
- window to the top of the hierarchy. That latter option is only meaningful when
- the desktop is very crowded.
-
-- `2019-05-13` Added the NxTerm application. If enabled via
- `CONFIG_TWM4XN_NXTERM`, there will now be a _NuttShell_ entry in the Main
- Menu. When pressed, this will bring up an NSH session in a Twm4Nx window.
-
-- `2019-05-14` We can now move an icon on the desktop. Includes logic to avoid
- collisions with other icons and with the background image. That later is an
- issue. The background image image widget needs to be removed; it can occlude a
- desktop icon. We need to paint the image directly on the background without
- the use of a widget.
-
-- `2019-05-15` Resizing now seems to work correctly in Twm4Nx.
-
-- `2019-05-20` Calibration screen is now in place.
-
-- `2019-05-21` A `CONTEMPORARY` theme was added. Still has a few glitches.
-
-- `2019-06-01` A retro, emulated segment LCD clock is now in place.
-
-## How To
-
-### Icon Manager
-
-- At start up, only the Icon Manager window is shown. The Icon Manager is a TWM
- alternative to more common desktop icons. Currently Twm4Nx supports both
- desktop icons and the Icon Manager.
-
- Whenever a new application is started from the Main Menu, its name shows up in
- the Icon Manager. Selecting the name will either de-iconify the window, or
- just raise it to the top of the display.
-
-### Main Menu:
-
-- A touch/click at any open location on the background (except the image at the
- center or on another icon) will bring up the Main Menu. Options:
- - Desktop. Iconify all windows and show the desktop
- - Twm4Nx Icom Manager. De-iconify and/or raise the Icon Manager to the top of
- the display.
- - Calibration. Perform touchscreen re-calibration.
- - Clock. Start and instance of clock in the window. The uses the the retro,
- LCD emulation of `apps/graphics/slcd`.
- - NuttShell. Start and instance of NSH running in an NxTerm.
-- All windows close after the terminal menu option is selected.
-
-### Window Toolbar
-
-- Most windows have a toolbar at the top. It is optional but used in most
- windows.
-- The toolbar contains window title and from zero to 4 buttons:
- - Right side: A menu button may be presented. The menu button is not used by
- anything in the current implementation and is always suppressed
- - Left side: The far left is (1) the terminate button (if present). If
- present, it will close window when selected. Not all windows can be closed.
- You can't close the Icon Manager or menu windows, for example. Then (2) a
- resize button. If presented and is selected, then the resize sequence
- described below it started. This may the be preceded by a minimize button
- that iconifies the window.
-
-### Moving a Window:
-
-- Grab the title in the toolbar and move the window to the desired position.
-
-### Resizing a Window:
-
-- A window must have the green resize button with the square or it cannot be
- resized.
-- Press resize button. A small window should pop-up in the upper left hand
- corner showing the current window size.
-- Touch anywhere in window (not the toolbar) and slide your finger. The resize
- window will show the new size but there will be no other update to the
- display. It is thought that continuous size updates would overwhelm lower end
- MCUs. Movements support include:
- - Move toward the right increases the width of the window
- - Move toward the left decreases the width of the window
- - Move toward the bottom increases the height of the window
- - Move toward the top decreases the height of the Window
- - Other moves will affect both the height and width of the window.
-- **Note**: While resizing, non-critical events from all other windows are
- ignored.
-
-### Themes
-
-- There are two themes support by the configuration system:
- - `CONFIG_TWM4NX_CLASSIC` – Strong bordered windows with dark primary colors.
- Reminiscent of Windows 98.
- - `CONFIG_TWM4NX_CONTEMPORARY` – Border-less windows in pastel shades for a
- more contemporary look.
-
-## Issues:
-
-`2019-05-16` Twm4Nx is in a very complete state but only at perhaps _alpha_ in
-its maturity. You should expect to see some undocumented problems. If you see
-such problems and can describe a sequence to actions to reproduce the problem,
-let me know and I will try to resolve the problems.
-
-Here are all known issues and features that are missing:
-
-TWM Compatibilities Issues:
-1. Resizing works a little differently in Twm4Nx.
-2. Right click should bring up a window list
-3. For TWM-like behavior, a window frame and toolbar should be highlighted when
- the window has focus.
-4. A right click on the toolbar should bring up a window-specific menu.
-
-There are no near-term plans to address these compatibility issues.
-
-Other issues/bugs. All-in-all, I would say that Twm4Nx is maturing well and is
-attaining stability. That being said, there are some issues and untested
-functionality that should be addressed:
-
-1. Icon drag movement includes logic to avoid collisions with other icons and
- with the background image. That later is an issue. We need to paint the image
- directly on the background without the use of a widget.
-2. There are a few color artifacts in the toolbar of the `CONTEMPORARY` theme.
- These look like borders are being drawn around the toolbar widgets (even
- though the are configured to be borderless).
-3. Most Twm4Nx configuration settings are hard-coded in `*_config.hxx` header
- files. These all need to be brought out and made accessible via Kconfig files
-4. I have seen some odd behavior when many NxTerm windows have been opened
- (around 15). Specifically, I see failures to start NSH in the windows so they
- come up blank. All other behaviors seem normal. Most likely, some NxTerm
- resource allocation is failing silently and leaving things in an unusable
- state. The board I am using has 128Mb of SDRAM so I can't believe that memory
- is the limiting factor. These are, however, RAM-backed windows and will use
- significant amounts of memory. The primary issue is that the number of
- windows should probably be managed in some way to assure that the end-user
- does not experience odd behaviors when resource usage is high.
-5. Menus with sub-menus have not been verified. There is no use of sub- menus in
- the current code base so I expect that there are issues when, for example,
- and item from a sub-menu item: That menu and all of its antecedent menus
- should be closed.
-6. There is an optional MENU button that may appear at the far left on the
- toolbar. It is not used by any window in the current code base and, hence, is
- unverified. I would expect some issues with generating and routing the MENU
- button events to applications. There are likely other unverified features.
-7. X/Y input may be either via a touchscreen or a mouse. Only touchscreen input
- has been verified. There is, however, very little difference. The primary
- issue is in cursor support: Cursors are needed with a mouse. Cursor images
- also change depending on the state (like grabbing and dragging or resizing).
- There is also a possibility of using auto-raise with a mouse as well. All of
- this logic is in place, but none has been verified.
-8. NxTerm windows really need to be scrollable. They are difficult to use with
- only a few lines on a small display. A related usability issue is the font
- height: The fonts report a maximum font height that results in a large line
- spacing on the display and, hence, fewer lines visible in the small window.
- This is latter issues is a problem with the fonts not Twm4Nx, however.
-9. There is a trivial rounding error in the calculation of the LCD width in
- `SLcd::CSLcd::getWidth()`. It currently truncates down. It needs to round up.
- This sometimes leaves a small, one-pixel- wide sliver on the clock display.
- This display always recovers and this only cosmetic.
-
-## Adding Twm4Nx Applications
-
-### Application Factories and the Main Menu
-
-The original TWM supported a .twmrc in which you could describe application
-programs supported on the desktop. Currently no such start-up file is available
-for Twm4Nx. Rather, all applications must be added via run-time interfaces. And
-overview of these interfaces is provided in this paragraph.
-
-Currently, there are only two applications developed for Twm4Nx: (1) An NxTerm
-hosting NSH that is analogous to an XTerm hosting the Bash shell in a Unix
-environment, and (2) a touchscreen calibration application. Let's focus instead
-on the NxTerm application as an example because the touchscreen calibration is a
-rather unusual beast.
-
-These example applications can be found at: `apps/graphics/twm4nx/apps` and
-`apps/include/graphics/twm4nx/apps`
-
-In short, adding an application involves a _Factory Object_ that is hooked into
-the Main Menu. A Factory Object is an object that is used to create other object
-instances. The way in which the Factory Object is represented is purely a
-decision of the application developer. One option, however, is to use the pure
-virtual base class `IApplicationFactory` as defined in
-`apps/include/graphics/twm4nx/iapplication.hxx`. This base class provides only a
-single method:
-
-```cpp
-bool initialize(FAR CTwm4Nx *twm4nx);
-```
-
-where CTwm4Nx is the Twm4NX session instance that allows the class
-implementation to interact with session specific resources. Multiple sessions
-would be required, for example, if the platform supported multiple displays.
-
-In practice, the application factory implementation class inherits from the
-following base classes:
-
-1. `IApplicationFactory`. Provides the common `initialize()` method.
-2. `IApplication`. Provides the information for the application's entry in the
- Main Menu
-3. `CTwm4NxEvent`. Hooks the application factory into the Twm4Nx event
- notification system.
-
-Initialization consists of instantiating the application factory instance and
-calling its `IApplicationFactory::initialize()` method. The application factory
-instance is a singleton that must persist for the life of the session. For the
-NxTerm application factory, this is done in
-`apps/graphics/twm4nx/src/twm4nx_main.c` like:
-
-```cpp
-CNxTermFactory nxtermFactory;
-success = nxtermFactory.initialize(twm4nx);
-```
-
-In addition to general initialization, the `IApplicationFactory::initialize()`
-method must register a new entry with the main menu. You can see an example of
-this in `apps/graphics/twm4nx/apps/cnxterm.c`:
-
-```cpp
-FAR CMainMenu *cmain = twm4nx->getMainMenu();
-return cmain->addApplication(this);
-```
-
-The argument to the `CMainMenu::addApplication()` method is of type
-`IApplication *`. Remember, however, that our application implementation `class`
-inherited from `IApplication`.
-
-The IApplication pure virtual base class is also defined in
-`apps/include/graphics/twm4nx/iapplication.hxx`. It essentially describes what
-the Main Menu logic should do when the menu item is selected. It includes these
-methods:
-
-1. `getName()`. Provides the name string that will be shown in the Main Menu for
- this selection.
-2. `getSubMenu()`. One possibility is that selecting the Main Menu item is that
- it may bring up yet another sub-menu of options.
-3. `getEventHandler()`. Returns an instance of `CTwm4NxEvent` that is used to
- route menu selection events. Remember that our application factory inherits
- from `CTwm4NxEvent` so this function only needs to return the 'this'
- pointer.
-4. `getEvent()`. Provides the event ID that will be used in the event
- notification. The returned value must conform to the description in
- `apps/include/graphics/twm4nx/twm4nx_events.hxx`. In particular, the
- recipient of the event must be `EVENT_RECIPIENT_APP`.
-
-The Twm4Nx application is then started when the application factory's
-`CTwm4NxEvent::event()` method is called with the specified event.
-
-### Application Windows
-
-How the application factory starts an application instance is purely up to the
-application designer. Typically this would include starting a new application
-task. General characteristics of an application include:
-
-1. It probably should inherit from `CTwm4NxEvent` so that it can receive events
- from the system.
-2. To create the window, it must instantiate and initialize an instance of
- `CWindow`.
-3. It must configure application events to receive notifications from Twm4Nx.
-
-To create an application window, the application must call the
-`CWindowFactory::createWindow()` method. For the NxTerm example, this looks
-like:
-
-```cpp
-NXWidgets::CNxString name("NuttShell");
-
-uint8_t wflags = (WFLAGS_NO_MENU_BUTTON | WFLAGS_HIDDEN);
-
-FAR CWindowFactory *factory = m_twm4nx->getWindowFactory();
-m_nxtermWindow = factory->createWindow(name, &CONFIG_TWM4NX_NXTERM_ICON,
- (FAR CIconMgr *)0, wflags);
-```
-
-The window factory is another factory that creates and manages window instance.
-The `createWindow()` method requires four parameters:
-
-1. The name of the window. This is the name that is show in the window toolbar
- and may be the same name as was used in the Main Menu entry.
-2. A reference to the the Icon image associated with the window. This is the
- image that is show on the desktop when the window is iconified. It is of
- type `NXWidgets::SRlePaletteBitmap`.
-3. A pointer to the Icon Manager instance that this window belongs with. This
- can be NULL to use the default Twm4Nx Icon Manager.
-4. A set of flags that describe properties of the windows.
-
- The flag values are defined byte `WFLAGS_*` definitions provided in
- `apps/include/graphics/twm4nx/cwindow.hxx`:
-
- - `WFLAGS_NO_MENU_BUTTON` – Omit the menu button from the toolbar.
- - `WFLAGS_NO_DELETE_BUTTON` – Omit the delete button from the toolbar.
- - `WFLAGS_NO_RESIZE_BUTTON` – Omit the resize button from the toolbar.
- - `WFLAGS_NO_MINIMIZE_BUTTON` – Omit the minimize button from the toolbar.
- - `WFLAGS_NO_TOOLBAR` – Omit the toolbar altogether.
- - `WFLAGS_ICONMGR` – This window is an icon manager.
- - `WFLAGS_MENU` – This window is a menu window.
- - `WFLAGS_HIDDEN` – Start with the window hidden.
-
-Once the `CWindow` is instantiated, events needed by the application can be
-configured as is done in the NxTerm application:
-
-```cpp
-struct SAppEvents events;
-events.eventObj = (FAR void *)this;
-events.redrawEvent = EVENT_NXTERM_REDRAW;
-events.resizeEvent = EVENT_NXTERM_RESIZE;
-events.mouseEvent = EVENT_NXTERM_XYINPUT;
-events.kbdEvent = EVENT_NXTERM_KBDINPUT;
-events.closeEvent = EVENT_NXTERM_CLOSE;
-events.deleteEvent = EVENT_NXTERM_DELETE;
-
-bool success = m_nxtermWindow->configureEvents(events);
-```
-
-Again, recall that the application inherits from `CTwm4NxEvent`. So passing
-`this` as the event object above assures that the specific events are routed to
-the application instance.
-
-Drawing in the application window can be performed using that facilities of
-NXWidgets using the `NXWidgets::CGraphicsPort` associated with the window. The
-NxTerm application does not perform any drawing, however; that drawing is
-performed by the NxTerm driver.
-
-The `NXWidgets::CGraphicsPort` can be obtained from a `CWindow` instance, say
-`m_window`, like:
-
-```cpp
-FAR NXWidgets::CWidgetControl *control = m_window->getWidgetControl();
-NXWidgets::CGraphicsPort *port = control->getGraphicsPort();
-```
-
-That `CGraphicsPort` is then passed to the widget constructor, binding the
-widget to that window and forcing all widget drawing to occur within the window.
-
-Obviously, a lot more could be written about drawing, much more than can be
-addressed in this README file.
(nuttx-apps) 02/14: remove wireless/xxx/README.md. Migrated to Documentation/applications/wireless
Posted by xi...@apache.org.
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 0f57c325612ead63b4f278f36a3097e72a5d6186
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:04:58 2023 +0200
remove wireless/xxx/README.md. Migrated to Documentation/applications/wireless
---
wireless/bluetooth/btsak/README.md | 140 --------------------------
wireless/bluetooth/nimble/README.md | 75 --------------
wireless/ieee802154/i8sak/README.md | 189 ------------------------------------
3 files changed, 404 deletions(-)
diff --git a/wireless/bluetooth/btsak/README.md b/wireless/bluetooth/btsak/README.md
deleted file mode 100644
index 7ab3c0211..000000000
--- a/wireless/bluetooth/btsak/README.md
+++ /dev/null
@@ -1,140 +0,0 @@
-# Wireless / Bluetooth / `btsak` Bluetooth Swiss Army Knife
-
-## Commands
-
-```
-Command: help
-Description: Should overall command help
-Usage: bt <ifname> help
-```
-
-```
-Command: info
-Description: Show Bluetooth driver information
-Usage: bt <ifname> info [-h]
-```
-
-```
-Command: features
-Description: Show Bluetooth driver information
-Usage: bt <ifname> features [-h] [le]
-Where: le - Selects LE features vs BR/EDR features
-```
-
-```
-Command: scan
-Description: Bluetooth scan commands
-Usage: bt <ifname> scan [-h] <start [-d]|get|stop>
-Where: start - Starts scanning. The -d option enables duplicate
- filtering.
- get - Shows new accumulated scan results
- stop - Stops scanning
-```
-
-```
-Command: advertise
-Description: Bluetooth advertise commands
-Usage: bt <ifname> advertise [-h] <start|stop>
-Where: start - Starts advertising
- stop - Stops advertising
-```
-
-```
-Command: security
-Description: Enable security (encryption) for a connection:
- If device is paired, key encryption will be enabled. If
- the link is already encrypted with sufficiently strong
- key this command does nothing.
-
- If the device is not paired pairing will be initiated. If
- the device is paired and keys are too weak but input output
- capabilities allow for strong enough keys pairing will be
- initiated.
-
- This command may return error if required level of security
- is not possible to achieve due to local or remote device
- limitation (eg input output capabilities).
-Usage: bt <ifname> security [-h] <addr> public|random <level>
-Where: <addr> - The 6-byte address of the connected peer
- <level> - Security level, on of:
-
- low - No encryption and no authentication
- medium - Encryption and no authentication (no MITM)
- high - Encryption and authentication (MITM)
- fips - Authenticated LE secure connections and encryption
-```
-
-```
-Command: gatt
-Description: Generic Attribute (GATT) commands
-Usage: bt <ifname> gatt [-h] <cmd> [option [option [option...]]]
-Where: See "GATT Commands" below
-```
-
-## GATT Commands
-
-```
-Command: exchange-mtu
-Description: Set MTU to out maximum and negotiate MTU with peer
-Usage: bt <ifname> gatt exchange-mtu [-h] <addr> public|random
-```
-
-```
-Command: mget
-Description: Get the pass/fail result of the last GATT 'exchange-mtu' command
-Usage: bt <ifname> gatt mget [-h]
-```
-
-```
-Command: discover
-Description: Initiate discovery
-Usage: bt <ifname> gatt discover [-h] <addr> public|random <uuid16> [<start> [<end>]]
-```
-
-```
-Command: characteristic
-Description: Initiate characteristics discovery
-Usage: bt <ifname> gatt characteristic [-h] <addr> public|random [<start> [<end>]]
-```
-
-```
-Command: descriptor
-Description: Initiate characteristics discovery
-Usage: bt <ifname> gatt descriptor [-h] <addr> public|random [<start> [<end>]]
-```
-
-```
-Command: dget
-Description: Get the result of the last discovery action
-Usage: bt <ifname> gatt dget [-h]
-```
-
-```
-Command: read
-Description: Initiate a GATT read operation.
-Usage: bt <ifname> gatt read [-h] <addr> public|random <handle> [<offset>]
-```
-
-```
-Command: read-multiple
-Description: Initiate a GATT read-multiple operation.
-Usage: bt <ifname> gatt read-multiple [-h] <addr> public|random <handle> [<handle> [<handle>]..]
-```
-
-```
-Command: rget
-Description: Get the data resulting from the last read operation
-Usage: bt <ifname> gatt rget [-h]
-```
-
-```
-Command: write
-Description: Initiate a GATT write operation.
-Usage: bt <ifname> gatt write [-h] <addr> public|random <handle> <byte> [<byte> [<byte>]..]
-```
-
-```
-Command: wget
-Description: Get the pass/fail result of the last GATT 'write' command
-Usage: bt <ifname> gatt wget [-h]
-```
diff --git a/wireless/bluetooth/nimble/README.md b/wireless/bluetooth/nimble/README.md
deleted file mode 100644
index 5800c6b5e..000000000
--- a/wireless/bluetooth/nimble/README.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# nimBLE for NuttX
-
-This application will build nimBLE stack (host-only) as a library/application
-in NuttX.
-
-# Porting Layer
-
-nimBLE supports being built as part of different OS, not only their mynewt
-RTOS. A porting layer was written for NuttX, which was mostly a copy of
-the Linux porting layer.
-
-## Modifying the porting layer
-
-NuttX is supported in nimBLE by adding an entry in the porting layer
-used to support different OSs. However, nimBLE supports each OS
-by generating a configuration header (`syscfg.h`) from YAML configuration
-files. If you want to modify the porting layer and change its configuration
-you will need to regenerate this header. This process is a bit involved since
-nimBLE uses its own `newt` build tool to do so and also somewhat assumes it will
-be built for their mynewt OS, so it actually may fail to build completely but
-it will still get to generate the required files.
-
-So, first is to get the newt tool:
-
- $ cd apps/nimble
- $ git clone https://github.com/apache/mynewt-newt
- $ cd mynewt-newt
-
-At the moment, you will probably require unstable version
-instead of a release so select a known working:
-
- $ git checkout c14c47bb683d
- $ ./build.sh
-
-There should be now a `newt` binary under `mynewt-newt/newt`.
-Extend your path so that it is visible:
-
- $ export PATH=mynewt-newt/newt:$PATH
-
-Now, create a `newt` project:
-
- $ newt new foo
-
-We want latest master version of mynewt OS and stack, so edit
-`foo/project.yml` and change the `vers` variable to `0.0.0`. Now
-do
-
- $ cd foo/
- $ newt upgrade
-
-Under `foo/repos` there will be a clone of both mynewt and nimble
-repo. Since this app already downloads nimble repo outside of `foo`,
-you can delete `foo/repos/apache-mynewt-nimble` and simply make a
-link to the `mynewt-nimble` directory, so that you can work on the
-nimBLE code directly.
-
-Now you can make any changes to the `yml` files such as
-`porting/targets/nuttx/syscfg.yml`. Finally, you can build with:
-
- $ newt build @apache-mynewt-nimble/porting/targets/nuttx
-
-This will most likely fail to complete but the generated headers
-should be there. So now copy them to the appropriate location in
-the `nuttx` target directory:
-
- $ cd foo/
- $ cp bin/@apache-mynewt-nimble/porting/targets/nuttx/generated/include/logcfg/logcfg.h \
- repos/apache-mynewt-nimble/porting/examples/nuttx/include/logcfg
- $ cp bin/@apache-mynewt-nimble/porting/targets/nuttx/generated/include/syscfg/syscfg.h \
- repos/apache-mynewt-nimble/porting/examples/nuttx/include/syscfg
-
-If these changes are done to fix a problem with NuttX porting layer in nimBLE, you
-should open a pull-request to nimBLE repository to include the updated header files.
-It is recommended to mention the issue in NuttX mailing list first to ensure the change
-is needed.
diff --git a/wireless/ieee802154/i8sak/README.md b/wireless/ieee802154/i8sak/README.md
deleted file mode 100644
index 1a0557b51..000000000
--- a/wireless/ieee802154/i8sak/README.md
+++ /dev/null
@@ -1,189 +0,0 @@
-# Wireless / IEEE 802.15.4 / `i8sak` or `i8` IEEE 802.15.4 Swiss Army Knife
-
-## Description
-
-The i8sak app is a useful CLI for testing various IEEE 802.15.4 functionality.
-It also serves as a starting place for learning how to interface with the NuttX
-IEEE 802.15.4 MAC layer.
-
-The i8sak CLI can be used to manipulate multiple MAC layer networks at once.
-Both a MAC character driver interface and a network interface using sockets are
-supported. The MAC character driver is used in cases where networking is not
-enabled and you want your application to use IEEE 802.15.4 directly. In most
-cases however, you will probably be using 6LoWPAN networking support and
-therefore, the MAC can be controlled directly from the socket interface rather
-than the MAC character driver. IEEE 802.15.4 MAC character drivers show up in
-NuttX as `/dev/ieeeN` by default.
-
-When you invoke the first call to i8sak with a specified interface name, it
-creates an i8sak instance and launches a daemon to handle processing work. The
-instance is considered sticky, so it is possible to run `i8 /dev/ieee0` or `i8
-wpan0` at the beginning of a session and then can exclude the interface name
-from all future calls. The number of i8sak instances supported is controllable
-through menuconfig.
-
-The `i8sak` app has many settings that can be configured. Most options are
-_sticky_, meaning, if you set the endpoint short address once, any future
-operation using the endpoint short address can default to the previously used
-address. This is particularly useful to keep the command lengths down.
-
-## How To Use
-
-The i8sak app has a series of CLI functions that can be invoked. The default
-i8sak command is `i8` to make things quick and easy to type.
-
-In my test setup I have 2 Clicker2-STM32 boards from MikroElektronika, with the
-BEE-click (MRF24J40) radios. Choose one device to be the PAN Coordinator. We'll
-refer to that as device A.
-
-On that device, run:
-
-```shell
-i8 /dev/ieee0 startpan cd:ab
-```
-
-This will tell the MAC layer that it should now act as a PAN coordinator using
-PAN ID CD:AB. For now, this function assumes that we are operating a non-beacon
-enabled PAN, since, as of this writing, beacon-enabled networks are unfinished.
-
-Next, on the same device, run:
-
-```shell
-i8 acceptassoc
-```
-
-Notice in the second command, we did not use the devname, again, that is
-_sticky_ so unless we are switching back and forth between character drivers, we
-can just use it once.
-
-The acceptassoc command, without any arguments, informs the `i8sak` instance to
-accept all association requests. The acceptassoc command also allows you to only
-accept requests from a single device by specifying the extended address with
-option `-e`.
-
-For instance:
-
-```shell
-i8 acceptassoc -e DEADBEEF00FADE0B
-```
-
-But for this example, let's just use the command with no arguments.
-
-Now, the second device will act as an endpoint device. The i8sak instance
-defaults to being in endpoint mode. Let's refer to the second device as device
-`B`.
-
-On device B, run:
-
-```shell
-i8 /dev/ieee0 assoc
-```
-
-This command attempts to associate with the node at the configured endpoint
-address. If everything is setup correctly, device A should have log information
-saying that a device tried to associate and that it accepted the association. On
-device `B`, the console should show that the association request was successful.
-With all default settings, device B should have been allocated a short address
-of `0x000B`.
-
-If you are following along with a packet sniffer, you should see something
-similar to the following:
-
-```
-1) Association Request
- Frame Type - CMD
- Sequence Number - 0
- Dest. PAN ID - 0xFADE
- Dest. Address - 0x000A
- Src. PAN ID - 0xFFFE
- Src. Address - 0xDEADBEEF00FADE0C
- Command Type - Association Request
-
- 1a) ACK
- Frame Type - ACK
- Sequence Number - 0
-
-2) Data Request
- Frame Type - CMD
- Sequence Number - 1
- Dest. PAN ID - 0xFADE
- Dest. Address - 0x000A
- Src. PAN ID - 0xFFFE
- Src. Address - 0xDEADBEEF00FADE0C
- Command Type - Data Request
-
- 2a) ACK
- Frame Type - ACK
- Sequence Number - 1
-
-3) Association Response
- Frame Type - CMD
- Sequence Number - 0
- Dest. PAN ID - 0xFADE
- Dest. Address - 0xDEADBEEF00FADE0C
- Src. Address - 0xDEADBEEF00FADE0A
- Command Type - Association Response
- Assigned SADDR - 0x000C
- Assoc Status - Successful
-
- 3a) ACK
- Frame Type - ACK
- Sequence Number - 0
-```
-
-The default endpoint address can be configured via Kconfig or set dynamically
-using the `set` command.
-
-Here is how to set the endpoint short address
-
-```shell
-i8 set ep_saddr 0a:00
-```
-
-When setting the address, it's important to make sure the endpoint addressing
-mode is configured the way you want: Use `s` for short addressing or `e` for
-extended
-
-```shell
-i8 set ep_addrmode s
-```
-
-Device B has now successfully associated with device A. If you want to send data
-from device B to device A, run the following on device B:
-
-```shell
-i8 tx ABCDEF
-```
-
-This will immediately (not actually immediate, transaction is sent using CSMA)
-send the frame to device A with frame payload `0xABCDEF`
-
-Sending data from device A to device B is different. In IEEE 802.15.4, frames
-must be extracted from the coordinator. To prepare the frame, run the following
-command on device A
-
-```shell
-i8 tx AB
-```
-
-Because the devmode is PAN Coordinator, the `i8sak` app knows to send the data
-as an indirect transaction. If you were running the `i8sak` app on a device that
-is a coordinator, but not the PAN coordinator, you can force the `i8sak` app to
-send the transaction directly, rather than to the parent coordinator, by using
-the `-d` option.
-
-**Note**: Currently, the indirect transaction timeout is disabled. This means
-frames must be extracted or space may run out. This is only for the testing
-phase as it is easier to debug when I am not fighting a timeout. Re-enabling the
-timeout may effect the behavior of the indirect transaction features in the
-`i8sak` app.
-
-To extract the data, run the following command on device `B`:
-
-```shell
-i8 poll
-```
-
-This command polls the endpoint (our device A PAN Coordinator in this case) to
-see if there is any data. In the console of device B you should see a Poll
-request status print out.
(nuttx-apps) 14/14: remove logging/xxx/README.md. Migrated to Documentation/applications/logging
Posted by xi...@apache.org.
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 532bcc5061dd349c40813b52efe698ca8b168057
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:08:52 2023 +0200
remove logging/xxx/README.md. Migrated to Documentation/applications/logging
---
logging/nxscope/README.md | 38 --------------------------------------
1 file changed, 38 deletions(-)
diff --git a/logging/nxscope/README.md b/logging/nxscope/README.md
deleted file mode 100644
index 87e0674b9..000000000
--- a/logging/nxscope/README.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# `NxScope Library`
-
-This library provides real-time data logging functionality for NuttX.
-
-The principle of action is to accumulate data gathered in virtual channels
-and periodically send buffered data through a dedicated interface packed
-with a custom protocol.
-
-Supported features:
- - up to 255 channels possible
- - support for standard data types and user-specific data (`enum nxscope_sample_dtype_e`)
- - support for vector data or point data
- - support for character-based channels (text messages)
- - support for channel metadata - can be used to enumerate samples or timestamp
- - stream buffer overflow detection (`NXSCOPE_STREAM_FLAGS_OVERFLOW`)
- - remote control with commands (`enum nxscope_hdr_id_e`)
- - protocol and interface implementation can be different for control commands and stream data
- - (optional) support for user-specific commands (`NXSCOPE_HDRID_USER` and `struct nxscope_callbacks_s`)
- - (optional) support for samples divider (`CONFIG_LOGGING_NXSCOPE_DIVIDER`)
- - (optional) support for ACK frames (`CONFIG_LOGGING_NXSCOPE_ACKFRAMES`)
- - (optional) support for user-defined types (`CONFIG_LOGGING_NXSCOPE_USERTYPES`)
- - (optional) support for non-buffered critical channels (`CONFIG_LOGGING_NXSCOPE_CRICHANNELS`)
-
-A custom interface and a custom protocol can be implemented with
-`struct nxscope_intf_s` and `struct nxscope_proto_s` structures.
-
-Supported interfaces:
- 1. a serial port: `logging/nxscope/nxscope_iser.c`
- 2. a dummy interface for debug purposes: `logging/nxscope/nxscope_idummy.c`
-
-A default serial protocol is implemented in `apps/logging/nxscope/nxscope_pser.c`
-It just packs NxScope data into simple frames with a CRC-16 checksum.
-
-## External tools
-
-- [Nxslib](https://github.com/railab/nxslib) - a Python (3.10+) client library for NxScope devices,
-- [Nxscli](https://github.com/railab/nxscli) - a Python (3.10+) command-line interface for NxScope,
-supporting data capture and visualization
(nuttx-apps) 04/14: remove examples/xxx/README.md. Migrated to Documentation/applications/examples
Posted by xi...@apache.org.
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 <ra...@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-testing@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.
(nuttx-apps) 03/14: remove testing/xxx/README.md. Migrated to Documentation/applications/testing
Posted by xi...@apache.org.
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 14f19f0e7d8aa7324d05decc76e7a9e490965b8b
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:05:20 2023 +0200
remove testing/xxx/README.md. Migrated to Documentation/applications/testing
---
testing/README.md | 165 ----------------------------------------
testing/arch_libc/README.md | 13 ----
testing/cxxtest/README.md | 27 -------
testing/fopencookie/README.md | 13 ----
testing/fstest/README.md | 25 ------
testing/mtd_config_fs/README.md | 16 ----
testing/nxffs/README.md | 6 --
testing/smart/README.md | 23 ------
testing/smart_test/README.md | 26 -------
9 files changed, 314 deletions(-)
diff --git a/testing/README.md b/testing/README.md
deleted file mode 100644
index ae1eae6ed..000000000
--- a/testing/README.md
+++ /dev/null
@@ -1,165 +0,0 @@
-# Testing
-
-The `apps/testing` directory is used to build NuttX-specific tests and to
-include external testing frameworks.
-
-There is overlap between what you will find in `apps/examples` and
-`apps/testing` in the sense that there are also tests in `apps/examples` as
-well. Those tests, however, can also be used to illustrate usage of a NuttX
-feature. Most of the tests in `apps/testing`, on the other hand, are pure tests
-with little value as usage examples.
-
-## `cxxtest`
-
-This is a test of the C++ standard library. At present a port of the uClibc++
-C++ library is available. Due to licensing issues, the uClibc++ C++ library is
-not included in the NuttX source tree by default, but must be installed (see the
-`README.txt` file in the uClibc++ download package for installation).
-
-The uClibc++ test includes simple test of:
-
-- iostreams,
-- STL,
-- RTTI, and
-- Exceptions
-
-### Example Configuration Options
-
-- `CONFIG_TESTING_CXXTEST=y` – Eanbles the example
-
-### Other Required Configuration Settings
-
-Other NuttX setting that are required include:
-
-- `CONFIG_HAVE_CXX=y`
-- `CONFIG_HAVE_CXXINITIALIZE=y`
-- `CONFIG_UCLIBCXX=y` or `CONFIG_LIBCXX=y`
-
-Additional uClibc++/libcxx settings may be required in your build environment.
-
-## `fstest`
-
-This is a generic file system test that derives from `testing/nxffs`. It was
-created to test the tmpfs file system, but should work with any file system
-provided that all initialization has already been performed prior to starting
-the test.
-
-This test a a general test for any file system, but includes some specific hooks
-for the SPIFFS file system.
-
-- `CONFIG_TESTING_FSTEST` – Enable the file system example.
-- `CONFIG_TESTING_FSTEST_MAXNAME` – Determines the maximum size of names used in
- the filesystem.
-- `CONFIG_TESTING_FSTEST_MAXFILE` – Determines the maximum size of a file.
-- `CONFIG_TESTING_FSTEST_MAXIO` – Max I/O, default `347`.
-- `CONFIG_TESTING_FSTEST_MAXOPEN` – Max open files.
-- `CONFIG_TESTING_FSTEST_MOUNTPT` – Path where the file system is mounted.
-- `CONFIG_TESTING_FSTEST_NLOOPS` – Number of test loops. default `100`.
-- `CONFIG_TESTING_FSTEST_VERBOSE` – Verbose output.
-
-## `mm`
-
-This is a simple test of the memory manager.
-
-## `nxffs`
-
-This is a test of the NuttX NXFFS FLASH file system. This is an NXFFS stress
-test and beats on the file system very hard. It should only be used in a
-simulation environment! Putting this NXFFS test on real hardware will most
-likely destroy your FLASH. You have been warned.
-
-## `ostest`
-
-This is the NuttX _qualification_ suite. It attempts to exercise a broad set of
-OS functionality. Its coverage is not very extensive as of this writing, but it
-is used to qualify each NuttX release.
-
-The behavior of the `ostest` can be modified with the following settings in the
-`boards/<arch>/<chip>/<board>/configs/<config>/defconfig` file:
-
-- `CONFIG_NSH_BUILTIN_APPS` – Build the OS test example as an NSH built-in
- application.
-- `CONFIG_TESTING_OSTEST_LOOPS` – Used to control the number of executions of
- the test. If undefined, the test executes one time. If defined to be zero,
- the test runs forever.
-
-- `CONFIG_TESTING_OSTEST_STACKSIZE` – Used to create the ostest task. Default is
- `8192`.
-- `CONFIG_TESTING_OSTEST_NBARRIER_THREADS` – Specifies the number of threads to
- create in the barrier test. The default is 8 but a smaller number may be
- needed on systems without sufficient memory to start so many threads.
-
-- `CONFIG_TESTING_OSTEST_RR_RANGE` – During round-robin scheduling test two
- threads are created. Each of the threads searches for prime numbers in the
- configurable range, doing that configurable number of times. This value
- specifies the end of search range and together with number of runs allows to
- configure the length of this test – it should last at least a few tens of
- seconds. Allowed values `[1; 32767]`, default `10000`.
-
-- `CONFIG_TESTING_OSTEST_RR_RUNS` – During round-robin scheduling test two
- threads are created. Each of the threads searches for prime numbers in the
- configurable range, doing that configurable number of times.
-
-## `smart` SMART File System
-
-This is a test of the SMART file system that derives from `testing/nxffs`.
-
-- `CONFIG_TESTING_SMART` – Enable the SMART file system example.
-
-- `CONFIG_TESTING_SMART_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_TESTING_SMART_ARCHINIT`. In this case, the
- initialization logic will call `smart_archinitialize()` to obtain the MTD
- driver instance.
-
-- `CONFIG_TESTING_SMART_NEBLOCKS` – When `CONFIG_TESTING_SMART_ARCHINIT` is not
- defined, this test will use the RAM MTD device at `drivers/mtd/rammtd.c` to
- simulate FLASH. In this case, this value must be provided to give the number
- of erase blocks in MTD RAM device. The size of the allocated RAM drive will
- be: `CONFIG_RAMMTD_ERASESIZE * CONFIG_TESTING_SMART_NEBLOCKS`.
-
-- `CONFIG_TESTING_SMART_MAXNAME` – Determines the maximum size of names used in
- the filesystem.
-
-- `CONFIG_TESTING_SMART_MAXFILE` – Determines the maximum size of a file.
-- `CONFIG_TESTING_SMART_MAXIO` – Max I/O, default `347`.
-- `CONFIG_TESTING_SMART_MAXOPEN` – Max open files.
-- `CONFIG_TESTING_SMART_MOUNTPT` – SMART mountpoint.
-- `CONFIG_TESTING_SMART_NLOOPS` – Number of test loops. default `100`.
-- `CONFIG_TESTING_SMART_VERBOSE` – Verbose output.
-
-## `smart_test` SMART File System
-
-Performs a file-based test on a SMART (or any) filesystem. Validates seek,
-append and seek-with-write operations.
-
-* `CONFIG_TESTING_SMART_TEST=y`
-
-```
-Author: Ken Pettit
- Date: April 24, 2013
-```
-
-Performs a file-based test on a SMART (or any) filesystem. Validates seek,
-append and seek-with-write operations.
-
-```
-Usage:
-
- flash_test mtdblock_device
-
-Additional options:
-
- --force to replace existing installation
-```
-
-## `smp`
-
-This is a simple test for SMP functionality. It is basically just the pthread
-barrier test with some custom instrumentation.
-
-## `unity`
-
-Unity is a unit testing framework for C developed by ThrowTheSwitch.org:
-
-http://www.throwtheswitch.org/unity
diff --git a/testing/arch_libc/README.md b/testing/arch_libc/README.md
deleted file mode 100644
index c45f062c7..000000000
--- a/testing/arch_libc/README.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Testing / `arch_libc` Arch-specific libc Test
-
-This is a test for arch-specific libc function. Arch-specific libc functions are often implemented in
-assembly language, here is the test for these functions. The test focuses on key features in assembly
-language, including aligned access, speed, callee saved register check and so on.
-Currently, the test only contains a subset of possible arch-specific libc functions. You are welcomed
-to put more cases here.
-
-- `CONFIG_TESTING_ARCH_LIBC` – Enable the test.
-- `CONFIG_TESTING_ARCH_LIBC_XXXXX` – Enable test for function XXXXX.
-
-EXAMPLE
- arch_libc - Run the test.
diff --git a/testing/cxxtest/README.md b/testing/cxxtest/README.md
deleted file mode 100644
index 28072cf55..000000000
--- a/testing/cxxtest/README.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Testing / `cxxtest` C++ STL
-
-This is a test of the C++ standard library. At present a port of the uClibc++
-C++ library is available. Due to licensing issues, the uClibc++ C++ library is
-not included in the NuttX source tree by default, but must be installed (see the
-`README.txt` file in the uClibc++ download package for installation).
-
-The uClibc++ test includes simple test of:
-
-- iostreams,
-- STL,
-- RTTI, and
-- Exceptions
-
-## Example Configuration Options
-
-- `CONFIG_TESTING_CXXTEST=y` – Enables the example
-
-## Other Required Configuration Settings
-
-Other NuttX setting that are required include:
-
-- `CONFIG_HAVE_CXX=y`
-- `CONFIG_HAVE_CXXINITIALIZE=y`
-- `CONFIG_UCLIBCXX=y` or `CONFIG_LIBCXX=y`
-
-Additional `uClibc++/libcxx` settings may be required in your build environment.
diff --git a/testing/fopencookie/README.md b/testing/fopencookie/README.md
deleted file mode 100644
index d24d04733..000000000
--- a/testing/fopencookie/README.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Testing / `fopencookie` Fopencookie
-
-Performs a basic operations with fopencookie call.
-
-```conf
-CONFIG_TESTING_SMART_TEST=y
-```
-
-```
-Usage:
-
- fopencookie
-```
diff --git a/testing/fstest/README.md b/testing/fstest/README.md
deleted file mode 100644
index 34d03be31..000000000
--- a/testing/fstest/README.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Testing / `fstest` Generic File System Test
-
-This is a generic file system test that derives from `testing/nxffs`. It was
-created to test the tmpfs file system, but should work with any file system
-provided that all initialization has already been performed prior to starting
-the test.
-
-This test a a general test for any file system, but includes some specific hooks
-for the SPIFFS file system.
-
-- `CONFIG_TESTING_FSTEST` – Enable the file system example.
-- `CONFIG_TESTING_FSTEST_MAXNAME` – Determines the maximum size of names used in
- the filesystem.
-- `CONFIG_TESTING_FSTEST_MAXFILE` – Determines the maximum size of a file.
-- `CONFIG_TESTING_FSTEST_MAXIO` – Max I/O, default `347`.
-- `CONFIG_TESTING_FSTEST_MAXOPEN` – Max open files.
-- `CONFIG_TESTING_FSTEST_MOUNTPT` – Path where the file system is mounted.
-- `CONFIG_TESTING_FSTEST_NLOOPS` – Number of test loops. default `100`.
-- `CONFIG_TESTING_FSTEST_VERBOSE` – Verbose output.
-
-EXAMPLE
- fstest -m /mnt -n 10 – Test /mnt 10 times
- fstest -h – Get help message
- fstest – Test path define by `CONFIG_TESTING_FSTEST_MOUNTPT`
- `CONFIG_TESTING_FSTEST_NLOOPS` times
diff --git a/testing/mtd_config_fs/README.md b/testing/mtd_config_fs/README.md
deleted file mode 100644
index fdea6a85b..000000000
--- a/testing/mtd_config_fs/README.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# Testing / `mtd_nvs` MTD non-volatile storage Test
-
-This is a test for MTD non-volatile storage. MTD non-volatile storage was originally
-implemented in Zephyr by Laczen. We made several modification to the original design.
-The main purpose of those modification was:
-1. support C-string key in nvs API(Original design only support uint16_t as key)
-2. Meanwhile achieve better performance by limiting flash read times(Theoratically
-better than Zephyr subsys/settings, which is based on original NVS).
-
-
-- `CONFIG_TESTING_FAILSAFE_MTD_CONFIG` – Enable the test.
-- `CONFIG_TESTING_FAILSAFE_MTD_CONFIG_VERBOSE` – Verbose output.
-
-EXAMPLE
- mtdconfig_fs_test -m /dev/config – Test MTD NVS on /dev/config
- mtdconfig_fs_test -h – Get help message
diff --git a/testing/nxffs/README.md b/testing/nxffs/README.md
deleted file mode 100644
index cf333eaa5..000000000
--- a/testing/nxffs/README.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# Testing / `nxffs` NuttX NXFFS FLASH File System
-
-This is a test of the NuttX NXFFS FLASH file system. This is an NXFFS stress
-test and beats on the file system very hard. It should only be used in a
-simulation environment! Putting this NXFFS test on real hardware will most
-likely destroy your FLASH. You have been warned.
diff --git a/testing/smart/README.md b/testing/smart/README.md
deleted file mode 100644
index febf64bb1..000000000
--- a/testing/smart/README.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# Testing / `smart` SMART File System
-
-This is a test of the SMART file system that derives from `testing/nxffs`.
-
-- `CONFIG_TESTING_SMART` – Enable the SMART file system example.
-- `CONFIG_TESTING_SMART_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_TESTING_SMART_ARCHINIT`. In this case, the
- initialization logic will call `smart_archinitialize()` to obtain the MTD
- driver instance.
-- `CONFIG_TESTING_SMART_NEBLOCKS` – When `CONFIG_TESTING_SMART_ARCHINIT` is not
- defined, this test will use the RAM MTD device at `drivers/mtd/rammtd.c` to
- simulate FLASH. In this case, this value must be provided to give the number
- of erase blocks in MTD RAM device. The size of the allocated RAM drive will
- be: `CONFIG_RAMMTD_ERASESIZE * CONFIG_TESTING_SMART_NEBLOCKS`.
-- `CONFIG_TESTING_SMART_MAXNAME` – Determines the maximum size of names used in
- the filesystem.
-- `CONFIG_TESTING_SMART_MAXFILE` – Determines the maximum size of a file.
-- `CONFIG_TESTING_SMART_MAXIO` – Max I/O, default `347`.
-- `CONFIG_TESTING_SMART_MAXOPEN` – Max open files.
-- `CONFIG_TESTING_SMART_MOUNTPT` – SMART mountpoint.
-- `CONFIG_TESTING_SMART_NLOOPS` – Number of test loops. default `100`.
-- `CONFIG_TESTING_SMART_VERBOSE` – Verbose output.
diff --git a/testing/smart_test/README.md b/testing/smart_test/README.md
deleted file mode 100644
index f0e6352f2..000000000
--- a/testing/smart_test/README.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Testing / `smart_test` SMART File System
-
-Performs a file-based test on a SMART (or any) filesystem. Validates seek,
-append and seek-with-write operations.
-
-```conf
-CONFIG_TESTING_SMART_TEST=y
-```
-
-```
-Author: Ken Pettit
- Date: April 24, 2013
-```
-
-Performs a file-based test on a SMART (or any) filesystem. Validates seek,
-append and seek-with-write operations.
-
-```
-Usage:
-
- flash_test mtdblock_device
-
- Additional options:
-
- --force to replace existing installation
-```
(nuttx-apps) 11/14: remove boot/xxx/README.md. Migrated to Documentation/applications/boot
Posted by xi...@apache.org.
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 2fac780f37388a288de119b86029f5883b798bb5
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:08:21 2023 +0200
remove boot/xxx/README.md. Migrated to Documentation/applications/boot
---
boot/mcuboot/README.md | 54 --------------------------------------------------
1 file changed, 54 deletions(-)
diff --git a/boot/mcuboot/README.md b/boot/mcuboot/README.md
deleted file mode 100644
index 439c2e720..000000000
--- a/boot/mcuboot/README.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Boot / `mcuboot` MCUboot
-
-## Description
-
-The NuttX port of MCUboot secure boot library expects that the platform provides a Flash storage with the following partitions:
-- `CONFIG_MCUBOOT_PRIMARY_SLOT_PATH`: MTD partition for the application firmware image PRIMARY slot;
-- `CONFIG_MCUBOOT_SECONDARY_SLOT_PATH`: MTD partition for the application firmware image SECONDARY slot;
-- `CONFIG_MCUBOOT_SCRATCH_PATH`: MTD partition for the Scratch area;
-
-Also, these are optional features that may be enabled:
-
-- `CONFIG_MCUBOOT_WATCHDOG`: If `CONFIG_WATCHDOG` is enabled, MCUboot shall reset the watchdog timer indicated by `CONFIG_MCUBOOT_WATCHDOG_DEVPATH` to the current timeout value, preventing any imminent watchdog timeouts.
-
-The porting layer of MCUboot library consists of the following interfaces:
-- `<flash_map_backend/flash_map_backend.h>`, for enabling MCUboot to manage the application firmware image slots in the device storage.
-- `<mcuboot_config/mcuboot_config.h>`, for configuration of MCUboot's features.
-- `<mcuboot_config/mcuboot_logging.h>`, for providing logging capabilities.
-- `<os/os_malloc.h>`, for providing MCUboot access to the OS memory management interfaces.
-- `<sysflash/sysflash.h>`, for configuration of the system's flash area organization.
-
-The NuttX port of MCUboot is implemented at application-level and requires minimal knowledge about characteristics of the underlying storage device. This is achieved by means of the `BCH` and `FTL` subsystems, which enable MCUboot to manage MTD partitions via character device drivers using standard POSIX filesystem operations (e.g. `open()` / `close()` / `read()` / `write()`).
-
-## Creating MCUboot-compatible application firmware images
-
-One common use case for MCUboot is to integrate it to a firmware update agent, which is an important component of a secure firmware update subsystem. Through MCUboot APIs an application is able to install a newly received application firmware image and, once this application firmware image is assured to be valid, the application may confirm it as a stable image. In case that application firmware image is deemed bogus, MCUboot provides an API for invalidating that update, which will induc [...]
-
-The `CONFIG_EXAMPLES_MCUBOOT_UPDATE_AGENT` example demonstrates this workflow by downloading an application firmware image from a webserver, installing it and triggering the firmware update process for the next boot after a system reset. There is also the `CONFIG_EXAMPLES_MCUBOOT_SLOT_CONFIRM`, which is a fairly simple example that just calls an MCUboot API for confirming the executing application firmware image as stable.
-
-For more information about all MCUboot examples, see `examples/mcuboot` directory.
-
-## Using MCUboot on NuttX as a secure boot solution
-
-NuttX port for MCUboot also enables the creation of a secure bootloader application requiring minimal platform-specific implementation. The logical implementation for the secure boot is performed at application-level by the MCUboot library. Once MCUboot validates the application firmware image, it delegates the loading and execution of the application firmware image to a platform-specific routine, which is accessed via `boardctl(BOARDIOC_BOOT_IMAGE)` call. Each platform must then provide [...]
-
-The MCUboot bootloader application may be enabled by selecting the `CONFIG_MCUBOOT_BOOTLOADER` option.
-
-## Assumptions
-
-### IOCTL MTD commands
-
-The implementation of `<flash_map_backend/flash_map_backend.h>` expects that the MTD driver for a given image partition handles the following `ioctl` commands:
-- `MTDIOC_GEOMETRY`, for retrieving information about the geometry of the MTD, required for the configuration of the size of each flash area.
-- `MTDIOC_ERASESTATE`, for retrieving the byte value of an erased cell of the MTD, required for the implementation of `flash_area_erased_val()` interface.
-
-### Write access alignment
-
-Through `flash_area_align()` interface MCUboot expects that the implementation provides the shortest data length that may be written via `flash_area_write()` interface. The NuttX implementation passes through the `BCH` and `FTL` layers, which appropriately handle the write alignment restrictions of the underlying MTD. So The NuttX implementation of `flash_area_align()` is able to return a fixed value of 1 byte, even if the MTD does not support byte operations.
-
-## Limitations
-
-### `<flash_map_backend/flash_map_backend.h>` functions are not multitasking-safe
-
-MCUboot's documentation imposes no restrictions regarding the usage of its public interfaces, which doesn't mean they are thread-safe.
-But, regarding NuttX implementation of the `<flash_map_backend/flash_map_backend.h>`, it is safe to state that they are **not** multitasking-safe. NuttX implementation manages the MTD partitions via character device drivers. As file-descriptors cannot be shared between different tasks, if one task calls `flash_area_open` and another task calls `flash_area_<read/write/close>` passing the same `struct flash_area` instance, it will result in failure.
(nuttx-apps) 13/14: remove fsutils/xxx/README.md. Migrated to Documentation/applications/fsutils
Posted by xi...@apache.org.
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 a0b34e89d2e178fcf1e618b48f63e271c7e33e72
Author: raiden00pl <ra...@railab.me>
AuthorDate: Tue Oct 24 14:08:43 2023 +0200
remove fsutils/xxx/README.md. Migrated to Documentation/applications/fsutils
---
fsutils/inifile/README.md | 144 ----------------------------------------------
1 file changed, 144 deletions(-)
diff --git a/fsutils/inifile/README.md b/fsutils/inifile/README.md
deleted file mode 100644
index 86590cbcb..000000000
--- a/fsutils/inifile/README.md
+++ /dev/null
@@ -1,144 +0,0 @@
-# File System Utilities / `inifile` INI File
-
-## Syntax
-
-This directory contains a very simple INI file parser. An INI file consists of a
-sequence of lines up to the end of file. A line may be one of the following:
-
-1. A blank line.
-
-2. A comment line. Any line beginning with `;`
-
-3. A section header. Definitions are divided into sections. Each section begins
- with a line containing the section name enclosed in square brackets. For
- example, `[section1]`. The left bracket must be the first character on the
- line. Section names are case insensitive, i.e., `SECTION1` and `Section1`
- refer to the same section.
-
-4. Variable assignments. A variable assignment is a variable name followed by
- the `=` sign and then the value of the variable. For example, `A=B`: `A` is
- the variable name; `B` is the variable value. All variables following the
- section header belong in the section.
-
- Variable names may be preceded with white space. Whitespace is not permitted
- before the `=` sign. Variable names are case insensitive, i.e., `A` and `a`
- refer to the same variable name.
-
- Variable values may be numeric (any base) or a string. The case of string
- arguments is preserved.
-
-## Programming Interfaces
-
-See `apps/include/fsutils/inifile.h` for interfaces supported by the INI file
-parser.
-
-## Test Program
-
-Below is a simple test program:
-
-```c
-int main(int argc, char *argv[])
-{
- INIHANDLE handle;
- FILE *stream;
- FAR char *ptr;
- long value;
-
- stream = fopen("/tmp/file.ini", "w");
- fprintf(stream, "; Test INI file\n");
- fprintf(stream, "[section1]\n");
- fprintf(stream, " VAR1=1\n");
- fprintf(stream, " VAR2=2\n");
- fprintf(stream, " VAR3=3\n");
- fprintf(stream, "\n");
- fprintf(stream, "[section2]\n");
- fprintf(stream, " VAR4=4\n");
- fprintf(stream, " VAR5=5\n");
- fprintf(stream, "VAR6=6\n");
- fprintf(stream, "\n");
- fclose(stream);
-
- handle = inifile_initialize("/tmp/file.ini");
-
- ptr = inifile_read_string(handle, "section2", "VAR5", "OOPS");
- printf("Section: %s Variable: %s String: %s\n", "section2", "VAR5", ptr);
- inifile_free_string(ptr);
-
- ptr = inifile_read_string(handle, "section1", "VAR2", "OOPS");
- printf("Section: %s Variable: %s String: %s\n", "section1", "VAR2", ptr);
- inifile_free_string(ptr);
-
- ptr = inifile_read_string(handle, "section3", "VAR3", "OOPS");
- printf("Section: %s Variable: %s String: %s\n", "section3", "VAR3", ptr);
- inifile_free_string(ptr);
-
- ptr = inifile_read_string(handle, "section1", "VAR3", "OOPS");
- printf("Section: %s Variable: %s String: %s\n", "section1", "VAR3", ptr);
- inifile_free_string(ptr);
-
- ptr = inifile_read_string(handle, "section1", "VAR1", "OOPS");
- printf("Section: %s Variable: %s String: %s\n", "section1", "VAR1", ptr);
- inifile_free_string(ptr);
-
- ptr = inifile_read_string(handle, "section1", "VAR42", "OOPS");
- printf("Section: %s Variable: %s String: %s\n", "section1", "VAR42", ptr);
- inifile_free_string(ptr);
-
- ptr = inifile_read_string(handle, "section2", "VAR6", "OOPS");
- printf("Section: %s Variable: %s String: %s\n", "section2", "VAR6", ptr);
- inifile_free_string(ptr);
-
- ptr = inifile_read_string(handle, "section2", "VAR4", "OOPS");
- printf("Section: %s Variable: %s String: %s\n", "section2", "VAR4", ptr);
- inifile_free_string(ptr);
-
- value = inifile_read_integer(handle, "section1", "VAR3", 0);
- printf("Section: %s Variable: %s Value: %ld\n", "section1", "VAR3", value);
-
- value = inifile_read_integer(handle, "section3", "VAR3", 0);
- printf("Section: %s Variable: %s String: %ld\n", "section3", "VAR3", value);
-
- value = inifile_read_integer(handle, "section1", "VAR1", 0);
- printf("Section: %s Variable: %s Value: %ld\n", "section1", "VAR1", value);
-
- value = inifile_read_integer(handle, "section2", "VAR5", 0);
- printf("Section: %s Variable: %s Value: %ld\n", "section2", "VAR5", value);
-
- value = inifile_read_integer(handle, "section2", "VAR6", 0);
- printf("Section: %s Variable: %s Value: %ld\n", "section2", "VAR6", value);
-
- value = inifile_read_integer(handle, "section1", "VAR42", 0);
- printf("Section: %s Variable: %s String: %ld\n", "section1", "VAR42", value);
-
- value = inifile_read_integer(handle, "section1", "VAR2", 0);
- printf("Section: %s Variable: %s Value: %ld\n", "section1", "VAR2", value);
-
- value = inifile_read_integer(handle, "section2", "VAR4", 0);
- printf("Section: %s Variable: %s Value: %ld\n", "section2", "VAR4", value);
-
- inifile_uninitialize(handle);
- return 0;
-}
-```
-
-Test program output:
-
-```
-Section: section2 Variable: VAR5 String: 5
-Section: section1 Variable: VAR2 String: 2
-Section: section3 Variable: VAR3 String: OOPS
-Section: section1 Variable: VAR3 String: 3
-Section: section1 Variable: VAR1 String: 1
-Section: section1 Variable: VAR42 String: OOPS
-Section: section2 Variable: VAR6 String: 6
-Section: section2 Variable: VAR4 String: 4
-
-Section: section1 Variable: VAR3 Value: 3
-Section: section3 Variable: VAR3 Value: 0
-Section: section1 Variable: VAR1 Value: 1
-Section: section2 Variable: VAR5 Value: 5
-Section: section2 Variable: VAR6 Value: 6
-Section: section1 Variable: VAR42 String: 0
-Section: section1 Variable: VAR2 Value: 2
-Section: section2 Variable: VAR4 Value: 4
-```