You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by gi...@apache.org on 2021/05/27 01:01:42 UTC
[incubator-nuttx-website] branch asf-site updated: Publishing web:
1a68dd3405cfbf4f87c58d8ba31efe69f551d462 docs:
cddde2459bbfc40ac8b870a6d61b2404938452a5
This is an automated email from the ASF dual-hosted git repository.
github-bot pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new e79cda3 Publishing web: 1a68dd3405cfbf4f87c58d8ba31efe69f551d462 docs: cddde2459bbfc40ac8b870a6d61b2404938452a5
e79cda3 is described below
commit e79cda3c814fbb64fc2be659c3520091d02919e9
Author: Brennan <ba...@brennanashton.com>
AuthorDate: Thu May 27 00:59:21 2021 +0000
Publishing web: 1a68dd3405cfbf4f87c58d8ba31efe69f551d462 docs: cddde2459bbfc40ac8b870a6d61b2404938452a5
---
content/docs/10.0.0/index.html | 2 +-
content/docs/10.0.1/applications/index.html | 2 +
content/docs/10.0.1/boards/index.html | 2 +
content/docs/10.0.1/components/binfmt.html | 2 +
.../10.0.1/components/drivers/block/index.html | 2 +
.../components/drivers/character/analog.html | 2 +
.../10.0.1/components/drivers/character/can.html | 2 +
.../10.0.1/components/drivers/character/index.html | 2 +
.../components/drivers/character/keypad.html | 2 +
.../10.0.1/components/drivers/character/pwm.html | 2 +
.../components/drivers/character/quadrature.html | 2 +
.../10.0.1/components/drivers/character/rtc.html | 2 +
.../components/drivers/character/serial.html | 2 +
.../10.0.1/components/drivers/character/timer.html | 2 +
.../components/drivers/character/touchscreen.html | 2 +
.../components/drivers/character/watchdog.html | 2 +
content/docs/10.0.1/components/drivers/index.html | 2 +
.../components/drivers/special/ethernet.html | 2 +
.../components/drivers/special/framebuffer.html | 2 +
.../10.0.1/components/drivers/special/i2c.html | 2 +
.../10.0.1/components/drivers/special/index.html | 2 +
.../10.0.1/components/drivers/special/lcd.html | 2 +
.../10.0.1/components/drivers/special/mtd.html | 2 +
.../10.0.1/components/drivers/special/sdio.html | 2 +
.../10.0.1/components/drivers/special/spi.html | 2 +
.../10.0.1/components/drivers/special/usbdev.html | 2 +
.../10.0.1/components/drivers/special/usbhost.html | 2 +
content/docs/10.0.1/components/filesystem.html | 2 +
content/docs/10.0.1/components/index.html | 2 +
content/docs/10.0.1/components/nsh/builtin.html | 2 +
content/docs/10.0.1/components/nsh/commands.html | 2 +
content/docs/10.0.1/components/nsh/config.html | 2 +
.../docs/10.0.1/components/nsh/customizing.html | 2 +
content/docs/10.0.1/components/nsh/index.html | 2 +
.../docs/10.0.1/components/nsh/installation.html | 2 +
content/docs/10.0.1/components/nsh/login.html | 2 +
content/docs/10.0.1/components/nsh/nsh.html | 2 +
content/docs/10.0.1/components/nxflat.html | 2 +
.../10.0.1/components/nxgraphics/appendix.html | 2 +
.../docs/10.0.1/components/nxgraphics/index.html | 2 +
content/docs/10.0.1/components/nxgraphics/nx.html | 2 +
.../10.0.1/components/nxgraphics/nxcursor.html | 2 +
.../docs/10.0.1/components/nxgraphics/nxfonts.html | 2 +
.../docs/10.0.1/components/nxgraphics/nxgl.html | 2 +
.../docs/10.0.1/components/nxgraphics/nxtk.html | 2 +
.../docs/10.0.1/components/nxgraphics/sample.html | 2 +
content/docs/10.0.1/components/nxwidgets.html | 2 +
content/docs/10.0.1/components/paging.html | 2 +
content/docs/10.0.1/components/power.html | 2 +
content/docs/10.0.1/components/socketcan.html | 2 +
content/docs/10.0.1/components/syslog.html | 2 +
content/docs/10.0.1/contributing/coding_style.html | 2 +
.../docs/10.0.1/contributing/documentation.html | 2 +
content/docs/10.0.1/contributing/index.html | 2 +
.../docs/10.0.1/contributing/making-changes.html | 2 +
content/docs/10.0.1/contributing/workflow.html | 2 +
content/docs/10.0.1/genindex.html | 2 +
content/docs/10.0.1/glossary.html | 2 +
content/docs/10.0.1/guides/drivers.html | 2 +
content/docs/10.0.1/guides/index.html | 2 +
content/docs/10.0.1/guides/nfs.html | 2 +
content/docs/10.0.1/guides/simulator.html | 2 +
content/docs/10.0.1/guides/usbtrace.html | 2 +
content/docs/10.0.1/index.html | 4 +-
content/docs/10.0.1/introduction/about.html | 2 +
.../docs/10.0.1/introduction/detailed_support.html | 2 +
.../introduction/development_environments.html | 2 +
content/docs/10.0.1/introduction/index.html | 2 +
content/docs/10.0.1/introduction/inviolables.html | 2 +
content/docs/10.0.1/introduction/licensing.html | 2 +
content/docs/10.0.1/introduction/resources.html | 2 +
.../10.0.1/introduction/supported_platforms.html | 2 +
content/docs/10.0.1/introduction/trademarks.html | 2 +
content/docs/10.0.1/quickstart/build_and_make.html | 2 +
content/docs/10.0.1/quickstart/compiling.html | 2 +
content/docs/10.0.1/quickstart/configuring.html | 2 +
content/docs/10.0.1/quickstart/debugging.html | 2 +
content/docs/10.0.1/quickstart/index.html | 2 +
content/docs/10.0.1/quickstart/install.html | 2 +
content/docs/10.0.1/quickstart/organization.html | 2 +
content/docs/10.0.1/quickstart/quickstart.html | 2 +
content/docs/10.0.1/quickstart/running.html | 2 +
content/docs/10.0.1/reference/index.html | 2 +
content/docs/10.0.1/reference/os/addrenv.html | 2 +
content/docs/10.0.1/reference/os/app_vs_os.html | 2 +
content/docs/10.0.1/reference/os/arch.html | 2 +
content/docs/10.0.1/reference/os/board.html | 2 +
content/docs/10.0.1/reference/os/boardctl.html | 2 +
content/docs/10.0.1/reference/os/conventions.html | 2 +
content/docs/10.0.1/reference/os/index.html | 2 +
content/docs/10.0.1/reference/os/iob.html | 2 +
content/docs/10.0.1/reference/os/led.html | 2 +
content/docs/10.0.1/reference/os/nuttx.html | 2 +
content/docs/10.0.1/reference/os/paging.html | 2 +
content/docs/10.0.1/reference/os/shm.html | 2 +
content/docs/10.0.1/reference/os/smp.html | 2 +
content/docs/10.0.1/reference/os/time_clock.html | 2 +
content/docs/10.0.1/reference/os/wqueue.html | 2 +
.../10.0.1/reference/user/01_task_control.html | 2 +
.../10.0.1/reference/user/02_task_scheduling.html | 2 +
.../10.0.1/reference/user/03_task_control.html | 2 +
.../10.0.1/reference/user/04_message_queue.html | 2 +
.../reference/user/05_counting_semaphore.html | 2 +
.../10.0.1/reference/user/06_clocks_timers.html | 2 +
content/docs/10.0.1/reference/user/07_signals.html | 2 +
content/docs/10.0.1/reference/user/08_pthread.html | 2 +
.../docs/10.0.1/reference/user/09_env_vars.html | 2 +
.../docs/10.0.1/reference/user/10_filesystem.html | 2 +
content/docs/10.0.1/reference/user/11_network.html | 2 +
.../10.0.1/reference/user/12_shared_memory.html | 2 +
content/docs/10.0.1/reference/user/index.html | 2 +
content/docs/10.0.1/reference/user/structures.html | 2 +
content/docs/10.0.1/releases/index.html | 2 +
content/docs/10.0.1/search.html | 2 +
content/docs/10.0.1/substitutions.html | 2 +
content/docs/10.1.0/_images/NXOrganization.gif | Bin 0 -> 34880 bytes
content/docs/10.1.0/_images/NuttXScreenShot.jpg | Bin 0 -> 5872 bytes
content/docs/10.1.0/_images/board.jpg | Bin 0 -> 187914 bytes
.../docs/10.1.0/_images/esp32-core-board-v2.jpg | Bin 0 -> 48460 bytes
.../docs/10.1.0/_images/esp32-devkitc-v4-front.jpg | Bin 0 -> 45574 bytes
content/docs/10.1.0/_images/menuconfig-debug.png | Bin 0 -> 309633 bytes
content/docs/10.1.0/_images/menuconfig.png | Bin 0 -> 124925 bytes
content/docs/10.1.0/_images/pinout.webp | Bin 0 -> 125938 bytes
content/docs/10.1.0/_images/pm.png | Bin 0 -> 32504 bytes
content/docs/10.1.0/_images/syscall-flat-after.png | Bin 0 -> 62410 bytes
.../docs/10.1.0/_images/syscall-flat-before.png | Bin 0 -> 14115 bytes
.../10.1.0/_images/syscall-protected-after.png | Bin 0 -> 91583 bytes
.../10.1.0/_images/syscall-protected-before.png | Bin 0 -> 55438 bytes
.../docs/10.1.0/_images/task-trace-internal.png | Bin 0 -> 141573 bytes
.../docs/10.1.0/_images/task-trace-overview.png | Bin 0 -> 529103 bytes
.../10.1.0/_images/trace-compass-screenshot.png | Bin 0 -> 112799 bytes
.../10.1.0/_sources/applications/index.rst.txt | 15 +
.../_sources/applications/nsh/builtin.rst.txt | 204 +
.../_sources/applications/nsh/commands.rst.txt | 1843 ++++
.../_sources/applications/nsh/config.rst.txt | 488 +
.../_sources/applications/nsh/customizing.rst.txt | 213 +
.../10.1.0/_sources/applications/nsh/index.rst.txt | 19 +
.../_sources/applications/nsh/installation.rst.txt | 184 +
.../10.1.0/_sources/applications/nsh/login.rst.txt | 261 +
.../10.1.0/_sources/applications/nsh/nsh.rst.txt | 361 +
.../docs/10.1.0/_sources/components/binfmt.rst.txt | 360 +
.../components/drivers/block/index.rst.txt | 41 +
.../components/drivers/character/analog.rst.txt | 55 +
.../components/drivers/character/can.rst.txt | 36 +
.../components/drivers/character/foc.rst.txt | 48 +
.../components/drivers/character/index.rst.txt | 68 +
.../components/drivers/character/keypad.rst.txt | 143 +
.../components/drivers/character/note.rst.txt | 296 +
.../components/drivers/character/pwm.rst.txt | 34 +
.../drivers/character/quadrature.rst.txt | 29 +
.../components/drivers/character/rtc.rst.txt | 25 +
.../components/drivers/character/serial.rst.txt | 29 +
.../components/drivers/character/timer.rst.txt | 333 +
.../drivers/character/touchscreen.rst.txt | 38 +
.../components/drivers/character/watchdog.rst.txt | 204 +
.../_sources/components/drivers/index.rst.txt | 32 +
.../components/drivers/special/ethernet.rst.txt | 17 +
.../components/drivers/special/framebuffer.rst.txt | 34 +
.../components/drivers/special/i2c.rst.txt | 22 +
.../components/drivers/special/index.rst.txt | 36 +
.../components/drivers/special/lcd.rst.txt | 47 +
.../components/drivers/special/mtd.rst.txt | 47 +
.../components/drivers/special/sdio.rst.txt | 33 +
.../components/drivers/special/socketcan.rst.txt | 66 +
.../components/drivers/special/spi.rst.txt | 25 +
.../components/drivers/special/syslog.rst.txt | 511 +
.../components/drivers/special/usbdev.rst.txt | 50 +
.../components/drivers/special/usbhost.rst.txt | 108 +
.../10.1.0/_sources/components/filesystem.rst.txt | 43 +
.../docs/10.1.0/_sources/components/index.rst.txt | 17 +
.../docs/10.1.0/_sources/components/nxflat.rst.txt | 404 +
.../components/nxgraphics/appendix.rst.txt | 647 ++
.../_sources/components/nxgraphics/index.rst.txt | 176 +
.../_sources/components/nxgraphics/nx.rst.txt | 719 ++
.../components/nxgraphics/nxcursor.rst.txt | 50 +
.../_sources/components/nxgraphics/nxfonts.rst.txt | 127 +
.../_sources/components/nxgraphics/nxgl.rst.txt | 259 +
.../_sources/components/nxgraphics/nxtk.rst.txt | 653 ++
.../_sources/components/nxgraphics/sample.rst.txt | 30 +
.../10.1.0/_sources/components/nxwidgets.rst.txt | 55 +
.../docs/10.1.0/_sources/components/paging.rst.txt | 409 +
.../docs/10.1.0/_sources/components/power.rst.txt | 245 +
.../_sources/contributing/coding_style.rst.txt | 2659 +++++
.../_sources/contributing/documentation.rst.txt | 195 +
.../10.1.0/_sources/contributing/index.rst.txt | 14 +
.../_sources/contributing/making-changes.rst.txt | 222 +
.../10.1.0/_sources/contributing/workflow.rst.txt | 42 +
content/docs/10.1.0/_sources/glossary.rst.txt | 368 +
.../docs/10.1.0/_sources/guides/cpp_cmake.rst.txt | 284 +
.../docs/10.1.0/_sources/guides/drivers.rst.txt | 206 +
content/docs/10.1.0/_sources/guides/index.rst.txt | 13 +
content/docs/10.1.0/_sources/guides/nfs.rst.txt | 284 +
.../docs/10.1.0/_sources/guides/simulator.rst.txt | 189 +
.../docs/10.1.0/_sources/guides/tasktrace.rst.txt | 20 +
.../_sources/guides/tasktraceinternal.rst.txt | 96 +
.../10.1.0/_sources/guides/tasktraceuser.rst.txt | 366 +
.../docs/10.1.0/_sources/guides/usbtrace.rst.txt | 216 +
content/docs/10.1.0/_sources/index.rst.txt | 34 +
.../10.1.0/_sources/introduction/about.rst.txt | 281 +
.../_sources/introduction/detailed_support.rst.txt | 3177 ++++++
.../introduction/development_environments.rst.txt | 155 +
.../10.1.0/_sources/introduction/index.rst.txt | 17 +
.../_sources/introduction/inviolables.rst.txt | 1 +
.../10.1.0/_sources/introduction/licensing.rst.txt | 11 +
.../10.1.0/_sources/introduction/resources.rst.txt | 22 +
.../introduction/supported_platforms.rst.txt | 285 +
.../_sources/introduction/trademarks.rst.txt | 30 +
.../10.1.0/_sources/platforms/arm/index.rst.txt | 11 +
.../arm/nrf52/boards/nrf52832-mdk/index.rst.txt | 61 +
.../nrf52/boards/nrf52832-sparkfun/index.rst.txt | 52 +
.../_sources/platforms/arm/nrf52/index.rst.txt | 181 +
.../docs/10.1.0/_sources/platforms/index.rst.txt | 13 +
.../_sources/platforms/risc-v/bl602/index.rst.txt | 12 +
.../10.1.0/_sources/platforms/risc-v/index.rst.txt | 11 +
.../esp32/boards/esp32-devkitc/index.rst.txt | 272 +
.../_sources/platforms/xtensa/esp32/index.rst.txt | 718 ++
.../10.1.0/_sources/platforms/xtensa/index.rst.txt | 11 +
.../10.1.0/_sources/quickstart/compiling.rst.txt | 75 +
.../10.1.0/_sources/quickstart/configuring.rst.txt | 123 +
.../10.1.0/_sources/quickstart/debugging.rst.txt | 268 +
.../docs/10.1.0/_sources/quickstart/index.rst.txt | 17 +
.../10.1.0/_sources/quickstart/install.rst.txt | 185 +
.../_sources/quickstart/organization.rst.txt | 513 +
.../10.1.0/_sources/quickstart/running.rst.txt | 86 +
.../docs/10.1.0/_sources/reference/index.rst.txt | 14 +
.../10.1.0/_sources/reference/os/addrenv.rst.txt | 305 +
.../10.1.0/_sources/reference/os/app_vs_os.rst.txt | 103 +
.../docs/10.1.0/_sources/reference/os/arch.rst.txt | 329 +
.../10.1.0/_sources/reference/os/board.rst.txt | 74 +
.../_sources/reference/os/conventions.rst.txt | 101 +
.../10.1.0/_sources/reference/os/index.rst.txt | 24 +
.../docs/10.1.0/_sources/reference/os/iob.rst.txt | 310 +
.../docs/10.1.0/_sources/reference/os/led.rst.txt | 122 +
.../10.1.0/_sources/reference/os/nuttx.rst.txt | 50 +
.../10.1.0/_sources/reference/os/paging.rst.txt | 13 +
.../docs/10.1.0/_sources/reference/os/shm.rst.txt | 38 +
.../docs/10.1.0/_sources/reference/os/smp.rst.txt | 99 +
.../_sources/reference/os/time_clock.rst.txt | 593 +
.../10.1.0/_sources/reference/os/wqueue.rst.txt | 307 +
.../reference/user/01_task_control.rst.txt | 875 ++
.../reference/user/02_task_scheduling.rst.txt | 180 +
.../reference/user/03_task_control.rst.txt | 458 +
.../reference/user/04_message_queue.rst.txt | 375 +
.../reference/user/05_counting_semaphore.rst.txt | 455 +
.../reference/user/06_clocks_timers.rst.txt | 370 +
.../_sources/reference/user/07_signals.rst.txt | 514 +
.../_sources/reference/user/08_pthread.rst.txt | 1710 +++
.../_sources/reference/user/09_env_vars.rst.txt | 95 +
.../_sources/reference/user/10_filesystem.rst.txt | 575 +
.../_sources/reference/user/11_network.rst.txt | 417 +
.../reference/user/12_shared_memory.rst.txt | 202 +
.../_sources/reference/user/13_boardctl.rst.txt | 252 +
.../_sources/reference/user/13_logging.rst.txt | 95 +
.../10.1.0/_sources/reference/user/index.rst.txt | 28 +
.../_sources/reference/user/structures.rst.txt | 170 +
content/docs/10.1.0/_sources/substitutions.rst.txt | 5 +
content/docs/10.1.0/_static/NuttX.png | Bin 0 -> 4961 bytes
content/docs/10.1.0/_static/NuttX320.png | Bin 0 -> 4151 bytes
content/docs/10.1.0/_static/basic.css | 856 ++
content/docs/10.1.0/_static/css/badge_only.css | 1 +
.../10.1.0/_static/css/fonts/Roboto-Slab-Bold.woff | Bin 0 -> 87624 bytes
.../_static/css/fonts/Roboto-Slab-Bold.woff2 | Bin 0 -> 67312 bytes
.../_static/css/fonts/Roboto-Slab-Regular.woff | Bin 0 -> 86288 bytes
.../_static/css/fonts/Roboto-Slab-Regular.woff2 | Bin 0 -> 66444 bytes
.../_static/css/fonts/fontawesome-webfont.eot | Bin 0 -> 165742 bytes
.../_static/css/fonts/fontawesome-webfont.svg | 2671 +++++
.../_static/css/fonts/fontawesome-webfont.ttf | Bin 0 -> 165548 bytes
.../_static/css/fonts/fontawesome-webfont.woff | Bin 0 -> 98024 bytes
.../_static/css/fonts/fontawesome-webfont.woff2 | Bin 0 -> 77160 bytes
.../10.1.0/_static/css/fonts/lato-bold-italic.woff | Bin 0 -> 323344 bytes
.../_static/css/fonts/lato-bold-italic.woff2 | Bin 0 -> 193308 bytes
.../docs/10.1.0/_static/css/fonts/lato-bold.woff | Bin 0 -> 309728 bytes
.../docs/10.1.0/_static/css/fonts/lato-bold.woff2 | Bin 0 -> 184912 bytes
.../_static/css/fonts/lato-normal-italic.woff | Bin 0 -> 328412 bytes
.../_static/css/fonts/lato-normal-italic.woff2 | Bin 0 -> 195704 bytes
.../docs/10.1.0/_static/css/fonts/lato-normal.woff | Bin 0 -> 309192 bytes
.../10.1.0/_static/css/fonts/lato-normal.woff2 | Bin 0 -> 182708 bytes
content/docs/10.1.0/_static/css/theme.css | 4 +
content/docs/10.1.0/_static/custom.css | 93 +
content/docs/10.1.0/_static/doctools.js | 321 +
.../docs/10.1.0/_static/documentation_options.js | 12 +
content/docs/10.1.0/_static/favicon.ico | Bin 0 -> 4286 bytes
content/docs/10.1.0/_static/file.png | Bin 0 -> 286 bytes
.../docs/10.1.0/_static/fonts/Inconsolata-Bold.ttf | Bin 0 -> 109948 bytes
.../10.1.0/_static/fonts/Inconsolata-Regular.ttf | Bin 0 -> 96964 bytes
content/docs/10.1.0/_static/fonts/Inconsolata.ttf | Bin 0 -> 63184 bytes
content/docs/10.1.0/_static/fonts/Lato-Bold.ttf | Bin 0 -> 656544 bytes
content/docs/10.1.0/_static/fonts/Lato-Regular.ttf | Bin 0 -> 656568 bytes
.../docs/10.1.0/_static/fonts/Lato/lato-bold.eot | Bin 0 -> 256056 bytes
.../docs/10.1.0/_static/fonts/Lato/lato-bold.ttf | Bin 0 -> 600856 bytes
.../docs/10.1.0/_static/fonts/Lato/lato-bold.woff | Bin 0 -> 309728 bytes
.../docs/10.1.0/_static/fonts/Lato/lato-bold.woff2 | Bin 0 -> 184912 bytes
.../10.1.0/_static/fonts/Lato/lato-bolditalic.eot | Bin 0 -> 266158 bytes
.../10.1.0/_static/fonts/Lato/lato-bolditalic.ttf | Bin 0 -> 622572 bytes
.../10.1.0/_static/fonts/Lato/lato-bolditalic.woff | Bin 0 -> 323344 bytes
.../_static/fonts/Lato/lato-bolditalic.woff2 | Bin 0 -> 193308 bytes
.../docs/10.1.0/_static/fonts/Lato/lato-italic.eot | Bin 0 -> 268604 bytes
.../docs/10.1.0/_static/fonts/Lato/lato-italic.ttf | Bin 0 -> 639388 bytes
.../10.1.0/_static/fonts/Lato/lato-italic.woff | Bin 0 -> 328412 bytes
.../10.1.0/_static/fonts/Lato/lato-italic.woff2 | Bin 0 -> 195704 bytes
.../10.1.0/_static/fonts/Lato/lato-regular.eot | Bin 0 -> 253461 bytes
.../10.1.0/_static/fonts/Lato/lato-regular.ttf | Bin 0 -> 607720 bytes
.../10.1.0/_static/fonts/Lato/lato-regular.woff | Bin 0 -> 309192 bytes
.../10.1.0/_static/fonts/Lato/lato-regular.woff2 | Bin 0 -> 182708 bytes
.../docs/10.1.0/_static/fonts/RobotoSlab-Bold.ttf | Bin 0 -> 170616 bytes
.../10.1.0/_static/fonts/RobotoSlab-Regular.ttf | Bin 0 -> 169064 bytes
.../fonts/RobotoSlab/roboto-slab-v7-bold.eot | Bin 0 -> 79520 bytes
.../fonts/RobotoSlab/roboto-slab-v7-bold.ttf | Bin 0 -> 170616 bytes
.../fonts/RobotoSlab/roboto-slab-v7-bold.woff | Bin 0 -> 87624 bytes
.../fonts/RobotoSlab/roboto-slab-v7-bold.woff2 | Bin 0 -> 67312 bytes
.../fonts/RobotoSlab/roboto-slab-v7-regular.eot | Bin 0 -> 78331 bytes
.../fonts/RobotoSlab/roboto-slab-v7-regular.ttf | Bin 0 -> 169064 bytes
.../fonts/RobotoSlab/roboto-slab-v7-regular.woff | Bin 0 -> 86288 bytes
.../fonts/RobotoSlab/roboto-slab-v7-regular.woff2 | Bin 0 -> 66444 bytes
.../10.1.0/_static/fonts/fontawesome-webfont.eot | Bin 0 -> 165742 bytes
.../10.1.0/_static/fonts/fontawesome-webfont.svg | 2671 +++++
.../10.1.0/_static/fonts/fontawesome-webfont.ttf | Bin 0 -> 165548 bytes
.../10.1.0/_static/fonts/fontawesome-webfont.woff | Bin 0 -> 98024 bytes
.../10.1.0/_static/fonts/fontawesome-webfont.woff2 | Bin 0 -> 77160 bytes
.../10.1.0/_static/images/menuconfig-debug.png | Bin 0 -> 309633 bytes
content/docs/10.1.0/_static/images/menuconfig.png | Bin 0 -> 124925 bytes
content/docs/10.1.0/_static/jquery-3.5.1.js | 10872 +++++++++++++++++++
content/docs/10.1.0/_static/jquery.js | 2 +
content/docs/10.1.0/_static/js/badge_only.js | 1 +
.../10.1.0/_static/js/html5shiv-printshiv.min.js | 4 +
content/docs/10.1.0/_static/js/html5shiv.min.js | 4 +
content/docs/10.1.0/_static/js/modernizr.min.js | 4 +
content/docs/10.1.0/_static/js/theme.js | 1 +
content/docs/10.1.0/_static/language_data.js | 297 +
content/docs/10.1.0/_static/minus.png | Bin 0 -> 90 bytes
content/docs/10.1.0/_static/plus.png | Bin 0 -> 90 bytes
content/docs/10.1.0/_static/pygments.css | 74 +
content/docs/10.1.0/_static/searchtools.js | 522 +
content/docs/10.1.0/_static/tabs.css | 53 +
content/docs/10.1.0/_static/tabs.js | 130 +
content/docs/10.1.0/_static/underscore-1.12.0.js | 2027 ++++
content/docs/10.1.0/_static/underscore.js | 6 +
.../{latest => 10.1.0}/applications/index.html | 3 +-
.../applications/nsh/builtin.html | 3 +-
.../applications/nsh/commands.html | 14 +-
.../applications/nsh/config.html | 3 +-
.../applications/nsh/customizing.html | 3 +-
.../{latest => 10.1.0}/applications/nsh/index.html | 3 +-
.../applications/nsh/installation.html | 3 +-
.../{latest => 10.1.0}/applications/nsh/login.html | 5 +-
.../{latest => 10.1.0}/applications/nsh/nsh.html | 3 +-
.../docs/{latest => 10.1.0}/components/binfmt.html | 3 +-
.../components/drivers/block/index.html | 3 +-
.../components/drivers/character/analog.html | 3 +-
.../components/drivers/character/can.html | 3 +-
.../components/drivers/character/foc.html | 5 +-
.../components/drivers/character/index.html | 3 +-
.../components/drivers/character/keypad.html | 3 +-
.../components/drivers/character/note.html | 3 +-
.../components/drivers/character/pwm.html | 3 +-
.../components/drivers/character/quadrature.html | 3 +-
.../components/drivers/character/rtc.html | 3 +-
.../components/drivers/character/serial.html | 3 +-
.../components/drivers/character/timer.html | 3 +-
.../components/drivers/character/touchscreen.html | 3 +-
.../components/drivers/character/watchdog.html | 5 +-
.../components/drivers/index.html | 3 +-
.../components/drivers/special/ethernet.html | 3 +-
.../components/drivers/special/framebuffer.html | 3 +-
.../components/drivers/special/i2c.html | 3 +-
.../components/drivers/special/index.html | 3 +-
.../components/drivers/special/lcd.html | 3 +-
.../components/drivers/special/mtd.html | 3 +-
.../components/drivers/special/sdio.html | 3 +-
.../components/drivers/special/socketcan.html | 3 +-
.../components/drivers/special/spi.html | 3 +-
.../components/drivers/special/syslog.html | 10 +-
.../components/drivers/special/usbdev.html | 3 +-
.../components/drivers/special/usbhost.html | 3 +-
.../{latest => 10.1.0}/components/filesystem.html | 3 +-
.../docs/{latest => 10.1.0}/components/index.html | 7 +-
.../docs/{latest => 10.1.0}/components/nxflat.html | 3 +-
.../components/nxgraphics/appendix.html | 3 +-
.../components/nxgraphics/index.html | 3 +-
.../components/nxgraphics/nx.html | 3 +-
.../components/nxgraphics/nxcursor.html | 3 +-
.../components/nxgraphics/nxfonts.html | 3 +-
.../components/nxgraphics/nxgl.html | 3 +-
.../components/nxgraphics/nxtk.html | 7 +-
.../components/nxgraphics/sample.html | 3 +-
.../{latest => 10.1.0}/components/nxwidgets.html | 3 +-
.../docs/{latest => 10.1.0}/components/paging.html | 3 +-
.../docs/{latest => 10.1.0}/components/power.html | 3 +-
.../contributing/coding_style.html | 3 +-
.../contributing/documentation.html | 9 +-
.../{latest => 10.1.0}/contributing/index.html | 3 +-
.../contributing/making-changes.html | 3 +-
.../{latest => 10.1.0}/contributing/workflow.html | 7 +-
content/docs/{latest => 10.1.0}/genindex.html | 3 +-
content/docs/{latest => 10.1.0}/glossary.html | 3 +-
.../docs/{latest => 10.1.0}/guides/cpp_cmake.html | 3 +-
.../docs/{latest => 10.1.0}/guides/drivers.html | 5 +-
content/docs/{latest => 10.1.0}/guides/index.html | 7 +-
content/docs/{latest => 10.1.0}/guides/nfs.html | 3 +-
.../docs/{latest => 10.1.0}/guides/simulator.html | 3 +-
.../docs/{latest => 10.1.0}/guides/tasktrace.html | 3 +-
.../guides/tasktraceinternal.html | 3 +-
.../{latest => 10.1.0}/guides/tasktraceuser.html | 7 +-
.../docs/{latest => 10.1.0}/guides/usbtrace.html | 3 +-
content/docs/{latest => 10.1.0}/index.html | 10 +-
.../{latest => 10.1.0}/introduction/about.html | 3 +-
.../introduction/detailed_support.html | 17 +-
.../introduction/development_environments.html | 3 +-
.../{latest => 10.1.0}/introduction/index.html | 3 +-
.../introduction/inviolables.html | 3 +-
.../{latest => 10.1.0}/introduction/licensing.html | 3 +-
.../{latest => 10.1.0}/introduction/resources.html | 5 +-
.../introduction/supported_platforms.html | 3 +-
.../introduction/trademarks.html | 3 +-
content/docs/10.1.0/objects.inv | Bin 0 -> 30780 bytes
.../{latest => 10.1.0}/platforms/arm/index.html | 9 +-
.../arm/nrf52/boards/nrf52832-mdk/index.html | 4 +-
.../arm/nrf52/boards/nrf52832-sparkfun/index.html | 4 +-
.../platforms/arm/nrf52/index.html | 10 +-
.../docs/{latest => 10.1.0}/platforms/index.html | 17 +-
.../platforms/risc-v/bl602/index.html | 9 +-
.../{latest => 10.1.0}/platforms/risc-v/index.html | 7 +-
.../xtensa/esp32/boards/esp32-devkitc/index.html | 18 +-
.../platforms/xtensa/esp32/index.html | 13 +-
.../{latest => 10.1.0}/platforms/xtensa/index.html | 7 +-
.../{latest => 10.1.0}/quickstart/compiling.html | 5 +-
.../{latest => 10.1.0}/quickstart/configuring.html | 3 +-
.../{latest => 10.1.0}/quickstart/debugging.html | 3 +-
.../docs/{latest => 10.1.0}/quickstart/index.html | 3 +-
.../{latest => 10.1.0}/quickstart/install.html | 3 +-
.../quickstart/organization.html | 3 +-
.../{latest => 10.1.0}/quickstart/running.html | 5 +-
.../docs/{latest => 10.1.0}/reference/index.html | 3 +-
.../{latest => 10.1.0}/reference/os/addrenv.html | 3 +-
.../{latest => 10.1.0}/reference/os/app_vs_os.html | 3 +-
.../docs/{latest => 10.1.0}/reference/os/arch.html | 46 +-
.../{latest => 10.1.0}/reference/os/board.html | 3 +-
.../reference/os/conventions.html | 3 +-
.../{latest => 10.1.0}/reference/os/index.html | 5 +-
.../docs/{latest => 10.1.0}/reference/os/iob.html | 7 +-
.../docs/{latest => 10.1.0}/reference/os/led.html | 3 +-
.../{latest => 10.1.0}/reference/os/nuttx.html | 3 +-
.../{latest => 10.1.0}/reference/os/paging.html | 3 +-
.../docs/{latest => 10.1.0}/reference/os/shm.html | 3 +-
.../docs/{latest => 10.1.0}/reference/os/smp.html | 3 +-
.../reference/os/time_clock.html | 3 +-
.../{latest => 10.1.0}/reference/os/wqueue.html | 5 +-
.../reference/user/01_task_control.html | 3 +-
.../reference/user/02_task_scheduling.html | 3 +-
.../reference/user/03_task_control.html | 3 +-
.../reference/user/04_message_queue.html | 94 +-
.../reference/user/05_counting_semaphore.html | 3 +-
.../reference/user/06_clocks_timers.html | 3 +-
.../reference/user/07_signals.html | 7 +-
.../reference/user/08_pthread.html | 3 +-
.../reference/user/09_env_vars.html | 3 +-
.../reference/user/10_filesystem.html | 3 +-
.../reference/user/11_network.html | 3 +-
.../reference/user/12_shared_memory.html | 3 +-
.../reference/user/13_boardctl.html | 3 +-
.../reference/user/13_logging.html | 3 +-
.../{latest => 10.1.0}/reference/user/index.html | 3 +-
.../reference/user/structures.html | 5 +-
content/docs/{latest => 10.1.0}/search.html | 3 +-
content/docs/10.1.0/searchindex.js | 1 +
content/docs/{latest => 10.1.0}/substitutions.html | 3 +-
content/docs/latest/applications/index.html | 2 +
content/docs/latest/applications/nsh/builtin.html | 2 +
content/docs/latest/applications/nsh/commands.html | 2 +
content/docs/latest/applications/nsh/config.html | 2 +
.../docs/latest/applications/nsh/customizing.html | 2 +
content/docs/latest/applications/nsh/index.html | 2 +
.../docs/latest/applications/nsh/installation.html | 2 +
content/docs/latest/applications/nsh/login.html | 2 +
content/docs/latest/applications/nsh/nsh.html | 2 +
content/docs/latest/components/binfmt.html | 2 +
.../latest/components/drivers/block/index.html | 2 +
.../components/drivers/character/analog.html | 2 +
.../latest/components/drivers/character/can.html | 2 +
.../latest/components/drivers/character/foc.html | 2 +
.../latest/components/drivers/character/index.html | 2 +
.../components/drivers/character/keypad.html | 2 +
.../latest/components/drivers/character/note.html | 2 +
.../latest/components/drivers/character/pwm.html | 2 +
.../components/drivers/character/quadrature.html | 2 +
.../latest/components/drivers/character/rtc.html | 2 +
.../components/drivers/character/serial.html | 2 +
.../latest/components/drivers/character/timer.html | 2 +
.../components/drivers/character/touchscreen.html | 2 +
.../components/drivers/character/watchdog.html | 2 +
content/docs/latest/components/drivers/index.html | 2 +
.../components/drivers/special/ethernet.html | 2 +
.../components/drivers/special/framebuffer.html | 2 +
.../latest/components/drivers/special/i2c.html | 2 +
.../latest/components/drivers/special/index.html | 2 +
.../latest/components/drivers/special/lcd.html | 2 +
.../latest/components/drivers/special/mtd.html | 2 +
.../latest/components/drivers/special/sdio.html | 2 +
.../components/drivers/special/socketcan.html | 2 +
.../latest/components/drivers/special/spi.html | 2 +
.../latest/components/drivers/special/syslog.html | 2 +
.../latest/components/drivers/special/usbdev.html | 2 +
.../latest/components/drivers/special/usbhost.html | 2 +
content/docs/latest/components/filesystem.html | 2 +
content/docs/latest/components/index.html | 2 +
content/docs/latest/components/nxflat.html | 2 +
.../latest/components/nxgraphics/appendix.html | 2 +
.../docs/latest/components/nxgraphics/index.html | 2 +
content/docs/latest/components/nxgraphics/nx.html | 2 +
.../latest/components/nxgraphics/nxcursor.html | 2 +
.../docs/latest/components/nxgraphics/nxfonts.html | 2 +
.../docs/latest/components/nxgraphics/nxgl.html | 2 +
.../docs/latest/components/nxgraphics/nxtk.html | 2 +
.../docs/latest/components/nxgraphics/sample.html | 2 +
content/docs/latest/components/nxwidgets.html | 2 +
content/docs/latest/components/paging.html | 2 +
content/docs/latest/components/power.html | 2 +
content/docs/latest/contributing/coding_style.html | 2 +
.../docs/latest/contributing/documentation.html | 2 +
content/docs/latest/contributing/index.html | 2 +
.../docs/latest/contributing/making-changes.html | 2 +
content/docs/latest/contributing/workflow.html | 2 +
content/docs/latest/faq/index.html | 2 +
content/docs/latest/genindex.html | 2 +
content/docs/latest/glossary.html | 2 +
content/docs/latest/guides/cpp_cmake.html | 2 +
content/docs/latest/guides/drivers.html | 2 +
content/docs/latest/guides/index.html | 2 +
content/docs/latest/guides/nfs.html | 2 +
content/docs/latest/guides/simulator.html | 2 +
content/docs/latest/guides/tasktrace.html | 2 +
content/docs/latest/guides/tasktraceinternal.html | 2 +
content/docs/latest/guides/tasktraceuser.html | 2 +
content/docs/latest/guides/usbtrace.html | 2 +
content/docs/latest/index.html | 4 +-
content/docs/latest/introduction/about.html | 2 +
.../docs/latest/introduction/detailed_support.html | 2 +
.../introduction/development_environments.html | 2 +
content/docs/latest/introduction/index.html | 2 +
content/docs/latest/introduction/inviolables.html | 2 +
content/docs/latest/introduction/licensing.html | 2 +
content/docs/latest/introduction/resources.html | 2 +
.../latest/introduction/supported_platforms.html | 2 +
content/docs/latest/introduction/trademarks.html | 2 +
.../arm/imxrt/boards/imxrt1020-evk/index.html | 2 +
.../arm/imxrt/boards/imxrt1050-evk/index.html | 2 +
.../arm/imxrt/boards/imxrt1060-evk/index.html | 2 +
.../arm/imxrt/boards/imxrt1064-evk/index.html | 2 +
.../arm/imxrt/boards/teensy-4.x/index.html | 2 +
content/docs/latest/platforms/arm/imxrt/index.html | 2 +
content/docs/latest/platforms/arm/index.html | 2 +
.../arm/nrf52/boards/nrf52832-mdk/index.html | 2 +
.../arm/nrf52/boards/nrf52832-sparkfun/index.html | 2 +
content/docs/latest/platforms/arm/nrf52/index.html | 2 +
content/docs/latest/platforms/index.html | 2 +
.../docs/latest/platforms/risc-v/bl602/index.html | 2 +
.../esp32c3/boards/esp32c3-devkit/index.html | 2 +
.../latest/platforms/risc-v/esp32c3/index.html | 2 +
content/docs/latest/platforms/risc-v/index.html | 2 +
.../platforms/risc-v/mpfs/boards/icicle/index.html | 2 +
.../docs/latest/platforms/risc-v/mpfs/index.html | 2 +
.../xtensa/esp32/boards/esp32-devkitc/index.html | 2 +
.../esp32/boards/esp32-wrover-kit/index.html | 2 +
.../docs/latest/platforms/xtensa/esp32/index.html | 2 +
content/docs/latest/platforms/xtensa/index.html | 2 +
content/docs/latest/quickstart/compiling.html | 2 +
content/docs/latest/quickstart/configuring.html | 2 +
content/docs/latest/quickstart/debugging.html | 2 +
content/docs/latest/quickstart/index.html | 2 +
content/docs/latest/quickstart/install.html | 2 +
content/docs/latest/quickstart/organization.html | 2 +
content/docs/latest/quickstart/running.html | 2 +
content/docs/latest/reference/index.html | 2 +
content/docs/latest/reference/os/addrenv.html | 2 +
content/docs/latest/reference/os/app_vs_os.html | 2 +
content/docs/latest/reference/os/arch.html | 2 +
content/docs/latest/reference/os/board.html | 2 +
content/docs/latest/reference/os/conventions.html | 2 +
content/docs/latest/reference/os/index.html | 2 +
content/docs/latest/reference/os/iob.html | 2 +
content/docs/latest/reference/os/led.html | 2 +
content/docs/latest/reference/os/nuttx.html | 2 +
content/docs/latest/reference/os/paging.html | 2 +
content/docs/latest/reference/os/shm.html | 2 +
content/docs/latest/reference/os/smp.html | 2 +
content/docs/latest/reference/os/time_clock.html | 2 +
content/docs/latest/reference/os/wqueue.html | 2 +
.../latest/reference/user/01_task_control.html | 2 +
.../latest/reference/user/02_task_scheduling.html | 2 +
.../latest/reference/user/03_task_control.html | 2 +
.../latest/reference/user/04_message_queue.html | 2 +
.../reference/user/05_counting_semaphore.html | 2 +
.../latest/reference/user/06_clocks_timers.html | 2 +
content/docs/latest/reference/user/07_signals.html | 2 +
content/docs/latest/reference/user/08_pthread.html | 2 +
.../docs/latest/reference/user/09_env_vars.html | 2 +
.../docs/latest/reference/user/10_filesystem.html | 2 +
content/docs/latest/reference/user/11_network.html | 2 +
.../latest/reference/user/12_shared_memory.html | 2 +
.../docs/latest/reference/user/13_boardctl.html | 2 +
content/docs/latest/reference/user/13_logging.html | 2 +
content/docs/latest/reference/user/index.html | 2 +
content/docs/latest/reference/user/structures.html | 2 +
content/docs/latest/search.html | 2 +
content/docs/latest/substitutions.html | 2 +
content/feed.xml | 4 +-
606 files changed, 52746 insertions(+), 316 deletions(-)
diff --git a/content/docs/10.0.0/index.html b/content/docs/10.0.0/index.html
index 48dc26c..caef3c9 100644
--- a/content/docs/10.0.0/index.html
+++ b/content/docs/10.0.0/index.html
@@ -207,7 +207,7 @@ by following these <a class="reference internal" href="contributing/documentatio
<div class="section" id="nuttx-documentation">
<h1>NuttX Documentation<a class="headerlink" href="#nuttx-documentation" title="Permalink to this headline">¶</a></h1>
<p>NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller environments, the primary governing standards in NuttX are Posix and ANSI standards. Additional standard APIs from Unix and other common RTOS’s (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).</p>
-<p>Last Updated: 26 May 21 at 00:53</p>
+<p>Last Updated: 27 May 21 at 00:56</p>
<div class="toctree-wrapper compound">
<p class="caption"><span class="caption-text">Table of Contents</span></p>
<ul class="current">
diff --git a/content/docs/10.0.1/applications/index.html b/content/docs/10.0.1/applications/index.html
index 9dc3589..398c34e 100644
--- a/content/docs/10.0.1/applications/index.html
+++ b/content/docs/10.0.1/applications/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/boards/index.html b/content/docs/10.0.1/boards/index.html
index db14ca2..cbb5298 100644
--- a/content/docs/10.0.1/boards/index.html
+++ b/content/docs/10.0.1/boards/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/binfmt.html b/content/docs/10.0.1/components/binfmt.html
index 5d50e81..78fd549 100644
--- a/content/docs/10.0.1/components/binfmt.html
+++ b/content/docs/10.0.1/components/binfmt.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/block/index.html b/content/docs/10.0.1/components/drivers/block/index.html
index ac5db68..c8cba05 100644
--- a/content/docs/10.0.1/components/drivers/block/index.html
+++ b/content/docs/10.0.1/components/drivers/block/index.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/analog.html b/content/docs/10.0.1/components/drivers/character/analog.html
index 7416ab7..6023b0c 100644
--- a/content/docs/10.0.1/components/drivers/character/analog.html
+++ b/content/docs/10.0.1/components/drivers/character/analog.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/can.html b/content/docs/10.0.1/components/drivers/character/can.html
index d015147..247eb0b 100644
--- a/content/docs/10.0.1/components/drivers/character/can.html
+++ b/content/docs/10.0.1/components/drivers/character/can.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/index.html b/content/docs/10.0.1/components/drivers/character/index.html
index abc24d8..19b70ec 100644
--- a/content/docs/10.0.1/components/drivers/character/index.html
+++ b/content/docs/10.0.1/components/drivers/character/index.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/keypad.html b/content/docs/10.0.1/components/drivers/character/keypad.html
index c7bded5..e7d8736 100644
--- a/content/docs/10.0.1/components/drivers/character/keypad.html
+++ b/content/docs/10.0.1/components/drivers/character/keypad.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/pwm.html b/content/docs/10.0.1/components/drivers/character/pwm.html
index 79e8777..730efa6 100644
--- a/content/docs/10.0.1/components/drivers/character/pwm.html
+++ b/content/docs/10.0.1/components/drivers/character/pwm.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/quadrature.html b/content/docs/10.0.1/components/drivers/character/quadrature.html
index 25bb9fa..7ec1d05 100644
--- a/content/docs/10.0.1/components/drivers/character/quadrature.html
+++ b/content/docs/10.0.1/components/drivers/character/quadrature.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/rtc.html b/content/docs/10.0.1/components/drivers/character/rtc.html
index 0bb6852..dc0c8f8 100644
--- a/content/docs/10.0.1/components/drivers/character/rtc.html
+++ b/content/docs/10.0.1/components/drivers/character/rtc.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/serial.html b/content/docs/10.0.1/components/drivers/character/serial.html
index b129ee5..2f3037d 100644
--- a/content/docs/10.0.1/components/drivers/character/serial.html
+++ b/content/docs/10.0.1/components/drivers/character/serial.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/timer.html b/content/docs/10.0.1/components/drivers/character/timer.html
index 6b5fa06..d3200d6 100644
--- a/content/docs/10.0.1/components/drivers/character/timer.html
+++ b/content/docs/10.0.1/components/drivers/character/timer.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/touchscreen.html b/content/docs/10.0.1/components/drivers/character/touchscreen.html
index e28e3a5..3e3ceb5 100644
--- a/content/docs/10.0.1/components/drivers/character/touchscreen.html
+++ b/content/docs/10.0.1/components/drivers/character/touchscreen.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/character/watchdog.html b/content/docs/10.0.1/components/drivers/character/watchdog.html
index dd7f665..e6b148c 100644
--- a/content/docs/10.0.1/components/drivers/character/watchdog.html
+++ b/content/docs/10.0.1/components/drivers/character/watchdog.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/index.html b/content/docs/10.0.1/components/drivers/index.html
index 12c9ddd..86f0042 100644
--- a/content/docs/10.0.1/components/drivers/index.html
+++ b/content/docs/10.0.1/components/drivers/index.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/ethernet.html b/content/docs/10.0.1/components/drivers/special/ethernet.html
index bdffe42..67795a9 100644
--- a/content/docs/10.0.1/components/drivers/special/ethernet.html
+++ b/content/docs/10.0.1/components/drivers/special/ethernet.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/framebuffer.html b/content/docs/10.0.1/components/drivers/special/framebuffer.html
index 16d80b9..e5d6d24 100644
--- a/content/docs/10.0.1/components/drivers/special/framebuffer.html
+++ b/content/docs/10.0.1/components/drivers/special/framebuffer.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/i2c.html b/content/docs/10.0.1/components/drivers/special/i2c.html
index 5edd85a..2d2405e 100644
--- a/content/docs/10.0.1/components/drivers/special/i2c.html
+++ b/content/docs/10.0.1/components/drivers/special/i2c.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/index.html b/content/docs/10.0.1/components/drivers/special/index.html
index a6d8fe7..7e589fb 100644
--- a/content/docs/10.0.1/components/drivers/special/index.html
+++ b/content/docs/10.0.1/components/drivers/special/index.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/lcd.html b/content/docs/10.0.1/components/drivers/special/lcd.html
index e09313a..e9b1c95 100644
--- a/content/docs/10.0.1/components/drivers/special/lcd.html
+++ b/content/docs/10.0.1/components/drivers/special/lcd.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/mtd.html b/content/docs/10.0.1/components/drivers/special/mtd.html
index ba61400..c919120 100644
--- a/content/docs/10.0.1/components/drivers/special/mtd.html
+++ b/content/docs/10.0.1/components/drivers/special/mtd.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/sdio.html b/content/docs/10.0.1/components/drivers/special/sdio.html
index 8fdb883..08c0c1a 100644
--- a/content/docs/10.0.1/components/drivers/special/sdio.html
+++ b/content/docs/10.0.1/components/drivers/special/sdio.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/spi.html b/content/docs/10.0.1/components/drivers/special/spi.html
index 086048a..4479c60 100644
--- a/content/docs/10.0.1/components/drivers/special/spi.html
+++ b/content/docs/10.0.1/components/drivers/special/spi.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/usbdev.html b/content/docs/10.0.1/components/drivers/special/usbdev.html
index fdbd90c..4e2dd1e 100644
--- a/content/docs/10.0.1/components/drivers/special/usbdev.html
+++ b/content/docs/10.0.1/components/drivers/special/usbdev.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/drivers/special/usbhost.html b/content/docs/10.0.1/components/drivers/special/usbhost.html
index fdf77dc..fa98f49 100644
--- a/content/docs/10.0.1/components/drivers/special/usbhost.html
+++ b/content/docs/10.0.1/components/drivers/special/usbhost.html
@@ -97,6 +97,8 @@
<option value="../../../../10.0.1" >10.0.1</option>
+ <option value="../../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/filesystem.html b/content/docs/10.0.1/components/filesystem.html
index 4e011f4..8f52a99 100644
--- a/content/docs/10.0.1/components/filesystem.html
+++ b/content/docs/10.0.1/components/filesystem.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/index.html b/content/docs/10.0.1/components/index.html
index 7aebaee..a5e137a 100644
--- a/content/docs/10.0.1/components/index.html
+++ b/content/docs/10.0.1/components/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nsh/builtin.html b/content/docs/10.0.1/components/nsh/builtin.html
index f0a49bf..dd2dcf2 100644
--- a/content/docs/10.0.1/components/nsh/builtin.html
+++ b/content/docs/10.0.1/components/nsh/builtin.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nsh/commands.html b/content/docs/10.0.1/components/nsh/commands.html
index d7cdbbb..3af0663 100644
--- a/content/docs/10.0.1/components/nsh/commands.html
+++ b/content/docs/10.0.1/components/nsh/commands.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nsh/config.html b/content/docs/10.0.1/components/nsh/config.html
index f111fff..6a4a373 100644
--- a/content/docs/10.0.1/components/nsh/config.html
+++ b/content/docs/10.0.1/components/nsh/config.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nsh/customizing.html b/content/docs/10.0.1/components/nsh/customizing.html
index 90e7676..2e5c24e 100644
--- a/content/docs/10.0.1/components/nsh/customizing.html
+++ b/content/docs/10.0.1/components/nsh/customizing.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nsh/index.html b/content/docs/10.0.1/components/nsh/index.html
index 5292d44..56d4b9b 100644
--- a/content/docs/10.0.1/components/nsh/index.html
+++ b/content/docs/10.0.1/components/nsh/index.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nsh/installation.html b/content/docs/10.0.1/components/nsh/installation.html
index 1b76e2c..eae9f64 100644
--- a/content/docs/10.0.1/components/nsh/installation.html
+++ b/content/docs/10.0.1/components/nsh/installation.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nsh/login.html b/content/docs/10.0.1/components/nsh/login.html
index fbaa7c5..9306558 100644
--- a/content/docs/10.0.1/components/nsh/login.html
+++ b/content/docs/10.0.1/components/nsh/login.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nsh/nsh.html b/content/docs/10.0.1/components/nsh/nsh.html
index ebf0c4a..bbd6f67 100644
--- a/content/docs/10.0.1/components/nsh/nsh.html
+++ b/content/docs/10.0.1/components/nsh/nsh.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxflat.html b/content/docs/10.0.1/components/nxflat.html
index 628b452..22f4532 100644
--- a/content/docs/10.0.1/components/nxflat.html
+++ b/content/docs/10.0.1/components/nxflat.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxgraphics/appendix.html b/content/docs/10.0.1/components/nxgraphics/appendix.html
index 6400b88..893548b 100644
--- a/content/docs/10.0.1/components/nxgraphics/appendix.html
+++ b/content/docs/10.0.1/components/nxgraphics/appendix.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxgraphics/index.html b/content/docs/10.0.1/components/nxgraphics/index.html
index ade2821..f541ead 100644
--- a/content/docs/10.0.1/components/nxgraphics/index.html
+++ b/content/docs/10.0.1/components/nxgraphics/index.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxgraphics/nx.html b/content/docs/10.0.1/components/nxgraphics/nx.html
index 119e9e6..f756de5 100644
--- a/content/docs/10.0.1/components/nxgraphics/nx.html
+++ b/content/docs/10.0.1/components/nxgraphics/nx.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxgraphics/nxcursor.html b/content/docs/10.0.1/components/nxgraphics/nxcursor.html
index bcc9561..69c88f3 100644
--- a/content/docs/10.0.1/components/nxgraphics/nxcursor.html
+++ b/content/docs/10.0.1/components/nxgraphics/nxcursor.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxgraphics/nxfonts.html b/content/docs/10.0.1/components/nxgraphics/nxfonts.html
index ee982ca..851f5e3 100644
--- a/content/docs/10.0.1/components/nxgraphics/nxfonts.html
+++ b/content/docs/10.0.1/components/nxgraphics/nxfonts.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxgraphics/nxgl.html b/content/docs/10.0.1/components/nxgraphics/nxgl.html
index e4c2bda..e9c8cb3 100644
--- a/content/docs/10.0.1/components/nxgraphics/nxgl.html
+++ b/content/docs/10.0.1/components/nxgraphics/nxgl.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxgraphics/nxtk.html b/content/docs/10.0.1/components/nxgraphics/nxtk.html
index b8b4aae..5a4713e 100644
--- a/content/docs/10.0.1/components/nxgraphics/nxtk.html
+++ b/content/docs/10.0.1/components/nxgraphics/nxtk.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxgraphics/sample.html b/content/docs/10.0.1/components/nxgraphics/sample.html
index b68e8f9..b133681 100644
--- a/content/docs/10.0.1/components/nxgraphics/sample.html
+++ b/content/docs/10.0.1/components/nxgraphics/sample.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/nxwidgets.html b/content/docs/10.0.1/components/nxwidgets.html
index 5faced8..d5447c0 100644
--- a/content/docs/10.0.1/components/nxwidgets.html
+++ b/content/docs/10.0.1/components/nxwidgets.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/paging.html b/content/docs/10.0.1/components/paging.html
index cb1de6f..4f90ea3 100644
--- a/content/docs/10.0.1/components/paging.html
+++ b/content/docs/10.0.1/components/paging.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/power.html b/content/docs/10.0.1/components/power.html
index e1758c7..64e9478 100644
--- a/content/docs/10.0.1/components/power.html
+++ b/content/docs/10.0.1/components/power.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/socketcan.html b/content/docs/10.0.1/components/socketcan.html
index 3ac33ba..63786ac 100644
--- a/content/docs/10.0.1/components/socketcan.html
+++ b/content/docs/10.0.1/components/socketcan.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/components/syslog.html b/content/docs/10.0.1/components/syslog.html
index dc29198..9b5b766 100644
--- a/content/docs/10.0.1/components/syslog.html
+++ b/content/docs/10.0.1/components/syslog.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/contributing/coding_style.html b/content/docs/10.0.1/contributing/coding_style.html
index ae06840..16b2313 100644
--- a/content/docs/10.0.1/contributing/coding_style.html
+++ b/content/docs/10.0.1/contributing/coding_style.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/contributing/documentation.html b/content/docs/10.0.1/contributing/documentation.html
index 99af3f4..a70346f 100644
--- a/content/docs/10.0.1/contributing/documentation.html
+++ b/content/docs/10.0.1/contributing/documentation.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/contributing/index.html b/content/docs/10.0.1/contributing/index.html
index 4bdec64..9dc1f76 100644
--- a/content/docs/10.0.1/contributing/index.html
+++ b/content/docs/10.0.1/contributing/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/contributing/making-changes.html b/content/docs/10.0.1/contributing/making-changes.html
index e79a518..bba27c3 100644
--- a/content/docs/10.0.1/contributing/making-changes.html
+++ b/content/docs/10.0.1/contributing/making-changes.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/contributing/workflow.html b/content/docs/10.0.1/contributing/workflow.html
index 991a225..34e623e 100644
--- a/content/docs/10.0.1/contributing/workflow.html
+++ b/content/docs/10.0.1/contributing/workflow.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/genindex.html b/content/docs/10.0.1/genindex.html
index 099d35b..9a41e0c 100644
--- a/content/docs/10.0.1/genindex.html
+++ b/content/docs/10.0.1/genindex.html
@@ -97,6 +97,8 @@
<option value="./../10.0.1" >10.0.1</option>
+ <option value="./../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/glossary.html b/content/docs/10.0.1/glossary.html
index 431dcb1..1105dff 100644
--- a/content/docs/10.0.1/glossary.html
+++ b/content/docs/10.0.1/glossary.html
@@ -96,6 +96,8 @@
<option value="./../10.0.1" >10.0.1</option>
+ <option value="./../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/guides/drivers.html b/content/docs/10.0.1/guides/drivers.html
index 5a5467d..6058068 100644
--- a/content/docs/10.0.1/guides/drivers.html
+++ b/content/docs/10.0.1/guides/drivers.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/guides/index.html b/content/docs/10.0.1/guides/index.html
index 6ca074c..44ea1c2 100644
--- a/content/docs/10.0.1/guides/index.html
+++ b/content/docs/10.0.1/guides/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/guides/nfs.html b/content/docs/10.0.1/guides/nfs.html
index 559c56c..2b4e030 100644
--- a/content/docs/10.0.1/guides/nfs.html
+++ b/content/docs/10.0.1/guides/nfs.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/guides/simulator.html b/content/docs/10.0.1/guides/simulator.html
index a180b71..41192d1 100644
--- a/content/docs/10.0.1/guides/simulator.html
+++ b/content/docs/10.0.1/guides/simulator.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/guides/usbtrace.html b/content/docs/10.0.1/guides/usbtrace.html
index 6ec8265..e6d64d8 100644
--- a/content/docs/10.0.1/guides/usbtrace.html
+++ b/content/docs/10.0.1/guides/usbtrace.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/index.html b/content/docs/10.0.1/index.html
index c6d11d5..9579181 100644
--- a/content/docs/10.0.1/index.html
+++ b/content/docs/10.0.1/index.html
@@ -96,6 +96,8 @@
<option value="./../10.0.1" >10.0.1</option>
+ <option value="./../10.1.0" >10.1.0</option>
+
</select>
</div>
@@ -211,7 +213,7 @@ by following these <a class="reference internal" href="contributing/documentatio
<div class="section" id="nuttx-documentation">
<h1>NuttX Documentation<a class="headerlink" href="#nuttx-documentation" title="Permalink to this headline">¶</a></h1>
<p>NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller environments, the primary governing standards in NuttX are Posix and ANSI standards. Additional standard APIs from Unix and other common RTOS’s (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).</p>
-<p>Last Updated: 26 May 21 at 00:53</p>
+<p>Last Updated: 27 May 21 at 00:56</p>
<div class="toctree-wrapper compound">
<p class="caption"><span class="caption-text">Table of Contents</span></p>
<ul class="current">
diff --git a/content/docs/10.0.1/introduction/about.html b/content/docs/10.0.1/introduction/about.html
index e011d06..853f170 100644
--- a/content/docs/10.0.1/introduction/about.html
+++ b/content/docs/10.0.1/introduction/about.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/introduction/detailed_support.html b/content/docs/10.0.1/introduction/detailed_support.html
index 849b904..bc6ffa9 100644
--- a/content/docs/10.0.1/introduction/detailed_support.html
+++ b/content/docs/10.0.1/introduction/detailed_support.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/introduction/development_environments.html b/content/docs/10.0.1/introduction/development_environments.html
index 3de5cbf..fc5673f 100644
--- a/content/docs/10.0.1/introduction/development_environments.html
+++ b/content/docs/10.0.1/introduction/development_environments.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/introduction/index.html b/content/docs/10.0.1/introduction/index.html
index 617e0fd..83ee85d 100644
--- a/content/docs/10.0.1/introduction/index.html
+++ b/content/docs/10.0.1/introduction/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/introduction/inviolables.html b/content/docs/10.0.1/introduction/inviolables.html
index 18f0bcc..67c324b 100644
--- a/content/docs/10.0.1/introduction/inviolables.html
+++ b/content/docs/10.0.1/introduction/inviolables.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/introduction/licensing.html b/content/docs/10.0.1/introduction/licensing.html
index 35307d0..a6368c3 100644
--- a/content/docs/10.0.1/introduction/licensing.html
+++ b/content/docs/10.0.1/introduction/licensing.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/introduction/resources.html b/content/docs/10.0.1/introduction/resources.html
index b800b89..06ac6c9 100644
--- a/content/docs/10.0.1/introduction/resources.html
+++ b/content/docs/10.0.1/introduction/resources.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/introduction/supported_platforms.html b/content/docs/10.0.1/introduction/supported_platforms.html
index 33056df..640cbaf 100644
--- a/content/docs/10.0.1/introduction/supported_platforms.html
+++ b/content/docs/10.0.1/introduction/supported_platforms.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/introduction/trademarks.html b/content/docs/10.0.1/introduction/trademarks.html
index 9895333..e8e667d 100644
--- a/content/docs/10.0.1/introduction/trademarks.html
+++ b/content/docs/10.0.1/introduction/trademarks.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/build_and_make.html b/content/docs/10.0.1/quickstart/build_and_make.html
index b618f4b..3e61ce1 100644
--- a/content/docs/10.0.1/quickstart/build_and_make.html
+++ b/content/docs/10.0.1/quickstart/build_and_make.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/compiling.html b/content/docs/10.0.1/quickstart/compiling.html
index 74f8591..b87e311 100644
--- a/content/docs/10.0.1/quickstart/compiling.html
+++ b/content/docs/10.0.1/quickstart/compiling.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/configuring.html b/content/docs/10.0.1/quickstart/configuring.html
index 41d0ba1..0a52375 100644
--- a/content/docs/10.0.1/quickstart/configuring.html
+++ b/content/docs/10.0.1/quickstart/configuring.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/debugging.html b/content/docs/10.0.1/quickstart/debugging.html
index 7bcd2e9..76e8c32 100644
--- a/content/docs/10.0.1/quickstart/debugging.html
+++ b/content/docs/10.0.1/quickstart/debugging.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/index.html b/content/docs/10.0.1/quickstart/index.html
index 070286d..a101083 100644
--- a/content/docs/10.0.1/quickstart/index.html
+++ b/content/docs/10.0.1/quickstart/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/install.html b/content/docs/10.0.1/quickstart/install.html
index 3c23c19..86f942c 100644
--- a/content/docs/10.0.1/quickstart/install.html
+++ b/content/docs/10.0.1/quickstart/install.html
@@ -99,6 +99,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/organization.html b/content/docs/10.0.1/quickstart/organization.html
index e314b04..072478f 100644
--- a/content/docs/10.0.1/quickstart/organization.html
+++ b/content/docs/10.0.1/quickstart/organization.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/quickstart.html b/content/docs/10.0.1/quickstart/quickstart.html
index 5c31ef6..41cb5b2 100644
--- a/content/docs/10.0.1/quickstart/quickstart.html
+++ b/content/docs/10.0.1/quickstart/quickstart.html
@@ -99,6 +99,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/quickstart/running.html b/content/docs/10.0.1/quickstart/running.html
index ccc5163..8dbd1de 100644
--- a/content/docs/10.0.1/quickstart/running.html
+++ b/content/docs/10.0.1/quickstart/running.html
@@ -99,6 +99,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/index.html b/content/docs/10.0.1/reference/index.html
index ff00912..b8c984b 100644
--- a/content/docs/10.0.1/reference/index.html
+++ b/content/docs/10.0.1/reference/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/addrenv.html b/content/docs/10.0.1/reference/os/addrenv.html
index 86f6f8f..ed76ed5 100644
--- a/content/docs/10.0.1/reference/os/addrenv.html
+++ b/content/docs/10.0.1/reference/os/addrenv.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/app_vs_os.html b/content/docs/10.0.1/reference/os/app_vs_os.html
index 92043d8..81c7c22 100644
--- a/content/docs/10.0.1/reference/os/app_vs_os.html
+++ b/content/docs/10.0.1/reference/os/app_vs_os.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/arch.html b/content/docs/10.0.1/reference/os/arch.html
index 602e95e..b28b8ba 100644
--- a/content/docs/10.0.1/reference/os/arch.html
+++ b/content/docs/10.0.1/reference/os/arch.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/board.html b/content/docs/10.0.1/reference/os/board.html
index 38c7c3b..35fda32 100644
--- a/content/docs/10.0.1/reference/os/board.html
+++ b/content/docs/10.0.1/reference/os/board.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/boardctl.html b/content/docs/10.0.1/reference/os/boardctl.html
index 6b95d9e..3dbec81 100644
--- a/content/docs/10.0.1/reference/os/boardctl.html
+++ b/content/docs/10.0.1/reference/os/boardctl.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/conventions.html b/content/docs/10.0.1/reference/os/conventions.html
index 8732c14..4b31714 100644
--- a/content/docs/10.0.1/reference/os/conventions.html
+++ b/content/docs/10.0.1/reference/os/conventions.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/index.html b/content/docs/10.0.1/reference/os/index.html
index 5ae6f7c..339edbe 100644
--- a/content/docs/10.0.1/reference/os/index.html
+++ b/content/docs/10.0.1/reference/os/index.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/iob.html b/content/docs/10.0.1/reference/os/iob.html
index 2a93ad7..a80e957 100644
--- a/content/docs/10.0.1/reference/os/iob.html
+++ b/content/docs/10.0.1/reference/os/iob.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/led.html b/content/docs/10.0.1/reference/os/led.html
index 3478a42..1513ed3 100644
--- a/content/docs/10.0.1/reference/os/led.html
+++ b/content/docs/10.0.1/reference/os/led.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/nuttx.html b/content/docs/10.0.1/reference/os/nuttx.html
index 47d972e..d21b382 100644
--- a/content/docs/10.0.1/reference/os/nuttx.html
+++ b/content/docs/10.0.1/reference/os/nuttx.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/paging.html b/content/docs/10.0.1/reference/os/paging.html
index 244e4e5..1c44086 100644
--- a/content/docs/10.0.1/reference/os/paging.html
+++ b/content/docs/10.0.1/reference/os/paging.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/shm.html b/content/docs/10.0.1/reference/os/shm.html
index 2778b67..db5552b 100644
--- a/content/docs/10.0.1/reference/os/shm.html
+++ b/content/docs/10.0.1/reference/os/shm.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/smp.html b/content/docs/10.0.1/reference/os/smp.html
index 09c8961..0d0c672 100644
--- a/content/docs/10.0.1/reference/os/smp.html
+++ b/content/docs/10.0.1/reference/os/smp.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/time_clock.html b/content/docs/10.0.1/reference/os/time_clock.html
index fd48ae4..1690de2 100644
--- a/content/docs/10.0.1/reference/os/time_clock.html
+++ b/content/docs/10.0.1/reference/os/time_clock.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/os/wqueue.html b/content/docs/10.0.1/reference/os/wqueue.html
index b70508d..7084567 100644
--- a/content/docs/10.0.1/reference/os/wqueue.html
+++ b/content/docs/10.0.1/reference/os/wqueue.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/01_task_control.html b/content/docs/10.0.1/reference/user/01_task_control.html
index c933b88..a2f4c77 100644
--- a/content/docs/10.0.1/reference/user/01_task_control.html
+++ b/content/docs/10.0.1/reference/user/01_task_control.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/02_task_scheduling.html b/content/docs/10.0.1/reference/user/02_task_scheduling.html
index bf32d2a..5c4f9eb 100644
--- a/content/docs/10.0.1/reference/user/02_task_scheduling.html
+++ b/content/docs/10.0.1/reference/user/02_task_scheduling.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/03_task_control.html b/content/docs/10.0.1/reference/user/03_task_control.html
index 0b933c9..e74ea8c 100644
--- a/content/docs/10.0.1/reference/user/03_task_control.html
+++ b/content/docs/10.0.1/reference/user/03_task_control.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/04_message_queue.html b/content/docs/10.0.1/reference/user/04_message_queue.html
index 8de1c4c..f93e369 100644
--- a/content/docs/10.0.1/reference/user/04_message_queue.html
+++ b/content/docs/10.0.1/reference/user/04_message_queue.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/05_counting_semaphore.html b/content/docs/10.0.1/reference/user/05_counting_semaphore.html
index 35af69f..7710980 100644
--- a/content/docs/10.0.1/reference/user/05_counting_semaphore.html
+++ b/content/docs/10.0.1/reference/user/05_counting_semaphore.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/06_clocks_timers.html b/content/docs/10.0.1/reference/user/06_clocks_timers.html
index 36585b8..d76a284 100644
--- a/content/docs/10.0.1/reference/user/06_clocks_timers.html
+++ b/content/docs/10.0.1/reference/user/06_clocks_timers.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/07_signals.html b/content/docs/10.0.1/reference/user/07_signals.html
index 3ddeb45..c2993ea 100644
--- a/content/docs/10.0.1/reference/user/07_signals.html
+++ b/content/docs/10.0.1/reference/user/07_signals.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/08_pthread.html b/content/docs/10.0.1/reference/user/08_pthread.html
index 13be5c4..992178c 100644
--- a/content/docs/10.0.1/reference/user/08_pthread.html
+++ b/content/docs/10.0.1/reference/user/08_pthread.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/09_env_vars.html b/content/docs/10.0.1/reference/user/09_env_vars.html
index 59eb921..b1a792b 100644
--- a/content/docs/10.0.1/reference/user/09_env_vars.html
+++ b/content/docs/10.0.1/reference/user/09_env_vars.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/10_filesystem.html b/content/docs/10.0.1/reference/user/10_filesystem.html
index 704735a..2732765 100644
--- a/content/docs/10.0.1/reference/user/10_filesystem.html
+++ b/content/docs/10.0.1/reference/user/10_filesystem.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/11_network.html b/content/docs/10.0.1/reference/user/11_network.html
index cf04a4f..528562d 100644
--- a/content/docs/10.0.1/reference/user/11_network.html
+++ b/content/docs/10.0.1/reference/user/11_network.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/12_shared_memory.html b/content/docs/10.0.1/reference/user/12_shared_memory.html
index fe741b1..d1982d6 100644
--- a/content/docs/10.0.1/reference/user/12_shared_memory.html
+++ b/content/docs/10.0.1/reference/user/12_shared_memory.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/index.html b/content/docs/10.0.1/reference/user/index.html
index d31c6dc..0ed6f9e 100644
--- a/content/docs/10.0.1/reference/user/index.html
+++ b/content/docs/10.0.1/reference/user/index.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/reference/user/structures.html b/content/docs/10.0.1/reference/user/structures.html
index 73358a9..9871f27 100644
--- a/content/docs/10.0.1/reference/user/structures.html
+++ b/content/docs/10.0.1/reference/user/structures.html
@@ -97,6 +97,8 @@
<option value="../../../10.0.1" >10.0.1</option>
+ <option value="../../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/releases/index.html b/content/docs/10.0.1/releases/index.html
index 91dff58..39e4f80 100644
--- a/content/docs/10.0.1/releases/index.html
+++ b/content/docs/10.0.1/releases/index.html
@@ -97,6 +97,8 @@
<option value="../../10.0.1" >10.0.1</option>
+ <option value="../../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/search.html b/content/docs/10.0.1/search.html
index 54bfc5a..cfe9348 100644
--- a/content/docs/10.0.1/search.html
+++ b/content/docs/10.0.1/search.html
@@ -99,6 +99,8 @@
<option value="./../10.0.1" >10.0.1</option>
+ <option value="./../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.0.1/substitutions.html b/content/docs/10.0.1/substitutions.html
index c30c2e8..1df6ccb 100644
--- a/content/docs/10.0.1/substitutions.html
+++ b/content/docs/10.0.1/substitutions.html
@@ -95,6 +95,8 @@
<option value="./../10.0.1" >10.0.1</option>
+ <option value="./../10.1.0" >10.1.0</option>
+
</select>
</div>
diff --git a/content/docs/10.1.0/_images/NXOrganization.gif b/content/docs/10.1.0/_images/NXOrganization.gif
new file mode 100644
index 0000000..6bae8e5
Binary files /dev/null and b/content/docs/10.1.0/_images/NXOrganization.gif differ
diff --git a/content/docs/10.1.0/_images/NuttXScreenShot.jpg b/content/docs/10.1.0/_images/NuttXScreenShot.jpg
new file mode 100644
index 0000000..f5a9dc1
Binary files /dev/null and b/content/docs/10.1.0/_images/NuttXScreenShot.jpg differ
diff --git a/content/docs/10.1.0/_images/board.jpg b/content/docs/10.1.0/_images/board.jpg
new file mode 100644
index 0000000..4046863
Binary files /dev/null and b/content/docs/10.1.0/_images/board.jpg differ
diff --git a/content/docs/10.1.0/_images/esp32-core-board-v2.jpg b/content/docs/10.1.0/_images/esp32-core-board-v2.jpg
new file mode 100644
index 0000000..7548f35
Binary files /dev/null and b/content/docs/10.1.0/_images/esp32-core-board-v2.jpg differ
diff --git a/content/docs/10.1.0/_images/esp32-devkitc-v4-front.jpg b/content/docs/10.1.0/_images/esp32-devkitc-v4-front.jpg
new file mode 100644
index 0000000..04fb739
Binary files /dev/null and b/content/docs/10.1.0/_images/esp32-devkitc-v4-front.jpg differ
diff --git a/content/docs/10.1.0/_images/menuconfig-debug.png b/content/docs/10.1.0/_images/menuconfig-debug.png
new file mode 100644
index 0000000..23828c2
Binary files /dev/null and b/content/docs/10.1.0/_images/menuconfig-debug.png differ
diff --git a/content/docs/10.1.0/_images/menuconfig.png b/content/docs/10.1.0/_images/menuconfig.png
new file mode 100644
index 0000000..c16c234
Binary files /dev/null and b/content/docs/10.1.0/_images/menuconfig.png differ
diff --git a/content/docs/10.1.0/_images/pinout.webp b/content/docs/10.1.0/_images/pinout.webp
new file mode 100644
index 0000000..52683a3
Binary files /dev/null and b/content/docs/10.1.0/_images/pinout.webp differ
diff --git a/content/docs/10.1.0/_images/pm.png b/content/docs/10.1.0/_images/pm.png
new file mode 100644
index 0000000..d84d864
Binary files /dev/null and b/content/docs/10.1.0/_images/pm.png differ
diff --git a/content/docs/10.1.0/_images/syscall-flat-after.png b/content/docs/10.1.0/_images/syscall-flat-after.png
new file mode 100644
index 0000000..e274db7
Binary files /dev/null and b/content/docs/10.1.0/_images/syscall-flat-after.png differ
diff --git a/content/docs/10.1.0/_images/syscall-flat-before.png b/content/docs/10.1.0/_images/syscall-flat-before.png
new file mode 100644
index 0000000..1ef26e7
Binary files /dev/null and b/content/docs/10.1.0/_images/syscall-flat-before.png differ
diff --git a/content/docs/10.1.0/_images/syscall-protected-after.png b/content/docs/10.1.0/_images/syscall-protected-after.png
new file mode 100644
index 0000000..e5fd903
Binary files /dev/null and b/content/docs/10.1.0/_images/syscall-protected-after.png differ
diff --git a/content/docs/10.1.0/_images/syscall-protected-before.png b/content/docs/10.1.0/_images/syscall-protected-before.png
new file mode 100644
index 0000000..64d5724
Binary files /dev/null and b/content/docs/10.1.0/_images/syscall-protected-before.png differ
diff --git a/content/docs/10.1.0/_images/task-trace-internal.png b/content/docs/10.1.0/_images/task-trace-internal.png
new file mode 100644
index 0000000..e8814c0
Binary files /dev/null and b/content/docs/10.1.0/_images/task-trace-internal.png differ
diff --git a/content/docs/10.1.0/_images/task-trace-overview.png b/content/docs/10.1.0/_images/task-trace-overview.png
new file mode 100644
index 0000000..4f585b7
Binary files /dev/null and b/content/docs/10.1.0/_images/task-trace-overview.png differ
diff --git a/content/docs/10.1.0/_images/trace-compass-screenshot.png b/content/docs/10.1.0/_images/trace-compass-screenshot.png
new file mode 100644
index 0000000..6e8c841
Binary files /dev/null and b/content/docs/10.1.0/_images/trace-compass-screenshot.png differ
diff --git a/content/docs/10.1.0/_sources/applications/index.rst.txt b/content/docs/10.1.0/_sources/applications/index.rst.txt
new file mode 100644
index 0000000..185c92b
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/index.rst.txt
@@ -0,0 +1,15 @@
+.. todo::
+ Applications included in ``apps`` repo should be documented here. This should also include information
+ on how to create a given application.
+
+Applications
+============
+
+NuttX ships a large number of applications covering a wide spectrum of functionality. These can be found in the `apps <https://github.com/apache/incubator-nuttx-apps>`_ repository. At the moment, these are documented in their individual README files so you can find more information at the repository.
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Contents:
+
+ nsh/index.rst
+
diff --git a/content/docs/10.1.0/_sources/applications/nsh/builtin.rst.txt b/content/docs/10.1.0/_sources/applications/nsh/builtin.rst.txt
new file mode 100644
index 0000000..b158b8b
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/nsh/builtin.rst.txt
@@ -0,0 +1,204 @@
+***************************
+NSH "Built-In" Applications
+***************************
+
+**Overview.** In addition to these commands that are a part of NSH,
+external programs can also be executed as NSH commands. These external
+programs are called "Built-In" Applications for historic reasons. That
+terminology is somewhat confusing because the actual NSH commands as
+described above are truly "built-into" NSH whereas these applications
+are really external to NuttX.
+
+These applications are built-into NSH in the sense that they can be
+executed by simply typing the name of the application at the NSH prompt.
+Built-in application support is enabled with these configuration option:
+
+ - ``CONFIG_BUILTIN``: Enable NuttX support for builtin applications.
+ - ``CONFIG_NSH_BUILTIN_APPS``: Enable NSH support for builtin
+ applications.
+
+When these configuration options are set, you will also be able to see
+the built-in applications if you enter "nsh> help". They will appear at
+the bottom of the list of NSH commands under::
+
+ Builtin Apps:
+
+Note that no detailed help information beyond the name of the built-in
+application is provided.
+
+Built-In Applications
+~~~~~~~~~~~~~~~~~~~~~
+
+**Overview.** The underlying logic that supports the NSH built-in
+applications is called "Built-In Applications". The builtin application
+logic can be found at ``apps/builtin``. This logic simply does the
+following:
+
+ #. It supports registration mechanism so that builtin applications can
+ dynamically register themselves at build time, and
+
+ #. Utility functions to look up, list, and execute the builtin
+ applications.
+
+**Built-In Application Utility Functions**. The utility functions
+exported by the builtin application logic are prototyped in
+``nuttx/include/nuttx/lib/builtin.h`` and ``apps/include/builtin.h``.
+These utility functions include:
+
+ - ``int builtin_isavail(FAR const char *appname);`` Checks for
+ availability of application registered as ``appname`` during build
+ time.
+
+ - ``const char *builtin_getname(int index);`` Returns a pointer to a
+ name of built-in application pointed by the ``index``. This is the
+ utility function that is used by NSH in order to list the available
+ built-in applications when "``nsh> help``" is entered.
+
+ - ``int exec_builtin(FAR const char *appname, FAR const char **argv);``
+ Executes built-in builtin application registered during compile time.
+ This is the utility function used by NSH to execute the built-in
+ application.
+
+**Autogenerated Header Files**. Application entry points with their
+requirements are gathered together in two files when NuttX is first
+built:
+
+ #. ``apps/builtin/builtin_proto.h``: Prototypes of application task
+ entry points.
+
+ #. ``apps/builtin/builtin_list.h``: Application specific information and
+ start-up requirements
+
+**Registration of Built-In Applications**. The NuttX build occurs in
+several phases as different build targets are executed: (1) *context*
+when the configuration is established, (2) *depend* when target
+dependencies are generated, and (3) *default* (``all``) when the normal
+compilation and link operations are performed. Built-in application
+information is collected during the make *context* build phase.
+
+An example application that can be "built-in" is be found in the
+``apps/examples/hello directory``. Let's walk through this specific
+cause to illustrate the general way that built-in applications are
+created and how they register themselves so that they can be used from
+NSH.
+
+``apps/examples/hello``. The main routine for apps/examples/hello can be
+found in ``apps/examples/hello/main.c``. The main routine is:
+
+.. code-block:: c
+
+ int hello_main(int argc, char *argv[])
+ {
+ printf("Hello, World!!\n");
+ return 0;
+ }
+
+This is the built in function that will be registered during the
+*context* build phase of the NuttX build. That registration is performed
+by logic in ``apps/examples/hello/Makefile``. But the build system gets
+to that logic through a rather tortuous path:
+
+ #. The top-level context make target is in ``nuttx/Makefile``. All build
+ targets depend upon the *context* build target. For the ``apps/``
+ directory, this build target will execute the *context* target in the
+ ``apps/Makefile``.
+
+ #. The ``apps/Makefile`` will, in turn, execute the *context* targets in
+ all of the configured sub-directories. In our case will include the
+ ``Makefile`` in ``apps/examples``.
+
+ #. And finally, the ``apps/examples/Makefile`` will execute the
+ *context* target in all configured ``example``\ sub-directories,
+ getting us finally to ``apps/examples/Makefile`` which is covered
+ below.
+
+**NOTE**: Since this context build phase can only be executed one time,
+any subsequent configuration changes that you make will, then, not be
+reflected in the build sequence. That is a common area of confusion.
+Before you can instantiate the new configuration, you have to first get
+rid of the old configuration. The most drastic way to this is::
+
+ make distclean
+
+But then you will have to re-configuration NuttX from scratch. But if
+you only want to re-build the configuration in the ``apps/``
+sub-directory, then there is a less labor-intensive way to do that. The
+following NuttX make command will remove the configuration only from the
+``apps/`` directory and will let you continue without re-configuring
+everything::
+
+ make apps_distclean
+
+Logic for the ``context`` target in ``apps/examples/hello/Makefile``
+registers the ``hello_main()`` application in the ``builtin``'s
+``builtin_proto.h``\ and ``builtin_list.h`` files. That logic that does
+that in ``apps/examples/hello/Makefile`` is abstracted below:
+
+ #. First, the ``Makefile`` includes ``apps/Make.defs``::
+
+ include $(APPDIR)/Make.defs
+
+ This defines a macro called ``REGISTER`` that adds data to the
+ *builtin* header files::
+
+ define REGISTER
+ @echo "Register: $1"
+ @echo "{ \"$1\", $2, $3, $4 }," >> "$(APPDIR)/builtin/builtin_list.h"
+ @echo "EXTERN int $4(int argc, char *argv[]);" >> "$(APPDIR)/builtin/builtin_proto.h"
+ endef
+
+ When this macro runs, you will see the output in the build
+ "``Register: hello``", that is a sure sign that the registration was
+ successful.
+
+ #. The make file then defines the application name (``hello``), the task
+ priority (default), and the stack size that will be allocated in the
+ task runs (2K)::
+
+ APPNAME = hello
+ PRIORITY = SCHED_PRIORITY_DEFAULT
+ STACKSIZE = 2048
+
+ #. And finally, the ``Makefile`` invokes the ``REGISTER`` macro to added
+ the ``hello_main()`` builtin application. Then, when the system build
+ completes, the ``hello`` command can be executed from the NSH command
+ line. When the ``hello`` command is executed, it will start the task
+ with entry point ``hello_main()`` with the default priority and with
+ a stack size of 2K::
+
+ context:
+ $(call REGISTER,$(APPNAME),$(PRIORITY),$(STACKSIZE),$(APPNAME)_main)
+
+
+**Other Uses of Built-In Application.** The primary purpose of builtin
+applications is to support command line execution of applications from
+NSH. However, there is one other use of builtin applications that should
+be mentioned.
+
+ #. **binfs**. *binfs* is a tiny file system located at
+ ``apps/builtin/binfs.c``. This provides an alternative what of
+ visualizing installed builtin applications. Without *binfs*, you can
+ see the installed builtin applications using the NSH help command.
+ *binfs* will create a tiny pseudo-file system mounted at ``/bin``.
+ Using *binfs*, you can see the available builtin applications by
+ listing the contents of ``/bin`` directory. This gives some
+ superficial Unix-like compatibility, but does not really add any new
+ functionality.
+
+Synchronous Built-In Applications
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By default, built-in commands started from the NSH command line will run
+asynchronously with NSH. If you want to force NSH to execute commands
+then wait for the command to execute, you can enable that feature by
+adding the following to the NuttX configuration file::
+
+ CONFIG_SCHED_WAITPID=y
+
+This configuration option enables support for the standard ``waitpid()``
+RTOS interface. When that interface is enabled, NSH will use it to wait,
+sleeping until the built-in application executes to completion.
+
+Of course, even with ``CONFIG_SCHED_WAITPID=y`` defined, specific
+applications can still be forced to run asynchronously by adding the
+ampersand (&) after the NSH command.
diff --git a/content/docs/10.1.0/_sources/applications/nsh/commands.rst.txt b/content/docs/10.1.0/_sources/applications/nsh/commands.rst.txt
new file mode 100644
index 0000000..3524128
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/nsh/commands.rst.txt
@@ -0,0 +1,1843 @@
+========
+Commands
+========
+
+.. _cmdtest:
+
+Evaluate Expression (test)
+**************************
+
+**Command Syntax:**
+
+.. code-block:: fish
+
+ [ <expression> ]
+ test <expression>
+
+**Synopsis**. These are two alternative forms of the same command.
+They support evaluation of a boolean expression which sets
+``$?``. This command is used most frequently as
+the conditional command following the ``if`` in the
+``if-then[-else]-fi``.
+
+**Expression Syntax:**
+
+::
+
+ expression = simple-expression | !expression | expression -o expression | expression -a expression
+
+ simple-expression = unary-expression | binary-expression
+
+ unary-expression = string-unary | file-unary
+
+ string-unary = -n string | -z string
+
+ file-unary = -b file | -c file | -d file | -e file | -f file | -r file | -s file | -w file
+
+ binary-expression = string-binary | numeric-binary
+
+ string-binary = string = string | string == string | string != string
+
+ numeric-binary = integer -eq integer | integer -ge integer | integer -gt integer | integer -le integer | integer -lt integer | integer -ne integer
+
+.. _cmdaddroute:
+
+Add a Routing Table Entry (addroute)
+************************************
+
+**Command Syntax:**
+
+::
+
+ addroute <target> [<netmask>] <router>
+ addroute default <ipaddr> <interface>
+
+**Synopsis**. This command adds an entry in the routing table. The
+new entry will map the IP address of a router on a local network
+(<router>) to an external network characterized by the <target> IP
+address and a network mask <netmask>
+
+The netmask may also be expressed using IPv4 CIDR or IPv6 slash
+notation. In that case, the netmask need not be provided.
+
+**Example:**
+
+::
+
+ nsh> addroute addroute 11.0.0.0 255.255.255.0 10.0.0.2
+
+which is equivalent to
+
+::
+
+ nsh> addroute 11.0.0.0/24 10.0.0.2
+
+The second form of the addroute command can be used to set the
+default gateway.
+
+.. _cmdarp:
+
+Access the ARP table (arp)
+**************************
+
+**Command syntax**::
+
+ arp [-t|-a <ipaddr> |-d <ipaddr> |-s <ipaddr> <hwaddr>]
+
+**Synopsis**: Access the OS ARP table.
+
+ -a <ipaddr> Will show the hardware address that the IP address <ipaddr> is
+ mapped to.
+ -d <ipaddr> Will delete the mapping for the IP address <ipaddr> from the
+ ARP table.
+ -s <ipaddr hwaddr> Will set (or replace) the mapping of the IP address <ipaddr> to
+ the hardware address <hwaddr>.
+ -t Will dump the entire content of the ARP table. This option is
+ only available if ``CONFIG_NETLINK_ROUTE`` is enabled.
+
+**Example**::
+
+ nsh> arp -a 10.0.0.1
+ nsh: arp: no such ARP entry: 10.0.0.1
+
+ nsh> arp -s 10.0.0.1 00:13:3b:12:73:e6
+ nsh> arp -a 10.0.0.1
+ HWAddr: 00:13:3b:12:73:e6
+
+ nsh> arp -d 10.0.0.1
+ nsh> arp -a 10.0.0.1
+ nsh: arp: no such ARP entry: 10.0.0.1
+
+.. _cmdbase64dec:
+
+Base64 Decode (base64dec)
+*************************
+
+**Command Syntax**::
+
+ base64dec [-w] [-f] <string or filepath>
+
+**Synopsis**. *To be provided.*
+
+.. _cmdbase64enc:
+
+Base64 Encode (base64enc)
+*************************
+
+**Command Syntax**::
+
+ base64enc [-w] [-f] <string or filepath>
+
+**Synopsis**. *To be provided.*
+
+.. _cmdbasename:
+
+Extract Base File/Directory Name (basename)
+*******************************************
+
+**Command Syntax**::
+
+ basename <path> [<suffix>]
+
+**Synopsis**. Extract the final string from a ``<path>`` by
+removing the preceding path segments and (optionally) removing any
+trailing ``<suffix>``.
+
+.. _cmdbreak:
+
+Terminate a Loop (break)
+************************
+
+**Command Syntax**::
+
+ break
+
+**Synopsis**. The ``break`` command is only meaningful within the
+body of the a ``while`` or ``until`` loop,
+between the ``do`` and ``done`` tokens. Outside of a loop,
+``break`` command does nothing. If the ``break`` command is
+executed within the body of a loop, the loop will immediately
+terminate and execution will continue with the next command
+immediately following the ``done`` token.
+
+.. _cmdcat:
+
+Concatenate Files (cat)
+***********************
+
+**Command Syntax**::
+
+ cat <path> [<path> [<path> ...]]
+
+**Synopsis**. This command copies and concatenates all of the
+files at ``<path>`` to the console (or to another file if the
+output is redirected).
+
+.. _cmdcd:
+
+Change Current Working Directory (cd)
+*************************************
+
+**Command Syntax**::
+
+ cd [<dir-path>|-|~|..]
+
+**Synopsis**. Changes the current working directory (``PWD``).
+Also sets the previous working directory environment variable
+(``OLDPWD``).
+
+**Forms:**
+
+================== =====================================
+``cd <dir-path>`` sets the current working directory to <dir-path>.
+``cd -`` sets the current working directory to the previous
+ working directory ($OLDPWD). Equivalent to cd $OLDPWD.
+``cd`` or ``cd ~`` set the current working directory to the 'home' directory.
+ The home directory can be configured by setting CONFIG_LIB_HOMEDIR
+ in the configuration file. The default home directory is /.
+``cd ..`` sets the current working directory to the parent directory.
+================== =====================================
+
+.. _cmdcmp:
+
+Compare Files (cmp)
+*******************
+
+**Command Syntax**::
+
+ cmp <path1> <path2>
+
+**Synopsis**. Compare of the contents of the file at ``<path1>``
+with the contents of the file at ``<path2>``. Returns an
+indication only if the files differ.
+
+.. _cmdcp:
+
+Copy Files (cp)
+***************
+
+**Command Syntax**::
+
+ cp <source-path> <dest-path>
+
+**Synopsis**. Copy of the contents of the file at
+``<source-path>`` to the location in the file system indicated by
+``<dest-path>``.
+
+.. _cmddate:
+
+Show or set the date and time (date)
+************************************
+
+**Command Syntax**::
+
+ date [-s "MMM DD HH:MM:SS YYYY"]
+
+**Synopsis**. Show or set the current date and time.
+
+Only one format is used both on display and when setting the
+date/time: ``MMM DD HH:MM:SS YYYY``. For example,
+
+24-hour time is used.
+
+.. _cmddd:
+
+Copy and Convert Files (dd)
+***************************
+
+**Command Syntax**::
+
+ dd if=<infile> of=<outfile> [bs=<sectsize>] [count=<sectors>] [skip=<sectors>]
+
+**Synopsis**. Copy blocks from <infile> to <outfile>. <infile> or
+<outfile> may be the path to a standard file, a character device,
+or a block device. Examples follow:
+
+Read from character device, write to regular file. This will
+create a new file of the specified size filled with zero::
+
+ nsh> ls -l /dev
+ /dev:
+ crw-rw-rw- 0 zero
+ nsh> dd if=/dev/zero of=/tmp/zeros bs=64 count=16
+ nsh> ls -l /tmp
+ /tmp:
+ -rw-rw-rw- 1024 ZEROS
+
+Read from character device, write to block device. This will fill
+the entire block device with zeros::
+
+ nsh> ls -l /dev
+ /dev:
+ brw-rw-rw- 0 ram0
+ crw-rw-rw- 0 zero
+ nsh> dd if=/dev/zero of=/dev/ram0
+
+Read from a block device, write to a character device. This will
+read the entire block device and dump the contents in the bit
+bucket::
+
+ nsh> ls -l /dev
+ /dev:
+ crw-rw-rw- 0 null
+ brw-rw-rw- 0 ram0
+ nsh> dd if=/dev/ram0 of=/dev/null
+
+.. _cmddelroute:
+
+Delete a Routing Table Entry (delroute)
+***************************************
+
+**Command Syntax**::
+
+ delroute <target> [<netmask>]
+
+**Synopsis**. The entry removed will be the first entry in the
+routing table that matches the external network characterized by
+the <target> IP address and the network mask <netmask>
+
+The netmask may also be expressed using IPv4 CIDR or IPv6 slash
+notation. In that case, the netmask need not be provided.
+
+**Example**::
+
+ nsh> delroute 11.0.0.0 255.255.255.0
+
+which is equivalent to::
+
+ nsh> delroute 11.0.0.0/24
+
+.. _cmddf:
+
+Show Volume Status (df)
+***********************
+
+**Command Syntax**::
+
+ df [-h]
+
+**Synopsis**. Show the state of each mounted volume. As an
+example::
+
+ nsh> mount
+ /etc type romfs
+ /tmp type vfat
+ nsh> df
+ Block Number
+ Size Blocks Used Available Mounted on
+ 64 6 6 0 /etc
+ 512 985 2 983 /tmp
+ nsh>
+
+If ``CONFIG_NSH_CMDOPT_DF_H`` is defined in the NuttX
+configuration, then the ``df`` will also support an option ``-h``
+which may be used to show the volume information in *human
+readable* format.
+
+.. _cmddirname:
+
+Extract Path to a File/Directory (dirname)
+******************************************
+
+**Command Syntax**::
+
+ dirname <path>
+
+**Synopsis**. Extract the path string leading up to the full
+``<path>`` by removing the final directory or file name.
+
+.. _cmddmesg:
+
+Dump Buffered SYSLOG Output (dmesg)
+***********************************
+
+**Command Syntax**::
+
+ dmesg
+
+**Synopsis**. This command can be used to dump (and clear) the
+content of any buffered syslog output messages. This command is
+only available if ``CONFIG_RAMLOG_SYSLOG`` is enabled. In that
+case, syslog output will be collected in an in-memory, circular
+buffer. Entering the ``dmesg`` command will dump the content of
+that in-memory, circular buffer to the NSH console output.
+``dmesg`` has the side effect of clearing the buffered data so
+that entering ``dmesg`` again will show only newly buffered data.
+
+.. _cmdecho:
+
+Echo Strings and Variables (echo)
+*********************************
+
+**Command Syntax**::
+
+ echo [-n] [<string|$name> [<string|$name>...]]
+
+**Synopsis**. Copy the sequence of strings and expanded
+environment variables to console output (or to a file if the
+output is re-directed).
+
+The ``-n`` option suppresses the trailing newline character.
+
+.. _cmdenv:
+
+Show Environment Variables (env)
+********************************
+
+**Command Syntax**::
+
+ env
+
+**Synopsis**. Show the current name-value pairs in the
+environment. Example::
+
+ nsh> env
+ PATH=/bin
+
+ nsh> set foo bar
+ nsh> env
+ PATH=/bin
+ foo=bar
+
+ nsh> unset PATH
+ nsh> env
+ foo=bar
+
+ nsh>
+
+.. note::NSH local variables are *not* shown by the ``env``
+ command.
+
+.. _cmdexec:
+
+Execute User Code (exec)
+************************
+
+**Command Syntax**::
+
+ exec <hex-address>
+
+**Synopsis**. Execute the user logic at address ``<hex-address>``.
+NSH will pause until the execution unless the user logic is
+executed in background via ``exec <hex-address> &``.
+
+.. _cmdexit:
+
+Exit NSH (exit)
+***************
+
+**Command Syntax**::
+
+ exit
+
+**Synopsis**. Exit NSH. Only useful for the serial front end if
+you have started some other tasks (perhaps using the ``exec``
+command) and you would like to have NSH out of the way. For the
+telnet front-end, ``exit`` terminates the telnet session.
+
+.. _cmdexport:
+
+Set an Environment Variable (export)
+************************************
+
+**Command Syntax**::
+
+ export <name> [<value>]
+
+**Synopsis**. The ``export`` command sets an environment variable,
+or promotes an NSH variable to an environment variable. As
+examples:
+
+ #. Using ``export`` to promote an NSH variable to an environment
+ variable::
+
+ nsh> env
+ PATH=/bin
+
+ nsh> set foo bar
+ nsh> env
+ PATH=/bin
+
+ nsh> export foo
+ nsh> env
+ PATH=/bin
+ foo=bar
+
+ A group-wide environment variable is created with the same
+ value as the local NSH variable; the local NSH variable is
+ removed.
+
+ .. note::This behavior differs from the Bash shell. Bash would
+ retain the local Bash variable which will shadow the
+ environment variable of the same name and same value.
+
+ #. Using ``export`` to set an environment variable::
+
+ nsh> export dog poop
+ nsh> env
+ PATH=/bin
+ foo=bar
+ dog=poop
+
+The ``export`` command is not supported by NSH unless both
+``CONFIG_NSH_VARS=y`` and ``CONFIG_DISABLE_ENVIRON``\ is not set.
+
+.. _cmdfree:
+
+Show Memory Manager Status (free)
+*********************************
+
+**Command Syntax**::
+
+ free
+
+**Synopsis**. Show the current state of the memory allocator. For
+example::
+
+ nsh> free
+ total used free largest
+ Mem: 4194288 1591552 2602736 2601584
+ nsh>
+
+**Where:**
+
+======= ======================================
+total This is the total size of memory allocated for use by malloc in bytes.
+used This is the total size of memory occupied by chunks handed out by malloc.
+free This is the total size of memory occupied by free (not in use) chunks.
+largest Size of the largest free (not in use) chunk.
+======= ======================================
+
+.. _cmdget:
+
+Get File Via TFTP (get)
+***********************
+
+**Command Syntax**::
+
+ get [-b|-n] [-f <local-path>] -h <ip-address> <remote-path>
+
+**Synopsis**. Copy the file at ``<remote-address>`` from the host
+whose IP address is identified by ``<ip-address>``.
+
+**Other options**
+
+=================== ============================================
+``-f <local-path>`` The file will be saved relative to the current working directory unless <local-path> is provided.
+``-n`` Selects text ("netascii") transfer mode (default).
+``-b`` Selects binary ("octet") transfer mode
+=================== ============================================
+
+.. _cmdhelp:
+
+Show Usage Command Usage (help)
+*******************************
+
+**Command Syntax**::
+
+ help [-v] [<cmd>]
+
+**Synopsis**. Presents summary information about NSH commands to
+console.
+
+**Options**
+
+========= ====================
+``-v`` how verbose output will full command usage.
+``<cmd>`` Show full command usage only for this command.
+========= ====================
+
+.. _cmdhexdump:
+
+Hexadecimal Dump of File or Device (hexdump)
+********************************************
+
+**Command Syntax**::
+
+ hexdump <file or device> [skip=<bytes>] [count=<bytes>]
+
+**Synopsis**. Dump data in hexadecimal format from a file or
+character device
+
+================= ==================================
+``skip=<bytes>`` Will skip <bytes> number of bytes from the beginning.
+``count=<bytes>`` Will stop after dumping <bytes> number of bytes.
+================= ==================================
+
+The ``skip`` and ``count`` options are only available if
+``CONFIG_NSH_CMDOPT_HEXDUMP`` is defined in the NuttX
+configuration.
+
+.. _cmdifconfig:
+
+Manage Network Configuration (ifconfig)
+***************************************
+
+**Command Syntax**::
+
+ ifconfig [nic_name [<ip-address>|dhcp]] [dr|gw|gateway <dr-address>] [netmask <net-mask>] [dns <dns-address>] [hw <hw-mac>]]
+
+**Synopsis**. Multiple forms of the ``ifconfig`` command are
+supported:
+
+ #. With one or no arguments, ``ifconfig`` will shows the current
+ configuration of the network and, perhaps, the status of
+ Ethernet device::
+
+ ifconfig
+ ifconfig [nic_name]
+
+ As an example::
+
+ nsh> ifconfig
+ eth0 HWaddr 00:18:11:80:10:06
+ IPaddr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0
+
+ If network statistics are enabled (``CONFIG_NET_STATISTICS``),
+ then this command will also show the detailed state of network.
+
+ #. If both the network interface name and an IP address are
+ supplied as arguments, then ``ifconfig`` will set the address
+ of the Ethernet device::
+
+ ifconfig nic_name ip_address
+
+ #. Other forms *to be provided*
+
+.. note:: This commands depends upon having the *procfs* file system
+ configured into the system. The *procfs* file system must also
+ have been mounted with a command like::
+
+ nsh> mount -t procfs /proc
+
+.. _cmdifdown:
+
+Take a network down (ifdown)
+****************************
+
+**Command Syntax**::
+
+ ifdown <interface>
+
+**Synopsis**. Take down the interface identified by the name
+<interface>.
+
+**Example**::
+
+ ifdown eth0
+
+.. _cmdifup:
+
+Bring a network up (ifup)
+*************************
+
+**Command Syntax**::
+
+ ifup <interface>
+
+**Synopsis**. Bring up down the interface identified by the name
+<interface>.
+
+**Example**::
+
+ ifup eth0
+
+.. _cmdinsmod:
+
+Install an OS module (insmod)
+*****************************
+
+**Command Syntax**::
+
+ insmod <file-path> <module-name>
+
+**Synopsis**. Install the loadable OS module at <file-path> as
+module <module-name>.
+
+**Example**::
+
+ nsh> ls -l /mnt/romfs
+ /mnt/romfs:
+ dr-xr-xr-x 0 .
+ -r-xr-xr-x 9153 chardev
+ nsh> ls -l /dev
+ /dev:
+ crw-rw-rw- 0 console
+ crw-rw-rw- 0 null
+ brw-rw-rw- 0 ram0
+ crw-rw-rw- 0 ttyS0
+ nsh> lsmod
+ NAME INIT UNINIT ARG TEXT SIZE DATA SIZE
+ nsh> insmod /mnt/romfs/chardev mydriver
+ nsh> ls -l /dev
+ /dev:
+ crw-rw-rw- 0 chardev
+ crw-rw-rw- 0 console
+ crw-rw-rw- 0 null
+ brw-rw-rw- 0 ram0
+ crw-rw-rw- 0 ttyS0
+ nsh> lsmod
+ NAME INIT UNINIT ARG TEXT SIZE DATA SIZE
+ mydriver 20404659 20404625 0 20404580 552 204047a8 0
+
+.. _cmdirqinfo:
+
+Show Interrupt Status (irqinfo)
+*******************************
+
+**Command Syntax**::
+
+ irqinfo
+
+**Synopsis**. Show the current count of interrupts taken on all
+attached interrupts.
+
+**Example**::
+
+ nsh> irqinfo
+ IRQ HANDLER ARGUMENT COUNT RATE
+ 3 00001b3d 00000000 156 19.122
+ 15 0000800d 00000000 817 100.000
+ 30 00000fd5 20000018 20 2.490
+
+.. _cmdkill:
+
+Send a signal to a task (kill)
+******************************
+
+**Command Syntax**::
+
+ kill -<signal> <pid>
+
+**Synopsis**. Send the <signal> to the task identified by <pid>.
+
+**Example**::
+
+ nsh> mkfifo /dev/fifo
+ nsh> cat /dev/fifo &
+ cat [2:128]
+ nsh> ps
+ PID PRI POLICY TYPE NPX STATE EVENT SIGMASK COMMAND
+ 0 0 FIFO Kthread --- Ready 00000000 Idle Task
+ 1 128 RR Task --- Running 00000000 init
+ 2 128 FIFO pthread --- Waiting Semaphore 00000000 <pthread>(51ea50)
+ nsh> kill -9 2
+ nsh> ps
+ PID PRI POLICY TYPE NPX STATE EVENT SIGMASK COMMAND
+ 0 0 FIFO Kthread --- Ready 00000000 Idle Task
+ 1 128 RR Task --- Running 00000000 init
+ nsh>
+
+.. note:: NuttX does not support a FULL POSIX signaling system. A
+ few standard signal names like ``SIGCHLD``, ``SIGUSR1``,
+ ``SIGUSR2``, ``SIGALRM``, and ``SIGPOLL`` exist in the system.
+ However, they do not have the default actions that you might
+ expect. Rather, NuttX supports only what are referred to as POSIX
+ real-time signals. These signals may be used to communicate with
+ running tasks, may be use to waiting waiting tasks, etc.
+
+ If the configuration option ``CONFIG_SIG_DEFAULT`` is enabled,
+ then default actions for the ``SIGINT`` and ``SIGKILL`` signals
+ (only) will be supported. In that case, as an example, ``kill -9``
+ (SIGKILL) will, indeed, terminate a task. Caution should be
+ exercised, however, because this is likely to cause memory leaks
+ and to strand resource since there is insufficient clean-up in
+ certain build configurations.
+
+.. _cmdlosetup:
+
+Setup/teardown the Loop Device (losetup)
+****************************************
+
+**Command Syntax 1**::
+
+ losetup [-o <offset>] [-r] <dev-path> <file-path>
+
+**Synopsis**. Setup the loop device at <dev-path> to access the
+file at <file-path> as a block device. In the following example a
+256K file is created (``dd``) and ``losetup`` is used to make the
+file accessible as a block device. A FAT file system is created
+(``mkfatfs``) and mounted (``mount``). Files can then be managed
+on the loop-mounted file::
+
+ nsh> dd if=/dev/zero of=/tmp/image bs=512 count=512
+ nsh> ls -l /tmp
+ /tmp:
+ -rw-rw-rw- 262144 IMAGE
+ nsh> losetup /dev/loop0 /tmp/image
+ nsh> ls -l /dev
+ /dev:
+ brw-rw-rw- 0 loop0
+ nsh> mkfatfs /dev/loop0
+ nsh> mount -t vfat /dev/loop0 /mnt/example
+ nsh> ls -l /mnt
+ ls -l /mnt
+ /mnt:
+ drw-rw-rw- 0 example/
+ nsh> echo "This is a test" >/mnt/example/atest.txt
+ nsh> ls -l /mnt/example
+ /mnt/example:
+ -rw-rw-rw- 16 ATEST.TXT
+ nsh> cat /mnt/example/atest.txt
+ This is a test
+ nsh>
+
+**Command Syntax 2**::
+
+ losetup d <dev-path>
+
+**Synopsis**. Teardown the setup for the loop device at
+<dev-path>.
+
+.. _cmdln:
+
+Link to a File or Directory (ln)
+********************************
+
+**Command Syntax**::
+
+ ln [-s] <target> <link>
+
+**Synopsis**. The ``ln`` command will create a new symbolic link
+at <link> for the existing file or directory, <target>. This
+implementation is simplified for use with NuttX in these ways:
+
+ - Links may be created only within the NuttX top-level,
+ :ref:`pseudo file system <file_system_overview>` No
+ file system currently supported by NuttX provides symbolic
+ links.
+ - For the same reason, only soft links are implemented.
+ - File privileges are ignored.
+ - ``c_time`` is not updated.
+
+.. _cmdls:
+
+List Directory Contents (ls)
+****************************
+
+**Command Syntax**::
+
+ ls [-lRs] <dir-path>
+
+**Synopsis**. Show the contents of the directory at
+``<dir-path>``. NOTE: ``<dir-path>`` must refer to a directory and
+no other file system object.
+
+**Options**
+
+====== ================================
+``-R`` Show the contents of specified directory and all of its sub-directories.
+``-s`` Show the size of the files along with the filenames in the listing
+``-l`` Show size and mode information along with the filenames in the listing.
+====== ================================
+
+.. _cmdlsmod:
+
+Show information about installed OS modules (lsmod)
+***************************************************
+
+**Command Syntax**::
+
+ lsmod
+
+**Synopsis**. Show information about the currently installed OS
+modules. This information includes:
+
+ - The module name assigned to the module when it was installed
+ (``NAME``, string).
+ - The address of the module initialization function (``INIT``,
+ hexadecimal).
+ - The address of the module un-initialization function
+ (``UNINIT``, hexadecimal).
+ - An argument that will be passed to the module un-initialization
+ function (``ARG``, hexadecimal).
+ - The start of the .text memory region (``TEXT``, hexadecimal).
+ - The size of the .text memory region size (``SIZE``, decimal).
+ - The start of the .bss/.data memory region (``DATA``,
+ hexadecimal).
+ - The size of the .bss/.data memory region size (``SIZE``,
+ decimal).
+
+**Example**::
+
+ nsh> lsmod
+ NAME INIT UNINIT ARG TEXT SIZE DATA SIZE
+ mydriver 20404659 20404625 0 20404580 552 204047a8 0
+
+.. _cmdmd5:
+
+Calculate MD5 (md5)
+*******************
+
+**Command Syntax**::
+
+ md5 [-f] <string or filepath>
+
+**Synopsis**. *To be provided.*
+
+.. _cmdmx:
+
+Access Memory (mb, mh, and mw)
+******************************
+
+**Command Syntax**::
+
+ mb <hex-address>[=<hex-value>][ <hex-byte-count>]
+ mh <hex-address>[=<hex-value>][ <hex-byte-count>]
+ mw <hex-address>[=<hex-value>][ <hex-byte-count>]
+
+**Synopsis**. Access memory using byte size access (mb), 16-bit
+accesses (mh), or 32-bit access (mw). In each case,
+
+============================= ==============================================
+``<hex-address>`` Specifies the address to be accessed. The current
+ value at that address will always be read and displayed.
+``<hex-address>=<hex-value>`` Read the value, then write <hex-value> to the location.
+``<hex-byte-count>`` Perform the mb, mh, or mw operation on a total of
+ <hex-byte-count> bytes, increment the <hex-address>
+ appropriately after each access.
+============================= ==============================================
+
+**Example**::
+
+ nsh> mh 0 16
+ 0 = 0x0c1e
+ 2 = 0x0100
+ 4 = 0x0c1e
+ 6 = 0x0110
+ 8 = 0x0c1e
+ a = 0x0120
+ c = 0x0c1e
+ e = 0x0130
+ 10 = 0x0c1e
+ 12 = 0x0140
+ 14 = 0x0c1e
+ nsh>
+
+.. _cmdps:
+
+Show Current Tasks and Threads (ps)
+***********************************
+
+**Command Syntax**::
+
+ ps
+
+**Synopsis**. Show the currently active threads and tasks. For
+example::
+
+ nsh> ps
+ PID PRI POLICY TYPE NPX STATE EVENT SIGMASK COMMAND
+ 0 0 FIFO Kthread --- Ready 00000000 Idle Task
+ 1 128 RR Task --- Running 00000000 init
+ 2 128 FIFO Task --- Waiting Semaphore 00000000 nsh_telnetmain()
+ 3 100 RR pthread --- Waiting Semaphore 00000000 <pthread>(21)
+ nsh>
+
+NOTE: This commands depends upon having the *procfs* file system
+configured into the system. The *procfs* file system must also
+have been mounted with a command like::
+
+ nsh> mount -t procfs /proc
+
+.. _cmdmkdir:
+
+Create a Directory (mkdir)
+**************************
+
+**Command Syntax**::
+
+ mkdir <path>
+
+**Synopsis**. Create the directory at ``<path>``. All components
+of ``<path>`` except the final directory name must exist on a
+mounted file system; the final directory must not.
+
+**Limited to Mounted File Systems**. Recall that NuttX uses a
+:ref:`pseudo file system <file_system_overview>`
+for its root file system. The ``mkdir`` command can only be used
+to create directories in volumes set up with the
+:ref:`mount <cmdmount>` command; it cannot be used to create
+directories in the *pseudo* file system.
+
+**Example**::
+
+ nsh> mkdir /mnt/fs/tmp
+ nsh> ls -l /mnt/fs
+ /mnt/fs:
+ drw-rw-rw- 0 TESTDIR/
+ drw-rw-rw- 0 TMP/
+ nsh>
+
+.. _cmdmkfatfs:
+
+Create a FAT File System (mkfatfs)
+**********************************
+
+**Command Syntax**
+
+ mkfatfs [-F <fatsize>] [-r <rootdirentries>] <block-driver>
+
+**Synopsis**. Format a fat file system on the block device
+specified by ``<block-driver>`` path. The FAT size may be provided
+as an option. Without the ``<fatsize>`` option, ``mkfatfs`` will
+select either the FAT12 or FAT16 format. For historical reasons,
+if you want the FAT32 format, it must be explicitly specified on
+the command line.
+
+The ``-r`` option may be specified to select the the number of
+entries in the root directory for FAT12 and FAT16 file systems.
+Typical values for small volumes would be 112 or 224; 512 should
+be used for large volumes, such as hard disks or very large SD
+cards. The default is 512 entries in all cases.
+
+The reported number of root directory entries used with FAT32 is
+zero because the FAT32 root directory is a cluster chain.
+
+NSH provides this command to access the
+``mkfatfs()`` NuttX API. This block device must
+reside in the NuttX :ref:`pseudo file system <file_system_overview>`
+and must have been created by some call to ``register_blockdriver()``
+(see ``include/nuttx/fs/fs.h``).
+
+.. _cmdmkfifo:
+
+Create a FIFO (mkfifo)
+**********************
+
+**Command Syntax**::
+
+ mkfifo <path>
+
+**Synopsis**. Creates a FIFO character device anywhere in the
+pseudo file system, creating whatever pseudo directories that may
+be needed to complete the ``<path>``. By convention, however,
+device drivers are place in the standard ``/dev`` directory. After
+it is created, the FIFO device may be used as any other device
+driver. NSH provides this command to access the
+```mkfifo()`` NuttX API.
+
+**Example**::
+
+ nsh> ls -l /dev
+ /dev:
+ crw-rw-rw- 0 console
+ crw-rw-rw- 0 null
+ brw-rw-rw- 0 ram0
+ nsh> mkfifo /dev/fifo
+ nsh> ls -l /dev
+ ls -l /dev
+ /dev:
+ crw-rw-rw- 0 console
+ crw-rw-rw- 0 fifo
+ crw-rw-rw- 0 null
+ brw-rw-rw- 0 ram0
+ nsh>
+
+.. _cmdmkrd:
+
+Create a RAMDISK (mkrd)
+***********************
+
+**Command Syntax**::
+
+ mkrd [-m <minor>] [-s <sector-size>] <nsectors>
+
+**Synopsis**. Create a ramdisk consisting of ``<nsectors>``, each
+of size ``<sector-size>`` (or 512 bytes if ``<sector-size>`` is
+not specified. The ramdisk will be registered as
+``/dev/ram<minor>``. If ``<minor>`` is not specified, ``mkrd``
+will attempt to register the ramdisk as ``/dev/ram0``.
+
+**Example**::
+
+ nsh> ls /dev
+ /dev:
+ console
+ null
+ ttyS0
+ ttyS1
+ nsh> mkrd 1024
+ nsh> ls /dev
+ /dev:
+ console
+ null
+ ram0
+ ttyS0
+ ttyS1
+ nsh>
+
+Once the ramdisk has been created, it may be formatted using the
+``mkfatfs`` command and mounted using the ``mount`` command.
+
+**Example**::
+
+ nsh> mkrd 1024
+ nsh> mkfatfs /dev/ram0
+ nsh> mount -t vfat /dev/ram0 /tmp
+ nsh> ls /tmp
+ /tmp:
+ nsh>
+
+.. _cmdmount:
+
+Mount a File System (mount)
+***************************
+
+**Command Syntax**::
+
+ mount -t <fstype> [-o <options>] <block-device> <dir-path>
+
+**Synopsis**. The ``mount`` command performs one of two different
+operations. If no parameters are provided on the command line
+after the ``mount`` command, then the ``mount`` command will
+enumerate all of the current mountpoints on the console.
+
+If the mount parameters are provided on the command after the
+``mount`` command, then the ``mount`` command will mount a file
+system in the NuttX pseudo-file system. ``mount`` performs a three
+way association, binding:
+
+ #. **File System.** The '-t ``<fstype>``' option identifies the
+ type of file system that has been formatted on the
+ ``<block-device>``. As of this writing, ``vfat`` is the only
+ supported value for ``<fstype>``
+ #. **Block Device.** The ``<block-device>`` argument is the full
+ or relative path to a block driver inode in the
+ :ref:`pseudo file system <file_system_overview>`. By
+ convention, this is a name under the ``/dev`` sub-directory.
+ This ``<block-device>`` must have been previously formatted
+ with the same file system type as specified by ``<fstype>``
+ #. **Mount Point.** The mount point, ``<dir-path>``, is the
+ location in the :ref:`pseudo file system <file_system_overview>`
+ where the mounted volume will appear. This mount point can only
+ reside in the NuttX
+ :ref:`pseudo file system <file_system_overview>`. By
+ convention, this mount point is a subdirectory under ``/mnt``.
+ The mount command will create whatever pseudo directories that
+ may be needed to complete the full path but the full path must
+ not already exist.
+
+After the volume has been mounted in the NuttX
+:ref:`pseudo file system <file_system_overview>`, it may be
+access in the same way as other objects in the file system.
+
+**Examples**:
+
+Using ``mount`` to mount a file system::
+
+ nsh> ls -l /dev
+ /dev:
+ crw-rw-rw- 0 console
+ crw-rw-rw- 0 null
+ brw-rw-rw- 0 ram0
+ nsh> ls /mnt
+ nsh: ls: no such directory: /mnt
+ nsh> mount -t vfat /dev/ram0 /mnt/fs
+ nsh> ls -l /mnt/fs/testdir
+ /mnt/fs/testdir:
+ -rw-rw-rw- 15 TESTFILE.TXT
+ nsh> echo "This is a test" >/mnt/fs/testdir/example.txt
+ nsh> ls -l /mnt/fs/testdir
+ /mnt/fs/testdir:
+ -rw-rw-rw- 15 TESTFILE.TXT
+ -rw-rw-rw- 16 EXAMPLE.TXT
+ nsh> cat /mnt/fs/testdir/example.txt
+ This is a test
+ nsh>
+
+Using ``mount`` to enumerate mounts::
+
+ nsh> mount
+ /etc type romfs
+ /mnt/fs type vfat
+ /tmp type vfat
+
+.. _cmdmv:
+
+Rename a File (mv)
+******************
+
+**Command Syntax**::
+
+ mv <old-path> <new-path>
+
+**Synopsis**. Rename the file object at ``<old-path>`` to
+``<new-path>``. Both paths must reside in the same mounted file
+system.
+
+.. _cmdnfsmount:
+
+Mount an NFS file system (nfsmount)
+***********************************
+
+**Command Syntax**::
+
+ nfsmount <server-address> <mount-point> <remote-path>
+
+**Synopsis**. Mount the remote NFS server directory<remote-path>
+at <mount-point> on the target machine. <server-address> is the IP
+address of the remote server.
+
+.. _cmdnslookup:
+
+Lookup a network address (nslookup)
+***********************************
+
+**Command Syntax**::
+
+ nslookup <host-name>
+
+**Synopsis**. Lookup and print the IP address associated with
+``<host-name>``.
+
+.. _cmdpasswd:
+
+Change a User's Password (passwd)
+*********************************
+
+**Command Syntax**::
+
+ passwd <username> <password>
+
+**Synopsis**. Set the password for the existing user <username> to
+<password>.
+
+.. _cmdpmconfig:
+
+Manage Power Management Subsystem (pmconfig)
+********************************************
+
+**Command Syntax**::
+
+ pmconfig [stay|relax] [normal|idle|standby|sleep]
+
+**Synopsis**. Control power management subsystem.
+
+.. _cmdpoweroff:
+
+Shut the system down (poweroff)
+*******************************
+
+**Command Syntax**::
+
+ poweroff [<n>]
+
+**Synopsis**. Shutdown and power off the system immediately. This
+command depends on board-specific hardware support to power down
+the system. The optional,decimal numeric argument may be included
+to provide power off mode to board-specific power off logic.
+
+NOTE: Supporting both the ``poweroff`` and ``shutdown`` commands
+is redundant.
+
+.. _cmdput:
+
+Send File Via TFTP (put)
+************************
+
+**Command Syntax**::
+
+ put [-b|-n] [-f <remote-path>] -h <ip-address> <local-path>
+
+**Synopsis**. Copy the file at ``<local-address>`` to the host
+whose IP address is identified by ``<ip-address>``.
+
+**Other options:**
+
+==================== =============================================
+``-f <remote-path>`` The file will be saved relative with the same
+ name on the host unless <remote-path> is provided.
+``-b|-n`` Selects either binary ("octet") or text ("netascii")
+ transfer mode. Default: text.
+==================== =============================================
+
+.. _cmdpwd:
+
+Show Current Working Directory (pwd)
+************************************
+
+**Command Syntax**::
+
+ pwd
+
+**Synopsis**. Show the current working directory::
+
+ nsh> cd /dev
+ nsh> pwd
+ /dev
+ nsh>
+
+Same as ``echo $PWD``::
+
+ nsh> echo $PWD
+ /dev
+ nsh>
+
+.. _cmdreadlink:
+
+Show target of a link (readlink)
+********************************
+
+**Command Syntax**::
+
+ readlink <link>
+
+**Synopsis**. Show the target of the soft link at the path
+``<link>``.
+
+.. _cmdreboot:
+
+Reboot the system (reboot)
+**************************
+
+**Command Syntax**::
+
+ reboot [<n>]
+
+**Synopsis**. Reset and reboot the system immediately. This
+command depends on hardware support to reset the system. The
+optional, decimal numeric argument <n> may be included to provide
+a reboot mode to board-specific reboot logic.
+
+NOTE: Supporting both the ``reboot`` and ``shutdown`` commands is
+redundant.
+
+.. _cmdrm:
+
+Remove a File (rm)
+******************
+
+**Command Syntax**::
+
+ rm <file-path>
+
+**Synopsis**. Remove the specified ``<file-path>`` name from the
+mounted file system. Recall that NuttX uses a
+:ref:`pseudo file system <file_system_overview>` for its root
+file system. The ``rm`` command can only be used to remove
+(unlink) files in volumes set up with the
+:ref:`mount <cmdmount>` command; it cannot be used to remove
+names in the *pseudo* file system.
+
+**Example**::
+
+ nsh> ls /mnt/fs/testdir
+ /mnt/fs/testdir:
+ TESTFILE.TXT
+ EXAMPLE.TXT
+ nsh> rm /mnt/fs/testdir/example.txt
+ nsh> ls /mnt/fs/testdir
+ /mnt/fs/testdir:
+ TESTFILE.TXT
+ nsh>
+
+.. _cmdrmdir:
+
+Remove a Directory (rmdir)
+**************************
+
+**Command Syntax**::
+
+ rmdir <dir-path>
+
+**Synopsis**. Remove the specified ``<dir-path>`` directory from
+the mounted file system. Recall that NuttX uses a
+:ref:`pseudo file system <file_system_overview>` for its root
+file system. The ``rmdir`` command can only be used to remove
+directories from volumes set up with the :ref:`mount <cmdmount>`
+command it cannot be used to remove directories from the *pseudo*
+file system.
+
+**Example**::
+
+ nsh> mkdir /mnt/fs/tmp
+ nsh> ls -l /mnt/fs
+ /mnt/fs:
+ drw-rw-rw- 0 TESTDIR/
+ drw-rw-rw- 0 TMP/
+ nsh> rmdir /mnt/fs/tmp
+ nsh> ls -l /mnt/fs
+ /mnt/fs:
+ drw-rw-rw- 0 TESTDIR/
+ nsh>
+
+.. _cmdrmmod:
+
+Remove on OS Module (rmmod)
+***************************
+
+**Command Syntax**::
+
+ rmmod <module-name>
+
+**Synopsis**. Remove the loadable OS module with the
+<module-name>. NOTE: An OS module can only be removed if it is not
+busy.
+
+**Example**::
+
+ nsh> lsmod
+ NAME INIT UNINIT ARG TEXT SIZE DATA SIZE
+ mydriver 20404659 20404625 0 20404580 552 204047a8 0
+ nsh> rmmod mydriver
+ nsh> lsmod
+ NAME INIT UNINIT ARG TEXT SIZE DATA SIZE
+ nsh>
+
+.. _cmdroute:
+
+Show routing table (route)
+**************************
+
+**Command Syntax**::
+
+ route ipv4|ipv6
+
+**Synopsis**. Show the contents of routing table for IPv4 or IPv6.
+
+If only IPv4 or IPv6 is enabled, then the argument is optional
+but, if provided, must match the enabled internet protocol
+version.
+
+.. _cmdrptun:
+
+Start/Stop the OpenAMP RPC Tunnel (rptun)
+*****************************************
+
+**Command Syntax**::
+
+ rptun start|stop <dev-path>
+
+**Synopsis**. Start or stop the OpenAMP RPC tunnel device at <dev-path>.
+
+.. _cmdset:
+
+Set a Variable (set)
+********************
+
+**Command Syntax**::
+
+ set [{+|-}{e|x|xe|ex}] [<name> <value>]
+
+**Synopsis**. Set the variable ``<name>`` to the string ``<value>`` and
+or set NSH parser control options.
+
+For example, a variable may be set like this::
+
+ nsh> echo $foobar
+
+ nsh> set foobar foovalue
+ nsh> echo $foobar
+ foovalue
+ nsh>
+
+If ``CONFIG_NSH_VARS`` is selected, the effect of this ``set`` command
+is to set the local NSH variable. Otherwise, the group-wide environment
+variable will be set.
+
+If the local NSH variable has already been *promoted* to an environment
+variable via the :ref:`export <cmdexport>`, then the ``set`` command
+will set the value of the environment variable rather than the local NSH
+variable.
+
+.. note:: The Bash shell does not work this way. Bash would set the value
+ of both the local Bash variable and the environment variable of the
+ same name to the same value.
+
+If ``CONFIG_NSH_VARS=y`` is selected and no arguments are provided, then
+the ``set`` command will list all of the local NSH variables::
+
+ nsh> set
+ foolbar=foovalue
+
+Set the *exit on error control* and/or *print a trace* of commands when
+parsing scripts in NSH. The settings are in effect from the point of
+execution, until they are changed again, or in the case of the
+initialization script, the settings are returned to the default settings
+when it exits. Included child scripts will run with the parents settings
+and changes made in the child script will effect the parent on return.
+
+ - Use ``set -e`` to enable and ``set +e`` to disable (ignore) the exit
+ condition on commands. The default is -e. Errors cause script to
+ exit.
+
+ - Use ``set -x`` to enable and ``set +x`` to disable (silence) printing
+ a trace of the script commands as they are executed. The default is
+ ``+x``: no printing of a trace of script commands as they are
+ executed.
+
+Example 1 - no exit on command not found::
+
+ set +e
+ notacommand
+
+Example 2 - will exit on command not found::
+
+ set -e
+ notacommand
+
+Example 3 - will exit on command not found, and print a trace of the
+script commands::
+
+ set -ex
+
+Example 4 - will exit on command not found, and print a trace of the
+script commands and set foobar to foovalue::
+
+ set -ex foobar foovalue
+ nsh> echo $foobar
+ foovalue
+
+.. _cmdsh:
+
+Execute an NSH Script (sh)
+**************************
+
+**Command Syntax**::
+
+ sh <script-path>
+
+**Synopsis**. Execute the sequence of NSH commands in the file referred
+to by ``<script-path>``.
+
+.. _cmdshutdown:
+
+Shut the system down (shutdown)
+*******************************
+
+**Command Syntax**::
+
+ shutdown [--reboot]
+
+**Synopsis**. Shutdown and power off the system or, optionally, reset
+and reboot the system immediately. This command depends on hardware
+support to power down or reset the system; one, both, or neither
+behavior may be supported.
+
+NOTE: The ``shutdown`` command duplicates the behavior of the
+``poweroff`` and ``eboot`` commands.
+
+.. _cmdsleep:
+
+Wait for Seconds (sleep)
+************************
+
+**Command Syntax**::
+
+ sleep <sec>
+
+**Synopsis**. Pause execution (sleep) for ``<sec>`` seconds.
+
+.. _cmdtelnetd:
+
+Time Start the Telnet Daemon (telnetd)
+**************************************
+
+**Command Syntax**::
+
+ telnetd
+
+**Synopsis**. Start the Telnet daemon if it is not already running.
+
+The Telnet daemon may be started either programmatically by calling
+``nsh_telnetstart()`` or it may be started from the NSH command line
+using this ``telnetd`` command.
+
+Normally this command would be suppressed with
+``CONFIG_NSH_DISABLE_TELNETD`` because the Telnet daemon is
+automatically started in ``nsh_main.c``. The exception is when
+``CONFIG_NSH_NETLOCAL`` is selected. In that case, the network is not
+enabled at initialization but rather must be enabled from the NSH
+command line or via other applications.
+
+In that case, when ``nsh_telnetstart()`` is called before the the
+network is initialized, it will fail.
+
+.. _cmdtime:
+
+Time execution of another command (time)
+****************************************
+
+**Command Syntax**::
+
+ time "<command>"
+
+**Synopsis**. Perform command timing. This command will execute the
+following <command> string and then show how much time was required to
+execute the command. Time is shown with a resolution of 100 microseconds
+which may be beyond the resolution of many configurations. Note that the
+<command> must be enclosed in quotation marks if it contains spaces or
+other delimiters.
+
+**Example**::
+
+ nsh> time "sleep 2"
+
+ 2.0100 sec
+ nsh>
+
+The additional 10 milliseconds in this example is due to the way that
+the sleep command works: It always waits one system clock tick longer
+than requested and this test setup used a 10 millisecond periodic system
+timer. Sources of error could include various quantization errors,
+competing CPU usage, and the additional overhead of the time command
+execution itself which is included in the total.
+
+The reported time is the elapsed time from starting of the command to
+completion of the command. This elapsed time may not necessarily be just
+the processing time for the command. It may included interrupt level
+processing, for example. In a busy system, command processing could be
+delayed if pre-empted by other, higher priority threads competing for
+CPU time. So the reported time includes all CPU processing from the
+start of the command to its finish possibly including unrelated
+processing time during that interval.
+
+Notice that::
+
+ nsh> time "sleep 2 &"
+ sleep [3:100]
+
+ 0.0000 sec
+ nsh>
+
+Since the sleep command is executed in background, the sleep command
+completes almost immediately. As opposed to the following where the time
+command is run in background with the sleep command::
+
+ nsh> time "sleep 2" &
+ time [3:100]
+ nsh>
+ 2.0100 sec
+
+.. _cmdtruncate:
+
+Set the Size of a File (truncate)
+*********************************
+
+**Command Syntax**::
+
+ truncate -s <length> <file-path>
+
+**Synopsis**. Shrink or extend the size of the regular file at
+<file-path> to the specified<length>.
+
+A <file-path> argument that does not exist is created. The <length>
+option is NOT optional.
+
+If a <file-path> is larger than the specified size, the extra data is
+lost. If a <file-path> is shorter, it is extended and the extended part
+reads as zero bytes.
+
+.. _cmdumount:
+
+Unmount a File System (umount)
+******************************
+
+**Command Syntax**::
+
+ umount <dir-path>
+
+**Synopsis**. Un-mount the file system at mount point ``<dir-path>``.
+The ``umount`` command can only be used to un-mount volumes previously
+mounted using :ref:`mount <cmdmount>` command.
+
+**Example**::
+
+ nsh> ls /mnt/fs
+ /mnt/fs:
+ TESTDIR/
+ nsh> umount /mnt/fs
+ nsh> ls /mnt/fs
+ /mnt/fs:
+ nsh: ls: no such directory: /mnt/fs
+ nsh>
+
+.. _cmduname:
+
+Print system information (uname)
+********************************
+
+**Command Syntax**::
+
+ uname [-a | -imnoprsv]
+
+**Synopsis**. Print certain system information. With no options, the
+output is the same as -s.
+
+========== ========================================
+``-a`` Print all information, in the following
+ order, except omit -p and -i if unknown:
+``-s, -o`` Print the operating system name (NuttX)
+``-n`` Print the network node hostname (only available if CONFIG_NET=y)
+``-r`` Print the kernel release
+``-v`` Print the kernel version
+``-m`` Print the machine hardware name
+``-i`` Print the machine platform name
+``-p`` Print "unknown"
+========== ========================================
+
+.. _cmdunset:
+
+Unset an Environment Variable (unset)
+*************************************
+
+**Command Syntax**:
+
+ unset <name>
+
+**Synopsis**. Remove the value associated with the variable ``<name>``.
+This will remove the name-value pair from both the NSH local variables
+and the group-wide environment variables. For example::
+
+ nsh> echo $foobar
+ foovalue
+ nsh> unset foobar
+ nsh> echo $foobar
+
+ nsh>
+
+.. _cmdurldecode:
+
+URL Decode (urldecode)
+**********************
+
+**Command Syntax**::
+
+ urldecode [-f] <string or filepath>
+
+**Synopsis**. *To be provided.*
+
+.. _cmdurlencode:
+
+URL Encode (urlencode)
+**********************
+
+**Command Syntax**::
+
+ urlencode [-f] <string or filepath>
+
+**Synopsis**. *To be provided.*
+
+.. _cmduseradd:
+
+Add a New User (useradd)
+************************
+
+**Command Syntax**::
+
+ useradd <username> <password>
+
+**Synopsis**. Add a new user with <username> and <password>.
+
+.. _cmduserdel:
+
+Delete a user (userdel)
+***********************
+
+**Command Syntax**::
+
+ userdel <username>
+
+**Synopsis**. Delete the user with the name <username>.
+
+.. _cmdusleep:
+
+Wait for Microseconds (usleep)
+******************************
+
+**Command Syntax**::
+
+ usleep <usec>
+
+**Synopsis**. Pause execution (sleep) of ``<usec>`` microseconds.
+
+.. _cmdwget:
+
+Get File Via HTTP (wget)
+************************
+
+**Command Syntax**
+
+ wget [-o <local-path>] <url>
+
+**Synopsis**. Use HTTP to copy the file at ``<url>`` to the current
+directory.
+
+**Options**
+
+=================== =================================================
+``-o <local-path>`` The file will be saved relative to the current working
+ directory and with the same name as on the HTTP server
+ unless <local-path> is provided.
+=================== =================================================
+
+.. _cmdxd:
+
+Hexadecimal Dump of Memory (xd)
+*******************************
+
+**Command Syntax**::
+
+ xd <hex-address> <byte-count>
+
+**Synopsis**. Dump ``<byte-count>`` bytes of data from address
+``<hex-address>``.
+
+**Example**::
+
+ nsh> xd 410e0 512
+ Hex dump:
+ 0000: 00 00 00 00 9c 9d 03 00 00 00 00 01 11 01 10 06 ................
+ 0010: 12 01 11 01 25 08 13 0b 03 08 1b 08 00 00 02 24 ....%..........$
+ ...
+ 01f0: 08 3a 0b 3b 0b 49 13 00 00 04 13 01 01 13 03 08 .:.;.I..........
+ nsh>
+
+Built-In Commands
+=================
+
+In addition to the commands that are part of NSH listed in the previous
+section above, there can be additional, external *built-in* applications
+that can be added to NSH. These are separately excecuble programs but
+will appear much like the commands that are a part of NSH. The primary
+difference from the user's perspective is that help information about
+the built-in applications is not available directly from NSH. Rather,
+you will need to execute the application with the ``-h`` option to get
+help about using the built-in applications.
+
+There are several built-in applications in the ``apps/`` repository. No
+attempt is made here to enumerate all of them. But a few of the more
+common, useful built-in applications are listed below.
+
+.. _cmdping:
+
+Check Network Peer (ping/ping6)
+*******************************
+
+**Command Syntax**::
+
+ ping [-c <count>] [-i <interval>] <ip-address>
+ ping6 [-c <count>] [-i <interval>] <ip-address>
+
+**Synopsis**. Test the network communication with a remote peer.
+Example::
+
+ nsh> ping 10.0.0.1
+ PING 10.0.0.1 56 bytes of data
+ 56 bytes from 10.0.0.1: icmp_seq=1 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=2 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=3 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=4 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=5 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=6 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=7 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=8 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=9 time=0 ms
+ 56 bytes from 10.0.0.1: icmp_seq=10 time=0 ms
+ 10 packets transmitted, 10 received, 0% packet loss, time 10190 ms
+ nsh>
+
+``ping6`` differs from ``ping`` in that it uses IPv6 addressing.
+
+
diff --git a/content/docs/10.1.0/_sources/applications/nsh/config.rst.txt b/content/docs/10.1.0/_sources/applications/nsh/config.rst.txt
new file mode 100644
index 0000000..55b39c2
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/nsh/config.rst.txt
@@ -0,0 +1,488 @@
+.. |br| raw:: html
+
+ <br/>
+
+======================
+Configuration Settings
+======================
+
+The availability of the above commands depends upon features that may or
+may not be enabled in the NuttX configuration file. The following
+:ref:`cmdtable <cmddependencies>` indicates the dependency of each command on
+NuttX configuration settings. General configuration settings are
+discussed in the NuttX Porting Guide.
+Configuration settings specific to NSH as discussed at the
+:ref:`cmdbottom <nshconfiguration>` of this document.
+
+Note that in addition to general NuttX configuration settings, each NSH
+command can be individually disabled via the settings in the rightmost
+column. All of these settings make the configuration of NSH potentially
+complex but also allow it to squeeze into very small memory footprints.
+
+.. _cmddependencies:
+
+Command Dependencies on Configuration Settings
+==============================================
+
+====================== =========================================== ======================
+Command Depends on Configuration Can Be Disabled with
+====================== =========================================== ======================
+``[`` ! ``CONFIG_NSH_DISABLESCRIPT`` ``CONFIG_NSH_DISABLE_TEST``
+:ref:`cmdaddroute` ``CONFIG_NET`` && ``CONFIG_NET_ROUTE`` ``CONFIG_NSH_DISABLE_ADDROUTE``
+:ref:`cmdarp` ``CONFIG_NET`` && ``CONFIG_NET_ARP`` ``CONFIG_NSH_DISABLE_ARP``
+:ref:`cmdbase64dec` ``CONFIG_NETUTILS_CODECS`` && ``CONFIG_NSH_DISABLE_BASE64DEC``
+ ``CONFIG_CODECS_BASE64``
+:ref:`cmdbase64enc` ``CONFIG_NETUTILS_CODECS`` && ``CONFIG_NSH_DISABLE_BASE64ENC``
+ ``CONFIG_CODECS_BASE64``
+:ref:`cmdbasename` . ``CONFIG_NSH_DISABLE_BASENAME``
+:ref:`cmdbreak` ! ``CONFIG_NSH_DISABLESCRIPT`` && .
+ ! ``CONFIG_NSH_DISABLE_LOOPS``
+:ref:`cmdcat` ``CONFIG_NSH_DISABLE_CAT`` .
+:ref:`cmdcd` ! ``CONFIG_DISABLE_ENVIRON`` ``CONFIG_NSH_DISABLE_CD``
+:ref:`cmdcmp` ``CONFIG_NSH_DISABLE_CMP`` .
+:ref:`cmdcp` ``CONFIG_NSH_DISABLE_CP`` .
+:ref:`cmddate` ``CONFIG_NSH_DISABLE_DATE`` .
+:ref:`cmddd` ``CONFIG_NSH_DISABLE_DD`` .
+:ref:`cmddelroute` ``CONFIG_NET`` && ``CONFIG_NET_ROUTE`` ``CONFIG_NSH_DISABLE_DELROUTE``
+:ref:`cmddf` ! ``CONFIG_DISABLE_MOUNTPOINT`` ``CONFIG_NSH_DISABLE_DF``
+:ref:`cmddirname` ``CONFIG_NSH_DISABLE_DIRNAME`` .
+:ref:`cmddmesg` ``CONFIG_RAMLOG_SYSLOG`` ``CONFIG_NSH_DISABLE_DMESG``
+:ref:`cmdecho` ``CONFIG_NSH_DISABLE_ECHO`` .
+:ref:`cmdenv` ``CONFIG_FS_PROCFS`` && ``CONFIG_NSH_DISABLE_ENV``
+ ! ``CONFIG_DISABLE_ENVIRON`` && |br|
+ ! ``CONFIG_PROCFS_EXCLUDE_ENVIRON``
+:ref:`cmdexec` ``CONFIG_NSH_DISABLE_EXEC`` .
+:ref:`cmdexit` ``CONFIG_NSH_DISABLE_EXIT`` .
+:ref:`cmdexport` ``CONFIG_NSH_VARS`` &&
+ ! ``CONFIG_DISABLE_ENVIRON`` ``CONFIG_NSH_DISABLE_EXPORT``
+:ref:`cmdfree` ``CONFIG_NSH_DISABLE_FREE`` .
+:ref:`cmdget` ``CONFIG_NET`` && ``CONFIG_NET_UDP`` && ``CONFIG_NSH_DISABLE_GET``
+ *MTU* >= 58\ [#1]_
+:ref:`cmdhelp` [#3]_ ``CONFIG_NSH_DISABLE_HELP`` .
+:ref:`cmdhexdump` ``CONFIG_NSH_DISABLE_HEXDUMP`` .
+:ref:`cmdifconfig` ``CONFIG_NET`` && ``CONFIG_FS_PROCFS`` && ``CONFIG_NSH_DISABLE_IFCONFIG``
+ ! ``CONFIG_FS_PROCFS_EXCLUDE_NET``
+:ref:`cmdifdown` ``CONFIG_NET`` && ``CONFIG_FS_PROCFS`` && ``CONFIG_NSH_DISABLE_IFUPDOWN``
+ ! ``CONFIG_FS_PROCFS_EXCLUDE_NET``
+:ref:`cmdifup` ``CONFIG_NET`` && ``CONFIG_FS_PROCFS`` &&
+ ! ``CONFIG_FS_PROCFS_EXCLUDE_NET`` ``CONFIG_NSH_DISABLE_IFUPDOWN``
+:ref:`cmdinsmod` ``CONFIG_MODULE`` ``CONFIG_NSH_DISABLE_MODCMDS``
+:ref:`cmdirqinfo` ! ``CONFIG_DISABLE_MOUNTPOINT`` && .
+ ``CONFIG_FS_PROCFS`` && |br|
+ ``CONFIG_SCHED_IRQMONITOR``
+:ref:`cmdkill` ``CONFIG_NSH_DISABLE_KILL`` .
+:ref:`cmdlosetup` ! ``CONFIG_DISABLE_MOUNTPOINT`` && ``CONFIG_NSH_DISABLE_LOSETUP``
+ ``CONFIG_DEV_LOOP``
+:ref:`cmdln` ``CONFIG_PSEUDOFS_SOFTLINKS`` ``CONFIG_NSH_DISABLE_LN``
+:ref:`cmdls` ``CONFIG_NSH_DISABLE_LS`` .
+:ref:`cmdlsmod` ``CONFIG_MODULE`` && ``CONFIG_FS_PROCFS`` ``CONFIG_NSH_DISABLE_MODCMDS``
+ && |br|
+ ! ``CONFIG_FS_PROCFS_EXCLUDE_MODULE``
+:ref:`cmdmd5` ``CONFIG_NETUTILS_CODECS`` && ``CONFIG_NSH_DISABLE_MD5``
+ ``CONFIG_CODECS_HASH_MD5``
+:ref:`cmdmx` . ``CONFIG_NSH_DISABLE_MB``, |br|
+ ``CONFIG_NSH_DISABLE_MH``, |br|
+ ``CONFIG_NSH_DISABLE_MW``
+:ref:`cmdmkdir` (! ``CONFIG_DISABLE_MOUNTPOINT`` \|\| ``CONFIG_NSH_DISABLE_MKDIR``
+ ! ``CONFIG_DISABLE_PSEUDOFS_OPERATIONS``)
+:ref:`cmdmkfatfs` ! ``CONFIG_DISABLE_MOUNTPOINT`` && ``CONFIG_NSH_DISABLE_MKFATFS``
+ ``CONFIG_FSUTILS_MKFATFS``
+:ref:`cmdmkfifo` ``CONFIG_PIPES`` && ``CONFIG_NSH_DISABLE_MKFIFO``
+ ``CONFIG_DEV_FIFO_SIZE`` > 0
+:ref:`cmdmkrd` ! ``CONFIG_DISABLE_MOUNTPOINT`` ``CONFIG_NSH_DISABLE_MKRD``
+:ref:`cmdmount` ! ``CONFIG_DISABLE_MOUNTPOINT`` ``CONFIG_NSH_DISABLE_MOUNT``
+:ref:`cmdmv` ! ``CONFIG_DISABLE_MOUNTPOINT`` \|\| ``CONFIG_NSH_DISABLE_MV``
+ ! ``CONFIG_DISABLE_PSEUDOFS_OPERATIONS``
+:ref:`cmdnfsmount` ! ``CONFIG_DISABLE_MOUNTPOINT`` && ``CONFIG_NSH_DISABLE_NFSMOUNT``
+ ``CONFIG_NET`` && ``CONFIG_NFS``
+:ref:`cmdnslookup` ``CONFIG_LIBC_NETDB`` && ``CONFIG_NSH_DISABLE_NSLOOKUP``
+ ``CONFIG_NETDB_DNSCLIENT``
+:ref:`cmdpasswd` ! ``CONFIG_DISABLE_MOUNTPOINT`` && ``CONFIG_NSH_DISABLE_PASSWD``
+ ``CONFIG_NSH_LOGIN_PASSWD``
+:ref:`cmdpmconfig` ``CONFIG_PM`` ``CONFIG_NSH_DISABLE_PMCONFIG``
+:ref:`cmdpoweroff` ``CONFIG_BOARDCTL_POWEROFF`` ``CONFIG_NSH_DISABLE_POWEROFF``
+:ref:`cmdps` ``CONFIG_FS_PROCFS`` && ``CONFIG_NSH_DISABLE_PS``
+ ! ``CONFIG_FS_PROCFS_EXCLUDE_PROC``
+:ref:`cmdput` ``CONFIG_NET`` && ``CONFIG_NET_UDP`` && ``CONFIG_NSH_DISABLE_PUT``
+ ``MTU >= 558`` [#1]_, [#2]_
+:ref:`cmdpwd` ! ``CONFIG_DISABLE_ENVIRON`` ``CONFIG_NSH_DISABLE_PWD``
+:ref:`cmdreadlink` ``CONFIG_PSEUDOFS_SOFTLINKS`` ``CONFIG_NSH_DISABLE_READLINK``
+:ref:`cmdreboot` ``CONFIG_BOARD_RESET`` ``CONFIG_NSH_DISABLE_REBOOT``
+:ref:`cmdrm` ! ``CONFIG_DISABLE_MOUNTPOINT`` \|\| ``CONFIG_NSH_DISABLE_RM``
+ ! ``CONFIG_DISABLE_PSEUDOFS_OPERATIONS``
+:ref:`cmdrmdir` ! ``CONFIG_DISABLE_MOUNTPOINT`` \|\
+ ! ``CONFIG_DISABLE_PSEUDOFS_OPERATIONS`` ``CONFIG_NSH_DISABLE_RMDIR``
+:ref:`cmdrmmod` ``CONFIG_MODULE`` ``CONFIG_NSH_DISABLE_MODCMDS``
+:ref:`cmdroute` ``CONFIG_FS_PROCFS`` && ``CONFIG_NSH_DISABLE_ROUTE``
+ ``CONFIG_FS_PROCFS_EXCLUDE_NET`` && |br|
+ ! ``CONFIG_FS_PROCFS_EXCLUDE_ROUTE`` &&
+ ``CONFIG_NET_ROUTE`` && |br|
+ ! ``CONFIG_NSH_DISABLE_ROUTE`` && |br|
+ (``CONFIG_NET_IPv4`` \|\
+ ``CONFIG_NET_IPv6``)
+:ref:`cmdrptun` ``CONFIG_RPTUN`` ``CONFIG_NSH_DISABLE_RPTUN``
+:ref:`cmdset` ``CONFIG_NSH_VARS`` \|\| ``CONFIG_NSH_DISABLE_SET``
+ ! ``CONFIG_DISABLE_ENVIRON``
+:ref:`cmdshutdown` ``CONFIG_BOARDCTL_POWEROFF`` \|\| ``CONFIG_NSH_DISABLE_SHUTDOWN``
+ ``CONFIG_BOARD_RESET``
+:ref:`cmdsleep` . ``CONFIG_NSH_DISABLE_SLEEP``
+``cmdsource`` ``CONFIG_FILE_STREAM`` && ``CONFIG_NSH_DISABLE_SOURCE``
+ ! ``CONFIG_NSH_DISABLESCRIPT``
+:ref:`cmdtelnetd` ``CONFIG_NSH_TELNET`` ``CONFIG_NSH_DISABLE_TELNETD``
+:ref:`cmdtest` ! ``CONFIG_NSH_DISABLESCRIPT`` ``CONFIG_NSH_DISABLE_TEST``
+:ref:`cmdtime` . ``CONFIG_NSH_DISABLE_TIME``
+:ref:`cmdtruncate` ! ``CONFIG_DISABLE_MOUNTPOINT`` ``CONFIG_NSH_DISABLE_TRUNCATE``
+:ref:`cmdumount` ! ``CONFIG_DISABLE_MOUNTPOINT`` ``CONFIG_NSH_DISABLE_UMOUNT``
+:ref:`cmduname` . ``CONFIG_NSH_DISABLE_UNAME``
+:ref:`cmdunset` ``CONFIG_NSH_VARS`` \|\| ``CONFIG_NSH_DISABLE_UNSET``
+ ! ``CONFIG_DISABLE_ENVIRON``
+:ref:`cmdurldecode` ! ``CONFIG_NETUTILS_CODECS`` && ``CONFIG_NSH_DISABLE_URLDECODE``
+ ``CONFIG_CODECS_URLCODE``
+:ref:`cmdurlencode` ! ``CONFIG_NETUTILS_CODECS`` && ``CONFIG_NSH_DISABLE_URLENCODE``
+ ``CONFIG_CODECS_URLCODE``
+:ref:`cmduseradd` ! ``CONFIG_DISABLE_MOUNTPOINT`` && ``CONFIG_NSH_DISABLE_USERADD``
+ ``CONFIG_NSH_LOGIN_PASSWD``
+:ref:`cmduserdel` ! ``CONFIG_DISABLE_MOUNTPOINT`` && ``CONFIG_NSH_DISABLE_USERDEL``
+ ``CONFIG_NSH_LOGIN_PASSWD``
+:ref:`cmdusleep` . ``CONFIG_NSH_DISABLE_USLEEP``
+:ref:`cmdwget` ``CONFIG_NET`` && ``CONFIG_NET_TCP`` ``CONFIG_NSH_DISABLE_WGET``
+:ref:`cmdxd` . ``CONFIG_NSH_DISABLE_XD``
+====================== =========================================== ======================
+
+.. [#1] Because of hardware padding, the actual required packet size may be larger
+.. [#2] Special TFTP server start-up options will probably be required to permit creation of files for the correct operation of the ``put`` command.
+.. [#3] Verbose help output can be suppressed by defining ``CONFIG_NSH_HELP_TERSE``. In that case, the help command is still available but will be slightly smaller.
+
+Built-In Command Dependencies on Configuration Settings
+=======================================================
+
+All built-in applications require that support for NSH built-in
+applications has been enabled. This support is enabled with
+``CONFIG_BUILTIN=y`` and ``CONFIG_NSH_BUILTIN_APPS=y``.
+
+============= ==================================================================================================
+Command Depends on Configuration
+============= ==================================================================================================
+``ping`` ``CONFIG_NET`` && ``CONFIG_NET_ICMP`` && ``CONFIG_NET_ICMP_SOCKET`` && ``CONFIG_SYSTEM_PING``
+``ping6`` ``CONFIG_NET`` && ``CONFIG_NET_ICMPv6`` && ``CONFIG_NET_ICMPv6_SOCKET`` && ``CONFIG_SYSTEM_PING6``
+============= ==================================================================================================
+
+.. _nshconfiguration:
+
+NSH-Specific Configuration Settings
+===================================
+
+The behavior of NSH can be modified with the following settings in the
+``boards/<arch>/<chip>/<board>/defconfig`` file:
+
+=================================== ==================================
+Configuration Description
+=================================== ==================================
+ ``CONFIG_NSH_READLINE`` Selects the minimal implementation of ``readline()``.
+ This minimal implementation provides on backspace for command
+ line editing. It expects some minimal VT100 command support from the terminal.
+
+ ``CONFIG_NSH_CLE`` Selects the more extensive, EMACS-like command line editor.
+ Select this option only if (1) you don't mind a modest increase
+ in the FLASH footprint, and (2) you work with a terminal that
+ supports extensive VT100 editing commands. Selecting this option
+ will add probably 1.5-2KB to the FLASH footprint.
+
+ ``CONFIG_NSH_BUILTIN_APPS`` Support external registered, "builtin" applications that can
+ be executed from the NSH command line (see apps/README.txt for
+ more information). This required ``CONFIG_BUILTIN`` to enable
+ NuttX support for "builtin" applications.
+
+ ``CONFIG_NSH_FILEIOSIZE`` Size of a static I/O buffer used for file access (ignored if there
+ is no file system). Default is 1024.
+
+ ``CONFIG_NSH_STRERROR`` ``strerror(errno)`` makes more readable output but
+ ``strerror()`` is very large and will not be used unless this
+ setting is *y*. This setting depends upon the ``strerror()``
+ having been enabled with ``CONFIG_LIBC_STRERROR``.
+
+ ``CONFIG_NSH_LINELEN`` The maximum length of one command line and of one output line.
+ Default: 80
+
+ ``CONFIG_NSH_DISABLE_SEMICOLON`` By default, you can enter multiple NSH commands on a line
+ with each command separated by a semicolon. You can disable this
+ feature to save a little memory on FLASH challenged platforms.
+ Default: n
+
+ ``CONFIG_NSH_CMDPARMS`` If selected, then the output from commands, from file applications,
+ and from NSH built-in commands can be used as arguments to other
+ commands. The entity to be executed is identified by
+ enclosing the command line in back quotes. For example::
+
+ set FOO `myprogram $BAR`
+
+ will execute the program named ``myprogram`` passing it the
+ value of the environment variable ``BAR``. The value of the
+ environment variable ``FOO`` is then set output of ``myprogram``
+ on ``stdout``. Because this feature commits significant
+ resources, it is disabled by default. The ``CONFIG_NSH_CMDPARMS`` interim
+ output will be retained in a temporary file. Full path to a
+ directory where temporary files can be created is taken from
+ ``CONFIG_LIBC_TMPDIR`` and it defaults to ``/tmp`` if
+ ``CONFIG_LIBC_TMPDIR`` is not set.
+
+ ``CONFIG_NSH_MAXARGUMENTS`` The maximum number of NSH command arguments. Default: 6
+
+ ``CONFIG_NSH_ARGCAT`` Support concatenation of strings with environment variables or
+ command output. For example::
+
+ set FOO XYZ
+ set BAR 123
+ set FOOBAR ABC_${FOO}_${BAR}
+
+ would set the environment variable ``FOO`` to ``XYZ``,
+ ``BAR`` to ``123`` and ``FOOBAR`` to ``ABC_XYZ_123``. If
+ ``CONFIG_NSH_ARGCAT`` is not selected, then a slightly small
+ FLASH footprint results but then also only simple environment
+ variables like ``$FOO`` can be used on the command line.
+
+ ``CONFIG_NSH_VARS`` By default, there are no internal NSH variables. NSH will use OS
+ environment variables for all variable storage. If this option,
+ NSH will also support local NSH variables. These variables are,
+ for the most part, transparent and work just like the OS
+ environment variables. The difference is that when you
+ create new tasks, all of environment variables are
+ inherited by the created tasks. NSH local variables are not.
+ If this option is enabled (and ``CONFIG_DISABLE_ENVIRON`` is not),
+ then a new command called 'export' is enabled. The export
+ command works very must like the set command except that is
+ operates on environment variables. When CONFIG_NSH_VARS
+ is enabled, there are changes in the behavior of certain commands.
+ See following :ref:`cmdtable <nsh_vars_table>`.
+
+ ``CONFIG_NSH_QUOTE`` Enables back-slash quoting of certain characters within the
+ command. This option is useful for the case where an NSH script
+ is used to dynamically generate a new NSH script. In that case,
+ commands must be treated as simple text strings without
+ interpretation of any special characters. Special characters
+ such as ``$``, :literal:`\``, ``"``, and others must be
+ retained intact as part of the test string. This option is
+ currently only available is ``CONFIG_NSH_ARGCAT`` is also
+ selected.
+
+ ``CONFIG_NSH_NESTDEPTH`` The maximum number of nested ``if-then[-else]-fi`` <#conditional>`__
+ sequences that are permissible. Default: 3
+
+ ``CONFIG_NSH_DISABLESCRIPT`` This can be set to *y* to suppress support for scripting.
+ This setting disables the ```sh`` <#cmdsh>`__,
+ ```test`` <#cmdtest>`__, and ```[`` <#cmtest>`__ commands and
+ the ```if-then[-else]-fi`` <#conditional>`__
+ construct. This would only be set on systems where a minimal
+ footprint is a necessity and scripting is not.
+
+ ``CONFIG_NSH_DISABLE_ITEF`` If scripting is enabled, then then this option can be selected
+ to suppress support for ``if-then-else-fi`` sequences in
+ scripts. This would only be set on systems where some minimal
+ scripting is required but ``if-then-else-fi`` is not.
+
+ ``CONFIG_NSH_DISABLE_LOOPS`` If scripting is enabled, then then this option can be selected
+ suppress support ``for while-do-done`` and
+ ``until-do-done`` sequences in scripts. This would only be set
+ on systems where some minimal scripting is required but looping
+ is not.
+
+ ``CONFIG_NSH_DISABLEBG`` This can be set to *y* to suppress support for background
+ commands. This setting disables the ```nice`` <#cmdoverview>`__
+ command prefix and the ```&`` <#cmdoverview>`__ command
+ suffix. This would only be set on systems where a minimal footprint
+ is a necessity and background command execution is not.
+
+ ``CONFIG_NSH_MMCSDMINOR`` If the architecture supports an MMC/SD slot and if the NSH
+ architecture specific logic is present, this option will provide
+ the MMC/SD minor number, i.e., the MMC/SD block driver will be
+ registered as ``/dev/mmcsd``\ *N* where *N* is the minor number.
+ Default is zero.
+
+ ``CONFIG_NSH_ROMFSETC`` Mount a ROMFS file system at ``/etc`` and provide a startup
+ script at ``/etc/init.d/rcS``.
+ The default startup script will mount a FAT FS RAMDISK at
+ ``/tmp`` but the logic is `easily extensible <#startupscript>`__.
+
+ ``CONFIG_NSH_CONSOLE`` If ``CONFIG_NSH_CONSOLE`` is set to *y*, then a serial console
+ front-end is selected.
+
+ Normally, the serial console device is a UART and RS-232
+ interface. However, if ``CONFIG_USBDEV`` is defined,
+ then a USB serial device may, instead, be used if the one of
+ the following are defined:
+
+ - ``CONFIG_PL2303`` and ``CONFIG_PL2303_CONSOLE``.
+ Sets up the Prolifics PL2303 emulation as a console device
+ at ``/dev/console``.
+ - ``CONFIG_CDCACM`` and ``CONFIG_CDCACM_CONSOLE``.
+ Sets up the CDC/ACM serial device as a console device at
+ ``/dev/console``.
+ - ``CONFIG_NSH_USBCONSOLE``. If defined, then an arbitrary USB
+ device may be used to as the NSH console. In this case,
+ ``CONFIG_NSH_USBCONDEV`` must be defined to indicate which
+ USB device to use as the console. The advantage of
+ using a device other that ``/dev/console`` is that
+ normal debug output can then use ``/dev/console`` while NSH
+ uses ``CONFIG_NSH_USBCONDEV``.
+
+ ``CONFIG_NSH_USBCONDEV``. If ``CONFIG_NSH_USBCONSOLE`` is
+ set to 'y', then ``CONFIG_NSH_USBCONDEV`` must also be set to select the USB
+ device used to support the NSH console. This should be set to
+ the quoted name of a readable/write-able USB driver
+ such as: ``CONFIG_NSH_USBCONDEV="/dev/ttyACM0"``.
+
+ If there are more than one USB slots, then a USB device minor
+ number may also need to be provided:
+
+ - ``CONFIG_NSH_UBSDEV_MINOR``: The minor device number of the USB device. Default: 0
+
+ If USB tracing is enabled (``CONFIG_USBDEV_TRACE``), then
+ NSH will initialize USB tracing as requested by the following.
+ Default: Only USB errors are traced.
+
+ - ``CONFIG_NSH_USBDEV_TRACEINIT``: Show initialization events
+ - ``CONFIG_NSH_USBDEV_TRACECLASS``: Show class driver events
+ - ``CONFIG_NSH_USBDEV_TRACETRANSFERS``: Show data transfer events
+ - ``CONFIG_NSH_USBDEV_TRACECONTROLLER``: Show controller events
+ - ``CONFIG_NSH_USBDEV_TRACEINTERRUPTS``: Show interrupt-related events.
+
+ ``CONFIG_NSH_ALTCONDEV`` and If ``CONFIG_NSH_CONSOLE`` is set ``CONFIG_NSH_CONDEV``
+ to *y*, then ``CONFIG_NSH_ALTCONDEV`` may also
+ be selected to enable use of an alternate character device to
+ support the NSH console. If ``CONFIG_NSH_ALTCONDEV`` is
+ selected, then ``CONFIG_NSH_CONDEV`` holds the
+ quoted name of a readable/write-able character
+ driver such as: ``CONFIG_NSH_CONDEV="/dev/ttyS1"``.
+ This is useful, for example, to separate the NSH command line
+ from the system console when the system console is used to provide
+ debug output. Default: ``stdin`` and ``stdout`` (probably
+ "``/dev/console``")
+
+ - **NOTE 1:** When any other device other than
+ ``/dev/console`` is used for a user interface, (1) linefeeds
+ (``\n``) will not be expanded to carriage return / linefeeds
+ (``\r\n``). You will need to configure your terminal
+ program to account for this.
+ And (2) input is not automatically echoed so you
+ will have to turn local echo on.
+ - **NOTE 2:** This option forces the console of all sessions to
+ use NSH_CONDEV. Hence, this option only makes sense for a
+ system that supports only a single session. This option
+ is, in particular, incompatible with Telnet
+ sessions because each Telnet session must use a different
+ console device.
+
+ ``CONFIG_NSH_TELNET`` If ``CONFIG_NSH_TELNET`` is set to *y*, then a TELNET server
+ front-end is selected. When this option is provided, you may log
+ into NuttX remotely using telnet in order to access NSH.
+
+ ``CONFIG_NSH_ARCHINIT`` Set ``CONFIG_NSH_ARCHINIT`` if your board provides architecture
+ specific initialization via the board-specific function
+ ``board_app_initialize()``. This function will be called early in
+ NSH initialization to allow board logic to do such things as
+ configure MMC/SD slots.
+=================================== ==================================
+
+.. _nsh_vars_table:
+
+================== =================================== =============================================
+CMD w/o ``CONFIG_NSH_VARS`` w/``CONFIG_NSH_VARS``
+================== =================================== =============================================
+``set <a> <b>`` Set environment variable <a> to <b> Set NSH variable <a> to <b> (Unless the NSH variable has been *promoted* via
+ ``export``, in which case the env ironment variable of the same name is set to <b>).
+``set`` Causes an error. Lists all NSH variables.
+``unset <a>`` Unsets environment variable <a> Unsets both environment variable *and* NSH variable with and name <a>
+``export <a> <b>`` Causes an error, Unsets NSH variable <a>. Sets environment variable <a> to <b>.
+``export <a>`` Causes an error. Sets environment variable <a> to the value of NSH variable <a> (or "" if the
+ NSH variable has not been set). Unsets NSH local variable <a>.
+``env`` Lists all environment variables Lists all environment variables (*only*)
+================== =================================== =============================================
+
+
+If Telnet is selected for the NSH console, then we must configure the
+resources used by the Telnet daemon and by the Telnet clients.
+
+====================================== ================================
+Configuration Description
+====================================== ================================
+``CONFIG_NSH_TELNETD_PORT`` The telnet daemon will listen on this TCP port number for connections. Default: 23
+``CONFIG_NSH_TELNETD_DAEMONPRIO`` Priority of the Telnet daemon. Default: ``SCHED_PRIORITY_DEFAULT``
+``CONFIG_NSH_TELNETD_DAEMONSTACKSIZE`` Stack size allocated for the Telnet daemon. Default: 2048
+``CONFIG_NSH_TELNETD_CLIENTPRIO`` Priority of the Telnet client. Default: ``SCHED_PRIORITY_DEFAULT``
+``CONFIG_NSH_TELNETD_CLIENTSTACKSIZE`` Stack size allocated for the Telnet client. Default: 2048
+====================================== ================================
+
+One or both of ``CONFIG_NSH_CONSOLE`` and ``CONFIG_NSH_TELNET`` must be
+defined. If ``CONFIG_NSH_TELNET`` is selected, then there some other
+configuration settings that apply:
+
+====================================== ================================
+Configuration Description
+====================================== ================================
+``CONFIG_NET=y`` Of course, networking must be enabled.
+``CONFIG_NET_TCP=y`` TCP/IP support is required for telnet (as well as various other
+ TCP-related configuration settings).
+``CONFIG_NSH_IOBUFFER_SIZE`` Determines the size of the I/O buffer to use for sending/ receiving
+ TELNET commands/responses
+``CONFIG_NSH_DHCPC`` Obtain the IP address via DHCP.
+``CONFIG_NSH_IPADDR`` If ``CONFIG_NSH_DHCPC`` is NOT set, then the static IP address must be
+ provided.
+``CONFIG_NSH_DRIPADDR`` Default router IP address
+``CONFIG_NSH_NETMASK`` Network mask
+``CONFIG_NSH_NOMAC`` Set if your Ethernet hardware has no built-in MAC address. If set, a
+ bogus MAC will be assigned.
+``CONFIG_NSH_MAX_ROUNDTRIP`` This is the maximum round trip for a response to a ICMP ECHO request. It
+ is in units of deciseconds. The default is 20 (2 seconds).
+====================================== ================================
+
+If you use DHCPC, then some special configuration network options are
+required. These include:
+
+============================================== ============================================================
+Configuration Description
+============================================== ============================================================
+``CONFIG_NET=y`` Of course, networking must be enabled.
+``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: Note that the actual MTU setting
+ will depend upon the specific link protocol. Here Ethernet
+ is indicated.
+============================================== ============================================================
+
+If ``CONFIG_NSH_ROMFSETC`` is selected, then the following additional
+configuration setting apply:
+
+============================== ==============================================================
+Configuration Description
+============================== ==============================================================
+``CONFIG_NSH_ARCHROMFS`` May be defined to specify an alternative ROMFS image
+ that can be found at ``boards/<arch>/<chip>/<board>/include/nsh_romfsimg.h``.
+``CONFIG_NSH_ROMFSMOUNTPT`` The default mountpoint for the ROMFS volume is ``"/etc"``,
+ but that can be changed with this setting. This must be a
+ absolute path beginning with '``/``' and enclosed in quotes.
+``CONFIG_NSH_INITSCRIPT`` This is the relative path to the startup script within the
+ mountpoint. The default is ``"init.d/rcS"``. This is a relative
+ path and must not start with '``/``' but must be enclosed in quotes.
+``CONFIG_NSH_ROMFSDEVNO`` This is the minor number of the ROMFS block device.
+ The default is '``0``' corresponding to ``/dev/ram0``.
+``CONFIG_NSH_ROMFSSECTSIZE`` This is the sector size to use with the ROMFS volume. Since the
+ default volume is very small, this defaults to 64 but should
+ be increased if the ROMFS volume were to be become large.
+ Any value selected must be a power of 2.
+============================== ==============================================================
+
+When the default ``rcS`` file used when ``CONFIG_NSH_ROMFSETC`` is
+selected, it will mount a FAT FS under ``/tmp``. The following
+selections describe that FAT FS.
+
+============================== =======================================================
+Configuration Description
+============================== =======================================================
+``CONFIG_NSH_FATDEVNO`` This is the minor number of the FAT FS block device.
+ The default is '``1``' corresponding to ``/dev/ram1``.
+``CONFIG_NSH_FATSECTSIZE`` This is the sector size use with the FAT FS. Default is 512.
+============================== =======================================================
+
diff --git a/content/docs/10.1.0/_sources/applications/nsh/customizing.rst.txt b/content/docs/10.1.0/_sources/applications/nsh/customizing.rst.txt
new file mode 100644
index 0000000..38b28a0
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/nsh/customizing.rst.txt
@@ -0,0 +1,213 @@
+*************************
+Customizing the NuttShell
+*************************
+
+**Overview.** The NuttShell (NSH) is a simple shell application that may
+be used with NuttX. It supports a variety of commands and is (very)
+loosely based on the Bash shell and the common utilities used with Bash
+shell programming. The paragraphs in this appendix will focus on
+customizing NSH: Adding new commands, changing the initialization
+sequence, etc.
+
+The NSH Library and NSH Initialization
+**************************************
+
+**Overview.** NSH is implemented as a library that can be found at
+``apps/nshlib``. As a library, it can be custom built into any
+application that follows the NSH initialization sequence described
+below. As an example, the code at ``apps/examples/nsh/nsh_main.c``
+illustrates how to start NSH and the logic there was intended to be
+incorporated into your own custom code. Although code was generated
+simply as an example, in the end most people just use this example code
+as their application ``main()`` function. That initialization performed
+by that example is discussed in the following paragraphs.
+
+NSH Initialization sequence
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The NSH start-up sequence is very simple. As an example, the code at
+``apps/system/nsh/nsh_main.c`` illustrates how to start NSH. It simple
+does the following:
+
+ #. This function calls ``nsh_initialize()`` which initializes the NSH
+ library. ``nsh_initialize()`` is described in more detail below.
+
+ #. If the Telnetconsole is enabled, it calls ``nsh_telnetstart()`` which
+ resides in the NSH library. ``nsh_telnetstart()`` will start the
+ Telnet daemon that will listen for Telnet connections and start
+ remote NSH sessions.
+
+ #. If a local console is enabled (probably on a serial port), then
+ ``nsh_consolemain()`` is called. ``nsh_consolemain()`` also resides
+ in the NSH library. ``nsh_consolemain()`` does not return so that
+ finished the entire NSH initialization sequence.
+
+``nsh_initialize()``
+~~~~~~~~~~~~~~~~~~~~
+
+The NSH initialization function, ``nsh_initialize()``, be found in
+``apps/nshlib/nsh_init.c``. It does only three things:
+
+ #. ``nsh_romfsetc()``: If so configured, it executes an NSH start-up
+ script that can be found at ``/etc/init.d/rcS`` in the target file
+ system. The ``nsh_romfsetc()`` function can be found in
+ ``apps/nshlib/nsh_romfsetc.c``. This function will (1) register a
+ ROMFS file system, then (2) mount the ROMFS file system. ``/etc`` is
+ the default location where a read-only, ROMFS file system is mounted
+ by ``nsh_romfsetc()``.
+
+ The ROMFS image is, itself, just built into the firmware. By default,
+ this ``rcS`` start-up script contains the following logic::
+
+ # Create a RAMDISK and mount it at XXXRDMOUNTPOINTXXX
+
+ mkrd -m XXXMKRDMINORXXX -s XXMKRDSECTORSIZEXXX XXMKRDBLOCKSXXX
+ mkfatfs /dev/ramXXXMKRDMINORXXX
+ mount -t vfat /dev/ramXXXMKRDMINORXXX XXXRDMOUNTPOINTXXX
+
+ Where the ``XXXX*XXXX`` strings get replaced in the template when the
+ ROMFS image is created:
+
+ - ``XXXMKRDMINORXXX`` will become the RAM device minor number.
+ Default: 0
+
+ - ``XXMKRDSECTORSIZEXXX`` will become the RAM device sector size
+
+ - ``XXMKRDBLOCKSXXX`` will become the number of sectors in the
+ device.
+
+ - ``XXXRDMOUNTPOINTXXX`` will become the configured mount point.
+ Default: ``/etc``
+
+ By default, the substituted values would yield an ``rcS`` file like::
+
+ # Create a RAMDISK and mount it at /tmp
+
+ mkrd -m 1 -s 512 1024
+ mkfatfs /dev/ram1
+ mount -t vfat /dev/ram1 /tmp
+
+ This script will, then:
+
+ - Create a RAMDISK of size 512*1024 bytes at ``/dev/ram1``,
+
+ - Format a FAT file system on the RAM disk at ``/dev/ram1``, and
+ then
+
+ - Mount the FAT file system at a configured mountpoint, ``/tmp``.
+
+ This ``rcS`` template file can be found at
+ ``apps/nshlib/rcS.template``. The resulting ROMFS file system can be
+ found in ``apps/nshlib/nsh_romfsimg.h``.
+
+ #. ``board_app_initialize()``: Next any architecture-specific NSH
+ initialization will be performed (if any). For the STM3240G-EVAL,
+ this architecture specific initialization can be found at
+ ``boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c``. This it does
+ things like: (1) Initialize SPI devices, (2) Initialize SDIO, and (3)
+ mount any SD cards that may be inserted.
+
+ #. ``nsh_netinit()``: The ``nsh_netinit()`` function can be found in
+ ``apps/nshlib/nsh_netinit.c``.
+
+NSH Commands
+************
+
+**Overview.** NSH supports a variety of commands as part of the NSH
+program. All of the NSH commands are listed in the NSH documentation
+`above <#cmdoverview>`__. Not all of these commands may be available at
+any time, however. Many commands depend upon certain NuttX configuration
+options. You can enter the help command at the NSH prompt to see the
+commands actual available:
+
+For example, if network support is disabled, then all network-related
+commands will be missing from the list of commands presented by
+'``nsh> help``'. You can see the specific command dependencies in the
+table `above <#cmddependencies>`__.
+
+Adding New NSH Commands
+~~~~~~~~~~~~~~~~~~~~~~~
+
+New commands can be added to the NSH very easily. You simply need to add
+two things:
+
+ #. The implementation of your command, and
+
+ #. A new entry in the NSH command table
+
+**Implementation of Your Command.** For example, if you want to add a
+new a new command called ``mycmd`` to NSH, you would first implement the
+``mycmd`` code in a function with this prototype:
+
+.. code-block:: c
+
+ int cmd_mycmd(FAR struct nsh_vtbl_s *vtbl, int argc, char **argv);
+
+The ``argc`` and ``argv`` are used to pass command line arguments to the
+NSH command. Command line parameters are passed in a very standard way:
+``argv[0]`` will be the name of the command, and ``argv[1]`` through
+``argv[argc-1]`` are the additional arguments provided on the NSH
+command line.
+
+The first parameter, ``vtbl``, is special. This is a pointer to
+session-specific state information. You don't need to know the contents
+of the state information, but you do need to pass this ``vtbl`` argument
+when you interact with the NSH logic. The only use you will need to make
+of the ``vtbl`` argument will be for outputting data to the console. You
+don't use ``printf()`` within NSH commands. Instead you would use:
+
+.. code-block:: c
+
+ void nsh_output(FAR struct nsh_vtbl_s *vtbl, const char *fmt, ...);
+
+So if you only wanted to output "Hello, World!" on the console, then
+your whole command implementation might be:
+
+.. code-block:: c
+
+ int cmd_mycmd(FAR struct nsh_vtbl_s *vtbl, int argc, char **argv)
+ {
+ nsh_output(vtbl, "Hello, World!");
+ return 0;
+ }
+
+The prototype for the new command should be placed in
+``apps/examples/nshlib/nsh.h``.
+
+**Adding You Command to the NSH Command Table**. All of the commands
+support by NSH appear in a single table called:
+
+.. code-block:: c
+
+ const struct cmdmap_s g_cmdmap[]
+
+That table can be found in the file
+``apps/examples/nshlib/nsh_parse.c``. The structure ``cmdmap_s`` is also
+defined in ``apps/nshlib/nsh_parse.c``:
+
+.. code-block:: c
+
+ struct cmdmap_s
+ {
+ const char *cmd; /* Name of the command */
+ cmd_t handler; /* Function that handles the command */
+ uint8_t minargs; /* Minimum number of arguments (including command) */
+ uint8_t maxargs; /* Maximum number of arguments (including command) */
+ const char *usage; /* Usage instructions for 'help' command */
+ };
+
+This structure provides everything that you need to describe your
+command: Its name (``cmd``), the function that handles the command
+(``cmd_mycmd()``), the minimum and maximum number of arguments needed by
+the command, and a string describing the command line arguments. That
+last string is what is printed when enter "``nsh> help``".
+
+So, for you sample command, you would add the following the to the
+``g_cmdmap[]`` table:
+
+.. code-block:: c
+
+ { "mycmd", cmd_mycmd, 1, 1, NULL },
+
+This entry is particularly simply because ``mycmd`` is so simple. Look
+at the other commands in ``g_cmdmap[]`` for more complex examples.
diff --git a/content/docs/10.1.0/_sources/applications/nsh/index.rst.txt b/content/docs/10.1.0/_sources/applications/nsh/index.rst.txt
new file mode 100644
index 0000000..a6650d3
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/nsh/index.rst.txt
@@ -0,0 +1,19 @@
+===============
+NuttShell (NSH)
+===============
+
+The NuttShell is a very complete shell system to be used in NuttX, similar to bash and other similar options. It supports a rich set of included commands, scripting and the ability to run your own applications as "builtin" (part of the same NuttX binary). NSH is implemented as an application where most of the functionality is part of the library called `nshlib`.
+
+As such, NSH is completely optional and can be disabled so that NuttX directly starts a given task instead of the main ``nsh`` application.
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Contents
+
+ nsh.rst
+ commands.rst
+ config.rst
+ customizing.rst
+ builtin.rst
+ installation.rst
+ login.rst
diff --git a/content/docs/10.1.0/_sources/applications/nsh/installation.rst.txt b/content/docs/10.1.0/_sources/applications/nsh/installation.rst.txt
new file mode 100644
index 0000000..2df8547
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/nsh/installation.rst.txt
@@ -0,0 +1,184 @@
+******************************
+Customizing NSH Initialization
+******************************
+
+**Ways to Customize NSH Initialization**. There are three ways to
+customize the NSH start-up behavior. Here they are presented in order of
+increasing difficulty:
+
+ #. You can extend the initialization logic in
+ ``boards/arm/stm32/stm3240g-eval/src/stm32_appinit.c``. The logic
+ there is called each time that NSH is started and is good place in
+ particular for any device-related initialization.
+
+ #. You replace the sample code at ``apps/examples/nsh/nsh_main.c`` with
+ whatever start-up logic that you want. NSH is a library at
+ ``apps/nshlib``. ``apps.examples/nsh`` is just a tiny, example
+ start-up function (``CONFIG_USER_ENTRYPOINT``\ ()) that that runs
+ immediately and illustrates how to start NSH If you want something
+ else to run immediately then you can write your write your own custom
+ ``CONFIG_USER_ENTRYPOINT``\ () function and then start other tasks
+ from your custom ``CONFIG_USER_ENTRYPOINT``\ ().
+
+ #. NSH also supports a start-up script that executed when NSH first
+ runs. This mechanism has the advantage that the start-up script can
+ contain any NSH commands and so can do a lot of work with very little
+ coding. The disadvantage is that is is considerably more complex to
+ create the start-up script. It is sufficiently complex that is
+ deserves its own paragraph
+
+NuttShell Start up Scripts
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+First of all you should look at `NSH Start-Up Script <#startupscript>`__
+paragraph. Most everything you need to know can be found there. That
+information will be repeated and extended here for completeness.
+
+**NSH Start-Up Script**. NSH supports options to provide a start up
+script for NSH. The start-up script contains any command support by NSH
+(i.e., that you see when you enter 'nsh> help'). In general this
+capability is enabled with ``CONFIG_NSH_ROMFSETC=y``, but has several
+other related configuration options as described with the `NSH-specific
+configuration settings <#nshconfiguration>`__ paragraph. This capability
+also depends on:
+
+ - ``CONFIG_DISABLE_MOUNTPOINT=n``. If mount point support is disabled,
+ then you cannot mount *any* file systems.
+
+ - ``CONFIG_FS_ROMFS`` enabled. This option enables ROMFS file system
+ support.
+
+**Default Start-Up Behavior**. The implementation that is provided is
+intended to provide great flexibility for the use of Start-Up files.
+This paragraph will discuss the general behavior when all of the
+configuration options are set to the default values.
+
+In this default case, enabling ``CONFIG_NSH_ROMFSETC`` will cause NSH to
+behave as follows at NSH start-up time:
+
+ - NSH will create a read-only RAM disk (a ROM disk), containing a tiny
+ ROMFS file system containing the following::
+
+ `--init.d/
+ `-- rcS
+
+ Where ``rcS`` is the NSH start-up script.
+
+ - NSH will then mount the ROMFS file system at ``/etc``, resulting in::
+
+ |--dev/
+ | `-- ram0
+ `--etc/
+ `--init.d/
+ `-- rcS
+
+ - By default, the contents of ``rcS`` script are::
+
+ # Create a RAMDISK and mount it at /tmp
+
+ mkrd -m 1 -s 512 1024
+ mkfatfs /dev/ram1
+ mount -t vfat /dev/ram1 /tmp
+
+ - NSH will execute the script at ``/etc/init.d/rcS`` at start-up
+ (before the first NSH prompt). After execution of the script, the
+ root FS will look like::
+
+ |--dev/
+ | |-- ram0
+ | `-- ram1
+ |--etc/
+ | `--init.d/
+ | `-- rcS
+ `--tmp/
+
+**Example Configurations**. Here are some configurations that have
+``CONFIG_NSH_ROMFSETC=y`` in the NuttX configuration file. They might
+provide useful examples:
+
+ - ``boards/arm/stm32/hymini-stm32v/nsh2``
+ - ``boards/arm/dm320/ntosd-dm320/nsh``
+ - ``boards/sim/sim/sim/nsh``
+ - ``boards/sim/sim/sim/nsh2``
+ - ``boards/sim/sim/sim/nx``
+ - ``boards/sim/sim/sim/nx11``
+ - ``boards/sim/sim/sim/touchscreen``
+
+In most of these cases, the configuration sets up the *default*
+``/etc/init.d/rcS`` script. The default script is here:
+``apps/nshlib/rcS.template``. (The funny values in the template like
+``XXXMKRDMINORXXX`` get replaced via ``sed`` at build time). This
+default configuration creates a ramdisk and mounts it at ``/tmp`` as
+discussed above.
+
+If that default behavior is not what you want, then you can provide your
+own custom ``rcS`` script by defining ``CONFIG_NSH_ARCHROMFS=y`` in the
+configuration file.
+
+**Modifying the ROMFS Image**. The contents of the ``/etc`` directory
+are retained in the file ``apps/nshlib/nsh_romfsimg.h`` OR, if
+``CONFIG_NSH_ARCHROMFS`` is defined,
+``include/arch/board/nsh_romfsimg.h``. In order to modify the start-up
+behavior, there are three things to study:
+
+ #. **Configuration Options.** The additional ``CONFIG_NSH_ROMFSETC``
+ configuration options discussed with the other `NSH-specific
+ configuration settings <#nshconfiguration>`__.
+
+ #. ``tools/mkromfsimg.sh`` **Script**. The script
+ ``tools/mkromfsimg.sh`` creates ``nsh_romfsimg.h``. It is not
+ automatically executed. If you want to change the configuration
+ settings associated with creating and mounting the ``/tmp``
+ directory, then it will be necessary to re-generate this header file
+ using the ``tools/mkromfsimg.sh`` script.
+
+ The behavior of this script depends upon several things:
+
+ #. The configuration settings then installed configuration.
+
+ #. The ``genromfs`` tool(available from
+ `http://romfs.sourceforge.net <http://romfs.sourceforge.net/>`__)
+ or included within the NuttX buildroot toolchain. There is also a
+ snapshot available in the NuttX tools repository
+ `here <https://bitbucket.org/nuttx/tools/src/master/genromfs-0.5.2.tar.gz>`__.
+
+ #. The ``xxd`` tool that is used to generate the C header files (xxd
+ is a normal part of a complete Linux or Cygwin installation,
+ usually as part of the ``vi`` package).
+
+ #. The file ``apps/nshlib/rcS.template`` (OR, if
+ ``CONFIG_NSH_ARCHROMFS`` is defined
+ ``include/arch/board/rcs.template``.
+
+ #. ``rcS.template``. The file ``apps/nshlib/rcS.template`` contains the
+ general form of the ``rcS`` file; configured values are plugged into
+ this template file to produce the final ``rcS`` file.
+
+ To generate a custom ``rcS`` file a copy of ``rcS.template`` needs to
+ be placed at ``tools/`` and changed according to the desired start-up
+ behaviour. Running ``tools/mkromfsimg.h`` creates ``nsh_romfsimg.h``
+ which needs to be copied to ``apps/nshlib`` OR if
+ ``CONFIG_NSH_ARCHROMFS`` is defined to
+ ``boards/<arch>/<chip>/<board>/include``.
+
+``rcS.template``. The default ``rcS.template``,
+``apps/nshlib/rcS.template``, generates the standard, default
+``apps/nshlib/nsh_romfsimg.h`` file.
+
+If ``CONFIG_NSH_ARCHROMFS`` is defined in the NuttX configuration file,
+then a custom, board-specific ``nsh_romfsimg.h`` file residing in
+``boards/<arch>/<chip>/<board>/include``\ will be used. NOTE when the OS
+is configured, ``include/arch/board`` will be linked to
+``boards/<arch>/<chip>/<board>/include``.
+
+All of the startup-behavior is contained in ``rcS.template``. The role
+of ``mkromfsimg.sh`` script is to (1) apply the specific configuration
+settings to ``rcS.template`` to create the final ``rcS``, and (2) to
+generate the header file ``nsh_romfsimg.h`` containing the ROMFS file
+system image. To do this, ``mkromfsimg.sh`` uses two tools that must be
+installed in your system:
+
+ #. The ``genromfs`` tool that is used to generate the ROMFS file system
+ image.
+
+ #. The ``xxd`` tool that is used to create the C header file.
diff --git a/content/docs/10.1.0/_sources/applications/nsh/login.rst.txt b/content/docs/10.1.0/_sources/applications/nsh/login.rst.txt
new file mode 100644
index 0000000..6aabfc3
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/nsh/login.rst.txt
@@ -0,0 +1,261 @@
+***********
+Shell Login
+***********
+
+Enabling Shell Logins
+*********************
+
+NuttShell sessions can be protected by requiring that the user supply
+username and password credentials at the beginning of the session.
+Logins can be enabled for standard USB or serial consoles with::
+
+ CONFIG_NSH_CONSOLE_LOGIN=y
+
+Logins for Telnet sessions can be enabled separately with::
+
+ CONFIG_NSH_TELNET_LOGIN=y
+
+Logins can be enabled for either or both session types. On a successful
+login, the user will have access to the NSH session::
+
+ login: admin
+ password:
+ User Logged-in!
+
+ NuttShell (NSH)
+ nsh>
+
+After each failed login attempt, a delay can be set up. The purpose of
+this delay is to discourage attempts to crack the password by brute
+force. That delay is configured with::
+
+ CONFIG_NSH_LOGIN_FAILDELAY=0
+
+This setting provides the login failure delay in units of milliseconds.
+The system will pause this amount of time after each failed login
+attempt. After a certain number of failed login attempts, the session
+will be closed. That number is controlled by::
+
+ CONFIG_NSH_LOGIN_FAILCOUNT=3
+
+Verification of Credentials
+***************************
+
+There are three ways that NSH can be configured to verify user
+credentials at login time:
+
+ #. The simplest implementation simply uses fixed login credentials and
+ is selected with::
+
+ CONFIG_NSH_LOGIN_FIXED=y
+
+ The fixed login credentials are selected via::
+
+ CONFIG_NSH_LOGIN_USERNAME=admin
+ CONFIG_NSH_LOGIN_PASSWORD="Administrator"
+
+ This is not very flexible since there can be only one user and the
+ password is fixed in the FLASH image. This option is also not very
+ secure because a malicious user could get the password by just
+ looking at the ``.text`` stings in the flash image.
+
+ #. NSH can also be configured to defer the entire user credential
+ verification to platform-specific logic with this setting::
+
+ CONFIG_NSH_LOGIN_PLATFORM=y
+
+ In this case, NSH will call a platform-specific function to perform
+ the verification of user credentials. The platform-specific logic
+ must provide a function with the following prototype:
+
+ .. code-block:: c
+
+ int platform_user_verify(FAR const char *username, FAR const char *password);
+
+ which is prototyped an described in ``apps/include/nsh.h`` and which
+ may be included like:
+
+ .. code-block:: c
+
+ #include <apps/nsh.h>
+
+ An appropriate place to implement this function might be in the
+ directory ``apps/platform/<board>``.
+
+ #. A final option is to use a password file contained encrypted password
+ information. This final option is selected with the following and
+ described in more detail in the following paragraph::
+
+ CONFIG_NSH_LOGIN_PASSWD=y
+
+Password Files
+**************
+
+NuttX can also be configured to support a password file, by default at
+``/etc/passwd``. This option enables support for a password file::
+
+ CONFIG_NSH_LOGIN_PASSWD=y
+
+This options requires that you have selected ``CONFIG_FSUTILS_PASSWD=y``
+to enable the access methods of ``apps/fsutils/passwd``::
+
+ CONFIG_FSUTILS_PASSWD=y
+
+And this determines the location of the password file in a mounted
+volume::
+
+ CONFIG_FSUTILS_PASSWD_PATH="/etc/passwd"
+
+``/etc/passwd`` is a *standard* location, but you will need to locate
+the password where ever you have a mounted volume.
+
+The password file can be a fixed list of users in a ROMFS file system or
+a modifiable list maintained in a file in some writable file system. If
+the password file lies in a read-only file system like ROMFS, then you
+should also indicate that the password file is read-only.
+
+ CONFIG_FSUTILS_PASSWD_READONLY=y
+
+If the password file is writable, then additional NSH commands will be
+enabled to modify the password file: ```useradd`` <#cmduseradd>`__,
+```userdel`` <#cmduserdel>`__, and ```passwd`` <#cmdpasswd>`__. If you
+do not wish you have these commands available, then they should be
+specifically disabled.
+
+The password file logic requires a few additional settings:
+
+ #. The size of dynamically allocated and freed buffer that is used for
+ file access::
+
+ CONFIG_FSUTILS_PASSWD_IOBUFFER_SIZE=512
+
+ #. And the 128-bit encryption key. The password file currently uses the
+ Tiny Encryption Algorithm (TEA), but could be extended to use
+ something more powerful.
+
+ CONFIG_FSUTILS_PASSWD_KEY1=0x12345678
+ CONFIG_FSUTILS_PASSWD_KEY2=0x9abcdef0
+ CONFIG_FSUTILS_PASSWD_KEY3=0x12345678
+ CONFIG_FSUTILS_PASSWD_KEY4=0x9abcdef0
+
+Password can only be decrypted with access to this key. Note that this
+key could potentially be fished out of your FLASH image, but without any
+symbolic information, that would be a difficult job since the TEA KEY is
+binary data and not distinguishable from other binary data in the FLASH
+image.
+
+If the password file is enabled (``CONFIG_NSH_LOGIN_PASSWD=y``), then
+the fixed user credentials will not be used for the NSH session login.
+Instead, the password file will be consulted to verify the user
+credentials.
+
+Creating a Password File for a ROMFS File System
+************************************************
+
+What we want to accomplish is a ROMFS file system, mounted at ``/etc``
+and containing the password file, ``passwd`` like::
+
+ NuttShell (NSH)
+ nsh> ls -Rl /etc
+ /etc:
+ dr-xr-xr-x 0 .
+ dr-xr-xr-x 0 init.d/
+ -r--r--r-- 39 passwd
+ /etc/init.d:
+ dr-xr-xr-x 0 ..
+ -r--r--r-- 110 rcS
+ nsh>
+
+Where ``/etc/init.d/rcS`` is the start-up script; ``/etc/passwd`` is a
+the password file. Note that here we assume that you are already using a
+start-up script. We can then piggyback the passwd file into the ``/etc``
+file system already mounted for the NSH start up file as described above
+`above <#custinit>`__.
+
+I use the sim/nsh configuration to create a new password file, but other
+configurations could also be used. That configuration already supports a
+ROMFS file system, passwords, and login prompts. First, I make these
+changes to that configuration.
+
+ #. Disable logins:
+
+ .. code-block:: diff
+
+ - CONFIG_NSH_CONSOLE_LOGIN=y
+ + # CONFIG_NSH_CONSOLE_LOGIN is not set
+ # CONFIG_NSH_TELNET_LOGIN is not set
+
+ #. Move the password file to a write-able file system:
+
+ .. code-block:: diff
+
+ - CONFIG_FSUTILS_PASSWD_PATH="/etc/passwd"
+ + CONFIG_FSUTILS_PASSWD_PATH="/tmp/passwd"
+
+ #. Make the password file modifiable
+
+ .. code-block:: diff
+
+ - CONFIG_FSUTILS_PASSWD_READONLY=y
+ # CONFIG_FSUTILS_PASSWD_READONLY is not set
+
+Now rebuild the simulation. No login should be required to enter the
+shell and you should find the ```useradd`` <#cmduseradd>`__,
+```userdel`` <#cmduserdel>`__, and ```passwd`` <#cmdpasswd>`__ commands
+available in the help summary, provided that they are enabled. Make
+certain that the ``useradd`` command is not disabled::
+
+ # CONFIG_NSH_DISABLE_USERADD is not set
+
+Use the NSH ```useradd`` <#cmduseradd>`__ command to add new uses with
+new user passwords like::
+
+ nsh> useradd <username> <password>
+
+Do this as many times as you would like. Each time that you do this a
+new entry with an encrypted password will be added to the ``passwd``
+file at ``/tmp/passwd``. You can see the content of the password file
+like::
+
+ nsh> cat /tmp/passwd
+
+When you are finished, you can simply copy the ``/tmp/passwd`` content
+from the ``cat`` command and paste it into an editor. Make sure to
+remove any carriage returns that may have ended up on the file if you
+are using Windows.
+
+Then create/re-create the ``nsh_romfsimg.h`` file as described below.
+
+ #. The content on the ``nsh_romfsimg.h`` header file is generated from a
+ template directory structure. Create the directory structure::
+
+ mkdir etc
+ mkdir etc/init.d
+
+ And copy your existing startup script into ``etc/init.c`` as ``rcS``.
+
+ #. Save your new password file in the ``etc/`` directory as ``passwd``.
+
+ #. Create the new ROMFS image::
+
+ genromfs -f romfs_img -d etc -V MyVolName
+
+ #. Convert the ROMFS image to a C header file::
+
+ xxd -i romfs_img >nsh_romfsimg.h
+
+ #. Edit ``nsh_romfsimg.h``: Mark both data definitions as ``const`` so
+ that the data will be stored in FLASH.
+
+ #. Edit nsh_romfsimg.h, mark both data definitions as ``const`` so that
+ that will be stored in FLASH.
+
+There is a good example of how to do this in the NSH simulation
+configuration at
+`boards/sim/sim/sim/configs/nsh <https://github.com/apache/incubator-nuttx/blob/master/boards/sim/sim/sim/configs/nsh/>`__.
+The ROMFS support files are provided at
+`boards/sim/include <https://github.com/apache/incubator-nuttx/blob/master/boards/sim/sim/sim/include/>`__
+and the
+`README.txt <https://github.com/apache/incubator-nuttx/blob/master/boards/sim/sim/sim/README.txt>`__
+file at the location provides detailed information about creating and
+modifying the ROMFS file system.
diff --git a/content/docs/10.1.0/_sources/applications/nsh/nsh.rst.txt b/content/docs/10.1.0/_sources/applications/nsh/nsh.rst.txt
new file mode 100644
index 0000000..f89b794
--- /dev/null
+++ b/content/docs/10.1.0/_sources/applications/nsh/nsh.rst.txt
@@ -0,0 +1,361 @@
+.. include:: /substitutions.rst
+.. _nsh:
+
+********
+Overview
+********
+
+**The NSH Library**. The ``apps/nshlib`` sub-directory contains the
+NuttShell (NSH) library. This library can easily to linked to
+produce a NSH application (See as an example
+``apps/examples/nsh``). The NSH Library provides a simple shell
+application for NuttX.
+
+Console/NSH Front End
+*********************
+
+**NSH Consoles**. Using settings in the configuration file, NSH may be
+configured to use (1) the serial stdin/out, (2) a USB serial
+device (such as CDC/ACM), or (3) a telnet connection as the
+console. Or, perhaps even all at once since or BOTH. An indefinite
+number of telnet sessions are supported.
+
+**Start-Up prompt**. When NSH is started, you will see the a welcome
+message such the following on the selected console:
+
+.. code-block::
+
+ NuttShell (NSH)
+ nsh>
+
+The greeting may also include NuttX versioning information if you
+are using a versioned copy of NuttX. ``nsh>`` is the NSH prompt
+and indicates that you may enter a command from the console.
+
+**USB console startup**. When using a USB console, the start-up
+sequence differs a little: In this case, you are required to press
+*ENTER* three times. Then NSH prompt will appear as described
+above. This is required for the following reasons:
+
+ #. This assures that the USB connection is stable. The USB
+ connection may be made, broken, and re-established a few times
+ if the USB cable is not yet fully seated. Waiting for *ENTER*
+ to be pressed three times assures that the connection is
+ stable.
+ #. The establishment of the connection is two step process: First,
+ the USB serial connection is made with the host PC. Then the
+ application that uses the serial interface is started on the
+ host. When the serial connection is established on the host,
+ the host operating system may send several *AT* modem commands
+ to the host depending upon how the host serial port is
+ configured. By waiting for *ENTER* to be pressed three
+ consecutive times, all of these modem commands will go to the
+ bit-bucket and will not be interpreted as NSH command input.
+ #. Similarly, in the second step when the applications is started,
+ there may be additional *AT* modem commands sent out the serial
+ port. Most serial terminal programs will do this unless they
+ are specifically configured to suppress the modem command
+ output. Waiting for the *ENTER* input eliminates the invalid
+ command errors from both (2) and (3).
+ #. Finally, if NSH did not wait for some positive indication that
+ the serial terminal program is up and running, then the output
+ of the NSH greeting and initial NSH prompt would be lost.
+
+**Extended Command Line Editing**. By default, NuttX uses a simple
+command line editor that allows command entry after the ``nsh>``
+and supports only the *backspace* key for editing. However, a more
+complete command line editor can be selected by setting
+``CONFIG_NSH_CLE=y`` in the NuttX configuration file. When that
+option is selected, the following EMACS-like line editing commands
+are supported:
+
+===================== ================================================
+Key Binding Editor Action
+===================== ================================================
+``^A`` Move cursor to start of the line
+``^B`` Move left one character
+``^D`` or *Del* Delete a single character at the cursor position
+``^E`` Move cursor to end of current line
+``^F`` Move right one character
+``^H`` or *Backspace* Delete character, left (backspace)
+``^K`` Delete to the end of the line
+``^U`` Delete the entire line
+===================== ================================================
+
+Command Overview
+****************
+
+**Simple, Re-directed, and Background Commands**. The NuttShell
+(NSH) is a simple shell application. NSH supports the following
+commands forms:
+
+=============================== ======================================
+Simple command ``<cmd>``
+Command with re-directed output ``<cmd> > <file> <cmd> >> <file>``
+Background command ``<cmd> &``
+Re-directed background command ``<cmd> > <file> & <cmd> >> <file> &``
+=============================== ======================================
+
+Where:
+
+ * ``<cmd>`` is any one of the simple commands listed later.
+ * ``<file>`` is the full or relative path to any writable object in the file system name space (file or character driver). Such objects will be referred to simply as files throughout this document.
+
+``nice`` **'d Background Commands**. NSH executes at the
+mid-priority (128). Backgrounded commands can be made to execute
+at higher or lower priorities using ``nice``::
+
+ [nice [-d <niceness>>]] <cmd> [> <file>|>> <file>] [&]
+
+Where ``<niceness>`` is any value between -20 and 19 where lower
+(more negative values) correspond to higher priorities. The
+default niceness is 10.
+
+**Multiple commands per line**. NSH will accept multiple commands
+per command line with each command separated with the semi-colon
+character (;).
+
+**Optional Syntax Extensions** Because these features commit
+significant resources, they are disabled by default.
+
+ - ``CONFIG_NSH_CMDPARMS``: If selected, then the output from
+ commands, from file applications, and from NSH built-in
+ commands can be used as arguments to other commands. The entity
+ to be executed is identified by enclosing the command line in
+ back quotes. For example,
+
+ .. code-block:: bash
+
+ set FOO myprogram $BAR
+
+ Will execute the program named ``myprogram`` passing it the
+ value of the environment variable ``BAR``. The value of the
+ environment variable ``FOO`` is then set output of
+ ``myprogram`` on ``stdout``.
+
+ - ``CONFIG_NSH_ARGCAT``: Support concatenation of strings
+ with environment variables or command output. For example:
+
+ .. code-block:: bash
+
+ set FOO XYZ
+ set BAR 123
+ set FOOBAR ABC_${FOO}_${BAR}
+
+ would set the environment variable ``FOO`` to ``XYZ``, ``BAR``
+ to ``123`` and ``FOOBAR`` to ``ABC_XYZ_123``. If
+ ``CONFIG_NSH_ARGCAT`` is not selected, then a slightly smaller
+ FLASH footprint results but then also only simple environment
+ variables like ``$FOO`` can be used on the command line.
+
+ - ``CONFIG_NSH_QUOTE``: Enables back-slash quoting of certain
+ characters within the command. This option is useful for the
+ case where an NSH script is used to dynamically generate a new
+ NSH script. In that case, commands must be treated as simple
+ text strings without interpretation of any special characters.
+ Special characters such as ``$``, :literal:`\``, ``"``, and
+ others must be retained intact as part of the test string. This
+ option is currently only available is ``CONFIG_NSH_ARGCAT`` is
+ also selected.
+
+Conditional Command Execution
+*****************************
+
+An ``if-then[-else]-fi`` construct is also supported in order to
+support conditional execution of commands. This works from the
+command line but is primarily intended for use within NSH scripts
+(see the ```sh`` <#cmdsh>`__ command). The syntax is as follows:
+
+.. code-block:: bash
+
+ if [!] <cmd>
+ then
+ [sequence of <cmd>]
+ else
+ [sequence of <cmd>]
+ fi
+
+Where ``<cmd>`` is a `simple command <#cmdoverview>`__. The
+command success value of zero is treated true; a non-zero command
+failure value is treated false. The ```test`` <#cmdtest>`__
+command is frequently used for comparisons.
+
+Looping
+*******
+
+**Looping Constructs**. ``while-do-done`` and ``until-do-done``
+looping constructs are also supported. These work from the command
+line but are primarily intended for use within NSH scripts (see
+the ```sh`` <#cmdsh>`__ command).
+
+ - ``while-do-done``: Execute ``[sequence of <cmd>]`` as long
+ as ``<cmd>`` has an exit status of zero. The syntax is as
+ follows:
+
+ .. code-block:: bash
+
+ while <cmd>
+ do
+ [sequence of <cmd>]
+ done
+
+ - ``until-do-done``: Execute ``[sequence of <cmd>]`` as long
+ as ``<cmd>`` has a non-zero exit status. The syntax is as
+ follows:
+
+ .. code-block::
+
+ until <cmd>
+ do
+ [sequence of <cmd>]
+ done
+
+Where ``<cmd>`` is a `simple command <#cmdoverview>`__. The
+command success value of zero is treated true; a non-zero command
+failure value is treated false. The ```test`` <#cmdtest>`__
+command is frequently used for comparisons.
+
+**The** ``break`` **Command**. A ``break`` command is also supported.
+The ``break`` command is only meaningful within the body of the a
+``while`` or ``until`` loop, between the ``do`` and ``done`` tokens.
+If the ``break`` command is executed within the body of a loop,
+the loop will immediately terminate and execution will continue
+with the next command immediately following the ``done`` token.
+
+Built-In Variables
+******************
+
+====== ====================================================
+``$?`` The result of the last simple command execution. |br|
+ On backgrounded commands, this variable holds only |br|
+ the result of spawning the background command.
+====== ====================================================
+
+Current Working Directory
+*************************
+
+``cd`` **and** ``pwd``. All path arguments to commands may be
+either an absolute path or a path relative to the current working
+directory. The current working directory is set using the
+``cd`` command and can be queried either by using the
+``pwd`` command or by using the ``echo $PWD`` command.
+
+Environment Variables
+*********************
+
+========== ================================================
+``PATH`` The default path in the file systems to look |br|
+ for executable, binary programs working directory
+``PWD`` The current working directory
+``OLDPWD`` The previous working directory
+========== ================================================
+
+NSH Start-Up Script
+*******************
+
+**NSH Start-Up Script**. NSH supports options to provide a start
+up script for NSH. In general this capability is enabled with
+``CONFIG_NSH_ROMFSETC``, but has several other related
+configuration options as described with the `NSH-specific
+configuration settings <#nshconfiguration>`__. This capability
+also depends on:
+
+ - ``CONFIG_DISABLE_MOUNTPOINT`` not set
+ - ``CONFIG_FS_ROMFS`` enabled
+
+**Default Start-Up Behavior**. The implementation that is provided
+is intended to provide great flexibility for the use of Start-Up
+files. This paragraph will discuss the general behavior when all
+of the configuration options are set to the default values.
+
+In this default case, enabling ``CONFIG_NSH_ROMFSETC`` will cause
+NSH to behave as follows at NSH startup time:
+
+ - NSH will create a read-only RAM disk (a ROM disk), containing a
+ tiny ROMFS file system containing the following::
+
+ `--init.d/
+ `-- rcS
+
+ Where rcS is the NSH start-up script.
+
+ - NSH will then mount the ROMFS file system at ``/etc``,
+ resulting in::
+
+ |--dev/
+ | `-- ram0
+ `--etc/
+ `--init.d/
+ `-- rcS
+
+ - By default, the contents of rcS script are::
+
+ # Create a RAMDISK and mount it at XXXRDMOUNTPOINTXXX
+
+ mkrd -m 1 -s 512 1024
+ mkfatfs /dev/ram1
+ mount -t vfat /dev/ram1 /tmp
+
+ - NSH will execute the script at ``/etc/init.d/rcS`` at start-up
+ (before the first NSH prompt). After execution of the script,
+ the root FS will look like::
+
+ |--dev/
+ | |-- ram0
+ | `-- ram1
+ |--etc/
+ | `--init.d/
+ | `-- rcS
+ `--tmp/
+
+**Modifying the ROMFS Image**. The contents of the ``/etc``
+directory are retained in the file ``apps/nshlib/nsh_romfsimg.h``
+OR, if ``CONFIG_NSH_ARCHROMFS`` is defined,
+``include/arch/board/rcs.template``). In order to modify the
+start-up behavior, there are three things to study:
+
+ #. **Configuration Options.** The additional
+ ``CONFIG_NSH_ROMFSETC`` configuration options discussed with
+ the other `NSH-specific configuration
+ settings <#nshconfiguration>`__.
+ #. `tools/mkromfsimg.sh`` **Script**. The script
+ ``tools/mkromfsimg.sh`` creates ``nsh_romfsimg.h``. It is not
+ automatically executed. If you want to change the configuration
+ settings associated with creating and mounting the ``/tmp``
+ directory, then it will be necessary to re-generate this header
+ file using the ``tools/mkromfsimg.sh`` script.
+
+ The behavior of this script depends upon three things:
+
+ - The configuration settings then installed configuration.
+ - The ``genromfs`` tool (available from
+ http://romfs.sourceforge.net).
+ - The file ``apps/nshlib/rcS.template`` (OR, if
+ ``CONFIG_NSH_ARCHROMFS`` is defined
+ ``include/arch/board/rcs.template``.
+
+ #. ``rcS.template``: The file ``apps/nshlib/rcS.template``
+ contains the general form of the ``rcS`` file; configured
+ values are plugged into this template file to produce the final
+ ``rcS`` file.
+
+.. note::
+ ``apps/nshlib/rcS.template`` generates the standard,
+ default ``nsh_romfsimg.h`` file. If ``CONFIG_NSH_ARCHROMFS`` is
+ defined in the NuttX configuration file, then a custom,
+ board-specific ``nsh_romfsimg.h`` file residing in the
+ ``boards/<arch>/<chip>/<board>/include`` directory will be used.
+ NOTE when the OS is configured, ``include/arch/board`` will be
+ linked to ``boards/<arch>/<chip>/<board>/include``.
+
+All of the startup-behavior is contained in ``rcS.template``. The
+role of ``mkromfsimg.sh`` is to (1) apply the specific
+configuration settings to ``rcS.template`` to create the final
+``rcS``, and (2) to generate the header file ``nsh_romfsimg.h``
+containing the ROMFS file system image.
+
+**Further Information**. See the section on `Customizing the
+NuttShell <#customizingnsh>`__ for additional, more detailed
+information about the NSH start-up script and how to modify it.
+
+
diff --git a/content/docs/10.1.0/_sources/components/binfmt.rst.txt b/content/docs/10.1.0/_sources/components/binfmt.rst.txt
new file mode 100644
index 0000000..e86c0ee
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/binfmt.rst.txt
@@ -0,0 +1,360 @@
+.. _binfmt:
+
+=============
+Binary Loader
+=============
+
+The purpose of a *binary loader* is to load and
+execute modules in various *binary formats* that reside in a file
+system. Loading refers instantiating the binary module in some fashion,
+usually copy all or some of the binary module into memory and then
+linking the module with other components. In most architectures, it is
+the base FLASH code that is the primary component that the binary module
+must link with because that is where the RTOS and primary tasks reside.
+Program modules can then be executed after they have been loaded.
+
+**Binary Formats**. The binary loader provides generic support for
+different binary formats. It supports a *registration interface* that
+allows the number of support binary formats to be loaded at run time.
+Each binary format provides a common, interface for use by the binary
+loader. When asked to load a binary, the binary loader will query each
+registered binary format, providing it with the path of the binary
+object to be loaded. The binary loader will stop when first binary
+format the recognizes the binary object and successfully loads it or
+when all registered binary formats have attempt loading the binary
+object and failed.
+
+At present, the following binary formats are support by NuttX:
+
+ - **ELF**. Standard ELF formatted files.
+ - **NXFLAT**. NuttX NXFLAT formatted files. More information about the
+ NXFLAT binary format can be found in the :ref:`NXFLAT
+ documentation <nxflat>`.
+
+**Executables and Libraries** The generic binary loader logic does not
+care what it is that it being loaded. It could load an executable
+program or a library. There are no strict rules, but a library will tend
+to export symbols and a program will tend to import symbols: The program
+will use the symbols exported by the library. However, at this point in
+time, none of the supported binary formats support exporting of symbols.
+
+**binfmt**. In the NuttX source code, the short name ``binfmt`` is used
+to refer to the NuttX binary loader. This is the name of the directory
+containing the binary loader and the name of the header files and
+variables used by the binary loader.
+
+The name ``binfmt`` is the same name used by the Linux binary loader.
+However, the NuttX binary loader is an independent development and
+shares nothing with the Linux binary loader other the same name and the
+same basic functionality.
+
+Binary Loader Interface
+=======================
+
+Header Files
+------------
+
+The interface to the binary loader is described in the header file
+``include/nuttx/binfmt/binfmt.h``.
+A brief summary of the data structurs and interfaces prototyped in that
+header file are listed below.
+
+Data Structures
+---------------
+
+When a binary format registers with the binary loader, it provides a
+pointer to a write-able instance of :c:struct:`binfmt_s`.
+
+.. c:struct:: binfmt_s
+
+ .. code-block:: c
+
+ struct binfmt_s
+ {
+ FAR struct binfmt_s *next; /* Supports a singly-linked list */
+ int (*load)(FAR struct binary_s *bin); /* Verify and load binary into memory */
+ };
+
+
+ The ``load`` method is used to load the binary format into memory. It
+ returns either ``OK`` (0) meaning that the binary object was loaded
+ successfully, or a negated ``errno`` indicating why the object was not
+ loaded.
+
+.. c:struct:: binary_s
+
+ The type ``struct binary_s`` is use both to (1) describe the binary
+ object to be loaded, and if successfully loaded, (2) to provide
+ information about where and how the binary object was loaded. That
+ structure is shown below:
+
+ .. code-block:: c
+
+ struct symtab_s;
+ struct binary_s
+ {
+ /* Information provided to the loader to load and bind a module */
+
+ FAR const char *filename; /* Full path to the binary to be loaded */
+ FAR const char **argv; /* Argument list */
+ FAR const struct symtab_s *exports; /* Table of exported symbols */
+ int nexports; /* The number of symbols in exports[] */
+
+ /* Information provided from the loader (if successful) describing the
+ * resources used by the loaded module.
+ */
+
+ main_t entrypt; /* Entry point into a program module */
+ FAR void *mapped; /* Memory-mapped, address space */
+ FAR void *alloc[BINFMT_NALLOC]; /* Allocated address spaces */
+
+ /* Constructors/destructors */
+
+ #ifdef CONFIG_BINFMT_CONSTRUCTORS
+ FAR binfmt_ctor_t *ctors; /* Pointer to a list of constructors */
+ FAR binfmt_dtor_t *dtors; /* Pointer to a list of destructors */
+ uint16_t nctors; /* Number of constructors in the list */
+ uint16_t ndtors; /* Number of destructors in the list */
+ #endif
+
+ /* Address environment.
+ *
+ * addrenv - This is the handle created by up_addrenv_create() that can be
+ * used to manage the tasks address space.
+ */
+
+ #ifdef CONFIG_ARCH_ADDRENV
+ group_addrenv_t addrenv; /* Task group address environment */
+ #endif
+
+ size_t mapsize; /* Size of the mapped address region (needed for munmap) */
+
+ /* Start-up information that is provided by the loader, but may be modified
+ * by the caller between load_module() and exec_module() calls.
+ */
+
+ uint8_t priority; /* Task execution priority */
+ size_t stacksize; /* Size of the stack in bytes (unallocated) */
+ };
+
+ Where the types ``binfmt_ctor_t`` and ``binfmt_dtor_t`` define the type
+ of one C++ constructor or destructor:
+
+ .. code-block:: c
+
+ typedef FAR void (*binfmt_ctor_t)(void);
+ typedef FAR void (*binfmt_dtor_t)(void);
+
+Function Interfaces
+-------------------
+
+Binary format management
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. c:function:: int register_binfmt(FAR struct binfmt_s *binfmt)
+
+ Register a loader for a binary format.
+
+ :return: This is a NuttX internal function so it follows the convention
+ that 0 (OK) is returned on success and a negated errno is returned on
+ failure.
+
+.. c:function:: int unregister_binfmt(FAR struct binfmt_s *binfmt)
+
+ Register a loader for a binary format.
+
+ :return:
+ This is a NuttX internal function so it follows the convention
+ that 0 (OK) is returned on success and a negated errno is returned on
+ failure.
+
+Basic module management
+~~~~~~~~~~~~~~~~~~~~~~~
+
+.. c:function:: int load_module(FAR struct binary_s *bin)
+
+ Load a module into memory, bind it to an exported symbol take,
+ and prep the module for execution.
+
+ :param bin:
+ The ``filename`` field will be used
+ in order to locate the module to be loaded from the file system.
+ The filename must be the full, absolute path to the file to be executed
+ unless ``CONFIG_LIB_ENVPATH`` is defined. In that case, filename may be
+ a relative path; a set of candidate absolute paths will be generated using
+ the ``PATH`` environment variable and ``load_module()`` will attempt to load each
+ file that is found at those absolute paths.
+
+ :return:
+ This is a NuttX internal function so it follows the convention that 0 (``OK``)
+ is returned on success and a negated ``errno`` is returned on failure.
+
+.. c:function:: int unload_module(FAR struct binary_s *bin)
+
+ Unload a (non-executing) module from memory. If the module has been started
+ (via :c:func:`exec_module`) and has not exited, calling this will be fatal.
+
+ However, this function must be called after the module exist. How this is
+ done is up to your logic. Perhaps you register it to be called by :c:func:`on_exit`?
+
+ :return:
+ This is a NuttX internal function so it follows the convention that 0 (``OK``)
+ is returned on success and a negated ``errno`` is returned on failure.
+
+.. c:function:: int exec_module(FAR const struct binary_s *bin);
+
+ Execute a module that has been loaded into memory by :c:func:`load_module`.
+
+ :return:
+ This is a NuttX internal function so it follows the convention that 0 (``OK``)
+ is returned on success and a negated ``errno`` is returned on failure.
+
+.. tip::
+ The function :c:func:`exec` is a convenience function that wraps
+ :c:func:`load_module` and :c:func:`exec_module` into one call.
+
+``PATH`` traversal logic
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. c:function:: ENVPATH_HANDLE envpath_init(void);
+
+ Initialize for the traversal of each value in the ``PATH`` variable. The
+ usage is sequence is as follows:
+
+ #. Call :c:func:`envpath_init` to initialize for the traversal.
+ ``envpath_init()`` will return an opaque handle that can then be
+ provided to :c:func:`envpath_next` and :c:func:`envpath_release`.
+ #. Call :c:func:`envpath_next` repeatedly to examine every file that lies in
+ the directories of the ``PATH`` variable.
+ #. Call :c:func:`envpath_release` to free resources set aside by
+ :c:func:`envpath_init`.
+
+ :return:
+ On success, :c:func:`envpath_init` return a non-``NULL``, opaque handle
+ that may subsequently be used in calls to :c:func:`envpath_next` and
+ :c:func:`envpath_release`. On error, a ``NULL`` handle value will be returned.
+ The most likely cause of an error would be that there is no value
+ associated with the ``PATH`` variable.
+
+.. c:function:: FAR char *envpath_next(ENVPATH_HANDLE handle, FAR const char *relpath)
+
+ Traverse all possible values in the PATH variable in attempt to find the
+ full path to an executable file when only a relative path is provided.
+
+ :param handle: The handle value returned by :c:func:`envpath_init`.
+ :param relpath: The relative path to the file to be found.
+
+ :return:
+ On success, a non-``NULL`` pointer to a null-terminated string is provided.
+ This is the full path to a file that exists in the file system.
+ This function will verify that the file exists (but will not verify that it is marked executable).
+
+ .. note::
+ The string pointer return in the success case points to allocated memory.
+ This memory must be freed by the called by calling :c:func:`kmm_free`.
+
+ ``NULL`` relpath from any absolute path in the ``PATH`` variable.
+ In this case, there is no point in calling :c:func:`envpath_next` further;
+ :c:func:`envpath_release` must be called to release resources set aside by
+ :c:func:`envpath_init`.
+
+.. c:function:: void envpath_release(ENVPATH_HANDLE handle)
+
+Release all resources set aside by envpath_init when the
+handle value was created. The handle value is invalid on
+return from this function. Attempts to all :c:func:`envpath_next`
+or :c:func:`envpath_release` with such a stale handle will result
+in undefined (i.e., not good) behavior.
+
+ :param handle: The handle value returned by :c:func:`envpath_init`.
+
+Symbol Tables
+=============
+
+**Symbol Tables**. Symbol tables are lists of name value mappings: The
+name is a string that identifies a symbol, and the value is an address
+in memory where the symbol of that name has been positioned. In most
+NuttX architectures symbol tables are required, as a minimum, in order
+to dynamically link the loaded binary object with the base code on
+FLASH. Since the binary object was separately built and separately
+linked, these symbols will appear as *undefined* symbols in the binary
+object. The binary loader will use the symbol table to look up the
+symbol by its name and to provide the address associated with the symbol
+as needed to perform the dynamic linking of the binary object to the
+base FLASH code.
+
+Some toolchains will prefix symbols with an underscore. To support these
+toolchains the ``CONFIG_SYMTAB_DECORATED`` setting may be defined. This
+will cause a leading underscore to be ignored on *undefined* symbols
+during dynamic linking.
+
+Symbol Table Header Files
+-------------------------
+
+The interface to the symbol table logic is described in the header file
+``include/nuttx/binfmt/symtab.h``.
+A brief summary of the data structurs and interfaces prototyped in that
+header file are listed below.
+
+Symbol Table Data Structures
+----------------------------
+
+.. c:struct:: symbtab_s
+
+ Describes one entry in the symbol table.
+
+ .. code-block:: c
+
+ struct symtab_s
+ {
+ FAR const char *sym_name; /* A pointer to the symbol name string */
+ FAR const void *sym_value; /* The value associated with the string */
+ };
+
+ A symbol table is a fixed size array of ``struct symtab_s``. The
+ information is intentionally minimal and supports only:
+
+ #. Function pointers as ``sym_values``. Of other kinds of values need to
+ be supported, then typing information would also need to be included
+ in the structure.
+ #. Fixed size arrays. There is no explicit provisional for dynamically
+ adding or removing entries from the symbol table (realloc might be
+ used for that purpose if needed). The intention is to support only
+ fixed size arrays completely defined at compilation or link time.
+
+Symbol Table Function Interfaces
+--------------------------------
+
+.. c:function:: FAR const struct symtab_s *symtab_findbyname(FAR const struct symtab_s *symtab, FAR const char *name, int nsyms);
+
+ Find the symbol in the symbol table with the matching name.
+ The implementation will be linear with respect to ``nsyms`` if
+ ``CONFIG_SYMTAB_ORDEREDBYNAME`` is not selected, and logarithmic
+ if it is.
+
+ :return:
+ A reference to the symbol table entry if an entry with
+ the matching name is found; NULL is returned if the entry is not found.
+
+.. c:function:: FAR const struct symtab_s *symtab_findbyvalue(FAR const struct symtab_s *symtab, FAR void *value, int nsyms);
+
+ Find the symbol in the symbol table whose value closest
+ (but not greater than), the provided value. This version assumes
+ that table is not ordered with respect to symbol value and, hence,
+ access time will be linear with respect to ``nsyms``.
+
+ :return:
+ A reference to the symbol table entry if an entry with the matching
+ value is found; ``NULL`` is returned if the entry is not found.
+
+Configuration Variables
+=======================
+
+ - ``CONFIG_BINFMT_DISABLE``: By default, support for loadable binary formats is built.
+ This logic may be suppressed be defining this setting.
+ - ``CONFIG_BINFMT_CONSTRUCTORS``: Build in support for C++ constructors in loaded modules.
+ - ``CONFIG_SYMTAB_ORDEREDBYNAME``: Symbol tables are order by name (rather than value).
+ - ``CONFIG_SYMTAB_DECORATED``: Symbols will have a leading underscore in object files.
+
+Additional configuration options may be required for the each enabled
+binary format.
diff --git a/content/docs/10.1.0/_sources/components/drivers/block/index.rst.txt b/content/docs/10.1.0/_sources/components/drivers/block/index.rst.txt
new file mode 100644
index 0000000..f82ca26
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/block/index.rst.txt
@@ -0,0 +1,41 @@
+====================
+Block Device Drivers
+====================
+
+Block device drivers have these properties:
+
+- ``include/nuttx/fs/fs.h``. All structures and APIs needed
+ to work with block drivers are provided in this header file.
+
+- ``struct block_operations``. Each block device driver must
+ implement an instance of ``struct block_operations``. That
+ structure defines a call table with the following methods:
+
+- ``int register_blockdriver(const char *path, const struct block_operations *bops, mode_t mode, void *priv);``.
+ Each block driver registers itself by calling
+ ``register_blockdriver()``, passing it the ``path`` where it
+ will appear in the :ref:`pseudo file system <file_system_overview>` and
+ it's initialized instance of ``struct block_operations``.
+
+- **User Access**. Users do not normally access block drivers
+ directly, rather, they access block drivers indirectly through
+ the ``mount()`` API. The ``mount()`` API binds a block driver
+ instance with a file system and with a mountpoint. Then the
+ user may use the block driver to access the file system on the
+ underlying media. *Example*: See the ``cmd_mount()``
+ implementation in ``apps/nshlib/nsh_fscmds.c``.
+
+- **Accessing a Character Driver as a Block Device**. See the
+ loop device at ``drivers/loop.c``. *Example*: See the
+ ``cmd_losetup()`` implementation in
+ ``apps/nshlib/nsh_fscmds.c``.
+
+- **Accessing a Block Driver as Character Device**. See the
+ Block-to-Character (BCH) conversion logic in ``drivers/bch/``.
+ *Example*: See the ``cmd_dd()`` implementation in
+ ``apps/nshlib/nsh_ddcmd.c``.
+
+- **Examples**. ``drivers/loop.c``,
+ ``drivers/mmcsd/mmcsd_spi.c``, ``drivers/ramdisk.c``, etc.
+
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/analog.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/analog.rst.txt
new file mode 100644
index 0000000..f4714d8
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/analog.rst.txt
@@ -0,0 +1,55 @@
+========================
+Analog (ADC/DAC) Drivers
+========================
+
+The NuttX analog drivers are split into two parts:
+
+#. An "upper half", generic driver that provides the common analog
+ interface to application level code, and
+#. A "lower half", platform-specific driver that implements the
+ low-level controls to implement the analog functionality.
+
+- General header files for the NuttX analog drivers reside in
+ ``include/nuttx/analog/``. These header files includes both the
+ application level interface to the analog driver as well as the
+ interface between the "upper half" and "lower half" drivers.
+- Common analog logic and share-able analog drivers reside in the
+ ``drivers/analog/``.
+- Platform-specific drivers reside in
+ ``arch/``\ *<architecture>*\ ``/src/``\ *<hardware>* directory
+ for the specific processor *<architecture>* and for the
+ specific *<chip>* analog peripheral devices.
+
+ADC Drivers
+-----------
+
+- ``include/nuttx/analog/adc.h``. All structures and APIs needed
+ to work with ADC drivers are provided in this header file. This
+ header file includes:
+
+ #. Structures and interface descriptions needed to develop a
+ low-level, architecture-specific, ADC driver.
+ #. To register the ADC driver with a common ADC character
+ driver.
+ #. Interfaces needed for interfacing user programs with the
+ common ADC character driver.
+
+- ``drivers/analog/adc.c``. The implementation of the common ADC
+ character driver.
+
+DAC Drivers
+-----------
+
+- ``include/nuttx/analog/dac.h``. All structures and APIs needed
+ to work with DAC drivers are provided in this header file. This
+ header file includes:
+
+ #. Structures and interface descriptions needed to develop a
+ low-level, architecture-specific, DAC driver.
+ #. To register the DAC driver with a common DAC character
+ driver.
+ #. Interfaces needed for interfacing user programs with the
+ common DAC character driver.
+
+- ``drivers/analog/dac.c``. The implementation of the common DAC
+ character driver.
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/can.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/can.rst.txt
new file mode 100644
index 0000000..b08ebb0
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/can.rst.txt
@@ -0,0 +1,36 @@
+===========
+CAN Drivers
+===========
+
+NuttX supports only a very low-level CAN driver. This driver
+supports only the data exchange and does not include any
+high-level CAN protocol. The NuttX CAN driver is split into two
+parts:
+
+#. An "upper half", generic driver that provides the common CAN
+ interface to application level code, and
+#. A "lower half", platform-specific driver that implements the
+ low-level timer controls to implement the CAN functionality.
+
+Files supporting CAN can be found in the following locations:
+
+- **Interface Definition**. The header file for the NuttX CAN
+ driver resides at ``include/nuttx/can/can.h``. This header file
+ includes both the application level interface to the CAN driver
+ as well as the interface between the "upper half" and "lower
+ half" drivers. The CAN module uses a standard character driver
+ framework.
+- **"Upper Half" Driver**. The generic, "upper half" CAN driver
+ resides at ``drivers/can.c``.
+- **"Lower Half" Drivers**. Platform-specific CAN drivers reside
+ in ``arch/``\ *<architecture>*\ ``/src/``\ *<hardware>*
+ directory for the specific processor *<architecture>* and for
+ the specific *<chip>* CAN peripheral devices.
+
+**Usage Note**: When reading from the CAN driver multiple messages
+may be returned, depending on (1) the size the returned can
+messages, and (2) the size of the buffer provided to receive CAN
+messages. *Never assume that a single message will be returned*...
+if you do this, *you will lose CAN data* under conditions where
+your read buffer can hold more than one small message. Below is an
+example about how you should think of the CAN read operation:
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/foc.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/foc.rst.txt
new file mode 100644
index 0000000..1a1612a
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/foc.rst.txt
@@ -0,0 +1,48 @@
+====================
+FOC Driver Interface
+====================
+
+Field Oriented Control (FOC) is a common technique to control
+either synchronous or asynchronous alternating current machines.
+The main goal of FOC is to control direct current (Id) and
+quadrature current (Iq) in powered device.
+
+The device on the kernel side is responsible for the following:
+
+#. update PWM duty cycles
+#. return ADC current samples
+#. synchronize user-space with PWM events
+
+The Nuttx FOC driver is split into two parts:
+
+#. An "upper half", generic driver that provides the common FOC
+ interface to application level code,
+#. A "lower half", platform-specific driver that implemets
+ the low-level logic to implement the FOC functionality
+
+Files supporting FOC can be found in the following locations:
+
+- ``include/nuttx/motor/foc/foc.h``.
+ "Upper-half" FOC interface available for the user-space.
+- ``include/nuttx/motor/foc/foc_lower.h``.
+ "Lower-half" FOC interface.
+- ``drivers/motor/foc/foc_dev.c``.
+ The generic "upper half" FOC driver.
+
+The majority of the functionality available to the application
+is implemented in driver ioctl calls. Supported ioctl commands:
+
+- ``MTRIOC_START`` - Start the FOC device, arg: none.
+- ``MTRIOC_STOP`` - Stop the FOC device, arg: none.
+- ``MTRIOC_GET_STATE`` - Get the FOC device state,
+ arg: ``struct foc_state_s`` pointer.
+ This is a blocking operation that is used to synchronize the user space
+ application with ADC samples.
+- ``MTRIOC_CLEAR_FAULT`` - Clear the FOC device fault state,
+ arg: none.
+- ``MTRIOC_SET_PARAMS`` - Set the FOC device operation parameters,
+ arg: ``struct foc_params_s`` pointer.
+- ``MTRIOC_SET_CONFIG`` - Set the FOC device configuration,
+ arg: ``struct foc_cfg_s`` pointer.
+- ``MTRIOC_GET_INFO`` - Get the FOC device info,
+ arg: ``struct foc_info_s`` pointer.
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/index.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/index.rst.txt
new file mode 100644
index 0000000..f0411bb
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/index.rst.txt
@@ -0,0 +1,68 @@
+.. _chardev:
+
+========================
+Character Device Drivers
+========================
+
+Character device drivers have these properties:
+
+- ``include/nuttx/fs/fs.h``. All structures and APIs needed
+ to work with character drivers are provided in this header
+ file.
+
+- ``struct file_operations``. Each character device driver
+ must implement an instance of ``struct file_operations``. That
+ structure defines a call table with the following methods:
+
+- ``int register_driver(const char *path, const struct file_operations *fops, mode_t mode, void *priv);``.
+ Each character driver registers itself by calling
+ ``register_driver()``, passing it the ``path`` where it will
+ appear in the :ref:`pseudo file system <file_system_overview>` and it's
+ initialized instance of ``struct file_operations``.
+
+- **User Access**. After it has been registered, the character
+ driver can be accessed by user code using the standard driver
+ operations including
+ ``open()``, ``close()``, ``read()``, ``write()``, etc.
+
+- **Specialized Character Drivers**. Within the common character
+ driver framework, there are different specific varieties of
+ *specialized* character drivers. The unique requirements of the
+ underlying device hardware often mandates some customization of
+ the character driver. These customizations tend to take the
+ form of:
+
+ - Device-specific ``ioctl()`` commands used to performed
+ specialized operations on the device. These ``ioctl()`` will
+ be documented in header files under ``include/nuttx`` that
+ detail the specific device interface.
+ - Specialized I/O formats. Some devices will require that
+ ``read()`` and/or ``write()`` operations use data conforming
+ to a specific format, rather than a plain stream of bytes.
+ These specialized I/O formats will be documented in header
+ files under ``include/nuttx`` that detail the specific
+ device interface. The typical representation of the I/O
+ format will be a C structure definition.
+
+ The specialized character drivers support by NuttX are
+ documented in the following paragraphs.
+
+- **Examples**: ``drivers/dev_null.c``, ``drivers/fifo.c``,
+ ``drivers/serial.c``, etc.
+
+.. toctree::
+ :caption: Supported Drivers
+
+ serial.rst
+ touchscreen.rst
+ analog.rst
+ pwm.rst
+ can.rst
+ quadrature.rst
+ timer.rst
+ rtc.rst
+ watchdog.rst
+ keypad.rst
+ note.rst
+ foc.rst
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/keypad.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/keypad.rst.txt
new file mode 100644
index 0000000..63e0446
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/keypad.rst.txt
@@ -0,0 +1,143 @@
+=======================
+Keyboard/Keypad Drivers
+=======================
+
+**Keypads vs. Keyboards** Keyboards and keypads are really the
+same devices for NuttX. A keypad is thought of as simply a
+keyboard with fewer keys.
+
+**Special Commands**. In NuttX, a keyboard/keypad driver is simply
+a character driver that may have an (optional) encoding/decoding
+layer on the data returned by the character driver. A keyboard may
+return simple text data (alphabetic, numeric, and punctuation) or
+control characters (enter, control-C, etc.) when a key is pressed.
+We can think about this the "normal" keyboard data stream.
+However, in addition, most keyboards support actions that cannot
+be represented as text or control data. Such actions include
+things like cursor controls (home, up arrow, page down, etc.),
+editing functions (insert, delete, etc.), volume controls, (mute,
+volume up, etc.) and other special functions. In this case, some
+special encoding may be required to multiplex the normal text data
+and special command key press data streams.
+
+**Key Press and Release Events** Sometimes the time that a key is
+released is needed by applications as well. Thus, in addition to
+normal and special key press events, it may also be necessary to
+encode normal and special key release events.
+
+**Encoding/Decoding** Layer. An optional encoding/decoding layer
+can be used with the basic character driver to encode the keyboard
+events into the text data stream. The function interfaces that
+comprise that encoding/decoding layer are defined in the header
+file ``include/nuttx/input/kbd_code.h``. These functions provide
+an matched set of (a) driver encoding interfaces, and (b)
+application decoding interfaces.
+
+#. **Driver Encoding Interfaces**. These are interfaces used by
+ the keyboard/keypad driver to encode keyboard events and data.
+
+ - ``kbd_press()``
+
+ **Function Prototype:**
+
+ **Description:**
+
+ **Input Parameters:**
+
+ - ``ch``: The character to be added to the output stream.
+ - ``stream``: An instance of ``lib_outstream_s`` to perform
+ the actual low-level put operation.
+
+ **Returned Value:**
+
+ - ``kbd_release()``
+
+ **Function Prototype:**
+
+ **Description:**
+
+ **Input Parameters:**
+
+ - ``ch``: The character associated with the key that was
+ released.
+ - ``stream``: An instance of ``lib_outstream_s`` to perform
+ the actual low-level put operation.
+
+ **Returned Value:**
+
+ - ``kbd_specpress()``
+
+ **Function Prototype:**
+
+ **Description:**
+
+ **Input Parameters:**
+
+ - ``keycode``: The command to be added to the output
+ stream. The enumeration ``enum kbd_keycode_e keycode``
+ identifies all commands known to the system.
+ - ``stream``: An instance of ``lib_outstream_s`` to perform
+ the actual low-level put operation.
+
+ **Returned Value:**
+
+ - ``kbd_specrel()``
+
+ **Function Prototype:**
+
+ **Description:**
+
+ **Input Parameters:**
+
+ - ``keycode``: The command to be added to the output
+ stream. The enumeration ``enum kbd_keycode_e keycode``
+ identifies all commands known to the system.
+ - ``stream``: An instance of ``lib_outstream_s`` to perform
+ the actual low-level put operation.
+
+ **Returned Value:**
+
+#. **Application Decoding Interfaces**. These are user interfaces
+ to decode the values returned by the keyboard/keypad driver.
+
+ - ``kbd_decode()``
+
+ **Function Prototype:**
+
+ **Description:**
+
+ **Input Parameters:**
+
+ - ``stream``: An instance of ``lib_instream_s`` to perform
+ the actual low-level get operation.
+ - ``pch``: The location to save the returned value. This
+ may be either a normal, character code or a special
+ command (i.e., a value from ``enum kbd_getstate_s``.
+ - ``state``: A user provided buffer to support parsing.
+ This structure should be cleared the first time that
+ ``kbd_decode()`` is called.
+
+ **Returned Value:**
+
+ - ``KBD_PRESS`` (0)**: Indicates the successful receipt
+ of normal, keyboard data. This corresponds to a keypress
+ event. The returned value in ``pch`` is a simple byte of
+ text or control data.
+ - ``KBD_RELEASE`` (1)**: Indicates a key release event.
+ The returned value in ``pch`` is the byte of text or
+ control data corresponding to the released key.
+ - ``KBD_SPECPRESS`` (2)**: Indicates the successful
+ receipt of a special keyboard command. The returned value
+ in ``pch`` is a value from ``enum kbd_getstate_s``.
+ - ``KBD_SPECREL`` (3)**: Indicates a special command key
+ release event. The returned value in ``pch`` is a value
+ from ``enum kbd_getstate_s``.
+ - ``KBD_ERROR`` (``EOF``)**: An error has getting the
+ next character (reported by the ``stream``). Normally
+ indicates the end of file.
+
+**I/O Streams**. Notice the use of the abstract I/O streams in
+these interfaces. These stream interfaces are defined in
+``include/nuttx/streams.h``.
+
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/note.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/note.rst.txt
new file mode 100644
index 0000000..ca27d22
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/note.rst.txt
@@ -0,0 +1,296 @@
+=====================
+Note Driver Interface
+=====================
+
+Note driver is the interface to access the instrumentation data.
+The following devices are provided.
+
+- :ref:`notectl`
+- :ref:`noteram`
+
+.. _notectl:
+
+Notectl Device (``/dev/notectl``)
+=================================
+
+ ``/dev/notectl`` is the device to control an instrumentation filter in NuttX kernel.
+ The device has only ioctl function to control the filter.
+
+``/dev/notectl`` Header Files
+-----------------------------
+
+ The header file ``include/nuttx/note/notectl_driver.h`` provides the interface definitions of the device.
+
+``/dev/notectl`` Data Structures
+--------------------------------
+
+.. c:struct:: note_filter_mode_s
+
+ .. code-block:: c
+
+ struct note_filter_mode_s
+ {
+ unsigned int flag; /* Filter mode flag */
+ #ifdef CONFIG_SMP
+ unsigned int cpuset; /* The set of monitored CPUs */
+ #endif
+ };
+
+ - ``flag`` : Filter mode flag. The bitwise OR of the following defines are available.
+
+ .. c:macro:: NOTE_FILTER_MODE_FLAG_ENABLE
+
+ Enable instrumentation
+
+ .. c:macro:: NOTE_FILTER_MODE_FLAG_SYSCALL
+
+ Enable syscall instrumentation
+
+ .. c:macro:: NOTE_FILTER_MODE_FLAG_IRQ
+
+ Enable IRQ instrumentaiton
+
+ - ``cpuset`` : (SMP only) Monitor only CPUs in the bitset. Bit 0=CPU0, Bit1=CPU1, etc.
+
+.. c:struct:: note_filter_syscall_s
+
+ .. code-block:: c
+
+ struct note_filter_syscall_s
+ {
+ uint8_t syscall_mask[];
+ };
+
+ - ``syscall_mask`` : A bitmap array of the syscall filter. If a bit is set, the corresponding syscall is not recorded.
+ The following helper macros are available:
+
+ .. c:macro:: NOTE_FILTER_SYSCALLMASK_SET(nr, s)
+
+ Set syscall number `nr` as masked. `s` specifies the variable of `struct note_filter_syscall_s`
+
+ .. c:macro:: NOTE_FILTER_SYSCALLMASK_CLR(nr, s)
+
+ Set syscall number `nr` as unmasked.
+
+ .. c:macro:: NOTE_FILTER_SYSCALLMASK_ISSET(nr, s)
+
+ Check whether syscall number `nr` is masked or not. True if masked.
+
+ .. c:macro:: NOTE_FILTER_SYSCALLMASK_ZERO(s)
+
+ Clear all masks.
+
+.. c:struct:: note_filter_irq_s
+
+ .. code-block:: c
+
+ struct note_filter_irq_s
+ {
+ uint8_t irq_mask[];
+ };
+
+ - ``irq_mask`` : A bitmap array of the IRQ filter. If a bit is set, the corresponding IRQ is not recorded.
+ The following helper macros are available:
+
+ .. c:macro:: NOTE_FILTER_IRQMASK_SET(nr, s)
+
+ Set IRQ number `nr` as masked. `s` specifies the variable of `struct note_filter_irq_s`
+
+ .. c:macro:: NOTE_FILTER_IRQMASK_CLR(nr, s)
+
+ Set IRQ number `nr` as unmasked.
+
+ .. c:macro:: NOTE_FILTER_IRQMASK_ISSET(nr, s)
+
+ Check whether IRQ number `nr` is masked or not. True if masked.
+
+ .. c:macro:: NOTE_FILTER_IRQMASK_ZERO(s)
+
+ Clear all masks.
+
+``/dev/notectl`` Ioctls
+-----------------------
+
+.. c:macro:: NOTECTL_GETMODE
+
+ Get note filter mode
+
+ :argument: A writable pointer to :c:struct:`note_filter_mode_s`
+
+ :return: If success, 0 (``OK``) is returned and current note filter mode is stored into the given pointer.
+ If failed, a negated ``errno`` is returned.
+
+.. c:macro:: NOTECTL_SETMODE
+
+ Set note filter mode
+
+ :argument: A read-only pointer to :c:struct:`note_filter_mode_s`
+
+ :return: If success, 0 (``OK``) is returned and the given filter mode is set as the current settings.
+ If failed, a negated ``errno`` is returned.
+
+.. c:macro:: NOTECTL_GETSYSCALLFILTER
+
+ Get syscall filter setting
+
+ :argument: A writable pointer to :c:struct:`note_filter_syscall_s`
+
+ :return: If success, 0 (``OK``) is returned and current syscall filter mode is stored into the given pointer.
+ If failed, a negated ``errno`` is returned.
+
+.. c:macro:: NOTECTL_SETSYSCALLFILTER
+
+ Set syscall filter setting
+
+ :argument: A read-only pointer to :c:struct:`note_filter_syscall_s`
+
+ :return: If success, 0 (``OK``) is returned and the given syscall filter mode is set as the current settings.
+ If failed, a negated ``errno`` is returned.
+
+.. c:macro:: NOTECTL_GETIRQFILTER
+
+ Get IRQ filter setting
+
+ :argument: A writable pointer to :c:struct:`note_filter_irq_s`
+
+ :return: If success, 0 (``OK``) is returned and current IRQ filter mode is stored into the given pointer.
+ If failed, a negated ``errno`` is returned.
+
+.. c:macro:: NOTECTL_SETIRQFILTER
+
+ Set IRQ filter setting
+
+ :argument: A read-only pointer to :c:struct:`note_filter_irq_s`
+
+ :return: If success, 0 (``OK``) is returned and the given IRQ filter mode is set as the current settings.
+ If failed, a negated ``errno`` is returned.
+
+
+.. _noteram:
+
+Noteram Device (``/dev/note``)
+==============================
+
+ ``/dev/note`` is the device to get the trace (instrumentation) data.
+ The device has read function to get the data and ioctl function to control the buffer mode.
+
+
+``/dev/note`` Header Files
+--------------------------
+
+ The header file ``include/nuttx/note/noteram_driver.h`` provides the interface definitions of the device.
+
+``/dev/note`` Data Structures
+--------------------------------
+
+.. c:struct:: noteram_get_taskname_s
+
+ .. code-block:: c
+
+ struct noteram_get_taskname_s
+ {
+ pid_t pid;
+ char taskname[CONFIG_TASK_NAME_SIZE + 1];
+ };
+
+ - ``pid`` : Task ID to get the task name.
+
+ - ``taskname`` : The task name string corresponding to given pid.
+
+``/dev/note`` Ioctls
+--------------------
+
+.. c:macro:: NOTERAM_CLEAR
+
+ Clear all contents of the circular buffer
+
+ :argument: Ignored
+
+ :return: Always returns 0.
+
+.. c:macro:: NOTERAM_GETMODE
+
+ Get overwrite mode
+
+ :argument: A writable pointer to ``unsigned int``.
+ The overwrite mode takes one of the following values.
+
+ .. c:macro:: NOTERAM_MODE_OVERWRITE_DISABLE
+
+ Overwrite mode is disabled. When the buffer is full, accepting the data will be stopped.
+
+ .. c:macro:: NOTERAM_MODE_OVERWRITE_ENABLE
+
+ Overwrite mode is enabled.
+
+ .. c:macro:: NOTERAM_MODE_OVERWRITE_OVERFLOW
+
+ Overwrite mode is disabled and the buffer is already full.
+
+ :return: If success, 0 (``OK``) is returned and current overwrite mode is stored into the given pointer.
+ If failed, a negated ``errno`` is returned.
+
+.. c:macro:: NOTERAM_SETMODE
+
+ Set overwrite mode
+
+ :argument: A read-only pointer to ``unsigned int``.
+
+ :return: If success, 0 (``OK``) is returned and the given overwriter mode is set as the current settings.
+ If failed, a negated ``errno`` is returned.
+
+.. c:macro:: NOTERAM_GETTASKNAME
+
+ Get task name string
+
+ :argument: A writable pointer to :c:struct:`noteram_get_taskname_s`
+
+ :return: If success, 0 (``OK``) is returned and the task name corresponding to given pid is stored into the given pointer.
+ If failed, a negated ``errno`` is returned.
+
+Filter control APIs
+===================
+
+The following APIs are the functions to control note filters directly.
+These are kernel APIs and application can use them only in FLAT build.
+
+The header file ``include/nuttx/sched_note.h`` is needed to use the following APIs.
+
+API description
+---------------
+
+.. c:function:: void sched_note_filter_mode(struct note_filter_mode_s *oldm, struct note_filter_mode_s *newm);
+
+ Set and get note filter mode.
+ (Same as :c:macro:`NOTECTL_GETMODE` / :c:macro:`NOTECTL_SETMODE` ioctls)
+
+ :param oldm: A writable pointer to :c:struct:`note_filter_mode_s` to get current filter mode.
+ If 0, no data is written.
+ :param newm: A read-only pointer to :c:struct:`note_filter_mode_s` which holds the new filter mode.
+ If 0, the filter mode is not updated.
+
+ :return: None
+
+.. c:function:: void sched_note_filter_syscall(struct note_filter_syscall_s *oldf, struct note_filter_syscall_s *newf);
+
+ Set and get syscall filter setting.
+ (Same as :c:macro:`NOTECTL_GETSYSCALLFILTER` / :c:macro:`NOTECTL_SETSYSCALLFILTER` ioctls)
+
+ :param oldf: A writable pointer to :c:struct:`note_filter_syscall_s` to get current syscall filter setting.
+ If 0, no data is written.
+ :param newf: A read-only pointer to :c:struct:`note_filter_syscall_s` of the new syscall filter setting.
+ If 0, the setting is not updated.
+
+ :return: None
+
+.. c:function:: void sched_note_filter_irq(struct note_filter_irq_s *oldf, struct note_filter_irq_s *newf);
+
+ Set and get IRQ filter setting.
+ (Same as :c:macro:`NOTECTL_GETIRQFILTER` / :c:macro:`NOTECTL_SETIRQFILTER` ioctls)
+
+ :param oldf: A writable pointer to :c:struct:`note_filter_irq_s` to get current IRQ filter setting.
+ If 0, no data is written.
+ :param newf: A read-only pointer to :c:struct:`note_filter_irq_s` of the new IRQ filter setting.
+ If 0, the setting is not updated.
+
+ :return: None
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/pwm.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/pwm.rst.txt
new file mode 100644
index 0000000..6222637
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/pwm.rst.txt
@@ -0,0 +1,34 @@
+===========
+PWM Drivers
+===========
+
+For the purposes of this driver, a PWM device is any device that
+generates periodic output pulses of controlled frequency and pulse
+width. Such a device might be used, for example, to perform
+pulse-width modulated output or frequency/pulse-count modulated
+output (such as might be needed to control a stepper motor).
+
+The NuttX PWM driver is split into two parts:
+
+#. An "upper half", generic driver that provides the common PWM
+ interface to application level code, and
+#. A "lower half", platform-specific driver that implements the
+ low-level timer controls to implement the PWM functionality.
+
+Files supporting PWM can be found in the following locations:
+
+- **Interface Definition**. The header file for the NuttX PWM
+ driver reside at ``include/nuttx/timers/pwm.h``. This header
+ file includes both the application level interface to the PWM
+ driver as well as the interface between the "upper half" and
+ "lower half" drivers. The PWM module uses a standard character
+ driver framework. However, since the PWM driver is a device
+ control interface and not a data transfer interface, the
+ majority of the functionality available to the application is
+ implemented in driver ioctl calls.
+- **"Upper Half" Driver**. The generic, "upper half" PWM driver
+ resides at ``drivers/timers/pwm.c``.
+- **"Lower Half" Drivers**. Platform-specific PWM drivers reside
+ in ``arch/``\ *<architecture>*\ ``/src/``\ *<hardware>*
+ directory for the specific processor *<architecture>* and for
+ the specific *<chip>* PWM peripheral devices.
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/quadrature.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/quadrature.rst.txt
new file mode 100644
index 0000000..51d5372
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/quadrature.rst.txt
@@ -0,0 +1,29 @@
+Quadrature Encoder Drivers
+==========================
+
+NuttX supports a low-level, two-part Quadrature Encoder driver.
+
+#. An "upper half", generic driver that provides the common
+ Quadrature Encoder interface to application level code, and
+#. A "lower half", platform-specific driver that implements the
+ low-level timer controls to implement the Quadrature Encoder
+ functionality.
+
+Files supporting the Quadrature Encoder can be found in the
+following locations:
+
+- **Interface Definition**. The header file for the NuttX
+ Quadrature Encoder driver reside at
+ ``include/nuttx/sensors/qencoder.h``. This header file includes
+ both the application level interface to the Quadrature Encoder
+ driver as well as the interface between the "upper half" and
+ "lower half" drivers. The Quadrature Encoder module uses a
+ standard character driver framework.
+- **"Upper Half" Driver**. The generic, "upper half" Quadrature
+ Encoder driver resides at ``drivers/sensors/qencoder.c``.
+- **"Lower Half" Drivers**. Platform-specific Quadrature Encoder
+ drivers reside in
+ ``arch/``\ *<architecture>*\ ``/src/``\ *<hardware>* directory
+ for the specific processor *<architecture>* and for the
+ specific *<chip>* Quadrature Encoder peripheral devices.
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/rtc.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/rtc.rst.txt
new file mode 100644
index 0000000..f913e45
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/rtc.rst.txt
@@ -0,0 +1,25 @@
+RTC Drivers
+===========
+
+NuttX supports a low-level, two-part RealTime Clock (RTC) driver.
+
+#. An "upper half", generic driver that provides the common RTC
+ interface to application level code, and
+#. A "lower half", platform-specific driver that implements the
+ low-level timer controls to implement the RTC functionality.
+
+Files supporting the RTC driver can be found in the following
+locations:
+
+- **Interface Definition**. The header file for the NuttX RTC
+ driver reside at ``include/nuttx/timers/rtc.h``. This header
+ file includes both the application level interface to the RTC
+ driver as well as the interface between the "upper half" and
+ "lower half" drivers. The RTC driver uses a standard character
+ driver framework.
+- **"Upper Half" Driver**. The generic, "upper half" RTC driver
+ resides at ``drivers/timers/rtc.c``.
+- **"Lower Half" Drivers**. Platform-specific RTC drivers reside
+ in ``arch/``\ *<architecture>*\ ``/src/``\ *<hardware>*
+ directory for the specific processor *<architecture>* and for
+ the specific *<chip>* RTC peripheral devices.
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/serial.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/serial.rst.txt
new file mode 100644
index 0000000..f45e45a
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/serial.rst.txt
@@ -0,0 +1,29 @@
+=====================
+Serial Device Drivers
+=====================
+
+- ``include/nuttx/serial/serial.h``. All structures and APIs
+ needed to work with serial drivers are provided in this header
+ file.
+
+- ``struct uart_ops_s``. Each serial device driver must
+ implement an instance of ``struct uart_ops_s``. That structure
+ defines a call table with the following methods:
+
+- ``int uart_register(FAR const char *path, FAR uart_dev_t *dev);``.
+ A serial driver may register itself by calling
+ ``uart_register()``, passing it the ``path`` where it will
+ appear in the :ref:`pseudo file system <file_system_overview>` and it's
+ initialized instance of ``struct uart_ops_s``. By convention,
+ serial device drivers are registered at paths like
+ ``/dev/ttyS0``, ``/dev/ttyS1``, etc. See the
+ ``uart_register()`` implementation in ``drivers/serial.c``.
+
+- **User Access**. Serial drivers are, ultimately, normal
+ `character drivers <#chardrivers>`__ and are accessed as other
+ character drivers.
+
+- **Examples**: ``arch/arm/src/stm32/stm32_serial.c``,
+ ``arch/arm/src/lpc214x/lpc214x_serial.c``,
+ ``arch/z16/src/z16f/z16f_serial.c``, etc.
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/timer.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/timer.rst.txt
new file mode 100644
index 0000000..4ca1256
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/timer.rst.txt
@@ -0,0 +1,333 @@
+Timer Drivers
+=============
+
+Files supporting the timer driver can be found in the following
+locations:
+
+- **Interface Definition**. The header file for the NuttX timer
+ driver reside at ``include/nuttx/timers/timer.h``. This header
+ file includes both the application level interface to the timer
+ driver as well as the interface between the "upper half" and
+ "lower half" drivers. The timer driver uses a standard
+ character driver framework.
+- **"Upper Half" Driver**. The generic, "upper half" timer driver
+ resides at ``drivers/timers/timer.c``.
+- **"Lower Half" Drivers**. Platform-specific timer drivers
+ reside in ``arch/``\ *<architecture>*\ ``/src/``\ *<hardware>*
+ directory for the specific processor *<architecture>* and for
+ the specific *<chip>* timer peripheral devices.
+
+There are two ways to enable Timer Support along with the Timer Example. The first is faster and simpler. Just run the following command to use a ready config file with timer support and example included. You need to check if there's a timer config file for your specific chip. You may check it at the specific board's path: ``/boards/<arch>/<chip>/<variant>/config``.
+
+.. code-block:: console
+
+ $ ./tools/configure.sh <variant>:timer
+
+And the second way is creating your own config file. To do so, follow the next instructions.
+
+Enabling the Timer Support and Example in ``menuconfing``
+----------------------------------------------------------
+
+ 1. Select Timer Instances
+
+ To select these timers browse in the ``menuconfig`` using the following path:
+
+ Go into menu :menuselection:`System Type --> <Chip> Peripheral Selection` and press :kbd:`Enter`.
+
+ Then select one or more timers according to availability.
+
+ 2. Enable the Timer Support
+
+ Go into menu :menuselection:`Device Drivers --> Timer Driver Support` and press :kbd:`Enter`. Then enable:
+
+ - [x] Timer Support
+ - [x] Timer Arch Implementation
+
+ 3. Include the Timer Example
+
+ Go into menu :menuselection:`Application Configuration --> Examples` and press :kbd:`Enter`. Then select the Timer Example.
+
+ - [x] Timer example
+
+ Below the option, it is possible to manually configure some parameters as the standard timer device path, the timeout, the sample rate in which the counter will be read, the number of samples to be executed, and other parameters.
+
+Timer Example
+--------------
+
+The previously selected example will basically consult the timer status, set a timer alarm interval, set a timer signal handler function to be notified at the alarm, which only increments a variable, and then it will start the timer. The application will periodically consult the timer status at the sample rate previously configured through the ``menuconfig`` to follow the time left until the timer expires. After the samples have been read, the application stops de timer.
+
+The `example code <https://github.com/apache/incubator-nuttx-apps/blob/master/examples/timer/timer_main.c>`_ may be explored, its path is at ``/examples/timer/timer_main.c`` in the apps' repository.
+
+In NuttX, the timer driver is a character driver and when a chip supports multiple timers, each one is accessible through its respective file in ``/dev`` directory. Each timer is registered using a unique numeric identifier (i.e. ``/dev/timer0``, ``/dev/timer1``, ...).
+
+Use the following command to run the example:
+
+.. code-block:: console
+
+ `nsh> timer`
+
+This command will use the timer 0. To use the others, specify it through a parameter (where x is the timer number):
+
+.. code-block:: console
+
+ `nsh> timer -d /dev/timerx`
+
+Application Level Interface
+----------------------------
+
+The first necessary thing to be done in order to use the timer driver in an application is to include the header file for the NuttX timer driver. It contains the Application Level Interface to the timer driver. To do so, include:
+
+.. code-block:: c
+
+ #include <nuttx/timers/timer.h>
+
+
+At an application level, the timer functionalities may be accessed through ``ioctl`` systems calls. The available ``ioctl`` commands are:
+
+ * :c:macro:`TCIOC_START`
+ * :c:macro:`TCIOC_STOP`
+ * :c:macro:`TCIOC_GETSTATUS`
+ * :c:macro:`TCIOC_SETTIMEOUT`
+ * :c:macro:`TCIOC_NOTIFICATION`
+ * :c:macro:`TCIOC_MAXTIMEOUT`
+
+These ``ioctl`` commands internally call lower-half layer operations and the parameters are forwarded to these ops through the ``ioctl`` system call. The return of a system call is the return of an operation.
+These ``struct timer_ops_s`` keeps pointers to the implementation of each operation. Following is the struct.
+
+.. c:struct:: timer_ops_s
+.. code-block:: c
+
+ struct timer_ops_s
+ {
+ /* Required methods *******************************************************/
+
+ /* Start the timer, resetting the time to the current timeout */
+
+ CODE int (*start)(FAR struct timer_lowerhalf_s *lower);
+
+ /* Stop the timer */
+
+ CODE int (*stop)(FAR struct timer_lowerhalf_s *lower);
+
+ /* Get the current timer status */
+
+ CODE int (*getstatus)(FAR struct timer_lowerhalf_s *lower,
+ FAR struct timer_status_s *status);
+
+ /* Set a new timeout value (and reset the timer) */
+
+ CODE int (*settimeout)(FAR struct timer_lowerhalf_s *lower,
+ uint32_t timeout);
+
+ /* Call the NuttX INTERNAL timeout callback on timeout.
+ * NOTE: Providing callback==NULL disable.
+ * NOT to call back into applications.
+ */
+
+ CODE void (*setcallback)(FAR struct timer_lowerhalf_s *lower,
+ CODE tccb_t callback, FAR void *arg);
+
+ /* Any ioctl commands that are not recognized by the "upper-half" driver
+ * are forwarded to the lower half driver through this method.
+ */
+
+ CODE int (*ioctl)(FAR struct timer_lowerhalf_s *lower, int cmd,
+ unsigned long arg);
+
+ /* Get the maximum supported timeout value */
+
+ CODE int (*maxtimeout)(FAR struct timer_lowerhalf_s *lower,
+ FAR uint32_t *maxtimeout);
+ };
+
+
+
+Since ``ioctl`` system calls expect a file descriptor, before using these commands, it's necessary to open the timer device special file in order to get a file descriptor. The following snippet demonstrates how to do so:
+
+.. code-block:: c
+
+ /* Open the timer device */
+
+ printf("Open %s\n", devname);
+
+ fd = open(devname, O_RDONLY);
+ if (fd < 0)
+ {
+ fprintf(stderr, "ERROR: Failed to open %s: %d\n",
+ devname, errno);
+ return EXIT_FAILURE;
+ }
+
+.. c:macro:: TCIOC_START
+
+The ``TCIOC_START`` command calls the ``start`` operation, which is described below.
+
+.. c:function:: int start(void)
+
+ The start operation configures the timer, enables the interrupt if ``TCIOC_NOTIFICATION`` has already been called and finally starts the timer.
+
+ :return: A Linux System Error Code for failing or 0 for success.
+
+This command may be used like so:
+
+.. code-block:: c
+
+ /* Start the timer */
+
+ printf("Start the timer\n");
+
+ ret = ioctl(fd, TCIOC_START, 0);
+ if (ret < 0)
+ {
+ fprintf(stderr, "ERROR: Failed to start the timer: %d\n", errno);
+ close(fd);
+ return EXIT_FAILURE;
+ }
+
+.. c:macro:: TCIOC_STOP
+
+The ``TCIOC_STOP`` command calls the ``stop`` operation, which is described below.
+
+.. c:function:: int stop(void)
+
+ The stop operation stops the timer and disables the interrupt.
+
+ :return: A Linux System Error Code for failing or 0 for success.
+
+This command may be used like so:
+
+.. code-block:: c
+
+ /* Stop the timer */
+
+ printf("\nStop the timer\n");
+
+ ret = ioctl(fd, TCIOC_STOP, 0);
+ if (ret < 0)
+ {
+ fprintf(stderr, "ERROR: Failed to stop the timer: %d\n", errno);
+ close(fd);
+ return EXIT_FAILURE;
+ }
+
+.. c:macro:: TCIOC_GETSTATUS
+
+The ``TCIOC_GETSTATUS`` command calls the ``getstatus`` operation, which is described below.
+
+.. c:function:: int getstatus(FAR struct timer_status_s *status)
+
+ The getstatus operation gathers the timer's current information.
+
+ :param status: A writable pointer to a struct ``timer_status_s``. This struct contains 3 fields: ``flags`` (``uint32_t``), ``timeout`` (``uint32_t``) and ``timeleft`` (``uint32_t``). Bit 0 from `flags` indicates the timer's status, 1 indicates that the timer is running, zero it is stopped. Bit 1 from `flags` indicates if there's a callback registered. The `timeout` indicates the time interval that was configured to trigger an alarm, it is in microseconds. The `timeleft` interval indica [...]
+
+ :return: A Linux System Error Code for failing or 0 for success.
+
+This command may be used like so:
+
+.. code-block:: c
+
+ /* Get timer status */
+
+ ret = ioctl(fd, TCIOC_GETSTATUS, (unsigned long)((uintptr_t)&status));
+ if (ret < 0)
+ {
+ fprintf(stderr, "ERROR: Failed to get timer status: %d\n", errno);
+ close(fd);
+ exit(EXIT_FAILURE);
+ }
+
+ /* Print the timer status */
+
+ printf(" flags: %08lx timeout: %lu timeleft: %lu\n",
+ (unsigned long)status.flags, (unsigned long)status.timeout,
+ (unsigned long)status.timeleft);
+
+.. c:macro:: TCIOC_SETTIMEOUT
+
+The ``TCIOC_SETTIMEOUT`` command calls the ``settimeout`` operation, which is described below.
+
+.. c:function:: int settimeout(uint32_t timeout)
+
+ The getstatus operation sets a timeout interval to trigger the alarm and then trigger an interrupt. It defines the timer interval in which the handler will be called.
+
+ :param timeout: An argument of type ``uint32_t`` with the timeout value in microseconds.
+
+ :return: A Linux System Error Code for failing or 0 for success.
+
+This command may be used like so:
+
+.. code-block:: c
+
+ /* Set the timer interval */
+
+ printf("Set timer interval to %lu\n",
+ (unsigned long)CONFIG_EXAMPLES_TIMER_INTERVAL);
+
+ ret = ioctl(fd, TCIOC_SETTIMEOUT, CONFIG_EXAMPLES_TIMER_INTERVAL);
+ if (ret < 0)
+ {
+ fprintf(stderr, "ERROR: Failed to set the timer interval: %d\n", errno);
+ close(fd);
+ return EXIT_FAILURE;
+ }
+
+.. c:macro:: TCIOC_NOTIFICATION
+
+The ``TCIOC_NOTIFICATION`` is used to configure the timer callback to notify the application via a signal when the timer expires. This command calls the ``setcallback`` operation. Which will not be described here, since the application does not set a callback directly. Instead, the user should configure a signal handler to catch notifications, and then, configure a timer notifier to notify and to signal the previously configured signal handler. For a better performance, a separate pthrea [...]
+
+In any case, this command expects a read-only pointer to a struct `timer_notify_s`. This struct contains 2 fields: ``pid`` (``pid_t``), that indicates the ID of the task/thread to receive the signal and ``event`` (``struct sigevent``), which describes the way a task will be notified.
+
+This command may be used like so:
+
+.. code-block:: c
+
+ printf("Configure the notification\n");
+
+ notify.pid = getpid();
+ notify.event.sigev_notify = SIGEV_SIGNAL;
+ notify.event.sigev_signo = CONFIG_EXAMPLES_TIMER_SIGNO;
+ notify.event.sigev_value.sival_ptr = NULL;
+
+ ret = ioctl(fd, TCIOC_NOTIFICATION, (unsigned long)((uintptr_t)¬ify));
+ if (ret < 0)
+ {
+ fprintf(stderr, "ERROR: Failed to set the timer handler: %d\n", errno);
+ close(fd);
+ return EXIT_FAILURE;
+ }
+
+
+.. c:macro:: TCIOC_MAXTIMEOUT
+
+The ``TCIOC_MAXTIMEOUT`` command calls the ``maxtimeout`` operation, which is described below.
+
+.. c:function:: int maxtimeout(uint32_t *status)
+
+ The maxtimeout operation gets the maximum timeout value that can be configured.
+
+ :param maxtimeout: A writable pointer to a variable of ``uint32_t`` type in which the value will be stored.
+ :return: A Linux System Error Code for failing or 0 for success.
+
+This command may be used like so:
+
+.. code-block:: c
+
+ /* Get the maximum timer timeout */
+
+ printf("Get the maximum timer timeout\n");
+
+ ret = ioctl(fd, TCIOC_MAXTIMEOUT, (uint32_t*)(&max_timeout));
+ if (ret < 0)
+ {
+ fprintf(stderr, "ERROR: Failed to reat the timer's maximum timeout: %d\n", errno);
+ close(fd);
+ return EXIT_FAILURE;
+ }
+
+ /* Print the maximum supported timeout */
+
+ printf("Maximum supported timeout: %" PRIu32 "\n", max_timeout);
+
+
+Those snippets were taken from the Example which provides a great resource to demonstrate how to use those ``ioctl`` commands.
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/touchscreen.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/touchscreen.rst.txt
new file mode 100644
index 0000000..70876d5
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/touchscreen.rst.txt
@@ -0,0 +1,38 @@
+==========================
+Touchscreen Device Drivers
+==========================
+
+NuttX supports a two-part touchscreen driver architecture.
+
+#. An "upper half", generic driver that provides the common
+ touchscreen interface to application level code, and
+#. A "lower half", platform-specific driver that implements the
+ low-level touchscreen controls to implement the touchscreen
+ functionality.
+
+Files supporting the touchscreen controller (TSC) driver can be
+found in the following locations:
+
+- **Interface Definition**. The header files for NuttX
+ touchscreen drivers reside in the
+ ``include/nuttx/include/input`` directory. The interface
+ between the touchscreen controller "upper half" and "lower
+ half" drivers are *not* common, but vary from
+ controller-to-controller. Because of this, each touchscreen
+ driver has its own unique header file that describes the "upper
+ half"/"lower half" interface in that directory. The application
+ level interface to each touchscreen driver, on the other hand,
+ *is* the same for each touchscreen driver and is described
+ ``include/nuttx/include/input/touchscreen.h``. The touchscreen
+ driver uses a standard character driver framework but read
+ operations return specially formatted data.
+- **"Upper Half" Driver**. The controller-specific, "upper half"
+ touchscreen drivers reside in the directory ``drivers/input``.
+- **"Lower Half" Drivers**. Platform-specific touchscreen drivers
+ reside in either: (1) The
+ ``arch/``\ *<architecture>*\ ``/src/``\ *<hardware>* directory
+ for the processor architectures that have build in touchscreen
+ controllers or (2) the
+ ``boards/``\ *<arch>*\ ``/``\ *<chip>*\ ``/``\ *<board>*\ ``/src/``
+ directory for boards that use an external touchscreen
+ controller chip.
diff --git a/content/docs/10.1.0/_sources/components/drivers/character/watchdog.rst.txt b/content/docs/10.1.0/_sources/components/drivers/character/watchdog.rst.txt
new file mode 100644
index 0000000..b4e8e53
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/character/watchdog.rst.txt
@@ -0,0 +1,204 @@
+======================
+Watchdog Timer Drivers
+======================
+
+NuttX supports a low-level, two-part watchdog timer driver.
+
+#. An "upper half", generic driver that provides the common
+ watchdog timer interface to application level code, and
+#. A "lower half", platform-specific driver that implements the
+ low-level timer controls to implement the watchdog timer
+ functionality.
+
+Files supporting the watchdog timer driver can be found in the
+following locations:
+
+- **Interface Definition**. The header file for the NuttX
+ watchdog timer driver reside at
+ ``include/nuttx/timers/watchdog.h``. This header file includes
+ both the application level interface to the watchdog timer
+ driver as well as the interface between the "upper half" and
+ "lower half" drivers. The watchdog timer driver uses a standard
+ character driver framework.
+- **"Upper Half" Driver**. The generic, "upper half" watchdog
+ timer driver resides at ``drivers/timers/watchdog.c``.
+- **"Lower Half" Drivers**. Platform-specific watchdog timer
+ drivers reside in
+ ``arch/``\ *<architecture>*\ ``/src/``\ *<hardware>* directory
+ for the specific processor *<architecture>* and for the
+ specific *<chip>* watchdog timer peripheral devices.
+
+There are two ways to enable Watchdog Timer Support along with the Watchdog Example. The first is faster and simpler. Just run the following command to use a ready config file with watchdog timer support and example included. You need to check if there's a watchdog config file for your specific chip. You may check it at the specific board's path: ``/boards/<arch>/<chip>/<board>/config``.
+
+.. code-block:: console
+
+ $ ./tools/configure.sh <board>:watchdog
+
+And the second way is creating your own config file. To do so, follow the next instructions.
+
+Enabling the Watchdog Support and Example in ``menuconfing``
+------------------------------------------------------------
+
+1. Select Watchdog Timer Instances
+
+ To select these wdts browse in the ``menuconfig`` using the following path:
+
+ Go into menu :menuselection:`System Type --> <Chip> Peripheral Selection` and press :kbd:`Enter`. Then select one or more watchdog timers according to availability of your chip.
+
+2. Enable the Watchdog Timer Support
+
+ Go into menu :menuselection:`Device Drivers --> Timer Driver Support` and press :kbd:`Enter`. Then enable:
+
+ - [x] Watchdog Timer Support
+
+3. Include the Watchdog Timer Example
+
+ Go into menu :menuselection:`Application Configuration --> Examples` and press :kbd:`Enter`. Then select the Watchdog Timer example.
+
+ - [x] Watchdog Timer example
+
+ Below the option, it is possible to manually configure some standard parameters that will be used by the example, but they also can be passed as command line arguments later.
+ The parameters are the following: the standard timer device path (which defines the WDT instance), the timeout period (which is the period on which the watchdog will expire),
+ the ping delay (which is the interval period between feeding the dog) and the ping time (which is the total interval that the example will feed the dog, after this interval,
+ the dog will starve and the chip will trigger an interrupt or reset.
+
+4. Include the Debug Watchdog Feature
+
+ In order to get the watchdog timer status, you need to enable it. For production code and for your application you may disable it.
+
+ Go into menu :menuselection:`Build Setup --> Debug Options` and press :kbd:`Enter`. Then enable:
+
+ - [x] Enable Debug Features
+ - [x] Watchdog Timer Debug Features
+
+Watchdog Timer Example
+----------------------
+
+The previously selected example will basically do the following:
+
+* Open the watchdog device
+* Set the watchdog timeout
+* Start the watchdog timer
+* Ping (feed the dog) during the ``pingtime`` with a delay of ``pingdelay`` and print out the wdt status in case debug was enabled.
+* Enter into an endless loop without pinging. It will cause the watchdog timer to reset the chip on timeout, i.e., after timer expiration.
+
+
+The `example code <https://github.com/apache/incubator-nuttx-apps/blob/master/examples/watchdog/watchdog_main.c>`_ may be explored, its path is at ``/examples/watchdog/watchdog_main.c`` in the apps' repository.
+
+In NuttX, the watchdog timer driver is a character driver and when a chip supports multiple watchdog timers, each one is accessible through its respective special file in ``/dev`` directory. Each watchdog timer is registered using a unique numeric identifier (i.e. ``/dev/watchdog0``, ``/dev/watchdog1``, ...).
+
+Use the following command to run the example:
+
+.. code-block:: console
+
+ nsh> wdog
+
+This command will use the watchdog timer 0. To use the others, specify it through a parameter (where x is the timer number):
+
+.. code-block:: console
+
+ nsh> wdog -i /dev/watchdogx
+
+Application Level Interface
+----------------------------
+
+The first necessary thing to be done in order to use the watchdog timer driver in an application is to include the header file for the NuttX Watchdog timer driver. It contains the Application Level Interface to the timer driver. To do so, include:
+
+.. code-block:: c
+
+ #include <nuttx/timers/watchdog.h>
+
+
+At an application level, the watchdog timer functionalities may be accessed through ``ioctl`` systems calls. These ``ioctl`` commands internally call lower-half layer operations and the parameters are forwarded to these operations through the ``ioctl`` system call. The example provides a great resource to demonstrate how to use those ``ioctl`` commands. The available ``ioctl`` commands are:
+
+.. c:macro:: WDIOC_START
+
+This command starts the watchdog timer.
+
+.. c:macro:: WDIOC_STOP
+
+This command stops the watchdog timer.
+
+.. c:macro:: WDIOC_GETSTATUS
+
+This command gets the status of the watchdog timer. It receives a writeable pointer to struct ``watchdog_status_s`` as parameter. The lower-half driver writes the current status in this struct.
+
+.. c:struct:: watchdog_status_s
+.. code-block:: c
+
+ struct watchdog_status_s
+ {
+ uint32_t flags; /* See WDFLAGS_* definitions above */
+ uint32_t timeout; /* The current timeout setting (in milliseconds) */
+ uint32_t timeleft; /* Time left until the watchdog expiration
+ * (in milliseconds) */
+ };
+
+.. c:macro:: WDIOC_SETTIMEOUT
+
+This command sets the timeout value, i.e., the value that will trigger the reset or interrupt. The argument is a ``uint32_t`` value in miliseconds.
+
+.. c:macro:: WDIOC_CAPTURE
+
+This command registers an user callback that will be triggered on timeout. It receives as argument a pointer to struct ``watchdog_capture_s``. If the user callback is NULL, then it configures only to reset. Not all chips support interrupt on timeout. This command is optional, i.e., if it's not used, the standard behaviour is to reset on timeout.
+
+.. c:struct:: watchdog_capture_s
+.. code-block:: c
+
+ struct watchdog_capture_s
+ {
+ CODE xcpt_t newhandler; /* The new watchdog capture handler */
+ CODE xcpt_t oldhandler; /* The previous watchdog capture handler (if any) */
+ };
+
+.. c:macro:: WDIOC_KEEPALIVE
+
+ This command resets the watchdog timer AKA '**ping**", "**kick**", "**pet**", "**feed**" the dog".
+
+Enable Built in System Monitoring to reset the watchdog
+-------------------------------------------------------
+
+The auto-monitor provides an OS-internal mechanism to automatically start and repeatedly reset the watchdog.
+
+To enable it, follow the next instructions:
+
+1. Select a Watchdog Timer Instance
+
+ To select the wdt browse in the ``menuconfig`` using the following path:
+
+ Go into menu :menuselection:`System Type --> <Chip> Peripheral Selection` and press :kbd:`Enter`. Then select one watchdog timer.
+
+2. Enable the Auto-monitor option
+
+ Go into menu :menuselection:`Device Drivers --> Timer Driver Support` and press :kbd:`Enter`. Then enable:
+
+ - [x] Watchdog Timer Support
+
+ Then press :kbd:`Enter` again to enter into the Watchdog Timer Support menu. And finally enable the Auto-monitor option:
+
+ - [x] Auto-monitor
+
+ After selecting the option you may want to configure some parameters:
+
+ * **Timeout**: It is the watchdog timer expiration time in seconds.
+ * **Keep a live interval**: This is the interval in which the watchdog will be fed. It is in seconds. It can't be bigger than the timeout. If this interval is equal to timeout interval, than this interval will automatically change to half timeout.
+ * **Keep alive by**: This is a choice to determine who is going to feed the dog. There are 4 possible choices that are described as follows.
+
+ ``Capture callback``: This choice registers a watchdog timer callback to reset the watchdog every time it expires, i.e., on timeout.
+
+ ``Timer callback``: This choice also uses a timer callback to reset the watchdog, but it will reset the watchdog every "keep a live interval".
+
+ ``Worker callback``: This choice uses a Work Queue to reset the watchdog every "keep a live interval". This choice depends on having the Low or High Priority Work Queue enabled.
+ If only the High Priority Work Queue is enabled, this one will be used, otherwise Low Priority Work Queue is used.
+
+ So, before enabling it, go into menu :menuselection:`RTOS Features --> Work queue support` and press :kbd:`Enter`.
+
+ - [x] Low priority (kernel) worker thread
+
+ ``Idle callback``: This choice sets an Idle callback to feed the dog. It depends on the PM module, because this callback is triggered by the PM state change. To enable it do the following:
+
+ Go into menu :menuselection:`Device Drivers` and enable:
+
+ - [x] Power Management Support
+
+After selecting one of these choices, the chip will keep itself alive by one of these options.
diff --git a/content/docs/10.1.0/_sources/components/drivers/index.rst.txt b/content/docs/10.1.0/_sources/components/drivers/index.rst.txt
new file mode 100644
index 0000000..fb4821c
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/index.rst.txt
@@ -0,0 +1,32 @@
+==============
+Device Drivers
+==============
+
+NuttX supports a variety of device drivers, which can be broadly
+divided in three classes:
+
+.. toctree::
+ :maxdepth: 1
+
+ character/index.rst
+ block/index.rst
+ special/index.rst
+
+.. note::
+ Device driver support depends on the *in-memory*, *pseudo*
+ file system that is enabled by default.
+
+Lower-half and upper-half
+=========================
+
+Drivers in NuttX generally work in two distinct layers:
+
+ * An *upper half* which registers itself to NuttX using
+ a call such as :c:func:`register_driver` or
+ :c:func:`register_blockdriver` and implements the corresponding
+ high-level interface (`read`, `write`, `close`, etc.).
+ implements the interface. This *upper half* calls into
+ the *lower half* via callbacks.
+ * A "lower half" which is typically hardware-specific. This is
+ usually implemented at the architecture or board level.
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/ethernet.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/ethernet.rst.txt
new file mode 100644
index 0000000..a8f371a
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/ethernet.rst.txt
@@ -0,0 +1,17 @@
+=======================
+Ethernet Device Drivers
+=======================
+
+- ``include/nuttx/net/netdev.h``. All structures and APIs
+ needed to work with Ethernet drivers are provided in this
+ header file. The structure ``struct net_driver_s`` defines the
+ interface and is passed to the network via
+ ``netdev_register()``.
+
+- ``int netdev_register(FAR struct net_driver_s *dev, enum net_lltype_e lltype);``.
+ Each Ethernet driver registers itself by calling
+ ``netdev_register()``.
+
+- **Examples**: ``drivers/net/dm90x0.c``,
+ ``arch/drivers/arm/src/c5471/c5471_ethernet.c``,
+ ``arch/z80/src/ez80/ez80_emac.c``, etc.
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/framebuffer.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/framebuffer.rst.txt
new file mode 100644
index 0000000..aefa7d1
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/framebuffer.rst.txt
@@ -0,0 +1,34 @@
+====================
+Frame Buffer Drivers
+====================
+
+- ``include/nuttx/video/fb.h``. All structures and APIs
+ needed to work with frame buffer drivers are provided in this
+ header file.
+
+- ``struct fb_vtable_s``. Each frame buffer device driver
+ must implement an instance of ``struct fb_vtable_s``. That
+ structure defines a call table with the following methods:
+
+ Get information about the video controller configuration and
+ the configuration of each color plane.
+
+ The following are provided only if the video hardware supports
+ RGB color mapping:
+
+ The following are provided only if the video hardware supports
+ a hardware cursor:
+
+- **Binding Frame Buffer Drivers**. Frame buffer drivers are not
+ normally directly accessed by user code, but are usually bound
+ to another, higher level device driver. In general, the binding
+ sequence is:
+
+ #. Get an instance of ``struct fb_vtable_s`` from the
+ hardware-specific frame buffer device driver, and
+ #. Provide that instance to the initialization method of the
+ higher level device driver.
+
+- **Examples**: ``arch/sim/src/up_framebuffer.c``. See also the
+ usage of the frame buffer driver in the ``graphics/``
+ directory.
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/i2c.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/i2c.rst.txt
new file mode 100644
index 0000000..a284468
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/i2c.rst.txt
@@ -0,0 +1,22 @@
+==================
+I2C Device Drivers
+==================
+
+- ``include/nuttx/i2c/i2c.h``. All structures and APIs needed
+ to work with I2C drivers are provided in this header file.
+
+- ``struct i2c_ops_s``. Each I2C device driver must implement
+ an instance of ``struct i2c_ops_s``. That structure defines a
+ call table with the following methods:
+
+- **Binding I2C Drivers**. I2C drivers are not normally directly
+ accessed by user code, but are usually bound to another, higher
+ level device driver. In general, the binding sequence is:
+
+ #. Get an instance of ``struct i2c_master_s`` from the
+ hardware-specific I2C device driver, and
+ #. Provide that instance to the initialization method of the
+ higher level device driver.
+
+- **Examples**: ``arch/z80/src/ez80/ez80_i2c.c``,
+ ``arch/z80/src/z8/z8_i2c.c``, etc.
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/index.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/index.rst.txt
new file mode 100644
index 0000000..4a58f03
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/index.rst.txt
@@ -0,0 +1,36 @@
+==========================
+Specialized Device Drivers
+==========================
+
+All device drivers that are accessible to application logic are
+either: (1) Character device drivers that can be accessed via the
+standard driver operations (``open()``, ``close()``, ``read()``,
+``write()``, etc.), or (2) block drivers that can be accessing
+only as part of mounting a file system or other special use cases
+as described in the preceding paragraph.
+
+In addition to this, there are also specialized "drivers" that can
+be used only within the OS logic itself and are not accessible to
+application logic. These specialized drivers are discussed in the
+following section.
+
+.. note::
+ While special drivers are *internal*, in some cases there are also
+ character/block drivers that sit on top of these special drivers
+ and thus expose them to applications.
+
+.. toctree::
+ :caption: Supported Drivers
+
+ syslog.rst
+ spi.rst
+ i2c.rst
+ ethernet.rst
+ socketcan.rst
+ framebuffer.rst
+ lcd.rst
+ mtd.rst
+ sdio.rst
+ usbhost.rst
+ usbdev.rst
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/lcd.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/lcd.rst.txt
new file mode 100644
index 0000000..63da835
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/lcd.rst.txt
@@ -0,0 +1,47 @@
+===========
+LCD Drivers
+===========
+
+- ``include/nuttx/lcd/lcd.h``. Structures and APIs needed to
+ work with LCD drivers are provided in this header file. This
+ header file also depends on some of the same definitions used
+ for the frame buffer driver as provided in
+ ``include/nuttx/video/fb.h``.
+
+- ``struct lcd_dev_s``. Each LCD device driver must implement
+ an instance of ``struct lcd_dev_s``. That structure defines a
+ call table with the following methods:
+
+ Get information about the LCD video controller configuration
+ and the configuration of each LCD color plane.
+
+ The following are provided only if the video hardware supports
+ RGB color mapping:
+
+ The following are provided only if the video hardware supports
+ a hardware cursor:
+
+ Get the LCD panel power status (0: full off -
+ ``CONFIG_LCD_MAXPOWER``: full on). On backlit LCDs, this
+ setting may correspond to the backlight setting.
+
+ Enable/disable LCD panel power (0: full off -
+ ``CONFIG_LCD_MAXPOWER``: full on). On backlit LCDs, this
+ setting may correspond to the backlight setting.
+
+ Get the current contrast setting (0-CONFIG_LCD_MAXCONTRAST) \*/
+
+ Set LCD panel contrast (0-CONFIG_LCD_MAXCONTRAST)
+
+- **Binding LCD Drivers**. LCD drivers are not normally directly
+ accessed by user code, but are usually bound to another, higher
+ level device driver. In general, the binding sequence is:
+
+ #. Get an instance of ``struct lcd_dev_s`` from the
+ hardware-specific LCD device driver, and
+ #. Provide that instance to the initialization method of the
+ higher level device driver.
+
+- **Examples**: ``drivers/lcd/p14201.c``,
+ ``boards/arm/sam34/sam3u-ek/src/up_lcd.c.`` See also the usage
+ of the LCD driver in the ``graphics/`` directory.
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/mtd.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/mtd.rst.txt
new file mode 100644
index 0000000..5e6e556
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/mtd.rst.txt
@@ -0,0 +1,47 @@
+================================
+Memory Technology Device Drivers
+================================
+
+- ``include/nuttx/mtd/mtd.h``. All structures and APIs needed
+ to work with MTD drivers are provided in this header file.
+
+- ``struct mtd_dev_s``. Each MTD device driver must implement
+ an instance of ``struct mtd_dev_s``. That structure defines a
+ call table with the following methods:
+
+ Erase the specified erase blocks (units are erase blocks):
+
+ Read/write from the specified read/write blocks:
+
+ Some devices may support byte oriented reads (optional). Most
+ MTD devices are inherently block oriented so byte-oriented
+ accesses are not supported. It is recommended that low-level
+ drivers not support read() if it requires buffering.
+
+ Some devices may also support byte oriented writes (optional).
+ Most MTD devices are inherently block oriented so byte-oriented
+ accesses are not supported. It is recommended that low-level
+ drivers not support read() if it requires buffering. This
+ interface is only available if ``CONFIG_MTD_BYTE_WRITE`` is
+ defined.
+
+ Support other, less frequently used commands:
+
+ - ``MTDIOC_GEOMETRY``: Get MTD geometry
+ - ``MTDIOC_XIPBASE:``: Convert block to physical address for
+ eXecute-In-Place
+ - ``MTDIOC_BULKERASE``: Erase the entire device
+
+ is provided via a single ``ioctl`` method (see
+ ``include/nuttx/fs/ioctl.h``):
+
+- **Binding MTD Drivers**. MTD drivers are not normally directly
+ accessed by user code, but are usually bound to another, higher
+ level device driver. In general, the binding sequence is:
+
+ #. Get an instance of ``struct mtd_dev_s`` from the
+ hardware-specific MTD device driver, and
+ #. Provide that instance to the initialization method of the
+ higher level device driver.
+
+- **Examples**: ``drivers/mtd/m25px.c`` and ``drivers/mtd/ftl.c``
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/sdio.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/sdio.rst.txt
new file mode 100644
index 0000000..d03f8ec
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/sdio.rst.txt
@@ -0,0 +1,33 @@
+===================
+SDIO Device Drivers
+===================
+
+- ``include/nuttx/sdio.h``. All structures and APIs needed to
+ work with SDIO drivers are provided in this header file.
+
+- ``struct sdio_dev_s``. Each SDIO device driver must
+ implement an instance of ``struct sdio_dev_s``. That structure
+ defines a call table with the following methods:
+
+ Mutual exclusion:
+
+ Initialization/setup:
+
+ Command/Status/Data Transfer:
+
+ Event/Callback support:
+
+ DMA support:
+
+- **Binding SDIO Drivers**. SDIO drivers are not normally
+ directly accessed by user code, but are usually bound to
+ another, higher level device driver. In general, the binding
+ sequence is:
+
+ #. Get an instance of ``struct sdio_dev_s`` from the
+ hardware-specific SDIO device driver, and
+ #. Provide that instance to the initialization method of the
+ higher level device driver.
+
+- **Examples**: ``arch/arm/src/stm32/stm32_sdio.c`` and
+ ``drivers/mmcsd/mmcsd_sdio.c``
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/socketcan.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/socketcan.rst.txt
new file mode 100644
index 0000000..cd9556f
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/socketcan.rst.txt
@@ -0,0 +1,66 @@
+========================
+SocketCAN Device Drivers
+========================
+
+ - ``include/nuttx/net/netdev.h``. All structures and APIs
+ needed to work with drivers are provided in this header file.
+ The structure struct net_driver_s defines the interface and is
+ passed to the network via netdev_register().
+
+ - ``include/nuttx/can.h``. CAN & CAN FD frame data
+ structures.
+
+ - ``int netdev_register(FAR struct net_driver_s *dev, enum net_lltype_e lltype)'``.
+ Each driver registers itself by calling netdev_register().
+
+ - ``Include/nuttx/net/can.h``. contains lookup tables for CAN
+ dlc to CAN FD len sizes named
+
+ .. code-block:: c
+
+ extern const uint8_t can_dlc_to_len[16];
+ extern const uint8_t len_to_can_dlc[65];
+
+ - **Initialization sequence is as follows**.
+
+ #. up_netinitialize(void) is called on startup of NuttX in this
+ function you call your own init function to initialize your
+ CAN driver
+ #. In your own init function you create the net_driver_s
+ structure set required init values and register the required
+ callbacks for SocketCAN
+ #. Then you ensure that the CAN interface is in down mode
+ (usually done by calling the d_ifdown function)
+ #. Register the net_driver_s using netdev_register
+
+ - **Receive sequence is as follows**.
+
+ #. Device generates interrupt
+ #. Process this interrupt in your interrupt handler
+ #. When a new CAN frame has been received you process this
+ frame
+ #. When the CAN frame is a normal CAN frame you allocate the
+ can_frame struct, when it's a CAN FD frame you allocate a
+ canfd_frame struct (note you can of course preallocate and
+ just use the pointer).
+ #. Copy the frame from the driver to the struct you've
+ allocated in the previous step.
+ #. Point the net_driver_s d_buf pointer to the allocated
+ can_frame
+ #. Call the ``can_input(FAR struct net_driver_s *dev)``
+ function ``include/nuttx/net/can.h``
+
+ - **Transmit sequence is as follows**.
+
+ #. Socket layer executes d_txavail callback
+ #. An example of the txavail function can be found in
+ ``arch/arm/src/s32k1xx/s32k1xx_flexcan.c``
+ #. An example of the txpoll function can be found in
+ ``arch/arm/src/s32k1xx/s32k1xx_flexcan.c``
+ #. In your ``transmit(struct driver_s *priv)`` function you
+ check the length of ``net_driver_s.d_len`` whether it
+ matches the size of a ``struct can_frame`` or
+ ``struct canfd_frame`` then you cast the content of the
+ ``net_driver_s.d_buf`` pointer to the correct CAN frame
+ struct
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/spi.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/spi.rst.txt
new file mode 100644
index 0000000..55560ea
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/spi.rst.txt
@@ -0,0 +1,25 @@
+==================
+SPI Device Drivers
+==================
+
+- ``include/nuttx/spi/spi.h``. All structures and APIs needed
+ to work with SPI drivers are provided in this header file.
+
+- ``struct spi_ops_s``. Each SPI device driver must implement
+ an instance of ``struct spi_ops_s``. That structure defines a
+ call table with the following methods:
+
+- **Binding SPI Drivers**. SPI drivers are not normally directly
+ accessed by user code, but are usually bound to another, higher
+ level device driver. See for example,
+ ``int mmcsd_spislotinitialize(int minor, int slotno, FAR struct spi_dev_s *spi)``
+ in ``drivers/mmcsd/mmcsd_spi.c``. In general, the binding
+ sequence is:
+
+ #. Get an instance of ``struct spi_dev_s`` from the
+ hardware-specific SPI device driver, and
+ #. Provide that instance to the initialization method of the
+ higher level device driver.
+
+- **Examples**: ``drivers/loop.c``,
+ ``drivers/mmcsd/mmcsd_spi.c``, ``drivers/ramdisk.c``, etc.
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/syslog.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/syslog.rst.txt
new file mode 100644
index 0000000..7e27766
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/syslog.rst.txt
@@ -0,0 +1,511 @@
+======
+SYSLOG
+======
+
+
+SYSLOG Interfaces
+=================
+
+Standard SYSLOG Interfaces
+--------------------------
+
+The NuttX SYSLOG is an architecture for getting debug and status
+information from the system. The syslogging interfaces are defined
+in the header file ``include/syslog.h``. The primary interface to
+SYSLOG sub-system is the function ``syslog()`` and, to a lesser
+extent, its companion ``vsyslog()``:
+
+.. c::function:: int syslog(int priority, FAR const IPTR char *format, ...);
+
+ Generates a log message. The
+ priority argument is formed by ORing the facility and the level
+ values (see ``include/syslog.h``). The remaining arguments are a
+ format, as in ``printf()`` and any arguments to the format.
+
+ The NuttX implementation does not support any special formatting
+ characters beyond those supported by ``printf()``.
+
+.. c::function:: void vsyslog(int priority, FAR const IPTR char *src, va_list ap);
+
+ Performs the same task as :c:func:`syslog`
+ with the difference that it takes a set of arguments which have
+ been obtained using the ``stdarg`` variable argument list macros.
+
+.. c::function:: int setlogmask(int mask);
+
+ The additional setlogmask() interface can use use to filter SYSLOG output.
+ This function sets the logmask and returns the previous mask.
+ If the mask argument is zero, the current logmask is not modified.
+
+ The SYSLOG priorities are: ``LOG_EMERG``, ``LOG_ALERT``, ``LOG_CRIT``,
+ ``LOG_ERR``, ``LOG_WARNING``, ``LOG_NOTICE``, ``LOG_INFO``, and ``LOG_DEBUG``.
+ The bit corresponding to a priority ``p`` is ``LOG_MASK(p)``; ``LOG_UPTO(p)``
+ provides the mask of all priorities in the above list up to and including ``p``.
+
+ Per *OpenGroup.org* "If the ``maskpri`` argument is 0,
+ the current log mask is not modified." In this implementation,
+ the value zero is permitted in order to disable all SYSLOG levels.
+
+ .. note::
+ REVISIT: Per POSIX the SYSLOG mask should be a per-process value but
+ in NuttX, the scope of the mask is dependent on the nature of the build:
+
+ - *Flat Build*: There is one, global SYSLOG mask that controls
+ all output.
+
+ - *Protected Build*: There are two SYSLOG masks. One within the
+ kernel that controls only kernel output. And one in user-space
+ that controls only user SYSLOG output.
+
+ - *Kernel Build*: The kernel build is compliant with the POSIX
+ requirement: There will be one mask for for each user process,
+ controlling the SYSLOG output only form that process. There
+ will be a separate mask accessible only in the kernel code to
+ control kernel SYSLOG output.
+
+The above are all standard interfaces as defined at
+`OpenGroup.org <http://pubs.opengroup.org/onlinepubs/009695399/functions/closelog.html>`__.
+Those interfaces are available for use by application software.
+The remaining interfaces discussed in this section are non-standard, OS-internal interfaces.
+
+Debug Interfaces
+----------------
+
+In NuttX, syslog output is really synonymous to debug output and,
+therefore, the debugging interface macros defined in the header
+file ``include/debug.h`` are also syslogging interfaces. Those
+macros are simply wrappers around ``syslog()``. The debugging
+interfaces differ from the syslog interfaces in that:
+
+ - They do not take a priority parameter; the priority is inherent
+ in the debug macro name.
+
+ - They decorate the output stream with information such as the
+ file name
+
+ - They can each be disabled via configuration options.
+
+Each debug macro has a base name that represents the priority and
+a prefix that represents the sub-system. Each macro is
+individually initialized by both priority and sub-system. For
+example, ``uerr()`` is the macro used for error level messages
+from the USB subsystem and is enabled with
+``CONFIG_DEBUG_USB_ERROR``.
+
+The base debug macro names, their priority, and configuration
+variable are summarized below:
+
+- ``info()``. The ``info()`` macro is the lowest priority
+ (``LOG_INFO``) and is intended to provide general information
+ about the flow of program execution so that you can get an
+ overview of the behavior of the program. ``info()`` is often
+ very chatty and voluminous and usually more information than
+ you may want to see. The ``info()`` macro is controlled via
+ CONFIG_DEBUG_subsystem_INFO
+
+- ``warn()``. The ``warn()`` macro has medium priority
+ (``LOG_WARN``) and is controlled by
+ ``CONFIG_DEBUG_subsystem_WARN``. The ``warn()`` is intended to
+ note exceptional or unexpected conditions that might be
+ potential errors or, perhaps, minor errors that easily
+ recovered.
+
+- ``err()``. This is a high priority debug macro (``LOG_ERROR``)
+ and controlled by ``CONFIG_DEBUG_subsystem_ERROR``. The
+ ``err()`` is reserved to indicate important error conditions.
+
+- ``alert()``. The highest priority debug macro (``LOG_EMERG``)
+ and is controlled by ``CONFIG_DEBUG_ALERT``. The ``alert()``
+ macro is reserved for use solely by assertion and crash
+ handling logic. It also differs from the other macros in that
+ it cannot be enabled or disabled per subsystem.
+
+SYSLOG Channels
+===============
+
+SYSLOG Channel Interfaces
+-------------------------
+
+In the NuttX SYSLOG implementation, the underlying device logic
+the supports the SYSLOG output is referred to as a SYSLOG
+*channel*. Each SYSLOG channel is represented by an interface
+defined in ``include/nuttx/syslog/syslog.h``:
+
+.. code-block:: c
+
+ /* This structure provides the interface to a SYSLOG device */
+
+ typedef CODE int (*syslog_putc_t)(int ch);
+ typedef CODE int (*syslog_flush_t)(void);
+
+ struct syslog_channel_s
+ {
+ /* I/O redirection methods */
+
+ syslog_putc_t sc_putc; /* Normal buffered output */
+ syslog_putc_t sc_force; /* Low-level output for interrupt handlers */
+ syslog_flush_t sc_flush; /* Flush buffered output (on crash) */
+
+ /* Implementation specific logic may follow */
+ };
+
+The channel interface is instantiated by calling
+:c:func:`syslog_channel()`.
+
+.. c:function:: int syslog_channel(FAR const struct syslog_channel_s *channel);
+
+ Configure the SYSLOG function to use the provided
+ channel to generate SYSLOG output.
+
+ ``syslog_channel()`` is a non-standard, internal OS interface and
+ is not available to applications. It may be called numerous times
+ as necessary to change channel interfaces. By default, all system
+ log output goes to console (``/dev/console``).
+
+ :param channel: Describes the interface to the channel to be used.
+
+ :return:
+ Zero (OK)is returned on success. A negated errno value is
+ returned on any failure.
+
+SYSLOG Channel Initialization
+-----------------------------
+
+The initial, default SYSLOG channel is established with statically
+initialized global variables so that some level of SYSLOG output
+may be available immediately upon reset. This initialized data is
+in the file ``drivers/syslog/syslog_channel.c``. The initial
+SYSLOG capability is determined by the selected SYSLOG channel:
+
+- *In-Memory Buffer (RAMLOG)*. Full SYSLOG capability as
+ available at reset.
+
+- *Serial Console*. If the serial implementation provides the
+ low-level character output function ``up_putc()``, then that
+ low level serial output is available as soon as the serial
+ device has been configured.
+
+- For all other SYSLOG channels, all SYSLOG output goes to the
+ bit- bucket until the SYSLOG channel device has been
+ initialized.
+
+The syslog channel device is initialized when the bring-up logic
+calls :c:func:`syslog_initialize()`.
+
+.. c:function:: int syslog_initialize(void)
+
+ .. code-block:: c
+
+ #include <nuttx/syslog/syslog.h>
+ #ifndef CONFIG_ARCH_SYSLOG
+ int syslog_initialize(void);
+ #else
+ # define syslog_initialize()
+ #endif
+
+ One power up, the SYSLOG facility is non-existent
+ or limited to very low-level output. This function is called later
+ in the initialization sequence after full driver support has been
+ initialized. It installs the configured SYSLOG drivers and enables
+ full SYSLOG capability.
+
+ This function performs these basic operations:
+
+ - Initialize the SYSLOG device
+
+ - Call :c:func:`syslog_channel` to begin using that device.
+
+ - If ``CONFIG_ARCH_SYSLOG`` is selected, then the
+ architecture-specific logic will provide its own SYSLOG device
+ initialize which must include as a minimum a call to
+ :c:func:`syslog_channel` to use the device.
+
+ :return:
+ Zero (``OK``) is returned on success; a
+ negated ``errno`` value is returned on any failure.
+
+Different types of SYSLOG devices have different OS initialization
+requirements. Some are available immediately at reset, some are
+available after some basic OS initialization, and some only after
+OS is fully initialized.
+
+There are other types of SYSLOG channel devices that may require
+even further initialization. For example, the file SYSLOG channel
+(described below) cannot be initialized until the necessary file
+systems have been mounted.
+
+Interrupt Level SYSLOG Output
+-----------------------------
+
+As a general statement, SYSLOG output only supports *normal*
+output from NuttX tasks. However, for debugging purposes, it is
+also useful to get SYSLOG output from interrupt level logic. In an
+embedded system, that is often where the most critical operations
+are performed.
+
+There are three conditions under which SYSLOG output generated
+from interrupt level processing can a included the SYSLOG output
+stream:
+
+ #. **Low-Level Serial Output**. If you are using a SYSLOG console
+ channel (``CONFIG_SYSLOG_CONSOLE``) and if the underlying
+ architecture supports the low-level ``up_putc()``
+ interface(\ ``CONFIG_ARCH_LOWPUTC``), then the SYSLOG logic
+ will direct the output to ``up_putc()`` which is capable of
+ generating the serial output within the context of an interrupt
+ handler.
+
+ There are a few issues in doing this however:
+
+ - ``up_putc()`` is able to generate debug output in any
+ context because it disables serial interrupts and polls the
+ hardware directly. These polls may take many milliseconds
+ and during that time, all interrupts are disable within the
+ interrupt handler. This, of course, interferes with the
+ real-time behavior of the RTOS.
+
+ - The output generated by ``up_putc()`` is immediate and in
+ real-time. The normal SYSLOG output, on the other hand, is
+ buffered in the serial driver and may be delayed with
+ respect to the immediate output by many lines. Therefore,
+ the interrupt level SYSLOG output provided through
+ ``up_putc()`` is grossly out of synchronization with other
+ debug output
+
+ #. **In-Memory Buffering**. If the RAMLOG SYSLOG channel is
+ supported, then all SYSLOG output is buffered in memory.
+ Interrupt level SYSLOG output is no different than normal
+ SYSLOG output in this case.
+
+ #. **Serialization Buffer**. A final option is the use of an
+ *interrupt buffer* to buffer the interrupt level SYSLOG output.
+ In this case:
+
+ - SYSLOG output generated from interrupt level process in not
+ sent to the SYSLOG channel immediately. Rather, it is
+ buffered in the interrupt serialization buffer.
+
+ - Later, when the next normal syslog output is generated, it
+ will first empty the content of the interrupt buffer to the
+ SYSLOG device in the proper context. It will then be
+ followed by the normal syslog output. In this case, the
+ interrupt level SYSLOG output will interrupt the normal
+ output stream and the interrupt level SYSLOG output will be
+ inserted into the correct position in the SYSLOG output when
+ the next normal SYSLOG output is generated.
+
+The SYSLOG interrupt buffer is enabled with
+``CONFIG_SYSLOG_INTBUFFER``. When the interrupt buffer is
+enabled, you must also provide the size of the interrupt buffer
+with ``CONFIG_SYSLOG_INTBUFSIZE``.
+
+SYSLOG Channel Options
+======================
+
+SYSLOG Console Device
+---------------------
+
+The typical SYSLOG device is the system console. If you are using
+a serial console, for example, then the SYSLOG output will appear
+on that serial port.
+
+This SYSLOG channel is automatically selected by
+``syslog_initialize()`` in the LATE initialization phase based on
+configuration options. The configuration options that affect this
+channel selection include:
+
+ - ``CONFIG_DEV_CONSOLE``. This setting indicates that the system
+ supports a console device, i.e., that the character device
+ ``/dev/console`` exists.
+
+ - ``CONFIG_SERIAL_CONSOLE``. This configuration option is
+ automatically selected when a UART or USART is configured as
+ the system console. There is no user selection.
+
+ - ``CONFIG_SYSLOG_CONSOLE``. This configuration option is
+ manually selected from the SYSLOG menu. This is the option that
+ actually enables the SYSLOG console device. It depends on
+ ``CONFIG_DEV_CONSOLE``.
+
+ - ``CONFIG_ARCH_LOWPUTC``. This is an indication from the
+ architecture configuration that the platform supports the
+ ``up_putc()`` interface. ``up_putc()`` is a very low level UART
+ interface that can even be used from interrupt handling.
+
+Interrupt level SYSLOG output will be lost unless: (1) the
+interrupt buffer is enabled to support serialization, or (2) a
+serial console is used and ``up_putc()`` is supported.
+
+.. note::
+ The console channel uses the fixed character device at
+ ``/dev/console``. The console channel is not synonymous with
+ ``stdout`` (or file descriptor 1). ``stdout`` is the current
+ output from a task when, say, ``printf()`` if used. Initially,
+ ``stdout`` does, indeed, use the ``/dev/console`` device. However,
+ ``stdout`` may subsequently be redirected to some other device or
+ file. This is always the case, for example, when a transient
+ device is used for a console -- such as a USB console or a Telnet
+ console. The SYSLOG channel is not redirected as ``stdout`` is;
+ the SYSLOG channel will stayed fixed (unless it is explicitly
+ changed via ``syslog_channel()``).
+
+References: ``drivers/syslog/syslog_consolechannel.c`` and
+``drivers/syslog/syslog_device.c``
+
+SYSLOG Character Device
+-----------------------
+
+The system console device, ``/dev/console``, is a character driver
+with some special properties. However, any character driver may be
+used as the SYSLOG output channel. For example, suppose you have a
+serial console on ``/dev/ttyS0`` and you want SYSLOG output on
+``/dev/ttyS1``. Or suppose you support only a Telnet console but
+want to capture debug output ``/dev/ttyS0``.
+
+This SYSLOG device channel is selected with ``CONFIG_SYSLOG_CHAR``
+and has no other dependencies. Differences from the SYSLOG console
+channel include:
+
+ - ``CONFIG_SYSLOG_DEVPATH``. This configuration option string
+ must be set provide the full path to the character device to be
+ used.
+
+ - The forced SYSLOG output always goes to the bit-bucket. This
+ means that interrupt level SYSLOG output will be lost unless
+ the interrupt buffer is enabled to support serialization.
+
+ - ``CONFIG_SYSLOG_CHAR_CRLF``. If ``CONFIG_SYSLOG_CHAR_CRLF`` is
+ selected, then linefeeds in the SYSLOG output will be expanded
+ to Carriage Return plus Linefeed. Since the character device is
+ not a console device, the addition of carriage returns to line
+ feeds would not be performed otherwise. You would probably want
+ this expansion if you use a serial terminal program with the
+ character device output.
+
+References: ``drivers/syslog/syslog_devchannel.c`` and
+``drivers/syslog/syslog_device.c``
+
+SYSLOG File Device
+------------------
+
+Files can also be used as the sink for SYSLOG output. There is,
+however, a very fundamental difference in using a file as opposed
+the system console, a RAM buffer, or character device: You must
+first mount the file system that supports the SYSLOG file. That
+difference means that the file SYSLOG channel cannot be supported
+during the boot-up phase but can be instantiated later when board
+level logic configures the application environment, including
+mounting of the file systems.
+
+The interface ``syslog_file_channel()`` is used to configure the
+SYSLOG file channel:
+
+.. c:function:: int syslog_file_channel(FAR const char *devpath);
+
+ Configure to use a file in a mounted file system
+ at ``devpath`` as the SYSLOG channel.
+
+ This tiny function is simply a wrapper around
+ ``syslog_dev_initialize()`` and ``syslog_channel()``. It calls
+ ``syslog_dev_initialize()`` to configure the character file at
+ ``devpath`` then calls ``syslog_channel()`` to use that device as
+ the SYSLOG output channel.
+
+ File SYSLOG channels differ from other SYSLOG channels in that
+ they cannot be established until after fully booting and mounting
+ the target file system. This function would need to be called from
+ board-specific bring-up logic AFTER mounting the file system
+ containing ``devpath``.
+
+ SYSLOG data generated prior to calling ``syslog_file_channel()``
+ will, of course, not be included in the file.
+
+ NOTE interrupt level SYSLOG output will be lost in this case
+ unless the interrupt buffer is used.
+
+ :param devpath:
+ The full path to the file to be used for SYSLOG
+ output. This may be an existing file or not. If the file
+ exists, ``syslog_file_channel()`` will append new SYSLOG data
+ to the end of the file. If it does not, then
+ ``syslog_file_channel()`` will create the file.
+
+ :return:
+ Zero (``OK``) is returned on success; a
+ negated ``errno`` value is returned on any failure.
+
+ References: ``drivers/syslog/syslog_filechannel.c``,
+ ``drivers/syslog/syslog_device.c``, and
+ ``include/nuttx/syslog/syslog.h``.
+
+SYSLOG RAMLOG Device
+--------------------
+
+The RAMLOG is a standalone feature that can be used to buffer any
+character data in memory. There are, however, special
+configurations that can be used to configure the RAMLOG as a
+SYSLOG channel. The RAMLOG functionality is described in a more
+general way in the following paragraphs.
+
+RAM Logging Device
+==================
+
+The RAM logging driver is a driver that was intended to support
+debugging output (SYSLOG) when the normal serial output is not
+available. For example, if you are using a Telnet or USB serial
+console, the debug output will get lost -- or worse. For example,
+what if you want to debug the network over Telnet?
+The RAM logging driver can also accept debug output data from
+interrupt handler with no special serialization buffering. As an
+added benefit, the RAM logging driver is much less invasive. Since
+no actual I/O is performed with the debug output is generated, the
+RAM logger tends to be much faster and will interfere much less
+when used with time critical drivers.
+
+The RAM logging driver is similar to a pipe in that it saves the
+debugging output in a circular buffer in RAM. It differs from a
+pipe in numerous details as needed to support logging.
+
+This driver is built when ``CONFIG_RAMLOG`` is defined in the
+NuttX configuration.
+
+``dmesg`` command
+-----------------
+
+When the RAMLOG (with SYSLOG) is enabled, a new NuttShell (NSH)
+command will appear: ``dmesg``. The ``dmesg`` command will dump
+the contents of the circular buffer to the console (and also clear
+the circular buffer).
+
+RAMLOG Configuration options
+----------------------------
+
+- ``CONFIG_RAMLOG``: Enables the RAM logging feature
+
+- ``CONFIG_RAMLOG_SYSLOG``: Use the RAM logging device for the
+ SYSLOG interface. If this feature is enabled, then all debug
+ output will be re-directed to the circular buffer in RAM. This
+ RAM log can be viewed from NSH using the ``dmesg`` command.
+ NOTE: Unlike the limited, generic character driver SYSLOG
+ device, the RAMLOG *can* be used to capture debug output from
+ interrupt level handlers.
+
+- ``CONFIG_RAMLOG_NPOLLWAITERS``: The number of threads than can
+ be waiting for this driver on ``poll()``. Default: 4
+
+- ``CONFIG_RAMLOG_BUFSIZE``: The size of the circular buffer to
+ use. Default: 1024 bytes.
+
+Other miscellaneous settings
+
+- ``CONFIG_RAMLOG_CRLF``: Pre-pend a carriage return before every
+ linefeed that goes into the RAM log.
+
+- ``CONFIG_RAMLOG_NONBLOCKING``: Reading from the RAMLOG will
+ never block if the RAMLOG is empty. If the RAMLOG is empty,
+ then zero is returned (usually interpreted as end-of-file). If
+ you do not define this, the NSH ``dmesg`` command will lock up
+ when called! So you probably do want this!
+
+- ``CONFIG_RAMLOG_NPOLLWAITERS``: The maximum number of threads
+ that may be waiting on the poll method.
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/usbdev.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/usbdev.rst.txt
new file mode 100644
index 0000000..589a60b
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/usbdev.rst.txt
@@ -0,0 +1,50 @@
+=======================
+USB Device-Side Drivers
+=======================
+
+- ``include/nuttx/usb/usbdev.h``. All structures and APIs
+ needed to work with USB device-side drivers are provided in
+ this header file.
+
+- ``include/nuttx/usb/usbdev_trace.h``. Declarations needed
+ to work with the NuttX USB device driver trace capability. That
+ USB trace capability is detailed in :ref:`separate
+ document <usbtrace>`.
+
+- ``struct usbdev_s``. Each USB device controller driver must
+ implement an instance of ``struct usbdev_s``. This structure is
+ defined in ``include/nuttx/usb/usbdev.h``.
+
+ **Examples**: ``arch/arm/src/dm320/dm320_usbdev.c``,
+ ``arch/arm/src/lpc17xx_40xx/lpc17_40_usbdev.c``,
+ ``arch/arm/src/lpc214x/lpc214x_usbdev.c``,
+ ``arch/arm/src/lpc313x/lpc313x_usbdev.c``, and
+ ``arch/arm/src/stm32/stm32_usbdev.c``.
+
+- ``struct usbdevclass_driver_s``. Each USB device class
+ driver must implement an instance of
+ ``struct usbdevclass_driver_s``. This structure is also defined
+ in ``include/nuttx/usb/usbdev.h``.
+
+ **Examples**: ``drivers/usbdev/pl2303.c`` and
+ ``drivers/usbdev/usbmsc.c``
+
+- **Binding USB Device-Side Drivers**. USB device-side controller
+ drivers are not normally directly accessed by user code, but
+ are usually bound to another, higher level USB device class
+ driver. The class driver is then configured to export the USB
+ device functionality. In general, the binding sequence is:
+
+ #. Each USB device class driver includes an initialization
+ entry point that is called from the application at
+ initialization time.
+
+ **Examples**: The function ``usbdev_serialinitialize()`` in
+ the file ``drivers/usbdev/pl2303.c`` and the function
+ in the file ``drivers/usbdev/usbmsc.c``
+
+ #. These initialization functions called the driver API,
+ ``usbdev_register()``. This driver function will *bind* the
+ USB class driver to the USB device controller driver,
+ completing the initialization.
+
diff --git a/content/docs/10.1.0/_sources/components/drivers/special/usbhost.rst.txt b/content/docs/10.1.0/_sources/components/drivers/special/usbhost.rst.txt
new file mode 100644
index 0000000..7c91c1d
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/drivers/special/usbhost.rst.txt
@@ -0,0 +1,108 @@
+=====================
+USB Host-Side Drivers
+=====================
+
+- ``include/nuttx/usb/usbhost.h``. All structures and APIs
+ needed to work with USB host-side drivers are provided in this
+ header file.
+
+- ``struct usbhost_driver_s`` and
+ ``struct usbhost_connection_s``. Each USB host controller
+ driver must implement an instance of
+ ``struct usbhost_driver_s`` and
+ ``struct usbhost_connection_s``: ``struct usbhost_driver_s``
+ provides the interface between the USB host driver and the USB
+ class driver; ``struct usbhost_connection_s`` provides the
+ interface between the USB host driver and platform-specific
+ connection management and device enumeration logic. These
+ structures are defined in ``include/nuttx/usb/usbhost.h``.
+
+ **Examples**: ``arch/arm/src/lpc17xx_40xx/lpc17_40_usbhost.c``,
+ ``arch/arm/src/stm32/stm32_otgfshost.c``,
+ ``arch/arm/src/sama5/sam_ohci.c``, and
+ ``arch/arm/src/sama5/sam_ehci.c``.
+
+- ``struct usbhost_class_s``. Each USB host class driver must
+ implement an instance of ``struct usbhost_class_s``. This
+ structure is also defined in ``include/nuttx/usb/usbhost.h``.
+
+ **Examples**: ``drivers/usbhost/usbhost_storage.c``
+
+- **USB Host Class Driver Registry**. The NuttX USB host
+ infrastructure includes a *registry*. During its
+ initialization, each USB host class driver must call the
+ interface, ``usbhost_registerclass()`` in order add its
+ interface to the registry. Later, when a USB device is
+ connected, the USB host controller will look up the USB host
+ class driver that is needed to support the connected device in
+ this registry.
+
+ **Examples**: ``drivers/usbhost/usbhost_registry.c``,
+ ``drivers/usbhost/usbhost_registerclass.c``, and
+ ``drivers/usbhost/usbhost_findclass.c``,
+
+- **Detection and Enumeration of Connected Devices**. Each USB
+ host device controller supports two methods that are used to
+ detect and enumeration newly connected devices (and also detect
+ disconnected devices):
+
+ - ``int (*wait)(FAR struct usbhost_connection_s *drvr, FAR const bool *connected);``
+
+ Wait for a device to be connected or disconnected.
+
+ - ``int (*enumerate)(FAR struct usbhost_connection_s *drvr, int rhpndx);``
+
+ Enumerate the device connected to a root hub port. As part
+ of this enumeration process, the driver will (1) get the
+ device's configuration descriptor, (2) extract the class ID
+ info from the configuration descriptor, (3) call
+ ``usbhost_findclass(``) to find the class that supports this
+ device, (4) call the ``create()`` method on the
+ ``struct usbhost_registry_s interface`` to get a class
+ instance, and finally (5) call the ``connect()`` method of
+ the ``struct usbhost_class_s`` interface. After that, the
+ class is in charge of the sequence of operations.
+
+- **Binding USB Host-Side Drivers**. USB host-side controller
+ drivers are not normally directly accessed by user code, but
+ are usually bound to another, higher level USB host class
+ driver. The class driver exports the standard NuttX device
+ interface so that the connected USB device can be accessed just
+ as with other, similar, on-board devices. For example, the USB
+ host mass storage class driver
+ (``drivers/usbhost/usbhost_storage.c``) will register a
+ standard, NuttX block driver interface (like ``/dev/sda``) that
+ can be used to mount a file system just as with any other other
+ block driver instance. In general, the binding sequence is:
+
+ #. Each USB host class driver includes an initialization entry
+ point that is called from the application at initialization
+ time. This driver calls ``usbhost_registerclass()`` during
+ this initialization in order to makes itself available in
+ the event the device that it supports is connected.
+
+ **Examples**: The function ``usbhost_msc_initialize()`` in
+ the file ``drivers/usbhost/usbhost_storage.c``
+
+ #. Each application must include a *waiter* thread thread that
+ (1) calls the USB host controller driver's ``wait()`` to
+ detect the connection of a device, and then (2) call the USB
+ host controller driver's ``enumerate`` method to bind the
+ registered USB host class driver to the USB host controller
+ driver.
+
+ **Examples**: The function ``nsh_waiter()`` in the file
+ ``boards/arm/lpc17xx_40xx/olimex-lpc1766stk/src/lpc17_40_appinit.c``.
+
+ #. As part of its operation during the binding operation, the
+ USB host class driver will register an instances of a
+ standard NuttX driver under the ``/dev`` directory. To
+ repeat the above example, the USB host mass storage class
+ driver (``drivers/usbhost/usbhost_storage.c``) will register
+ a standard, NuttX block driver interface (like ``/dev/sda``)
+ that can be used to mount a file system just as with any
+ other other block driver instance.
+
+ **Examples**: See the call to ``register_blockdriver()`` in
+ the function ``usbhost_initvolume()`` in the file
+ ``drivers/usbhost/usbhost_storage.c``.
diff --git a/content/docs/10.1.0/_sources/components/filesystem.rst.txt b/content/docs/10.1.0/_sources/components/filesystem.rst.txt
new file mode 100644
index 0000000..5794dc3
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/filesystem.rst.txt
@@ -0,0 +1,43 @@
+=================
+NuttX File System
+=================
+
+**Overview**. NuttX includes an optional, scalable file system.
+This file-system may be omitted altogether; NuttX does not depend
+on the presence of any file system.
+
+**Pseudo Root File System**. A simple *in-memory*, *pseudo* file
+system can be enabled by default. This is an *in-memory* file
+system because it does not require any storage medium or block
+driver support. Rather, file system contents are generated
+on-the-fly as referenced via standard file system operations
+(open, close, read, write, etc.). In this sense, the file system
+is *pseudo* file system (in the same sense that the Linux
+``/proc`` file system is also referred to as a pseudo file
+system).
+
+Any user supplied data or logic can be accessed via the
+pseudo-file system. Built in support is provided for character and
+block `drivers <#DeviceDrivers>`__ in the ``/dev`` pseudo file
+system directory.
+
+**Mounted File Systems** The simple in-memory file system can be
+extended my mounting block devices that provide access to true
+file systems backed up via some mass storage device. NuttX
+supports the standard ``mount()`` command that allows a block
+driver to be bound to a mountpoint within the pseudo file system
+and to a file system. At present, NuttX supports the standard VFAT
+and ROMFS file systems, a special, wear-leveling NuttX FLASH File
+System (NXFFS), as well as a Network File System client (NFS
+version 3, UDP).
+
+**Comparison to Linux** From a programming perspective, the NuttX
+file system appears very similar to a Linux file system. However,
+there is a fundamental difference: The NuttX root file system is a
+pseudo file system and true file systems may be mounted in the
+pseudo file system. In the typical Linux installation by
+comparison, the Linux root file system is a true file system and
+pseudo file systems may be mounted in the true, root file system.
+The approach selected by NuttX is intended to support greater
+scalability from the very tiny platform to the moderate platform.
+
diff --git a/content/docs/10.1.0/_sources/components/index.rst.txt b/content/docs/10.1.0/_sources/components/index.rst.txt
new file mode 100644
index 0000000..4274601
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/index.rst.txt
@@ -0,0 +1,17 @@
+OS Components
+=============
+
+NuttX is very feature-rich RTOS and is thus composed of various different subsystems. The following sections explain how each of these main RTOS components work and can be used. For detailed documentation on the specific API used in this case, you can head to the :doc:`reference <../reference/index>`.
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Contents:
+
+ power.rst
+ binfmt.rst
+ drivers/index.rst
+ filesystem.rst
+ nxflat.rst
+ nxgraphics/index.rst
+ nxwidgets.rst
+ paging.rst
diff --git a/content/docs/10.1.0/_sources/components/nxflat.rst.txt b/content/docs/10.1.0/_sources/components/nxflat.rst.txt
new file mode 100644
index 0000000..ca1dffd
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/nxflat.rst.txt
@@ -0,0 +1,404 @@
+.. _nxflat:
+
+======
+NXFLAT
+======
+
+Overview
+========
+
+Functionality
+-------------
+
+NXFLAT is a customized and simplified version of binary format
+implemented a few years ago called
+`XFLAT <http://xflat.sourceforge.net/>`__ With the NXFLAT binary format
+you will be able to do the following:
+
+ - Place separately linked programs in a file system, and
+ - Execute those programs by dynamically linking them to the base NuttX
+ code.
+
+This allows you to extend the NuttX base code after it has been written
+into FLASH. One motivation for implementing NXFLAT is support clean CGI
+under an HTTPD server.
+
+This feature is especially attractive when combined with the NuttX ROMFS
+support: ROMFS allows you to execute programs in place (XIP) in flash
+without copying anything other than the .data section to RAM. In fact,
+the initial NXFLAT release only worked on ROMFS. Later extensions also
+support execution NXFLAT binaries from an SRAM copy as well.
+
+This NuttX feature includes:
+
+ - A dynamic loader that is built into the NuttX core (See
+ `GIT <https://github.com/apache/incubator-nuttx/blob/master/binfmt/>`__).
+ - Minor changes to RTOS to support position independent code, and
+ - A linker to bind ELF binaries to produce the NXFLAT binary format
+ (See GIT).
+
+Background
+----------
+
+NXFLAT is derived from `XFLAT <http://xflat.sourceforge.net/>`__. XFLAT
+is a toolchain add that provides full shared library and XIP executable
+support for processors that have no Memory Management Unit
+(MMU:sup:`1`). NXFLAT is greatly simplified for the deeply embedded
+environment targeted by NuttX:
+
+ - NXFLAT does not support shared libraries, because
+ - NXFLAT does not support *exportation* of symbol values from a module
+
+Rather, the NXFLAT module only *imports* symbol values. In the NXFLAT
+model, the (PIC:sup:`2`) NXFLAT module resides in a FLASH file system
+and when it is loaded at run time, it is dynamically linked only to the
+(non-PIC) base NuttX code: The base NuttX *exports* a symbol table; the
+NXFLAT module *imports* those symbol value to dynamically bind the
+module to the base code.
+
+Limitations
+-----------
+
+ - **ROMFS (or RAM mapping) Only**:
+ The current NXFLAT release will work only with either (1) NXFLAT
+ executable modules residing on a ROMFS file system, or (2) executables
+ residing on other file systems provided that CONFIG_FS_RAMMAP is
+ defined. This limitation is because the loader depends on the capability
+ to mmap() the code segment. See the NuttX User Guide for further information.
+
+ NUTTX does not provide any general kind of file mapping capability.
+ In fact, true file mapping is only possible with MCUs that provide an MMU1.
+ Without an MMU, file system may support eXecution In Place (XIP) to mimic
+ file mapping. Only the ROMFS file system supports that kind of XIP execution
+ need by NXFLAT.
+
+ It is also possible to simulate file mapping by allocating memory, copying
+ the NXFLAT binary file into memory, and executing from the copy of the
+ executable file in RAM. That capability can be enabled with the CONFIG_FS_RAMMAP
+ configuration option. With that option enabled, NXFLAT will work that kind
+ of file system but will require copying of all NXFLAT executables to RAM.
+
+ - **GCC/ARM/Cortex-M3/4 Only**:
+ At present, the NXFLAT toolchain is only available for ARM and Cortex-M3/4 (thumb2) targets.
+
+ - **Read-Only Data in RAM**:
+ With older GCC compilers (at least up to 4.3.3), read-only data must
+ reside in RAM. In code generated by GCC, all data references are
+ indexed by the PIC2 base register (that is usually R10 or sl for the
+ ARM processors). The includes read-only data (.rodata). Embedded
+ firmware developers normally like to keep .rodata in FLASH with
+ the code sections. But because all data is referenced with the
+ PIC base register, all of that data must lie in RAM. A NXFLAT
+ change to work around this is under investigation3.
+
+ Newer GCC compilers (at least from 4.6.3), read-only data is
+ no long GOT-relative, but is now accessed PC-relative.
+ With PC relative addressing, read-only data must reside in the I-Space.
+
+ - **Globally Scoped Function Function Pointers**:
+ If a function pointer is taken to a statically defined function,
+ then (at least for ARM) GCC will generate a relocation that NXFLAT
+ cannot handle. The workaround is make all such functions global in
+ scope. A fix would involve a change to the GCC compiler as described
+ in Appendix B.
+
+ - **Special Handling of Callbacks**:
+ Callbacks through function pointers must be avoided or, when
+ then cannot be avoided, handled very specially. The reason
+ for this is that the PIC module requires setting of a special
+ value in a PIC register. If the callback does not set the PIC
+ register, then the called back function will fail because it
+ will be unable to correctly access data memory. Special logic
+ is in place to handle some NuttX callbacks: Signal callbacks
+ and watchdog timer callbacks. But other callbacks (like those
+ used with qsort() must be avoided in an NXFLAT module.
+
+Supported Processors
+--------------------
+
+As mentioned `above <#limitations>`__, the NXFLAT toolchain is only
+available for ARM and Cortex-M3 (thumb2) targets. Furthermore, NXFLAT
+has only been tested on the Eagle-100 LMS6918 Cortex-M3 board.
+
+Development Status
+------------------
+
+The initial release of NXFLAT was made in NuttX version 0.4.9. Testing
+is limited to the tests found under ``apps/examples/nxflat`` in the
+source tree. Some known problems exist (see the
+`TODO <https://github.com/apache/incubator-nuttx/blob/master/TODO>`__ list). As
+such, NXFLAT is currently in an early alpha phase.
+
+NXFLAT Toolchain
+================
+
+Building the NXFLAT Toolchain
+-----------------------------
+
+In order to use NXFLAT, you must use special NXFLAT tools to create the
+binary module in FLASH. To do this, you will need to download the
+buildroot package and build it on your Linux or Cygwin machine. The
+buildroot can be downloaded from
+`Bitbucket.org <https://bitbucket.org/nuttx/buildroot/downloads>`__. You
+will need version 0.1.7 or later.
+
+Here are some general build instructions:
+
+- You must have already configured NuttX in ``<some-dir>/nuttx``
+- Download the buildroot package ``buildroot-0.x.y`` into
+ ``<some-dir>``
+- Unpack ``<some-dir>/buildroot-0.x.y.tar.gz`` using a command like ``tar zxf buildroot-0.x.y``. This will result in a new directory like ``<some-dir>/buildroot-0.x.y``
+- Move this into position:
+ ``mv <some-dir>/buildroot-0.x.y``\ <some-dir>/buildroot
+- ``cd``\ <some-dir>/buildroot
+- Copy a configuration file into the top buildroot directory:
+ ``cp boards/abc-defconfig-x.y.z .config``.
+- Enable building of the NXFLAT tools by ``make menuconfig``. Select to
+ build the NXFLAT toolchain with GCC (you can also select omit
+ building GCC with and only build the NXFLAT toolchain for use with
+ your own GCC toolchain).
+- Make the toolchain: ``make``. When the make completes, the tool
+ binaries will be available under
+ ``<some-dir>/buildroot/build_abc/staging_dir/bin``
+
+mknxflat
+--------
+
+``mknxflat`` is used to build a *thunk* file. See below
+for usage::
+
+ Usage: mknxflat [options] <bfd-filename>
+
+ Where options are one or more of the following. Note
+ that a space is always required between the option and
+ any following arguments.
+
+ -d Use dynamic symbol table. [symtab]
+ -f <cmd-filename>
+ Take next commands from <cmd-filename> [cmd-line]
+ -o <out-filename>
+ Output to [stdout]
+ -v Verbose output [no output]
+ -w Import weakly declared functions, i.e., weakly
+ declared functions are expected to be provided at
+ load-time [not imported]
+
+ldnxflat
+--------
+
+``ldnxflat`` is use to link your object files along with the *thunk*
+file generated by ``mknxflat`` to produce the NXFLAT
+binary module. See below for usage::
+
+ Usage: ldnxflat [options] <bfd-filename>
+
+ Where options are one or more of the following. Note
+ that a space is always required between the option and
+ any following arguments.
+
+ -d Use dynamic symbol table [Default: symtab]
+ -e <entry-point>
+ Entry point to module [Default: _start]
+ -o <out-filename>
+ Output to <out-filename> [Default: <bfd-filename>.nxf]
+ -s <stack-size>
+ Set stack size to <stack-size> [Default: 4096]
+ -v Verbose output. If -v is applied twice, additional
+ debug output is enabled [Default: no verbose output].
+
+mksymtab
+--------
+
+There is a small helper program available in ``nuttx/tools`` call
+``mksymtab``. ``mksymtab`` can be sued to generate symbol tables for the
+NuttX base code that would be usable by the typical NXFLAT application.
+``mksymtab`` builds symbol tables from common-separated value (CSV)
+files. In particular, the CSV files:
+
+ #. ``nuttx/syscall/syscall.csv`` that describes the NuttX RTOS
+ interface, and
+ #. ``nuttx/libc/libc.csv`` that describes the NuttX C library interface.
+ #. ``nuttx/libc/math.cvs`` that descirbes any math library.
+
+::
+
+ USAGE: ./mksymtab <cvs-file> <symtab-file>
+
+ Where:
+
+ <cvs-file> : The path to the input CSV file
+ <symtab-file>: The path to the output symbol table file
+ -d : Enable debug output
+
+For example,
+
+::
+
+ cd nuttx/tools
+ cat ../syscall/syscall.csv ../libc/libc.csv | sort >tmp.csv
+ ./mksymtab.exe tmp.csv tmp.c
+
+Making an NXFLAT module
+-----------------------
+
+Below is a snippet from an NXFLAT make file (simplified from NuttX
+`Hello,
+World! <https://github.com/apache/incubator-nuttx-apps/blob/master/examples/nxflat/tests/hello/Makefile>`__
+example).
+
+* Target 1:
+
+ .. code-block:: makefile
+
+ hello.r1: hello.o
+ abc-nuttx-elf-ld -r -d -warn-common -o $@ $^
+
+* Target 2:
+
+ .. code-block:: makefile
+
+ hello-thunk.S: hello.r1
+ mknxflat -o $@ $^
+
+* Target 3:
+
+ .. code-block:: makefile
+
+ hello.r2: hello-thunk.S
+ abc-nuttx-elf-ld -r -d -warn-common -T binfmt/libnxflat/gnu-nxflat-gotoff.ld -no-check-sections -o $@ hello.o hello-thunk.o
+
+* Target 4:
+
+ .. code-block:: makefile
+
+ hello: hello.r2
+ ldnxflat -e main -s 2048 -o $@ $^
+
+**Target 1**. This target links all of the module's object files
+together into one relocatable object. Two relocatable objects will be
+generated; this is the first one (hence, the suffic ``.r1``). In this
+"Hello, World!" case, there is only a single object file, ``hello.o``,
+that is linked to produce the ``hello.r1`` object.
+
+When the module's object files are compiled, some special compiler
+CFLAGS must be provided. First, the option ``-fpic`` is required to tell
+the compiler to generate position independent code (other GCC options,
+like ``-fno-jump-tables`` might also be desirable). For ARM compilers,
+two additional compilation options are required: ``-msingle-pic-base``
+and ``-mpic-register=r10``.
+
+**Target 2**. Given the ``hello.r1`` relocatable object, this target
+will invoke ```mknxflat`` <#mknxflat>`__ to make the *thunk* file,
+``hello-thunk.S``. This *thunk* file contains all of the information
+needed to create the imported function list.
+
+**Target 3** This target is similar to **Target 1**. In this case, it
+will link together the module's object files (only ``hello.o`` here)
+along with the assembled *thunk* file, ``hello-thunk.o`` to create the
+second relocatable object, ``hello.r2``. The linker script,
+``gnu-nxflat-gotoff.ld`` is required at this point to correctly position
+the sections. This linker script produces two segments: An *I-Space*
+(Instruction Space) segment containing mostly ``.text`` and a *D-Space*
+(Data Space) segment containing ``.got``, ``.data``, and ``.bss``
+sections. The I-Space section must be origined at address 0 (so that the
+segment's addresses are really offsets into the I-Space segment) and the
+D-Space section must also be origined at address 0 (so that segment's
+addresses are really offsets into the I-Space segment). The option
+``-no-check-sections`` is required to prevent the linker from failing
+because these segments overlap.
+
+**NOTE:** There are two linker scripts located at ``binfmt/libnxflat/``.
+
+ #. ``binfmt/libnxflat/gnu-nxflat-gotoff.ld``. Older versions of GCC
+ (at least up to GCC 4.3.3), use GOT-relative addressing to access RO
+ data. In that case, read-only data (.rodata) must reside in D-Space
+ and this linker script should be used.
+ #. ``binfmt/libnxflat/gnu-nxflat-pcrel.ld``. Newer versions of GCC
+ (at least as of GCC 4.6.3), use PC-relative addressing to access RO
+ data. In that case, read-only data (.rodata) must reside in I-Space
+ and this linker script should be used.
+
+**Target 4**. Finally, this target will use the ``hello.r2`` relocatable
+object to create the final, NXFLAT module ``hello`` by executing
+``ldnxflat``.
+
+**binfmt Registration** NXFLAT calls :c:func:`register_binfmt` to
+incorporate itself into the system.
+
+Appendix A: No GOT Operation
+============================
+
+When GCC generate position independent code, new code sections will
+appear in your programs. One of these is the GOT (Global Offset Table)
+and, in ELF environments, another is the PLT (Procedure Lookup Table.
+For example, if your C code generated (ARM) assembly language like this
+without PIC:
+
+.. code-block:: asm
+
+ ldr r1, .L0 /* Fetch the offset to 'x' */
+ ldr r0, [r10, r1] /* Load the value of 'x' with PIC offset */
+ /* ... */
+ .L0: .word x /* Offset to 'x' */
+
+Then when PIC is enabled (say with the -fpic compiler option), it will
+generate code like this:
+
+.. code-block:: asm
+
+ ldr r1, .L0 /* Fetch the offset to the GOT entry */
+ ldr r1, [r10, r1] /* Fetch the (relocated) address of 'x' from the GOT */
+ ldr r0, [r1, #0] /* Fetch the value of 'x' */
+ /* ... */
+ .L1 .word x(GOT) /* Offset to entry in the GOT */
+
+See
+`reference <http://xflat.sourceforge.net/NoMMUSharedLibs.html#shlibsgot>`__
+
+Notice that the generates an extra level of indirection through the GOT.
+This indirection is not needed by NXFLAT and only adds more RAM usage
+and execution time.
+
+NXFLAT (like `XFLAT <http://xflat.sourceforge.net/>`__) can work even
+better without the GOT. Patches against older version of GCC exist to
+eliminate the GOT indirections. Several are available
+`here <http://xflat.cvs.sourceforge.net/viewvc/xflat/xflat/gcc/>`__ if
+you are inspired to port them to a new GCC version.
+
+Appendix B: PIC Text Workaround
+===============================
+
+There is a problem with the memory model in GCC that prevents it from
+being used as you need to use it in the NXFLAT context. The problem is
+that GCC PIC model assumes that the executable lies in a flat,
+contiguous (virtual) address space like::
+
+ Virtual
+ .text
+ .got
+ .data
+ .bss
+
+It assumes that the PIC base register (usually r10 for ARM) points to
+the base of ``.text`` so that any address in ``.text``, ``.got``,
+``.data``, ``.bss`` can be found with an offset from the same base
+address. But that is not the memory arrangement that we need in the XIP
+embedded environment. We need two memory regions, one in FLASH
+containing shared code and on per task in RAM containing task-specific
+data::
+
+ Flash RAM
+ .text .got
+ .data
+ .bss
+
+The PIC base register needs to point to the base of the ``.got`` and
+only addresses in the ``.got``, ``.data``, and ``.bss`` sections can be
+accessed as an offset from the PIC base register. See also this `XFLAT
+discussion <http://xflat.cvs.sourceforge.net/viewvc/*checkout*/xflat/xflat/gcc/README?revision=1.1.1.1>`__.
+
+Patches against older version of GCC exist to correct this GCC behavior.
+Several are available
+`here <http://xflat.cvs.sourceforge.net/viewvc/xflat/xflat/gcc/>`__ if
+you are inspired to port them to a new GCC version.
+
diff --git a/content/docs/10.1.0/_sources/components/nxgraphics/appendix.rst.txt b/content/docs/10.1.0/_sources/components/nxgraphics/appendix.rst.txt
new file mode 100644
index 0000000..ec0e4b8
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/nxgraphics/appendix.rst.txt
@@ -0,0 +1,647 @@
+========
+Appendix
+========
+
+``graphics/`` Directory Structure
+=================================
+
+The graphics capability consist both of components internal to the RTOS
+and of user-callable interfaces. In the NuttX kernel mode build there
+are some components of the graphics subsystem are callable in user mode
+and other components that are internal to the RTOS. The directory
+``nuttx/graphics`` contains only those components that are internal to
+the RTOS. User callable functions must be part of a library that can be
+linked against user applications. This user callable interfaces are
+provided in sub-directories under ``nuttx/libnx``.
+
+``libnx/nx``
+ Common callable interfaces that are, logically, part of both nxmu and
+ nxsu.
+``graphics/nxglib`` and ``libnx/nxglib``
+ The NuttX tiny graphics library. The directory contains generic
+ utilities support operations on primitive graphics objects and logic
+ to rasterize directly into a framebuffer or through an LCD driver
+ interface. It has no concept of windows (other than the one,
+ framebuffer or LCD window).
+``graphics/nxbe``
+ This is the *back-end* of a tiny windowing system. It can be used
+ with either of two front-ends to complete a windowing system (see
+ ``nxmu`` and ``nxsu`` below). It contains most of the important
+ window management logic: clipping, window controls, window drawing,
+ etc.
+``graphics/nxmu`` and ``libnx/nxmu``
+ This is the NX multi user *front end*. When combined with the generic
+ *back-end* (``nxbe``), it implements a multi-threaded, multi-user
+ windowing system. The files in this directory present the window APIs
+ described in ``include/nuttx/nx/nx.h``. The multi-user front end
+ includes a graphics server that executes on its own thread; multiple
+ graphics clients then communicate with the server via a POSIX message
+ queue to serialize window operations from many threads.
+``libnx/nxfonts``
+ This is where the NXFONTS implementation resides. This is a
+ relatively low-level set of charset set/glyph management APIs. See
+ ``include/nuttx/nx/nxfonts.h``.
+``libnx/nxtk``
+ This is where the NXTOOLKIT implementation resides. This toolkit is
+ built on top of NX and works with the multi-user NX front-end. See
+ ``include/nuttx/nx/nxtk.h``.
+``apps/graphics/NxWidgets``
+ The :ref:`NxWidgets <nxwidgets>` code is provided as a separate
+ package provided in the ``apps/`` repository.
+``graphics/nxterm``
+ The NxTerm driver is built on top of NX and works with the multi-user
+ NX front-end. See ``include/nuttx/nx/nxterm.h``.
+
+NX Configuration Options
+========================
+
+General Configuration Settings
+------------------------------
+
+``CONFIG_NX``
+ Enables overall support for graphics library and NX
+``CONFIG_NX_RAMBACKED``
+ Enables RAM backed window support. If this option is selected, then
+ windows may be optionally created with a RAM framebuffer backing up
+ the window content. Rending into the window will result in rending
+ into the backup framebuffer, then updating the physical display from
+ the framebuffer.
+
+ The advantage of this option is that the application that manages
+ window will no longer receive redraw() callbacks. Those calls
+ normally occur, for example, when a window "above" moves exposing a
+ portion of the window below. If this option is selected, then the
+ system will redraw the exposed portion of the window from the backup
+ framebuffer without intervention of the window applications. This
+ greatly reduces the complexity of the application and performance of
+ the window at the expense of increased memory usage.
+
+ An exception is the case when the window is resized to a wider and/or
+ taller size. In that case, the redraw callback will till occur. It is
+ necessary in that case to provide new graphic content for the
+ extended window area.
+
+ Redraw requests in other cases are also suppressed: Changes to window
+ position, size, etc.
+
+NXGL Configuration Settings
+---------------------------
+
+``CONFIG_NX_NPLANES``:
+ Some YUV color formats requires support for multiple planes, one for
+ each color component. Unless you have such special hardware, this
+ value should be undefined or set to 1.
+``CONFIG_NX_DISABLE_1BPP``, ``CONFIG_NX_DISABLE_2BPP``, ``CONFIG_NX_DISABLE_4BPP``, ``CONFIG_NX_DISABLE_8BPP`` ``CONFIG_NX_DISABLE_16BPP``, ``CONFIG_NX_DISABLE_24BPP``, and ``CONFIG_NX_DISABLE_32BPP``:
+ NX supports a variety of pixel depths. You can save some memory by
+ disabling support for unused color depths.
+``CONFIG_NX_PACKEDMSFIRST``:
+ If a pixel depth of less than 8-bits is used, then NX needs to know
+ if the pixels pack from the MS to LS or from LS to MS
+``CONFIG_NX_LCDDRIVER``:
+ By default, NX builds to use a framebuffer driver (see
+ ``include/nuttx/video/fb.h``). If this option is defined, NX will
+ build to use an LCD driver (see ``include/nuttx/lcd/lcd.h``).
+``CONFIG_NX_ANTIALIASING``:
+ Enable support for anti-aliasing when rendering lines as various
+ orientations. This option is only available for use with frame buffer
+ drivers and only with 16-, 24-, or 32-bit RGB color formats.
+
+Configuration Settings
+----------------------
+
+``CONFIG_NX_XYINPUT``:
+ Build in support for an X/Y input such as a mouse or a touscreen.
+``CONFIG_NX_KBD``:
+ Build in support of keypad/keyboard input.
+``CONFIG_NX_WRITEONLY``:
+ Define if the underlying graphics device does not support read
+ operations. Automatically defined if ``CONFIG_NX_LCDDRIVER`` and
+ ``CONFIG_LCD_NOGETRUN`` are defined.
+
+NX Server Configuration Settings
+--------------------------------
+
+``CONFIG_NX_BLOCKING``
+ Open the client message queues in blocking mode. In this case,
+ ``nx_eventhandler()`` will not return until a message is received and
+ processed.
+``CONFIG_NX_MXSERVERMSGS`` and ``CONFIG_NX_MXCLIENTMSGS``
+ Specifies the maximum number of messages that can fit in the message
+ queues. No additional resources are allocated, but this can be set to
+ prevent flooding of the client or server with too many messages
+ (``CONFIG_PREALLOC_MQ_MSGS`` controls how many messages are
+ pre-allocated).
+
+NXTK Configuration Settings
+---------------------------
+
+``CONFIG_NXTK_BORDERWIDTH``:
+ Specifies the width of the border (in pixels) used with framed
+ windows. The default is 4.
+``CONFIG_NXTK_BORDERCOLOR1``, ``CONFIG_NXTK_BORDERCOLOR2``, and ``CONFIG_NXTK_BORDERCOLOR3``:
+ Specify the colors of the border used with framed windows.
+``CONFIG_NXTK_BORDERCOLOR2``
+ The shadow side color and so is normally darker.
+``CONFIG_NXTK_BORDERCOLOR3``
+ The shiny side color and so is normally brighter. The default is
+ medium, dark, and light grey, respectively
+``CONFIG_NXTK_AUTORAISE``:
+ If set, a window will be raised to the top if the mouse position is
+ over a visible portion of the window. Default: A mouse button must be
+ clicked over a visible portion of the window.
+
+NXFONTS Configuration Settings
+------------------------------
+
+``CONFIG_NXFONTS_CHARBITS``:
+ The number of bits in the character set. Current options are only 7
+ and 8. The default is 7.
+``CONFIG_NXFONT_SANS17X22``:
+ This option enables support for a tiny, 17x22 san serif font (font
+ ``ID FONTID_SANS17X22`` == 14).
+``CONFIG_NXFONT_SANS20X26``:
+ This option enables support for a tiny, 20x26 san serif font (font
+ ``ID FONTID_SANS20X26`` == 15).
+``CONFIG_NXFONT_SANS23X27``:
+ This option enables support for a tiny, 23x27 san serif font (font
+ ``ID FONTID_SANS23X27`` == 1).
+``CONFIG_NXFONT_SANS22X29``:
+ This option enables support for a small, 22x29 san serif font (font
+ ``ID FONTID_SANS22X29`` == 2).
+``CONFIG_NXFONT_SANS28X37``:
+ This option enables support for a medium, 28x37 san serif font (font
+ ``ID FONTID_SANS28X37`` == 3).
+``CONFIG_NXFONT_SANS39X48``:
+ This option enables support for a large, 39x48 san serif font (font
+ ``ID FONTID_SANS39X48`` == 4).
+``CONFIG_NXFONT_SANS17X23B``:
+ This option enables support for a tiny, 17x23 san serif bold font
+ (font ``ID FONTID_SANS17X23B`` == 16).
+``CONFIG_NXFONT_SANS20X27B``:
+ This option enables support for a tiny, 20x27 san serif bold font
+ (font ``ID FONTID_SANS20X27B`` == 17).
+``CONFIG_NXFONT_SANS22X29B``:
+ This option enables support for a small, 22x29 san serif bold font
+ (font ID ``FONTID_SANS22X29B`` == 5).
+``CONFIG_NXFONT_SANS28X37B``:
+ This option enables support for a medium, 28x37 san serif bold font
+ (font ID ``FONTID_SANS28X37B`` == 6).
+``CONFIG_NXFONT_SANS40X49B``:
+ This option enables support for a large, 40x49 san serif bold font
+ (font ID ``FONTID_SANS40X49B`` == 7).
+``CONFIG_NXFONT_SERIF22X29``:
+ This option enables support for a small, 22x29 font (with serifs)
+ (font ID ``FONTID_SERIF22X29`` == 8).
+``CONFIG_NXFONT_SERIF29X37``:
+ This option enables support for a medium, 29x37 font (with serifs)
+ (font ID ``FONTID_SERIF29X37`` == 9).
+``CONFIG_NXFONT_SERIF38X48``:
+ This option enables support for a large, 38x48 font (with serifs)
+ (font ID ``FONTID_SERIF38X48`` == 10).
+``CONFIG_NXFONT_SERIF22X28B``:
+ This option enables support for a small, 27x38 bold font (with
+ serifs) (font ID ``FONTID_SERIF22X28B`` == 11).
+``CONFIG_NXFONT_SERIF27X38B``:
+ This option enables support for a medium, 27x38 bold font (with
+ serifs) (font ID ``FONTID_SERIF27X38B`` == 12).
+``CONFIG_NXFONT_SERIF38X49B``:
+ This option enables support for a large, 38x49 bold font (with
+ serifs) (font ID ``FONTID_SERIF38X49B`` == 13).
+
+NxTerm Configuration Settings
+-----------------------------
+
+General NxTerm settings.
+
+``CONFIG_NXTERM``:
+ Enables building of the NxTerm driver.
+
+NxTerm output text/graphics options:
+
+``CONFIG_NXTERM_BPP``:
+ Currently, NxTerm supports only a single pixel depth. This
+ configuration setting must be provided to support that single pixel
+ depth. Default: The smallest enabled pixel depth. (see
+ ``CONFIG_NX_DISABLE_*BPP``)
+``CONFIG_NXTERM_CURSORCHAR``:
+ The bitmap code to use as the cursor. Default '_'
+``CONFIG_NXTERM_MXCHARS``:
+ NxTerm needs to remember every character written to the console so
+ that it can redraw the window. This setting determines the size of
+ some internal memory allocations used to hold the character data.
+ Default: 128.
+``CONFIG_NXTERM_CACHESIZE``:
+ NxTerm supports caching of rendered fonts. This font caching is
+ required for two reasons: (1) First, it improves text performance,
+ but more importantly (2) it preserves the font memory. Since the NX
+ server runs on a separate server thread, it requires that the
+ rendered font memory persist until the server has a chance to render
+ the font. Unfortunately, the font cache would be quite large if all
+ fonts were saved. The ``CONFIG_NXTERM_CACHESIZE`` setting will
+ control the size of the font cache (in number of glyphs). Only that
+ number of the most recently used glyphs will be retained. Default:
+ 16.
+
+ NOTE: There can still be a race condition between the NxTerm
+ driver and the NX task. If you every see character corruption
+ (especially when printing a lot of data or scrolling), then
+ increasing the value of ``CONFIG_NXTERM_CACHESIZE`` is something
+ that you should try. Alternatively, you can reduce the size of
+ ``CONFIG_MQ_MAXMSGSIZE`` which will force NxTerm task to pace the
+ server task. ``CONFIG_NXTERM_CACHESIZE`` should be larger than
+ ``CONFIG_MQ_MAXMSGSIZE`` in any event.
+
+``CONFIG_NXTERM_LINESEPARATION``:
+ This the space (in rows) between each row of test. Default: 0
+``CONFIG_NXTERM_NOWRAP``:
+ By default, lines will wrap when the test reaches the right hand side
+ of the window. This setting can be defining to change this behavior
+ so that the text is simply truncated until a new line is encountered.
+
+NxTerm input options:
+
+``CONFIG_NXTERM_NXKBDIN``:
+ Take input from the NX keyboard input callback. By default, keyboard
+ input is taken from stdin (``/dev/console``). If this option is set,
+ then the interface\ ``nxterm_kdbin()`` is enabled. That interface may
+ be driven by window callback functions so that keyboard input *only*
+ goes to the top window.
+``CONFIG_NXTERM_KBDBUFSIZE``:
+ If ``CONFIG_NXTERM_NXKBDIN`` is enabled, then this value may be used
+ to define the size of the per-window keyboard input buffer. Default:
+ 16
+``CONFIG_NXTERM_NPOLLWAITERS``:
+ The number of threads that can be waiting for read data available.
+ Default: 4
+
+Installing New Fonts
+====================
+
+**The BDF Font Converter**. There is a tool called *bdf-converter* in
+the directory ``tools/.``. The *bdf-converter* program be used to
+convert fonts in Bitmap Distribution Format (BDF) into fonts that can be
+used in the NX graphics system. The BDF format most well known as a font
+format traditionally used for X-11 bitmap fonts.
+
+ A Note about Font Copyrights: My understanding is that the underlying
+ bitmap font data for traditional fonts cannot be copyrighted (the
+ same is not true for scalable fonts). This is because a copyright
+ covers only the form of delivery of the font and not the underlying
+ font content and, at least for the traditional typefaces, the
+ underlying font designs are ancient. There could be issues, however,
+ if you convert from modern, trademarked images. However, remember
+ that I am a programmer not an attorney and that my knowledge of font
+ copyright issues is limited to what I glean by Googling.
+
+**Font Installation Steps**, Below are general instructions for creating
+and installing a new font in the NX graphic system. The first two steps
+only apply if you are using the BDF font converter program.
+
+#. Locate a font in BDF format. There are many good BDF bitmap fonts
+ bundled with X-11. See `this
+ link <http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html>`__, as an
+ example,
+
+#. Use the *bdf-converter* program to convert the BDF font to the NuttX
+ font format. This will result in a C header file containing
+ definitions. That header file should be installed at, for example,
+ ``graphics/nxfonts/nxfonts_myfont.h``.
+
+The remaining steps apply however you managed to create the NuttX C font
+header file. After you have your C font header file, the next thing to
+do is to create a new NuttX configuration variable to select the font.
+For example, suppose you define the following variable:
+``CONFIG_NXFONT_MYFONT``. Then you would need to:
+
+3. Define ``CONFIG_NXFONT_MYFONT=y`` in your NuttX configuration file.
+
+A font ID number has to be assigned for each new font. The font IDs are
+defined in the file ``include/nuttx/nx/nxfonts.h``. Those definitions
+have to be extended to support your new font. Look at how the font ID
+enabled by ``CONFIG_NXFONT_SANS23X27`` is defined and add an ID for
+yournew font in a similar fashion:
+
+4. ``include/nuttx/nx/nxfonts.h``. Add you new font as a possible
+ system default font:
+
+ .. code-block:: c
+
+ #if defined(CONFIG_NXFONT_SANS23X27)
+ # define NXFONT_DEFAULT FONTID_SANS23X27
+ #elif defined(CONFIG_NXFONT_MYFONT)
+ # define NXFONT_DEFAULT FONTID_MYFONT
+ #endif
+
+ Then define the actual font ID. Make sure that the font ID value is
+ unique:
+
+ .. code-block:: c
+
+ #if defined(CONFIG_NXFONT_SANS23X27)
+ # define NXFONT_DEFAULT FONTID_SANS23X27
+ #elif defined(CONFIG_NXFONT_MYFONT)
+ # define NXFONT_DEFAULT FONTID_MYFONT
+ #endif
+
+New Add the font to the NX build system. There are several files that
+you have to modify to do this. Look how the build system uses the font
+CONFIG_NXFONT_SANS23X27 for examaples:
+
+5. ``nuttx/graphics/Makefile``. This file needs logic to
+ auto-generate a C source file from the header file that you generated
+ with the *bdf-converter* program. Notice ``NXFONTS_FONTID=2``; this
+ must be set to the same font ID value that you defined in the
+ ``include/nuttx/nx/nxfonts.h`` file.
+
+ .. code-block:: makefile
+
+ genfontsources:
+ ifeq ($(CONFIG_NXFONT_SANS23X27),y)
+ @$(MAKE) -C nxfonts -f Makefile.sources NXFONTS_FONTID=1 EXTRAFLAGS=$(EXTRAFLAGS)
+ endif
+ ifeq ($(CONFIG_NXFONT_MYFONT),y)
+ @$(MAKE) -C nxfonts -f Makefile.sources NXFONTS_FONTID=2 EXTRAFLAGS=$(EXTRAFLAGS)
+ endif
+
+6. ``nuttx/graphics/nxfonts/Make.defs``. Set the make variable
+ ``NXFSET_CSRCS``. ``NXFSET_CSRCS`` determines the name of the font C
+ file to build when ``NXFONTS_FONTID=2``:
+
+ .. code-block:: makefile
+
+ ifeq ($(CONFIG_NXFONT_SANS23X27),y)
+ NXFSET_CSRCS += nxfonts_bitmaps_sans23x27.c
+ endif
+ ifeq ($(CONFIG_NXFONT_MYFONT),y)
+ NXFSET_CSRCS += nxfonts_bitmaps_myfont.c
+ endif
+
+7. ``nuttx/graphics/nxfonts/Makefile.sources``. This is the Makefile
+ used in step 5 that will actually generate the font C file. So, given
+ your NXFONTS_FONTID=2, it needs to determine a prefix to use for
+ auto-generated variable and function names and (again) the name of
+ the autogenerated file to create (this must be the same name that was
+ used in ``nuttx/graphics/nxfonts/Make.defs``):
+
+ .. code-block:: makefile
+
+ ifeq ($(NXFONTS_FONTID),1)
+ NXFONTS_PREFIX := g_sans23x27_
+ GEN_CSRC = nxfonts_bitmaps_sans23x27.c
+ endif
+ ifeq ($(NXFONTS_FONTID),2)
+ NXFONTS_PREFIX := g_myfont_
+ GEN_CSRC = nxfonts_bitmaps_myfont.c
+ endif
+
+8. ``graphics/nxfonts/nxfonts_bitmaps.c``. This is the file that
+ contains the generic font structures. It is used as a "template&qout;
+ file by ``nuttx/graphics/nxfonts/Makefile.sources``\ to create your
+ customized font data set at build time.
+
+ .. code-block:: c
+
+ #if NXFONTS_FONTID == 1
+ # include "nxfonts_sans23x27.h"
+ #elif NXFONTS_FONTID == 2
+ # include "nxfonts_myfont.h"
+ #else
+ # error "No font ID specified"
+ #endif
+
+ Where ``nxfonts_myfont.h`` is the NuttX font file that we generated
+ in step 2 using the *bdf-converter* tool.
+
+9. ``graphics/nxfonts/nxfonts_getfont.c``. Finally, we need to
+ extend the logic that does the run-time font lookups so that can find
+ our new font. The lookup function is
+ ```NXHANDLE nxf_getfonthandle(enum nx_fontid_e fontid)`` <#nxfgetfonthandle>`__.
+ Note that the lookup is based on the font ID that was defined in step
+ 4. The new font information needs to be added to data structures used
+ by that function:
+
+ .. code-block:: c
+
+ #ifdef CONFIG_NXFONT_SANS23X27
+ extern const struct nx_fontpackage_s g_sans23x27_package;
+ #endif
+ #ifdef CONFIG_NXFONT_MYFONT
+ extern const struct nx_fontpackage_s g_myfont_package;
+ #endif
+
+ static FAR const struct nx_fontpackage_s *g_fontpackages[] =
+ {
+ #ifdef CONFIG_NXFONT_SANS23X27
+ &g_sans23x27_package,
+ #endif
+ #ifdef CONFIG_NXFONT_MYFONT
+ &g_myfont_package,
+ #endif
+ NULL
+ };
+
+
+NX Test Coverage
+================
+
+``apps/examples/nx``. The primary test tool for debugging NX resides
+at ``apps/examples/nx``.
+
+**Building** ``apps/examples/nx``. NX testing was performed using
+``apps/examples/nx`` with the Linux/Cygwin-based NuttX simulator.
+Configuration files for building this test can be found in
+``boards/sim/sim/sim/configs/nx`` and
+``boards/sim/sim/sim/configs/nx11``. There are two alternative
+configurations for building the simulation:
+
+#. The configuration using the configuration file at
+ ``boards/sim/sim/sim/configs/nx/defconfig``. This default
+ configuration exercises the NX logic a 8 BPP but provides no visual
+ feedback. In this configuration, a very simple, simulated framebuffer
+ driver is used that is based upon a simple region of memory posing as
+ video memory. That default configuration can be built as follows::
+
+ tools/configure.sh sim:nx
+ make
+ ./nuttx
+
+#. The preferred configuration is at
+ ``boards/sim/sim/sim/configs/nx11/defconfig``. This configuration
+ extends the test with a simulated framebuffer driver that uses an X
+ window as a framebuffer. This is a superior test configuration
+ because the X window appears at your desktop and you can see the NX
+ output. This preferred configuration can be built as follows::
+
+ tools/configure sim:nx11
+ make
+ ./nuttx
+
+ *Update:* The sim target has suffered some bit-rot over the years and
+ so the following caveats need to be added:
+
+ - The X target builds under recent Cygwin configurations, but does
+ not execute. (It fails inside of ``XOpenDisplay()``.
+
+ - The X target does not build under current (9.09) Ubuntu
+ distributions. I needed to make the following changes:
+
+ The build will also fail to locate the X header files unless you
+ install an X11 development package.
+
+ - Refer to the readme file in sim configuration
+ `README.txt <https://github.com/apache/incubator-nuttx/blob/master/boards/sim/sim/sim/README.txt>`__
+ file for additional information.
+
+**Test Coverage**. At present, ``apps/examples/nx``\ t only exercises a
+subset of NX; the remainder is essentially untested. The following table
+describes the testing performed on each NX API:
+
+NXGLIB API Test Coverage
+------------------------
+
+================================ ==================================== ========
+Function Special Setup/Notes Verified
+================================ ==================================== ========
+``nxgl_rgb2yuv()`` . NO
+``nxgl_yuv2rgb()`` . NO
+``nxgl_rectcopy()`` . YES
+``nxgl_rectoffset()`` . YES
+``nxgl_vectoradd()`` . YES
+``nxgl_vectorsubtract()`` . YES
+``nxgl_rectintersect()`` . YES
+``nxgl_rectunion()`` . YES
+``nxgl_nonintersecting()`` . YES
+``nxgl_rectoverlap()`` . YES
+``nxgl_rectinside()`` . YES
+``nxgl_rectsize()`` . YES
+``nxgl_nullrect()`` . YES
+``nxgl_runoffset()`` Verified by apps/examples/nxlines. YES
+``nxgl_runcopy()`` . NO
+``nxgl_trapoffset()`` Verified by apps/examples/nxlines. YES
+``nxgl_trapcopy()`` Verified by apps/examples/nxlines. YES
+``nxgl_colorcopy`` . YES
+``nxgl_splitline`` Verified using apps/examples/nxlines YES
+ Generally works well, but has some
+ accuracy/overflow problems wide
+ lines that are nearly horizontal.
+ There is a "fudge factor" that seems
+ to eliminate the problem, but there
+ could still be issues in some
+ configurations.
+``nxgl_circlepts`` Verified by apps/examples/nxlines. YES
+``nxgl_circletraps`` Verified by apps/examples/nxlines. YES
+================================ ==================================== ========
+
+NX Server Callbacks Test Coverage
+---------------------------------
+
+============== ==================== ========
+Function Special Setup/Notes Verified
+============== ==================== ========
+``redraw()`` . YES
+``position()`` . YES
+``mousein()`` . YES
+``kbdin()`` . YES
+============== ==================== ========
+
+NX API Test Coverage
+--------------------
+
+========================= =============================================================== ========
+Function Special Setup/Notes Verified
+========================= =============================================================== ========
+``nx_runinstance()`` . YES
+``nx_connectinstance()`` . YES
+``nx_disconnect()`` . YES
+``nx_eventhandler()`` . YES
+``nx_eventnotify()`` This is not used in the current version of apps/examples/nx, NO
+ was tested in a previous version)
+``nx_openwindow()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` in the YES
+ ``<NuttX-Directory>/.config file``
+``nx_closewindow()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` YES
+ in the ``<NuttX-Directory>/.config`` file
+``nx_requestbkgd()`` Verified by ``apps/examples/nxtext`` and YES
+ ``apps/examples/nxhello``.
+``nx_releasebkgd()`` Verified by ``apps/examples/nxtext`` and YES
+ ``apps/examples/nxhello``.
+``nx_getposition()`` . NO
+``nx_setposition()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` in the YES
+ ``<NuttX-Directory>/.config`` file
+``nx_setsize()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` in the YES
+ ``<NuttX-Directory>/.config`` file
+``nx_raise()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` in the YES
+ ``<NuttX-Directory>/.config`` file
+``nx_lower()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` in the YES
+ ``<NuttX-Directory>/.config`` file
+``nx_modal()`` . NO
+``nx_setvisibility()`` Exercized using Twm4Nx YES, Informally
+``nx_ishidden()`` Exercized using Twm4Nx YES, Informally
+``nx_fill()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` in the YES
+ ``<NuttX-Directory>/.config`` file
+``nx_getrectangle()`` . YES
+``nx_filltrapezoid()`` Verified by ``apps/examples/nxlines``. YES
+``nx_drawline()`` by ``apps/examples/nxlines``. YES
+``nx_drawcircle()`` Verified by ``apps/examples/nxlines``. YES
+``nx_fillcircle()`` Verified by ``apps/examples/nxlines``. YES
+``nx_setbgcolor()`` . YES
+``nx_move()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` in the YES
+ ``<NuttX-Directory>/.config`` file
+``nx_bitmap()`` Change to ``CONFIG_EXAMPLES_NX_RAWWINDOWS=y`` in the YES
+ ``<NuttX-Directory>/.config`` file.
+``nx_kbdin()`` . YES
+``nx_mousein()`` . YES
+========================= =============================================================== ========
+
+NXTK API Test Coverage
+----------------------
+
+============================ ========================= ========
+Function Special Setup/Notes Verified
+============================ ========================= ========
+``nxtk_openwindow()`` . YES
+``nxtk_closewindow()`` . YES
+``nxtk_getposition()`` . NO
+``nxtk_setposition()`` . YES
+``nxtk_setsize()`` . YES
+``nxtk_raise()`` . YES
+``nxtk_lower()`` . YES
+``nxtk_modal()`` . NO
+``nxtk_setvisibility()`` Exercized using Twm4Nx YES, informally
+``nxtk_ishidden()`` Exercized using Twm4Nx YES, informally
+``nxtk_fillwindow()`` . YES
+``nxtk_getwindow()`` . NO
+``nxtk_filltrapwindow()`` . NO
+``nxtk_drawlinewindow()`` . YES
+``nxtk_drawcirclewindow()`` . YES
+``nxtk_fillcirclewindow()`` . YES
+``nxtk_movewindow()`` . NO
+``nxtk_bitmapwindow()`` . YES
+``nxtk_opentoolbar()`` . YES
+``nxtk_closetoolbar()`` . YES
+``nxtk_filltoolbar()`` . YES
+``nxtk_gettoolbar()`` . NO
+``nxtk_filltraptoolbar()`` . NO
+``nxtk_drawlinetoolbar()`` . NO
+``nxtk_drawcircletoolbar()`` . NO
+``nxtk_fillcircletoolbar()`` . NO
+``nxtk_movetoolbar()`` . NO
+``nxtk_bitmaptoolbar()`` . NO
+============================ ========================= ========
+
+NXFONTS API Test Coverage
+-------------------------
+
+======================== ============================= ========
+Function Special Setup/Notes Verified
+======================== ============================= ========
+``nxf_getfonthandle()`` . YES
+``nxf_getfontset()`` . YES
+``nxf_getbitmap()`` . YES
+``nxf_convert_2bpp()`` . NO
+``nxf_convert_4bpp()`` . NO
+``nxf_convert_8bpp()`` Use defconfig when building. YES
+``nxf_convert_16bpp()`` . YES
+``nxf_convert_24bpp()`` . NO
+``nxf_convert_32bpp()`` . YES
+======================== ============================= ========
+
diff --git a/content/docs/10.1.0/_sources/components/nxgraphics/index.rst.txt b/content/docs/10.1.0/_sources/components/nxgraphics/index.rst.txt
new file mode 100644
index 0000000..7c0614b
--- /dev/null
+++ b/content/docs/10.1.0/_sources/components/nxgraphics/index.rst.txt
@@ -0,0 +1,176 @@
+.. _nxgraphics:
+
+=====================
+NX Graphics Subsystem
+=====================
+
+This document describes the tiny graphics support included in NuttX. It
+includes an overview description of that graphics support, detailed
+descriptions of the NuttX graphics APIs, and discussion of code
+organization, and OS configuration options.
+
+.. figure:: NuttXScreenShot.jpg
+ :align: center
+
+ **Figure 1**. This screnshot shows the final frame for the NuttX example
+ at ``apps/examples/nx`` running on the simulated, Linux x86 platform with
+ simulated framebuffer output to an X window. This picture shows to framed window
+ with (blank) toolbars. Each window has displayed text as received from the
+ NX keyboard interface The second window has just been raised to the top of the display.
+
+Objectives
+==========
+
+The objective of this development was to provide a tiny windowing system
+in the spirit of X, but greatly scaled down and appropriate for most
+resource-limited embedded environments. The current NX implementation
+supports the general following, high-level features:
+
+- **Virtual Vertical Graphics Space**. Windows that reside in a
+ virtual, *vertical* space so that it makes sense to talk about one
+ window being on top of another and obscuring the window below it.
+- **Client/Server Model**. A standard client server/model was adopted.
+ NX may be considered a server and other logic that presents the
+ windows are NX clients.
+- **Multi-User Support**. NX includes *front-end* logic to support a
+ separate NX server thread that can serve multiple NX client threads.
+ The NX is a server thread/daemon the serializes graphics operations
+ from multiple clients.
+- **Minimal Graphics Toolset**. The actual implementation of the
+ graphics operations is performed by common, *back-end* logic. This
+ back-end supports only a primitive set of graphic and rendering
+ operations.
+- **Device Interface**. NX supports any graphics device either of two
+ device interfaces:
+
+ - Any device with random access video memory using the NuttX
+ framebuffer driver interface (see ``include/nuttx/video/fb.h``).
+ - Any LCD-like device than can accept raster line *runs* through a
+ parallel or serial interface (see ``include/nuttx/lcd/lcd.h``). By
+ default, NX is configured to use the frame buffer driver unless
+ ``CONFIG_NX_LCDDRIVER`` is defined =y in your NuttX configuration
+ file.
+
+- **Transparent to NX Client**. The window client on "sees" the
+ sub-window that is operates in and does not need to be concerned with
+ the virtual, vertical space (other that to respond to *redraw*
+ requests from NX when needed).
+- **Framed Windows and Toolbars**. NX also adds the capability to
+ support windows with frames and toolbars on top of the basic
+ windowing support. These are windows such as those shown in the
+ `screenshot <#screenshot>`__ above. These framed windows sub-divide
+ one one window into three relatively independent subwindows: A frame,
+ the contained window and an (optional) toolbar window.
+- **Mouse Support**. NX provides support for a mouse or other X/Y
+ pointing devices. APIs are provided to allow external devices to give
+ X/Y position information and mouse button presses to NX. NX will then
+ provide the mouse input to the relevant window clients via callbacks.
+ Client windows only receive the mouse input callback if the mouse is
+ positioned over a visible portion of the client window; X/Y position
+ is provided to the client in the relative coordinate system of the
+ client window.
+- **Keyboard input**. NX also supports keyboard/keypad devices. APIs
+ are provided to allow external devices to give keypad information to
+ NX. NX will then provide the mouse input to the top window on the
+ display (the window that has the *focus*) via a callback function.
+
+Organization
+============
+
+NX is organized into 6 (and perhaps someday 7 or 8) logical modules.
+These logical modules also correspond to the directory organization.
+That NuttX directory organization is discussed in `Appendix
+B <#grapicsdirs>`__ of this document. The logic modules are discussed in
+the following sub-paragraphs.
+
+.. figure:: NXOrganization.gif
+ :align: center
+
+NX Graphics Library (``NXGL``)
+------------------------------
+
+NXGLIB is a standalone library that contains low-level graphics
+utilities and direct framebuffer or LCD rendering logic. NX is built on
+top NXGLIB.
+
+NX (``NXSU`` and ``NXMU``)
... 50925 lines suppressed ...