these docs have moved to mynewt-documentation and other mynewt-* repos
diff --git a/docs/faq/answers.md b/docs/faq/answers.md
deleted file mode 100644
index 1da1f0b..0000000
--- a/docs/faq/answers.md
+++ /dev/null
@@ -1,74 +0,0 @@
-## FAQ
-Here are some lists, grouped by categories, of frequently asked questions.
-
-**Mynewt software questions:**
-
-* [How do I reduce the code size for my Mynewt image?](/os/tutorials/codesize/)
-
-
-**Administrative questions:**
-
-* [How do I submit a bug?](#submit-a-bug)
-* [How do I request a feature?](#request-feature)
-* [How do I submit a patch if I am not a committer?](#not-committer-patch)
-* [Can I merge my own Pull Request into the git repo if I am a committer?](#committer-merge)
-* [How do I make changes to documentation?](#change-doc)
-* [How do I make changes to documentation using an editor on my laptop?](#doc-editor)
-
-
-<br>
-### <a name="summit-a-bug"></a> How do I submit a bug?
-<br>
-If you do not have a JIRA account sign up for an account on [JIRA](https://issues.apache.org/jira/secure/Signup!default.jspa).
-
-Submit a request to the @dev mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project. You can view the issues on JIRA for the MYNEWT project without an account but you need to log in for reporting a bug.
-
-Log in. Choose the "MYNEWT" project. Click on the "Create" button to create a ticket. Choose "Bug" as the Issue Type. Fill in the bug description, how it is triggered, and other details.
-
-### <a name="request-feature"></a> How do I request a feature?
-<br>
-If you do not have a JIRA account sign up for an account on [JIRA](https://issues.apache.org/jira/secure/Signup!default.jspa).
-
-Submit a request to the @dev mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project. You can view the issues on JIRA for the MYNEWT project without an account but you need to log in for reporting a bug.
-
-Log in. Choose the "MYNEWT" project. Click on the "Create" button to create a ticket. Choose "Wish" as the Issue Type. Fill in the feature description, benefits, and any other implementation details. Note in the description whether you want to work on it yourself.
-
-If you are not a committer and you wish to work on it, someone who is on the committer list will have to review your request and assign it to you. You will have to refer to this JIRA ticket in your pull request.
-
-### <a name="not-committer-patch"></a>I am not on the committer list. How do I submit a patch?
-<br>
-**You submit your proposed changes for your peers with committer status to review and merge.**
-
-The process to submit a Pull Request on github.com is described on the [Confluence page for the project](https://cwiki.apache.org/confluence/display/MYNEWT/Submitting+Pull+Requests).
-
-### <a name="committer-merge"></a>I am a committer in the project. Can I merge my own Pull Request into the git repository?
-<br>
-Yes, but only if your Pull Request has been reviewed and approved by another committer in Apache Mynewt.
-The process to merge a Pull Request is described on the [Confluence page for the project](https://cwiki.apache.org/confluence/display/MYNEWT/Merging+Pull+Requests).
-
-### <a name="change-doc"></a>I would like to make some edits to the documentation. What do I do?
-<br>
-You submit your proposed changes for your peers with committer status to review and merge.
-
-Go to the [documentation mirror](https://github.com/apache/mynewt-site) on github.com.
-
-Navigate to the file you wish to edit on github.com. All the technical documentation is in Markdown files under the `/docs` directory. Click on the pencil icon ("Edit the file in your fork of this project") and start making changes.
-
-Click the green "Propose file change" button. You will be directed to the page where you can start a pull request from the branch that was created for you. The branch is gets an automatic name `patch-#` where # is a number. Click on the green "Compare & pull request" to open the pull request.
-
-In the comment for the pull request, include a description of the changes you have made and why. Github will automatically notify everyone on the commits@mynewt.apache.org mailing list about the newly opened pull requests. You can open a pull request even if you don't think the code is ready for merging but want some discussion on the matter.
-
-Upon receiving notification, one or more committers will review your work, ask for edits or clarifications, and merge when your proposed changes are ready.
-
-If you want to withdraw the pull request simply go to your fork `https://github.com/<your github username>/mynewt-site` and click on "branches". You should see your branch under "Your branches". Click on the delete icon.
-
-### <a name="doc-editor"></a>I would like to make some edits to the documentation but want to use an editor on my own laptop. What do I do?
-<br>
-You submit your proposed changes for your peers with committer status to review and merge.
-
-Go to the [documentation mirror](https://github.com/apache/mynewt-site) on github.com. You need to create your own fork of the repo in github.com by clicking on the "Fork" button on the top right. Clone the forked repository into your laptop (using `git clone` from a terminal or using the download buttons on the github page)and create a local branch for the edits and switching to it (using `git checkout -b <new-branchname>` or GitHub Desktop).
-
-Make your changes using the editor of your choice. Push that branch to your fork on github. Then submit a pull request from that branch on your github fork.
-
-The review and merge process is the same as other pull requests described for earlier questions.
-
diff --git a/docs/faq/go_env.md b/docs/faq/go_env.md
deleted file mode 100644
index ebd2d3d..0000000
--- a/docs/faq/go_env.md
+++ /dev/null
@@ -1,182 +0,0 @@
-## Contributing to Newt or Newtmgr Tools
-
-Newt and Newtmgr are written in Go (golang). This guide shows you how to install Go and setup your environment to update and build the tools if you want to:
-
-* Build the tools with latest updates from the master branch on Linux or Windows platforms.
-
- **Note:** For Mac OS, you can use the `brew install mynewt-newt -HEAD` and the `brew install mynewt-newtmgr --HEAD` commands.
-
-* Contribute to newt or newtmgr features or fix bugs.
-
-This guide shows you how to perform the following:
-
-1. Install Mac OS X, Linux, Windows. (Tasks that are specific to each platform are called out.)
-2. Setup the Go environment.
-3. Download the source, build, and install the newt or newtmgr tools.
-4. Update and rebuild the tools.
-
-**Note:** You will also need to read and follow the instructions from the [FAQ](/faq/answers/) to set up your git repos to submit changes.
-
-
-### Step 1: Installing Go
-The latest master branch of newt and newtmgr requires GO version 1.10. You can skip this step and proceed to Step 2 if you already have Go version 1.10 installed.
-
-<br>
-#### Installing Go on Mac OS X
-
-If you do not have Homebrew installed, run the following command. You will be prompted for your sudo password.
-
-```no-highlight
-$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
-```
-You can also extract (or `git clone`) Homebrew and install it to /usr/local.
-
-<br>
-Use brew to install Go:
-
-```no-highlight
-$ brew install go
-==>
-...
-...
-==> Summary
-🍺 /usr/local/Cellar/go/1.10.3: 8,170 files, 336.8MB
-```
-You can also download the Go package directly from (https://golang.org/dl/) and install it in /usr/local/bin instead of brewing it.
-
-<br>
-#### Installing Go on Linux and Windows
-You can download Go from [https://golang.org/dl/](https://golang.org/dl/).
-
-<br>
-###Step 2: Setting Up Your Go Environment
-
-This section describes the Go environment and how to setup a Go workspace. If you already have a Go workspace for your other Go projects, you can skip this step and proceed to Step 3.
-
-Go provides an environment to compile Go code, construct Go packages, and import Go code. You will use Go commands to import the newt or newtmgr package repository into your local Go environment. The Go language environment dictates a specific directory structure, or workspace in Go parlance. It must contain three sibling directories with the names **src**, **pkg** and **bin**:
-
-* src contains Go source files organized into packages (one package per directory)
-* pkg contains package objects
-* bin contains the Go application executables that Go builds and installs.
-
-The **GOPATH** environment variable specifies the location of your workspace. To setup this workspace environment, create a **dev** directory and then a **go** directory under it. Set the GOPATH environment variable to this directory where you will clone the newt and newtmgr repositories.
-
-```no-highlight
-$ cd $HOME
-$ mkdir -p dev/go
-$ cd dev/go
-$ export GOPATH=`pwd`
-```
-<br>
-Add the following export statements to your ~/.bash_profile file and source the file:
-```no-highlight
-export GOPATH=$HOME/dev/go
-export PATH=$GOPATH/bin:$PATH
-```
-<br>
-
-### Step 3: Downloading the Source and Installing the Tools
-Newt and newtmgr are individual Go packages and have their own git repositories. You can download the source and install one or both tools.
-
-We use the `go get` command to download the source, build, and install the binary in the **$GOPATH/bin** directory.
-
-<br>
-#### Downloading and Installing the Newt Tool
-
-The newt Go package is **mynewt.apache.org/newt/newt** and is stored in the [Apache Mynewt newt tool repository mirrored on github](https://github.com/apache/mynewt-newt).
-
-
-Download the newt package source and install the tool:
-
-```no-highlight
-$cd $GOPATH
-$go get mynewt.apache.org/newt/newt
-$cd $GOPATH/src/mynewt.apache.org/newt
-$ls
-DISCLAIMER RELEASE_NOTES.md util
-INSTALLING.md build.sh viper
-LICENSE newt yaml
-NOTICE newtmgr
-README.md newtvm
-$git status
-On branch master
-Your branch is up-to-date with 'origin/master'.
-nothing to commit, working directory clean
-```
-<br>
-**Note:** The source code under the **newtmgr** directory is no longer used or updated. The current **newtmgr** source has its own Git repository.
-
-<br>
-Check that the newt binary is installed and you are using the one from ** $GOPATH/bin**:
-
-```no-highlight
-$ls $GOPATH/bin/newt
-~/dev/go/bin/newt
-$which newt
-~/dev/go/bin/newt
-$newt version
-Apache Newt version: 1.1.0-dev
-```
-<br>
-#### Downloading and Installing the Newtmgr Tool
-
-The newtmgr Go package is **mynewt.apache.org/newtmgr/newtmgr**. It is stored in the [Apache Mynewt newtmgr tool repository mirrored on github](https://github.com/apache/mynewt-newtmgr).
-
-Download the newtmgr package and install the tool:
-
-```no-highlight
-$cd $GOPATH
-$go get mynewt.apache.org/newtmgr/newtmgr
-$cd $GOPATH/src/mynewt.apache.org/newtmgr
-$ls
-LICENSE NOTICE README.md newtmgr nmxact
-$git status
-On branch master
-Your branch is up-to-date with 'origin/master'.
-nothing to commit, working directory clean
-```
-<br>
-Check that the newtmgr binary is installed and you are using the one from **$GOPATH/bin**:
-
-```no-highlight
-$ls $GOPATH/bin/newtmgr
-~/dev/go/bin/newtmgr
-$which newtmgr
-~/dev/go/bin/newtmgr
-```
-<br>
-### Step 4: Updating and Rebuilding the Tools:
-This section shows you how to rebuild the newt and newtmgr tools with the latest updates from the master branch or after you have made changes in your branch.
-
-Here is the general procedure to rebuild either the newt or newtmgr tool. The only difference is the directory where you will be executing the commands from. You will need to repeat the procedure to rebuild both tools.
-
-1. Change to the directory where the local Git repository for the tool is installed.
-2. Pull the latest changes from the master branch. If you made changes you will need to rebase with **origin master** (See [FAQ](/faq/answers/)).
-3. Build and install the tool.
-
-<br>
-Change to the directory where the source for the tool is installed.
-
-For the **newt** tool:
-```no-highlight
-$cd $GOPATH/src/mynewt.apache.org/newt/newt
-```
-
-For the **newtmgr** tool:
-```no-highlight
-$cd $GOPATH/src/mynewt.apache.org/newtmgr/newtmgr
-```
-<br>
-After you change to the specific tool directory, get the latest updates from the master branch. If you made changes and need to rebase with the origin, add the `--rebase origin master` arguments to the `git pull` command:
-
-```no-highlight
-$git pull
-```
-
-<br>
-Build and install the tool. The updated binary will be installed in the **$GOPATH/bin** directory:
-
-```no-highlight
-$go install
-```
-You can run the `ls -l` command to check the modification time for the binary to ensure the new version is installed.
diff --git a/docs/faq/how_to_edit_docs.md b/docs/faq/how_to_edit_docs.md
deleted file mode 100644
index 1725612..0000000
--- a/docs/faq/how_to_edit_docs.md
+++ /dev/null
@@ -1,55 +0,0 @@
-## How to Edit Docs
-
-### Objective
-
-Learn the process of editing docs by adding some content to a test document.
-
-### Markdown, MkDocs, Mou
-
-The Mynewt documentation you see on the Apache website is a bunch of HTML files generated using MkDocs which is a simple static site generation tool geared towards building project documentation. You can read about it at [http://www.mkdocs.org](http://www.mkdocs.org). Documentation source files are written in Markdown, and configured with a single YAML configuration file. Markdown is a lightweight markup language with plain text formatting syntax designed so that it can be converted to HTML and many other formats using a tool (which in our case is MkDocs).
-
-The HTML pages are generated periodically after changes have been reviewed and accepted into the master branch.
-
-
-### Access to the Apache repo
-
-Get an account on Apache. You do not need a committer account to view the website or clone the repository but you need it to push changes to it.
-
-If you are not a committer, you may follow the proposed non-committer workflow to share your work. The direct link to the proposed workflow is [https://git-wip-us.apache.org/docs/workflow.html](https://git-wip-us.apache.org/docs/workflow.html). You will find the steps described in more detail later in this tutorial.
-
-### Editing an existing page
-
-* Create a fork on the [github mirror](https://github.com/apache/mynewt-site).
-* Create a new branch to work on your documentation and move to that branch.
-```
- $ git checkout -b <your-branch-name>
-```
-
-* Make changes directly on github.com. Generate a pull request. Alternatively, you can edit locally on your machine, push the branch (or the changes in the branch) to your fork on github.com, and then generate a pull request.
-
-### Adding a new page
-
-If you create a new file somewhere in the `docs` subdirectory to add a new page, you have to add a line in the `mkdocs.yml` file at the correct level. For example, if you add a new module named "Wi-Fi" by creating a new file named `wifi.md` in the `network` directory, you have to insert the following line under `Networking User Guide` in the `mkdocs.yml` file (at the same level as the `docs` directory). In this example, a link will show up in the navigation bar on the left under "Networking User Guide" titled "Wi-Fi" and take the user to the contents of the 'wifi.md' file when the link is clicked. ** Note: The change will show up on this [Mynewt site](http://mynewt.apache.org) only after your pull request is merged in and the updated site is generated.**
-
-```
- - 'Wi-Fi': 'wifi.md'
-```
-### Local preview of HTML files
-
-You have the option to install MkDocs and do a local conversion yourself to preview the pages using the built-in webserver that comes with MkDocs. In order to install MkDocs you'll need Python installed on your system, as well as the Python package manager, pip. You can check if you have them already (usually you will).
-```
- $ python --version
- Python 2.7.2
- $ pip --version
- pip 1.5.2
- $ pip install mkdocs
-```
-You will then run the built-in webserver from the root of the documentation directory using the command `mkdocs serve`. The root directory for documentation is `mynewt-site` or the directory with the `mkdocs.yml` file.
-```
- $ ls
- docs images mkdocs.yml
- $ mkdocs serve
-```
-Then go to [http://127.0.0.1:8000](http://127.0.0.1:8000) to preview your pages and see how they will look on the website. **Remember that the Myself website itself will not be updated.**
-
-For more information on MkDocs go to [http://www.mkdocs.org](http://www.mkdocs.org).
diff --git a/docs/faq/ide.md b/docs/faq/ide.md
deleted file mode 100644
index bacee39..0000000
--- a/docs/faq/ide.md
+++ /dev/null
@@ -1,252 +0,0 @@
-## Developing Mynewt Applications with Visual Studio Code
-
-This guide shows you how to set up Visual Studio Code to develop and debug Mynewt applications. Visual Studio Code is supported on Mac OS, Linux, and Windows. This guide shows you how to:
-
-1. Install Visual Studio Code.
-2. Install the C/C++ and debugger extensions.
-3. Define task configurations to build Mynewt applications.
-4. Define debugger configurations to debug Mynewt applications.
-5. Launch the debugger.
-
-Prerequisites:
-
-* Have Internet connectivity to fetch remote Mynewt components.
-* Have a computer to build a Mynewt application.
-* Perform [native installation](/os/get_started/native_install_intro.md) for the Mynewt tools and toolchains.
-
- **Note:** For Windows platforms, ensure that the MinGW bash you install is added to your Windows Path. In addition, if you are using Windows 10 WSL, you must have the MinGW bash before the Windows 10 WSL bash in your Windows Path.
-
-* Read the Mynewt OS Concepts section.
-* Create a project space (directory structure) and populate it with the core code repository (apache-mynewt-core) or know how to as explained in Creating Your First Project.
-* Complete one of the [Blinky Tutorials](/os/tutorials/blinky.md).
-
-**Notes:**
-
-* This guide is not a tutorial for Visual Studio Code. It assumes you are familiar with Visual Studio Code. If this is your first time using Visual Studio Code, we recommend that you read the Visual Studio Code [documentation and tutorials](https://code.visualstudio.com/docs) and evaluate whether you would like to use it to develop Mynewt applications.
-* This guide uses Visual Studio Code on Windows. Visual Studio Code is supported on Linux and Mac OS but may have some variations in the keyboard shortcuts and command names for these platforms.
-* You can also use the Eclipse IDE to develop Mynewt applications. See [https://www.codecoup.pl/blog/hacking-mynewt-in-eclipse](https://www.codecoup.pl/blog/hacking-mynewt-in-eclipse) for more details. On Windows platforms, you must also ensure the MinGW bash is set in your Windows Path as described in the prerequisites.
-
-### Installing Visual Studio Code
-Download and install Visual Studio Code from [https://code.visualstudio.com/](https://code.visualstudio.com/).
-
-### Installing the C/C++ and Debugger Extensions
-
-You need to install two extensions:
-
-1. The C/C++ extension from Microsoft. This extension provides language support such as symbol searching, signatuare help, go to definition, and go to declaration.
-
-2. The Native Debug extension from webfreak. This extension provides GDB support.
-
-<br>
-To install the C/C++ extension:
-
-1. Press `Ctrl-P` to open the search box.
-2. Type `ext install cpptools` in the search box and press Enter. You should see the extension at the top of the list.
-3. Click `Install` to install the extension.
-<br>
-
-To install the Native Debugger:
-
-1. Press `Ctrl-P` to open the search box.
-2. Type `ext install webfreak.debug` in the search box and press Enter. You should see the Native Debug extension at the top of the list.
-3. Click `Install` to install the extension.
-<br>
-###Defining Tasks for Mynewt Projects
-
-Two main concepts in Visual Studio Code are workspaces and tasks. A workspace represents a folder that is open. You can open multiple workspaces and switch between workspaces.
-
-Tasks allow you to integrate the external tools and operations that are used to build or test your project into Visual Studio Code. Tasks are run from and the task results can be analyzed in Visual Studio Code. Tasks are defined within the scope of a workspace. This means that the tasks you define for a workspace only apply to the given workspace.
-
-<br>
-####Associating a Mynewt Project to a Workspace
-For your Mynewt project, your Visual Studio Code workspace is the Mynewt project base directory. For example, if you create a project named `myproj` under the `~/dev` directory, then you open the `~/dev/myproj` folder for your workspace.
-
-Select **File** > **Open Folder**, and select the `myproj` folder from the `Select Folder` dialog box to open the folder.
-
-<br>
-####Defining Visual Studio Code Tasks to Build and Debug Mynewt Applications
-
-You define Visual Studio Code tasks to build and debug your Mynewt targets in Visual Studio Code. We use the Blinky application for the Arduino Zero board from the [Blinky On Arduino Zero Tutorial](/os/tutorials/arduino_zero.md) to illustrate how to define the tasks to build and debug the Arduino blinky bootloader and application targets.
-
-Perform the following steps to create the tasks to build and debug the Arduino blinky bootloader and appliction targets:
-
-Step 1: Press `Ctrl-Shift-P`, type `task`, and select **Tasks:Configure Task Runner** from the search results.
-
-Step 2: Select **Others** (scroll down to the bottom of the list) to create a task runner for external commands.
-<br>
-<p align="center"><img src="/faq/pics/task_runner_small.png"></p>
-<br>
-Tasks are defined in the `tasks.json` file. You should see the `.vscode` folder created in the `MYPROJ` folder and a `tasks.json` file created in the `.vscode` folder. The `tasks.json` file has the following default values.
-
-<br>
-<p align="center"><img src="/faq/pics/task_json_small.png"></p>
-<br>
-
-The sample `tasks.json` file defines a simple task that runs the echo command with "Hello World" as the argument.
-
-Step 3: Delete the content from the `tasks.json` file, add the following definitions, and press `Ctrl-S` to save the file.
-
-```no-highlight
-{
- "version": "0.1.0",
- "command": "newt",
- "echoCommand": true,
- "isShellCommand": true,
-
- "tasks":[
- {
- "taskName": "build_arduino_boot",
- "args": ["build", "arduino_boot"],
- "suppressTaskName": true
- },
- {
- "taskName": "build_arduino_blinky",
- "args": ["build", "arduino_blinky"],
- "isBuildCommand": true,
- "suppressTaskName": true
- },
- {
- "taskName": "create_arduino_blinky",
- "args": ["create-image", "arduino_blinky", "1.0.0"],
- "suppressTaskName":true
- },
- {
- "taskName": "debug_arduino_blinky",
- "args": ["debug", "arduino_blinky", "-n"],
- "suppressTaskName": true
- }
- ]
-}
-```
-<br>
-The `tasks.json` file specifies the tasks that are run to build and debug the Arduino blinky targets. Each task runs a `newt` command. The `newt` command to run and the arguments for the `newt` command are passed in the `args` property for each task.
-
-The following tasks are defined in this example:
-
-1. **build_arduino_boot**: Runs the `newt build arduino_boot` command to build the arduino_boot target.
-2. **build_arduino_blinky**: Runs the `newt build arduino_blinky` command to build the arduino_blinky target.
-
- **Note:** This task sets the `isBuildCommand` property to `true`. This is an optional property that, when set to true, allows you to run the **Tasks: Run Build Task**(`Ctrl-Shift-B`) command to start the task.
-
-3. **create_arduino_blinky**: Runs the `newt create-image arduino_blinky` command to create the image file.
-4. **debug_arduino_blinky**: Runs the `newt debug arduino_blinky -n` command to debug the arduino_blinky target. The `-n` flag is specified to start only the GDB server and not the GDB client. We will launch the GDB client from Visual Studio Code.
-
-For more information on tasks and all supported properties, see the [Visual Studio Code Task documentation](https://code.visualstudio.com/docs/editor/tasks).
-
-<br>
-####Running a Task
-
-To run a task, press `Ctrl-Shift-P`, type `task` on the search box, and select **Tasks: Run Task**. The tasks that you define in the `tasks.json` file are listed. Select the task to run.
-
-The following is an example of running the `build_arduino_boot` task:
-<br>
-<p align="center"><img src="/faq/pics/task_select_small.png"></p>
-<br>
-<br>
-<p align="center"><img src="/faq/pics/task_start_small.png"></p>
-
-<br>
-
-**Note**:To run the `build_arduino_blinky` task, you can use the keyboard shortcut `Ctrl-Shift-B` because the task has the property `isBuildCommand` set to true.
-
-<br>
-####Defining Tasks for Other Newt Commands
-
-Other newt commands, such as the `newt load` command, do not need to run from within Visual Studio Code. You can define a task for each command as a convenience and run the command as a task, or you can run the newt command on the command line from the Visual Studio Code integrated terminal or an external terminal.
-
-To create the tasks for the `newt load arduino_boot` and `newt load arduino_blinky` commands, add the following definitions to the `tasks.json` file:
-
-```no-highlight
- {
- "taskName": "load_arduino_boot",
- "args": ["load", "arduino_boot"],
- "suppressTaskName":true
- },
- {
- "taskName": "load_arduino_blinky",
- "args": ["load", "arduino_blinky"],
- "suppressTaskName":true
- },
-
-```
-
-
-<br>
-To run a command from the Visual Studio integrated terminal, instead of starting a task, press ``Ctrl-` `` to launch the integrated terminal and enter the command on the prompt:
-<br>
-<p align="center"><img src="/faq/pics/integrated_terminal_small.png"></p>
-<br>
-###Defining Debugger Configurations
-You need to define a debugger configuration to launch the GDB debugger from within Visual Studio Code:
-
-Step 1: Select **Debug** > **Open Configuration**, and select the **GDB** environment.
-
-<br>
-<p align="center"><img src="/faq/pics/debug_new_config_small.png"></p>
-<br>
-
-You should see a default `launch.json` file created in the `.vscode` folder.
-<br>
-<p align="center"><img src="/faq/pics/launch_small.png"></p>
-<br>
-
-<br>
-Step 2: Delete the content from the `launch.json` file, add the following definitions, and press 'Ctrl-S' to save the file.
-
-```no-highlight
-{
- "version": "0.2.0",
- "configurations": [
- {
- "name": "gdb_arduino_blinky",
- "type": "gdb",
- "request": "attach",
- "executable": "${workspaceRoot}\\bin\\targets\\arduino_blinky\\app\\apps\\blinky\\blinky.elf",
- "target": ":3333",
- "cwd": "${workspaceRoot}",
- "gdbpath": "C:\\Program Files (x86)\\GNU Tools ARM Embedded\\4.9 2015q2\\bin\\arm-none-eabi-gdb.exe",
- "remote": true
-
- }
- ]
-}
-
-```
-<br>
-This defines a `gdb_arduino_blinky` debugger configuration. It specifies:
-
-* The debugger is type **gdb**.
-* To use the `blinky.elf` file for the executable.
-* To use port 3333 to connect with the remote target.
-* To use arm-none-eabi-gdb for the GDB program.
-<br>
-###Debugging Your Application
-To debug your application, start the GDB server and launch the GDB session from Visual Studio Code. For the the arduino blinky example, perform the following:
-
-Step 1: Run the debug_arduino_blinky task to start the GDB server. Perform the following:
-
-1. Press `Ctrl-Shift-P` and type `task` in the search box.
-2. Select **Tasks:Run Task** > **debug_arduino_blinky**.
-3. Press `Ctrl-Shift-U` to open the Output Panel and see the OpenOCD GDB Server output.
-<br>
-<p align="center"><img src="/faq/pics/gdb_server_small.png"></p>
-<br>
-
-Step 2: Start the GDB session. Perform the following:
-
-1. Press `Ctrl-Shift-Y` to view the Debug Console.
-2. Press the Debugging icon on the activity bar (Ctrl-Shift-D) to bring up the Debug Side Bar.
-3. Select `gdb_arduino_blinky` from the DEBUG drop down menu.
-4. Press the green play button to start the gdb session.
-
-<p align="center"><img src="/faq/pics/gdb_small.png"></p>
-<br>
-Step 3: Debug your application. You should see a debug session similar to the one shown below:
-<p align="center"><img src="/faq/pics/gdb_debug_small.png"></p>
-<br>
-For more information on how to use the Visual Studio Code Debugger, see the [Visual Studio Code debugging documentation](https://code.visualstudio.com/docs/editor/debugging).
-
-
-### Working with Multiple Mynewt Applications
-
-As mentioned previously, each mynewt project corresponds to a Visual Studio Code workspace. If you have multiple Mynewt application targets defined in same project, you will need to define build and debug tasks for each target in the `tasks.json` file and debugger configurations for the targets in the `launch.json` file for the workspace. If you have a different Mynewt project for each mynewt application, you will need to define build and debug tasks in the `tasks.json` file and the debugger configuration in the `launch.json` file for each workspace.
diff --git a/docs/faq/mynewt_dev_cycle.jpg b/docs/faq/mynewt_dev_cycle.jpg
deleted file mode 100644
index 6b4795d..0000000
--- a/docs/faq/mynewt_dev_cycle.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/debug_new_config_small.png b/docs/faq/pics/debug_new_config_small.png
deleted file mode 100755
index 5d2e287..0000000
--- a/docs/faq/pics/debug_new_config_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/gdb_debug_small.png b/docs/faq/pics/gdb_debug_small.png
deleted file mode 100755
index 5ebfb11..0000000
--- a/docs/faq/pics/gdb_debug_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/gdb_server_small.png b/docs/faq/pics/gdb_server_small.png
deleted file mode 100755
index e6a42d7..0000000
--- a/docs/faq/pics/gdb_server_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/gdb_small.png b/docs/faq/pics/gdb_small.png
deleted file mode 100755
index f6c35d2..0000000
--- a/docs/faq/pics/gdb_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/integrated_terminal_small.png b/docs/faq/pics/integrated_terminal_small.png
deleted file mode 100755
index 11414c8..0000000
--- a/docs/faq/pics/integrated_terminal_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/launch_small.png b/docs/faq/pics/launch_small.png
deleted file mode 100755
index 5c13dcf..0000000
--- a/docs/faq/pics/launch_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/task_json_small.png b/docs/faq/pics/task_json_small.png
deleted file mode 100755
index 5047f61..0000000
--- a/docs/faq/pics/task_json_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/task_runner_small.png b/docs/faq/pics/task_runner_small.png
deleted file mode 100755
index 25a70fa..0000000
--- a/docs/faq/pics/task_runner_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/task_select_small.png b/docs/faq/pics/task_select_small.png
deleted file mode 100755
index 35bc304..0000000
--- a/docs/faq/pics/task_select_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/faq/pics/task_start_small.png b/docs/faq/pics/task_start_small.png
deleted file mode 100755
index f84cd26..0000000
--- a/docs/faq/pics/task_start_small.png
+++ /dev/null
Binary files differ
diff --git a/docs/network/ble/ble_blemesh.md b/docs/network/ble/ble_blemesh.md
deleted file mode 100644
index 5b31da6..0000000
--- a/docs/network/ble/ble_blemesh.md
+++ /dev/null
@@ -1,32 +0,0 @@
-**blemesh** sample application implements Bluetooth Mesh node that supports
-On/Off and Level models.
-
-To build application use following target. Note that since this application
-uses Non-resolvable Private Address there is no need for configuring public
-address.
-
-```
-newt target create blemesh
-newt target set blemesh app=@apache-mynewt-core/apps/blemesh
-newt target set blemesh bsp=@apache-mynewt-core/hw/bsp/nrf52840pdk
-newt target set blemesh build_profile=optimized
-newt target set blemesh syscfg=BLE_MESH_PB_GATT=1:BLE_MESH_DEV_UUID='(uint8_t[16]){0x22, 0x20, 0}'
-```
-
-Every device should have unique Device UUID so config amend and rebuild is needed for each of
-the devices that will be added to a network.
-
-```
-newt target set blemesh syscfg=BLE_MESH_PB_GATT=1:BLE_MESH_DEV_UUID='(uint8_t[16]){0x22, 0x21, 0}'
-...
-newt target set blemesh syscfg=BLE_MESH_PB_GATT=1:BLE_MESH_DEV_UUID='(uint8_t[16]){0x22, 0x22, 0}'
-...
-newt target set blemesh syscfg=BLE_MESH_PB_GATT=1:BLE_MESH_DEV_UUID='(uint8_t[16]){0x22, 0x23, 0}'
-```
-
-GATT bearer is enabled so that it is possible to provision those with Bluetooth Mesh application
-from Silicon Labs
-(available [here](https://play.google.com/store/apps/details?id=com.siliconlabs.bluetoothmesh))
-which doesn't support advertising bearer.
-
-
diff --git a/docs/network/ble/ble_hs/ble_att/ble_att.md b/docs/network/ble/ble_hs/ble_att/ble_att.md
deleted file mode 100644
index 4778706..0000000
--- a/docs/network/ble/ble_hs/ble_att/ble_att.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">NimBLE Host ATT Client Reference</font>
-
-### Introduction
-
-The Attribute Protocol (ATT) is a mid-level protocol that all BLE devices use to exchange data. Data is exchanged when an ATT client reads or writes an attribute belonging to an ATT server. Any device that needs to send or receive data must support both the client and server functionality of the ATT protocol. The only devices which do not support ATT are the most basic ones: broadcasters and observers (i.e., beaconing devices and listening devices).
-
-Most ATT functionality is not interesting to an application. Rather than use ATT directly, an application uses the higher level GATT profile, which sits directly above ATT in the host. NimBLE exposes the few bits of ATT functionality which are not encompassed by higher level GATT functions. This section documents the ATT functionality that the NimBLE host exposes to the application.
-
-### Header
-
-```c
-#include "host/ble_hs.h"
-```
-
-### Definitions
-
-None.
-
-### Functions
-
-| Function | Description |
-|----------|-------------|
-| [ble_att_mtu](functions/ble_att_mtu.md) | Retrieves the ATT MTU of the specified connection. |
-| [ble_att_preferred_mtu](functions/ble_att_preferred_mtu.md) | Retrieves the preferred ATT MTU. |
-| [ble_att_set_preferred_mtu](functions/ble_att_set_preferred_mtu.md) | Sets the preferred ATT MTU; the device will indicate this value in all subseqeunt ATT MTU exchanges. |
-| [ble_att_svr_read_local](functions/ble_att_svr_read_local.md) | Reads a locally registered attribute. |
-| [ble_att_svr_write_local](functions/ble_att_svr_write_local.md) | Writes a locally registered attribute. |
diff --git a/docs/network/ble/ble_hs/ble_att/functions/ble_att_mtu.md b/docs/network/ble/ble_hs/ble_att/functions/ble_att_mtu.md
deleted file mode 100644
index b33b922..0000000
--- a/docs/network/ble/ble_hs/ble_att/functions/ble_att_mtu.md
+++ /dev/null
@@ -1,20 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_att\_mtu</font>
-
-```c
-uint16_t
-ble_att_mtu(uint16_t conn_handle)
-```
-
-### Description
-
-Retrieves the ATT MTU of the specified connection. If an MTU exchange for this connection has occurred, the MTU is the lower of the two peers' preferred values. Otherwise, the MTU is the default value of 23.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The handle of the connection to query. |
-
-### Returned values
-
-The specified connection's ATT MTU, or 0 if there is no such connection.
diff --git a/docs/network/ble/ble_hs/ble_att/functions/ble_att_preferred_mtu.md b/docs/network/ble/ble_hs/ble_att/functions/ble_att_preferred_mtu.md
deleted file mode 100644
index d3e2c54..0000000
--- a/docs/network/ble/ble_hs/ble_att/functions/ble_att_preferred_mtu.md
+++ /dev/null
@@ -1,18 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_att\_preferred\_mtu</font>
-
-```c
-uint16_t
-ble_att_preferred_mtu(void)
-```
-
-### Description
-
-Retrieves the preferred ATT MTU. This is the value indicated by the device during an ATT MTU exchange.
-
-### Parameters
-
-None
-
-### Returned values
-
-The preferred ATT MTU.
diff --git a/docs/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu.md b/docs/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu.md
deleted file mode 100644
index 3d8e86f..0000000
--- a/docs/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_att\_set\_preferred\_mtu</font>
-
-```c
-int
-ble_att_set_preferred_mtu(uint16_t mtu)
-```
-
-### Description
-
-Sets the preferred ATT MTU; the device will indicate this value in all subseqeunt ATT MTU exchanges. The ATT MTU of a connection is equal to the lower of the two peers' preferred MTU values. The ATT MTU is what dictates the maximum size of any message sent during a GATT procedure. The specified MTU must be within the following range: [23, BLE\_ATT\_MTU\_MAX]. 23 is a minimum imposed by the Bluetooth specification; BLE\_ATT\_MTU\_MAX is a NimBLE compile-time setting.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| mtu | The preferred ATT MTU. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EINVAL | The specifeid value is not within the allowed range. |
diff --git a/docs/network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local.md b/docs/network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local.md
deleted file mode 100644
index baa0f62..0000000
--- a/docs/network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_att\_svr\_read\_local</font>
-
-```c
-int
-ble_att_svr_read_local(
- uint16_t attr_handle,
- struct os_mbuf **out_om
-)
-```
-
-### Description
-
-Reads a locally registered attribute. If the specified attribute handle coresponds to a GATT characteristic value or descriptor, the read is performed by calling the registered GATT access callback.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| attr\_handle | The 16-bit handle of the attribute to read. |
-| out\_om | On success, this is made to point to a newly-allocated mbuf containing the attribute data read. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [ATT return code](../../ble_hs_return_codes/#return-codes-att) | The attribute access callback reports failure. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local.md b/docs/network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local.md
deleted file mode 100644
index c4ee452..0000000
--- a/docs/network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_att\_svr\_write\_local</font>
-
-```c
-int
-ble_att_svr_write_local(
- uint16_t attr_handle,
- struct os_mbuf *om
-)
-```
-
-### Description
-
-Writes a locally registered attribute. This function consumes the supplied mbuf regardless of the outcome. If the specified attribute handle coresponds to a GATT characteristic value or descriptor, the write is performed by calling the registered GATT access callback.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| attr\_handle | The 16-bit handle of the attribute to write. |
-| om | The value to write to the attribute. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [ATT return code](../../ble_hs_return_codes/#return-codes-att) | The attribute access callback reports failure. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_att/mdtoc.md b/docs/network/ble/ble_hs/ble_att/mdtoc.md
deleted file mode 100644
index 18238ae..0000000
--- a/docs/network/ble/ble_hs/ble_att/mdtoc.md
+++ /dev/null
@@ -1,8 +0,0 @@
- - 'ATT':
- - toc: 'network/ble/ble_hs/ble_att/ble_att.md'
- - 'Functions':
- - 'ble_att_mtu': 'network/ble/ble_hs/ble_att/functions/ble_att_mtu.md'
- - 'ble_att_preferred_mtu': 'network/ble/ble_hs/ble_att/functions/ble_att_preferred_mtu.md'
- - 'ble_att_set_preferred_mtu': 'network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu.md'
- - 'ble_att_svr_read_local': 'network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local.md'
- - 'ble_att_svr_write_local': 'network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local.md'
diff --git a/docs/network/ble/ble_hs/ble_gap/ble_gap.md b/docs/network/ble/ble_hs/ble_gap/ble_gap.md
deleted file mode 100644
index 2375aea..0000000
--- a/docs/network/ble/ble_hs/ble_gap/ble_gap.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">NimBLE Host GAP Reference</font>
-
-### Introduction
-
-The Generic Access Profile (GAP) is responsible for all connecting, advertising, scanning, and connection updating operations.
-
-### Header
-
-```c
-#include "host/ble_hs.h"
-```
-
-### Definitions
-
-[BLE host GAP definitions](definitions/ble_gap_defs.md)
-
-### Functions
-
-| Function | Description |
-|----------|-------------|
-| [ble_gap_adv_active](functions/ble_gap_adv_active.md) | Indicates whether an advertisement procedure is currently in progress. |
-| [ble_gap_adv_rsp_set_data](functions/ble_gap_adv_rsp_set_data.md) | Configures the data to include in subsequent scan responses. |
-| [ble_gap_adv_rsp_set_fields](functions/ble_gap_adv_rsp_set_fields.md) | Configures the fields to include in subsequent scan responses. |
-| [ble_gap_adv_set_data](functions/ble_gap_adv_set_data.md) | Configures the data to include in subsequent advertisements. |
-| [ble_gap_adv_set_fields](functions/ble_gap_adv_set_fields.md) | Configures the fields to include in subsequent advertisements. |
-| [ble_gap_adv_set_phys](functions/ble_gap_adv_set_phys.md) | <font color="red"> [experimental]</font> Configures primary and secondary PHYs to use in subsequent extended advertisements from Bluetooth 5. |
-| [ble_gap_adv_set_tx_power](functions/ble_gap_adv_set_tx_power.md) | <font color="red"> [experimental]</font> Configures Tx Power level to use in subsequent extended advertisements from Bluetooth 5. |
-| [ble_gap_adv_start](functions/ble_gap_adv_start.md) | Initiates advertising. |
-| [ble_gap_adv_stop](functions/ble_gap_adv_stop.md) | Stops the currently-active advertising procedure. |
-| [ble_gap_conn_active](functions/ble_gap_conn_active.md) | Indicates whether a connect procedure is currently in progress. |
-| [ble_gap_conn_cancel](functions/ble_gap_conn_cancel.md) | Aborts a connect procedure in progress. |
-| [ble_gap_conn_find](functions/ble_gap_conn_find.md) | Searches for a connection with the specified handle. |
-| [ble_gap_conn_rssi](functions/ble_gap_conn_rssi.md) | Retrieves the most-recently measured RSSI for the specified connection. |
-| [ble_gap_connect](functions/ble_gap_connect.md) | Initiates a connect procedure. |
-| [ble_gap_ext_connect](functions/ble_gap_ext_connect.md) | <font color="red"> [experimental]</font> Same as above but using extended connect from Bluetooth 5. |
-| [ble_gap_disc](functions/ble_gap_disc.md) | Performs the Limited or General Discovery Procedures. |
-| [ble_gap_ext_disc](functions/ble_gap_ext_disc.md) | <font color="red"> [experimental]</font> Same as above but using extended advertising from Bluetooth 5. |
-| [ble_gap_disc_active](functions/ble_gap_disc_active.md) | Indicates whether a discovery procedure is currently in progress. |
-| [ble_gap_disc_cancel](functions/ble_gap_disc_cancel.md) | Cancels the discovery procedure currently in progress. |
-| [ble_gap_security_initiate](functions/ble_gap_security_initiate.md) | Initiates the GAP encryption procedure. |
-| [ble_gap_set_event_cb](functions/ble_gap_set_event_cb.md) | Configures a connection to use the specified GAP event callback. |
-| [ble_gap_terminate](functions/ble_gap_terminate.md) | Terminates an established connection. |
-| [ble_gap_update_params](functions/ble_gap_update_params.md) | Initiates a connection parameter update procedure. |
-| [ble_gap_wl_set](functions/ble_gap_wl_set.md) | Overwrites the controller's white list with the specified contents. |
-| [ble_gap_set_priv_mode](functions/ble_gap_set_priv_mode.md) | Set privacy mode for peer device. |
-| [ble_gap_read_le_phy](functions/ble_gap_read_le_phy.md) | Read PHY on the connections. |
-| [ble_gap_set_prefered_default_le_phy](functions/ble_gap_set_prefered_default_le_phy.md) | Set default prefered PHY mode for new connections. |
-| [ble_gap_set_prefered_le_phy](functions/ble_gap_set_prefered_le_phy.md) | Set prefered PHY mode for the connections. |
diff --git a/docs/network/ble/ble_hs/ble_gap/definitions/ble_gap_defs.md b/docs/network/ble/ble_hs/ble_gap/definitions/ble_gap_defs.md
deleted file mode 100644
index 7f8606c..0000000
--- a/docs/network/ble/ble_hs/ble_gap/definitions/ble_gap_defs.md
+++ /dev/null
@@ -1,582 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">GAP events</font>
-
-```c
-typedef int ble_gap_event_fn(struct ble_gap_event *ctxt, void *arg);
-```
-
-```c
-#define BLE_GAP_EVENT_CONNECT 0
-#define BLE_GAP_EVENT_DISCONNECT 1
-#define BLE_GAP_EVENT_CONN_CANCEL 2
-#define BLE_GAP_EVENT_CONN_UPDATE 3
-#define BLE_GAP_EVENT_CONN_UPDATE_REQ 4
-#define BLE_GAP_EVENT_L2CAP_UPDATE_REQ 5
-#define BLE_GAP_EVENT_TERM_FAILURE 6
-#define BLE_GAP_EVENT_DISC 7
-#define BLE_GAP_EVENT_DISC_COMPLETE 8
-#define BLE_GAP_EVENT_ADV_COMPLETE 9
-#define BLE_GAP_EVENT_ENC_CHANGE 10
-#define BLE_GAP_EVENT_PASSKEY_ACTION 11
-#define BLE_GAP_EVENT_NOTIFY_RX 12
-#define BLE_GAP_EVENT_NOTIFY_TX 13
-#define BLE_GAP_EVENT_SUBSCRIBE 14
-#define BLE_GAP_EVENT_MTU 15
-#define BLE_GAP_EVENT_IDENTITY_RESOLVED 16
-#define BLE_GAP_EVENT_REPEAT_PAIRING 17
-```
-
-```c
-/**
- * Represents a GAP-related event. When such an event occurs, the host
- * notifies the application by passing an instance of this structure to an
- * application-specified callback.
- */
-struct ble_gap_event {
- /**
- * Indicates the type of GAP event that occurred. This is one of the
- * BLE_GAP_EVENT codes.
- */
- uint8_t type;
-
- /**
- * A discriminated union containing additional details concerning the GAP
- * event. The 'type' field indicates which member of the union is valid.
- */
- union {
- /**
- * Represents a connection attempt. Valid for the following event
- * types:
- * o BLE_GAP_EVENT_CONNECT
- */
- struct {
- /**
- * The status of the connection attempt;
- * o 0: the connection was successfully established.
- * o BLE host error code: the connection attempt failed for
- * the specified reason.
- */
- int status;
-
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
- } connect;
-
- /**
- * Represents a terminated connection. Valid for the following event
- * types:
- * o BLE_GAP_EVENT_DISCONNECT
- */
- struct {
- /**
- * A BLE host return code indicating the reason for the
- * disconnect.
- */
- int reason;
-
- /** Information about the connection prior to termination. */
- struct ble_gap_conn_desc conn;
- } disconnect;
-
- /**
- * Represents an advertising report received during a discovery
- * procedure. Valid for the following event types:
- * o BLE_GAP_EVENT_DISC
- */
- struct ble_gap_disc_desc disc;
-
-#if MYNEWT_VAL(BLE_EXT_ADV)
- /**
- * Represents an extended advertising report received during a discovery
- * procedure. Valid for the following event types:
- * o BLE_GAP_EVENT_EXT_DISC
- */
- struct ble_gap_ext_disc_desc ext_disc;
-#endif
- /**
- * Represents an attempt to update a connection's parameters. If the
- * attempt was successful, the connection's descriptor reflects the
- * updated parameters.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_CONN_UPDATE
- */
- struct {
- /**
- * The result of the connection update attempt;
- * o 0: the connection was successfully updated.
- * o BLE host error code: the connection update attempt failed
- * for the specified reason.
- */
- int status;
-
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
- } conn_update;
-
- /**
- * Represents a peer's request to update the connection parameters.
- * This event is generated when a peer performs any of the following
- * procedures:
- * o L2CAP Connection Parameter Update Procedure
- * o Link-Layer Connection Parameters Request Procedure
- *
- * To reject the request, return a non-zero HCI error code. The value
- * returned is the reject reason given to the controller.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_L2CAP_UPDATE_REQ
- * o BLE_GAP_EVENT_CONN_UPDATE_REQ
- */
- struct {
- /**
- * Indicates the connection parameters that the peer would like to
- * use.
- */
- const struct ble_gap_upd_params *peer_params;
-
- /**
- * Indicates the connection parameters that the local device would
- * like to use. The application callback should fill this in. By
- * default, this struct contains the requested parameters (i.e.,
- * it is a copy of 'peer_params').
- */
- struct ble_gap_upd_params *self_params;
-
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
- } conn_update_req;
-
- /**
- * Represents a failed attempt to terminate an established connection.
- * Valid for the following event types:
- * o BLE_GAP_EVENT_TERM_FAILURE
- */
- struct {
- /**
- * A BLE host return code indicating the reason for the failure.
- */
- int status;
-
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
- } term_failure;
-
- /**
- * Represents an attempt to change the encrypted state of a
- * connection. If the attempt was successful, the connection
- * descriptor reflects the updated encrypted state.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_ENC_CHANGE
- */
- struct {
- /**
- * Indicates the result of the encryption state change attempt;
- * o 0: the encrypted state was successfully updated;
- * o BLE host error code: the encryption state change attempt
- * failed for the specified reason.
- */
- int status;
-
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
- } enc_change;
-
- /**
- * Represents a passkey query needed to complete a pairing procedure.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_PASSKEY_ACTION
- */
- struct {
- /** Contains details about the passkey query. */
- struct ble_gap_passkey_params params;
-
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
- } passkey;
-
- /**
- * Represents a received ATT notification or indication.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_NOTIFY_RX
- */
- struct {
- /**
- * The contents of the notification or indication. If the
- * application wishes to retain this mbuf for later use, it must
- * set this pointer to NULL to prevent the stack from freeing it.
- */
- struct os_mbuf *om;
-
- /** The handle of the relevant ATT attribute. */
- uint16_t attr_handle;
-
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
-
- /**
- * Whether the received command is a notification or an
- * indication;
- * o 0: Notification;
- * o 1: Indication.
- */
- uint8_t indication:1;
- } notify_rx;
-
- /**
- * Represents a transmitted ATT notification or indication, or a
- * completed indication transaction.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_NOTIFY_TX
- */
- struct {
- /**
- * The status of the notification or indication transaction;
- * o 0: Command successfully sent;
- * o BLE_HS_EDONE: Confirmation (indication ack) received;
- * o BLE_HS_ETIMEOUT: Confirmation (indication ack) never
- * received;
- * o Other return code: Error.
- */
- int status;
-
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
-
- /** The handle of the relevant characterstic value. */
- uint16_t attr_handle;
-
- /**
- * Whether the transmitted command is a notification or an
- * indication;
- * o 0: Notification;
- * o 1: Indication.
- */
- uint8_t indication:1;
- } notify_tx;
-
- /**
- * Represents a state change in a peer's subscription status. In this
- * comment, the term "update" is used to refer to either a notification
- * or an indication. This event is triggered by any of the following
- * occurrences:
- * o Peer enables or disables updates via a CCCD write.
- * o Connection is about to be terminated and the peer is
- * subscribed to updates.
- * o Peer is now subscribed to updates after its state was restored
- * from persistence. This happens when bonding is restored.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_SUBSCRIBE
- */
- struct {
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
-
- /** The value handle of the relevant characteristic. */
- uint16_t attr_handle;
-
- /** One of the BLE_GAP_SUBSCRIBE_REASON codes. */
- uint8_t reason;
-
- /** Whether the peer was previously subscribed to notifications. */
- uint8_t prev_notify:1;
-
- /** Whether the peer is currently subscribed to notifications. */
- uint8_t cur_notify:1;
-
- /** Whether the peer was previously subscribed to indications. */
- uint8_t prev_indicate:1;
-
- /** Whether the peer is currently subscribed to indications. */
- uint8_t cur_indicate:1;
- } subscribe;
-
- /**
- * Represents a change in an L2CAP channel's MTU.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_MTU
- */
- struct {
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
-
- /**
- * Indicates the channel whose MTU has been updated; either
- * BLE_L2CAP_CID_ATT or the ID of a connection-oriented channel.
- */
- uint16_t channel_id;
-
- /* The channel's new MTU. */
- uint16_t value;
- } mtu;
-
- /**
- * Represents a change in peer's identity. This is issued after
- * successful pairing when Identity Address Information was received.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_IDENTITY_RESOLVED
- */
- struct {
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
- } identity_resolved;
-
- /**
- * Represents a peer's attempt to pair despite a bond already existing.
- * The application has two options for handling this event type:
- * o Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the
- * conflicting bond. The stack will verify the bond has
- * been deleted and continue the pairing procedure. If
- * the bond is still present, this event will be reported
- * again.
- * o Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE. The stack will
- * silently ignore the pairing request.
- *
- * Valid for the following event types:
- * o BLE_GAP_EVENT_REPEAT_PAIRING
- */
- struct ble_gap_repeat_pairing repeat_pairing;
-
- /**
- * Represents a change of PHY. This is issue after successful
- * change on PHY.
- */
- struct {
- int status;
- uint16_t conn_handle;
-
- /**
- * Indicates enabled TX/RX PHY. Possible values:
- * o BLE_GAP_LE_PHY_1M
- * o BLE_GAP_LE_PHY_2M
- * o BLE_GAP_LE_PHY_CODED
- */
- uint8_t tx_phy;
- uint8_t rx_phy;
- } phy_updated;
- };
-};
-```
-
-```c
-#define BLE_GAP_CONN_MODE_NON 0
-#define BLE_GAP_CONN_MODE_DIR 1
-#define BLE_GAP_CONN_MODE_UND 2
-```
-
-```c
-#define BLE_GAP_DISC_MODE_NON 0
-#define BLE_GAP_DISC_MODE_LTD 1
-#define BLE_GAP_DISC_MODE_GEN 2
-```
-
-```c
-/*** Reason codes for the subscribe GAP event. */
-
-/** Peer's CCCD subscription state changed due to a descriptor write. */
-#define BLE_GAP_SUBSCRIBE_REASON_WRITE 1
-
-/** Peer's CCCD subscription state cleared due to connection termination. */
-#define BLE_GAP_SUBSCRIBE_REASON_TERM 2
-
-/**
- * Peer's CCCD subscription state changed due to restore from persistence
- * (bonding restored).
- */
-#define BLE_GAP_SUBSCRIBE_REASON_RESTORE 3
-```
-
-```c
-struct ble_gap_sec_state {
- unsigned encrypted:1;
- unsigned authenticated:1;
- unsigned bonded:1;
- unsigned key_size:5;
-};
-```
-
-```c
-/**
- * conn_mode: One of the following constants:
- * o BLE_GAP_CONN_MODE_NON
- * (non-connectable; 3.C.9.3.2).
- * o BLE_GAP_CONN_MODE_DIR
- * (directed-connectable; 3.C.9.3.3).
- * o BLE_GAP_CONN_MODE_UND
- * (undirected-connectable; 3.C.9.3.4).
- * disc_mode: One of the following constants:
- * o BLE_GAP_DISC_MODE_NON
- * (non-discoverable; 3.C.9.2.2).
- * o BLE_GAP_DISC_MODE_LTD
- * (limited-discoverable; 3.C.9.2.3).
- * o BLE_GAP_DISC_MODE_GEN
- * (general-discoverable; 3.C.9.2.4).
- */
-struct ble_gap_adv_params {
- /*** Mandatory fields. */
- uint8_t conn_mode;
- uint8_t disc_mode;
-
- /*** Optional fields; assign 0 to make the stack calculate them. */
- uint16_t itvl_min;
- uint16_t itvl_max;
- uint8_t channel_map;
- uint8_t filter_policy;
- uint8_t high_duty_cycle:1;
-};
-```
-
-```c
-#define BLE_GAP_ROLE_MASTER 0
-#define BLE_GAP_ROLE_SLAVE 1
-```
-
-```c
-struct ble_gap_conn_desc {
- struct ble_gap_sec_state sec_state;
- ble_addr_t our_id_addr;
- ble_addr_t peer_id_addr;
- ble_addr_t our_ota_addr;
- ble_addr_t peer_ota_addr;
- uint16_t conn_handle;
- uint16_t conn_itvl;
- uint16_t conn_latency;
- uint16_t supervision_timeout;
- uint8_t role;
- uint8_t master_clock_accuracy;
-};
-```
-
-```c
-
-struct ble_gap_conn_params {
- uint16_t scan_itvl;
- uint16_t scan_window;
- uint16_t itvl_min;
- uint16_t itvl_max;
- uint16_t latency;
- uint16_t supervision_timeout;
- uint16_t min_ce_len;
- uint16_t max_ce_len;
-};
-```
-
-```c
-struct ble_gap_ext_disc_params {
- uint16_t itvl;
- uint16_t window;
- uint8_t passive:1;
-};
-```
-
-```c
-struct ble_gap_disc_params {
- uint16_t itvl;
- uint16_t window;
- uint8_t filter_policy;
- uint8_t limited:1;
- uint8_t passive:1;
- uint8_t filter_duplicates:1;
-};
-```
-
-```c
-struct ble_gap_upd_params {
- uint16_t itvl_min;
- uint16_t itvl_max;
- uint16_t latency;
- uint16_t supervision_timeout;
- uint16_t min_ce_len;
- uint16_t max_ce_len;
-};
-```
-
-```c
-struct ble_gap_passkey_params {
- uint8_t action;
- uint32_t numcmp;
-};
-```
-
-```c
-struct ble_gap_disc_desc {
- /*** Common fields. */
- uint8_t event_type;
- uint8_t length_data;
- ble_addr_t addr;
- int8_t rssi;
- uint8_t *data;
-
- /***
- * LE direct advertising report fields; direct_addr is BLE_ADDR_ANY if
- * direct address fields are not present.
- */
- ble_addr_t direct_addr;
-};
-```
-
-```c
-struct ble_gap_repeat_pairing {
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
-
- /** Properties of the existing bond. */
- uint8_t cur_key_size;
- uint8_t cur_authenticated:1;
- uint8_t cur_sc:1;
-
- /**
- * Properties of the imminent secure link if the pairing procedure is
- * allowed to continue.
- */
- uint8_t new_key_size;
- uint8_t new_authenticated:1;
- uint8_t new_sc:1;
- uint8_t new_bonding:1;
-};
-```
-
-```c
-struct ble_gap_disc_desc {
- /*** Common fields. */
- uint8_t event_type;
- uint8_t length_data;
- ble_addr_t addr;
- int8_t rssi;
- uint8_t *data;
-
- /***
- * LE direct advertising report fields; direct_addr is BLE_ADDR_ANY if
- * direct address fields are not present.
- */
- ble_addr_t direct_addr;
-};
-```
-
-```c
-struct ble_gap_repeat_pairing {
- /** The handle of the relevant connection. */
- uint16_t conn_handle;
-
- /** Properties of the existing bond. */
- uint8_t cur_key_size;
- uint8_t cur_authenticated:1;
- uint8_t cur_sc:1;
-
- /**
- * Properties of the imminent secure link if the pairing procedure is
- * allowed to continue.
- */
- uint8_t new_key_size;
- uint8_t new_authenticated:1;
- uint8_t new_sc:1;
- uint8_t new_bonding:1;
-};
-```
-
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_active.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_active.md
deleted file mode 100644
index e4985f4..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_active.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_active</font>
-
-```c
-int
-ble_gap_adv_active(void)
-```
-
-### Description
-
-Indicates whether an advertisement procedure is currently in progress.
-
-### Parameters
-
-None
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | No advertisement procedure in progress. |
-| 1 | Advertisement procedure in progress. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_data.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_data.md
deleted file mode 100644
index e4610dc..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_data.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_rsp\_set\_data</font>
-
-```c
-int
-ble_gap_adv_rsp_set_data(
- const uint8_t *data,
- int data_len
-)
-```
-
-### Description
-
-Configures the data to include in subsequent scan responses.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| data | Buffer containing the scan response data. |
-| data\_len | The size of the response data, in bytes. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EBUSY | Advertising is in progress. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_fields.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_fields.md
deleted file mode 100644
index f34044d..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_fields.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_rsp\_set\_fields</font>
-
-```c
-int
-ble_gap_adv_rsp_set_fields(const struct ble_hs_adv_fields *rsp_fields)
-```
-
-### Description
-
-Configures the fields to include in subsequent scan responses. This is a convenience wrapper for ble\_gap\_adv\_rsp\_set\_data().
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| adv\_fields | Specifies the scan response data. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EBUSY | Advertising is in progress. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_data.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_data.md
deleted file mode 100644
index 69c765c..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_data.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_set\_data</font>
-
-```c
-int
-ble_gap_adv_set_data(
- const uint8_t *data,
- int data_len
-)
-```
-
-### Description
-
-Configures the data to include in subsequent advertisements.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| data | Buffer containing the advertising data. |
-| data\_len | The size of the advertising data, in bytes. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EBUSY | Advertising is in progress. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields.md
deleted file mode 100644
index 1c5aa3c..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_set\_fields</font>
-
-```c
-int
-ble_gap_adv_set_fields(const struct ble_hs_adv_fields *adv_fields)
-```
-
-### Description
-
-Configures the fields to include in subsequent advertisements. This is a convenience wrapper for ble\_gap\_adv\_set\_data().
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| adv\_fields | Specifies the advertisement data. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EBUSY | Advertising is in progress. |
-| BLE\_HS\_EMSGSIZE | The specified data is too large to fit in an advertisement. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_phys.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_phys.md
deleted file mode 100644
index dfbab85..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_phys.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_set\_phys</font><font color="red" style="font-size:18pt"> [experimental] </font>
-
-```c
-int
-ble_gap_adv_set_phys(uint8_t primary_phy, uint8_t secondary_phy)
-```
-
-### Description
-
-Set primary and secondary PHYs for extended advertising procedure.
-
-### Parameters
-
-None
-
-| *Parameter* | *Description* |
-|---------------|-----------------------------------------------------------------------------------------------------------------|
-| primary_phy | Primary PHY to use for extended advertising procedure. <ul><li>BLE\_HCI\_LE\_1M</li> <li>BLE\_HCI\_LE\_CODED</li></ul> |
-| secondary_phy | Secondary PHY to use for extended advertising procedure. <ul><li>BLE\_HCI\_LE\_1M</li> <li>BLE\_HCI\_LE\_2M</li> <li>BLE\_HCI\_LE\_CODED</li></ul> |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_tx_power.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_tx_power.md
deleted file mode 100644
index 8d2d6af..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_tx_power.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_set\_tx\_power</font><font color="red" style="font-size:18pt"> [experimental] </font>
-
-```c
-int
-ble_gap_adv_set_tx_power(int8_t tx_power)
-```
-
-### Description
-
-Set Tx Power level for extended advertising procedure.
-
-### Parameters
-
-None
-
-| *Parameter* | *Description* |
-|-------------|-----------------------------------------------------------|
-| tx_power | Tx Power level to use for extended advertising procedure. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md
deleted file mode 100644
index 1784a16..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_start</font>
-
-```c
-int
-ble_gap_adv_start(
- uint8_t own_addr_type,
- const ble_addr_t *direct_addr,
- int32_t duration_ms,
- const struct ble_gap_adv_params *adv_params,
- ble_gap_event_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates advertising.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| own\_addr\_type | The type of address the stack should use for itself. Valid values are: <ul><li>BLE\_OWN\_ADDR\_PUBLIC</li> <li>BLE\_OWN\_ADDR\_RANDOM</li> <li>BLE\_OWN\_ADDR\_RPA\_PUBLIC\_DEFAULT</li> <li>BLE\_OWN\_ADDR\_RPA\_RANDOM\_DEFAULT</li></ul> |
-| direct\_addr | The peer's address for directed advertising. This parameter shall be non-NULL if directed advertising is being used. |
-| duration\_ms | The duration of the advertisement procedure. On expiration, the procedure ends and a BLE\_GAP\_EVENT\_ADV\_COMPLETE event is reported. Units are milliseconds. Specify BLE\_HS\_FOREVER for no expiration. |
-| adv\_params | Additional arguments specifying the particulars of the advertising procedure. |
-| cb | The callback to associate with this advertising procedure. If advertising ends, the event is reported through this callback. If advertising results in a connection, the connection inherits this callback as its event-reporting mechanism. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_stop.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_stop.md
deleted file mode 100644
index 894285c..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_stop.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_adv\_stop</font>
-
-```c
-int
-ble_gap_adv_stop(void)
-```
-
-### Description
-
-Stops the currently-active advertising procedure. A success return code indicates that advertising has been fully aborted; a new advertising procedure can be initiated immediately.
-
-### Parameters
-
-None
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EALREADY | There is no active advertising procedure. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_active.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_active.md
deleted file mode 100644
index a8991af..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_active.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_conn\_active</font>
-
-```c
-int
-ble_gap_conn_active(void)
-```
-
-### Description
-
-Indicates whether a connect procedure is currently in progress.
-
-### Parameters
-
-None
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | No connect procedure in progress. |
-| 1 | Connect procedure in progress. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_cancel.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_cancel.md
deleted file mode 100644
index 6855b8d..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_cancel.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_conn\_cancel</font>
-
-```c
-int
-ble_gap_conn_cancel(void)
-```
-
-### Description
-
-Aborts a connect procedure in progress.
-
-### Parameters
-
-None
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_find.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_find.md
deleted file mode 100644
index 23e79f0..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_find.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_conn\_find</font>
-
-```c
-int
-ble_gap_conn_find(
- uint16_t handle,
- struct ble_gap_conn_desc *out_desc
-)
-```
-
-### Description
-
-Searches for a connection with the specified handle. If a matching connection is found, the supplied connection descriptor is filled correspondingly.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| handle | The connection handle to search for. |
-| out\_desc | On success, this is populated with information relating to the matching connection. Pass NULL if you don't need this information. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOTCONN | No matching connection was found. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_rssi.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_rssi.md
deleted file mode 100644
index 563252f..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_conn_rssi.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_conn\_rssi</font>
-
-```c
-int
-ble_gap_conn_rssi(
- uint16_t conn_handle,
- int8_t *out_rssi
-)
-```
-
-### Description
-
-Retrieves the most-recently measured RSSI for the specified connection. A connection's RSSI is updated whenever a data channel PDU is received.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | Specifies the connection to query. |
-| out\_rssi | On success, the retrieved RSSI is written here. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [HCI return code](../../ble_hs_return_codes/#return-codes-hci) | The controller rejected the request. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_connect.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_connect.md
deleted file mode 100644
index 98b2a92..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_connect.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_connect</font>
-
-```c
-int
-ble_gap_connect(
- uint8_t own_addr_type,
- const ble_addr_t *peer_addr,
- int32_t duration_ms,
- const struct ble_gap_conn_params *conn_params,
- ble_gap_event_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates a connect procedure.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| own\_addr\_type | The type of address the stack should use for itself during connection establishment. <ul><li>BLE\_OWN\_ADDR\_PUBLIC</li> <li>BLE\_OWN\_ADDR\_RANDOM</li> <li>BLE\_OWN\_ADDR\_RPA\_PUBLIC\_DEFAULT</li> <li>BLE\_OWN\_ADDR\_RPA\_RANDOM\_DEFAULT</li></ul> |
-| peer\_addr | The address of the peer to connect to. If this parameter is NULL, the white list is used. |
-| duration\_ms | The duration of the discovery procedure. On expiration, the procedure ends and a BLE\_GAP\_EVENT\_DISC\_COMPLETE event is reported. Units are milliseconds. |
-| conn\_params | Additional arguments specifying the particulars of the connect procedure. Specify null for default values. |
-| cb | The callback to associate with this connect procedure. When the connect procedure completes, the result is reported through this callback. If the connect procedure succeeds, the connection inherits this callback as its event-reporting mechanism. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EALREADY | A connection attempt is already in progress. |
-| BLE\_HS\_EBUSY | Initiating a connection is not possible because scanning is in progress. |
-| BLE\_HS\_EDONE | The specified peer is already connected. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc.md
deleted file mode 100644
index dead01a..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_disc</font>
-
-```c
-int
-ble_gap_disc(
- uint8_t own_addr_type,
- int32_t duration_ms,
- const struct ble_gap_disc_params *disc_params,
- ble_gap_event_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Performs the Limited or General Discovery Procedures.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| own\_addr\_type | The type of address the stack should use for itself when sending scan requests. Valid values are: <ul><li>BLE\_ADDR\_TYPE\_PUBLIC</li> <li>BLE\_ADDR\_TYPE\_RANDOM</li> <li>BLE\_ADDR\_TYPE\_RPA\_PUB\_DEFAULT</li> <li>BLE\_ADDR\_TYPE\_RPA\_RND\_DEFAULT</li></ul> This parameter is ignored unless active scanning is being used. |
-| duration\_ms | The duration of the discovery procedure. On expiration, the procedure ends and a BLE\_GAP\_EVENT\_DISC\_COMPLETE event is reported. Units are milliseconds. Specify BLE\_HS\_FOREVER for no expiration. |
-| disc\_params | Additional arguments specifying the particulars of the discovery procedure. |
-| cb | The callback to associate with this discovery procedure. Advertising reports and discovery termination events are reported through this callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc_active.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc_active.md
deleted file mode 100644
index 3c3d1c9..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc_active.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_disc\_active</font>
-
-```c
-int
-ble_gap_disc_active(void)
-```
-
-### Description
-
-Indicates whether a discovery procedure is currently in progress.
-
-### Parameters
-
-None
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | No discovery procedure in progress. |
-| 1 | Discovery procedure in progress. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc_cancel.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc_cancel.md
deleted file mode 100644
index 58def57..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_disc_cancel.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_disc\_cancel</font>
-
-```c
-int
-ble_gap_disc_cancel(void)
-```
-
-### Description
-
-Cancels the discovery procedure currently in progress. A success return code indicates that scanning has been fully aborted; a new discovery or connect procedure can be initiated immediately.
-
-### Parameters
-
-None
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EALREADY | There is no discovery procedure to cancel. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_ext_connect.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_ext_connect.md
deleted file mode 100644
index 2e97a87..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_ext_connect.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_ext\_connect</font><font color="red" style="font-size:18pt"> [experimental] </font>
-
-```c
-int
-ble_gap_ext_connect(
- uint8_t own_addr_type,
- const ble_addr_t *peer_addr,
- int32_t duration_ms,
- uint8_t phy_mask,
- const struct ble_gap_conn_params *phy_1m_conn_params,
- const struct ble_gap_conn_params *phy_2m_conn_params,
- const struct ble_gap_conn_params *phy_coded_conn_params,
- ble_gap_event_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates a connect procedure.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| own\_addr\_type | The type of address the stack should use for itself during connection establishment. <ul><li>BLE\_ADDR\_TYPE\_PUBLIC</li> <li>BLE\_ADDR\_TYPE\_RANDOM</li> <li>BLE\_ADDR\_TYPE\_RPA\_PUB\_DEFAULT</li> <li>BLE\_ADDR\_TYPE\_RPA\_RND\_DEFAULT</li></ul> |
-| peer\_addr | The identity address of the peer to connect to. White list is used when this parameters is set to NULL. |
-| duration\_ms | The duration of the discovery procedure. On expiration, the procedure ends and a BLE\_GAP\_EVENT\_DISC\_COMPLETE event is reported. Units are milliseconds. |
-| phy\_mask | Define on which PHYs connection attempt should be done |
-| phy\_1m\_conn\_params | Additional arguments specifying the particulars of the connect procedure. When BLE_GAP_LE_PHY_1M_MASK is set in phy_mask this parameter can be specify to null for default values. |
-| phy\_2m\_conn\_params | Additional arguments specifying the particulars of the connect procedure. When BLE_GAP_LE_PHY_2M_MASK is set in phy_mask this parameter can be specify to null for default values. |
-| phy\_coded\_conn\_params | Additional arguments specifying the particulars of the connect procedure. When BLE_GAP_LE_PHY_CODED_MASK is set in phy_mask this parameter can be specify to null for default values. |
-| cb | The callback to associate with this connect procedure. When the connect procedure completes, the result is reported through this callback. If the connect procedure succeeds, the connection inherits this callback as its event-reporting mechanism. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_ext_disc.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_ext_disc.md
deleted file mode 100644
index 96e6167..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_ext_disc.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_ext\_disc </font> <font color="red" style="font-size:18pt"> [experimental] </font>
-
-```c
-int
-ble_gap_ext_disc(
- uint8_t own_addr_type,
- uint16_t duration,
- uint16_t period,
- uint8_t filter_duplicates,
- uint8_t filter_policy,
- uint8_t limited,
- const struct ble_gap_ext_disc_params *uncoded_params,
- const struct ble_gap_ext_disc_params *coded_params
- const struct ble_gap_disc_params *disc_params,
- ble_gap_event_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Performs the Limited or General Discovery Procedures.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| own\_addr\_type | The type of address the stack should use for itself when sending scan requests. Valid values are: <ul><li>BLE\_ADDR\_TYPE\_PUBLIC</li> <li>BLE\_ADDR\_TYPE\_RANDOM</li> <li>BLE\_ADDR\_TYPE\_RPA\_PUB\_DEFAULT</li> <li>BLE\_ADDR\_TYPE\_RPA\_RND\_DEFAULT</li></ul> This parameter is ignored unless active scanning is being used. |
-| duration | The duration of the discovery procedure. On expiration, the procedure ends and a BLE\_GAP\_EVENT\_DISC\_COMPLETE event is reported. Unit is 10ms. Specify 0 for no expiration. |
-| period | Time interval between each scan (valid when duration non-zero). |
-| filter\_duplicates | Filter duplicates flag. |
-| filter\_policy | Filter policy as specified by Bluetooth specification. |
-| limited | Enables limited discovery. |
-| uncoded\_params | Additional arguments specifying the particulars of the discovery procedure for uncoded PHY. Specify NULL if discovery is not needed on uncoded PHY |
-| coded\_params | Additional arguments specifying the particulars of the discovery procedure for coded PHY. Specify NULL if discovery os not needed on coded PHY |
-| cb | The callback to associate with this discovery procedure. Advertising reports and discovery termination events are reported through this callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_read_le_phy.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_read_le_phy.md
deleted file mode 100644
index 23a42a9..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_read_le_phy.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_read\_le\_phy</font>
-
-```c
-int
-ble_gap_read_le_phy(
- uint16_t conn_handle,
- uint8_t *tx_phy,
- uint8_t *rx_phy
-)
-```
-
-### Description
-
-Read PHY on given connection.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The handle corresponding to the connection to on which PHY is read. |
-| tx\_phy | Tx PHY. One of: <ul><li>BLE\_GAP\_LE\_PHY\_1M</li> <li>BLE\_GAP\_LE\_PHY\_2M</li><li>BLE\_GAP\_LE\_PHY\_CODED</li></ul> |
-| rx\_phy | Rx PHY. One of: <ul><li>BLE\_GAP\_LE\_PHY\_1M</li> <li>BLE\_GAP\_LE\_PHY\_2M</li><li>BLE\_GAP\_LE\_PHY\_CODED</li></ul> |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_security_initiate.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_security_initiate.md
deleted file mode 100644
index 3650983..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_security_initiate.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_security\_initiate</font>
-
-```c
-int
-ble_gap_security_initiate(uint16_t conn_handle)
-```
-
-### Description
-
-Initiates the GAP encryption procedure.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The handle corresponding to the connection to encrypt. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOTCONN | The there is no connection with the specified handle. |
-| BLE\_HS\_EALREADY | An encrpytion procedure for this connection is already in progress. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_event_cb.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_event_cb.md
deleted file mode 100644
index 1f0475a..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_event_cb.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_set\_event\_cb</font>
-
-```c
-int
-ble_gap_set_event_cb(
- uint16_t conn_handle,
- ble_gap_event_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Configures a connection to use the specified GAP event callback. A connection's GAP event callback is first specified when the connection is created, either via advertising or initiation. This function replaces the callback that was last configured.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The handle of the connection to configure. |
-| cb | The callback to associate with the connection. |
-| cb\_arg | An optional argument that the callback receives. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOTCONN | There is no connection with the specified handle. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_prefered_default_le_phy.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_prefered_default_le_phy.md
deleted file mode 100644
index d03fba6..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_prefered_default_le_phy.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_set\_prefered\_default\_le\_phy</font>
-
-```c
-int
-ble_gap_set_prefered_default_le_phy(
- uint8_t tx_phys_mask,
- uint8_t rx_phys_mask
-)
-```
-
-### Description
-
-Set prefered default LE PHY mask. It is used for new connections.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| tx\_phys\_mask | Prefered tx PHY mask is a bit mask of: <ul><li>BLE\_GAP\_LE\_PHY\_1M\_MASK</li> <li>BLE\_GAP\_LE\_PHY\_2M\_MASK</li><li>BLE\_GAP\_LE\_PHY\_CODED\_MASK</li></ul> |
-| rx\_phys\_mask | Prefered rx PHY mask is a bit mask of: <ul><li>BLE\_GAP\_LE\_PHY\_1M\_MASK</li> <li>BLE\_GAP\_LE\_PHY\_2M\_MASK</li><li>BLE\_GAP\_LE\_PHY\_CODED\_MASK</li></ul> |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_prefered_le_phy.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_prefered_le_phy.md
deleted file mode 100644
index b12ab2d..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_prefered_le_phy.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_set\_prefered\_le\_phy</font>
-
-```c
-int
-ble_gap_set_prefered_le_phy(
- uint16_t conn_handle,
- uint8_t tx_phys_mask,
- uint8_t rx_phys_mask,
- uint16_t phy_opts
-)
-```
-
-### Description
-
-Set prefered LE PHY mask for given connection.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The handle corresponding to the connection where new PHY mask should be applied. |
-| tx\_phys\_mask | Prefered tx PHY mask is a bit mask of: <ul><li>BLE\_GAP\_LE\_PHY\_1M\_MASK</li> <li>BLE\_GAP\_LE\_PHY\_2M\_MASK</li><li>BLE\_GAP\_LE\_PHY\_CODED\_MASK</li></ul> |
-| rx\_phys\_mask | Prefered rx PHY mask is a bit mask of: <ul><li>BLE\_GAP\_LE\_PHY\_1M\_MASK</li> <li>BLE\_GAP\_LE\_PHY\_2M\_MASK</li><li>BLE\_GAP\_LE\_PHY\_CODED\_MASK</li></ul> |
-| phy\_opts | PHY options for coded PHY. One of: <ul><li>BLE\_GAP\_LE\_PHY\_CODED\_ANY</li> <li>BLE\_GAP\_LE\_PHY\_CODED\_S2</li><li>BLE\_GAP\_LE\_PHY\_CODED\_S8</li></ul> |
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_priv_mode.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_priv_mode.md
deleted file mode 100644
index 4a690b5..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_set_priv_mode.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_set\_priv\_mode</font>
-
-```c
-int
-ble_gap_set_priv_mode(
- const ble_addr_t *peer_addr,
- uint8_t priv_mode
-)
-```
-
-### Description
-
-Set privacy mode for given device.
-
- If device mode is used, then Nimble accepts both the peer's identity address and a resolvable private address.
-
- If network mode is used, then Nimble accepts only resolvable private address.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| peer\_addr | The identity address of the peer for which privacy mode shall be changed. |
-| priv\_mode | The privacy mode. One of: <ul><li>BLE\_GAP\_PRIVATE\_MODE\_NETWORK</li> <li>BLE\_GAP\_PRIVATE\_MODE\_DEVICE</li> </ul> |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_terminate.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_terminate.md
deleted file mode 100644
index ad81d5c..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_terminate.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_terminate</font>
-
-```c
-int
-ble_gap_terminate(
- uint16_t conn_handle,
- uint8_t hci_reason
-)
-```
-
-### Description
-
-Terminates an established connection.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The handle corresponding to the connection to terminate. |
-| hci\_reason | The HCI error code to indicate as the reason for termination. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOTCONN | There is no connection with the specified handle. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_update_params.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_update_params.md
deleted file mode 100644
index b97c7f9..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_update_params.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_update\_params</font>
-
-```c
-int
-ble_gap_update_params(
- uint16_t conn_handle,
- const struct ble_gap_upd_params *params
-)
-```
-
-### Description
-
-Initiates a connection parameter update procedure.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The handle corresponding to the connection to update. |
-| params | The connection parameters to attempt to update to. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOTCONN | The there is no connection with the specified handle. |
-| BLE\_HS\_EALREADY | A connection update procedure for this connection is already in progress. |
-| BLE\_HS\_EINVAL | Requested parameters are invalid. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_wl_set.md b/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_wl_set.md
deleted file mode 100644
index fb15312..0000000
--- a/docs/network/ble/ble_hs/ble_gap/functions/ble_gap_wl_set.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gap\_wl\_set</font>
-
-```c
-int
-ble_gap_wl_set(
- const ble_addr_t *addrs,
- uint8_t white_list_count
-)
-```
-
-### Description
-
-Overwrites the controller's white list with the specified contents.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| addrs | The entries to write to the white list. |
-| white\_list\_count | The number of entries in the white list. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gap/mdtoc.md b/docs/network/ble/ble_hs/ble_gap/mdtoc.md
deleted file mode 100644
index 2b27c66..0000000
--- a/docs/network/ble/ble_hs/ble_gap/mdtoc.md
+++ /dev/null
@@ -1,26 +0,0 @@
- - 'GAP':
- - toc: 'network/ble/ble_hs/ble_gap/ble_gap.md'
- - 'Definitions':
- - 'GAP definitions': 'network/ble/ble_hs/ble_gap/definitions/ble_gap_defs.md'
- - 'Functions':
- - 'ble_gap_adv_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_active.md'
- - 'ble_gap_adv_rsp_set_data': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_data.md'
- - 'ble_gap_adv_rsp_set_fields': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_fields.md'
- - 'ble_gap_adv_set_data': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_data.md'
- - 'ble_gap_adv_set_fields': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields.md'
- - 'ble_gap_adv_set_phys': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_phys.md'
- - 'ble_gap_adv_start': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md'
- - 'ble_gap_adv_stop': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_stop.md'
- - 'ble_gap_conn_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_active.md'
- - 'ble_gap_conn_cancel': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_cancel.md'
- - 'ble_gap_conn_find': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_find.md'
- - 'ble_gap_conn_rssi': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_rssi.md'
- - 'ble_gap_connect': 'network/ble/ble_hs/ble_gap/functions/ble_gap_connect.md'
- - 'ble_gap_disc': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc.md'
- - 'ble_gap_disc_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc_active.md'
- - 'ble_gap_disc_cancel': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc_cancel.md'
- - 'ble_gap_security_initiate': 'network/ble/ble_hs/ble_gap/functions/ble_gap_security_initiate.md'
- - 'ble_gap_set_event_cb': 'network/ble/ble_hs/ble_gap/functions/ble_gap_set_event_cb.md'
- - 'ble_gap_terminate': 'network/ble/ble_hs/ble_gap/functions/ble_gap_terminate.md'
- - 'ble_gap_update_params': 'network/ble/ble_hs/ble_gap/functions/ble_gap_update_params.md'
- - 'ble_gap_wl_set': 'network/ble/ble_hs/ble_gap/functions/ble_gap_wl_set.md'
diff --git a/docs/network/ble/ble_hs/ble_gattc/ble_gattc.md b/docs/network/ble/ble_hs/ble_gattc/ble_gattc.md
deleted file mode 100644
index 339c9fd..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/ble_gattc.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">NimBLE Host GATT Client Reference</font>
-
-### Introduction
-
-The Generic Attribute Profile (GATT) manages all activities involving services, characteristics, and descriptors. The client half of the GATT API initiates GATT procedures.
-
-### Header
-
-```c
-#include "host/ble_hs.h"
-```
-
-### Definitions
-
-[BLE host GATT client definitions](definitions/ble_gattc_defs.md)
-
-### Functions
-
-| Function | Description |
-|----------|-------------|
-| [ble_gattc_disc_all_chrs](functions/ble_gattc_disc_all_chrs.md) | Initiates GATT procedure: Discover All Characteristics of a Service. |
-| [ble_gattc_disc_all_dscs](functions/ble_gattc_disc_all_dscs.md) | Initiates GATT procedure: Discover All Characteristic Descriptors. |
-| [ble_gattc_disc_all_svcs](functions/ble_gattc_disc_all_svcs.md) | Initiates GATT procedure: Discover All Primary Services. |
-| [ble_gattc_disc_chrs_by_uuid](functions/ble_gattc_disc_chrs_by_uuid.md) | Initiates GATT procedure: Discover Characteristics by UUID. |
-| [ble_gattc_disc_svc_by_uuid](functions/ble_gattc_disc_svc_by_uuid.md) | Initiates GATT procedure: Discover Primary Service by Service UUID. |
-| [ble_gattc_exchange_mtu](functions/ble_gattc_exchange_mtu.md) | Initiates GATT procedure: Exchange MTU. |
-| [ble_gattc_find_inc_svcs](functions/ble_gattc_find_inc_svcs.md) | Initiates GATT procedure: Find Included Services. |
-| [ble_gattc_indicate](functions/ble_gattc_indicate.md) | Sends a characteristic indication. |
-| [ble_gattc_indicate_custom](functions/ble_gattc_indicate_custom.md) | Sends a characteristic indication. |
-| [ble_gattc_notify](functions/ble_gattc_notify.md) | Sends a characteristic notification. |
-| [ble_gattc_notify_custom](functions/ble_gattc_notify_custom.md) | Sends a "free-form" characteristic notification. |
-| [ble_gattc_read](functions/ble_gattc_read.md) | Initiates GATT procedure: Read Characteristic Value. |
-| [ble_gattc_read_by_uuid](functions/ble_gattc_read_by_uuid.md) | Initiates GATT procedure: Read Using Characteristic UUID. |
-| [ble_gattc_read_long](functions/ble_gattc_read_long.md) | Initiates GATT procedure: Read Long Characteristic Values. |
-| [ble_gattc_read_mult](functions/ble_gattc_read_mult.md) | Initiates GATT procedure: Read Multiple Characteristic Values. |
-| [ble_gattc_write](functions/ble_gattc_write.md) | Initiates GATT procedure: Write Characteristic Value. |
-| [ble_gattc_write_flat](functions/ble_gattc_write_flat.md) | Initiates GATT procedure: Write Characteristic Value (flat buffer version). |
-| [ble_gattc_write_long](functions/ble_gattc_write_long.md) | Initiates GATT procedure: Write Long Characteristic Values. |
-| [ble_gattc_write_no_rsp](functions/ble_gattc_write_no_rsp.md) | Initiates GATT procedure: Write Without Response. |
-| [ble_gattc_write_no_rsp_flat](functions/ble_gattc_write_no_rsp_flat.md) | Initiates GATT procedure: Write Without Response. |
-| [ble_gattc_write_reliable](functions/ble_gattc_write_reliable.md) | Initiates GATT procedure: Reliable Writes. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/definitions/ble_gattc_defs.md b/docs/network/ble/ble_hs/ble_gattc/definitions/ble_gattc_defs.md
deleted file mode 100644
index be1aeb2..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/definitions/ble_gattc_defs.md
+++ /dev/null
@@ -1,91 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">GATT Client Definitions</font>
-
-```c
-struct ble_gatt_error {
- uint16_t status;
- uint16_t att_handle;
-};
-```
-
-```c
-struct ble_gatt_svc {
- uint16_t start_handle;
- uint16_t end_handle;
- ble_uuid_any_t uuid;
-};
-```
-
-```c
-struct ble_gatt_attr {
- uint16_t handle;
- uint16_t offset;
- struct os_mbuf *om;
-};
-```
-
-```c
-struct ble_gatt_chr {
- uint16_t def_handle;
- uint16_t val_handle;
- uint8_t properties;
- ble_uuid_any_t uuid;
-};
-```
-
-```c
-struct ble_gatt_dsc {
- uint16_t handle;
- ble_uuid_any_t uuid;
-};
-```
-
-```c
-typedef int ble_gatt_mtu_fn(uint16_t conn_handle,
- const struct ble_gatt_error *error,
- uint16_t mtu, void *arg);
-```
-
-```c
-typedef int ble_gatt_disc_svc_fn(uint16_t conn_handle,
- const struct ble_gatt_error *error,
- const struct ble_gatt_svc *service,
- void *arg);
-```
-
-```c
-/**
- * The host will free the attribute mbuf automatically after the callback is
- * executed. The application can take ownership of the mbuf and prevent it
- * from being freed by assigning NULL to attr->om.
- */
-typedef int ble_gatt_attr_fn(uint16_t conn_handle,
- const struct ble_gatt_error *error,
- struct ble_gatt_attr *attr,
- void *arg);
-```
-
-```c
-/**
- * The host will free the attribute mbufs automatically after the callback is
- * executed. The application can take ownership of the mbufs and prevent them
- * from being freed by assigning NULL to each attribute's om field.
- */
-typedef int ble_gatt_reliable_attr_fn(uint16_t conn_handle,
- const struct ble_gatt_error *error,
- struct ble_gatt_attr *attrs,
- uint8_t num_attrs, void *arg);
-```
-
-```c
-typedef int ble_gatt_chr_fn(uint16_t conn_handle,
- const struct ble_gatt_error *error,
- const struct ble_gatt_chr *chr, void *arg);
-```
-
-```c
-typedef int ble_gatt_dsc_fn(uint16_t conn_handle,
- const struct ble_gatt_error *error,
- uint16_t chr_def_handle,
- const struct ble_gatt_dsc *dsc,
- void *arg);
-```
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_chrs.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_chrs.md
deleted file mode 100644
index 0711304..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_chrs.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_disc\_all\_chrs</font>
-
-```c
-int
-ble_gattc_disc_all_chrs(
- uint16_t conn_handle,
- uint16_t start_handle,
- uint16_t end_handle,
- ble_gatt_chr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Discover All Characteristics of a Service.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| start\_handle | The handle to begin the search at (generally the service definition handle). |
-| end\_handle | The handle to end the search at (generally the last handle in the service). |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_dscs.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_dscs.md
deleted file mode 100644
index 2a262d9..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_dscs.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_disc\_all\_dscs</font>
-
-```c
-int
-ble_gattc_disc_all_dscs(
- uint16_t conn_handle,
- uint16_t start_handle,
- uint16_t end_handle,
- ble_gatt_dsc_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Discover All Characteristic Descriptors.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| chr\_val\_handle | The handle of the characteristic value attribute. |
-| chr\_end\_handle | The last handle in the characteristic definition. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_svcs.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_svcs.md
deleted file mode 100644
index 7b8fabd..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_svcs.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_disc\_all\_svcs</font>
-
-```c
-int
-ble_gattc_disc_all_svcs(
- uint16_t conn_handle,
- ble_gatt_disc_svc_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Discover All Primary Services.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-None
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_chrs_by_uuid.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_chrs_by_uuid.md
deleted file mode 100644
index 3fcd869..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_chrs_by_uuid.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_disc\_chrs\_by\_uuid</font>
-
-```c
-int
-ble_gattc_disc_chrs_by_uuid(
- uint16_t conn_handle,
- uint16_t start_handle,
- uint16_t end_handle,
- const ble_uuid_t *uuid,
- ble_gatt_chr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Discover Characteristics by UUID.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| start\_handle | The handle to begin the search at (generally the service definition handle). |
-| end\_handle | The handle to end the search at (generally the last handle in the service). |
-| chr\_uuid128 | The 128-bit UUID of the characteristic to discover. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_svc_by_uuid.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_svc_by_uuid.md
deleted file mode 100644
index 3f51298..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_svc_by_uuid.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_disc\_svc\_by\_uuid</font>
-
-```c
-int
-ble_gattc_disc_svc_by_uuid(
- uint16_t conn_handle,
- const ble_uuid_t *uuid,
- ble_gatt_disc_svc_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Discover Primary Service by Service UUID.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| service\_uuid128 | The 128-bit UUID of the service to discover. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu.md
deleted file mode 100644
index 0c9923b..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_exchange\_mtu</font>
-
-```c
-int
-ble_gattc_exchange_mtu(
- uint16_t conn_handle,
- ble_gatt_mtu_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Exchange MTU.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_find_inc_svcs.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_find_inc_svcs.md
deleted file mode 100644
index c4325a4..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_find_inc_svcs.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_find\_inc\_svcs</font>
-
-```c
-int
-ble_gattc_find_inc_svcs(
- uint16_t conn_handle,
- uint16_t start_handle,
- uint16_t end_handle,
- ble_gatt_disc_svc_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Find Included Services.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| start\_handle | The handle to begin the search at (generally the service definition handle). |
-| end\_handle | The handle to end the search at (generally the last handle in the service). |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate.md
deleted file mode 100644
index 9f07808..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_indicate</font>
-
-```c
-int
-ble_gattc_indicate(
- uint16_t conn_handle,
- uint16_t chr_val_handle
-)
-```
-
-### Description
-
-Sends a characteristic indication. The content of the message is read from the specified characteristic.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| chr\_val\_handle | The value attribute handle of the characteristic to include in the outgoing indication. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate_custom.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate_custom.md
deleted file mode 100644
index ee0ddec..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate_custom.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_indicate\_custom</font>
-
-```c
-int
-ble_gattc_indicate_custom(
- uint16_t conn_handle,
- uint16_t chr_val_handle,
- struct os_mbuf *txom
-)
-```
-
-### Description
-
-Sends a characteristic indication. The content of the message is read from the specified characteristic.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| chr\_val\_handle | The value attribute handle of the characteristic to include in the outgoing indication. |
-| txom | The data to include in the indication. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify.md
deleted file mode 100644
index 42bc0a8..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_notify</font>
-
-```c
-int
-ble_gattc_notify(
- uint16_t conn_handle,
- uint16_t chr_val_handle
-)
-```
-
-### Description
-
-Sends a characteristic notification. The content of the message is read from the specified characteristic.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| chr\_val\_handle | The value attribute handle of the characteristic to include in the outgoing notification. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify_custom.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify_custom.md
deleted file mode 100644
index ad80b53..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify_custom.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_notify\_custom</font>
-
-```c
-int
-ble_gattc_notify_custom(
- uint16_t conn_handle,
- uint16_t chr_val_handle,
- struct os_mbuf *txom
-)
-```
-
-### Description
-
-Sends a "free-form" characteristic notification. This function consumes the supplied mbuf regardless of the outcome.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| chr\_val\_handle | The attribute handle to indicate in the outgoing notification. |
-| txom | The value to write to the characteristic. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read.md
deleted file mode 100644
index d387635..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_read</font>
-
-```c
-int
-ble_gattc_read(
- uint16_t conn_handle,
- uint16_t attr_handle,
- ble_gatt_attr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Read Characteristic Value.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| attr\_handle | The handle of the characteristic value to read. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_by_uuid.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_by_uuid.md
deleted file mode 100644
index 259d982..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_by_uuid.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_read\_by\_uuid</font>
-
-```c
-int
-ble_gattc_read_by_uuid(
- uint16_t conn_handle,
- uint16_t start_handle,
- uint16_t end_handle,
- const ble_uuid_t *uuid,
- ble_gatt_attr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Read Using Characteristic UUID.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| start\_handle | The first handle to search (generally the handle of the service definition). |
-| end\_handle | The last handle to search (generally the last handle in the service definition). |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_long.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_long.md
deleted file mode 100644
index a61534d..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_long.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_read\_long</font>
-
-```c
-int
-ble_gattc_read_long(
- uint16_t conn_handle,
- uint16_t handle,
- uint16_t offset,
- ble_gatt_attr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Read Long Characteristic Values.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| handle | The handle of the characteristic value to read. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_mult.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_mult.md
deleted file mode 100644
index a82d489..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_mult.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_read\_mult</font>
-
-```c
-int
-ble_gattc_read_mult(
- uint16_t conn_handle,
- const uint16_t *handles,
- uint8_t num_handles,
- ble_gatt_attr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Read Multiple Characteristic Values.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| handles | An array of 16-bit attribute handles to read. |
-| num\_handles | The number of entries in the "handles" array. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write.md
deleted file mode 100644
index 03a8bac..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_write</font>
-
-```c
-int
-ble_gattc_write(
- uint16_t conn_handle,
- uint16_t attr_handle,
- struct os_mbuf *txom,
- ble_gatt_attr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Write Characteristic Value. This function consumes the supplied mbuf regardless of the outcome.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| attr\_handle | The handle of the characteristic value to write to. |
-| txom | The value to write to the characteristic. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_flat.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_flat.md
deleted file mode 100644
index 8edc5c9..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_flat.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_write\_flat</font>
-
-```c
-int
-ble_gattc_write_flat(
- uint16_t conn_handle,
- uint16_t attr_handle,
- const void *data,
- uint16_t data_len,
- ble_gatt_attr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Write Characteristic Value (flat buffer version).
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| attr\_handle | The handle of the characteristic value to write to. |
-| value | The value to write to the characteristic. |
-| value\_len | The number of bytes to write. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_long.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_long.md
deleted file mode 100644
index 0e31b69..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_long.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_write\_long</font>
-
-```c
-int
-ble_gattc_write_long(
- uint16_t conn_handle,
- uint16_t attr_handle,
- uint16_t offset,
- struct os_mbuf *txom,
- ble_gatt_attr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Write Long Characteristic Values. This function consumes the supplied mbuf regardless of the outcome.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| attr\_handle | The handle of the characteristic value to write to. |
-| txom | The value to write to the characteristic. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp.md
deleted file mode 100644
index 227ccf1..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_write\_no\_rsp</font>
-
-```c
-int
-ble_gattc_write_no_rsp(
- uint16_t conn_handle,
- uint16_t attr_handle,
- struct os_mbuf *txom
-)
-```
-
-### Description
-
-Initiates GATT procedure: Write Without Response. This function consumes the supplied mbuf regardless of the outcome.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| attr\_handle | The handle of the characteristic value to write to. |
-| txom | The value to write to the characteristic. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp_flat.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp_flat.md
deleted file mode 100644
index ce14795..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp_flat.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_write\_no\_rsp\_flat</font>
-
-```c
-int
-ble_gattc_write_no_rsp_flat(
- uint16_t conn_handle,
- uint16_t attr_handle,
- const void *data,
- uint16_t data_len
-)
-```
-
-### Description
-
-Initiates GATT procedure: Write Without Response. This function consumes the supplied mbuf regardless of the outcome.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| attr\_handle | The handle of the characteristic value to write to. |
-| value | The value to write to the characteristic. |
-| value\_len | The number of bytes to write. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_reliable.md b/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_reliable.md
deleted file mode 100644
index 248bc29..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_reliable.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gattc\_write\_reliable</font>
-
-```c
-int
-ble_gattc_write_reliable(
- uint16_t conn_handle,
- struct ble_gatt_attr *attrs,
- int num_attrs,
- ble_gatt_reliable_attr_fn *cb,
- void *cb_arg
-)
-```
-
-### Description
-
-Initiates GATT procedure: Reliable Writes. This function consumes the supplied mbufs regardless of the outcome.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| conn\_handle | The connection over which to execute the procedure. |
-| attrs | An array of attribute descriptors; specifies which characteristics to write to and what data to write to them. The mbuf pointer in each attribute is set to NULL by this function. |
-| num\_attrs | The number of characteristics to write; equal to the number of elements in the 'attrs' array. |
-| cb | The function to call to report procedure status updates; null for no callback. |
-| cb\_arg | The optional argument to pass to the callback function. |
-
-### Returned values
-
-None
diff --git a/docs/network/ble/ble_hs/ble_gattc/mdtoc.md b/docs/network/ble/ble_hs/ble_gattc/mdtoc.md
deleted file mode 100644
index 1713086..0000000
--- a/docs/network/ble/ble_hs/ble_gattc/mdtoc.md
+++ /dev/null
@@ -1,26 +0,0 @@
- - 'GATT client':
- - toc: 'network/ble/ble_hs/ble_gattc/ble_gattc.md'
- - 'Definitions':
- - 'GATT client definitions': 'network/ble/ble_hs/ble_gattc/definitions/ble_gattc_defs.md'
- - 'Functions':
- - 'ble_gattc_disc_all_chrs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_chrs.md'
- - 'ble_gattc_disc_all_dscs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_dscs.md'
- - 'ble_gattc_disc_all_svcs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_svcs.md'
- - 'ble_gattc_disc_chrs_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_chrs_by_uuid.md'
- - 'ble_gattc_disc_svc_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_svc_by_uuid.md'
- - 'ble_gattc_exchange_mtu': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu.md'
- - 'ble_gattc_find_inc_svcs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_find_inc_svcs.md'
- - 'ble_gattc_indicate': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate.md'
- - 'ble_gattc_indicate_custom': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate_custom.md'
- - 'ble_gattc_notify': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify.md'
- - 'ble_gattc_notify_custom': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify_custom.md'
- - 'ble_gattc_read': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read.md'
- - 'ble_gattc_read_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_by_uuid.md'
- - 'ble_gattc_read_long': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_long.md'
- - 'ble_gattc_read_mult': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_mult.md'
- - 'ble_gattc_write': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write.md'
- - 'ble_gattc_write_flat': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_flat.md'
- - 'ble_gattc_write_long': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_long.md'
- - 'ble_gattc_write_no_rsp': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp.md'
- - 'ble_gattc_write_no_rsp_flat': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp_flat.md'
- - 'ble_gattc_write_reliable': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_reliable.md'
diff --git a/docs/network/ble/ble_hs/ble_gatts/ble_gatts.md b/docs/network/ble/ble_hs/ble_gatts/ble_gatts.md
deleted file mode 100644
index f2774ba..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/ble_gatts.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">NimBLE Host GATT Server Reference</font>
-
-### Introduction
-
-The Generic Attribute Profile (GATT) manages all activities involving services, characteristics, and descriptors. The server half of the GATT API handles registration and responding to GATT clients.
-
-### Header
-
-```c
-#include "host/ble_hs.h"
-```
-
-### Definitions
-
-[BLE host GATT server definitions](definitions/ble_gatts_defs.md)
-
-### Functions
-
-| Function | Description |
-|----------|-------------|
-| [ble_gatts_add_svcs](functions/ble_gatts_add_svcs.md) | Queues a set of service definitions for registration. |
-| [ble_gatts_svc_set_visibility](functions/ble_gatts_svc_set_visibility.md) | Changes visibility of a service with specified handle. |
-| [ble_gatts_count_cfg](functions/ble_gatts_count_cfg.md) | Adjusts a host configuration object's settings to accommodate the specified service definition array. |
-| [ble_gatts_find_chr](functions/ble_gatts_find_chr.md) | Retrieves the pair of attribute handles associated with a local GATT characteristic. |
-| [ble_gatts_find_dsc](functions/ble_gatts_find_dsc.md) | Retrieves the attribute handle associated with a local GATT descriptor. |
-| [ble_gatts_find_svc](functions/ble_gatts_find_svc.md) | Retrieves the attribute handle associated with a local GATT service. |
diff --git a/docs/network/ble/ble_hs/ble_gatts/definitions/ble_gatts_defs.md b/docs/network/ble/ble_hs/ble_gatts/definitions/ble_gatts_defs.md
deleted file mode 100644
index d22490e..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/definitions/ble_gatts_defs.md
+++ /dev/null
@@ -1,235 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">GATT Server Definitions</font>
-
-```c
-typedef int ble_gatt_access_fn(uint16_t conn_handle, uint16_t attr_handle,
- struct ble_gatt_access_ctxt *ctxt, void *arg);
-```
-
-```c
-typedef uint16_t ble_gatt_chr_flags;
-```
-
-```c
-struct ble_gatt_chr_def {
- /**
- * Pointer to characteristic UUID; use BLE_UUIDxx_DECLARE macros to declare
- * proper UUID; NULL if there are no more characteristics in the service.
- */
- const ble_uuid_t *uuid;
-
- /**
- * Callback that gets executed when this characteristic is read or
- * written.
- */
- ble_gatt_access_fn *access_cb;
-
- /** Optional argument for callback. */
- void *arg;
-
- /**
- * Array of this characteristic's descriptors. NULL if no descriptors.
- * Do not include CCCD; it gets added automatically if this
- * characteristic's notify or indicate flag is set.
- */
- struct ble_gatt_dsc_def *descriptors;
-
- /** Specifies the set of permitted operations for this characteristic. */
- ble_gatt_chr_flags flags;
-
- /** Specifies minimum required key size to access this characteristic. */
- uint8_t min_key_size;
-
- /**
- * At registration time, this is filled in with the characteristic's value
- * attribute handle.
- */
- uint16_t * const val_handle;
-};
-```
-
-```c
-struct ble_gatt_svc_def {
- /**
- * One of the following:
- * o BLE_GATT_SVC_TYPE_PRIMARY - primary service
- * o BLE_GATT_SVC_TYPE_SECONDARY - secondary service
- * o 0 - No more services in this array.
- */
- uint8_t type;
-
- /**
- * Pointer to service UUID; use BLE_UUIDxx_DECLARE macros to declare
- * proper UUID; NULL if there are no more characteristics in the service.
- */
- const ble_uuid_t *uuid;
-
- /**
- * Array of pointers to other service definitions. These services are
- * reported as "included services" during service discovery. Terminate the
- * array with NULL.
- */
- const struct ble_gatt_svc_def **includes;
-
- /**
- * Array of characteristic definitions corresponding to characteristics
- * belonging to this service.
- */
- const struct ble_gatt_chr_def *characteristics;
-};
-```
-
-```c
-struct ble_gatt_dsc_def {
- /**
- * Pointer to descriptor UUID; use BLE_UUIDxx_DECLARE macros to declare
- * proper UUID; NULL if there are no more characteristics in the service.
- */
- const ble_uuid_t *uuid;
-
- /** Specifies the set of permitted operations for this descriptor. */
- uint8_t att_flags;
-
- /** Specifies minimum required key size to access this descriptor. */
- uint8_t min_key_size;
-
- /** Callback that gets executed when the descriptor is read or written. */
- ble_gatt_access_fn *access_cb;
-
- /** Optional argument for callback. */
- void *arg;
-};
-```
-
-```c
-/**
- * Context for an access to a GATT characteristic or descriptor. When a client
- * reads or writes a locally registered characteristic or descriptor, an
- * instance of this struct gets passed to the application callback.
- */
-struct ble_gatt_access_ctxt {
- /**
- * Indicates the gatt operation being performed. This is equal to one of
- * the following values:
- * o BLE_GATT_ACCESS_OP_READ_CHR
- * o BLE_GATT_ACCESS_OP_WRITE_CHR
- * o BLE_GATT_ACCESS_OP_READ_DSC
- * o BLE_GATT_ACCESS_OP_WRITE_DSC
- */
- uint8_t op;
-
- /**
- * A container for the GATT access data.
- * o For reads: The application populates this with the value of the
- * characteristic or descriptor being read.
- * o For writes: This is already populated with the value being written
- * by the peer. If the application wishes to retain this mbuf for
- * later use, the access callback must set this pointer to NULL to
- * prevent the stack from freeing it.
- */
- struct os_mbuf *om;
-
- /**
- * The GATT operation being performed dictates which field in this union is
- * valid. If a characteristic is being accessed, the chr field is valid.
- * Otherwise a descriptor is being accessed, in which case the dsc field
- * is valid.
- */
- union {
- /**
- * The characteristic definition corresponding to the characteristic
- * being accessed. This is what the app registered at startup.
- */
- const struct ble_gatt_chr_def *chr;
-
- /**
- * The descriptor definition corresponding to the descriptor being
- * accessed. This is what the app registered at startup.
- */
- const struct ble_gatt_dsc_def *dsc;
- };
-}
-```
-
-```c
-/**
- * Context passed to the registration callback; represents the GATT service,
- * characteristic, or descriptor being registered.
- */
-struct ble_gatt_register_ctxt {
- /**
- * Indicates the gatt registration operation just performed. This is
- * equal to one of the following values:
- * o BLE_GATT_REGISTER_OP_SVC
- * o BLE_GATT_REGISTER_OP_CHR
- * o BLE_GATT_REGISTER_OP_DSC
- */
- uint8_t op;
-
- /**
- * The value of the op field determines which field in this union is valid.
- */
- union {
- /** Service; valid if op == BLE_GATT_REGISTER_OP_SVC. */
- struct {
- /** The ATT handle of the service definition attribute. */
- uint16_t handle;
-
- /**
- * The service definition representing the service being
- * registered.
- */
- const struct ble_gatt_svc_def *svc_def;
- } svc;
-
- /** Characteristic; valid if op == BLE_GATT_REGISTER_OP_CHR. */
- struct {
- /** The ATT handle of the characteristic definition attribute. */
- uint16_t def_handle;
-
- /** The ATT handle of the characteristic value attribute. */
- uint16_t val_handle;
-
- /**
- * The characteristic definition representing the characteristic
- * being registered.
- */
- const struct ble_gatt_chr_def *chr_def;
-
- /**
- * The service definition corresponding to the characteristic's
- * parent service.
- */
- const struct ble_gatt_svc_def *svc_def;
- } chr;
-
- /** Descriptor; valid if op == BLE_GATT_REGISTER_OP_DSC. */
- struct {
- /** The ATT handle of the descriptor definition attribute. */
- uint16_t handle;
-
- /**
- * The descriptor definition corresponding to the descriptor being
- * registered.
- */
- const struct ble_gatt_dsc_def *dsc_def;
-
- /**
- * The characteristic definition corresponding to the descriptor's
- * parent characteristic.
- */
- const struct ble_gatt_chr_def *chr_def;
-
- /**
- * The service definition corresponding to the descriptor's
- * grandparent service
- */
- const struct ble_gatt_svc_def *svc_def;
- } dsc;
- };
-};
-```
-
-```c
-typedef void ble_gatt_register_fn(struct ble_gatt_register_ctxt *ctxt,
- void *arg);
-```
diff --git a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_add_svcs.md b/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_add_svcs.md
deleted file mode 100644
index d0ed070..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_add_svcs.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gatts\_add\_svcs</font>
-
-```c
-int
-ble_gatts_add_svcs(const struct ble_gatt_svc_def *svcs)
-```
-
-### Description
-
-Queues a set of service definitions for registration. All services queued in this manner get registered when ble\_hs\_init() is called.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| svcs | An array of service definitions to queue for registration. This array must be terminated with an entry whose 'type' equals 0. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOMEM | Heap exhaustion. |
diff --git a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_count_cfg.md b/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_count_cfg.md
deleted file mode 100644
index c435e00..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_count_cfg.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gatts\_count\_cfg</font>
-
-```c
-int
-ble_gatts_count_cfg(const struct ble_gatt_svc_def *defs)
-```
-
-### Description
-
-Adjusts a host configuration object's settings to accommodate the specified service definition array. This function adds the counts to the appropriate fields in the supplied configuration object without clearing them first, so it can be called repeatedly with different inputs to calculate totals. Be sure to zero the GATT server settings prior to the first call to this function.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| defs | The service array containing the resource definitions to be counted. |
-| cfg | The resource counts are accumulated in this configuration object. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EINVAL | The svcs array contains an invalid resource definition. |
diff --git a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_chr.md b/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_chr.md
deleted file mode 100644
index 4607808..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_chr.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gatts\_find\_chr</font>
-
-```c
-int
-ble_gatts_find_chr(
- const ble_uuid_t *svc_uuid,
- const ble_uuid_t *chr_uuid,
- uint16_t *out_def_handle,
- uint16_t *out_val_handle
-)
-```
-
-### Description
-
-Retrieves the pair of attribute handles associated with a local GATT characteristic.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| svc\_uuid128 | The UUID of the parent service. |
-| chr\_uuid128 | The UUID of the characteristic to look up. |
-| out\_def\_handle | On success, populated with the handle of the characteristic definition attribute. Pass null if you don't need this value. |
-| out\_val\_handle | On success, populated with the handle of the characteristic value attribute. Pass null if you don't need this value. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOENT | The specified service or characteristic could not be found. |
diff --git a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_dsc.md b/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_dsc.md
deleted file mode 100644
index 5b7e3fc..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_dsc.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gatts\_find\_dsc</font>
-
-```c
-int
-ble_gatts_find_dsc(
- const ble_uuid_t *svc_uuid,
- const ble_uuid_t *chr_uuid,
- const ble_uuid_t *dsc_uuid,
- uint16_t *out_handle
-)
-```
-
-### Description
-
-Retrieves the attribute handle associated with a local GATT descriptor.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| svc\_uuid128 | The UUID of the grandparent service. |
-| chr\_uuid128 | The UUID of the parent characteristic. |
-| dsc\_uuid128 | The UUID of the descriptor ro look up. |
-| out\_handle | On success, populated with the handle of the descripytor attribute. Pass null if you don't need this value. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOENT | The specified service, characteristic, or descriptor could not be found. |
diff --git a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_svc.md b/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_svc.md
deleted file mode 100644
index e0ae306..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_svc.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gatts\_find\_svc</font>
-
-```c
-int
-ble_gatts_find_svc(
- const ble_uuid_t *uuid,
- uint16_t *out_handle
-)
-```
-
-### Description
-
-Retrieves the attribute handle associated with a local GATT service.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| uuid128 | The UUID of the service to look up. |
-| out\_handle | On success, populated with the handle of the service attribute. Pass null if you don't need this value. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOENT | The specified service could not be found. |
diff --git a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_svc_set_visibility.md b/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_svc_set_visibility.md
deleted file mode 100644
index 187f5b2..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/functions/ble_gatts_svc_set_visibility.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_gatts\_svc\_set\_visibility</font>
-
-```c
-int
-ble_gatts_svc_set_visibility(uint16_t handle, int visible)
-```
-
-### Description
-
-Changes visibility of a service with specified handle. This function allow any service to be hidden (and then restored) from clients.
-<br/>
-<br/>
-Note: From GATT point of view, the service is still registered and has the same handle range assigned and it is ATT server which hides the attributes from the client.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| handle | The handle of a service for which the visibility should be changed. |
-| visible | The value of visibility to set. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_ENOENT | The svcs with specified handle does not exist. |
diff --git a/docs/network/ble/ble_hs/ble_gatts/mdtoc.md b/docs/network/ble/ble_hs/ble_gatts/mdtoc.md
deleted file mode 100644
index bd46bde..0000000
--- a/docs/network/ble/ble_hs/ble_gatts/mdtoc.md
+++ /dev/null
@@ -1,11 +0,0 @@
- - 'GATT server':
- - toc: 'network/ble/ble_hs/ble_gatts/ble_gatts.md'
- - 'Definitions':
- - 'GATT server definitions': 'network/ble/ble_hs/ble_gatts/definitions/ble_gatts_defs.md'
- - 'Functions':
- - 'ble_gatts_add_svcs': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_add_svcs.md'
- - 'ble_gatts_svc_set_visibility': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_svc_set_visibility.md'
- - 'ble_gatts_count_cfg': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_count_cfg.md'
- - 'ble_gatts_find_chr': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_chr.md'
- - 'ble_gatts_find_dsc': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_dsc.md'
- - 'ble_gatts_find_svc': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_svc.md'
diff --git a/docs/network/ble/ble_hs/ble_hs.md b/docs/network/ble/ble_hs/ble_hs.md
deleted file mode 100644
index c823bc0..0000000
--- a/docs/network/ble/ble_hs/ble_hs.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# NimBLE Host
-
-### Introduction
-
-At a high level, the NimBLE stack is divided into two components:
-
-* Host
-* Controller
-
-This document is an API reference for the host component. If you are interested in the general structure of the NimBLE stack and its non-host components, you might want to read the [BLE introduction](../ble_intro.md).
-
-The host sits directly below the application, and it serves as the interface to the application for all BLE operations.
-
-### Reference
-
-* [NimBLE Host Return Codes](ble_hs_return_codes.md)
-* [Generic Access Protocol (GAP)](ble_gap/ble_gap.md)
-* [Generic Attribute Profile (GATT) Client](ble_gattc/ble_gattc.md)
-* [Generic Attribute Profile (GATT) Server](ble_gatts/ble_gatts.md)
-* [Identity](ble_hs_id/ble_hs_id.md)
-* [Other](other/other.md)
diff --git a/docs/network/ble/ble_hs/ble_hs_id/ble_hs_id.md b/docs/network/ble/ble_hs/ble_hs_id/ble_hs_id.md
deleted file mode 100644
index 818c41b..0000000
--- a/docs/network/ble/ble_hs/ble_hs_id/ble_hs_id.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">NimBLE Host Identity Reference</font>
-
-### Introduction
-
-The identity API provides facilities for querying and configuring your device's addresses. BLE's addressing scheme is quite involved; the summary that follows is only a brief introduction.
-
-BLE defines four address types:
-
-| Type | Description | Identity? | Configured with |
-|-------------------------------|-------------------------------------------------------------------------------------------------|-----------|---------------------------------------------|
-| Public | Address assigned by manufacturer; the three most significant bytes form the manufacturer's OUI. | Yes | N/A; read from controller at startup. |
-| Static random | Randomly generated address. | Yes | *ble_hs_id_set_rnd()* |
-| Resolvable private (RPA) | Address randomly generated from an identity address and an identity resolving key (IRK). | No | N/A; generated by controller periodically. |
-| Non-resolvable private (NRPA) | Randomly generated address. | No | *ble_hs_id_set_rnd()* |
-
-#### Identity Addresses
-
-The third column in the above table indicates the _identity_ property of each address type. An identity address never changes, and a device can be identified by one of its unique identity addresses.
-
-Non-identity addresses are used by devices supporting BLE privacy. A device using the privacy feature frequently changes its own address to a newly-generated non-identity address. By cycling its address, the device makes it impossible for eavesdroppers to track its location.
-
-A device can have up to two identity addresses at once: one public and one static random. As indicated in the above table, the public identity address cannot be configured; the static random identity address can be set by calling *ble_hs_id_set_rnd()*.
-
-The address type is selected on a per-GAP-procedure basis. Each time you initiate a GAP procedure, you indicate which address type the device should use for the duration of the procedure.
-
-### Header
-
-```c
-#include "host/ble_hs.h"
-```
-
-### Definitions
-
-None.
-
-### Functions
-
-| Function | Description |
-|----------|-------------|
-| [ble_hs_id_copy_addr](functions/ble_hs_id_copy_addr.md) | Retrieves one of the device's identity addresses. |
-| [ble_hs_id_gen_rnd](functions/ble_hs_id_gen_rnd.md) | Generates a new random address. |
-| [ble_hs_id_set_rnd](functions/ble_hs_id_set_rnd.md) | Sets the device's random address. |
diff --git a/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_copy_addr.md b/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_copy_addr.md
deleted file mode 100644
index 89b50f1..0000000
--- a/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_copy_addr.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_id\_copy\_addr</font>
-
-```c
-int
-ble_hs_id_copy_addr(
- uint8_t id_addr_type,
- uint8_t *out_id_addr,
- int *out_is_nrpa
-)
-```
-
-### Description
-
-Retrieves one of the device's identity addresses. The device can have two identity addresses: one public and one random. The id\_addr\_type argument specifies which of these two addresses to retrieve.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| id\_addr\_type | The type of identity address to retrieve. Valid values are: <ul><li>BLE\_ADDR\_PUBLIC</li> <li>BLE\_ADDR\_RANDOM</li></ul> |
-| out\_id\_addr | On success, the requested identity address is copied into this buffer. The buffer must be at least six bytes in size. |
-| out\_is\_nrpa | On success, the pointed-to value indicates whether the retrieved address is a non-resolvable private address. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EINVAL | An invalid address type was specified. |
-| BLE\_HS\_ENOADDR | The device does not have an identity address of the requested type. |
-| other | Other ble host core code on error. |
diff --git a/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd.md b/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd.md
deleted file mode 100644
index 53a55da..0000000
--- a/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_id\_gen\_rnd</font>
-
-```c
-int
-ble_hs_id_gen_rnd(
- int nrpa,
- ble_addr_t *out_addr
-)
-```
-
-### Description
-
-Generates a new random address. This function does not configure the device with the new address; the caller can use the address in subsequent operations.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| nrpa | The type of random address to generate: 0: static 1: non-resolvable private |
-| out\_addr | On success, the generated address gets written here. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd.md b/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd.md
deleted file mode 100644
index 5f2a3bf..0000000
--- a/docs/network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_id\_set\_rnd</font>
-
-```c
-int
-ble_hs_id_set_rnd(const uint8_t *rnd_addr)
-```
-
-### Description
-
-Sets the device's random address. The address type (static vs. non-resolvable private) is inferred from the most-significant byte of the address. The address is specified in host byte order (little-endian!).
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| rnd\_addr | The random address to set. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/ble_hs_id/mdtoc.md b/docs/network/ble/ble_hs/ble_hs_id/mdtoc.md
deleted file mode 100644
index 49d0bdd..0000000
--- a/docs/network/ble/ble_hs/ble_hs_id/mdtoc.md
+++ /dev/null
@@ -1,6 +0,0 @@
- - 'Identity':
- - toc: 'network/ble/ble_hs/ble_hs_id/ble_hs_id.md'
- - 'Functions':
- - 'ble_hs_id_copy_addr': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_copy_addr.md'
- - 'ble_hs_id_gen_rnd': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd.md'
- - 'ble_hs_id_set_rnd': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd.md'
diff --git a/docs/network/ble/ble_hs/ble_hs_return_codes.md b/docs/network/ble/ble_hs/ble_hs_return_codes.md
deleted file mode 100644
index 1ec65c8..0000000
--- a/docs/network/ble/ble_hs/ble_hs_return_codes.md
+++ /dev/null
@@ -1,271 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">NimBLE Host Return Codes</font>
-
-* [Introduction](#introduction)
- * [Summary](#summary)
- * [Example](#example)
-* [Return Code Reference](#return-code-reference)
- * [Return codes - Core](#return-codes-core)
- * [Return codes - ATT](#return-codes-att)
- * [Return codes - HCI](#return-codes-hci)
- * [Return codes - L2CAP](#return-codes-l2cap)
- * [Return codes - Security manager (us)](#return-codes-security-manager-(us))
- * [Return codes - Security manager (peer)](#return-codes-security-manager-(peer))
-
-### Introduction
-
-#### Summary
-
-The NimBLE host reports status to the application via a set of return codes. The host encompasses several layers of the Bluetooth specification that each defines its own set of status codes. Rather than "abstract away" information from lower layers that the application developer might find useful, the NimBLE host aims to indicate precisely what happened when something fails. Consequently, the host utilizes a rather large set of return codes.
-
-A return code of 0 indicates success. For failure conditions, the return codes are partitioned into five separate sets:
-
-| Set | Condition | Notes|
-|-----|-------------|
-| Core | Errors detected internally by the NimBLE host. |
-| ATT | The ATT server has reported a failure via the transmission of an ATT Error Response. The return code corresponds to the value of the Error Code field in the response. |
-| HCI | The controller has reported an error to the host via a command complete or command status HCI event. The return code corresponds to the value of the Status field in the event.
-| L2CAP | An L2CAP signaling procedure has failed and an L2CAP Command Reject was sent as a result. The return code corresponds to the value of the Reason field in the command.
-| Security manager (us) | The host detected an error during a security manager procedure and sent a Pairing Failed command to the peer. The return code corresponds to the value of the Reason field in the Pairing Failed command. |
-| Security manager (peer) | A security manager procedure failed because the peer sent us a Pairing Failed command. The return code corresponds to the value of the Reason field in the Pairing Failed command. |
-
-The return codes in the core set are defined by the NimBLE Host. The other sets are defined in the Bluetooth specification; the codes in this latter group are referred to as _formal status codes_. As defined in the Bluetooth specification, the formal status code sets are not disjoint. That is, they overlap. For example, the spec defines a status code of 1 to have all of the following meanings:
-
-| Layer | Meaning |
-|-------|---------|
-| ATT | Invalid handle. |
-| HCI | Unknown HCI command. |
-| L2CAP | Signalling MTU exceeded. |
-| SM | Passkey entry failed. |
-
-Clearly, the host can't just return an unadorned formal status code and expect the application to make sense of it. To resolve this ambiguity, the NimBLE host divides the full range of an int into several subranges. Each subrange corresponds to one of the five return code sets. For example, the ATT set is mapped onto the subrange _[0x100, 0x200)_. To indicate an ATT error of 3 (write not permitted), the NimBLE host returns a value 0x103 to the application.
-
-The host defines a set of convenience macros for converting from a formal status code to NimBLE host status code. These macros are documented in the table below.
-
-| Macro | Status code set | Base value |
-|-------|-----------------|-------------------|
-| BLE\_HS\_ATT\_ERR() | ATT | 0x100 |
-| BLE\_HS\_HCI\_ERR() | HCI | 0x200 |
-| BLE\_HS\_L2C\_ERR() | L2CAP | 0x300 |
-| BLE\_HS\_SM\_US\_ERR() | Security manager (us) | 0x400 |
-| BLE\_HS\_SM\_PEER\_ERR() | Security manager (peer) | 0x500 |
-
-#### Example
-
-The following example demonstrates how an application might determine which error is being reported by the host. In this example, the application performs the GAP encryption procedure and checks the return code. To simplify the example, the application uses a hypothetical *my_blocking_enc_proc()* function, which blocks until the pairing operation has completed.
-
-```c
-void
-encrypt_connection(uint16_t conn_handle)
-{
- int rc;
-
- /* Perform a blocking GAP encryption procedure. */
- rc = my_blocking_enc_proc(conn_handle);
- switch (rc) {
- case 0:
- console_printf("success - link successfully encrypted\n");
- break;
-
- case BLE_HS_ENOTCONN:
- console_printf("failure - no connection with handle %d\n",
- conn_handle);
- break;
-
- case BLE_HS_ERR_SM_US_BASE(BLE_SM_ERR_CONFIRM_MISMATCH):
- console_printf("failure - mismatch in peer's confirm and random "
- "commands.\n");
- break;
-
- case BLE_HS_ERR_SM_PEER_BASE(BLE_SM_ERR_CONFIRM_MISMATCH):
- console_printf("failure - peer reports mismatch in our confirm and "
- "random commands.\n");
- break;
-
- default:
- console_printf("failure - other error: 0x%04x\n", rc);
- break;
- }
-}
-```
-
-### Return Code Reference
-
-#### Header
-
-All NimBLE host return codes are made accessible by including the following header:
-
-```c
-#include "host/ble_hs.h"
-```
-
-#### Return codes - Core
-
-The precise meaning of each of these error codes depends on the function that returns it. The API reference for a particular function indicates the conditions under which each of these codes are returned.
-
-| Value | Name | Condition |
-|-------|----------------|----------------------------------------------|
-| 0x00 | _N/A_ | Success |
-| 0x01 | BLE\_HS\_EAGAIN | Temporary failure; try again. |
-| 0x02 | BLE\_HS\_EALREADY | Operation already in progress or completed. |
-| 0x03 | BLE\_HS\_EINVAL | One or more arguments are invalid. |
-| 0x04 | BLE\_HS\_EMSGSIZE | The provided buffer is too small. |
-| 0x05 | BLE\_HS\_ENOENT | No entry matching the specified criteria. |
-| 0x06 | BLE\_HS\_ENOMEM | Operation failed due to resource exhaustion. |
-| 0x07 | BLE\_HS\_ENOTCONN | No open connection with the specified handle.|
-| 0x08 | BLE\_HS\_ENOTSUP | Operation disabled at compile time. |
-| 0x09 | BLE\_HS\_EAPP | Application callback behaved unexpectedly. |
-| 0x0a | BLE\_HS\_EBADDATA | Command from peer is invalid. |
-| 0x0b | BLE\_HS\_EOS | Mynewt OS error. |
-| 0x0c | BLE\_HS\_ECONTROLLER | Event from controller is invalid. |
-| 0x0d | BLE\_HS\_ETIMEOUT | Operation timed out. |
-| 0x0e | BLE\_HS\_EDONE | Operation completed successfully. |
-| 0x0f | BLE\_HS\_EBUSY | Operation cannot be performed until procedure completes. |
-| 0x10 | BLE\_HS\_EREJECT | Peer rejected a connection parameter update request. |
-| 0x11 | BLE\_HS\_EUNKNOWN | Unexpected failure; catch all. |
-| 0x12 | BLE\_HS\_EROLE | Operation requires different role (e.g., central vs. peripheral). |
-| 0x13 | BLE\_HS\_ETIMEOUT\_HCI | HCI request timed out; controller unresponsive. |
-| 0x14 | BLE\_HS\_ENOMEM\_EVT | Controller failed to send event due to memory exhaustion (combined host-controller only). |
-| 0x15 | BLE\_HS\_ENOADDR | Operation requires an identity address but none configured. |
-| 0x16 | BLE\_HS\_ENOTSYNCED | Attempt to use the host before it is synced with controller. |
-| 0x17 | BLE\_HS\_EAUTHEN | Insufficient authentication. |
-| 0x18 | BLE\_HS\_EAUTHOR | Insufficient authorization. |
-| 0x19 | BLE\_HS\_EENCRYPT | Insufficient encryption level. |
-| 0x1a | BLE\_HS\_EENCRYPT\_KEY\_SZ | Insufficient key size. |
-| 0x1b | BLE\_HS\_ESTORE\_CAP | Storage at capacity. |
-| 0x1c | BLE\_HS\_ESTORE\_FAIL | Storage IO error. |
-
-
-#### Return codes - ATT
-
-| NimBLE Value | Formal Value | Name | Condition |
-|--------------|--------------|--------|-------------|
-| 0x0101 | 0x01 | BLE\_ATT\_ERR\_INVALID\_HANDLE | The attribute handle given was not valid on this server. |
-| 0x0102 | 0x02 | BLE\_ATT\_ERR\_READ\_NOT\_PERMITTED | The attribute cannot be read. |
-| 0x0103 | 0x03 | BLE\_ATT\_ERR\_WRITE\_NOT\_PERMITTED | The attribute cannot be written. |
-| 0x0104 | 0x04 | BLE\_ATT\_ERR\_INVALID\_PDU | The attribute PDU was invalid. |
-| 0x0105 | 0x05 | BLE\_ATT\_ERR\_INSUFFICIENT\_AUTHEN | The attribute requires authentication before it can be read or written. |
-| 0x0106 | 0x06 | BLE\_ATT\_ERR\_REQ\_NOT\_SUPPORTED | Attribute server does not support the request received from the client. |
-| 0x0107 | 0x07 | BLE\_ATT\_ERR\_INVALID\_OFFSET | Offset specified was past the end of the attribute. |
-| 0x0108 | 0x08 | BLE\_ATT\_ERR\_INSUFFICIENT\_AUTHOR | The attribute requires authorization before it can be read or written. |
-| 0x0109 | 0x09 | BLE\_ATT\_ERR\_PREPARE\_QUEUE\_FULL | Too many prepare writes have been queued. |
-| 0x010a | 0x0a | BLE\_ATT\_ERR\_ATTR\_NOT\_FOUND | No attribute found within the given attribute handle range. |
-| 0x010b | 0x0b | BLE\_ATT\_ERR\_ATTR\_NOT\_LONG | The attribute cannot be read or written using the Read Blob Request. |
-| 0x010c | 0x0c | BLE\_ATT\_ERR\_INSUFFICIENT\_KEY\_SZ | The Encryption Key Size used for encrypting this link is insufficient. |
-| 0x010d | 0x0d | BLE\_ATT\_ERR\_INVALID\_ATTR\_VALUE\_LEN | The attribute value length is invalid for the operation. |
-| 0x010e | 0x0e | BLE\_ATT\_ERR\_UNLIKELY | The attribute request that was requested has encountered an error that was unlikely, and therefore could not be completed as requested. |
-| 0x010f | 0x0f | BLE\_ATT\_ERR\_INSUFFICIENT\_ENC | The attribute requires encryption before it can be read or written. |
-| 0x0110 | 0x10 | BLE\_ATT\_ERR\_UNSUPPORTED\_GROUP | The attribute type is not a supported grouping attribute as defined by a higher layer specification. |
-| 0x0111 | 0x11 | BLE\_ATT\_ERR\_INSUFFICIENT\_RES | Insufficient Resources to complete the request. |
-
-
-#### Return codes - HCI
-
-| NimBLE Value | Formal Value | Name | Condition |
-|--------------|--------------|--------|-------------|
-| 0x0201 | 0x01 | BLE\_ERR\_UNKNOWN\_HCI\_CMD | Unknown HCI Command |
-| 0x0202 | 0x02 | BLE\_ERR\_UNK\_CONN\_ID | Unknown Connection Identifier |
-| 0x0203 | 0x03 | BLE\_ERR\_HW\_FAIL | Hardware Failure |
-| 0x0204 | 0x04 | BLE\_ERR\_PAGE\_TMO | Page Timeout |
-| 0x0205 | 0x05 | BLE\_ERR\_AUTH\_FAIL | Authentication Failure |
-| 0x0206 | 0x06 | BLE\_ERR\_PINKEY\_MISSING | PIN or Key Missing |
-| 0x0207 | 0x07 | BLE\_ERR\_MEM\_CAPACITY | Memory Capacity Exceeded |
-| 0x0208 | 0x08 | BLE\_ERR\_CONN\_SPVN\_TMO | Connection Timeout |
-| 0x0209 | 0x09 | BLE\_ERR\_CONN\_LIMIT | Connection Limit Exceeded |
-| 0x020a | 0x0a | BLE\_ERR\_SYNCH\_CONN\_LIMIT | Synchronous Connection Limit To A Device Exceeded |
-| 0x020b | 0x0b | BLE\_ERR\_ACL\_CONN\_EXISTS | ACL Connection Already Exists |
-| 0x020c | 0x0c | BLE\_ERR\_CMD\_DISALLOWED | Command Disallowed |
-| 0x020d | 0x0d | BLE\_ERR\_CONN\_REJ\_RESOURCES | Connection Rejected due to Limited Resources |
-| 0x020e | 0x0e | BLE\_ERR\_CONN\_REJ\_SECURITY | Connection Rejected Due To Security Reasons |
-| 0x020f | 0x0f | BLE\_ERR\_CONN\_REJ\_BD\_ADDR | Connection Rejected due to Unacceptable BD\_ADDR |
-| 0x0210 | 0x10 | BLE\_ERR\_CONN\_ACCEPT\_TMO | Connection Accept Timeout Exceeded |
-| 0x0211 | 0x11 | BLE\_ERR\_UNSUPPORTED | Unsupported Feature or Parameter Value |
-| 0x0212 | 0x12 | BLE\_ERR\_INV\_HCI\_CMD\_PARMS | Invalid HCI Command Parameters |
-| 0x0213 | 0x13 | BLE\_ERR\_REM\_USER\_CONN\_TERM | Remote User Terminated Connection |
-| 0x0214 | 0x14 | BLE\_ERR\_RD\_CONN\_TERM\_RESRCS | Remote Device Terminated Connection due to Low Resources |
-| 0x0215 | 0x15 | BLE\_ERR\_RD\_CONN\_TERM\_PWROFF | Remote Device Terminated Connection due to Power Off |
-| 0x0216 | 0x16 | BLE\_ERR\_CONN\_TERM\_LOCAL | Connection Terminated By Local Host |
-| 0x0217 | 0x17 | BLE\_ERR\_REPEATED\_ATTEMPTS | Repeated Attempts |
-| 0x0218 | 0x18 | BLE\_ERR\_NO\_PAIRING | Pairing Not Allowed |
-| 0x0219 | 0x19 | BLE\_ERR\_UNK\_LMP | Unknown LMP PDU |
-| 0x021a | 0x1a | BLE\_ERR\_UNSUPP\_REM\_FEATURE | Unsupported Remote Feature / Unsupported LMP Feature |
-| 0x021b | 0x1b | BLE\_ERR\_SCO\_OFFSET | SCO Offset Rejected |
-| 0x021c | 0x1c | BLE\_ERR\_SCO\_ITVL | SCO Interval Rejected |
-| 0x021d | 0x1d | BLE\_ERR\_SCO\_AIR\_MODE | SCO Air Mode Rejected |
-| 0x021e | 0x1e | BLE\_ERR\_INV\_LMP\_LL\_PARM | Invalid LMP Parameters / Invalid LL Parameters |
-| 0x021f | 0x1f | BLE\_ERR\_UNSPECIFIED | Unspecified Error |
-| 0x0220 | 0x20 | BLE\_ERR\_UNSUPP\_LMP\_LL\_PARM | Unsupported LMP Parameter Value / Unsupported LL Parameter Value |
-| 0x0221 | 0x21 | BLE\_ERR\_NO\_ROLE\_CHANGE | Role Change Not Allowed |
-| 0x0222 | 0x22 | BLE\_ERR\_LMP\_LL\_RSP\_TMO | LMP Response Timeout / LL Response Timeout |
-| 0x0223 | 0x23 | BLE\_ERR\_LMP\_COLLISION | LMP Error Transaction Collision |
-| 0x0224 | 0x24 | BLE\_ERR\_LMP\_PDU | LMP PDU Not Allowed |
-| 0x0225 | 0x25 | BLE\_ERR\_ENCRYPTION\_MODE | Encryption Mode Not Acceptable |
-| 0x0226 | 0x26 | BLE\_ERR\_LINK\_KEY\_CHANGE | Link Key cannot be Changed |
-| 0x0227 | 0x27 | BLE\_ERR\_UNSUPP\_QOS | Requested QoS Not Supported |
-| 0x0228 | 0x28 | BLE\_ERR\_INSTANT\_PASSED | Instant Passed |
-| 0x0229 | 0x29 | BLE\_ERR\_UNIT\_KEY\_PAIRING | Pairing With Unit Key Not Supported |
-| 0x022a | 0x2a | BLE\_ERR\_DIFF\_TRANS\_COLL | Different Transaction Collision |
-| 0x022c | 0x2c | BLE\_ERR\_QOS\_PARM | QoS Unacceptable Parameter |
-| 0x022d | 0x2d | BLE\_ERR\_QOS\_REJECTED | QoS Rejected |
-| 0x022e | 0x2e | BLE\_ERR\_CHAN\_CLASS | Channel Classification Not Supported |
-| 0x022f | 0x2f | BLE\_ERR\_INSUFFICIENT\_SEC | Insufficient Security |
-| 0x0230 | 0x30 | BLE\_ERR\_PARM\_OUT\_OF\_RANGE | Parameter Out Of Mandatory Range |
-| 0x0232 | 0x32 | BLE\_ERR\_PENDING\_ROLE\_SW | Role Switch Pending |
-| 0x0234 | 0x34 | BLE\_ERR\_RESERVED\_SLOT | Reserved Slot Violation |
-| 0x0235 | 0x35 | BLE\_ERR\_ROLE\_SW\_FAIL | Role Switch Failed |
-| 0x0236 | 0x36 | BLE\_ERR\_INQ\_RSP\_TOO\_BIG | Extended Inquiry Response Too Large |
-| 0x0237 | 0x37 | BLE\_ERR\_SEC\_SIMPLE\_PAIR | Secure Simple Pairing Not Supported By Host |
-| 0x0238 | 0x38 | BLE\_ERR\_HOST\_BUSY\_PAIR | Host Busy - Pairing |
-| 0x0239 | 0x39 | BLE\_ERR\_CONN\_REJ\_CHANNEL | Connection Rejected due to No Suitable Channel Found |
-| 0x023a | 0x3a | BLE\_ERR\_CTLR\_BUSY | Controller Busy |
-| 0x023b | 0x3b | BLE\_ERR\_CONN\_PARMS | Unacceptable Connection Parameters |
-| 0x023c | 0x3c | BLE\_ERR\_DIR\_ADV\_TMO | Directed Advertising Timeout |
-| 0x023d | 0x3d | BLE\_ERR\_CONN\_TERM\_MIC | Connection Terminated due to MIC Failure |
-| 0x023e | 0x3e | BLE\_ERR\_CONN\_ESTABLISHMENT | Connection Failed to be Established |
-| 0x023f | 0x3f | BLE\_ERR\_MAC\_CONN\_FAIL | MAC Connection Failed |
-| 0x0240 | 0x40 | BLE\_ERR\_COARSE\_CLK\_ADJ | Coarse Clock Adjustment Rejected but Will Try to Adjust Using Clock Dragging |
-
-#### Return codes - L2CAP
-
-| NimBLE Value | Formal Value | Name | Condition |
-|--------------|--------------|--------|-------------|
-| 0x0300 | 0x00 | BLE\_L2CAP\_SIG\_ERR\_CMD\_NOT\_UNDERSTOOD | Invalid or unsupported incoming L2CAP sig command. |
-| 0x0301 | 0x01 | BLE\_L2CAP\_SIG\_ERR\_MTU\_EXCEEDED | Incoming packet too large. |
-| 0x0302 | 0x02 | BLE\_L2CAP\_SIG\_ERR\_INVALID\_CID | No channel with specified ID. |
-
-#### Return codes - Security manager (us)
-
-| NimBLE Value | Formal Value | Name | Condition |
-|--------------|--------------|--------|-------------|
-| 0x0401 | 0x01 | BLE\_SM\_ERR\_PASSKEY | The user input of passkey failed, for example, the user cancelled the operation. |
-| 0x0402 | 0x02 | BLE\_SM\_ERR\_OOB | The OOB data is not available. |
-| 0x0403 | 0x03 | BLE\_SM\_ERR\_AUTHREQ | The pairing procedure cannot be performed as authentication requirements cannot be met due to IO capabilities of one or both devices. |
-| 0x0404 | 0x04 | BLE\_SM\_ERR\_CONFIRM\_MISMATCH | The confirm value does not match the calculated compare value. |
-| 0x0405 | 0x05 | BLE\_SM\_ERR\_PAIR\_NOT\_SUPP | Pairing is not supported by the device. |
-| 0x0406 | 0x06 | BLE\_SM\_ERR\_ENC\_KEY\_SZ | The resultant encryption key size is insufficient for the security requirements of this device. |
-| 0x0407 | 0x07 | BLE\_SM\_ERR\_CMD\_NOT\_SUPP | The SMP command received is not supported on this device. |
-| 0x0408 | 0x08 | BLE\_SM\_ERR\_UNSPECIFIED | Pairing failed due to an unspecified reason. |
-| 0x0409 | 0x09 | BLE\_SM\_ERR\_REPEATED | Pairing or authentication procedure is disallowed because too little time has elapsed since last pairing request or security request. |
-| 0x040a | 0x0a | BLE\_SM\_ERR\_INVAL | The Invalid Parameters error code indicates that the command length is invalid or that a parameter is outside of the specified range. |
-| 0x040b | 0x0b | BLE\_SM\_ERR\_DHKEY | Indicates to the remote device that the DHKey Check value received doesn’t match the one calculated by the local device. |
-| 0x040c | 0x0c | BLE\_SM\_ERR\_NUMCMP | Indicates that the confirm values in the numeric comparison protocol do not match. |
-| 0x040d | 0x0d | BLE\_SM\_ERR\_ALREADY | Indicates that the pairing over the LE transport failed due to a Pairing Request sent over the BR/EDR transport in process. |
-| 0x040e | 0x0e | BLE\_SM\_ERR\_CROSS\_TRANS | Indicates that the BR/EDR Link Key generated on the BR/EDR transport cannot be used to derive and distribute keys for the LE transport. |
-
-#### Return codes - Security manager (peer)
-
-| NimBLE Value | Formal Value | Name | Condition |
-|--------------|--------------|--------|-------------|
-| 0x0501 | 0x01 | BLE\_SM\_ERR\_PASSKEY | The user input of passkey failed, for example, the user cancelled the operation. |
-| 0x0502 | 0x02 | BLE\_SM\_ERR\_OOB | The OOB data is not available. |
-| 0x0503 | 0x03 | BLE\_SM\_ERR\_AUTHREQ | The pairing procedure cannot be performed as authentication requirements cannot be met due to IO capabilities of one or both devices. |
-| 0x0504 | 0x04 | BLE\_SM\_ERR\_CONFIRM\_MISMATCH | The confirm value does not match the calculated compare value. |
-| 0x0505 | 0x05 | BLE\_SM\_ERR\_PAIR\_NOT\_SUPP | Pairing is not supported by the device. |
-| 0x0506 | 0x06 | BLE\_SM\_ERR\_ENC\_KEY\_SZ | The resultant encryption key size is insufficient for the security requirements of this device. |
-| 0x0507 | 0x07 | BLE\_SM\_ERR\_CMD\_NOT\_SUPP | The SMP command received is not supported on this device. |
-| 0x0508 | 0x08 | BLE\_SM\_ERR\_UNSPECIFIED | Pairing failed due to an unspecified reason. |
-| 0x0509 | 0x09 | BLE\_SM\_ERR\_REPEATED | Pairing or authentication procedure is disallowed because too little time has elapsed since last pairing request or security request. |
-| 0x050a | 0x0a | BLE\_SM\_ERR\_INVAL | The Invalid Parameters error code indicates that the command length is invalid or that a parameter is outside of the specified range. |
-| 0x050b | 0x0b | BLE\_SM\_ERR\_DHKEY | Indicates to the remote device that the DHKey Check value received doesn’t match the one calculated by the local device. |
-| 0x050c | 0x0c | BLE\_SM\_ERR\_NUMCMP | Indicates that the confirm values in the numeric comparison protocol do not match. |
-| 0x050d | 0x0d | BLE\_SM\_ERR\_ALREADY | Indicates that the pairing over the LE transport failed due to a Pairing Request sent over the BR/EDR transport in process. |
-| 0x050e | 0x0e | BLE\_SM\_ERR\_CROSS\_TRANS | Indicates that the BR/EDR Link Key generated on the BR/EDR transport cannot be used to derive and distribute keys for the LE transport. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_uid.md b/docs/network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_uid.md
deleted file mode 100644
index 8524993..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_uid.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_eddystone\_set\_adv\_data\_uid</font>
-
-```c
-int
-ble_eddystone_set_adv_data_uid(
- struct ble_hs_adv_fields *adv_fields,
- void *uid
-)
-```
-
-### Description
-
-Configures the device to advertise eddystone UID beacons.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| adv\_fields | The base advertisement fields to transform into an eddystone beacon. All configured fields are preserved; you probably want to clear this struct before calling this function. |
-| uid | The 16-byte UID to advertise. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EBUSY | Advertising is in progress. |
-| BLE\_HS\_EMSGSIZE | The specified data is too large to fit in an advertisement. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_url.md b/docs/network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_url.md
deleted file mode 100644
index 327b82c..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_url.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_eddystone\_set\_adv\_data\_url</font>
-
-```c
-int
-ble_eddystone_set_adv_data_url(
- struct ble_hs_adv_fields *adv_fields,
- uint8_t url_scheme,
- char *url_body,
- uint8_t url_body_len,
- uint8_t url_suffix
-)
-```
-
-### Description
-
-Configures the device to advertise eddystone URL beacons.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| adv\_fields | The base advertisement fields to transform into an eddystone beacon. All configured fields are preserved; you probably want to clear this struct before calling this function. |
-| url\_scheme | The prefix of the URL; one of the BLE\_EDDYSTONE\_URL\_SCHEME values. |
-| url\_body | The middle of the URL. Don't include the suffix if there is a suitable suffix code. |
-| url\_body\_len | The string length of the url\_body argument. |
-| url\_suffix | The suffix of the URL; one of the BLE\_EDDYSTONE\_URL\_SUFFIX values; use BLE\_EDDYSTONE\_URL\_SUFFIX\_NONE if the suffix is embedded in the body argument. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EBUSY | Advertising is in progress. |
-| BLE\_HS\_EMSGSIZE | The specified data is too large to fit in an advertisement. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_hs_evq_set.md b/docs/network/ble/ble_hs/other/functions/ble_hs_evq_set.md
deleted file mode 100644
index 8a6dd03..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_hs_evq_set.md
+++ /dev/null
@@ -1,20 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_evq\_set</font>
-
-```c
-void
-ble_hs_evq_set(struct os_eventq *evq)
-```
-
-### Description
-
-Designates the specified event queue for NimBLE host work. By default, the host uses the default event queue and runs in the main task. This function is useful if you want the host to run in a different task.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| evq | The event queue to use for host work. |
-
-### Returned values
-
-None
diff --git a/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_att_pkt.md b/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_att_pkt.md
deleted file mode 100644
index 8b7daa6..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_att_pkt.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_mbuf\_att\_pkt</font>
-
-```c
-struct os_mbuf *
-ble_hs_mbuf_att_pkt(void)
-```
-
-### Description
-
-Allocates an mbuf suitable for an ATT command packet. The resulting packet has sufficient leading space for: <ul><li>ACL data header</li> <li>L2CAP B-frame header</li> <li>Largest ATT command base (prepare write request / response).</li></ul>
-
-### Parameters
-
-None
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| An empty mbuf | Success. |
-| null | Memory exhaustion. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_from_flat.md b/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_from_flat.md
deleted file mode 100644
index da40f17..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_from_flat.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_mbuf\_from\_flat</font>
-
-```c
-struct os_mbuf *
-ble_hs_mbuf_from_flat(
- const void *buf,
- uint16_t len
-)
-```
-
-### Description
-
-Allocates a an mbuf and fills it with the contents of the specified flat buffer.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| buf | The flat buffer to copy from. |
-| len | The length of the flat buffer. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| A newly-allocated mbuf | Success. |
-| NULL | Memory exhaustion. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_to_flat.md b/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_to_flat.md
deleted file mode 100644
index 34b87a9..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_hs_mbuf_to_flat.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_mbuf\_to\_flat</font>
-
-```c
-int
-ble_hs_mbuf_to_flat(
- const struct os_mbuf *om,
- void *flat,
- uint16_t max_len,
- uint16_t *out_copy_len
-)
-```
-
-### Description
-
-Copies the contents of an mbuf into the specified flat buffer. If the flat buffer is too small to contain the mbuf's contents, it is filled to capacity and BLE\_HS\_EMSGSIZE is returned.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| om | The mbuf to copy from. |
-| flat | The destination flat buffer. |
-| max\_len | The size of the flat buffer. |
-| out\_copy\_len | The number of bytes actually copied gets written here. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EMSGSIZE | The flat buffer is too small to contain the mbuf's contents. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_hs_sched_reset.md b/docs/network/ble/ble_hs/other/functions/ble_hs_sched_reset.md
deleted file mode 100644
index 03f5e9d..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_hs_sched_reset.md
+++ /dev/null
@@ -1,20 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_sched\_reset</font>
-
-```c
-void
-ble_hs_sched_reset(int reason)
-```
-
-### Description
-
-Causes the host to reset the NimBLE stack as soon as possible. The application is notified when the reset occurs via the host reset callback.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| reason | The host error code that gets passed to the reset callback. |
-
-### Returned values
-
-None
diff --git a/docs/network/ble/ble_hs/other/functions/ble_hs_synced.md b/docs/network/ble/ble_hs/other/functions/ble_hs_synced.md
deleted file mode 100644
index 6aeb618..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_hs_synced.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_hs\_synced</font>
-
-```c
-int
-ble_hs_synced(void)
-```
-
-### Description
-
-Indicates whether the host has synchronized with the controller. Synchronization must occur before any host procedures can be performed.
-
-### Parameters
-
-None
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 1 | The host and controller are in sync. |
-| 0 | The host and controller our out of sync. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_ibeacon_set_adv_data.md b/docs/network/ble/ble_hs/other/functions/ble_ibeacon_set_adv_data.md
deleted file mode 100644
index 24c285b..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_ibeacon_set_adv_data.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_ibeacon\_set\_adv\_data</font>
-
-```c
-int
-ble_ibeacon_set_adv_data(
- void *uuid128,
- uint16_t major,
- uint16_t minor
-)
-```
-
-### Description
-
-Configures the device to advertise iBeacons.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| uuid | The 128-bit UUID to advertise. |
-| major | The major version number to include in iBeacons. |
-| minor | The minor version number to include in iBeacons. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EBUSY | Advertising is in progress. |
-| [Core return code](../../ble_hs_return_codes/#return-codes-core) | Unexpected error. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_uuid_cmp.md b/docs/network/ble/ble_hs/other/functions/ble_uuid_cmp.md
deleted file mode 100644
index ebe11da..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_uuid_cmp.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_uuid\_cmp</font>
-
-```c
-int
-ble_uuid_cmp(
- const ble_uuid_t *uuid1,
- const ble_uuid_t *uuid2
-)
-```
-
-### Description
-
-Compares two Bluetooth UUIDs.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| uuid1 | The first UUID to compare. |
-| uuid2 | The second UUID to compare. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | The two uuids are equal. |
-| nonzero | The uuids differ. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_uuid_init_from_buf.md b/docs/network/ble/ble_hs/other/functions/ble_uuid_init_from_buf.md
deleted file mode 100644
index 7c01959..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_uuid_init_from_buf.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_uuid\_init\_from\_buf</font>
-
-```c
-int
-ble_uuid_init_from_buf(
- ble_uuid_any_t *uuid,
- const void *buf,
- size_t len
-)
-```
-
-### Description
-
-Constructs a UUID object from a byte array.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| uuid | On success, this gets populated with the constructed UUID. |
-| buf | The source buffer to parse. |
-| len | The size of the buffer, in bytes. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| 0 | Success. |
-| BLE\_HS\_EINVAL | The source buffer does not contain a valid uuid. |
diff --git a/docs/network/ble/ble_hs/other/functions/ble_uuid_to_str.md b/docs/network/ble/ble_hs/other/functions/ble_uuid_to_str.md
deleted file mode 100644
index e5fbb13..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_uuid_to_str.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_uuid\_to\_str</font>
-
-```c
-char *
-ble_uuid_to_str(
- const ble_uuid_t *uuid,
- char *dst
-)
-```
-
-### Description
-
-Converts the specified UUID to its string representation. Example string representations: <ul><li>16-bit: 0x1234</li> <li>32-bit: 0x12345678</li> <li>128-bit: 12345678-1234-1234-1234-123456789abc</li></ul>
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| uuid | The source UUID to convert. |
-| dst | The destination buffer. |
-
-### Returned values
-
-A pointer to the supplied destination buffer.
diff --git a/docs/network/ble/ble_hs/other/functions/ble_uuid_u16.md b/docs/network/ble/ble_hs/other/functions/ble_uuid_u16.md
deleted file mode 100644
index 4773081..0000000
--- a/docs/network/ble/ble_hs/other/functions/ble_uuid_u16.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">ble\_uuid\_u16</font>
-
-```c
-uint16_t
-ble_uuid_u16(const ble_uuid_t *uuid)
-```
-
-### Description
-
-Converts the specified 16-bit UUID to a uint16\_t.
-
-### Parameters
-
-| *Parameter* | *Description* |
-|-------------|---------------|
-| uuid | The source UUID to convert. |
-
-### Returned values
-
-| *Value* | *Condition* |
-|---------|-------------|
-| The converted integer | Success. |
-| 0 | The specified uuid is not 16 bits. |
diff --git a/docs/network/ble/ble_hs/other/mdtoc.md b/docs/network/ble/ble_hs/other/mdtoc.md
deleted file mode 100644
index 319e4ea..0000000
--- a/docs/network/ble/ble_hs/other/mdtoc.md
+++ /dev/null
@@ -1,16 +0,0 @@
- - 'Other':
- - toc: 'network/ble/ble_hs/other/other.md'
- - 'Functions':
- - 'ble_eddystone_set_adv_data_uid': 'network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_uid.md'
- - 'ble_eddystone_set_adv_data_url': 'network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_url.md'
- - 'ble_hs_evq_set': 'network/ble/ble_hs/other/functions/ble_hs_evq_set.md'
- - 'ble_hs_mbuf_att_pkt': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_att_pkt.md'
- - 'ble_hs_mbuf_from_flat': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_from_flat.md'
- - 'ble_hs_mbuf_to_flat': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_to_flat.md'
- - 'ble_hs_sched_reset': 'network/ble/ble_hs/other/functions/ble_hs_sched_reset.md'
- - 'ble_hs_synced': 'network/ble/ble_hs/other/functions/ble_hs_synced.md'
- - 'ble_ibeacon_set_adv_data': 'network/ble/ble_hs/other/functions/ble_ibeacon_set_adv_data.md'
- - 'ble_uuid_cmp': 'network/ble/ble_hs/other/functions/ble_uuid_cmp.md'
- - 'ble_uuid_init_from_buf': 'network/ble/ble_hs/other/functions/ble_uuid_init_from_buf.md'
- - 'ble_uuid_to_str': 'network/ble/ble_hs/other/functions/ble_uuid_to_str.md'
- - 'ble_uuid_u16': 'network/ble/ble_hs/other/functions/ble_uuid_u16.md'
diff --git a/docs/network/ble/ble_hs/other/other.md b/docs/network/ble/ble_hs/other/other.md
deleted file mode 100644
index ced789b..0000000
--- a/docs/network/ble/ble_hs/other/other.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">NimBLE Host Other Reference</font>
-
-### Introduction
-
-This section is a reference on miscellaneous parts of the NimBLE host which don't fit anywhere else!
-
-### Header
-
-```c
-#include "host/ble_hs.h"
-```
-
-### Definitions
-
-None.
-
-### Functions
-
-| Function | Description |
-|----------|-------------|
-| [ble_eddystone_set_adv_data_uid](functions/ble_eddystone_set_adv_data_uid.md) | Configures the device to advertise eddystone UID beacons. |
-| [ble_eddystone_set_adv_data_url](functions/ble_eddystone_set_adv_data_url.md) | Configures the device to advertise eddystone URL beacons. |
-| [ble_hs_evq_set](functions/ble_hs_evq_set.md) | Designates the specified event queue for NimBLE host work. |
-| [ble_hs_mbuf_att_pkt](functions/ble_hs_mbuf_att_pkt.md) | Allocates an mbuf suitable for an ATT command packet. |
-| [ble_hs_mbuf_from_flat](functions/ble_hs_mbuf_from_flat.md) | Allocates a an mbuf and fills it with the contents of the specified flat buffer. |
-| [ble_hs_mbuf_to_flat](functions/ble_hs_mbuf_to_flat.md) | Copies the contents of an mbuf into the specified flat buffer. |
-| [ble_hs_sched_reset](functions/ble_hs_sched_reset.md) | Causes the host to reset the NimBLE stack as soon as possible. |
-| [ble_hs_synced](functions/ble_hs_synced.md) | Indicates whether the host has synchronized with the controller. |
-| [ble_ibeacon_set_adv_data](functions/ble_ibeacon_set_adv_data.md) | Configures the device to advertise iBeacons. |
-| [ble_uuid_cmp](functions/ble_uuid_cmp.md) | Compares two Bluetooth UUIDs. |
-| [ble_uuid_init_from_buf](functions/ble_uuid_init_from_buf.md) | Constructs a UUID object from a byte array. |
-| [ble_uuid_to_str](functions/ble_uuid_to_str.md) | Converts the specified UUID to its string representation. |
-| [ble_uuid_u16](functions/ble_uuid_u16.md) | Converts the specified 16-bit UUID to a uint16\_t. |
diff --git a/docs/network/ble/ble_intro.md b/docs/network/ble/ble_intro.md
deleted file mode 100644
index 63d35ae..0000000
--- a/docs/network/ble/ble_intro.md
+++ /dev/null
@@ -1,66 +0,0 @@
-## BLE Introduction
-
-Apache Mynewt offers the world's first fully open-source Bluetooth Low Energy (BLE) or Bluetooth Smart stack fully compliant with Bluetooth 5 specifications with support for Bluetooth Mesh. It is called NimBLE.
-
-BLE technology operates in the unlicensed industrial, scientific and medical (ISM) band at 2.4 to 2.485 GHz which is available in most countries. It uses a spread spectrum, frequency hopping, full-duplex signal. BLE FHSS employs 40 2-MHz-wide channels to ensure greater reliability over longer distances. It also features 0-dBm (1 mW) power output and a typical maximum range of 50 meters.
-With Bluetooth 5 specification range can be increased 4 times and speed 2 time.
-
-Note that BLE is not compatible with standard (BR/EDR aka classic) Bluetooth.
-<br>
-
-### Features
-
-NimBLE complies with Bluetooth Core Specification 5.0 which makes it an ideal wireless technology for the Internet of Things (IoT).
-
-* LE Advertising Extensions
-* 2Msym/s PHY for higher throughput
-* Coded PHY for LE Long Range
-* Advertising Extensions
-* High Duty Cycle Non-Connectable Advertising
-* Channel Selection Algorithm #2 to utilize channels in more efficient way.
-* LE Privacy 1.2 for frequent changes to the device address to make it difficult to track for outsiders
-* LE Secure Connections featuring FIPS-compliant algorithms.
-* LE Data Length Extension for higher throughput
-* **Coming Soon**: Assigning an Internet Protocol (IP) address (complaint with the IPv6 or 6LoWPAN standard) to a Bluetooth device through Internet Protocol Support Profile (IPSP)
-
-The Bluetooth 5 is backward compatible with previous Bluetooth version 4.2 which is also supported by Apache Mynewt.
-
-### Bluetooth Mesh features
-
-Bluetooth Mesh is a great addition to and opens a wide range of new possibilities for the IoT connectivity space. NimBLE fully supports the following Bluetooth Mesh features:
-
-* Advertising and GATT bearers
-* PB-GATT and PB-ADV provisioning
-* Foundation Models (server role)
-* Relay support
-* GATT Proxy
-
-### Components
-
-A Bluetooth low energy stack (NimBLE included) consists of two components with several subcomponents:
-
-* **Controller**
- * **Physical Layer**: adaptive frequency-hopping Gaussian Frequency Shift Keying (GFSK) radio using 40 RF channels (0-39), with 2 MHz spacing.
- * **Link Layer**: with one of five states (Standby, Advertising, Scanning, Initiating, Connection states) active at any time
-
-* **Host**
- * **Logical Link Control and Adaptation Protocol (L2CAP)**: provides logical channels, named L2CAP channels, which are multiplexed over one or more logical links to provide packet segmentation and reassembly, flow control, error control, streaming, QoS etc.
- * **Security Manager (SM)**: uses Security Manager Protocol (SMP) for pairing and transport specific key distribution for securing radio communication
- * **Attribute protocol (ATT)**: allows a device (*Server*) to expose certain pieces of data, known as *Attributes*, to another device (*Client*)
- * **Generic Attribute Profile (GATT)**: a framework for using the ATT protocol to exchange attributes encapsulated as *Characteristics* or *Services*
- * **Generic Access Profile (GAP)**: a base profile which all Bluetooth devices implement, which in the case of LE, defines the Physical Layer, Link Layer, L2CAP, Security Manager, Attribute Protocol and Generic Attribute Profile.
- * **Host Controller Interface (HCI)**: the interface between the host and controller either through software API or by a hardware interface such as SPI, UART or USB.
-
-Subsequent chapters in this manual will go into the details of the implementation of each component, APIs available, and things to consider while designing a NimBLE app.
-
-<br>
-
-### Example NimBLE projects
-
-Mynewt comes with two built-in projects that allow users to play with NimBLE, try the tutorials out with, and see how to use available services.
-
-1. **btshell** : A simple shell application which provides a basic interface to the host-side of the BLE stack (replaces deprecated **bletiny**).
-2. **bleprph**: A basic peripheral device with no user interface. It advertises automatically on startup, and resumes advertising whenever a connection is terminated. It supports a maximum of one connection.
-3. **blemesh**: A sample application for Bluetooth Mesh Node using on/off model.
-
-<br>
diff --git a/docs/network/ble/ble_mesh.md b/docs/network/ble/ble_mesh.md
deleted file mode 100644
index 663720a..0000000
--- a/docs/network/ble/ble_mesh.md
+++ /dev/null
@@ -1,88 +0,0 @@
-## Bluetooth Mesh
-
-### Introduction to Mesh
-
-Bluetooth Mesh is a new standard from Bluetooth SIG that was released in 2017. It
-enables many-to-many device communication (as opposed to point-to-point approach
-in BLE) and is optimised for large-scale networks like building automation or
-sensors network. It utilizes managed flood based approach where only
-mains-powered nodes relay messages making it very power efficient (battery
-powered low-power nodes that don't relay messages can operate in mesh network
-for years).
-
-Bluetooth Mesh is complementary to Bluetooth specification and requires
-features from 4.0 release only. This allows deployment of networks using hardware
-already available on the market.
-
-### Topology
-
-
-
-<br>
-<br>
-
-Bluetooth Mesh defines few features (roles) for devices in network. Those are:
-
-* Relay - receive and retransmit mesh messages over the advertising bearer to
- enable larger networks
-* Proxy - receive and retransmit mesh messages between GATT and advertising
- bearers.
-* Low Power - operate within a mesh network at significantly reduced receiver
- duty cycles only in conjunction with a node supporting the Friend feature
-* Friend - the ability to help a node supporting the Low Power feature to
- operate by storing messages destined for those nodes
-
-
-### Bearers
-
-Mesh Profile specification allows two kinds of bearers for transmitting data:
-
-* Advertising Bearer
- * Uses LE advertising to broadcast messages to all nodes that are listening
- at this time
- * Uses non-connectable advertising only
- * 29 octets of network message
-* GATT Bearer
- * Uses LE Connections to send messages
- * Uses standard GATT service (one for Provisioning and one for Proxy)
-
-
-### Provisioning
-
-Provisioning is a process of adding an unprovisioned device to a mesh network
-managed by a Provisioner. A Provisioner provides the unprovisioned device with
-provisioning data that allows it to become a mesh node (network key, current IV
-index and unicast address). A Provisioner is typically a smart phone or other
-mobile computing device.
-
-### Models
-
-Models define basic functionality of nodes on a mesh network. Mesh Profile
-Specification defines foundation models used to configure and manage network.
-Mesh Model Specification includes models defininig functionality that is
-standard across device types. Those consists of:
-
-* Generics - root models
- * On/Off
- * Level
- * Battery Server
- * Location
- * Client Property
- * and others
-* Sensors - defines a standard way of interfacing with sensors
-* Time and Scenes - defines a set of functionalities related to time and
- saved states on devices
-* Lighting - defines a set functionalities related to lighting control
-
-Complex models e.g. Lighting may contain other models eg Generic On/Off. The following
-image shows an example of Light Lightness Server Model.
-
-
-
-## Mesh Node features supported by Apache Mynewt
-
-* Advertising and GATT bearers
-* PB-GATT and PB-ADV provisioning
-* Foundation Models (server role)
-* Relay support
-* GATT Proxy
diff --git a/docs/network/ble/ble_sec.md b/docs/network/ble/ble_sec.md
deleted file mode 100644
index e92aece..0000000
--- a/docs/network/ble/ble_sec.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## BLE Security
-
-The Bluetooth Low Energy security model includes five distinct security concepts as listed below. For detailed specifications, see BLUETOOTH SPECIFICATION Version 4.2 [Vol 1, Part A].
-
-* **Pairing**: The process for creating one or more shared secret keys. In LE a single link key is generated by combining contributions from each device into a link key used during pairing.
-
-* **Bonding**: The act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair.
-
-* **Device authentication**: Verification that the two devices have the same keys (verify device identity)
-
-* **Encryption**: Keeps message confidential. Encryption in Bluetooth LE uses AES-CCM cryptography and is performed in the *Controller*.
-
-* **Message integrity**: Protects against message forgeries.
-
-Bluetooth LE uses four association models depending on the I/O capabilities of the devices.
-
-* **Just Works**: designed for scenarios where at least one of the devices does not have a display capable of displaying a six digit number nor does it have a keyboard capable of entering six decimal digits.
-
-* **Numeric Comparison**: designed for scenarios where both devices are capable of displaying a six digit number and both are capable of having the user enter "yes" or "no". A good example of this model is the cell phone / PC scenario.
-
-* **Out of Band**: designed for scenarios where an Out of Band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic numbers used in the pairing process.
-
-* **Passkey Entry**: designed for the scenario where one device has input capability but does not have the capability to display six digits and the other device has output capabilities. A good example of this model is the PC and keyboard scenario.
-
-### Key Generation
-
-Key generation for all purposes in Bluetooth LE is performed by the *Host* on each LE device independent of any other LE device.
-
-### Privacy Feature
-Bluetooth LE supports an optional feature during connection mode and connection procedures that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis.
-
-There are two variants of the privacy feature.
-
-* In the first variant, private addresses are resolved and generated by the *Host*.
-* In the second variant, private addresses are resolved and generated by the *Controller* without involving the Host after the Host provides the Controller device identity information. The Host may provide the Controller with a complete resolving list or a subset of the resolving list.
-Device filtering becomes possible in the second variant when address resolution is performed in the Controller because the peer’s device identity address can be resolved prior to checking whether it is in the white list.
-
-**Note**: When address resolution is performed exclusively in the Host, a device may experience increased power consumption because device filtering must be disabled. For more details on the privacy feature, refer to BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C] (Published 02 December 2014), Page 592.
diff --git a/docs/network/ble/ble_setup/ble_addr.md b/docs/network/ble/ble_setup/ble_addr.md
deleted file mode 100644
index 4abab4c..0000000
--- a/docs/network/ble/ble_setup/ble_addr.md
+++ /dev/null
@@ -1,57 +0,0 @@
-## Configure an Address
-
-A BLE device needs an address to do just about anything. For information on
-the various types of Bluetooth addresses, see the
-[NimBLE Host Identity Reference](../../../network/ble/ble_hs/ble_hs_id/ble_hs_id.md).
-
-There are several methods for assigning an address to a NimBLE device. The
-available options are documented below:
-
-### Method 1: Configure nRF hardware with a public address
-
-When Mynewt is running on a Nordic nRF platform, the NimBLE controller will
-attempt to read a public address out of the board's FICR or UICR registers.
-The controller uses the following logic while trying to read an address from
-hardware:
-
-1. If the *DEVICEADDRTYPE* FICR register is written, read the address
-programmed in the *DEVICEADDR[0]* and *DEVICEADDR[1]* FICR registers.
-2. Else if the upper 16 bits of the *CUSTOMER[1]* UICR register are 0, read the address programmed in the *CUSTOMER[0]* and *CUSTOMER[1]* UCI registers.
-3. Else, no address available.
-
-### Method 2: Hardcode a public address in the Mynewt target
-
-The NimBLE controller package exports a
-[syscfg](../../../os/modules/sysinitconfig/sysinitconfig.md) setting called
-`BLE_PUBLIC_DEV_ADDR`. This setting can be overridden at the application or
-target level to configure a public Bluetooth address. For example, a target
-can assign the public address *11:22:33:44:55:66* as follows:
-
-```
-syscfg.vals:
- BLE_PUBLIC_DEV_ADDR: '(uint8_t[6]){0x66, 0x55, 0x44, 0x33, 0x22, 0x11}'
-```
-
-This setting takes the form of a C expression. Specifically, the value is a
-designated initializer expressing a six-byte array. Also note that the bytes
-are reversed, as an array is inherently little-endian, while addresses are
-generally expressed in big-endian.
-
-Note: this method takes precedence over method 1. Whatever is written to the
-`BLE_PUBLIC_DEV_ADDR` setting is the address that gets used.
-
-### Method 3: Configure a random address at runtime
-
-Random addresses get configured through the NimBLE host. The following two
-functions are used in random address configuration:
-
-* [ble_hs_id_gen_rnd](../../../network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd/): Generates a new random address.
-* [ble_hs_id_set_rnd](../../../network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd/): Sets the device's random address.
-
-For an example of how this is done, see the
-[BLE iBeacon tutorial](../../../os/tutorials/ibeacon/).
-
-<br>
-
-*Note:* A NimBLE device can be configured with multiple addresses; at most one
-of each address type.
diff --git a/docs/network/ble/ble_setup/ble_lp_clock.md b/docs/network/ble/ble_setup/ble_lp_clock.md
deleted file mode 100644
index 3d8e33e..0000000
--- a/docs/network/ble/ble_setup/ble_lp_clock.md
+++ /dev/null
@@ -1,82 +0,0 @@
-## Configure clock for controller
-
-The NimBLE stack uses OS cputime for scheduling various events inside controller.
-Since the code of controller is optimized to work with 32768 Hz clock, the OS
-cputime has to be configured accordingly.
-
-To make things easier, controller package (`net/nimble/controller`) defines new
-system configuration setting `BLE_LP_CLOCK` as sets it to `1` so other packages
-can be configured if necessary. The next section describes configuration required
-for controller to work properly.
-
-### System configuration
-
-**Note:** All BSPs based on nRF5x have below settings automatically applied when
-`BLE_LP_CLOCK` is set, there is no need to configure this in application.
-
-The following things need to be configured for NimBLE controller to work properly:
-
-- OS cputime frequency shall be set to `32768`
-- OS cputime timer source shall be set to 32768 Hz clock source
-- Default 1 MHz clock source can be disabled if not used by application
-- 32768 Hz clock source shall be enabled
-- Crystal settling time shall be set to non-zero value (see [below](#crystal-settle-time-configuration))
-
-For example, on nRF52 platform timer 5 can be used as source for 32768 Hz clock.
-Also, timer 0 can be disabled since this is the default source for OS cputime
-clock and is no longer used. The configuration will look as below:
-
-```
-syscfg.vals:
- OS_CPUTIME_FREQ: 32768
- OS_CPUTIME_TIMER_NUM: 5
- TIMER_0: 0
- TIMER_5: 1
- BLE_XTAL_SETTLE_TIME: 1500
-```
-
-On nRF51 platform the only difference is to use timer 3 instead of timer 5.
-
-On platforms without 32768 Hz crystal available it usually can be synthesized by
-setting `XTAL_32768_SYNTH` to `1` - this is also already configured in existing
-BSPs.
-
-### Clock accuracy
-
-Controller needs to know clock source accuracy since this affects sleep time and has
-to be taken into account when scheduling Bluetooth events. The configuration variable
-`BLE_LL_OUR_SCA` defines clock drift (in ppm) while `BLE_LL_MASTER_SCA` is an
-enumerated value derived from clock drift value and shall be set as follows:
-
-- SCA between 251 and 500 ppm = 0
-- SCA between 151 and 250 ppm = 1
-- SCA between 101 and 150 ppm = 2
-- SCA between 76 and 100 ppm = 3
-- SCA between 51 and 75 ppm = 4
-- SCA between 31 and 50 ppm = 5
-- SCA between 21 and 30 ppm = 6
-- SCA between 0 and 20 ppm = 7
-
-The default value of 60 ppm is large enough to work with most platforms with LFXO.
-For platforms without LFXO (e.g. using internal RC oscillator or synthesized clock
-instead) it shall be changed if necessary.
-
-Note that using clock drift value larger than necessary will impact battery life since
-controller will use wider margin for scheduling Bluetooth events thus reducing sleep
-time. For this reason it is recommended to adjust clock drift value to match clock
-source used on platform.
-
-### Crystal settle time configuration
-
-The configuration variable `BLE_XTAL_SETTLE_TIME` is used by the controller to turn
-on the necessary clock source(s) for the radio and associated peripherals prior to
-Bluetooth events (advertising, scanning, connections, etc). For the nRF5x platforms,
-the HFXO needs to be turned on prior to using the radio and the `BLE_XTAL_SETTLE_TIME`
-must be set to accommodate this time. The amount of time required is board dependent,
-so users must characterize their hardware and set `BLE_XTAL_SETTLE_TIME` accordingly.
-The current value of 1500 microseconds is a fairly long time and was intended to work
-for most, if not all, platforms.
-
-Note that changing this time will impact battery life with the amount depending on the
-application. The HFXO draws a fairly large amount of current when running so keeping
-this time as small as possible will reduce overall current drain.
\ No newline at end of file
diff --git a/docs/network/ble/ble_setup/ble_setup_intro.md b/docs/network/ble/ble_setup/ble_setup_intro.md
deleted file mode 100644
index 3c9af9d..0000000
--- a/docs/network/ble/ble_setup/ble_setup_intro.md
+++ /dev/null
@@ -1,6 +0,0 @@
-## NimBLE setup
-
-Most NimBLE initialization is done automatically by
-[sysinit](../../../os/modules/sysinitconfig/sysinitconfig.md). This section
-documents the few bits of initialization that an application must perform
-manually.
diff --git a/docs/network/ble/ble_setup/ble_sync_cb.md b/docs/network/ble/ble_setup/ble_sync_cb.md
deleted file mode 100644
index d6bbc24..0000000
--- a/docs/network/ble/ble_setup/ble_sync_cb.md
+++ /dev/null
@@ -1,75 +0,0 @@
-## Respond to *sync* and *reset* events
-
-### sync
-
-The NimBLE stack is inoperable while the host and controller are out of sync.
-In a combined host-controller app, the sync happens immediately at startup.
-When the host and controller are separate, sync typically occurs in under a
-second after the application starts. An application learns when sync is
-achieved by configuring the host's *sync callback*: `ble_hs_cfg.sync_cb`. The
-host calls the sync callback whenever sync is acquired. The sync callback has
-the following form:
-
-```
-typedef void ble_hs_sync_fn(void);
-```
-
-Because the NimBLE stack begins in the unsynced state, the application should
-delay all BLE operations until the sync callback has been called.
-
-### reset
-
-Another event indicated by the host is a *controller reset*. The NimBLE stack
-resets itself when a catstrophic error occurs, such as loss of communication
-between the host and controller. Upon resetting, the host drops all BLE
-connections and loses sync with the controller. After a reset, the application
-should refrain from using the host until sync is again signalled via the sync
-callback.
-
-An application learns of a host reset by configuring the host's *reset
-callback*: `ble_hs_cfg.reset_cb`. This callback has the following form:
-
-```
-typedef void ble_hs_reset_fn(int reason);
-```
-
-The `reason` parameter is a
-[NimBLE host return code](../../../network/ble/ble_hs/ble_hs_return_codes/).
-
-### Example
-
-The following example demonstrates the configuration of the sync and reset
-callbacks.
-
-```c
-#include "sysinit/sysinit.h"
-#include "console/console.h"
-#include "host/ble_hs.h"
-
-static void
-on_sync(void)
-{
- /* Begin advertising, scanning for peripherals, etc. */
-}
-
-static void
-on_reset(int reason)
-{
- console_printf("Resetting state; reason=%d\n", reason);
-}
-
-int
-main(void)
-{
- /* Initialize all packages. */
- sysinit();
-
- ble_hs_cfg.sync_cb = on_sync;
- ble_hs_cfg.reset_cb = on_reset;
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-}
-```
diff --git a/docs/network/ble/btshell/btshell_GAP.md b/docs/network/ble/btshell/btshell_GAP.md
deleted file mode 100644
index eb5ab59..0000000
--- a/docs/network/ble/btshell/btshell_GAP.md
+++ /dev/null
@@ -1,349 +0,0 @@
-
-## GAP API for btshell
-
-<br>
-
-Generic Access Profile (GAP) defines the generic procedures related to discovery of Bluetooth devices (idle mode procedures) and link management aspects of connecting to Bluetooth devices (connecting mode procedures). It also defines procedures related to use of different security levels.
-
-Several different modes and procedures may be performed simultaneously over an LE physical transport. The following modes and procedures are defined for use over an LE physical transport:
-
-1. **Broadcast mode and observation procedure**
- - These allow two devices to communicate in a unidirectional connectionless manner using the advertising events.
-2. **Discovery modes and procedures**
- - All devices shall be in either non-discoverable mode or one of the discoverable modes.
- - A device in the discoverable mode shall be in either the general discoverable mode or the limited discoverable mode.
- - A device in non-discoverable mode will not be discovered by any device that is performing either the general discovery procedure or the limited discovery procedure.
-3. **Connection modes and procedures**
- - allow a device to establish a connection to another device.
- - allow updating of parameters of the connection
- - allow termination of the connection
-4. **Bonding modes and procedures**
- - Bonding allows two connected devices to exchange and store security and identity information to create a trusted relationship.
- - Bonding can occur only between two devices in bondable mode.
-
-
-<br>
-
-### Available commands
-
-Parameters default values are marked red.
-
-## Configuration
-
-|**Command** | **Parmeters** | ** Possible values** | **Description** |
-|-------------|------------------|---------------------------|------------------------------------------------------------|
-|**set** | | | Set configuration options |
-| |addr | XX:XX:XX:XX:XX:XX | Local device address |
-| |addr_type | `public` | Local device address type |
-| | | random | Use random address for scan requests |
-| |mtu | [23-UINT16_MAX] | GATT Maximum Transmission Unit (MTU) |
-| |irk | XX:XX:XX... | Local Identity Resolving Key (16 byte |
-|**set-priv-mode** | | | Set privacy mode for device |
-| | addr | XX:XX:XX:XX:XX:XX | Remote device address |
-| | addr_type | `public` | Remote device public address type |
-| | | random | Remote device random address type |
-| | mode | [`0`-1] | 0 - use network privacy, 1 - use device privacy |
-|**white-list**| | | Add devices to white list <br> (this command accepts multiple instances of addr and addr_type parameters) |
-| | addr | XX:XX:XX:XX:XX:XX | Remote device address |
-| | addr_type | `public` | Remote device public address type |
-| | | random | Remote device random address type |
-
-## Device discovery and connection
-
-|**Command** | **Parmeters** | ** Possible values** | **Description** |
-|-------------|------------------|---------------------------|------------------------------------------------------------|
-|**scan** | | | Discover remote devices |
-| |cancel | | cancel ongoing scan procedure |
-| |extended | `none` | Start legacy scan |
-| | | 1M | Start extended scan on 1M PHY |
-| | | coded | Start extended scan on Coded PHY |
-| | | both | Start extended scan on both PHYs |
-| |duration | [1-`INT32_MAX`], | Duration of scan in milliseconds |
-| |limited | [`0`-1] | Use limited discovery procedure |
-| |passive | [`0`-1] | Use passive scan |
-| |interval | [`0`-UINT16_MAX] | Scan interval, if 0 use stack's default |
-| |window | [`0`-UINT16_MAX] | Scan window, if 0 use stack's default |
-| |filter | `no_wl` | Scan filter policy - Accept all advertising packets |
-| | | use_wl | Accept only advertising packets from devices on White List |
-| | | no_wl_inita | Accept all advertising packets (including directed RPA) |
-| | | use_wl_inita | Accept only advertising packets from devices on White List <br>(including directed RPA)|
-| |nodups | [`0`-1] | Disable duplicates filtering |
-| |own_addr_type | `public` | Use public address for scan requests |
-| | | random | Use random address for scan requests |
-| | | rpa_pub | Use RPA address for scan requests <br> (fallback to public if no IRK) |
-| | | rpa_rnd | Use RPA address for scan requests <br> (fallback to random if no IRK) |
-| |extended_duration | [`0`-UINT16_MAX] | Duration of extended scan in 10 milliseconds |
-| |extended_period | [`0`-UINT16_MAX] | Periodic scan interval in 1.28 seconds (0 disabled) |
-| |longrange_interval| [`0`-UINT16_MAX] | Scan interval for Coded Scan , if 0 use stack's default |
-| |longrange_window | [`0`-UINT16_MAX] | Scan window for Coded Scan , if 0 use stack's default |
-| |longrange_passive | [`0`-1] | Use passive scan for Coded Scan |
-|**connect** | | | Initiate connection to remote device |
-| |cancel | | Cancel ongoing connection procedure |
-| |extended |`none` | Use legacy connection procedure |
-| | |1M | Extended connect using 1M PHY scan parameters |
-| | |coded | Extended connect using Coded PHY scan parameters |
-| | |both | Extended connect using 1M and Coded PHYs scan parameters |
-| | |all | Extended connect using 1M and Coded PHYs scan parameters <br> (Provide also connection parameters for 2M PHY) |
-| |peer_addr_type | `public` | Remote device public address type |
-| | | random | Remote device random address type |
-| | | public_id | Remote device public address type (Identity) |
-| | | random_id | Remote device random address type (Identity) |
-| |peer_addr | XX:XX:XX:XX:XX:XX | Remote device address |
-| |own_addr_type | `public` | Use public address for scan requests |
-| | | random | Use random address for scan requests |
-| | | rpa_pub | Use RPA address for scan requests <br> (fallback to public if no IRK) |
-| | | rpa_rnd | Use RPA address for scan requests <br> (fallback to random if no IRK) |
-| |duration | [`0`-INT32_MAX] | Connection attempt duration, if 0 use stack's default |
-| |scan_interval | [0-UINT16_MAX] | Scan interval, default: 0x0010 |
-| |scan_window | [0-UINT16_MAX] | Scan window, default: 0x0010 |
-| |interval_min | [0-UINT16_MAX] | Minimum connection interval, default: 30 |
-| |interval_max | [0-UINT16_MAX] | Maximum connection interval, default: 50 |
-| |latency | [UINT16] | Connection latency, default: 0 |
-| |timeout | [UINT16] | Connection timeout, default: 0x0100 |
-| |min_conn_event_len| [UINT16] | Minimum length of connection event, default: 0x0010 |
-| |max_conn_event_len| [UINT16] | Maximum length of connection event, default: 0x0300 |
-| |coded_scan_interval | [0-UINT16_MAX] | Coded PHY Scan interval, default: 0x0010 |
-| |coded_scan_window | [0-UINT16_MAX] | Coded PHY Scan window, default: 0x0010 |
-| |coded_interval_min | [0-UINT16_MAX] | Coded PHY Minimum connection interval, default: 30 |
-| |coded_interval_max | [0-UINT16_MAX] | Coded PHY Maximum connection interval, default: 50 |
-| |coded_latency | [UINT16] | Coded PHY Connection latency, default: 0 |
-| |coded_timeout | [UINT16] | Coded PHY Connection timeout, default: 0x0100 |
-| |coded_min_conn_event_len| [UINT16] | Coded PHY Minimum length of connection event, default: 0x0010 |
-| |coded_max_conn_event_len| [UINT16] | Coded PHY Maximum length of connection event, default: 0x0300 |
-| |2M_scan_interval | [0-UINT16_MAX] | 2M PHY Scan interval, default: 0x0010 |
-| |2M_scan_window | [0-UINT16_MAX] | 2M PHY Scan window, default: 0x0010 |
-| |2M_interval_min | [0-UINT16_MAX] | 2M PHY Minimum connection interval, default: 30 |
-| |2M_interval_max | [0-UINT16_MAX] | 2M PHY Maximum connection interval, default: 50 |
-| |2M_latency | [UINT16] | 2M PHY Connection latency, default: 0 |
-| |2M_timeout | [UINT16] | 2M PHY Connection timeout, default: 0x0100 |
-| |2M_min_conn_event_len| [UINT16] | 2M PHY Minimum length of connection event, default: 0x0010 |
-| |2M_max_conn_event_len| [UINT16] | 2M PHY Maximum length of connection event, default: 0x0300 |
-|**disconnect** | | | Disconnect exisiting connection |
-| |conn | [UINT16] | Connection handle |
-| |reason | [UINT8] | Disconnect reason |
-|**show-addr** | | | Show local public and random identity addresses |
-|**show-conn** | | | Show current connections |
-|**conn-rssi**| | | Obtain RSSI of specified connection |
-| |conn | [UINT16] | Connection handle |
-|**conn-update-params**| | | Update parameters of specified connection |
-| |conn | [UINT16] | Connection handle |
-| |interval_min | [0-UINT16_MAX] | Minimum connection interval, default: 30 |
-| |interval_max | [0-UINT16_MAX] | Maximum connection interval, default: 50 |
-| |latency | [UINT16] | Connection latency, default: 0 |
-| |timeout | [UINT16] | Connection timeout, default: 0x0100 |
-| |min_conn_event_len| [UINT16] | Minimum length of connection event, default: 0x0010 |
-| |max_conn_event_len| [UINT16] | Maximum length of connection event, default: 0x0300 |
-|**conn-datalen**| | | Set DLE parmaeters for connection |
-| |conn | [UINT16] | Connection handle |
-| |octets | [UINT16] | Maximum transmission packet size |
-| |time | [UINT16] | Maximum transmission packet time |
-|**phy-set** | | | Set prefered PHYs used for connection |
-| |conn | [UINT16] | Connection handle |
-| |tx_phys_mask | [UINT8] | Prefered PHYs on TX is mask of following bits<br>0x00 - no preference<br>0x01 - 1M, 0x02 - 2M, 0x04 - Coded
-| |rx_phys_mask | [UINT8] | Prefered PHYs on RX is mask of following bits<br>0x00 - no preference<br>0x01 - 1M, 0x02 - 2M, 0x04 - Coded
-| |phy_opts | [UINT16] | Options for Coded PHY<br> 0 - any coding, 1 - prefer S2, 2 - prefer S8 |
-|**phy-set-default** | | | Set default prefered PHYs used for new connection |
-| |tx_phys_mask | [UINT8] | Prefered PHYs on TX is mask of following bits<br>0x00 - no preference<br>0x01 - 1M, 0x02 - 2M, 0x04 - Coded
-| |rx_phys_mask | [UINT8] | Prefered PHYs on RX is mask of following bits<br>0x00 - no preference<br>0x01 - 1M, 0x02 - 2M, 0x04 - Coded
-|**phy-read** | | | Read connection current PHY |
-| |conn | [UINT16] | Connection handle |
-|**l2cap-update** | | | Update connection parameters |
-| |interval_min | [0-UINT16_MAX] | Minimum connection interval, default: 30 |
-| |interval_max | [0-UINT16_MAX] | Maximum connection interval, default: 50 |
-| |latency | [UINT16] | Connection latency, default: 0 |
-| |timeout | [UINT16] | Connection timeout, default: 0x0100 |
-
-## Security
-
-|**Command** | **Parmeters** | ** Possible values** | **Description** |
-|-------------|------------------|---------------------------|------------------------------------------------------------|
-|**security-set-data** | | | Set security configuration |
-| |oob-flag | [`0`-1] | Set Out-Of-Band (OOB) flag in Security Manager |
-| |mitm-flag | [`0`-1] | Set Man-In-The-Middle (MITM) flag in Security Manager |
-| |io_capabilities | 0 | Set Input-Output Capabilities to "DisplayOnly" |
-| | | 1 | Set Input-Output Capabilities to "DisplayYesNo" |
-| | | 2 | Set Input-Output Capabilities to "KeyboardOnly" |
-| | | 3 | Set Input-Output Capabilities to "NoInputNoOutput" |
-| | | 4 | Set Input-Output Capabilities to "KeyboardDisplay" |
-| |our_key_dist | [UINT8] | Set Local Keys Distribution, this is a bit field of possible values: <br> LTK (0x01), IRK (0x02), CSRK (0x04), LTK_SC(0x08) |
-| |their_key_dist | [UINT8] | Set Remote Keys Distribution, this is a bit field of possible values: <br> LTK (0x01), IRK (0x02), CSRK (0x04), LTK_SC(0x08) |
-| |bonding-flag | [`0`-1] | Set Bonding flag in Security Manager |
-| |sc-flag | [`0`-1] | Set Secure Connections flag in Security Manager |
-|**security-pair**| | | Start pairing procedure |
-| |conn | [UINT16] | Connection handle |
-|**security-encryption**| | | Start encryption procedure |
-| |conn | [UINT16] | Connection handle |
-| |ediv | [UINT16] | EDIV for LTK to use (use storage if not provided) |
-| |rand | [UINT64] | Rand for LTK |
-| |ltk | XX:XX:XX... | LTK (16 bytes) |
-|**security-start**| | | Start security procedure <br>(This starts either pairing or encryption depending if keys are stored)|
-| |conn | [UINT16] | Connection handle |
-|**auth-passkey**| | | Reply to Passkey request |
-| |conn | [UINT16] | Connection handle |
-| |action | [UINT16] | Action to reply (as received in event) |
-| |key | [0-999999] | Passkey to reply (Input or Display action) |
-| |oob | XX:XX:XX:... | Out-Of-Band secret (16 bytes) (OOB action) |
-| |yesno | Yy-Ny | Confirm passkey (for Passkey Confirm action) |
-
-## Advertising with Extended Advertising enabled
-
-|**Command** | **Parmeters** | ** Possible values** | **Description** |
-|-------------|------------------|---------------------------|------------------------------------------------------------|
-|**advertise-configure** | | | Configure new advertising instance |
-| |instance | [`0`-UINT8_MAX] | Advertising instance |
-| |connectable | [`0`-1] | Use connectable advertising |
-| |scannable | [`0`-1] | Use scannable advertising |
-| |peer_addr_type | `public` | Remote device public address type |
-| | | random | Remote device random address type |
-| | | public_id | Remote device public address type (Identity) |
-| | | random_id | Remote device random address type (Identity) |
-| |peer_addr | XX:XX:XX:XX:XX:XX | Remote device address - if provided perform directed advertising |
-| |own_addr_type | `public` | Use public address for scan requests |
-| | | random | Use random address for scan requests |
-| | | rpa_pub | Use RPA address for scan requests <br> (fallback to public if no IRK) |
-| | | rpa_rnd | Use RPA address for scan requests <br> (fallback to random if no IRK) |
-| |channel_map | [`0`-UINT8_MAX} | Primary advertising channels map. If 0 use all channels. |
-| |filter | `none` | Advertising filter policy - no filtering, no whitelist used|
-| | | scan | process all connection requests but only scans from white list|
-| | | conn | process all scan request but only connection requests from white list|
-| | | both | ignore all scan and connection requests unless in white list|
-| |interval_min | [`0`-UINT32_MAX] | Minimum advertising interval in 0.625 miliseconds <br> If 0 use stack default. |
-| |interval_max | [`0`-UINT32_MAX] | Maximum advertising interval in 0.625 miliseconds <br> If 0 use stack default. |
-| |rx_power | [-127 - `127`] | Advertising TX power in dBm |
-| |primary_phy | `1M` | Use 1M PHY on primary advertising channels |
-| | | `coded` | Use Coded PHY on primary advertising channels |
-| |secondary_phy | `1M` | Use 1M PHY on secondary advertising channels |
-| | | `coded` | Use coded PHY on primary advertising channels |
-| | | `2M` | Use 2M PHY on primary advertising channels |
-| |sid | [`0`-16] | Adsertising instance SID |
-| |high_duty | [`0`-1] | Use high_duty advertising |
-| |anonymous | [`0`-1] | Use anonymous advertising |
-| |legacy | [`0`-1] | Use legacy PDUs for advertising |
-| |include_tx_power | [`0`-1] | Include TX power information in advertising PDUs |
-| |scan_req_notif | [`0`-1] | Enable SCAN_REQ notifications |
-|**advertise-set-addr**| | | Configure *random* adress for instance |
-| |instance | [`0`-UINT8_MAX] | Advertising instance |
-| |addr | XX:XX:XX:XX:XX:XX | Random address |
-|**advertise-set-adv-data**| | | Configure advertising instance ADV_DATA. This allow to configure following TLVs:|
-|**advertise-set-scan-rsp**| | | Configure advertising instance SCAN_RSP. This allow to configure following TLVs:|
-| |instance | [`0`-UINT8_MAX] | Advertising instance |
-| |flags | [`0`-UINT8_MAX] | Flags value |
-| |uuid16 | [UINT16] | 16-bit UUID value (can be passed multiple times) |
-| |uuid16_is_complete| [`0`-1] | I 16-bit UUID list is complete |
-| |uuid32 | [UINT32] | 32-bit UUID value (can be passed multiple times) |
-| |uuid32_is_complete| [`0`-1] | I 32-bit UUID list is complete |
-| |uuid128 | XX:XX:XX:... | 128-bit UUID value (16 bytes) (can be passed multiple times)|
-| |uuid128_is_complete| [`0`-1] | I 128-bit UUID list is complete |
-| |tx_power_level | [-127 - 127] | TX Power level to include |
-| |appearance | [UINT16] | Appearance |
-| |name | string | Name |
-| |advertising_interval| [UINT16] | Advertising interval |
-| |service_data_uuid32| XX:XX:XX:... | 32-bit UUID service data |
-| |service_data_uuid128| XX:XX:XX:... | 128-bit UUID service data |
-| |uri | XX:XX:XX:... | URI |
-| |msg_data | XX:XX:XX:... | Manufacturer data |
-| |eddystone_url | string | Eddystone with specified URL |
-|**advertise-start**| | | Start advertising with configured instance |
-| |instance | [`0`-UINT8_MAX] | Advertising instance |
-| |duration | [`0`-UINT16_MAX] | Advertising duration in 10ms units. 0 - forver |
-| |max_events | [`0`-UINT8_MAX] | Maximum number of advertising events. 0 - no limit |
-|**advertise-stop**| | | Stop advertising |
-| |instance | [`0`-UINT8_MAX] | Advertising instance |
-|**advertise-remove**| | | Remove configured advertising instance |
-| |instance | [`0`-UINT8_MAX] | Advertising instance |
-
-## Legacy Advertising with Extended Advertising disabled
-
-|**Command** | **Parmeters** | ** Possible values** | **Description** |
-|-------------|------------------|---------------------------|------------------------------------------------------------|
-|**advertise**| | | Enable advertising |
-| |stop | | Stop enabled advertising |
-| |conn | `und` | Connectable mode: undirected |
-| | | non | non-connectable |
-| | | dir | directed |
-| |discov | `gen` | Discoverable mode: general discoverable |
-| | | ltd | limited discoverable |
-| | | non | non-discoverable |
-| |scannable | [`0`-1] | Use scannable advertising |
-| |peer_addr_type | `public` | Remote device public address type |
-| | | random | Remote device random address type |
-| | | public_id | Remote device public address type (Identity) |
-| | | random_id | Remote device random address type (Identity) |
-| |peer_addr | XX:XX:XX:XX:XX:XX | Remote device address - if provided perform directed advertising |
-| |own_addr_type | `public` | Use public address for scan requests |
-| | | random | Use random address for scan requests |
-| | | rpa_pub | Use RPA address for scan requests <br> (fallback to public if no IRK) |
-| | | rpa_rnd | Use RPA address for scan requests <br> (fallback to random if no IRK) |
-| |channel_map | [`0`-UINT8_MAX} | Primary advertising channels map. If 0 use all channels. |
-| |filter | `none` | Advertising filter policy - no filtering, no whitelist used|
-| | | scan | process all connection requests but only scans from white list|
-| | | conn | process all scan request but only connection requests from white list|
-| | | both | ignore all scan and connection requests unless in white list|
-| |interval_min | [`0`-UINT32_MAX] | Minimum advertising interval in 0.625 miliseconds <br> If 0 use stack default. |
-| |interval_max | [`0`-UINT32_MAX] | Maximum advertising interval in 0.625 miliseconds <br> If 0 use stack default. |
-| |high_duty | [`0`-1] | Use high_duty advertising |
-| |duration | [`1`-INT32_MAX] | Advertising duration in ms |
-|**set-adv-data**| | | Configure advertising instance ADV_DATA. This allow to configure following TLVs:|
-|**set-scan-rsp**| | | Configure advertising instance SCAN_RSP. This allow to configure following TLVs:|
-| |flags | [`0`-UINT8_MAX] | Flags value |
-| |uuid16 | [UINT16] | 16-bit UUID value (can be passed multiple times) |
-| |uuid16_is_complete| [`0`-1] | I 16-bit UUID list is complete |
-| |uuid32 | [UINT32] | 32-bit UUID value (can be passed multiple times) |
-| |uuid32_is_complete| [`0`-1] | I 32-bit UUID list is complete |
-| |uuid128 | XX:XX:XX:... | 128-bit UUID value (16 bytes) (can be passed multiple times)|
-| |uuid128_is_complete| [`0`-1] | I 128-bit UUID list is complete |
-| |tx_power_level | [-127 - 127] | TX Power level to include |
-| |appearance | [UINT16] | Appearance |
-| |name | string | Name |
-| |advertising_interval| [UINT16] | Advertising interval |
-| |service_data_uuid32| XX:XX:XX:... | 32-bit UUID service data |
-| |service_data_uuid128| XX:XX:XX:... | 128-bit UUID service data |
-| |uri | XX:XX:XX:... | URI |
-| |msg_data | XX:XX:XX:... | Manufacturer data |
-| |eddystone_url | string | Eddystone with specified URL |
-
-## L2CAP Connection Oriented Channels
-|**Command** | **Parmeters** | ** Possible values** | **Description** |
-|-------------|------------------|---------------------------|------------------------------------------------------------|
-|**l2cap-create-server** | | | Create L2CAP server |
-| |psm | [UINT16] | PSM |
-|**l2cap-connect** | | | Connect to remote L2CAP server |
-| |conn | [UINT16] | Connection handle |
-| |psm | [UINT16] | PSM |
-|**l2cap-disconnect** | | | Disconnec from L2CAP server |
-| |conn | [UINT16] | Connection handle |
-| |idx | [UINT16] | L2CAP connection oriented channel identifier |
-|**l2cap-send** | | | Send data over connected L2CAP channel |
-| |conn | [UINT16] | Connection handle |
-| |idx | [UINT16] | L2CAP connection oriented channel identifier |
-| |bytes | [UINT16] | Number of bytes to send (hardcoded data pattern) |
-|**l2cap-show-coc** | | | Show connected L2CAP channels |
-
-## Keys storage
-|**Command** | **Parmeters** | ** Possible values** | **Description** |
-|-------------|------------------|---------------------------|------------------------------------------------------------|
-|**keystore-add** | | | Add keys to storage |
-| |type | msec | Master Key |
-| | | ssec | Slave Key |
-| | | cccd | Client Characteristic Configuration Descriptor |
-| |addr | XX:XX:XX:XX:XX:XX | Device address |
-| |addr_type | `public` | Device address type |
-| | | random | Use random address for scan requests |
-| |ediv | [UINT16] | EDIV for LTK to add |
-| |rand | [UINT64] | Rand for LTK |
-| |ltk | XX:XX:XX... | LTK (16 bytes) |
-| |irk | XX:XX:XX... | Identity Resolving Key (16 bytes) |
-| |csrk | XX:XX:XX... | Connection Signature Resolving Key (16 bytes) |
-|**keystore-del** | | | Delete keys from storage |
-| |type | msec | Master Key |
-| | | ssec | Slave Key |
-| | | cccd | Client Characteristic Configuration Descriptor |
-| |addr | XX:XX:XX:XX:XX:XX | Device address |
-| |addr_type | `public` | Device address type |
-| | | random | Use random address for scan requests |
-| |ediv | [UINT16] | EDIV for LTK to remove |
-| |rand | [UINT64] | Rand for LTK |
-|**keystore-show** | | | Show stored keys |
-| |type | msec | Master Keys |
-| | | ssec | Slave Keys |
-| | | cccd | Client Characteristic Configuration Descriptor s |
diff --git a/docs/network/ble/btshell/btshell_GATT.md b/docs/network/ble/btshell/btshell_GATT.md
deleted file mode 100644
index 9832761..0000000
--- a/docs/network/ble/btshell/btshell_GATT.md
+++ /dev/null
@@ -1,59 +0,0 @@
-## GATT feature API for btshell
-
-<br>
-
-GATT(GENERIC ATTRIBUTE PROFILE) describes a service framework using the Attribute Protocol for discovering services, and for reading and writing characteristic values on a peer device. There are 11 features defined in the GATT Profile, and each of the features is mapped to procedures and sub-procedures:
-
-### Available commands
-
-Parameters default values (if applicable) are marked red.
-
-## Configuration
-
-|**Command** | **Parmeters** | ** Possible values** | **Description** |
-|-------------|------------------|---------------------------|------------------------------------------------------------|
-|**gatt-discover-characteristic**|| | Discover GATT characteristics |
-| |conn | [UINT16] | Connection handle |
-| |uuid | [UINT16] | Characteristic UUID |
-| |start | [UINT16] | Discovery start handle |
-| |end | [UINT16] | Discovery end handle |
-|**gatt-discover-descriptor**| | | Discover GATT descriptors |
-| |conn | [UINT16] | Connection handle |
-| |start | [UINT16] | Discovery start handle |
-| |end | [UINT16] | Discovery end handle |
-|**gatt-discover-service**| | | Discover services |
-| |conn | [UINT16] | Connection handle |
-| |uuid16 | [UINT16] | Service UUID |
-|**gatt-discover-full**| | | Discover services, characteristic and descriptors |
-| |conn | [UINT16] | Connection handle |
-|**gatt-find-included-services**|| | Find included services |
-| |conn | [UINT16] | Connection handle |
-| |start | [UINT16] | Discovery start handle |
-| |end | [UINT16] | Discovery end handle |
-|**gatt-exchange-mtu**| | | Initiate ATT MTU exchange procedure |
-| |conn | [UINT16] | Connection handle |
-|**gatt-read** | | | Read attribute |
-| |conn | [UINT16] | Connection handle |
-| |long | [`0`-1] | Long read |
-| |attr | [UINT16] | Attribute handle |
-| |offset | [UINT16] | Long read offset value |
-| |uuid | [UINT16] | Characteristic UUID |
-| |start | [UINT16] | Discovery start handle |
-| |end | [UINT16] | Discovery end handle |
-|**gatt-notify** | | | Send notification or indication to all subscribed peers |
-| |attr | [UINT16] | Attribute handle |
-|**gatt-service-changed** | | | Send Services Changed notification |
-| |start | [UINT16] | Start handle |
-| |end | [UINT16] | End handle |
-|**gatt-service-visibility** | | | Set service visibility |
-| |handle | [UINT16] | Service handle |
-| |visibility | [`0`-1] | Service visibility |
-|**gatt-show** | | | Show remote devices discovered databases structure |
-|**gatt-show-local** | | | Show local database structure |
-|**gatt-write** | | | Write attribute |
-| |conn | [UINT16] | Connection handle |
-| |no_rsp | [`0`-1] | Use Write Without Response |
-| |long | [`0`-1] | Use Long Write procedure |
-| |attr | [UINT16] | Attribute handle |
-| |offset | [UINT16] | Long write offset value |
-| |value | XX:XX:XX... | Data to write |
diff --git a/docs/network/ble/btshell/btshell_advdata.md b/docs/network/ble/btshell/btshell_advdata.md
deleted file mode 100644
index ed345d5..0000000
--- a/docs/network/ble/btshell/btshell_advdata.md
+++ /dev/null
@@ -1,35 +0,0 @@
-
-## Advertisement Data Fields
-
-<br>
-
-This part defines the advertisement data fields used in the `btshell` app. For a complete list of all data types and formats used for Extended Inquiry Response (EIR), Advertising Data (AD), and OOB data blocks, refer to the Supplement to the Bluetooth Core Specification, CSSv6, available for download [here](https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=302735&_ga=1.133090766.1368218946.1444779486).
-
-
-<br>
-
-
-
-|**Name** | **Definition** | **Details** | **btshell Notes** |
-|----|---------|---------------|--|
-| flags | Indicates basic information about the advertiser. | Flags used over the LE physical channel are: <br> * Limited Discoverable Mode <br> * General Discoverable Mode <br> * BR/EDR Not Supported <br> * Simultaneous LE and BR/EDR to Same Device Capable (Controller) <br> * Simultaneous LE and BR/EDR to Same Device Capable (Host) | NimBLE will auto-calculate if set to 0. |
-| uuid16 |16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 16-bit Service UUIDs available. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. | Set repeatedly for multiple service UUIDs. |
-| uuid16_is_complete | 16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
-| uuid32 | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 32-bit Service UUIDs available. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. | Set repeatedly for multiple service UUIDs. |
-| uuid32_is_complete | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
-| uuid128 | Global 128-bit Service UUIDs | More 128-bit Service UUIDs available. | Set repeatedly for multiple service UUIDs. |
-| uuid128_is_complete | Global 128-bit Service UUIDs | Complete list of 128-bit Service UUIDs |
-| tx_power_level | TX Power Level | Indicates the transmitted power level of the packet containing the data type. The TX Power Level data type may be used to calculate path loss on a received packet using the following equation: <br> <br> pathloss = Tx Power Level – RSSI <br> <br> where “RSSI” is the received signal strength, in dBm, of the packet received. | NimBLE will auto-calculate if set to -128. |
-| slave_interval_range | Slave Connection Interval Range | Contains the Peripheral’s preferred connection interval range, for all logical connections. Size: 4 Octets . The first 2 octets defines the minimum value for the connection interval in the following manner: <br> <br> connIntervalmin = Conn_Interval_Min * 1.25 ms <br> <br> Conn_Interval_Min range: 0x0006 to 0x0C80 <br> Value of 0xFFFF indicates no specific minimum. <br> <br> The other 2 octets defines the maximum value for the connection interval in the following manner: <br> <br> connIntervalmax = Conn_Interval_Max * 1.25 ms <br> Conn_Interval_Max range: 0x0006 to 0x0C80 <br> Conn_Interval_Max shall be equal to or greater than the Conn_Interval_Min. <br> Value of 0xFFFF indicates no specific maximum.|
-| service_data_uuid16 | Service Data - 16 bit UUID | Size: 2 or more octets <br> The first 2 octets contain the 16 bit Service UUID followed by additional service data |
-| public_target_address | Public Target Address | Defines the address of one or more intended recipients of an advertisement when one or more devices were bonded using a public address. This data type shall exist only once. It may be sent in either the Advertising or Scan Response data, but not both. |
-| appearance | Appearance | Defines the external appearance of the device. The Appearance data type shall exist only once. It may be sent in either the Advertising or Scan Response data, but not both. |
-| advertising_interval | Advertising Interval | Contains the advInterval value as defined in the Core specification, Volume 6, Part B, Section 4.4.2.2. |
-| service_data_uuid32 | Service Data - 32 bit UUID | Size: 4 or more octets <br> The first 4 octets contain the 32 bit Service UUID followed by additional service data |
-| service_data_uuid128 | Service Data - 128 bit UUID | Size: 16 or more octets <br> The first 16 octets contain the 128 bit Service UUID followed by additional service data |
-| uri | Uniform Resource Identifier (URI) | Scheme name string and URI as a UTF-8 string |
-| mfg_data | Manufacturer Specific data | Size: 2 or more octets <br> The first 2 octets contain the Company Identifier Code followed by additional manufacturer specific data |
-| eddystone_url | | |
-
-<br>
-
diff --git a/docs/network/ble/btshell/btshell_api.md b/docs/network/ble/btshell/btshell_api.md
deleted file mode 100644
index 80c8048..0000000
--- a/docs/network/ble/btshell/btshell_api.md
+++ /dev/null
@@ -1,133 +0,0 @@
-## API for btshell app
-
-"btshell" is one of the sample applications that come with Mynewt. It is a shell application which provides a basic interface to the host-side of the BLE stack. "btshell" includes all the possible roles (Central/Peripheral) and they may be run simultaneously. You can run btshell on a board and issue commands that make it behave as a central or a peripheral with different peers.
-
-**btshell** is a new application that uses shell subsystem introduced in Mynewt 1.1 and has updated commands and parameters names. Thanks to support for tab completion commands names are more descriptive and self-explanatory without requiring extensive typing.
-
-Highlighted below are some of the ways you can use the API to establish connections and discover services and characteristics from peer devices. For descriptions of the full API, go to the next sections on [GAP in btshell](btshell_GAP.md) and [GATT in btshell](btshell_GATT.md).
-
-<br>
-
-### Set device address.
-
-On startup, btshell has the following identity address configuration:
-
-* Public address: None
-* Random address: None
-
-The below `set` commands can be used to change the address configuration:
-
-```
-set addr_type=public addr=<device-address>
-set addr_type=random addr=<device-address>
-```
-
-For example:
-
-```
-set addr_type=public addr=01:02:03:04:05:06
-set addr_type=random addr=c1:aa:bb:cc:dd:ee
-```
-
-The address configuration can be viewed with the `gatt-show-addr` command, as follows:
-
-```
-gatt-show-addr
-public_id_addr=01:02:03:04:05:06 random_id_addr=c1:aa:bb:cc:dd:ee
-```
-
-<br>
-
-### Initiate a direct connection to a device
-
-In this case, your board is acting as a central and initiating a connection with another BLE device. The example assumes you know the address of the peer, either by scanning for available peers or because you have set up the peer yourself.
-
-```hl_lines="1"
-connect peer_addr=d4:f5:13:53:d2:43
-connection established; handle=1 our_ota_addr_type=0 our_ota_addr=0a:0b:0c:0d:0e:0f out_id_addr_type=0 our_id_addr=0a:0b:0c:0d:0e:0f peer_addr_type=0 peer_addr=43:d2:53:13:f5:d4 conn_itvl=40 conn_latency=0 supervision_timeout=256 encrypted=0 authenticated=0 bonded=0
-```
-
-The `handle=1` in the output indicates that it is connection-1.
-
-<br>
-
-### Configure advertisements to include device name
-
-In this case, your board is acting as a peripheral.
-
-With Extended Advertising enabled (should be executed after advertise-configure):
-```
-advertise-set-adv-data name=<your-device-name>
-```
-
-With Extended Advertising disabled:
-```
-set-adv-data name=<your-device-name>
-```
-
-<br>
-
-### Begin sending undirected general advertisements
-
-In this case, your board is acting as a peripheral.
-
-With Extended Advertising enabled:
-```
-advertise-configure connectable=1 legacy=1 scannable=1
-advertise-start
-```
-
-With Extended Advertising disabled:
-```
-advertise conn=und discov=gen
-```
-
-<br>
-
-### Show established connections.
-
-```
-gatt-show-conn
-```
-
-<br>
-
-### Discover and display peer's services, characteristics, and descriptors.
-
-This is how you discover and then display the services of the peer you established earlier across connection-1.
-
-```hl_lines="1 2"
-gatt-discover-full conn=1
-gatt-show
-[ts=132425ssb, mod=64 level=2] CONNECTION: handle=1 addr=d4:f5:13:53:d2:43
-[ts=132428ssb, mod=64 level=2] start=1 end=5 uuid=0x1800
-[ts=132433ssb, mod=64 level=2] start=6 end=16 uuid=0x1808
-[ts=132437ssb, mod=64 level=2] start=17 end=31 uuid=0x180a
-[ts=132441ssb, mod=64 level=2] start=32 end=65535 uuid=00000000-0000-1000-1000000000000000
-```
-
-<br>
-
-### Read an attribute belonging to the peer
-
-```
-gatt-read conn=1 attr=21
-```
-
-<br>
-
-### Write to an attribute belonging to the peer
-
-```
-gatt-write conn=1 attr=3 value=0x01:0x02:0x03
-```
-
-<br>
-
-### Perform a passive scan
-
-This is how you tell your board to listen to all advertisements around it. The duration is specified in ms.
-
-```
-scan duration=1000 passive=1 filter=no_wl
-```
diff --git a/docs/network/ble/mesh_lightning_model.jpg b/docs/network/ble/mesh_lightning_model.jpg
deleted file mode 100644
index 4c62e05..0000000
--- a/docs/network/ble/mesh_lightning_model.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/network/ble/mesh_topology.jpg b/docs/network/ble/mesh_topology.jpg
deleted file mode 100644
index 57ba3f9..0000000
--- a/docs/network/ble/mesh_topology.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/newt/command_list/newt_build.md b/docs/newt/command_list/newt_build.md
deleted file mode 100644
index 56e075e..0000000
--- a/docs/newt/command_list/newt_build.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt build </font>
-
-Build one or more targets.
-
-#### Usage:
-
-```no-highlight
- newt build <target-name> [target_name ...] [flags]
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-
-#### Description
-Compiles, links, and builds an ELF binary for the target named <target-name>. It builds an ELF file for the application specified by the `app` variable for the `target-name` target. The image can be loaded and run on the hardware specified by the `bsp` variable for the target. The command creates the 'bin/' directory under the project's base directory (that the `newt new` command created) and stores the executable in the 'bin/targets/<target-name>/app/apps/<app-name>' directory. A `manifest.json` build manifest file is also generated in the same directory. This build manifest contains information such as build time, version, image name, a hash to identify the image, packages actually used to create the build, and the target for which the image is built.
-
-You can specify a list of target names, separated by a space, to build multiple targets.
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt build <br> my_blinky_sim | Builds an executable for the `my_blinky_sim` target. For example, if the `my_blinky_sim` target has `app` set to `apps/blinky`, you will find the generated .elf, .a, and .lst files in the 'bin/targets/my_blinky_sim/app/apps/blinky' directory.
- | newt build <br> my_blinky_sim myble | Builds the images for the applications defined by the `my_blinky_sim` and `myble` targets.
diff --git a/docs/newt/command_list/newt_clean.md b/docs/newt/command_list/newt_clean.md
deleted file mode 100644
index 632b184..0000000
--- a/docs/newt/command_list/newt_clean.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt clean </font>
-
-Delete build artifacts for one or more targets.
-
-#### Usage:
-
-```no-highlight
- newt clean <target-name> [target-name...] | all [flags]
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-
-```
-#### Description
-
-Deletes all the build artifacts generated for the `target-name` target. It does not delete the target definition. You can specify a list of targets, separated by a space, to delete the artifacts for multiple targets, or specify `all` to delete the artifacts for all targets.
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt clean myble | Deletes the 'bin/targets/myble' directory where all the build artifacts generated from the `myble` target build are stored.
- | newt clean my_blinky_sim myble | Deletes the 'bin/targets/my_blinky_sim' and the 'bin/targets/myble' directories where all the artifacts generated from the `my_blinky_sim` and `myble` target builds are stored.
- | newt clean all | Removes the artifacts for all target builds. Deletes the top level 'bin' directory.
diff --git a/docs/newt/command_list/newt_complete.md b/docs/newt/command_list/newt_complete.md
deleted file mode 100644
index 7f2d55c..0000000
--- a/docs/newt/command_list/newt_complete.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt complete </font>
-
-Performs bash autocompletion using tab. It is not intended to be called directly from the command line.
-
-#### Install bash autocompletion
-
-```no-highlight
- $ brew install bash-completion
- Updating Homebrew...
- <snip>
- Bash completion has been installed to:
- /usr/local/etc/bash_completion.d
- ==> Summary
- 🍺 /usr/local/Cellar/bash-completion/1.3_1: 189 files, 607.8K
-```
-
-#### Enable autocompletion for newt
-
-```no-highlight
- $ complete -C "newt complete" newt
-```
-
-#### Usage
-
-Hit tab and see possible completion options or completed command.
-
-```no-highlight
- $ newt target s
- set show
- $ newt target show
-```
diff --git a/docs/newt/command_list/newt_create_image.md b/docs/newt/command_list/newt_create_image.md
deleted file mode 100644
index d929a9a..0000000
--- a/docs/newt/command_list/newt_create_image.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt create-image </font>
-
-Create and sign an image by adding an image header to the binary file created for a target. Version number in the header is set to <version>. To sign an image provide a .pem file for the signing-key and an optional key-id.
-
-#### Usage:
-
-```no-highlight
- newt create-image <target-name> <version> [signing-key [key-id]][flags]
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-Adds an image header to the created binary file for the `target-name` target. The image version is set to `version`. It creates a `<app-name>.img` file the image, where `app-name` is the value specified in the target `app` variable, and stores the file in the '/bin/targets/<target-name>/app/apps/<app-name>/' directory. It also creates a `<app-name>.hex` file for the image in the same directory, and adds the version, build id, image file name, and image hash to the `manifest.json` file that the `newt build` command created.
-
-To sign an image, provide a .pem file for the `signing-key` and an optional `key-id`. `key-id` must be a value between 0-255.
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt create-image myble2 1.0.1.0 | Creates an image for target `myble2` and assigns it version `1.0.1.0`. <br> <br> For the following target definition: <br> targets/myble2 <br> app=@apache-mynewt-core/apps/btshell <br> bsp=@apache-mynewt-core/hw/bsp/nrf52dk <br> build_profile=optimized <br> syscfg=STATS_NAMES=1 <br><br> the 'bin/targets/myble2/app/apps/btshell/btshell.img' and 'bin/targets/myble2/app/apps/btshell/btshell.hex' files are created, and the manifest in 'bin/targets/myble2/app/apps/btshell/manifest.json' is updated with the image information.
- | newt create-image myble2 1.0.1.0 private.pem | Creates an image for target `myble2` and assigns it the version `1.0.1.0`. Signs the image using private key specified by the private.pem file.
diff --git a/docs/newt/command_list/newt_debug.md b/docs/newt/command_list/newt_debug.md
deleted file mode 100644
index d493752..0000000
--- a/docs/newt/command_list/newt_debug.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt debug </font>
-
-Open a debugger session to a target.
-
-#### Usage:
-
-```no-highlight
- newt debug <target-name> [flag]
-```
-#### Flags:
-```no-highlight
- --extrajtagcmd string Extra commands to send to JTAG software
- -n, --noGDB Do not start GDB from command line
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-Opens a debugger session to the image built for the <target-name> target.
-
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt debug myble2 | Opens a J-Link connection and starts a GNU gdb session to debug bin/targets/myble2/app/apps/btshell/btshell.elf when the target is as follows: <br> <br> targets/myble2 <br> app=@apache-mynewt-core/apps/btshell <br> bsp=@apache-mynewt-core/hw/bsp/nrf52dk <br> build_profile=optimized <br> syscfg=STATS_NAMES=1
- | newt debug myble2 -n | Opens a J-Link connection bin/targets/myble2/app/apps/btshell/btshell.elf but do not start GDB on the command line.
diff --git a/docs/newt/command_list/newt_help.md b/docs/newt/command_list/newt_help.md
deleted file mode 100644
index 7db5675..0000000
--- a/docs/newt/command_list/newt_help.md
+++ /dev/null
@@ -1,60 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt help </font>
-
-Display the help text for the newt command line tool:
-
-```no-highlight
-Newt allows you to create your own embedded application based on the Mynewt
-operating system. Newt provides both build and package management in a single
-tool, which allows you to compose an embedded application, and set of
-projects, and then build the necessary artifacts from those projects. For more
-information on the Mynewt operating system, please visit
-https://mynewt.apache.org/.
-```
-
-#### Usage:
-```no-highlight
- newt help [command]
-```
-#### Global Flags:
-
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-
-#### Available Commands:
-```no-highlight
- build Build one or more targets
- clean Delete build artifacts for one or more targets
- create-image Add image header to target binary
- debug Open debugger session to target
- info Show project info
- install Install project dependencies
- load Load built target to board
- mfg Manufacturing flash image commands
- new Create a new project
- pkg Create and manage packages in the current workspace
- run build/create-image/download/debug <target>
- size Size of target components
- sync Synchronize project dependencies
- target Command for manipulating targets
- test Executes unit tests for one or more packages
- upgrade Upgrade project dependencies
- vals Display valid values for the specified element type(s)
- version Display the Newt version number
-```
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt help target | Displays the help text for the newt `target` command
- | newt help | Displays the help text for newt tool
-
-
-
diff --git a/docs/newt/command_list/newt_info.md b/docs/newt/command_list/newt_info.md
deleted file mode 100644
index 3e2c209..0000000
--- a/docs/newt/command_list/newt_info.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt info </font>
-
-Show information about the current project.
-
-#### Usage:
-
-```no-highlight
- newt info [flags]
-```
-
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-
-#### Description
-
-Displays the repositories in the current project (the local as well as all the external repositories fetched). It also displays the packages in the local repository.
-
diff --git a/docs/newt/command_list/newt_install.md b/docs/newt/command_list/newt_install.md
deleted file mode 100644
index 9a56ad0..0000000
--- a/docs/newt/command_list/newt_install.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt install </font>
-
-Install project dependencies.
-
-#### Usage:
-```no-highlight
- newt install [flags]
-```
-
-#### Flags:
-```no-highlight
- -f, --force Force install of the repositories in project, regardless of what exists in repos directory
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-This command downloads the description for all the repositories specified in the `project.yml` file for the current project, and installs the correct versions of all the packages specified by the project dependencies.
-
-You must run this command from within the current project directory. (Remember to `cd` into this project directory after you use `newt new` to create this project before you run `newt install`.)
-
diff --git a/docs/newt/command_list/newt_load.md b/docs/newt/command_list/newt_load.md
deleted file mode 100644
index ad77ca4..0000000
--- a/docs/newt/command_list/newt_load.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt load </font>
-
-Load application image onto the board for a target.
-
-#### Usage:
-
-```no-highlight
- newt load <target-name> [flags]
-```
-
-
-#### Flags:
-
-```no-highlight
- --extrajtagcmd string Extra commands to send to JTAG software
-
-```
-
-### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-Uses download scripts to automatically load, onto the connected board, the image built for the app defined by the `target-name` target If the wrong board is connected or the target definition is incorrect (i.e. the wrong values are given for bsp or app), the command will fail with error messages such as `Can not connect to J-Link via USB` or `Unspecified error -1`.
diff --git a/docs/newt/command_list/newt_mfg.md b/docs/newt/command_list/newt_mfg.md
deleted file mode 100644
index 1a8dca6..0000000
--- a/docs/newt/command_list/newt_mfg.md
+++ /dev/null
@@ -1,99 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt mfg </font>
-
-Commands to create, build, and upload manufacturing image.
-
-#### Usage:
-
-```no-highlight
- newt mfg [flags]
- newt mfg [command]
-```
-#### Available Commands:
-
-```no-highlight
- create Create a manufacturing flash image
- deploy Build and upload a manufacturing image (build + load)
- load Load a manufacturing flash image onto a device
-```
-
-#### Global Flags:
-
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-Sub-command | Explanation
--------------| ------------------------
-create | A manufacturing image specifies 1) a boot loader target, and 2) one or more image targets. Assuming the manufacturing entity has been created and defined in the `mfgs/<mfg image name>/` package (see Examples below), this command collects the manufacturing related files in the newly created `bin/mfgs/<mfg image name>` directory. The collection includes the image file, the hex file, and the manifests with the image build time, version, manufacturing package build time, image ID (or hash) etc. It is essentially a snapshot of the image data and metadata uploaded to the device flash at manufacturing time. Note that the command expects the targets and images to have already been built using `newt build` and `newt create-image` commands.
-deploy | A combination of build and load commands to put together and upload manufacturing image on to the device.
-load | Loads the manufacturing package onto to the flash of the connected device.
-
-
-#### Examples
-
-Suppose you have created two targets (one for the bootloader and one for the `blinky` app).
-
-```no-highlight
-$ newt target show
-targets/my_blinky_sim
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/native
- build_profile=debug
-targets/rb_blinky
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/rb-nano2
- build_profile=debug
-targets/rb_boot
- app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/rb-nano2
- build_profile=optimized
-```
-
-Create the directory to hold the mfg packages.
-
-```
-$ mkdir -p mfgs/rb_blinky_rsa
-```
-
-The `rb_blinky_rsa` package needs a pkg.yml file. In addition it is needs a mfg.yml file to specify the two constituent targets. An example of each file is shown below.
-
-```
-$ more mfgs/rb_blinky_rsa/pkg.yml
-pkg.name: "mfgs/rb_blinky_rsa"
-pkg.type: "mfg"
-pkg.description:
-pkg.author:
-pkg.homepage:
-```
-
-```
-$ more mfgs/rb_blinky_rsa/mfg.yml
-mfg.bootloader: 'targets/rb_boot'
-mfg.images:
- - 'targets/rb_blinky'
-```
-
-Build the bootloader and app images.
-
-```
-$ newt build rb_boot
-$ newt create-image rb_blinky 0.0.1
-```
-
-Run the `newt mfg create` command to collect all the manufacturing snapshot files.
-
-```
-$ newt mfg create rb_blinky_rsa 0.0.1
-Creating a manufacturing image from the following files:
-<snip>
-Generated the following files:
-<snip>
-$
-```
diff --git a/docs/newt/command_list/newt_new.md b/docs/newt/command_list/newt_new.md
deleted file mode 100644
index 01c7140..0000000
--- a/docs/newt/command_list/newt_new.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt new </font>
-
-Create a new project from a skeleton. Currently, the default skeleton is the [blinky repository](https://github.com/apache/mynewt-blinky).
-
-
-#### Usage:
-```no-highlight
- newt new <project-name> [flags]
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-### Description
-Creates a new project named `project-name` from the default skeleton [blinky repository](https://github.com/apache/mynewt-blinky).
-
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt new test_project | Creates a new project named `test_project` using the default skeleton from the `apache/mynewt-blinky` repository.
-
diff --git a/docs/newt/command_list/newt_pkg.md b/docs/newt/command_list/newt_pkg.md
deleted file mode 100644
index 0c89f1b..0000000
--- a/docs/newt/command_list/newt_pkg.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt pkg </font>
-
-Commands for creating and manipulating packages.
-
-#### Usage:
-```no-highlight
- newt pkg [command] [flags]
-```
-#### Flags:
-```no-highlight
- -t, --type string Type of package to create: app, bsp, lib, sdk, unittest. (default "lib")
-
-```
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-The pkg command provides subcommands to create and manage packages. The subcommands take one or two `package-name` arguments.
-
-Sub-command | Explanation
-------------------------| ------------------------
-copy | The copy <src-pkg> <dst-pkg> command creates the new `dst-pkg` package by cloning the `src-pkg` package.
-move | The move <old-pkg> <new-pkg> command moves the `old-pkg` package to the `new-pkg` package.
-new | The new <new-pkg> command creates a new package named `new-pkg`, from a template, in the current directory. You can create a package of type `app`, `bsp`, `lib`, `sdk`, or `unittest`. The default package type is `lib`. You use the -t flag to specify a different package type.
-remove | The remove <my-pkg> command deletes the `my-pkg` package.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-copy | newt pkg copy <br>apps/btshell apps/new_btshell | Copies the `apps/btshell` package to the `apps/new_btshell`.
-move | newt pkg move <br>apps/slinky apps/new_slinky | Moves the `apps/slinky` package to the `apps/new_slinky` package.
-new | newt pkg new apps/new_slinky | Creates a package named `apps/new_slinky` of type `pkg` in the current directory.
-new | newt pkg new hw/bsp/myboard -t bsp| Creates a package named `hw/bsp/myboard` of type `bsp` in the current directory.
-remove | newt pkg remove hw/bsp/myboard | Removes the `hw/bsp/myboard` package.
-
diff --git a/docs/newt/command_list/newt_resign_image.md b/docs/newt/command_list/newt_resign_image.md
deleted file mode 100644
index b28c5cd..0000000
--- a/docs/newt/command_list/newt_resign_image.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt resign-image </font>
-Sign or re-sign an existing image file.
-
-#### Usage:
-
-```no-highlight
- newt resign-image <image-file> [signing-key [key-id]][flags]
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-Changes the signature of an existing image file. To sign an image, specify a .pem file for the `signing-key` and an optional `key-id`. `key-id` must be a value between 0-255. If a signing key is not specified, the command strips the current signature from the image file.
-
-A new image header is created. The rest of the image is byte-for-byte equivilent to the original image.
-
-Warning: The image hash will change if you change the key-id or the type of key used for signing.
-
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt resign-image bin/targets/myble/app/apps/btshell/btshell.img private.pem | Signs the `bin/targets/myble/app/apps/btshell/btshell.img` file with the private.pem key.
- | newt resign-image bin/targets/myble/app/apps/btshell/btshell.img | Strips the current signature from `bin/targets/myble/app/apps/btshell/btshell.img` file.|
diff --git a/docs/newt/command_list/newt_run.md b/docs/newt/command_list/newt_run.md
deleted file mode 100644
index 220c3b0..0000000
--- a/docs/newt/command_list/newt_run.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt run </font>
-
-A single command to do four steps - build a target, create-image, load image on a board, and start a debug session with the image on the board.
-
-**Note**: If the version number is omitted:
-
-* The create-image step is skipped for a bootloader target.
-* You will be prompted to enter a version number for an application target.
-
-#### Usage:
-
-```no-highlight
- newt run <target-name> [<version>][flags]
-```
-
-#### Flags:
-```no-highlight
- --extrajtagcmd string Extra commands to send to JTAG software
- -n, --noGDB Do not start GDB from the command line
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-
-#### Description
-Same as running `build <target-name>`, `create-image <target-name> <version>`, `load <target-name>`, and `debug <target-name>`.
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt run blink_rigado | Compiles and builds the image for the `app` and the `bsp` defined for target `blink_rigado`, loads the image onto the board, and opens an active GNU gdb debugging session to run the image.
- | newt run ble_rigado 0.1.0.0 | Compiles and builds the image for the `app` and the `bsp` defined for target `ble_rigado`, signs and creates the image with version number 0.1.0.0, loads the image onto the board, and opens an active GNU gdb debugging session to run the image. <br> <br> Note that if there is no bootloader available for a particular board/kit, a signed image creation step is not necessary.
diff --git a/docs/newt/command_list/newt_size.md b/docs/newt/command_list/newt_size.md
deleted file mode 100644
index 4804654..0000000
--- a/docs/newt/command_list/newt_size.md
+++ /dev/null
@@ -1,61 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt size </font>
-
-Calculates the size of target components for a target.
-
-#### Usage:
-
-```no-highlight
- newt size <target-name> [flags]
-```
-
-#### Flags:
-```no-highlight
- -F, --flash Print FLASH statistics
- -R, --ram Print RAM statistics
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-
-#### Description
-Displays the RAM and FLASH size of each component for the `target-name` target.
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt size blink_rigado | Inspects and lists the RAM and Flash memory that each component (object files and libraries) for the `blink_rigado` target.
-
-#### Example output for `newt size blink_rigado`:
-
-```no-highlight
-
-$ newt size blink_rigado
- FLASH RAM
- 9 223 *fill*
- 1052 0 baselibc.a
- 195 1116 blinky.a
- 616 452 bmd300eval.a
- 64 0 cmsis-core.a
- 124 0 crt0.o
- 8 0 crti.o
- 16 0 crtn.o
- 277 196 full.a
- 20 8 hal.a
- 96 1068 libg.a
- 1452 0 libgcc.a
- 332 28 nrf52xxx.a
- 3143 677 os.a
-
-objsize
- text data bss dec hex filename
- 7404 1172 2212 10788 2a24 /Users/<username>/dev/rigado/bin/blink_rigado/apps/blinky/blinky.elf
-```
diff --git a/docs/newt/command_list/newt_sync.md b/docs/newt/command_list/newt_sync.md
deleted file mode 100644
index 4f9eb4b..0000000
--- a/docs/newt/command_list/newt_sync.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt sync </font>
-
-Synchronize and refresh the contents of the local copy of all the repositories used in the project with the latest updates maintained in the remote repositories.
-
-#### Usage:
-
-```no-highlight
- newt sync [flags]
-```
-#### Flags:
-```no-highlight
- -f, --force Force overwrite of existing remote repository
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-Synchronize project dependencies and repositories. Prior to 1.0.0 release, the command deletes and resynchronizes each repository. Post 1.0.0, it will abort the synchronization if there are any local changes to any repository. Using the -f to force overwrite of existing repository will stash and save the changes while pulling in all the latest changes from the remote repository.
diff --git a/docs/newt/command_list/newt_target.md b/docs/newt/command_list/newt_target.md
deleted file mode 100644
index 680617e..0000000
--- a/docs/newt/command_list/newt_target.md
+++ /dev/null
@@ -1,68 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt target </font>
-
-Commands to create, delete, configure and query targets.
-
-#### Usage:
-
-```no-highlight
- newt target [command] [flags]
-```
-#### Available Commands:
-```no-highlight
- amend Add, change, or delete values for multi-value target variables
- config View or populate a target's system configuration settings
- copy Copy target
- create Create a target
- delete Delete target
- dep View target's dependency graph
- revdep View target's reverse-dependency graph
- set Set target configuration variable
- show View target configuration variables
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-
-#### Description
-The target command provides subcommands to create, build, delete, and query targets. The subcommands take one or two `target-name` arguments.
-
-Sub-command | Explanation
--------------| ------------------------
-amend | The amend command allows you to add, change, or delete values for multi-value target variables that you have set with the `newt target set` command. The format of the amend command is: <br>newt target amend <target-name> <var-name=var-value> [var-name=var-value...] <br>Specify the `-d` flag to delete values.<br><br>The following multi-value variables can be amended: `aflags`, `cflags`, `lflags`, `syscfg`. <br>The `var-value` format depends on the `var-name` as follows: <ul><li>`aflags`, `cflags`, `lflags`: A string of flags, with each flag separated by a space. These variables are saved in the target's `pkg.yml` file.</li><li>`syscfg`: The `syscfg` variable allows you to assign values to configuration settings in your target's `syscfg.yml` file. <br><br>The format is `syscfg=setting-name1=setting-value1[:setting-name2=setting-value2...]`, where `setting-name1` is a configuration setting name and `setting-value1` is the value to assign to `setting-name1`. If `setting-value1` is not specified, the setting is set to value `1`. You use a `:` to delimit each setting when you amend multiple settings.<br><br>To delete a system configuration setting, you only need to specify the setting name. For example, `syscfg=setting-name1:setting-name2` deletes configuration settings named `setting-name1` and `setting-name2`. </li></ul>
-config | The config command allows you to view or populate a target's system configuration settings. A target's system configuration settings include the settings of all the packages it includes. The settings for a package are listed in the package's `syscfg.yml` file. The `config` command has two subcommands: `show` and `init`. <br><br> The config show <target-name> command displays the system configuration setting definitions and values for all the packages that the `target-name` target includes. <br><br>The config init <target-name> command populates the target's `syscfg.yml` file with the system configuration values for all the packages that the `target-name` target includes.
-copy | The copy <src-target> <dst-target> command creates a new target named `dst-target` by cloning the `src-target` target.
-create | The create <target-name> command creates an empty target named `target-name`. It creates the `targets/target-name` directory and the skeleton `pkg.yml` and `target.yml` files in the directory.
-delete | The delete <target-name> command deletes the description for the `target-name` target. It deletes the 'targets/target-name' directory. It does not delete the 'bin/targets/target-name' directory where the build artifacts are stored. If you want to delete the build artifacts, run the `newt clean <target-name>` command **before** deleting the target.
-dep | The dep <target-name> command displays a dependency tree for the packages that the `target-name` target includes. It shows each package followed by the list of libraries or packages that it depends on.
-revdep | The revdep <target-name> command displays the reverse dependency tree for the packages that the `target-name` target includes. It shows each package followed by the list of libraries or packages that depend on it.
-set | The set <target-name> <var-name=var-value> [var-name=var-value...] command sets variables (attributes) for the <target-name> target. The set command overwrites your current variable values. <br><br>The valid `var-name` values are: `app`, `bsp`, `loader`, `build_profile`, `cflags`, `lflags`, `aflags`, `syscfg`. <br><br>The `var-value` format depends on the `var-name` as follows: <ul><li>`app`, `bsp`, `loader`: @<source-path>, where `source-path` is the directory containing the application or bsp source. These variables are stored in the target's target.yml file. For a simulated target, e.g. for software testing purposes, set `bsp` to `@apache-mynewt-core/hw/bsp/native`.</li> <li>`build_profile`: `optimized` or `debug`</li><li>`aflags`, `cflags`, `lflags`: A string of flags, with each flag separated by a space. These variables are saved in the target's `pkg.yml` file.</li><li>`syscfg`: The `syscfg` variable allows you to assign values to configuration settings in your target's `syscfg.yml` file. <br>The format is `syscfg=setting-name1=setting-value1[:setting-name2=setting-value2...]`, where `setting-name1` is a configuration setting name and `setting-value1` is the value to assign to `setting-name1`. If `setting-value1` is not specified, the setting is set to value `1`. You use a `:` to delimit each setting when you set multiple settings. </li></ul>You can specify `var-name=` or `var-name=""` to unset a variable value.<br><br> **Warning**: For multi-value variables, the command overrides all existing values. Use the `newt target amend` command to change or add new values for a multi-value variable after you have set the variable value. The multi-value variables are: `aflags`, `cflags`, `lflags`, and `syscfg`.<br><br>To display all the existing values for a target variable (attribute), you can run the `newt vals <variable-name>` command. For example, `newt vals app` displays the valid values available for the variable `app` for any target.
-show | The show [target-name] command shows the values of the variables (attributes) for the `target-name` target. When `target-name` is not specified, the command shows the variables for all the targets that are defined for your project.
-
-#### Examples
-
- Sub-command | Usage | Explanation
---------------| -----------------------|-----------------
-amend | newt target amend myble syscfg=CONFIG_NEWTMGR=0 cflags="-DTEST"|Changes (or adds) the `CONFIG_NEWTMGR` variable to value 0 in the `syscfg.yml` file and adds the -DTEST flag to `pkg.cflags` in the `pkg.yml` file for the `myble` target. Other syscfg setting values and cflags values are not changed.
-amend | newt target amend myble -d syscfg=LOG_LEVEL:CONFIG_NEWTMGR cflags="-DTEST"|Deletes the `LOG_LEVEL` and `CONFIG_NEWTMGR` settings from the `syscfg.yml` file and the -DTEST flag from `pkg.cflags` for the `myble` target. Other syscfg setting values and cflags values are not changed.
-config show | newt target config show rb_blinky | Shows the system configuration settings for all the packages that the `rb_blinky` target includes.
-config init | newt target config init my_blinky | Creates and populates the `my_blinky` target's `syscfg.yml` file with the system configuration setting values from all the packages that the `my_blinky` target includes.
-copy | newt target copy <br>rb_blinky rb_btshell | Creates the `rb_btshell` target by cloning the `rb_blinky` target.
-create | newt target create <br>my_new_target | Creates the `my_newt_target` target. It creates the `targets/my_new_target` directory and creates the skeleton `pkg.yml` and `target.yml` files in the directory.
-delete | newt target delete rb_btshell | Deletes the `rb_btshell` target. It deletes the `targets/rb_btshell` directory.
-dep | newt target dep myble | Displays the dependency tree of all the package dependencies for the `myble` target. It lists each package followed by a list of packages it depends on.
-revdep | newt target revdep myble | Displays the reverse dependency tree of all the package dependencies for the `myble` target. It lists each package followed by a list of packages that depend on it.
-set | newt target set myble <br>app=@apache-mynewt-core/apps/btshell | Use `btshell` as the application to build for the `myble` target.
-set | newt target set myble <br>cflags="-DNDEBUG -Werror" | Set `pkg.cflags` variable with `-DNDEBUG -Werror` in the `myble` target's `pkg.yml` file..
-set | newt target set myble syscfg=LOG_NEWTMGR=0:CONFIG_NEWTMGR | Sets the `syscfg.vals` variable in the `myble` target's `syscfg.yml` file with the setting values: LOG_NEWTMGR: 0 and CONFIG_NEWTMGR: 1. CONFIG_NEWTMGR is set to 1 because a value is not specified.
-set | newt target set myble cflags= | Unsets the `pkg.cflags` variable in the `myble` target's `pkg.yml` file.
-show | newt target show myble | Shows all variable settings for the `myble` target, i.e. the values that app, bsp, build_profile, cflags, aflags, ldflags, syscfg variables are set to. Note that not all variables have to be set for a target.
-show | newt target show | Shows all the variable settings for all the targets defined for the project.
-
diff --git a/docs/newt/command_list/newt_test.md b/docs/newt/command_list/newt_test.md
deleted file mode 100644
index 27afdba..0000000
--- a/docs/newt/command_list/newt_test.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt test </font>
-
-Execute unit tests for one or more packages.
-
-#### Usage:
-
-```no-highlight
- newt test <package-name> [package-names...] | all [flags]
-```
-
-#### Flags:
-```no-highlight
- -e, --exclude string Comma separated list of packages to exclude
-
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-
-#### Description
-Executes unit tests for one or more packages. You specify a list of packages, separated by space, to test multiple packages in the same command, or specify `all` to test all packages. When you use the `all` option, you may use the `-e` flag followed by a comma separated list of packages to exclude from the test.
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt test <br>@apache-mynewt-core/kernel/os | Tests the `kernel/os` package in the `apache-mynewt-core` repository.
- | newt test kernel/os encoding/json | Tests the `kernel/os` and `encoding/json` packages in the current repository.
- | newt test all | Tests all packages.
- | newt test all -e net/oic,encoding/json | Tests all packages except for the `net/oic` and the `encoding/json` packages.
-
-
-
-
-
diff --git a/docs/newt/command_list/newt_upgrade.md b/docs/newt/command_list/newt_upgrade.md
deleted file mode 100644
index 0e9f731..0000000
--- a/docs/newt/command_list/newt_upgrade.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt upgrade </font>
-
-Upgrade project dependencies.
-
-#### Usage:
-```no-highlight
- newt upgrade [flags]
-```
-
-#### Flags:
-```no-highlight
- -f, --force Force upgrade of the repositories to latest state in project.yml
-```
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-Upagrades your project and package dependencies. If you have changed the project.yml description for the project, you need to run this command to update all the package dependencies.
diff --git a/docs/newt/command_list/newt_vals.md b/docs/newt/command_list/newt_vals.md
deleted file mode 100644
index 7931cd7..0000000
--- a/docs/newt/command_list/newt_vals.md
+++ /dev/null
@@ -1,63 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt vals </font>
-
-Display valid values for the specified element type(s).
-
-
-#### Usage:
-
-```no-highlight
- newt vals <element-type> [element-types...] [flags]
-```
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-#### Description
-
-Displays valid values for the specified element type(s). You must set valid values for one or more elements when you define a package or a target. Valid element types are:
-
-* api
-* app
-* bsp
-* build_profile
-* compiler
-* lib
-* sdk
-* target
-
-#### Examples
-
- Sub-command | Usage | Explanation
--------------| --------------------|-----------------
- | newt vals api | Shows the possible values for APIs a package may specify as required. For example, the `pkg.yml` for `adc` specifies that it requires the api named `ADC_HW_IMPL`, one of the values listed by the command.
-
-#### Example output for `newt vals bsp`:
-
-This lists all possible values that may be assigned to a target's bsp attribute.
-
-```no-highlight
-$ newt vals bsp
-bsp names:
- @apache-mynewt-core/hw/bsp/arduino_primo_nrf52
- @apache-mynewt-core/hw/bsp/bmd300eval
- @apache-mynewt-core/hw/bsp/ci40
- @apache-mynewt-core/hw/bsp/frdm-k64f
- @apache-mynewt-core/hw/bsp/native
- @apache-mynewt-core/hw/bsp/nrf51-arduino_101
- @apache-mynewt-core/hw/bsp/nrf51-blenano
- @apache-mynewt-core/hw/bsp/nrf51dk
- @apache-mynewt-core/hw/bsp/nrf51dk-16kbram
- @apache-mynewt-core/hw/bsp/nrf52dk
- @apache-mynewt-core/hw/bsp/nucleo-f401re
- @apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
- @apache-mynewt-core/hw/bsp/rb-nano2
- @apache-mynewt-core/hw/bsp/stm32f4discovery
-$ newt target set sample_target bsp=@apache-mynewt-core/hw/bsp/rb-nano2
-```
-Obviously, this output will grow as more board support packages are added for new boards and MCUs.
diff --git a/docs/newt/command_list/newt_version.md b/docs/newt/command_list/newt_version.md
deleted file mode 100644
index f28ac42..0000000
--- a/docs/newt/command_list/newt_version.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newt version </font>
-
-Display the version of the newt tool you have installed
-
-#### Usage:
-
-```no-highlight
- newt version [flags]
-```
-
-#### Global Flags:
-```no-highlight
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-```
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newt version | Displays the version of the newt tool you have installed
-
-
diff --git a/docs/newt/install/newt_linux.md b/docs/newt/install/newt_linux.md
deleted file mode 100644
index 7edd009..0000000
--- a/docs/newt/install/newt_linux.md
+++ /dev/null
@@ -1,205 +0,0 @@
-## Installing Newt on Linux
-
-You can install the latest release (1.4.0) of the newt tool from a Debian binary package (amd64). You can also download and build the latest release version of newt from source.
-
-This page shows you how to:
-
-1. Set up your computer to download Debian binary packages from the runtimeco APT repository.
-
- **Note:** The key for signing the repository has changed. If you set up your computer before release 1.1.0, you will need to download and import the public key again.
-
-2. Install the latest release version of newt from a Debian binary package. You can use apt-get to install the package or manually download and install the Debian binary package.
-
-3. Download, build, and install the latest release version of newt from source.
-
-If you are installing on an amd64 platform, we recommend that you install from the binary package.
-
-See [Installing Previous Releases of Newt](/newt/install/prev_releases.md) to install an earlier version of newt.
-
-**Note:** We have tested the newt tool binary and apt-get install from the runtimeco APT repository for Ubuntu version 1704. Earlier Ubuntu versions (for example: Ubuntu 14) may have incompatibility with the repository. You can manually download and install the Debian binary package.
-
-**Note:** See [Setting Up a Go Environment to Contribute to Newt and Newtmgr Tools](/faq/go_env) if you want to:
-
-* Use the newt tool with the latest updates from the master branch. The master branch may be unstable and we recommend that you use the latest stable release version.
-* Contribute to the newt tool.
-
-<br>
-### Setting Up Your Computer to use apt-get to Install the Package
-
-The newt Debian packages are stored in a private APT repository on **https://github/runtimeco/debian-mynewt**. To use apt-get, you must set up the following on your computer to retrieve packages from the repository:
-
-**Note**: You only need to perform this setup once on your computer. However, if you previously downloaded and imported the public key for the runtimeco APT repository, you will need to perform step 2 again as the key has changed.
-
-1. Download the public key for the runtimeco APT repository and import the key into the apt keychain.
-2. Add the repository for the binary and source packages to the apt source list.
-
-<br>
-
-Download the public key for the runtimeco apt repo (**Note:** There is a `-` after `apt-key add`):
-
-```no-highlight
-$ wget -qO - https://raw.githubusercontent.com/runtimeco/debian-mynewt/master/mynewt.gpg.key | sudo apt-key add -
-```
-<br>
-
-Add the repository for the binary and source packages to the `mynewt.list` apt source list file:
-
-```no-highlight
-$ sudo tee /etc/apt/sources.list.d/mynewt.list <<EOF
-deb [arch=amd64] https://raw.githubusercontent.com/runtimeco/debian-mynewt/master latest main
-EOF
-```
-
-<br>
-Update the available packages:
-```no-highlight
-$ sudo apt-get update
-```
-<br>
-**Note:** If you are not using Ubuntu version 1704, you may see the following errors. We have provided instructions on how to manually download and install the binary package.
-
-```no-highlight
-
-W: Failed to fetch https://raw.githubusercontent.com/runtimeco/debian-mynewt/master/dists/latest/main/source/Sources HttpError404
-
-```
-<br>
-## Installing the Latest Release of Newt from a Binary Package
-
-You can use either apt-get to install the package, or manually download and install the Debian binary package.
-
-<br>
-#### Method 1: Using apt-get to Upgrade or to Install
-
-Run the following commands to upgrade or install the latest version of newt:
-
-```no-highlight
-$ sudo apt-get update
-$ sudo apt-get install newt
-```
-
-**Note:** If you encounter build errors (such as missing `sys/mman.h`), please make sure you have a 32-bit glibc:
-
-```no-highlight
-$ sudo apt-get install gcc-multilib
-```
-
-<br>
-#### Method 2: Downloading and Installing the Debian Package Manually
-
-Download and install the package manually.
-
-```no-highlight
-$ wget https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.4.0/newt_1.4.0-1_amd64.deb
-$ sudo dpkg -i newt_1.4.0-1_amd64.deb
-```
-<br>
-See [Checking the Installed Version of Newt](#check) to verify that you are using the installed version of newt.
-
-<br>
-### Installing the Latest Release of Newt from a Source Package
-
-If you are running Linux on a different architecture, you can build and install the latest release version of newt from source.
-
-**Note**: newt 1.4.0 requires go version 1.10.
-<br>
-
-1. Download and unpack the newt source:
-
-```no-highlight
-$ wget -P /tmp https://github.com/apache/mynewt-newt/archive/mynewt_1_4_0_tag.tar.gz
-$ tar -xzf /tmp/mynewt_1_4_0_tag.tar.gz
-```
-
-<br>
-2. Run the build.sh to build the newt tool.
-
-```no-highlight
-
-$ cd mynewt-newt-mynewt_1_4_0_tag
-$ ./build.sh
-$ rm /tmp/mynewt_1_4_0_tag.tar.gz
-```
-
-<br>
-4. You should see the `newt/newt` executable. Move the executable to a bin directory in your PATH:
-
-* If you previously built newt from the master branch, you can move the binary to your $GOPATH/bin directory.
-
- $ mv newt/newt $GOPATH/bin
-
-* If you are installing newt for the first time and do not have a Go workspace set up, you can move the binary to /usr/bin or a directory in your PATH:
-
- $ mv newt/newt /usr/bin
-
-
-<br>
-###<a name="check"></a> Checking the Installed Version of Newt
-
-<br>
-1. Check which newt you are using and that the version is the latest release version.
-
-```no-highlight
-$ which newt
-/usr/bin/newt
-$ newt version
-Apache Newt version: 1.4.0
-```
-
-<br>
-2. Get information about newt:
-```no-highlight
-$ newt
-Newt allows you to create your own embedded application based on the Mynewt
-operating system. Newt provides both build and package management in a single
-tool, which allows you to compose an embedded application, and set of
-projects, and then build the necessary artifacts from those projects. For more
-information on the Mynewt operating system, please visit
-https://mynewt.apache.org/.
-
-Please use the newt help command, and specify the name of the command you want
-help for, for help on how to use a specific command
-
-Usage:
- newt [flags]
- newt [command]
-
-Examples:
- newt
- newt help [<command-name>]
- For help on <command-name>. If not specified, print this message.
-
-Available Commands:
- build Build one or more targets
- clean Delete build artifacts for one or more targets
- create-image Add image header to target binary
- debug Open debugger session to target
- info Show project info
- install Install project dependencies
- load Load built target to board
- mfg Manufacturing flash image commands
- new Create a new project
- pkg Create and manage packages in the current workspace
- resign-image Re-sign an image.
- run build/create-image/download/debug <target>
- size Size of target components
- sync Synchronize project dependencies
- target Commands to create, delete, configure, and query targets
- test Executes unit tests for one or more packages
- upgrade Upgrade project dependencies
- vals Display valid values for the specified element type(s)
- version Display the Newt version number
-
-Flags:
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-
-Use "newt [command] --help" for more information about a command.
-
-```
-<br>
diff --git a/docs/newt/install/newt_mac.md b/docs/newt/install/newt_mac.md
deleted file mode 100644
index 255ef56..0000000
--- a/docs/newt/install/newt_mac.md
+++ /dev/null
@@ -1,152 +0,0 @@
-## Installing Newt on Mac OS
-
-Newt is supported on Mac OS X 64 bit platforms and has been tested on Mac OS Sierra.
-
-This page shows you how to install the following versions of newt:
-
-* Upgrade to or install the latest release version (1.4.0).
-* Install the latest from the master branch (unstable).
-
-See [Installing Previous Releases of Newt](/newt/install/prev_releases) to install an earlier version of newt.
-
-**Note:** If you would like to contribute to the newt tool, see [Setting Up Go Environment to Contribute to Newt and Newtmgr Tools](/faq/go_env).
-
-### Installing Homebrew
-
-If you do not have Homebrew installed, run the following command. You will be prompted for your sudo password.
-
-```no-highlight
-$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
-```
-You can also extract (or `git clone`) Homebrew and install it to /usr/local.
-
-### Adding the Mynewt Homebrew Tap
-
-If this is your first time installing newt, add the **runtimeco/homebrew-mynewt** tap:
-
-```no-highlight
-$ brew tap runtimeco/homebrew-mynewt
-$ brew update
-```
-
-### Upgrading to or Installing the Latest Release Version
-
-Perform the following to upgrade or install the latest release version of newt.
-
-#### Upgrading to the Latest Release Version of Newt
-
-If you have installed an earlier version of newt using brew, run the following commands to upgrade to latest version of newt:
-
-```no-highlight
-$ brew update
-$ brew upgrade mynewt-newt
-```
-
-<br>
-#### Installing the Latest Release Version of Newt
-
-Run the following command to install the latest release version of newt:
-
-```no-highlight
-$ brew update
-$ brew install mynewt-newt
-```
-<br>
-**Notes:** Homebrew bottles for newt are available for Mac OS Sierra. If you are running an earlier version of Mac OS, the installation will install the latest version of Go and compile newt locally.
-
-<br>
-### Checking the Installed Version
-
-Check that you are using the installed version of newt:
-
-```no-highlight
-$ which newt
-/usr/local/bin/newt
-$ newt version
-Apache Newt version: 1.4.0
-```
-**Note:** If you previously built newt from source and the output of `which newt` shows "$GOPATH/bin/newt", you will need to move "$GOPATH/bin" after "/usr/local/bin" for your PATH in ~/.bash_profile, and source ~/.bash_profile.
-
-<br>
-Get information about newt:
-
-```no-highlight
-$ newt help
-Newt allows you to create your own embedded application based on the Mynewt
-operating system. Newt provides both build and package management in a single
-tool, which allows you to compose an embedded application, and set of
-projects, and then build the necessary artifacts from those projects. For more
-information on the Mynewt operating system, please visit
-https://mynewt.apache.org/.
-
-Please use the newt help command, and specify the name of the command you want
-help for, for help on how to use a specific command
-
-Usage:
- newt [flags]
- newt [command]
-
-Examples:
- newt
- newt help [<command-name>]
- For help on <command-name>. If not specified, print this message.
-
-Available Commands:
- build Build one or more targets
- clean Delete build artifacts for one or more targets
- create-image Add image header to target binary
- debug Open debugger session to target
- info Show project info
- install Install project dependencies
- load Load built target to board
- mfg Manufacturing flash image commands
- new Create a new project
- pkg Create and manage packages in the current workspace
- resign-image Re-sign an image.
- run build/create-image/download/debug <target>
- size Size of target components
- sync Synchronize project dependencies
- target Commands to create, delete, configure, and query targets
- test Executes unit tests for one or more packages
- upgrade Upgrade project dependencies
- vals Display valid values for the specified element type(s)
- version Display the Newt version number
-
-Flags:
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-
-Use "newt [command] --help" for more information about a command.
-```
-
-<br>
-### Installing Newt from the Master Branch
-
-We recommend that you use the latest release version of newt. If you would like to use the master branch with the latest updates, you can install newt from the HEAD of the master branch.
-
-** Notes: **
-
-* The master branch may be unstable.
-* This installation will install the latest version of Go on your computer, if it is not installed, and compile newt locally.
-
-<br>
-If you previously installed newt using brew, unlink the current version:
-```no-highlight
-$ brew unlink mynewt-newt
-```
-<br>
-Install the latest unstable version of newt from the master branch:
-```no-highlight
-$ brew install mynewt-newt --HEAD
-```
-<br>
-To switch back to the latest stable release version of newt, you can run:
-```no-highlight
-$ brew switch mynewt-newt 1.4.0
-```
-<br>
diff --git a/docs/newt/install/newt_windows.md b/docs/newt/install/newt_windows.md
deleted file mode 100644
index d5c0d4a..0000000
--- a/docs/newt/install/newt_windows.md
+++ /dev/null
@@ -1,201 +0,0 @@
-## Installing Newt on Windows
-
-You can develop and build Mynewt OS applications for your target boards on the Windows platform. This guide shows you how to install the latest release version of newt from binary or from source. The tool is written in Go (golang).
-
-In Windows, we use MinGW as the development environment to build and run Mynewt OS applications for target boards. MinGW runs the bash shell and provides a Unix-like environment. This provides a uniform way to build Mynewt OS applications. The Mynewt documentation and tutorials use Unix commands and you can use the same Unix commands on MinGW to follow the tutorials. The documentation will note any commands or behaviors that are specific to Windows.
-
-This guide shows you how to perform the following:
-
-1. Install MSYS2/MinGW.
-2. Install Git.
-3. Install latest release (1.2.0) of newt from binary.
-4. Install latest release of newt from source.
-
-See [Installing Previous Releases of Newt](/newt/install/prev_releases) to install an earlier version of newt. You still need to set up your MinGW development environment.
-
-**Note:** If you would like to contribute to the newt tool, see [Setting Up Go Environment to Contribute to Newt and Newtmgr Tools](/faq/go_env.md).
-
-<br>
-### Installing MSYS2/MinGW
-MSYS2/MinGW provides a bash shell and tools to build applications that run on Windows. It includes three subsystems:
-
-* MSYS2 toolchain to build POSIX applications that run on Windows.
-* MinGW32 toolchains to build 32 bit native Windows applications.
-* MinGW64 toolchains to build 64 bit native Windows applications.
-
-The subsystems run the bash shell and provide a Unix-like environment. You can also run Windows applications from the shell. We will use the MinGW subsystem.
-
-**Note:** You can skip this installation step if you already have MinGW installed (from an earlier MSYS2/MinGW or Git Bash installation), but you must list the **bin** path for your installation in your Windows Path. For example: if you installed MSYS2/MinGW in the ** C:\msys64 ** directory, add **C:\msys64\usr\bin** to your Windows Path. If you are using Windows 10 WSL, ensure that you use the **C:\msys64\usr\bin\bash.exe** and not the Windows 10 WSL bash.
-
-
-To install and setup MSYS2 and MinGW:
-
-1. Download and run the [MSYS2 installer](http://www.msys2.org). Select the 64 bit version if you are running on a 64 bit platform. Follow the prompts and check the `Run MSYS2 now` checkbox on the `Installation Complete` dialog.
-2. In the MSYS2 terminal, run the `pacman -Syuu` command. If you get a message to run the update again, close the terminal and run the `pacman -Syuu` command in a new terminal.
-
- To start a new MSYS2 terminal, select the "MSYS2 MSYS" application from the Windows start menu.
-
-3. Add a new user variable named **MSYS2_PATH_TYPE** and set the value to **inherit** in your Windows environment. This enables the MSYS2 and MinGW bash to inherit your Windows user **Path** values.
-
- To add the variable, select properties for your computer > Advanced system settings > Environment Variables > New
-
-4. Add the MinGW **bin** path to your Windows Path. For example: if you install MSYS2/MinGW in the **C:\msys64** directory, add **C:\msys64\usr\bin** to your Windows Path.
-
- **Note:** If you are using Windows 10 WSL, ensure that you use the **C:\msys64\usr\bin\bash.exe** and not the Windows 10 WSL bash.
-
-
-5. Run the `pacman -Su vim` command to install the vim editor.
-
- **Note:**You can also use a Windows editor. You can access your files from the **C:\<msys-install-folder>\home\<username>** folder, where **msys-install-folder** is the folder you installed MSYS2 in. For example, if you installed MSYS2 in the **msys64** folder, your files are stored in **C:\msys64\home\<username>**
-
-6. Run the `pacman -Su tar` command to install the tar tool.
-
-You will need to start a MinGW terminal to run the commands specified in the Mynewt documentation and tutorials. To start a MinGW terminal, select the "MSYS2 Mingw" application from the start Menu (you can use either MinGW32 or MinGW64).
-In Windows, we use the MinGW subsystem to build Mynewt tools and applications.
-
-### Installing Git for Windows
-
-Download and install [Git for Windows](https://git-for-windows.github.io) if it is not already installed.
-
-
-### Installing the Latest Release of the Newt Tool from Binary
-
-You can install the latest release of newt from binary. It has been tested on Windows 10 64 bit platform.
-
-<br>
-1. Start a MinGW terminal.
-
-<br>
-2. Download the newt binary tar file:
-
-```no-highlight
-
-$ wget -P /tmp https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.3.0/newt_1_3_0_windows_amd64.tar.gz
-
-```
-<br>
-3. Extract the file:
-
-* If you previously built newt from the master branch, you can extract the file into your $GOPATH/bin directory. Note: This overwrites the current newt.exe in the directory and assumes that you are using $GOPATH/bin for your Go applications.
-
- tar -xzf /tmp/newt_1_3_0_windows_amd64.tar.gz -C $GOPATH/bin
-
-* If you are installing newt for the first time and do not have a Go workspace setup, you can extract into /usr/bin directory:
-
- tar -xzf /tmp/newt_1_3_0_windows_amd64.tar.gz -C /usr/bin
-
-
-<br>
-4. Verify the installed version of newt. See [Checking the Installed Version](#check_newt).
-
-<br>
-### Installing the Latest Release of Newt From Source
-
-If you have an older version of Windows or a 32 bit platform, you can build and install the latest release version of newt from source.
-
-<br>
-1. If you do not have Go installed, download and install the latest version of [Go](https://golang.org/dl/). Newt requires Go version 1.7.6 or higher.
-
-<br>
-2. Start a MinGw terminal.
-
-<br>
-3. Download and unpack the newt source:
-
-```no-highlight
-
-$ wget -P /tmp https://github.com/apache/mynewt-newt/archive/mynewt_1_3_0_tag.tar.gz
-$ tar -xzf /tmp/mynewt_1_3_0_tag.tar.gz
-```
-
-<br>
-4. Run the build.sh to build the newt tool.
-
-```no-highlight
-
-$ cd mynewt-newt-mynewt_1_3_0_tag
-$ ./build.sh
-$ rm /tmp/mynewt_1_3_0_tag.tar.gz
-```
-
-<br>
-5. You should see the `newt/newt.exe` executable. Move the executable to a bin directory in your PATH:
-
-* If you previously built newt from the master branch, you can move the executable to the $GOPATH/bin directory.
-
- $ mv newt/newt.exe $GOPATH/bin
-
-* If you are installing newt for the first time and do not have a Go workspace set up, you can move the executable to /usr/bin or a directory in your PATH:
-
- $ mv newt/newt.exe /usr/bin
-
-<br>
-### <a name="check_newt"></a>Checking the Installed Version
-
-<br>
-1. Check the version of newt:
-
-```no-highlight
-
-$ newt version
-Apache Newt version: 1.3.0
-
-```
-
-<br>
-2. Get information about newt:
-
-```no-highlight
-
-Newt allows you to create your own embedded application based on the Mynewt
-operating system. Newt provides both build and package management in a single
-tool, which allows you to compose an embedded application, and set of
-projects, and then build the necessary artifacts from those projects. For more
-information on the Mynewt operating system, please visit
-https://mynewt.apache.org/.
-
-Please use the newt help command, and specify the name of the command you want
-help for, for help on how to use a specific command
-
-Usage:
- newt [flags]
- newt [command]
-
-Examples:
- newt
- newt help [<command-name>]
- For help on <command-name>. If not specified, print this message.
-
-Available Commands:
- build Build one or more targets
- clean Delete build artifacts for one or more targets
- create-image Add image header to target binary
- debug Open debugger session to target
- info Show project info
- install Install project dependencies
- load Load built target to board
- mfg Manufacturing flash image commands
- new Create a new project
- pkg Create and manage packages in the current workspace
- resign-image Re-sign an image.
- run build/create-image/download/debug <target>
- size Size of target components
- sync Synchronize project dependencies
- target Commands to create, delete, configure, and query targets
- test Executes unit tests for one or more packages
- upgrade Upgrade project dependencies
- vals Display valid values for the specified element type(s)
- version Display the Newt version number
-
-Flags:
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-
-Use "newt [command] --help" for more information about a command.
-
-```
diff --git a/docs/newt/install/prev_releases.md b/docs/newt/install/prev_releases.md
deleted file mode 100644
index d22cd79..0000000
--- a/docs/newt/install/prev_releases.md
+++ /dev/null
@@ -1,81 +0,0 @@
-## Installing Previous Releases of Newt
-
-This page shows you how to install previous releases of newt for Mac OS, Linux, and Windows.
-
-
-### Mac OS
-You can install previous releases of newt using `mynewt-newt@X.Y` Homebrew formulas, where X.Y is a version number.
-
-For example, if you want to install newt 1.0, run the following commands:
-
-```no-highlight
-
-$ brew update
-$ brew install mynewt-newt@1.0
-
-```
-
-**Note:** This is a keg-only installation. newt 1.0 is installed in /usr/local/Cellar/mynewt-newt@1.0/1.0.0/bin but not symlinked into /usr/local/bin.
-
-If you need this version of newt first in your PATH, run the following commands:
-
-```no-highlight
-
-$ echo 'export PATH=/usr/local/Cellar/mynewt-newt@1.0/1.0.0/bin:$PATH' >> ~/.bash_profile
-$ source ~/.bash_profile
-
-```
-
-<br>
-You can also manually symlink into /usr/local/bin as follows:
-
-<br>
-1. Unlink newt if you have the latest version of newt installed:
-
-```no-highlight
-$ brew unlink mynewt-newt
-```
-<br>
-2. Link mynewt-newt@1.0 into /usr/local/bin:
-
-```no-highlight
-$ brew link -f mynewt-newt@1.0
-```
-
-<br>
-### Linux
-<br>
-1. Download the binary:
-
-Version|Download
--------|--------
-1.0.0 |[newt_1.0.0-1_amd64.deb](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.0.0/newt_1.0.0-1_amd64.deb)
-1.1.0 |[newt_1.1.0-1_amd64.deb](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.1.0/newt_1.1.0-1_amd64.deb)
-1.2.0 |[newt_1.2.0-1_amd64.deb](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.2.0/newt_1.2.0-1_amd64.deb)
-1.3.0 |[newt_1.3.0-1_amd64.deb](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.3.0/newt_1.3.0-1_amd64.deb)
-
-<br>
-2. Run the `sudo apt-get remove newt` command to remove the the current installation.
-
-<br>
-3. Install the package. For example, run `sudo dpkg -i newt_1.0.0-1_amd64.deb` to install newt 1.0.0
-
-<br>
-### Windows
-<br>
-1. Download the binary:
-
-Version|Download
--------|--------
-1.1.0 |[newt_1_1_0_windows_amd64.tar.gz](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.1.0/newt_1_1_0_windows_amd64.tar.gz)
-
-<br>
-2. Extract the file:
-
-* If you previously built newt from the master branch, you can extract the file into your $GOPATH/bin directory. Note: This overwrites the current newt.exe in the directory and assumes that you are using $GOPATH/bin for your Go applications.
-
- tar -xzf newt_1_1_0_windows_amd64.tar.gz -C $GOPATH/bin
-
-* If you are installing newt for the first time and do not have a Go workspace setup, you can extract into /usr/bin directory:
-
- tar -xzf newt_1_1_0_windows_amd64.tar.gz -C /usr/bin
diff --git a/docs/newt/newt_intro.md b/docs/newt/newt_intro.md
deleted file mode 100644
index 6812478..0000000
--- a/docs/newt/newt_intro.md
+++ /dev/null
@@ -1,202 +0,0 @@
-## Newt Tool
-
-### Introduction
-
-Newt is a smart build and package management system for embedded contexts. It is a single tool that accomplishes both the following goals:
-
-* source package management
-* build, debug and install.
-
-### Rationale
-
-In order for the Mynewt operating system to work well for constrained environments across the many different types of microcontroller applications (from doorbells to medical devices to power grids), a system is needed that lets you select which packages to install and which packages to build.
-
-The build systems for embedded devices are often fairly complicated and not well served for this purpose. For example, autoconf is designed for detecting system compatibility issues but not well suited when it comes to tasks like:
-
-* Building for multiple targets
-* Deciding what to build in and what not to build in
-* Managing dependencies between components
-
-Fortunately, solutions addressing these very issues can be found in source package management systems in higher level languages such as Javascript
-(Node), Go, PHP and Ruby. We decided to fuse their source management
-systems with a make system built for embedded systems and create Newt.
-
-### Build System
-
-A good build system must allow the user to take a few common steps while developing embedded applications:
-
-* Generate full flash images
-* Download debug images to a target board using a debugger
-* Conditionally compile libraries & code based upon build settings
-
-Newt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in mynewt-blinky/develop:
-
-```hl_lines="7 12"
-$ tree -L 3
-.
-├── DISCLAIMER
-├── LICENSE
-├── NOTICE
-├── README.md
-├── apps
-│ └── blinky
-│ ├── pkg.yml
-│ └── src
-├── project.yml
-└── targets
- ├── my_blinky_sim
- │ ├── pkg.yml
- │ └── target.yml
- └── unittest
- ├── pkg.yml
- └── target.yml
-
-6 directories, 10 files
-```
-
-<br>
-
-When Newt sees a directory tree that contains a "project.yml" file, it is smart enough to recognize it as the base directory of a project, and
-automatically builds a package tree. It also recognizes two important package directories in the package tree - "apps" and "targets". More on these directories in [Newt Theory of Ops](newt_operation.md).
-
-
-When Newt builds a target, it recursively resolves all package dependencies, and generates artifacts that are placed in the bin/targets/<target-name>/app/apps/<app-name> directory, where the bin directory is under the project base directory, `target-name` is the name of the target, and `app-name` is the name of the application. For our example `my_blinky_sim` is the name of the target and `blinky` is the name of the application. The `blinky.elf` executable is stored in the bin/targets/my_blinky_sim/app/apps/blinky directory as shown in the source tree:
-
-```
-tree -L 6 bin/
-bin/
-└── targets
- ├── my_blinky_sim
- │ ├── app
- │ │ ├── apps
- │ │ │ └── blinky
- │ │ │ ├── apps
- │ │ │ ├── apps_blinky.a
- │ │ │ ├── apps_blinky.a.cmd
- │ │ │ ├── blinky.elf
- │ │ │ ├── blinky.elf.cmd
- │ │ │ ├── blinky.elf.dSYM
- │ │ │ ├── blinky.elf.lst
- │ │ │ └── manifest.json
- │ │ ├── hw
- │ │ │ ├── bsp
- │ │ │ │ └── native
- │ │ │ ├── drivers
- │ │ │ │ └── uart
- │ │ │ ├── hal
- │ │ │ │ ├── hw_hal.a
- │ │ │ │ ├── hw_hal.a.cmd
- │ │ │ │ └── repos
-
-<snip>
-```
-
-<br>
-
-### More operations using Newt
-
-Once a target has been built, Newt allows additional operations on the target.
-
-* **load**: Download built target to board
-* **debug**: Open debugger session to target
-* **size**: Get size of target components
-* **create-image**: Add image header to the binary image
-* **run**: Build, create image, load, and finally open a debug session with the target
-* **target**: Create, delete, configure, and query a target
-
-For more details on how Newt works, go to [Newt - Theory of Operations](newt_operation.md).
-
-<br>
-
-### Source Management and Repositories
-
-The other major element of the Newt tool is the ability to create reusable source distributions from a collection of code. **A project can be a reusable container of source code.** In other words, projects can be versioned and redistributed, not packages. A project bundles together packages that are typically needed to work together in a product e.g. RTOS core, filesystem APIs, and networking stack.
-
-A project that has been made redistributable is known as a **repository**.
-Repositories can be added to your local project by adding them into your project.yml file. Here is an example of the blinky project's yml file which relies on apache-mynewt-core:
-
-```
-$ more project.yml
-<snip>
-project.repositories:
- - apache-mynewt-core
-
-# Use github's distribution mechanism for core ASF libraries.
-# This provides mirroring automatically for us.
-#
-repository.apache-mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: incubator-mynewt-core
-```
-
-<br>
-
-When you specify this repository in the blinky's project file, you can then use the Newt tool to install dependencies:
-
-```
-$ newt install
-Downloading repository description for apache-mynewt-core... success!
-Downloading repository incubator-mynewt-core (branch: develop) at
-https://github.com/apache/incubator-mynewt-core.git
-Cloning into
-'/var/folders/7l/7b3w9m4n2mg3sqmgw2q1b9p80000gn/T/newt-repo814721459'...
-remote: Counting objects: 17601, done.
-remote: Compressing objects: 100% (300/300), done.
-remote: Total 17601 (delta 142), reused 0 (delta 0), pack-reused 17284
-Receiving objects: 100% (17601/17601), 6.09 MiB | 3.17 MiB/s, done.
-Resolving deltas: 100% (10347/10347), done.
-Checking connectivity... done.
-Repos successfully installed
-```
-
-<br>
-
-Newt will install this repository in the <project>/repos directory. In the case of blinky, the directory structure ends up looking like:
-
-```
-$ tree -L 2
-.
-├── DISCLAIMER
-├── LICENSE
-├── NOTICE
-├── README.md
-├── apps
-│ └── blinky
-├── project.state
-├── project.yml
-├── repos
-│ └── apache-mynewt-core
-└── targets
- ├── my_blinky_sim
- └── unittest
-```
-
-<br>
-
-In order to reference the installed repositories in packages, the "@" notation should be specified in the repository specifier. As an example, the apps/blinky application has the following dependencies in its pkg.yml file. This tells the build system to look in the base directory of repos/apache-mynewt-core for the `kernel/os`, `hw/hal`, and `sys/console/full` packages.
-
-```
-$ more apps/blinky/pkg.yml
-<snip>
-pkg.deps:
- - "@apache-mynewt-core/kernel/os"
- - "@apache-mynewt-core/hw/hal"
- - "@apache-mynewt-core/sys/console/full"
-```
-
-<br>
-
-
-
-Newt has the ability to autocomplete within `bash`. The following instructions allow MAC users to enable autocomplete within `bash`.
-
-1. Install the autocomplete tools for bash via `brew install bash-completion`
-2. Tell your shell to use newt for autocompletion of newt via `complete -C "newt complete" newt`. You can add this to your .bashrc or other init file to have it automatically set for all bash shells.
-
-Notes:
-
-1. Autocomplete will give you flag hints, but only if you type a '-'.
-2. Autocomplete will not give you completion hints for the flag arguments (those optional things after the flag like `-l DEBUG`)
-3. Autocomplete uses newt to parse the project to find targets and libs.
diff --git a/docs/newt/newt_operation.md b/docs/newt/newt_operation.md
deleted file mode 100644
index c45c829..0000000
--- a/docs/newt/newt_operation.md
+++ /dev/null
@@ -1,309 +0,0 @@
-## Newt Tool - Theory of Operations
-
-Newt has a fairly smart package manager that can read a directory tree, build a dependency tree, and emit the right build artifacts.
-
-### Building dependencies
-
-Newt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in mynewt-blinky/develop:
-
-```hl_lines="7 12"
-$ tree -L 3
-.
-├── DISCLAIMER
-├── LICENSE
-├── NOTICE
-├── README.md
-├── apps
-│ └── blinky
-│ ├── pkg.yml
-│ └── src
-├── project.yml
-└── targets
- ├── my_blinky_sim
- │ ├── pkg.yml
- │ └── target.yml
- └── unittest
- ├── pkg.yml
- └── target.yml
-
-6 directories, 10 files
-```
-
-<br>
-
-When newt sees a directory tree that contains a "project.yml" file it knows that it is in the base directory of a project, and automatically builds a package tree. You can see that there are two essential package directories, "apps" and "targets."
-
-<br>
-
-#### "apps" Package Directory
-
-`apps` is where applications are stored, and applications are where the main() function is contained. The base project directory comes with one simple app called `blinky` in the `apps` directory. The core repository `@apache-mynewt-core` comes with many additional sample apps in its `apps` directory. At the time of this writing, there are several example BLE apps, the boot app, slinky app for using newt manager protocol, and more in that directory.
-
-```
-@~/dev/myproj$ ls repos/apache-mynewt-core/apps/
-blecent bleprph bsnprph ocf_sample testbench
-blecsc bleprph_oic btshell pwm_test timtest
-blehci blesplit ffs2native sensors_test trng_test
-blehr bletest iptest slinky
-blemesh bleuart lora_app_shell slinky_oic
-blemesh_light boot loraping spitest
-blemesh_shell bsncent lorashell splitty
-```
-
-Along with the `targets` directory, `apps` represents the top-level of the build tree for the particular project, and define the dependencies for the rest of the system. Mynewt users and developers can add their own apps to the project's `apps` directory.
-
-The app definition is contained in a `pkg.yml` file. For example, blinky's `pkg.yml` file is:
-
-```
-$ more apps/blinky/pkg.yml
-<snip>
-pkg.name: apps/blinky
-pkg.type: app
-pkg.description: Basic example application which blinks an LED.
-pkg.author: "Apache Mynewt <dev@mynewt.apache.org>"
-pkg.homepage: "http://mynewt.apache.org/"
-pkg.keywords:
-
-pkg.deps:
- - "@apache-mynewt-core/kernel/os"
- - "@apache-mynewt-core/hw/hal"
- - "@apache-mynewt-core/sys/console/full"
-```
-
-<br>
-
-This file says that the name of the package is apps/blinky, and it depends on the `kernel/os, `hw/hal` and `sys/console/full` packages.
-
-**NOTE:** @apache-mynewt-core is a repository descriptor, and this will be
-covered in the "repository" section.
-
-<br>
-
-#### "targets" Package Directory
-
-`targets` is where targets are stored, and each target is a collection of parameters that must be passed to newt in order to generate a reproducible build. Along with the `apps` directory, `targets` represents the top of the build tree. Any packages or parameters specified at the target level cascades down to all dependencies.
-
-Most targets consist of:
-
-* app: The application to build
-* bsp: The board support package to combine with that application
-* build_profile: Either debug or optimized.
-
-The `my_blinky_sim` target that is included by default has the following settings:
-
-```
-$ newt target show
-targets/my_blinky_sim
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/native
- build_profile=debug
-$ ls targets/my_blinky_sim/
-pkg.yml target.yml
-```
-There are helper functions to aid the developer specify parameters for a target.
-
-* **vals**: Displays all valid values for the specified parameter type (e.g. bsp for a target)
-* **target show**: Displays the variable values for either a specific target or all targets defined for the project
-* **target set**: Sets values for target variables
-
-In general, the three basic parameters of a target (`app`, `bsp`, and `build_profile`) are stored in the target's `target.yml` file in the targets/<target-name> directory, where `target-name` is the name of the target. You will also see a `pkg.yml` file in the same directory. Since targets are packages, a `pkg.yml` is expected. It contains typical package descriptors, dependencies, and additional parameters such as the following:
-
-* Cflags: Any additional compiler flags you might want to specify to the build
-* Aflags: Any additional assembler flags you might want to specify to the build
-* Lflags: Any additional linker flags you might want to specify to the build
-
-You can also override the values of the system configuration settings that are defined by the packages that your target includes. You override the values in your target's `syscfg.yml` file (stored in the targets/<target-name> directory). You can use the `newt target config show` command to see the configuration settings and values for your target, and use the `newt target set` command to set the `syscfg` variable and override the configuration setting values. You can also use an editor to create your target's `syscfg.yml` file and add the setting values to the file. See [System Configuration And Initialization](/os/modules/sysinitconfig/sysinitconfig.md) for more information on system configuration settings.
-
-<br>
-
-
-### Resolving dependencies
-
-When newt builds a project, it will:
-
-* find the top-level project.yml file
-* recurse the packages in the package tree, and build a list of all
-source packages
-
-Newt then looks at the target that the user set, for example, blinky_sim:
-
-```
-$ more targets/my_blinky_sim/
-pkg.yml target.yml
-$ more targets/my_blinky_sim/target.yml
-### Target: targets/my_blinky_sim
-target.app: "apps/blinky"
-target.bsp: "@apache-mynewt-core/hw/bsp/native"
-target.build_profile: "debug"
-```
-
-<br>
-
-The target specifies two major things:
-
-* Application (target.app): The application to build
-* Board Support Package (target.bsp): The board support package to build
-along with that application.
-
-Newt builds the dependency tree specified by all the packages. While building this tree, it does a few other things:
-
-- Sets up the include paths for each package. Any package that depends on another package, automatically gets the include directories from the package it includes. Include directories in the
-newt structure must always be prefixed by the package name. For example, kernel/os has the following include tree and its include directory files contains the package name "os" before any header files. This is so in order to avoid any header file conflicts.
-
-
-```
-$tree kernel/os/include
-kernel/os/include
-└── os
- ├── arch
- │ ├── cortex_m0
- │ │ └── os
- │ │ └── os_arch.h
- │ ├── cortex_m4
- │ │ └── os
- │ │ └── os_arch.h
- │ ├── mips
- │ │ └── os
- │ │ └── os_arch.h
- │ ├── sim
- │ │ └── os
- │ │ └── os_arch.h
- │ └── sim-mips
- │ └── os
- │ └── os_arch.h
- ├── endian.h
- ├── os.h
- ├── os_callout.h
- ├── os_cfg.h
- ├── os_cputime.h
- ├── os_dev.h
- ├── os_eventq.h
- ├── os_fault.h
- ├── os_heap.h
- ├── os_malloc.h
- ├── os_mbuf.h
- ├── os_mempool.h
- ├── os_mutex.h
- ├── os_sanity.h
- ├── os_sched.h
- ├── os_sem.h
- ├── os_task.h
- ├── os_test.h
- ├── os_time.h
- └── queue.h
-
-<snip>
-
-```
-
-<br>
-
-- Validates API requirements. Packages can export APIs they
-implement, (i.e. pkg.api: hw-hal-impl), and other packages can require
-those APIs (i.e. pkg.req_api: hw-hal-impl).
-
-- Reads and validates the configuration setting definitions and values from the package `syscfg.yml` files.
-It generates a `syscfg.h` header file that packages include in the source files in order to access the settings.
-It also generates a system initialization function to initialize the packages.
-See [System Configuration And Initialization](/os/modules/sysinitconfig/sysinitconfig.md) for more information.
-
-
-In order to properly resolve all dependencies in the build system, newt recursively processes the package dependencies until there are no new dependencies. And it builds a big list of all the packages that need to be built.
-
-
-Newt then goes through this package list, and builds every package into
-an archive file.
-
-**NOTE:** The newt tool generates compiler dependencies for all of these packages, and only rebuilds the packages whose dependencies have changed. Changes in package & project dependencies are also taken into account. It is smart, after all!
-
-### Producing artifacts
-
-Once newt has built all the archive files, it then links the archive files together. The linkerscript to use is specified by the board support package (BSP.)
-
-The newt tool creates a bin directory under the base project directory, and places a target's build artifacts into the bin/targets/<target-name>/app/apps/<app-name> directory, where `target-name` is the name of the target and `app-name` is the name of the application. As an example, the `blinky.elf` executable for the `blinky` application defined by the `my_blinky_sim` target is stored in the bin/targets/my_blinky_sim/app/apps/blinky directory as shown in the following source tree:
-
-```
-$tree -L 9 bin/ bin/
-└── targets
- ├── my_blinky_sim
- │ ├── app
- │ │ ├── apps
- │ │ │ └── blinky
- │ │ │ ├── apps
- │ │ │ │ └── blinky
- │ │ │ │ └── src
- │ │ │ │ ├── main.d
- │ │ │ │ ├── main.o
- │ │ │ │ └── main.o.cmd
- │ │ │ ├── apps_blinky.a
- │ │ │ ├── apps_blinky.a.cmd
- │ │ │ ├── blinky.elf
- │ │ │ ├── blinky.elf.cmd
- │ │ │ ├── blinky.elf.dSYM
- │ │ │ │ └── Contents
- │ │ │ │ ├── Info.plist
- │ │ │ │ └── Resources
- │ │ │ │ └── DWARF
- │ │ │ ├── blinky.elf.lst
- │ │ │ └── manifest.json
- │ │ ├── hw
- │ │ │ ├── bsp
- │ │ │ │ └── native
- │ │ │ │ ├── hw_bsp_native.a
- │ │ │ │ ├── hw_bsp_native.a.cmd
- │ │ │ │ └── repos
- │ │ │ │ └── apache-mynewt-core
- │ │ │ │ └── hw
-
-<snip>
-```
-
-<br>
-
-As you can see, a number of files are generated:
-
-- Archive File
-- *.cmd: The command use to generate the object or archive file
-- *.lst: The list file where symbols are located
-
-Note: The *.o object files that get put into the archive file are stored in the bin/targets/my_blinky_sim/app/apps/blinky/apps/blinky/src directory.
-
-### Download/Debug Support
-
-Once a target has been build, there are a number of helper functions
-that work on the target. These are:
-
-* **load** Download built target to board
-* **debug** Open debugger session to target
-* **size** Size of target components
-* **create-image** Add image header to target binary
-* **run** The equivalent of build, create-image, load, and debug on specified target
-* **target** Create, delete, configure, and query a target
-
-`load` and `debug` handles driving GDB and the system debugger. These
-commands call out to scripts that are defined by the BSP.
-
-```
-$ more repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_debug.sh
-<snip>
-. $CORE_PATH/hw/scripts/jlink.sh
-
-FILE_NAME=$BIN_BASENAME.elf
-
-if [ $# -gt 2 ]; then
- SPLIT_ELF_NAME=$3.elf
- # TODO -- this magic number 0x42000 is the location of the second image
- # slot. we should either get this from a flash map file or somehow learn
- # this from the image itself
- EXTRA_GDB_CMDS="add-symbol-file $SPLIT_ELF_NAME 0x8000 -readnow"
-fi
-
-JLINK_DEV="nRF52"
-
-jlink_debug
-
-```
-
-The idea is that every BSP will add support for the debugger environment
-for that board. That way common tools can be used across various development boards and kits.
-
diff --git a/docs/newt/newt_ops.md b/docs/newt/newt_ops.md
deleted file mode 100644
index 1a405ac..0000000
--- a/docs/newt/newt_ops.md
+++ /dev/null
@@ -1,50 +0,0 @@
-## Command Structure
-
-Just like verbs are actions in a sentence and adverbs modifiy verbs, so in the *newt* tool, commands are actions and flags modify actions. A command can have subcommands. Arguments to commands and subcommands, with appropriate flags, dictate the execution and result of a command.
-
-For instance, in the example below, the *newt* command has the subcommand `target set` in which the argument 'my_target1' is the target whose attribute, *app*, is set to '@apache-mynewt-core/hw/bsp/nrf52dk'
-
-```no-highlight
- newt target set my_target1 app=@apache-mynewt-core/hw/bsp/nrf52dk
-```
-
-Global flags work uniformly across *newt* commands. Consider the flag `-v, --verbose,` It works both for command and subcommands, to generate verbose output. Likewise, the help flag `-h` or `--help,` to print helpful messsages.
-
-A command may additionally take flags specific to it. For example, the `-n ` flag instructs `newt debug` not to start GDB from command line.
-
-```no-highlight
- newt debug <target-name> -n
-```
-In addition to the [Newt Tool Manual](newt_intro.md) in docs, command-line help is available for each command (and subcommand), through the `-h` or `--help` options.
-
-```no-highlight
- newt target --help
- Commands to create, delete, configure, and query targets
-
- Usage:
- newt target [flags]
- newt target [command]
-
- Available Commands:
- amend Add, change, or delete values for multi-value target variables
- config View or populate a target's system configuration
- copy Copy target
- create Create a target
- delete Delete target
- dep View target's dependency graph
- revdep View target's reverse-dependency graph
- set Set target configuration variable
- show View target configuration variables
-
- Global Flags:
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-
- Use "newt target [command] --help" for more information about a command.
-
-```
diff --git a/docs/newtmgr/command_list/newtmgr_config.md b/docs/newtmgr/command_list/newtmgr_config.md
deleted file mode 100644
index bcf0546..0000000
--- a/docs/newtmgr/command_list/newtmgr_config.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr config </font>
-Read and write config values on a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr config <var-name> [var-value] -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-Reads and sets the value for the `var-name` config variable on a device. Specify a `var-value` to set the value for the `var-name` variable. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newtmgr config myvar -c profile01 | Reads the `myvar` config variable value from a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
- | newtmgr config myvar 2 -c profile01 | Sets the `myvar` config variable to the value `2` on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-
diff --git a/docs/newtmgr/command_list/newtmgr_conn.md b/docs/newtmgr/command_list/newtmgr_conn.md
deleted file mode 100644
index 95d0610..0000000
--- a/docs/newtmgr/command_list/newtmgr_conn.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr conn </font>
-Manage newtmgr connection profiles.
-
-#### Usage:
-
-```no-highlight
- newtmgr conn [command] [flags]
-```
-
-#### Flags:
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-The conn command provides subcommands to add, delete, and view connection profiles. A connection profile specifies information on how to connect and communicate with a remote device. Newtmgr commands use the information from a connection profile to send newtmgr requests to remote devices.
-
-Sub-command | Explanation
--------------| ------------------------
-add | The newtmgr conn add <conn_profile> <var-name=value ...> command creates a connection profile named `conn_profile`. The command requires the `conn_profile` name and a list of, space separated, var-name=value pairs. The var-names are: `type`, and `connstring`. <br><br>The valid values for each var-name parameter are: <ul><li>`type`: The connection type. Valid values are: <ul><li>**serial**: Newtmgr protocol over a serial connection.</li><li> **oic_serial**: OIC protocol over a serial connection.</li><li> **udp**:newtmgr protocol over UDP.</li><li> **oic_udp**: OIC protocol over UDP.</li><li>**ble** newtmgr protocol over BLE. This type uses native OS BLE support </li><li> **oic_ble**: OIC protocol over BLE. This type uses native OS BLE support. </li><li> **bhd**: newtmgr protocol over BLE. This type uses the blehostd implemenation.</li><li> **oic_bhd**: OIC protocol over BLE. This type uses the blehostd implementation. </li></li></ul><br>**Note:** newtmgr does not support BLE on Windows.<br><br><li>`connstring`: The physical or virtual address for the connection. <br><br> The format of the `connstring` value depends on the connection `type` value as follows:<ul><li>**serial** and **oic_serial**: A quoted string with two, comma separated, `attribute=value` pairs. The attribute names and value format for each attribute are: <ul><li>`dev`: (Required) The name of the serial port to use. For example: **/dev/ttyUSB0** on a Linux platform or **COM1** on a Windows platform .</li><li>`baud`: (Optional) A number that specifies the buad rate for the connection. Defaults to **115200** if the attribute is not specified.</li> </li></ul><br>Example: connstring="dev=/dev/ttyUSB0, baud=9600"<br><br> **Note:** The 1.0 format, which only requires a serial port name, is still supported. For example, `connstring=/dev/ttyUSB0`.</li><br><li>**udp** and **oic_udp**: The peer ip address and port number that the newtmgr or oicmgr on the remote device is listening on. It must be of the form: **[<ip-address>]:<port-number>**. </li><br><li>**ble** and **oic_ble**: The format is a quoted string of, comma separated, `attribute=value` pairs. The attribute names and the value for each attribute are:<ul><li>`peer_name`: A string that specifies the name the peer BLE device advertises.<br><br>**Note**: If this attribute is specified, you do not need to specify a value for the `peer_id` attribute.</li><br><li>`peer_id`: The peer BLE device address or UUID. The format depends on the OS that the newtmgr tool is running on:<ul></li>**Linux**: 6 byte BLE address. Each byte must be a hexidecimal number and separated by a colon.</li><li>**MacOS**: 128 bit UUID.</li></ul><br>**Note**: This value is only used when a peer name is not specified for the connection profile or with the `--name` flag option. </li><br><li>`ctlr_name`: (Optional) Controller name. This value depends on the OS that the newtmgr tool is running on. </li></ul><br>**Notes**: <ul><li>You must specify `connstring=" "` if you do not specify any attribute values.</li><li>You can use the `--name` flag to specify a device name when you issue a newtmgr command that communicates with a BLE device. You can use this flag to override or in lieu of specifying a `peer_name` or `peer_id` attribute in the connection profile.</li></ul><br><li>**bhd** and **oic_bhd**: The format is a quoted string of, comma separated, `attribute=value` pairs. The attribute names and the value format for each attribute are: <ul><li>`peer_name`: A string that specifies the name the peer BLE device advertises. <br><br>**Note**: If this attribute is specified, you do not need to specify values for the `peer_addr` and `peer_addr_type` attributes.</li> <br><li>`peer_addr`: A 6 byte peer BLE device address. Each byte must be a hexidecimal number and separated by a colon. You must also specify a `peer_addr_type` value for the device address. <br><br>**Note:** This value is only used when a peer name is not specified for the connection profile or with the `--name` flag option.</li><br><li> `peer_addr_type`: The peer address type. Valid values are:<ul><li>**public**: Public address assigned by the manufacturer.</li><li> **random**: Static random address.</li><li>**rpa_pub**: Resolvable Private Address with public identity address.</li><li>**rpa_rnd**: Resolvable Private Address with static random identity address.</li></ul><br>**Note:** This value is only used when a peer name is not specified for the connection profile or with the `--name` flag option.</li><br></li><li>`own_addr_type`: (Optional) The address type of the BLE controller for the host that the newtmgr tool is running on. See the `peer_addr_type` attribute for valid values. Defaults to **random**. </li><br><li>`ctlr_path`: The path of the port that is used to connect the BLE controller to the host that the newtmgr tool is running on.</li></ul><br> **Note**: You can use the `--name` flag to specify a device name when you issue a newtmgr command that communicates with a BLE device. You can use this flag to override or in lieu of specifying a `peer_name` or `peer_addr` attribute in the connection profile.
-</li></ul></li></ul></li></ul>
-delete | The newtmgr conn delete <conn_profile> command deletes the `conn_profile` connection profile.
-show | The newtmgr conn show [conn_profile] command shows the information for the `conn_profile` connection profile. It shows information for all the connection profiles if `conn_profile` is not specified.
-
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-add | newtmgr conn add myserial02 type=oic_serial connstring=/dev/ttys002 | Creates a connection profile, named `myserial02`, to communicate over a serial connection at 115200 baud rate with the oicmgr on a device that is connected to the host on port /dev/ttys002.
-add | newtmgr conn add myserial03 type=serial connstring="dev=/dev/ttys003, baud=57600" | Creates a connection profile, named `myserial03`, to communicate over a serial connection at 57600 baud rate with the newtmgr on a device that is connected to the host on port /dev/ttys003.
-add | newtmgr conn add myudp5683 type=oic_udp<br>connstring=[127.0.0.1]:5683 | Creates a connection profile, named `myudp5683`, to communicate over UDP with the oicmgr on a device listening on localhost and port 5683.
-add | newtmgr conn add mybleprph type=ble connstring="peer_name=nimble-bleprph"| Creates a connection profile, named `mybleprph`, to communicate over BLE, using the native OS BLE support, with the newtmgr on a device named `nimble-bleprph`.
-add | newtmgr conn add myble<br>type=ble connstring=" "| Creates a connection profile, named `myble`, to communicate over BLE, using the native OS BLE support, with the newtmgr on a device. You must use the `--name` flag to specify the device name when you issue a newtmgr command that communicates with the device. |
-add | newtmgr conn add myblehostd type=oic_bhd connstring="peer_name=nimble-bleprph,ctlr_path=/dev/cu.usbmodem14221" | Creates a connection profile, named `myblehostd`, to communicate over BLE, using the blehostd implementation, with the oicmgr on a device named `nimble-bleprph`. The BLE controller is connected to the host on USB port /dev/cu.usbmodem14211 and uses static random address.
-delete | newtmgr conn delete myserial02 | Deletes the connection profile named `myserial02`
-delete | newtmgr conn delete myserial02 | Deletes the connection profile named `myserial02`
-show | newtmgr conn show myserial01 | Displays the information for the `myserial01` connection profile.
-show | newtmgr conn show | Displays the information for all connection profiles.
diff --git a/docs/newtmgr/command_list/newtmgr_crash.md b/docs/newtmgr/command_list/newtmgr_crash.md
deleted file mode 100644
index f8ecc00..0000000
--- a/docs/newtmgr/command_list/newtmgr_crash.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr crash </font>
-Send a crash command to a device.
-
-
-#### Usage:
-
-```no-highlight
- newtmgr crash <assert|div0|jump0|ref0|wdog> -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-Sends a crash command to a device to run one of the following crash tests: `div0`, `jump0`, `ref0`, `assert`, `wdog`. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newtmgr crash div0<br>-c profile01 | Sends a request to a device to execute a divide by 0 test. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
- | newtmgr crash ref0<br>-c profile01 | Sends a request to a device to execute a nil pointer reference test. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
diff --git a/docs/newtmgr/command_list/newtmgr_datetime.md b/docs/newtmgr/command_list/newtmgr_datetime.md
deleted file mode 100644
index 01f7b2a..0000000
--- a/docs/newtmgr/command_list/newtmgr_datetime.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr datetime </font>
-Manage datetime on a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr datetime [rfc-3339-date-string] -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-Reads or sets the datetime on a device. Specify a `datetime-value` in the command to set the datetime on the device. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-**Note**: You must specify the `datetime-value` in the RFC 3339 format.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newtmgr datetime<br>-c profile01 | Reads the datetime value from a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
- | newtmgr datetime 2017-03-01T22:44:00<br>-c profile01 | Sets the datetime on a device to March 1st 2017 22:44:00 UTC. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
- | newtmgr datetime 2017-03-01T22:44:00-08:00<br>-c profile01| Sets the datetime on a device to March 1st 2017 22:44:00 PST. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
diff --git a/docs/newtmgr/command_list/newtmgr_echo.md b/docs/newtmgr/command_list/newtmgr_echo.md
deleted file mode 100644
index bfadc9b..0000000
--- a/docs/newtmgr/command_list/newtmgr_echo.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr echo </font>
-Send data to a device and display the echoed back data.
-
-#### Usage:
-
-```no-highlight
- newtmgr echo <text> -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-Sends the `text` to a device and outputs the text response from the device. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newtmgr echo hello<br>-c profile01 | Sends the text 'hello' to a device and displays the echoed back data. Newtmgr connects to the device over a connection specified in the `profile01` profile.
diff --git a/docs/newtmgr/command_list/newtmgr_fs.md b/docs/newtmgr/command_list/newtmgr_fs.md
deleted file mode 100644
index 5177c2a..0000000
--- a/docs/newtmgr/command_list/newtmgr_fs.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr fs</font>
-Access files on a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr fs [command] -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-The fs command provides the subcommands to download a file from and upload a file to a device. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-Sub-command | Explanation
--------------| ------------------------
-download | The newtmgr download <src-filename> <dst-filename> command downloads the file named <src-filename> from a device and names it <dst-filename> on your host.
-upload | The newtmgr upload <src-filename> <dst-filename> command uploads the file named <src-filename> to a device and names the file <dst-filename> on the device.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-download | newtmgr fs download /cfg/mfg mfg.txt -c profile01 | Downloads the file name `/cfg/mfg` from a device and names the file `mfg.txt` on your host. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-upload | newtmgr fs upload mymfg.txt /cfg/mfg -c profile01 | Uploads the file name `mymfg.txt` to a device and names the file `cfg/mfg` on the device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
diff --git a/docs/newtmgr/command_list/newtmgr_image.md b/docs/newtmgr/command_list/newtmgr_image.md
deleted file mode 100644
index 8240952..0000000
--- a/docs/newtmgr/command_list/newtmgr_image.md
+++ /dev/null
@@ -1,61 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr image </font>
-Manage images on a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr image [command] -c <connection_profile> [flags]
-```
-
-#### Flags:
-The coredownload subcommand uses the following local flags:
-
-```no-highlight
- -n, --bytes uint32 Number of bytes of the core to download
- -e, --elfify Create an ELF file
- --offset unint32 Offset of the core file to start the download
-
-```
-<br>
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-<br>
-####Description
-The image command provides subcommands to manage core and image files on a device. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-Sub-command | Explanation
--------------| ------------------------
-confirm | The newtmgr image confirm [hex-image-hash] command makes an image setup permanent on a device. If a `hex-image-hash` hash value is specified, Mynewt permanently switches to the image identified by the hash value. If a hash value is not specified, the current image is made permanent.
-coreconvert | The newtmgr image coreconvert <core-filename> <elf-file> command converts the `core-filename` core file to an ELF format and names it `elf-file`. <br><br> **Note**: This command does not download the core file from a device. The core file must exist on your host.
-coredownload | The newtmgr image coredownload <core-filename> command downloads the core file from a device and names the file `core-filename` on your host. Use the local flags under Flags to customize the command.
-coreerase | The newtmgr image coreerase command erases the core file on a device.
-corelist | The newtmgr image corelist command lists the core(s) on a device.
-erase | The newtmgr image erase command erases an unused image from the secondary image slot on a device. The image cannot be erased if the image is a confirmed image, is marked for test on the next reboot, or is an active image for a split image setup. |
-list | The newtmgr image list command displays information for the images on a device.
-test | The newtmgr test <hex-image-hash> command tests the image, identified by the `hex-image-hash` hash value, on next reboot.
-upload | The newtmgr image upload <image-file> command uploads the `image-file` image file to a device.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-confirm | newtmgr confirm<br>-c profile01 | Makes the current image setup on a device permanent. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-confirm | newtmgr confirm<br>be9699809a049...73d77f<br>-c profile01 | Makes the image, identified by the `be9699809a049...73d77f` hash value, setup on a device permanent. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-coreconvert | newtmgr image coreconvert mycore mycore.elf | Converts the `mycore` file to the ELF format and saves it in the `mycore.elf` file.
-coredownload | newtmgr image coredownload <br>mycore -c profile01 | Downloads the core from a device and saves it in the `mycore` file. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-coredownload | newtmgr image coredownload <br>mycore -e <br>-c profile01 | Downloads the core from a device, converts the core file into the ELF format, and saves it in the `mycore` file. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-coredownload | newtmgr image coredownload <br>mycore <br>--offset 10 -n 30<br>-c profile01 | Downloads 30 bytes, starting at offset 10, of the core from a device and saves it in the `mycore` file. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-coreerase | newtmgr image coreerase <br>-c profile01 | Erases the core file on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-corelist | newtmgr image corelist<br>-c profile01 | Lists the core files on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-erase | newtmgr image erase<br>-c profile01 | Erases the image, if unused, from the secondary image slot on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-list | newtmgr image list<br>-c profile01 | Lists the images on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-test | newtmgr image test <br>be9699809a049...73d77f | Tests the image, identified by the `be9699809a049...73d77f` hash value, during the next reboot on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-upload | newtmgr image <br>upload btshell.img<br>-c profile01 | Uploads the `btshell.img` image to a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
diff --git a/docs/newtmgr/command_list/newtmgr_logs.md b/docs/newtmgr/command_list/newtmgr_logs.md
deleted file mode 100644
index ce06f3f..0000000
--- a/docs/newtmgr/command_list/newtmgr_logs.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr log </font>
-Manage logs on a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr log [command] -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-The log command provides subcommands to manage logs on a device. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-Sub-command | Explanation
--------------| ------------------------
-clear | The newtmgr log clear command clears the logs on a device.
-level_list | The newtmgr level_list command shows the log levels on a device.
-list | The newtmgr log list command shows the log names on a device.
-module_list | The newtmgr log module_list command shows the log module names on a device.
-show | The newtmgr log show command displays logs on a device. The command format is: <br>newtmgr log show [log_name [min-index [min-timestamp]]] -c <conn_profile><br><br>The following optional parameters can be used to filter the logs to display: <ul><li>**log_name**: Name of log to display. If log_name is not specified, all logs are displayed.</li><li>**min-index**: Minimum index of the log entries to display. This value is only valid when a log_name is specified. The value can be `last` or a number. If the value is `last`, only the last log entry is displayed. If the value is a number, log entries with an index equal to or higher than min-index are displayed.</li><li>**min-timestamp**: Minimum timestamp of log entries to display. The value is only valid if min-index is specified and is not the value `last`. Only log entries with a timestamp equal to or later than min-timestamp are displayed. Log entries with a timestamp equal to min-timestamp are only displayed if the log entry index is equal to or higher than min-index.</li></ul>
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-clear | newtmgr log clear<br>-c profile01 | Clears the logs on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-level_list | newtmgr log level_list <br>-c profile01 | Shows the log levels on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-list | newtmgr log list<br>-c profile01 | Shows the log names on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-module_list | newtmgr log module_list<br>-c profile01 | Shows the log module names on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-show | newtmgr log show -c profile01 | Displays all logs on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-show | newtmgr log show reboot_log -c profile01 | Displays all log entries for the reboot_log on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-show | newtmgr log show reboot_log last -c profile01 | Displays the last entry from the reboot_log on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-show | newtmgr log show reboot_log 2 -c profile01 | Displays the reboot_log log entries with an index 2 and higher on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-show | newtmgr log show reboot_log 5 123456 -c profile01 | Displays the reboot_log log entries with a timestamp higher than 123456 and log entries with a timestamp equal to 123456 and an index equal to or higher than 5. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
diff --git a/docs/newtmgr/command_list/newtmgr_mpstats.md b/docs/newtmgr/command_list/newtmgr_mpstats.md
deleted file mode 100644
index 6feaa68..0000000
--- a/docs/newtmgr/command_list/newtmgr_mpstats.md
+++ /dev/null
@@ -1,57 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr mpstat </font>
-Read memory pool statistics from a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr mpstat -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-Reads and displays the memory pool statistics from a device. Newtmgr uses the `conn_profile` connection profile to connect to the device. It lists the following statistics for each memory pool:
-
-* **name**: Memory pool name
-* **blksz**: Size (number of bytes) of each memory block
-* **cnt**: Number of blocks allocated for the pool
-* **free**: Number of free blocks
-* **min**: The lowest number of free blocks that were available
-
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newtmgr mpstat -c profile01 | Reads and displays the memory pool statistics from a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-
-Here is an example output for the `myble` application from the [Enabling Newt Manager in any app](/os/tutorials/add_newtmgr.md) tutiorial:
-
-```no-highlight
-$ newtmgr mpstat -c myserial
- name blksz cnt free min
- ble_att_svr_entry_pool 20 75 0 0
- ble_att_svr_prep_entry_pool 12 64 64 64
- ble_gap_update 24 1 1 1
- ble_gattc_proc_pool 56 4 4 4
- ble_gatts_clt_cfg_pool 12 2 1 1
- ble_hci_ram_evt_hi_pool 72 2 2 1
- ble_hci_ram_evt_lo_pool 72 8 8 8
- ble_hs_conn_pool 92 1 1 1
- ble_hs_hci_ev_pool 16 10 10 9
- ble_l2cap_chan_pool 28 3 3 3
- ble_l2cap_sig_proc_pool 20 1 1 1
- btshell_chr_pool 36 64 64 64
- btshell_dsc_pool 28 64 64 64
- btshell_svc_pool 36 32 32 32
- msys_1 292 12 9 6
-```
diff --git a/docs/newtmgr/command_list/newtmgr_reset.md b/docs/newtmgr/command_list/newtmgr_reset.md
deleted file mode 100644
index 74c382c..0000000
--- a/docs/newtmgr/command_list/newtmgr_reset.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr reset </font>
-Send a reset request to a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr reset -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-Resets a device. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newtmgr reset<br>-c profile01 |Resets a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
diff --git a/docs/newtmgr/command_list/newtmgr_run.md b/docs/newtmgr/command_list/newtmgr_run.md
deleted file mode 100644
index 17cb846..0000000
--- a/docs/newtmgr/command_list/newtmgr_run.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr run </font>
-Run test procedures on a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr run [command] -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-The run command provides subcommands to run test procedures on a device. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-Sub-command | Explanation
--------------| ------------------------
-list | The newtmgr run list command lists the registered tests on a device.
-test | The newtmgr run test [all|testname] [token-value] command runs the `testname` test or all tests on a device. All tests are run if `all` or no `testname` is specified. If a `token-value` is specified, the token value is output with the log messages.
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-list | newtmgr run<br>list -c profile01 | Lists all the registered tests on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-test | newtmgr run <br>test all<br>201612161220<br>-c profile01 | Runs all the tests on a device. Outputs the `201612161220` token with the log messages. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-test | newtmgr run <br>test mynewtsanity<br>-c profile01 | Runs the `mynewtsanity` test on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
diff --git a/docs/newtmgr/command_list/newtmgr_stat.md b/docs/newtmgr/command_list/newtmgr_stat.md
deleted file mode 100644
index 41457af..0000000
--- a/docs/newtmgr/command_list/newtmgr_stat.md
+++ /dev/null
@@ -1,91 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr stat</font>
-Read statistics from a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr stat <stats_name> -c <conn_profile> [flags]
- newtmgr stat [command] -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-Displays statistic for the Stats named `stats_name` from a device. You can use the `list` subcommand to get a list of the Stats names from the device. Newtmgr uses the `conn_profile` connection profile to connect to the device.
-
-Sub-command | Explanation
--------------| -----------------------
- | The newtmgr stat <stats_name> command displays the statistics for the `stats_name` Stats from a device.
-list | The newtmgr stat list command displays the list of Stats names from a device.
-
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newtmgr stat ble_att -c profile01 | Displays the `ble_att` statistics on a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-list | newtmgr stat list -c profile01 | Displays the list of Stats names from a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-
-Here are some example outputs for the `myble` application from the [Enabling Newt Manager in any app](/os/tutorials/add_newtmgr.md) tutiorial:
-
-The statistics for the ble_att Stats:
-```no-highlight
-
-$ newtmgr stat ble_att -c myserial
-stat group: ble_att
- 0 error_rsp_rx
- 0 error_rsp_tx
- 0 exec_write_req_rx
- 0 exec_write_req_tx
- 0 exec_write_rsp_rx
- 0 exec_write_rsp_tx
- 0 find_info_req_rx
- 0 find_info_req_tx
- 0 find_info_rsp_rx
- 0 find_info_rsp_tx
- 0 find_type_value_req_rx
- 0 find_type_value_req_tx
- 0 find_type_value_rsp_rx
- 0 find_type_value_rsp_tx
-
- ...
-
- 0 read_rsp_rx
- 0 read_rsp_tx
- 0 read_type_req_rx
- 0 read_type_req_tx
- 0 read_type_rsp_rx
- 0 read_type_rsp_tx
- 0 write_cmd_rx
- 0 write_cmd_tx
- 0 write_req_rx
- 0 write_req_tx
- 0 write_rsp_rx
- 0 write_rsp_tx
-```
-<br>
-The list of Stats names using the list subcommand:
-```no-highlight
-
-$ newtmgr stat list -c myserial
-stat groups:
- ble_att
- ble_gap
- ble_gattc
- ble_gatts
- ble_hs
- ble_l2cap
- ble_ll
- ble_ll_conn
- ble_phy
- stat
-```
diff --git a/docs/newtmgr/command_list/newtmgr_taskstats.md b/docs/newtmgr/command_list/newtmgr_taskstats.md
deleted file mode 100644
index 0206b26..0000000
--- a/docs/newtmgr/command_list/newtmgr_taskstats.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">newtmgr taskstat </font>
-Read task statistics from a device.
-
-#### Usage:
-
-```no-highlight
- newtmgr taskstat -c <conn_profile> [flags]
-```
-
-#### Global Flags:
-
-```no-highlight
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
-
-#### Description
-Reads and displays the task statistics from a device. Newtmgr uses the `conn_profile` connection profile to connect to the device. It lists the following statistics for each task:
-
-* **task**: Task name
-* **pri**: Task priority
-* **runtime**: The time (ms) that the task has been running for
-* **csw**: Number of times the task has switched context
-* **stksz**: Stack size allocated for the task
-* **stkuse**: Actual stack size the task uses
-* **last_checkin**: Last sanity checkin with the [Sanity Task](/os/core_os/sanity/sanity.md)
-* **next_checkin**: Next sanity checkin
-
-
-#### Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
- | newtmgr taskstat<br>-c profile0 | Reads and displays the task statistics from a device. Newtmgr connects to the device over a connection specified in the `profile01` connection profile.
-
-Here is an example output for the `myble` application from the [Enabling Newt Manager in any app](/os/tutorials/add_newtmgr.md) tutiorial:
-
-```no-highlight
-$ newtmgr taskstat -c myserial
- task pri tid runtime csw stksz stkuse last_checkin next_checkin
- ble_ll 0 2 0 12 80 58 0 0
- idle 255 0 16713 95 64 31 0 0
- main 127 1 2 81 512 275 0 0
-```
diff --git a/docs/newtmgr/install_linux.md b/docs/newtmgr/install_linux.md
deleted file mode 100644
index fafd64c..0000000
--- a/docs/newtmgr/install_linux.md
+++ /dev/null
@@ -1,204 +0,0 @@
-## Installing Newtmgr on Linux
-
-You can install the latest release (1.4.0) of the newtmgr tool from a Debian binary package (amd64). You can also download and build the latest release version of newtmgr from source.
-
-This page shows you how to:
-
-1. Set up your computer to download Debian binary packages from the runtimeco APT repository.
-
- **Note:** The key for signing the repository has changed. If you set up your computer before release 1.1.0, you will need to download and import the public key again.
-
-2. Install the latest release version of newtmgr from a Debian binary package. You can use apt-get to install the package or manually download and install the Debian binary package.
-
-3. Download, build, and install the latest release version of newtmgr from source.
-
-See [Installing Previous Releases of Newtgmr](/newtmgr/prev_releases) to install an earlier version of newtmgr.
-
-If you are installing on an amd64 platform, we recommend that you install from the binary package.
-
-**Note:** We have tested the newtmgr tool binary and apt-get install from the runtimeco APT repository for Ubuntu version 1704. Earlier Ubuntu versions (for example: Ubuntu 14) may have incompatibility with the repository. You can manually download and install the Debian binary package.
-
-
-**Note:** See [Setting Up a Go Environment to Contribute to Newt and Newtmgr Tools](/faq/go_env) if you want to:
-
-* Use the newtmgr tool with the latest updates from the master branch. The master branch may be unstable and we recommend that you use the latest stable release version.
-* Contribute to the newtmgr tool.
-
-<br>
-
-### Setting Up Your Computer to use apt-get to Install the Package
-
-The newtmgr Debian packages are stored in a private APT repository on **https://github/runtimeco/debian-mynewt**. To use apt-get, you must set up the following on your computer to retrieve packages from the repository:
-
-**Note**: You only need to perform this setup once on your computer. However, if you previously downloaded and imported the public key for the runtimeco APT repository, you will need to perform step 2 again as the key has changed.
-
-1. Download the public key for the runtimeco APT repository and import the key into the apt keychain.
-2. Add the repository for the binary and source packages to the apt source list.
-
-<br>
-1. Download the public key for the runtimeco apt repo (**Note:** There is a `-` after `apt-key add`):
-
-```no-highlight
-wget -qO - https://raw.githubusercontent.com/runtimeco/debian-mynewt/master/mynewt.gpg.key | sudo apt-key add -
-```
-
-<br>
-2. Add the repository for the binary packages to the `mynewt.list` apt source list file.
-
-```no-highlight
-$ sudo -s
-[sudo] password for <user>:
-# cat > /etc/apt/sources.list.d/mynewt.list <<EOF
-deb https://raw.githubusercontent.com/runtimeco/debian-mynewt/master latest main
-EOF
-# exit
-```
-**Note:** Do not forget to exit the root shell.
-
-<br>
-4. Verify the content of the source list file:
-
-```no-highlight
-$ cat /etc/apt/sources.list.d/mynewt.list
-deb https://raw.githubusercontent.com/runtimeco/debian-mynewt/master latest main
-```
-
-<br>
-5. Update the available packages:
-
-```no-highlight
-$ sudo apt-get update
-```
-
-<br>
-**Note:** If you are not using Ubuntu version 1704, you may see the following errors. We have provided instructions on how to manually download and install the binary package.
-
-```no-highlight
-W: Failed to fetch https://raw.githubusercontent.com/runtimeco/debian-mynewt/master/dists/latest/main/source/Sources HttpError404
-```
-<br>
-### Installing the Latest Release of Newtmgr from a Binary Package
-
-You can use either apt-get to install the package, or manually download and install the Debian binary package.
-
-<br>
-#### Method 1: Using apt-get to Upgrade or to Install
-
-Run the following commands to upgrade or install the latest version of newtmgr:
-
-```no-highlight
-
-$ sudo apt-get update
-$ sudo apt-get install newtmgr
-
-```
-
-#### Method 2: Downloading and Installing the Debian Package Manually
-
-Download and install the package manually.
-
-```no-highlight
-$ wget https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.4.0/newtmgr_1.4.0-1_amd64.deb
-$ sudo dpkg -i newtmgr_1.4.0-1_amd64.deb
-```
-
-See [Checking the Installed Version of Newtmgr](#check) to verify that you are using the installed version of newtmgr.
-
-<br>
-### Installing the Latest Release Version of Newtmgr from Source
-
-If you are running Linux on a different architecture, you can build and install the latest release version of newtmgr from source.
-
-<br>
-1. Download and install the latest version of [Go](https://golang.org/dl/) if it not already available on your distro. Newtmgr requires Go version 1.7.6 or higher.
-
-<br>
-2. Create a Go workspace in the /tmp directory:
-
-```no-highlight
-
-$ cd /tmp
-$ mkdir go
-$ cd go
-$ export GOPATH=/tmp/go
-
-```
-
-<br>
-3. Run `go get` to download the newtmgr source. Note that `go get` pulls down the HEAD from the master branch in git, builds, and installs newtmgr.
-
-```no-highlight
-$ go get mynewt.apache.org/newtmgr/newtmgr
-$ ls -l /tmp/go/bin/newtmgr
--rwxr-xr-x 1 user staff 17884488 Jul 29 16:25 /tmp/go/bin/newtmgr
-```
-
-<br>
-4. Check out the source from the latest release version:
-
-```no-highlight
-$ cd src/mynewt.apache.org/newtmgr
-$ git checkout mynewt_1_4_0_tag
-Note: checking out 'mynewt_1_4_0_tag'.
-```
-
-<br> 5. Build newtmgr from the latest release version:
-
-```no-highlight
-$ cd newtmgr
-$ go install
-$ ls /tmp/go/bin/newtmgr
--rwxr-xr-x 1 user staff 17888680 Jul 29 16:28 /tmp/go/bin/newtmgr
-```
-
-<br>
-6. If you have a Go workspace, remember to reset your GOPATH to your Go workspace.
-
-<br>
-7. Copy the newtmgr executable to a bin directory in your path. You can put it in the /usr/bin or the $GOPATH/bin directory.
-
-<br>
-###<a name="check"></a> Checking the Latest Version of Newtmgr is Installed
-
-<br>
-1. Run `which newtmgr` to verify that you are using the installed version of newtmgr.
-
-<br>
-2. Get information about the newtmgr tool:
-
-```no-highlight
-$ newtmgr
-Newtmgr helps you manage remote devices running the Mynewt OS
-
-Usage:
- newtmgr [flags]
- newtmgr [command]
-
-Available Commands:
- config Read or write a config value on a device
- conn Manage newtmgr connection profiles
- crash Send a crash command to a device
- datetime Manage datetime on a device
- echo Send data to a device and display the echoed back data
- fs Access files on a device
- help Help about any command
- image Manage images on a device
- log Manage logs on a device
- mpstat Read mempool statistics from a device
- reset Perform a soft reset of a device
- run Run test procedures on a device
- stat Read statistics from a device
- taskstat Read task statistics from a device
-
-Flags:
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-
-Use "newtmgr [command] --help" for more information about a command.
-```
-
-<br>
diff --git a/docs/newtmgr/install_mac.md b/docs/newtmgr/install_mac.md
deleted file mode 100644
index e3fae95..0000000
--- a/docs/newtmgr/install_mac.md
+++ /dev/null
@@ -1,126 +0,0 @@
-## Installing Newtmgr on Mac OS
-
-Newtmgr is supported on Mac OS X 64 bit platforms and has been tested on Mac OS Sierra.
-
-This page shows you how to install the following versions of newtmgr:
-
-* Upgrade to or install the latest release version (1.4.0).
-* Install the latest from the master branch (unstable).
-
-See [Installing Previous Releases of Newtmgr](/newtmgr/prev_releases) to install an earlier version of newtmgr.
-
-**Note:** If you would like to contribute to the newtmgr tool, see [Setting Up Go Environment to Contribute to Newt and Newtmgr Tools](/faq/go_env).
-
-### Adding the Mynewt Homebrew Tap
-
-You should have added the **runtimeco/homebrew-mynewt** tap when you installed the **newt** tool. Run the following commands if you have not done so:
-
-```no-highlight
-
-$ brew tap runtimeco/homebrew-mynewt
-$ brew update
-
-```
-
-### Upgrading to or Installing the Latest Release Version
-
-Perform the following to upgrade or install the latest release version of newtmgr.
-
-#### Upgrading to the Latest Release Version of Newtmgr
-
-If you have installed an earlier version of newtmgr using brew, run the following commands to upgrade to the latest version of newtmgr:
-
-```no-highlight
-
-$ brew update
-$ brew upgrade mynewt-newtmgr
-
-```
-
-<br>
-#### Installing the Latest Release Version of Newtmgr
-
-Run the following command to install the latest release version of newtmgr:
-
-```no-highlight
-
-$ brew update
-$ brew install mynewt-newtmgr
-```
-<br>
-**Notes:** Homebrew bottles for newtmgr 1.4.0 are available for Mac OS Sierra. If you are running an earlier version of Mac OS, the installation will install the latest version of Go and compile newtmgr locally.
-
-<br>
-### Checking the Installed Version
-
-Check that you are using the installed version of newtmgr:
-```no-highlight
-$ which newtmgr
-/usr/local/bin/newtmgr
-```
-**Note:** If you previously built newtmgr from source and the output of `which newtmgr` shows "$GOPATH/bin/newtmgr", you will need to move "$GOPATH/bin" after "/usr/local/bin" for your PATH in ~/.bash_profile, and source ~/.bash_profile.
-
-<br>
-Get information about newtmgr:
-
-```no-highlight
-
-$ newtmgr help
-Usage:
- newtmgr [flags]
- newtmgr [command]
-
-Available Commands:
- config Read or write a config value on a device
- conn Manage newtmgr connection profiles
- crash Send a crash command to a device
- datetime Manage datetime on a device
- echo Send data to a device and display the echoed back data
- fs Access files on a device
- help Help about any command
- image Manage images on a device
- log Manage logs on a device
- mpstat Read mempool statistics from a device
- reset Perform a soft reset of a device
- run Run test procedures on a device
- stat Read statistics from a device
- taskstat Read task statistics from a device
-
-Flags:
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-
-Use "newtmgr [command] --help" for more information about a command.
-
-```
-<br>
-
-### Installing Newtmgr from the Master Branch
-
-We recommend that you use the latest release version of newtmgr. If you would like to use the master branch with the latest updates, you can install newtmgr from the HEAD of the master branch.
-
-** Notes: **
-
-* The master branch may be unstable.
-* This installation will install the latest version of Go on your computer, if it is not installed, and compile newtmgr locally.
-
-<br>
-If you already installed newtgmr, unlink the current version:
-```no-highlight
-$ brew unlink mynewt-newtmgr
-```
-<br>
-Install the latest unstable version of newtmgr from the master branch:
-```no-highlight
-$ brew install mynewt-newtmgr --HEAD
-```
-<br>
-To switch back to the latest stable release version of newtmgr, you can run:
-```no-highlight
-$ brew switch mynewt-newtmgr 1.4.0
-```
-<br>
diff --git a/docs/newtmgr/install_windows.md b/docs/newtmgr/install_windows.md
deleted file mode 100644
index 72a67d5..0000000
--- a/docs/newtmgr/install_windows.md
+++ /dev/null
@@ -1,161 +0,0 @@
-## Installing Newtmgr on Windows
-
-This guide shows you how to install the latest release of newtmgr from binary or from source. The tool is written in Go (golang).
-
-It assumes that you have already installed the [newt tool on Windows](/newt/install/newt_windows/) and have the Windows development environment set up.
-
-This guide shows you how to perform the following:
-
-1. Install latest release of newtmgr from binary.
-2. Install latest release of newtmgr from source.
-
-See [Installing Previous Releases of Newtmgr](/newtmgr/prev_releases) to install an earlier version of newtgmr.
-
-**Note:** If you would like to contribute to the newtmgr tool, see [Setting Up Go Environment to Contribute to Newt and Newtmgr Tools](/faq/go_env.md).
-
-### Installing the Latest Release of Newtmgr Tool from Binary
-
-You can install the latest release of newtmgr from binary. It has been tested on Windows 10 64 bit platform.
-
-<br>
-1. Start a MinGW terminal.
-
-<br>
-2. Download the newtmgr binary tar file:
-
-```no-highlight
-
-$ wget -P /tmp https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.3.0/newtmgr_1_3_0_windows_amd64.tar.gz
-
-```
-<br>
-3. Extract the file:
-
-* If you previously built newtmgr from the master branch, you can extract the file into your $GOPATH/bin directory. Note: This overwrites the current newtmgr.exe in the directory and assumes that you are using $GOPATH/bin for your Go applications.
-
- tar -xzf /tmp/newtmgr_1_3_0_windows_amd64.tar.gz -C $GOPATH/bin
-
-* If you are installing newtmgr for the first time and do not have Go setup, you can extract into /usr/bin directory:
-
- tar -xzf /tmp/newtmgr_1_3_0_windows_amd64.tar.gz -C /usr/bin
-
-
-<br>
-4. Verify the installed version of newtmgr. See [Checking the Installed Version](#check_newtmgr).
-<br>
-
-
-<br>
-### Installing the Latest Release of Newtmgr from Source
-
-If you have an older version of Windows or a 32 bit platform, you can build and install the latest release version of newtmgr from source.
-
-<br>
-1. Download and install the latest version of [Go](https://golang.org/dl/). Newtmgr requires Go version 1.7.6 or higher.
-
-<br>
-2. Start MinGW terminal.
-
-<br>
-3. Create a Go workspace in the /tmp directory:
-
-```no-highlight
-
-$ cd /tmp
-$ mkdir go
-$ cd go
-$ export GOPATH=/tmp/go
-
-```
-
-<br>
-4. Run `go get` to download the newtmgr source. Note that `go get` pulls down the HEAD from the master branch in git, builds, and installs newtmgr.
-
-```no-highlight
-
-$ go get mynewt.apache.org/newtmgr/newtmgr
-```
-**Note** If you get the following error, you may ignore it as we will rebuild newtmgr from the latest release version of newtmgr in the next step:
-
-```no-highlight
-
-# github.com/currantlabs/ble/examples/lib/dev
-..\..\..\github.com\currantlabs\ble\examples\lib\dev\dev.go:7: undefined: DefaultDevice
-
-```
-
-<br>
-5. Check out the source from the latest release version:
-
-```no-highlight
-
-$ cd src/mynewt.apache.org/newtmgr
-$ git checkout mynewt_1_3_0_tag
-Note: checking out 'mynewt_1_3_0_tag'.
-
-```
-
-<br>
-6. Build newtmgr from the latest release version:
-
-```no-highlight
-
-$ cd newtmgr
-$ go install
-$ ls /tmp/go/bin/newtmgr.exe
--rwxr-xr-x 1 user None 15457280 Sep 12 00:30 /tmp/go/bin/newtmgr.exe
-
-```
-
-<br>
-7. If you have a Go workspace, remember to reset your GOPATH to your Go workspace.
-
-<br>
-7. Copy the newtmgr executable to a bin directory in your path. You can put it in the /usr/bin or the $GOPATH/bin directory.
-
-
-<br>
-### <a name="check_newtmgr"></a>Checking the Installed Version
-
-<br>
-1. Run `which newtmgr` to verify that you are using the installed version of newtmgr.
-
-<br>
-2. Get information about the newtmgr tool:
-
-```no-highlight
-
-$newtmgr
-Newtmgr helps you manage remote devices running the Mynewt OS
-
-Usage:
- newtmgr [flags]
- newtmgr [command]
-
-Available Commands:
- config Read or write a config value on a device
- conn Manage newtmgr connection profiles
- crash Send a crash command to a device
- datetime Manage datetime on a device
- echo Send data to a device and display the echoed back data
- fs Access files on a device
- help Help about any command
- image Manage images on a device
- log Manage logs on a device
- mpstat Read mempool statistics from a device
- reset Perform a soft reset of a device
- run Run test procedures on a device
- stat Read statistics from a device
- taskstat Read task statistics from a device
-
-Flags:
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-
-Use "newtmgr [command] --help" for more information about a command.
-
-```
diff --git a/docs/newtmgr/overview.md b/docs/newtmgr/overview.md
deleted file mode 100644
index d75ce4e..0000000
--- a/docs/newtmgr/overview.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## Newt Manager
-
-Newt Manager (newtmgr) is the application tool that enables a user to communicate with and manage remote devices running the Mynewt OS. It uses a connection profile to establish a connection with a device and sends command requests to the device. The tool follows the same command structure as the [newt tool](../newt/newt_ops.md).
-
-
-### Available high-level commands
-The following are the high-level newtmgr commands. Some of these commands have subcommands. You can use the -h flag to get help for each command. See the documentation for each command in this guide if you need more information and examples.
-
-```no-highlight
-Available Commands:
- config Read or write a config value on a device
- conn Manage newtmgr connection profiles
- crash Send a crash command to a device
- datetime Manage datetime on a device
- echo Send data to a device and display the echoed back data
- fs Access files on a device
- help Help about any command
- image Manage images on a device
- log Manage logs on a device
- mpstat Read mempool statistics from a device
- reset Perform a soft reset of a device
- run Run test procedures on a device
- stat Read statistics from a device
- taskstat Read task statistics from a device
-
-Flags:
- -c, --conn string connection profile to use
- -h, --help help for newtmgr
- -l, --loglevel string log level to use (default "info")
- --name string name of target BLE device; overrides profile setting
- -t, --timeout float timeout in seconds (partial seconds allowed) (default 10)
- -r, --tries int total number of tries in case of timeout (default 1)
-```
diff --git a/docs/newtmgr/prev_releases.md b/docs/newtmgr/prev_releases.md
deleted file mode 100644
index dd82d95..0000000
--- a/docs/newtmgr/prev_releases.md
+++ /dev/null
@@ -1,81 +0,0 @@
-## Installing Previous Releases of Newtmgr
-
-This page shows you how to install previous releases of newtmgr for Mac OS, Linux, and Windows.
-
-
-### Mac OS
-You can install previous releases of newtmgr using `mynewt-newtmgr@X.Y` Homebrew formulas, where X.Y is a version number.
-
-For example, if you want to install newtmgr 1.0, run the following commands:
-
-```no-highlight
-
-$ brew update
-$ brew install mynewt-newtmgr@1.0
-
-```
-
-**Note:** This is a keg-only installation. newtgmr 1.0 is installed in /usr/local/Cellar/mynewt-newtmgr@1.0/1.0.0/bin but not symlinked into /usr/local/bin.
-
-If you need this version of newtmgr first in your PATH, run the following commands:
-
-```no-highlight
-
-$ echo 'export PATH=/usr/local/Cellar/mynewt-newtmgr@1.0/1.0.0/bin:$PATH' >> ~/.bash_profile
-$ source ~/.bash_profile
-
-```
-
-<br>
-You can also manually symlink into /usr/local/bin as follows:
-
-<br>
-1. Unlink newtmgr if you have the latest version of newtmgr installed:
-
-```no-highlight
-$ brew unlink mynewt-newtmgr
-```
-<br>
-2. Link mynewt-newt@1.0 into /usr/local/bin:
-
-```no-highlight
-$ brew link -f mynewt-newtmgr@1.0
-```
-
-<br>
-### Linux
-<br>
-1. Download the binary:
-
-Version|Download
--------|--------
-1.0.0 |[newtmgr_1.0.0-1_amd64.deb](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.0.0/newtmgr_1.0.0-1_amd64.deb)
-1.1.0 |[newtmgr_1.1.0-1_amd64.deb](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.1.0/newtmgr_1.1.0-1_amd64.deb)
-1.2.0 |[newtmgr_1.2.0-1_amd64.deb](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.2.0/newtmgr_1.2.0-1_amd64.deb)
-1.3.0 |[newtmgr_1.3.0-1_amd64.deb](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.3.0/newtmgr_1.3.0-1_amd64.deb)
-
-<br>
-2. Run the `sudo apt-get remove newtmgr` command to remove the the current installation.
-
-<br>
-3. Install the package. For example, run `sudo dpkg -i newtmgr_1.0.0-1_amd64.deb` to install newtmgr 1.0.0
-
-<br>
-### Windows
-<br>
-1. Download the binary:
-
-Version|Download
--------|--------
-1.1.0 |[newtmgr_1_1_0_windows_amd64.tar.gz](https://raw.githubusercontent.com/runtimeco/binary-releases/master/mynewt-newt-tools_1.1.0/newtmgr_1_1_0_windows_amd64.tar.gz)
-
-<br>
-2. Extract the file:
-
-* If you previously built newtmgr from the master branch, you can extract the file into your $GOPATH/bin directory. Note: This overwrites the current newtmgr.exe in the directory and assumes that you are using $GOPATH/bin for your Go applications.
-
- tar -xzf newtmgr_1_1_0_windows_amd64.tar.gz -C $GOPATH/bin
-
-* If you are installing newtmgr for the first time and do not have a Go workspace setup, you can extract into /usr/bin directory:
-
- tar -xzf newtmgr_1_1_0_windows_amd64.tar.gz -C /usr/bin
diff --git a/docs/newtmgr/protocol.md b/docs/newtmgr/protocol.md
deleted file mode 100644
index f385320..0000000
--- a/docs/newtmgr/protocol.md
+++ /dev/null
@@ -1,9 +0,0 @@
-## Newt Manager Protocol
-
-<synopsis>
-
-
-## Description
-
-
-## How it works
\ No newline at end of file
diff --git a/docs/os/core_os/callout/callout.md b/docs/os/core_os/callout/callout.md
deleted file mode 100644
index 042dd7b..0000000
--- a/docs/os/core_os/callout/callout.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# Callout
-
-Callouts are MyNewt OS timers.
-
-### Description
-
-Callout is a way of setting up an OS timer. When the timer fires, it is delivered as an event to task's event queue.
-
-User would initialize their callout structure using *os_callout_init()*, or *os_callout_func_init()* and then arm it with *os_callout_reset()*.
-
-If user wants to cancel the timer before it expires, they can either use *os_callout_reset()* to arm it for later expiry, or stop it altogether by calling *os_callout_stop()*.
-
-There are 2 different options for data structure to use. First is *struct os_callout*, which is a bare-bones version. You would initialize this with *os_callout_init()*.
-
-Second option is *struct os_callout_func*. This you can use if you expect to have multiple different types of timers in your task, running concurrently. The structure contains a function pointer, and you would call that function from your task's event processing loop.
-
-Time unit when arming the timer is OS ticks. This rate of this ticker depends on the platform this is running on. You should use OS define *OS_TICKS_PER_SEC* to convert wallclock time to OS ticks.
-
-Callout timer fires out just once. For periodic timer type of operation you need to rearm it once it fires.
-
-### Data structures
-
- struct os_callout {
- struct os_event c_ev;
- struct os_eventq *c_evq;
- uint32_t c_ticks;
- TAILQ_ENTRY(os_callout) c_next;
- };
-
-
-| Element | Description |
-|---------|-------------|
-| c_ev | Event structure of this callout |
-| c_evq | Event queue where this callout is placed on timer expiry |
-| c_ticks | OS tick amount when timer fires |
-| c_next | Linkage to other unexpired callouts |
-
-
- struct os_callout_func {
- struct os_callout cf_c;
- os_callout_func_t cf_func;
- void *cf_arg;
- };
-
-
-| Element | Description |
-|---------|-------------|
-| cf_c | struct os_callout. See above |
-| cf_func | Function pointer which should be called by event queue processing |
-| cf_arg | Generic void * argument to that function |
-
-### List of Functions
-
-The functions available in callout are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_callout_func_init](os_callout_func_init) | Initializes the given callout function struct. |
-| [os_callout_init](os_callout_init) | Initializes the given callout struct. |
-| [os_callout_queued](os_callout_queued) | Checks whether the given callout has been armed. |
-| [os_callout_reset](os_callout_reset) | Resets the callout to happen in the given number of OS ticks. |
-| [os_callout_stop](os_callout_stop) | Disarms a timer. |
-
diff --git a/docs/os/core_os/callout/os_callout_func_init.md b/docs/os/core_os/callout/os_callout_func_init.md
deleted file mode 100644
index 2c45817..0000000
--- a/docs/os/core_os/callout/os_callout_func_init.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_callout_func_init </font>
-
-
- void os_callout_func_init(struct os_callout_func *cf, struct os_eventq *evq, os_callout_func_t timo_func, void *ev_arg)
-
-
-Initializes the given *struct os_callout_func*. Data structure is filled in with elements given as argument.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| cf | Pointer to os_callout_func being initialized |
-| evq | Event queue where this gets delivered to |
-| timo_func | Timeout function. Event processing should call this |
-| ev_arg | Generic argument for the event |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-The same notes as with *os_callout_init()*.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-
- struct os_callout_func g_native_cputimer;
- struct os_eventq g_native_cputime_evq;
- void native_cputimer_cb(void *arg);
-
- /* Initialize the callout function */
- os_callout_func_init(&g_native_cputimer,
- &g_native_cputime_evq,
- native_cputimer_cb,
- NULL);
-
-
-
-
diff --git a/docs/os/core_os/callout/os_callout_init.md b/docs/os/core_os/callout/os_callout_init.md
deleted file mode 100644
index 7d30fdc..0000000
--- a/docs/os/core_os/callout/os_callout_init.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_callout_init </font>
-
-
- void os_callout_init(struct os_callout *c, struct os_eventq *evq, void *ev_arg)
-
-
-Initializes *struct os_callout*. Event type will be set to *OS_EVENT_T_TIMER*.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| c | Pointer to os_callout to initialize |
-| evq | Event queue where this gets delivered to |
-| ev_arg | Generic argument which is filled in for the event |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-Be careful not to call this if the callout is armed, because that will mess up the list of pending callouts.
-Or if the timer has already fired, it will mess up the event queue where the callout was delivered to.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-
- struct os_eventq my_evq;
- struct os_callout my_callouts[8];
-
- for (i = 0; i < 8; i++) {
- os_callout_init(&my_callouts[i], &my_evq, (void *)i);
- }
-
diff --git a/docs/os/core_os/callout/os_callout_queued.md b/docs/os/core_os/callout/os_callout_queued.md
deleted file mode 100644
index 9e69f96..0000000
--- a/docs/os/core_os/callout/os_callout_queued.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_callout_queued</font>
-
-
- int os_callout_queued(struct os_callout *c)
-
-
-Tells whether the callout has been armed or not.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| c | Pointer to callout being checked |
-
-#### Returned values
-
-0: timer is not armed
-non-zero: timer is armed
-
-
-
diff --git a/docs/os/core_os/callout/os_callout_reset.md b/docs/os/core_os/callout/os_callout_reset.md
deleted file mode 100644
index 5c6875b..0000000
--- a/docs/os/core_os/callout/os_callout_reset.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_callout_reset </font>
-
-
- void os_callout_reset(struct os_callout *c, int32_t timo)
-
-
-Resets the callout to happen *timo* in OS ticks.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| c | Pointer to os_callout being reset |
-| timo | OS ticks the timer is being set to |
-
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-
- /* Re-start the timer (run every 50 msecs) */
- os_callout_reset(&g_bletest_timer.cf_c, OS_TICKS_PER_SEC / 20);
-
diff --git a/docs/os/core_os/callout/os_callout_stop.md b/docs/os/core_os/callout/os_callout_stop.md
deleted file mode 100644
index 76aa87d..0000000
--- a/docs/os/core_os/callout/os_callout_stop.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_callout_stop </font>
-
-
- void os_callout_stop(struct os_callout *c)
-
-
-Disarms a timer.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| c | Pointer to os_callout being stopped |
-
-
-#### Returned values
-
-N/A
-
-
-#### Example
-
-
-
- struct os_callout_func g_native_cputimer;
-
- os_callout_stop(&g_native_cputimer.cf_c);
-
-
-
diff --git a/docs/os/core_os/context_switch/context_switch.md b/docs/os/core_os/context_switch/context_switch.md
deleted file mode 100644
index ca6da87..0000000
--- a/docs/os/core_os/context_switch/context_switch.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# Scheduler/Context Switching
-
-
-Scheduler's job is to maintain the list of tasks and decide which one should be running next.
-
-## Description
-
-Task states can be *running*, *ready to run* or *sleeping*.
-
-When task is *running*, CPU is executing in that task's context. The program counter (PC) is pointing to instructions task wants to execute and stack pointer (SP) is pointing to task's stack.
-
-Task which is *ready to run* wants to get on the CPU to do its work.
-
-Task which is *sleeping* has no more work to do. It's waiting for someone else to wake it up.
-
-Scheduler algorithm is simple: from among the tasks which are ready to run, pick the the one with highest priority (lowest numeric value in task's t_prio field), and make its state *running*.
-
-Tasks which are either *running* or *ready to run* are kept in linked list `g_os_run_list`. This list is ordered by priority.
-
-Tasks which are *sleeping* are kept in linked list `g_os_sleep_list`.
-
-Scheduler has a CPU architecture specific component; this code is responsible for swapping in the task which should be *running*. This process is called context switch. During context switching the state of the CPU (e.g. registers) for the currently *running* task is stored and the new task is swapped in.
-
-
-## List of Functions
-
-
-The functions available in context_switch are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_sched](os_sched.md) | Performs context switch if needed. |
-| [os_arch_ctx_sw](os_arch_ctx_sw.md) | Change the state of task given task to *running*. |
-| [os_sched_ctx_sw_hook](os_sched_ctx_sw_hook.md) | Performs task accounting when context switching. |
-| [os_sched_get_current_task](os_sched_get_current_task.md) | Returns the pointer to task which is currently *running*. |
-| [os_sched_insert](os_sched_insert.md) | Insert task into scheduler's ready to run list. |
-| [os_sched_next_task](os_sched_next_task.md) | Returns the pointer to highest priority task from the list which are *ready to run*. |
-| [os_sched_os_timer_exp](os_sched_os_timer_exp.md) | Inform scheduler that OS time has moved forward. |
-| [os_sched_remove](os_sched_remove.md) | Stops a task and removes it from all the OS task lists. |
-| [os_sched_resort](os_sched_resort.md) | Inform scheduler that the priority of the given task has changed and the *ready to run* list should be re-sorted. |
-| [os_sched_set_current_task](os_sched_set_current_task.md) | Sets the given task to *running*. |
-| [os_sched_sleep](os_sched_sleep.md) | The given task's state is changed from *ready to run* to *sleeping*. |
-| [os_sched_wakeup](os_sched_wakeup.md) | Called to make task *ready to run*. If task is *sleeping*, it is woken up. |
diff --git a/docs/os/core_os/context_switch/os_arch_ctx_sw.md b/docs/os/core_os/context_switch/os_arch_ctx_sw.md
deleted file mode 100644
index 7b3c1bc..0000000
--- a/docs/os/core_os/context_switch/os_arch_ctx_sw.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_arch_ctx_sw </font>
-
-void os_arch_ctx_sw(struct os_task *next_t)
-
-
-Change the state of task pointed by *next_t* to be *running*.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| next_t | Pointer to task which must run next |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-This would get called from another task's context.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
-void
- os_sched(struct os_task *next_t)
- {
- os_sr_t sr;
-
- OS_ENTER_CRITICAL(sr);
-
- if (!next_t) {
- next_t = os_sched_next_task();
- }
-
- if (next_t != g_current_task) {
- os_arch_ctx_sw(next_t);
- }
-
- OS_EXIT_CRITICAL(sr);
- }
-```
-
-
diff --git a/docs/os/core_os/context_switch/os_sched.md b/docs/os/core_os/context_switch/os_sched.md
deleted file mode 100644
index 2eb34cf..0000000
--- a/docs/os/core_os/context_switch/os_sched.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched </font>
-
-```c
-void os_sched(struct os_task *next_t)
-```
-
-Performs context switch if needed. If *next_t* is set, that task will be made *running*. If *next_t* is NULL, highest priority *ready to run* is swapped in. This function can be called when new tasks were made *ready to run* or if the current task is moved to *sleeping* state.
-
-This function will call the architecture specific routine to swap in the new task.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| next_t | Pointer to task which must run next (optional) |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-Interrupts must be disabled when calling this.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
-os_error_t
-os_mutex_release(struct os_mutex *mu)
-{
- ...
- OS_EXIT_CRITICAL(sr);
-
- /* Re-schedule if needed */
- if (resched) {
- os_sched(rdy);
- }
-
- return OS_OK;
-
-}
-```
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md b/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md
deleted file mode 100644
index 3042478..0000000
--- a/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_ctx_sw_hook </font>
-
-```c
-void os_sched_ctx_sw_hook(struct os_task *next_t)
-```
-
-Performs task accounting when context switching.
-
-This function must be called from the architecture specific context switching routine *os_arch_ctx_sw()* before resuming execution of the *running* task.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
-void
-os_arch_ctx_sw(struct os_task *t)
-{
- os_sched_ctx_sw_hook(t);
-
- /* Set PendSV interrupt pending bit to force context switch */
- SCB->ICSR = SCB_ICSR_PENDSVSET_Msk;
-}
-```
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_get_current_task.md b/docs/os/core_os/context_switch/os_sched_get_current_task.md
deleted file mode 100644
index 3a7a961..0000000
--- a/docs/os/core_os/context_switch/os_sched_get_current_task.md
+++ /dev/null
@@ -1,39 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_get_current_task </font>
-
-```c
-struct os_task *os_sched_get_current_task(void)
-```
-
-Returns the pointer to task which is currently *running*.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-See description.
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
-void
-os_time_delay(int32_t osticks)
-{
- os_sr_t sr;
-
- if (osticks > 0) {
- OS_ENTER_CRITICAL(sr);
- os_sched_sleep(os_sched_get_current_task(), (os_time_t)osticks);
- OS_EXIT_CRITICAL(sr);
- os_sched(NULL);
- }
-}
-```
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_insert.md b/docs/os/core_os/context_switch/os_sched_insert.md
deleted file mode 100644
index dce6755..0000000
--- a/docs/os/core_os/context_switch/os_sched_insert.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_insert </font>
-
-```c
-os_error_t
-os_sched_insert(struct os_task *t)
-```
-
-Insert task into scheduler's *ready to run* list.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| t | Pointer to task |
-
-#### Returned values
-
-Returns OS_EINVAL if task state is not *READY*.
-Returns 0 on success.
-
-#### Notes
-
-You probably don't need to call this.
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_next_task.md b/docs/os/core_os/context_switch/os_sched_next_task.md
deleted file mode 100644
index d199ff3..0000000
--- a/docs/os/core_os/context_switch/os_sched_next_task.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_next_task </font>
-
-```c
-struct os_task *os_sched_next_task(void)
-```
-
-Returns the pointer to highest priority task from the list which are *ready to run*.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-See description.
-
-#### Notes
-
-Should be called with interrupts disabled.
-
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_os_timer_exp.md b/docs/os/core_os/context_switch/os_sched_os_timer_exp.md
deleted file mode 100644
index f5a03fc..0000000
--- a/docs/os/core_os/context_switch/os_sched_os_timer_exp.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_os_timer_exp </font>
-
-```c
-void os_sched_os_timer_exp(void)
-```
-
-Inform scheduler that OS time has moved forward, and it should inspect tasks which are *sleeping* to check whether they should be moved to *g_run_list* or not.
-
-This function should be called from code which handles moving OS time forward. After calling it, the highest priority task which is *ready to run* might've changed, so call to *os_sched()* should be done.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-```c
-void
-timer_handler(void)
-{
- os_time_tick();
- os_callout_tick();
- os_sched_os_timer_exp();
- os_sched(NULL);
-}
-```
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_remove.md b/docs/os/core_os/context_switch/os_sched_remove.md
deleted file mode 100644
index f0a5048..0000000
--- a/docs/os/core_os/context_switch/os_sched_remove.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_remove </font>
-
-```c
-int os_sched_remove(struct os_task *t)
-```
-Stops and removes task `t`.
-
-The function removes the task from the `g_os_task_list` task list. It also removes the task from one of the following task list:
-
-* `g_os_run_list` if the task is in the Ready state.
-* `g_os_sleep_list` if the task is in the Sleep state.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `t` | Pointer to the `os_task` structure for the task to be removed.|
-
-#### Returned values
-OS_OK - The task is removed successfully.
-
-#### Notes
-This function must be called with all interrupts disabled.
-
-#### Example
-
-The `os_task_remove` function calls the `os_sched_remove ` function to remove a task:
-```c
-
-int
-os_task_remove(struct os_task *t)
-{
- int rc;
- os_sr_t sr;
-
- /* Add error checking code to ensure task can removed. */
-
-
- /* Call os_sched_remove to remove the task. */
- OS_ENTER_CRITICAL(sr);
- rc = os_sched_remove(t);
- OS_EXIT_CRITICAL(sr);
- return rc;
-}
-```
diff --git a/docs/os/core_os/context_switch/os_sched_resort.md b/docs/os/core_os/context_switch/os_sched_resort.md
deleted file mode 100644
index c755fb3..0000000
--- a/docs/os/core_os/context_switch/os_sched_resort.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_resort </font>
-
-```c
-void os_sched_resort(struct os_task *t)
-```
-
-Inform scheduler that the priority of the task *t* has changed (e.g. in order to avoid priority inversion), and the *ready to run* list should be re-sorted.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| t | Pointer to a task whose priority has changed |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-*t* must be *ready to run* before calling this.
-
-#### Example
-
-<Add text to set up the context for the example here>
-```c
-os_error_t
-os_mutex_pend(struct os_mutex *mu, uint32_t timeout)
-{
- ....
- /* Change priority of owner if needed */
- if (mu->mu_owner->t_prio > current->t_prio) {
- mu->mu_owner->t_prio = current->t_prio;
- os_sched_resort(mu->mu_owner);
- }
- ....
-}
-```
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_set_current_task.md b/docs/os/core_os/context_switch/os_sched_set_current_task.md
deleted file mode 100644
index 8839980..0000000
--- a/docs/os/core_os/context_switch/os_sched_set_current_task.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_set_current_task </font>
-
-```c
-void
-os_sched_set_current_task(struct os_task *t)
-```
-
-Sets the currently running task to 't'.
-
-This is called from architecture specific context switching code to update scheduler state. Call is made when state of the task 't' is made *running*.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| t | Pointer to a task |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
- This function simply sets the global variable holding the currently running task. It does not perform a context switch or change the os run or sleep list.
-
-
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_sleep.md b/docs/os/core_os/context_switch/os_sched_sleep.md
deleted file mode 100644
index 3c46887..0000000
--- a/docs/os/core_os/context_switch/os_sched_sleep.md
+++ /dev/null
@@ -1,63 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_sleep </font>
-
-```c
-int
-os_sched_sleep(struct os_task *t, os_time_t nticks)
-```
-
-Task 't' state is changed from *ready to run* to *sleeping*. Sleep time will be specified in *nticks*.
-
-Task will be woken up after sleep timer expires, unless there are other signals causing it to wake up.
-
-If *nticks* is set to *OS_TIMEOUT_NEVER*, task never wakes up with a sleep timer.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| t | Pointer to task |
-| nticks | Number of ticks to sleep in OS ticks |
-
-#### Returned values
-
-Returns 0 on success.
-
-#### Notes
-
-Must be called with interrupts disabled.
-
-#### Example
-
-<Add text to set up the context for the example here>
-```c
-struct os_event *
-os_eventq_get(struct os_eventq *evq)
-{
- struct os_event *ev;
- os_sr_t sr;
-
- OS_ENTER_CRITICAL(sr);
-pull_one:
- ev = STAILQ_FIRST(&evq->evq_list);
- if (ev) {
- STAILQ_REMOVE(&evq->evq_list, ev, os_event, ev_next);
- ev->ev_queued = 0;
- } else {
- evq->evq_task = os_sched_get_current_task();
- os_sched_sleep(evq->evq_task, OS_TIMEOUT_NEVER);
- OS_EXIT_CRITICAL(sr);
-
- os_sched(NULL);
-
- OS_ENTER_CRITICAL(sr);
- evq->evq_task = NULL;
- goto pull_one;
- }
- OS_EXIT_CRITICAL(sr);
-
- return (ev);
-}
-```
-
-
-
diff --git a/docs/os/core_os/context_switch/os_sched_wakeup.md b/docs/os/core_os/context_switch/os_sched_wakeup.md
deleted file mode 100644
index 4407c96..0000000
--- a/docs/os/core_os/context_switch/os_sched_wakeup.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched_wakeup </font>
-
-```c
-int
-os_sched_wakeup(struct os_task *t)
-```
-
-Called to make task *ready to run*. If task is *sleeping*, it is woken up.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| t | Pointer to task |
-
-#### Returned values
-
-Returns 0 on success.
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-```c
-void
-os_eventq_put(struct os_eventq *evq, struct os_event *ev)
-{
- ....
- /* If task waiting on event, wake it up. */
- resched = 0;
- if (evq->evq_task) {
- os_sched_wakeup(evq->evq_task);
- evq->evq_task = NULL;
- resched = 1;
- }
- ....
-}
-```
-
-
diff --git a/docs/os/core_os/cputime/os_cputime.md b/docs/os/core_os/cputime/os_cputime.md
deleted file mode 100644
index f724473..0000000
--- a/docs/os/core_os/cputime/os_cputime.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# CPU Time
-
-The MyNewt `cputime` module provides high resolution time and timer support.
-
-## Description
-
-The `cputime` API provides high resolution time and timer support. The module must be initialized, using the `os_cputime_init()` function, with the clock frequency to use. The module uses the `hal_timer` API, defined in hal/hal_timer.h, to access the hardware timers. It uses the hardware timer number specified by the `OS_CPUTIME_TIMER_NUM` system configuration setting.
-
-## Data Structures
-
-The module uses the following data structures:
-
-* `uint32_t` to represent `cputime`. Only the lower 32 bits of a 64 timer are used.
-* `struct hal_timer` to represent a cputime timer.
-
-## List of Functions
-
-The functions available in cputime are:
-
-| **Function** | **Description** |
-|-----------|-----------|
-| [os_cputime_delay_nsecs](os_cputime_delay_nsecs.md) | Delays for a specified number of nanoseconds. |
-| [os_cputime_delay_ticks](os_cputime_delay_ticks.md) | Delays for a specified number of ticks. |
-| [os_cputime_delay_usecs](os_cputime_delay_usecs.md) | Delays for a specified number of microseconds. |
-| [os_cputime_get32](os_cputime_get32.md) | Gets the current value of the cpu time.|
-| [os_cputime_init](os_cputime_init.md) | Initializes the cputime module. |
-| [os_cputime_nsecs_to_ticks](os_cputime_nsecs_to_ticks.md) | Converts the specified number of nanoseconds to number of ticks. |
-| [os_cputime_ticks_to_nsecs](os_cputime_ticks_to_nsecs.md) | Converts the specified number of ticks to number of nanoseconds. |
-| [os_cputime_ticks_to_usecs](os_cputime_ticks_to_usecs.md) | Converts the specified number of ticks to number of microseconds. |
-| [os_cputime_timer_init](os_cputime_timer_init.md) | Initializes a timer. |
-| [os_cputime_timer_relative](os_cputime_timer_relative.md) | Sets a timer to expire in the specified number of microseconds from the current time. |
-| [os_cputime_timer_start](os_cputime_timer_start.md) | Sets a timer to expire at the specified cputime. |
-| [os_cputime_timer_stop](os_cputime_timer_stop.md) | Stops a timer from running. |
-| [os_cputime_usecs_to_ticks](os_cputime_usecs_to_ticks.md) | Converts the specified number of microseconds to number of ticks. |
-
-## List of Macros
-
-These macros should be used to evaluate the time with respect to each other.
-
-* `CPUIME_LT(t1,t2)` -- evaluates to true if t1 is before t2 in time.
-* `CPUTIME_GT(t1,t2)` -- evaluates to true if t1 is after t2 in time
-* `CPUTIME_LEQ(t1,t2)` -- evaluates to true if t1 is on or before t2 in time.
-* `CPUTIME_GEQ(t1,t2)` -- evaluates to true if t1 is on or after t2 in time.
diff --git a/docs/os/core_os/cputime/os_cputime_delay_nsecs.md b/docs/os/core_os/cputime/os_cputime_delay_nsecs.md
deleted file mode 100644
index c4e0e71..0000000
--- a/docs/os/core_os/cputime/os_cputime_delay_nsecs.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_delay_nsecs</font>
-
-```c
-void os_cputime_delay_nsecs(uint32_t nsecs)
-```
-Waits for a specified number of nanoseconds to elapse before returning.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `nsecs` | Number of nanoseconds to delay for.
-
-
-#### Returned values
-N/A
-
-#### Notes
-
-#### Example
-Delays for 250000 nsecs:
-```c
-os_cputime_delay_nsecs(250000)
-```
diff --git a/docs/os/core_os/cputime/os_cputime_delay_ticks.md b/docs/os/core_os/cputime/os_cputime_delay_ticks.md
deleted file mode 100644
index a744141..0000000
--- a/docs/os/core_os/cputime/os_cputime_delay_ticks.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_delay_ticks</font>
-
-```c
-void os_cputime_delay_ticks(uint32_t ticks)
-```
-Waits for a specified number of ticks to elapse before returning.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `ticks` | Number of ticks to delay for.
-
-
-#### Returned values
-N/A
-
-#### Notes
-
-#### Example
-Delays for 100000 ticks:
-```c
-os_cputime_delay_ticks(100000)
-```
diff --git a/docs/os/core_os/cputime/os_cputime_delay_usecs.md b/docs/os/core_os/cputime/os_cputime_delay_usecs.md
deleted file mode 100644
index 86c1b43..0000000
--- a/docs/os/core_os/cputime/os_cputime_delay_usecs.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_delay_usecs</font>
-
-```c
-void os_cputime_delay_usecs(uint32_t usecs)
-```
-Waits for a specified number of microseconds to elapse before returning.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `usecs` | Number of microseconds to delay for.
-
-
-#### Returned values
-N/A
-
-#### Notes
-
-#### Example
-Delays for 250000 usecs:
-```c
-os_cputime_delay_usecs(250000)
-```
diff --git a/docs/os/core_os/cputime/os_cputime_get32.md b/docs/os/core_os/cputime/os_cputime_get32.md
deleted file mode 100644
index b2ee2c8..0000000
--- a/docs/os/core_os/cputime/os_cputime_get32.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_get32</font>
-
-```c
-uint32_t os_cputime_get32(void)
-```
-Gets the current cputime. If a timer is 64 bits, only the lower 32 bit is returned.
-
-#### Arguments
-N/A
-
-#### Returned values
-
-The current cputime.
-
-#### Notes
-
-#### Example
-
-```c
-uint32 cur_cputime;
-cur_cputime = os_cputime_get32();
-```
-
diff --git a/docs/os/core_os/cputime/os_cputime_init.md b/docs/os/core_os/cputime/os_cputime_init.md
deleted file mode 100644
index 2e119c8..0000000
--- a/docs/os/core_os/cputime/os_cputime_init.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_init</font>
-
-```c
-int os_cputime_init(uint32_t clock_freq)
-```
-Initializes the cputime module with the clock frequency (in HZ) to use for the timer resolution. It configures the hardware timer specified by the `OS_CPUTIME_TIMER_NUM` sysconfig value to run at the specified clock frequency.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `clock_freq` | Clock frequency, in HZ, for the timer resolution.
-
-
-#### Returned values
-
-0 on success and -1 on error.
-
-#### Notes
-This function must be called after os_init is called. It should only be called once and before any other timer API and hardware timers are used.
-
-#### Example
-A BSP package usually calls this function and uses the `OS_CPUTIME_FREQUENCY` sysconfig value for the clock frequency argument:
-```c
-int rc
-rc = os_cputime_init(MYNEWT_VAL(OS_CPUTIME_FREQUENCY));
-```
-
diff --git a/docs/os/core_os/cputime/os_cputime_nsecs_to_ticks.md b/docs/os/core_os/cputime/os_cputime_nsecs_to_ticks.md
deleted file mode 100644
index 1666d58..0000000
--- a/docs/os/core_os/cputime/os_cputime_nsecs_to_ticks.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_nsecs_to_ticks</font>
-
-```c
-uint32_t os_cputime_nsecs_to_ticks(uint32_t nsecs)
-```
-Converts a specified number of nanoseconds to cputime ticks.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `nsecs` | Number of nanoseconds to convert to ticks.
-
-
-#### Returned values
-The number of ticks in `nsecs` nanoseconds.
-
-#### Notes
-
-#### Example
-```c
-uint32_t num_ticks;
-num_ticks = os_cputime_nsecs_to_ticks(1000000);
-```
diff --git a/docs/os/core_os/cputime/os_cputime_ticks_to_nsecs.md b/docs/os/core_os/cputime/os_cputime_ticks_to_nsecs.md
deleted file mode 100644
index dc6afa0..0000000
--- a/docs/os/core_os/cputime/os_cputime_ticks_to_nsecs.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_ticks_to_nsecs</font>
-
-```c
-uint32_t os_cputime_ticks_to_nsecs(uint32_t ticks)
-```
-Converts cputime ticks to nanoseconds.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `ticks` | Number of cputime ticks to convert to nanoseconds.
-
-
-#### Returned values
-The number of nanoseconds in `ticks` number of ticks.
-
-#### Notes
-
-#### Example
-```c
-uint32_t num_nsecs;
-num_nsecs = os_cputime_ticks_to_nsecs(1000000);
-```
diff --git a/docs/os/core_os/cputime/os_cputime_ticks_to_usecs.md b/docs/os/core_os/cputime/os_cputime_ticks_to_usecs.md
deleted file mode 100644
index 6fcc496..0000000
--- a/docs/os/core_os/cputime/os_cputime_ticks_to_usecs.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_ticks_to_usecs</font>
-
-```c
-uint32_t os_cputime_ticks_to_usecs(uint32_t ticks)
-```
-Converts a specified number of cputime ticks to microseconds.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `ticks` | Number of cputime ticks to convert to microseconds.
-
-
-#### Returned values
-The number of microseconds in `ticks` number of ticks.
-
-#### Notes
-
-#### Example
-```c
-uint32_t num_usecs;
-num_usecs = os_cputime_ticks_to_usecs(1000000);
-```
diff --git a/docs/os/core_os/cputime/os_cputime_timer_init.md b/docs/os/core_os/cputime/os_cputime_timer_init.md
deleted file mode 100644
index 7fba485..0000000
--- a/docs/os/core_os/cputime/os_cputime_timer_init.md
+++ /dev/null
@@ -1,65 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_timer_init</font>
-
-```c
-void os_cputime_timer_init(struct hal_timer *timer, hal_timer_cb fp, void *arg)
-```
-Initializes a cputime timer, indicated by `timer`, with a pointer to a callback function to call when the timer expires. When an optional opaque argument is specified, it is passed to the timer callback function.
-
-The callback function has the following prototype:
-```c
-void hal_timer_cb(void *arg)
-```
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `timer` | Pointer to the hal_timer to initialize. This value cannot be NULL.
-| `fp` | Pointer to the callback function to call when the timer expires. This value cannot be NULL.
-| `arg` | Optional opaque argument to pass to the hal timer callback function.
-
-
-#### Returned values
-N/A
-
-#### Notes
-
-#### Example
-
-Example of ble_ll setting up a response timer:
-
-```c
-ble_ll_wfr_timer_exp(void *arg)
-{
- int rx_start;
- uint8_t lls;
-
- ...
-
- /* If we have started a reception, there is nothing to do here */
- if (!rx_start) {
- switch (lls) {
- case BLE_LL_STATE_ADV:
- ble_ll_adv_wfr_timer_exp();
- break;
-
- ...
-
- /* Do nothing here. Fall through intentional */
- case BLE_LL_STATE_INITIATING:
- default:
- break;
- }
- }
-}
-
-void ble_ll_init(void)
-{
- ...
-
- os_cputime_timer_init(&g_ble_ll_data.ll_wfr_timer, ble_ll_wfr_timer_exp, NULL);
-
- ...
-}
-```
-
diff --git a/docs/os/core_os/cputime/os_cputime_timer_relative.md b/docs/os/core_os/cputime/os_cputime_timer_relative.md
deleted file mode 100644
index 2d420a8..0000000
--- a/docs/os/core_os/cputime/os_cputime_timer_relative.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_timer_relative</font>
-
-```c
-void os_cputime_timer_relative(struct hal_timer *timer, uint32_t usecs)
-```
-Sets a timer to expire in the specified number of microseconds from the current time. The callback function for the timer is called when the timer expires.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `timer` | Pointer to an initialized hal_timer.
-| `usecs` | The number of microseconds to set the timer to expire from now.
-
-
-#### Returned values
-N/A
-
-#### Notes
-
-`timer` must be initialized using the `os_cputime_timer_init()` function before setting up a timer.
-
-#### Example
-`
-```c
-struct hal_timer mytimer;
- ...
-
-os_cputime_timer_relative(&mytimer, 100);
-
-```
-
diff --git a/docs/os/core_os/cputime/os_cputime_timer_start.md b/docs/os/core_os/cputime/os_cputime_timer_start.md
deleted file mode 100644
index 4cdba9c..0000000
--- a/docs/os/core_os/cputime/os_cputime_timer_start.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_timer_start</font>
-
-```c
-void os_cputime_timer_start(struct hal_timer *timer, uint32_t cputime)
-```
-Sets a timer to expire at the specified cputime. The callback function for the timer is called when the timer expires.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `timer` | Pointer to an initialized hal_timer.
-| `cputime` | The cputime when the timer expires.
-
-
-#### Returned values
-N/A
-
-#### Notes
-
-`timer` must be initialized using the `os_cputime_timer_init()` function before setting up a timer.
-
-#### Example
-
-```c
-void
-ble_ll_wfr_enable(uint32_t cputime)
-{
- os_cputime_timer_start(&g_ble_ll_data.ll_wfr_timer, cputime);
-}
-
-```
-
diff --git a/docs/os/core_os/cputime/os_cputime_timer_stop.md b/docs/os/core_os/cputime/os_cputime_timer_stop.md
deleted file mode 100644
index 5c38f06..0000000
--- a/docs/os/core_os/cputime/os_cputime_timer_stop.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_timer_stop</font>
-
-```c
-void os_cputime_timer_stop(struct hal_timer *timer)
-```
-Stops a timer from running. The timer is removed from the timer queue and interrupts are disabled if there are no more timers on the timer queue.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `timer` | Pointer to the timer to stop.
-
-
-#### Returned values
-N/A
-
-#### Notes
-
-#### Example
-
-```c
-void
-ble_ll_wfr_disable(void)
-{
- os_cputime_timer_stop(&g_ble_ll_data.ll_wfr_timer);
-}
-
-```
-
diff --git a/docs/os/core_os/cputime/os_cputime_usecs_to_ticks.md b/docs/os/core_os/cputime/os_cputime_usecs_to_ticks.md
deleted file mode 100644
index dd6618d..0000000
--- a/docs/os/core_os/cputime/os_cputime_usecs_to_ticks.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_cputime_usecs_to_ticks</font>
-
-```c
-uint32_t os_cputime_usecs_to_ticks(uint32_t usecs)
-```
-Converts a specified number of microseconds to cputime ticks.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `usecs` | Number of microseconds to convert to ticks.
-
-
-#### Returned values
-The number of ticks in `usecs` nanoseconds.
-
-#### Notes
-
-#### Example
-```c
-uint32_t num_ticks;
-num_ticks = os_cputime_usecs_to_ticks(100);
-```
diff --git a/docs/os/core_os/event_queue/event_queue.md b/docs/os/core_os/event_queue/event_queue.md
deleted file mode 100644
index 540955c..0000000
--- a/docs/os/core_os/event_queue/event_queue.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# Event Queues
-
-
-An event queue allows a task to serialize incoming events and simplify event processing. Events are stored in a queue and a task removes and processes an event from the queue. An event is processed in the context of this task. Events may be generated by [OS callouts](../callout/callout.md), interrupt handlers, and other tasks.
-
-### Description
-
-Mynewt's event queue model uses callback functions to process events. Each event is associated with a callback function that is called to process the event. This model enables a library package, that uses events in its implementation but does not have real-time timing requirements, to use an application event queue instead of creating a dedicated event queue and task to process its events. The callback function executes in the context of the task that the application creates to manage the event queue. This model reduces an application's memory requirement because memory must be allocated for the task's stack when a task is created. A package that has real-time timing requirements and must run at a specific task priority should create a dedicated event queue and task to process its events.
-
-In the Mynewt model, a package defines its events and implements the callback functions for the events. A package that does not have real-time timing requirements should use Mynewt's default event queue for its events. The callback function for an event from the Mynewt default event queue is executed in the context of the application main task. A package can, optionally, export a function that allows an application to specify the event queue for the package to use. (See the example in the `os_eventq_designate()` function description on how to write such a function.) The application task handler that manages the event queue simply pulls events from the event queue and executes the event's callback function in its context.
-
-
-A common way that Mynewt applications or packages process events from an event queue is to have a task that executes in an infinite loop and calls the `os_eventq_get()` function to dequeue and return the event from the head of the event queue. The task then calls the event callback function to process the event. The `os_eventq_get()` function puts the task in to the `sleeping` state when there are no events on the queue. (See [Scheduler](../context_switch/context_switch.md) for more information on task execution states.) Other tasks (or interrupts) call the `os_eventq_put()` function to add an event to the queue. The `os_eventq_put()` function determines whether a task is blocked waiting for an event on the queue and puts the task into the `ready-to-run` state.
-
-A task can use the `os_eventq_run()` wrapper function that calls the `os_eventq_get()` function to dequeue an event from the queue and then calls the event callback function to process the event.
-
-Note:
-
-* Only one task should consume or block waiting for events from an event queue.
-* The [os_callout](../callout/callout.md) subsystem uses events for timer expiration notification.
-
-### Data structures
-
-
-The `os_event` structure defines an event and has the following fields:
-
-```c
-struct os_event {
- uint8_t ev_queued;
- os_event_fn *ev_cb;
- void *ev_arg;
- STAILQ_ENTRY(os_event) ev_next;
-};
-```
-
-| Element | Description |
-|---------|-------------|
-| `ev_queued` | Internal field that indicates whether this event is currently linked to an event queue |
-| `ev_cb` | Pointer to the callback function to call to process this event |
-| `ev_arg` | Pointer to an optional opaque data that the callback function uses to process this event |
-| `ev_next` | Linkage attaching this event to an event queue |
-
-
-An event callback function has the following function prototype:
-```c
-typedef void os_event_fn(struct os_event *ev);
-
-```
-A pointer to the `os_event` structure for the event is passed as an argument to the callback function.
-
-Notes: If the memory for the `os_event` structure is dynamically allocated:
-
-* You must not free the memory for an event that is currently on an event queue.
-* You must free the memory in the callback function after it completes processing the event.
-
-You must set the callback function for an event when you initialize the event. For example, here is an example of a statically-initialized event in the NimBLE host:
-
-```c
-static void ble_hs_event_tx_notify(struct os_event *ev);
-
-/** OS event - triggers tx of pending notifications and indications. */
-static struct os_event ble_hs_ev_tx_notifications = {
- .ev_cb = ble_hs_event_tx_notify,
-};
-
-```
-
-<br>
-The `os_eventq` structure defines an event queue and has the following fields:
-
-```c
-struct os_eventq {
- struct os_task *evq_task;
- STAILQ_HEAD(, os_event) evq_list;
-};
-```
-
-
-| Element | Description |
-|---------|-------------|
-| `evq_task` | Pointer to the task, if any, that is waiting (in the `sleeping` state) for the `os_eventq_get()` function to return an event |
-| `evq_list` | Head of the list of events in this queue |
-
-You must call the `os_eventq_init()` function to initialize an event queue before you can add events to the queue.
-
-### List of Functions
-
-
-The functions available in the Event Queue feature are:
-
-| **Function** | **Description** |
-|---------|-------------|
-| [`os_eventq_init`](os_eventq_init.md) | Initializes an event queue. |
-| [`os_eventq_inited`](os_eventq_inited.md) | Indicates whether an event queue has been initialized. |
-| [`os_eventq_get`](os_eventq_get.md) | Dequeues an event from the head of an event queue. The calling task blocks (in the `sleeping` state) when the event queue is empty. |
-| [`os_eventq_put`](os_eventq_put.md) | Enqueues an event at the tail of an event queue and puts a task waiting for an event on the queue into the `ready-to-run` state. |
-| [`os_eventq_remove`](os_eventq_remove.md) | Removes an event from an event queue. |
-| [`os_eventq_dflt_get`](os_eventq_dflt_get.md) | Gets the default event queue. |
-| [`os_eventq_designate`](os_eventq_designate.md) | Reassigns a package's current event queue to a new event queue. |
-| [`os_eventq_run`](os_eventq_run.md) | Wrapper function that dequeues an event from an event queue and calls the callbck function for the event. |
-
-
-
diff --git a/docs/os/core_os/event_queue/os_eventq_designate.md b/docs/os/core_os/event_queue/os_eventq_designate.md
deleted file mode 100644
index 901231e..0000000
--- a/docs/os/core_os/event_queue/os_eventq_designate.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_eventq_designate</font>
-
-```c
- void
- os_eventq_designate(struct os_eventq **cur_evq, struct os_eventq *new_evq, struct os_event *start_ev)
-```
-
-Reassigns a package's current event queue pointer to point to a new event queue. If a startup event
-is specified, the event is added to the new event queue and removed from the current event queue.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `cur_evq`| Current event queue pointer to reassign |
-| `new_evq` | New event queue to use for the package |
-| `start_ev` | Start event to add to the new event queue |
-
-#### Returned values
-
-None
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-This example shows the `mgmt_evq_set()` function that the `mgmt/newtmgr` package implements. The function
-allows an application to specify an event queue for `newtmgr` to use. The `mgmt_evq_set()` function calls the `os_eventq_designate()` function to reassign the `nmgr_evq` to the event queue that the application specifies.
-
-
-```c
-void
-mgmt_evq_set(struct os_eventq *evq)
-{
- os_eventq_designate(&nmgr_evq, evq, NULL);
-}
-
-
-```
-
diff --git a/docs/os/core_os/event_queue/os_eventq_dflt_get.md b/docs/os/core_os/event_queue/os_eventq_dflt_get.md
deleted file mode 100644
index 3cf0718..0000000
--- a/docs/os/core_os/event_queue/os_eventq_dflt_get.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_eventq_dflt_get</font>
-
-```c
- struct os_eventq
- *os_eventq_dflt_get(void)
-```
-
-Gets the OS default event queue that Mynewt creates at startup.
-
-#### Arguments
-
-None
-
-#### Returned values
-
-`struct os_eventq *`: Pointer to OS the default event queue.
-
-#### Notes
-
-None
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-This example shows an application's `main()` function processing events from the OS default event queue.
-
-
-```c
-void main(int argc, char**argv)
-{
- sysinit();
-
- ...
-
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-
-}
-```
-
diff --git a/docs/os/core_os/event_queue/os_eventq_dflt_set.md b/docs/os/core_os/event_queue/os_eventq_dflt_set.md
deleted file mode 100644
index 05592a1..0000000
--- a/docs/os/core_os/event_queue/os_eventq_dflt_set.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_eventq_dflt_set</font>
-
-```c
- void
- os_eventq_dflt_set(struct os_eventq *evq)
-```
-
-Sets `struct os_eventq` as the default event queue
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `evq` | Pointer to default event queue to use |
-
-#### Returned values
-
-None
-
-#### Notes
-
-Usually done at subsystem init time; before OS has been started, and before interrupts generating events have been enabled.
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-This sets the default event queue used by newtmgr task.
-
-
-```c
-struct os_eventq g_nmgr_evq;
-
-int
-nmgr_task_init(uint8_t prio, os_stack_t *stack_ptr, uint16_t stack_len)
-{
- /* variable declarations here */
-
- os_eventq_init(&g_nmgr_evq);
- os_eventq_dflt_set(&g_nmgr_evq);
-
- /* initialization continues here */
-}
-```
-
diff --git a/docs/os/core_os/event_queue/os_eventq_get.md b/docs/os/core_os/event_queue/os_eventq_get.md
deleted file mode 100644
index 6e01f45..0000000
--- a/docs/os/core_os/event_queue/os_eventq_get.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_eventq_get</font>
-
-```c
-struct os_event *
-os_eventq_get(struct os_eventq *evq)
-```
-
-Dequeues and returns an event from the head of an event queue. When the event queue is empty,
-the function puts the task into the `sleeping` state.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `evq` | Event queue to retrieve the event from |
-
-
-#### Returned values
-
-A pointer to the `os_event` structure for the event dequeued from the queue.
-
-#### Notes
-In most cases, you do not need to call this function directly. You should call the `os_eventq_run()` wrapper
-function that calls this function to retrieve an event and then calls the callback function to process the event.
-
-#### Example
-
-Example of the `os_eventq_run()` wrapper function that calls this function:
-
-```c
-void
-os_eventq_run(struct os_eventq *evq)
-{
- struct os_event *ev;
-
- ev = os_eventq_get(evq);
- assert(ev->ev_cb != NULL);
-
- ev->ev_cb(ev);
-}
-
-```
-
diff --git a/docs/os/core_os/event_queue/os_eventq_init.md b/docs/os/core_os/event_queue/os_eventq_init.md
deleted file mode 100644
index 86b25b3..0000000
--- a/docs/os/core_os/event_queue/os_eventq_init.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_eventq_init</font>
-
-```c
- void
- os_eventq_init(struct os_eventq *evq)
-```
-
-Initializes an event queue.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `evq` | Pointer to the event queue to initialize |
-
-#### Returned values
-
-None
-
-#### Notes
-
-Called during OS, package, and application initialization and before interrupts generating events have been enabled.
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-This example shows the `app/bletest` application initializing the `g_bletest_evq` event queue.
-
-```c
-struct os_eventq g_bletest_evq;
-
-int
-main(void)
-{
- /* variable declarations here */
-
- os_eventq_init(&g_bletest_evq);
-
- /* initialization continues here */
-
-}
-```
-
diff --git a/docs/os/core_os/event_queue/os_eventq_inited.md b/docs/os/core_os/event_queue/os_eventq_inited.md
deleted file mode 100644
index 44fadf0..0000000
--- a/docs/os/core_os/event_queue/os_eventq_inited.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_eventq_inited</font>
-
-```c
- int
- os_eventq_inited(const struct os_eventq *evq)
-```
-
-Indicates whether an event queue has been initialized.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `evq` | Pointer to the event queue to check |
-
-#### Returned values
-
-* 1 if the event queue has been initialized and ready for use.
-* 0 if the event queue has not been initialized.
-
-#### Notes
-You do not need to call this function prior to using an event queue if you have called the `os_eventq_init()` function
-to initialize the queue.
-
-#### Example
-
-<Add text to set up the context for the example here>
-This example checks whether an event queue has been initialized.
-
-
-```c
-struct os_eventq g_my_evq;
-
-int
-my_task_init(uint8_t prio, os_stack_t *stack_ptr, uint16_t stack_len)
-{
- /* variable declarations here */
-
- if(os_eventq_inited(&g_my_evq))
- {
- /* deal with the event queue */
- };
-
-}
-```
-
diff --git a/docs/os/core_os/event_queue/os_eventq_put.md b/docs/os/core_os/event_queue/os_eventq_put.md
deleted file mode 100644
index 453aede..0000000
--- a/docs/os/core_os/event_queue/os_eventq_put.md
+++ /dev/null
@@ -1,74 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_eventq_put</font>
-
-```c
-void
-os_eventq_put(struct os_eventq *evq, struct os_event *ev)
-```
-
-Enqueues an event onto the tail of an event queue. It puts a task, if any, that is in the `sleeping ` state waiting for an event into the `ready-to-run` state.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `evq` | Event queue to add the event to |
-| `ev` | Event to enqueue |
-
-
-#### Returned values
-
-N/A
-
-#### Example
-
-<Add text to set up the context for the example here>
-This example shows the ble host adding a host controller interface event to the `ble_hs_eventq` event queue.
-```c
-
-/* Returns the ble_hs_eventq */
-static struct os_eventq *
-ble_hs_evq_get(void)
-{
- return ble_hs_evq;
-}
-
-/* Event callback function */
-static void
-ble_hs_event_rx_hci_ev(struct os_event *ev)
-{
- uint8_t *hci_evt;
- int rc;
-
- hci_evt = ev->ev_arg;
- rc = os_memblock_put(&ble_hs_hci_ev_pool, ev);
- BLE_HS_DBG_ASSERT_EVAL(rc == 0);
-
- ble_hs_hci_evt_process(hci_evt);
-}
-
-void
-ble_hs_enqueue_hci_event(uint8_t *hci_evt)
-{
- struct os_event *ev;
-
- /* Allocates memory for the event */
- ev = os_memblock_get(&ble_hs_hci_ev_pool);
-
- if (ev == NULL) {
- ble_hci_trans_buf_free(hci_evt);
- } else {
- /*
- * Initializes the event with the ble_hs_event_rx_hci_ev callback function
- * and the hci_evt data for the callback function to use.
- */
- ev->ev_queued = 0;
- ev->ev_cb = ble_hs_event_rx_hci_ev;
- ev->ev_arg = hci_evt;
-
- /* Enqueues the event on the ble_hs_evq */
- os_eventq_put(ble_hs_evq_get(), ev);
- }
-}
-```
-
diff --git a/docs/os/core_os/event_queue/os_eventq_remove.md b/docs/os/core_os/event_queue/os_eventq_remove.md
deleted file mode 100644
index f221212..0000000
--- a/docs/os/core_os/event_queue/os_eventq_remove.md
+++ /dev/null
@@ -1,52 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_eventq_remove</font>
-
-```c
-void
-os_eventq_remove(struct os_eventq *evq, struct os_event *ev)
-```
-
-Removes an event from an event queue.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `evq` | Event queue to remove the event from |
-| `ev` | Event to remove |
-
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-This example from the `os_callout_stop()` function shows how to remove a callout event from an event queue. It removes
-the event from the queue if the event is queued.
-
-```c
-void
-os_callout_stop(struct os_callout *c)
-{
- os_sr_t sr;
-
- OS_ENTER_CRITICAL(sr);
-
- if (os_callout_queued(c)) {
- TAILQ_REMOVE(&g_callout_list, c, c_next);
- c->c_next.tqe_prev = NULL;
- }
-
- if (c->c_evq) {
- os_eventq_remove(c->c_evq, &c->c_ev);
- }
-
- OS_EXIT_CRITICAL(sr);
-}
-```
-
diff --git a/docs/os/core_os/event_queue/os_eventq_run.md b/docs/os/core_os/event_queue/os_eventq_run.md
deleted file mode 100644
index 52a754c..0000000
--- a/docs/os/core_os/event_queue/os_eventq_run.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_eventq_run</font>
-
-```c
- void
- os_eventq_run(struct os_eventq *evq)
-```
-Wrapper function that calls the `os_eventq_get()` function to dequeue the event from the head of the event queue and then calls the callback function for the event.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `evq`| Event queue to dequeue the event from |
-
-#### Returned values
-
-None
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-This example shows an application `main()` that calls the `os_eventq_run()` function to process events from the OS default event queue in an infinite loop.
-
-```c
-int
-main(int argc, char **argv)
-{
-
- sysinit();
- ...
-
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-}
-```
-
diff --git a/docs/os/core_os/heap/heap.md b/docs/os/core_os/heap/heap.md
deleted file mode 100644
index 1981a4f..0000000
--- a/docs/os/core_os/heap/heap.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Heap
-
-
-API for doing dynamic memory allocation.
-
-
-### Description
-
-This provides malloc()/free() functionality with locking. The shared resource heap needs to be protected from concurrent access when OS has been started. *os_malloc()* function grabs a mutex before calling *malloc()*.
-
-### Data structures
-
-N/A
-
-### List of Functions
-
-
-The functions available in heap are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_free](os_free) | Frees previously allocated memory back to the heap. |
-| [os_malloc](os_malloc) | Allocates the given number of bytes from heap and returns a pointer to it. |
-| [os_realloc](os_realloc) | Tries to resize previously allocated memory block, and returns pointer to resized memory. |
-
-
-
diff --git a/docs/os/core_os/heap/os_free.md b/docs/os/core_os/heap/os_free.md
deleted file mode 100644
index feb4946..0000000
--- a/docs/os/core_os/heap/os_free.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_free</font>
-
-```c
-void os_free(void *mem)
-```
-
-Frees previously allocated memory back to the heap.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mem | Pointer to memory being released |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-Calls C-library *free()* behind the covers.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- os_free(info);
-```
-
-
diff --git a/docs/os/core_os/heap/os_malloc.md b/docs/os/core_os/heap/os_malloc.md
deleted file mode 100644
index ab6544b..0000000
--- a/docs/os/core_os/heap/os_malloc.md
+++ /dev/null
@@ -1,39 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_malloc</font>
-
-```c
-void *os_malloc(size_t size)
-```
-
-Allocates *size* number of bytes from heap and returns a pointer to it.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| size | Number of bytes to allocate |
-
-#### Returned values
-
-<ptr>: pointer to memory allocated from heap.
-NULL: not enough memory available.
-
-#### Notes
-
-*os_malloc()* calls *malloc()*, which is provided by C-library. The heap must be set up during platform initialization.
-Depending on which C-library you use, you might have to do the heap setup differently. Most often *malloc()* implementation will maintain a list of allocated and then freed memory blocks. If user asks for memory which cannot be satisfied from free list, they'll call platform's *sbrk()*, which then tries to grow the heap.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- info = (struct os_task_info *) os_malloc(
- sizeof(struct os_task_info) * tcount);
- if (!info) {
- rc = -1;
- goto err;
- }
-```
-
-
diff --git a/docs/os/core_os/heap/os_realloc.md b/docs/os/core_os/heap/os_realloc.md
deleted file mode 100644
index e675155..0000000
--- a/docs/os/core_os/heap/os_realloc.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_realloc</font>
-
-```c
-void *os_realloc(void *ptr, size_t size)
-```
-
-Tries to resize previously allocated memory block, and returns pointer to resized memory.
-ptr can be NULL, in which case the call is similar to calling *os_malloc()*.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| ptr | Pointer to previously allocated memory |
-| size | New size to adjust the memory block to |
-
-#### Returned values
-
-NULL: size adjustment was not successful. <br>
-ptr: pointer to new start of memory block
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
-<Insert the code snippet here>
-```
-
diff --git a/docs/os/core_os/mbuf/OS_MBUF_DATA.md b/docs/os/core_os/mbuf/OS_MBUF_DATA.md
deleted file mode 100644
index 27effcb..0000000
--- a/docs/os/core_os/mbuf/OS_MBUF_DATA.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MBUF_DATA</font>
-
-```c
-OS_MBUF_DATA(__om, __type)
-```
-
-Macro used to cast the data pointer of an mbuf to a given type.
-
-
-<br>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
-| __type | Type to cast |
-
-
-<br>
-
-#### Example
-
-```c
- struct os_mbuf *om
- uint8_t *rxbuf;
-
- rxbuf = OS_MBUF_DATA(om, uint8_t *);
-```
-
diff --git a/docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md b/docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md
deleted file mode 100644
index a132362..0000000
--- a/docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MBUF_LEADINGSPACE</font>
-
-```c
-OS_MBUF_LEADINGSPACE(__om)
-```
-
-Macro used to get the amount of leading space in an mbuf (in bytes).
-
-
-<br>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
-
-
-<br>
-
-#### Notes
-This macro works on both normal mbufs and packet header mbufs. The amount of leading space is the number of bytes between the current om_data pointer of the mbuf and the start of the mbuf user data buffer.
-
-<br>
-
-#### Example
-
-```c
- uint8_t *dptr;
- uint16_t space;
- struct os_mbuf *om;
- struct my_data_struct my_data;
-
- /* Copy data from "my_data" into the start of an mbuf but only if there is enough room */
- space = OS_MBUF_LEADINGSPACE(om);
- if (space >= sizeof(struct my_data_struct)) {
- dptr = om->om_data - sizeof(struct my_data_struct);
- memcpy(dptr, &my_data, sizeof(struct my_data_struct));
- }
-```
-
-
diff --git a/docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md b/docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md
deleted file mode 100644
index 98faaec..0000000
--- a/docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MBUF_PKTHDR</font>
-
-```c
-OS_MBUF_PKTHDR(__om)
-```
-
-Macro used to get a pointer to the os mbuf packet header of an mbuf.
-
-
-<br>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
-
-
-<br>
-
-#### Example
-
-```c
-int
-does_packet_have_data(struct os_mbuf *om)
-{
- struct os_mbuf_pkthdr *hdr;
-
- hdr = OS_MBUF_PKTHDR(om);
- if (hdr->omp_len != 0) {
- /* Packet has data in it */
- return TRUE
- } else {
- /* Packet has no data */
- return FALSE;
- }
-}
-```
-
-
diff --git a/docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md b/docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md
deleted file mode 100644
index 942dcd2..0000000
--- a/docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MBUF_PKTHDR_TO_MBUF</font>
-
-```c
-OS_MBUF_PKTHDR_TO_MBUF(__hdr)
-```
-
-Macro used to get a pointer to the mbuf given a pointer to the os mbuf packet header
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| __hdr | Pointer to os mbuf packet header (struct os_mbuf_pkthdr *) |
-
-<br>
-
-
-#### Example
-
-```c
- struct os_mbuf *om;
- struct os_mbuf_pkthdr *hdr;
-
- om = OS_MBUF_PKTHDR_TO_MBUF(hdr);
- os_mbuf_free_chain(om);
-```
-
-
-
diff --git a/docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md b/docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md
deleted file mode 100644
index 104cca3..0000000
--- a/docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MBUF_PKTLEN</font>
-
-```c
-OS_MBUF_PKTLEN(__om)
-```
-
-Macro used to get the length of an entire mbuf chain.
-
-
-<br>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
-
-
-<br>
-
-#### Example
-
-```c
- uint16_t pktlen;
- struct os_mbuf *om;
-
- /* Check if there is any data in the mbuf chain */
- pktlen = OS_MBUF_PKTLEN(om);
- if (pktlen != 0) {
- /* mbuf chain has data */
- }
-```
-
-
diff --git a/docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md b/docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md
deleted file mode 100644
index d93d948..0000000
--- a/docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MBUF_TRAILINGSPACE</font>
-
-```c
-OS_MBUF_TRAILINGSPACE(__om)
-```
-
-Macro used to get the amount of trailing space in an mbuf (in bytes).
-
-
-<br>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
-
-
-<br>
-
-#### Notes
-This macro works on both normal mbufs and packet header mbufs. The amount of trailing space is the number of bytes between the current om_data pointer of the mbuf and the end of the mbuf.
-
-<br>
-
-#### Example
-
-```c
- uint16_t space;
- struct os_mbuf *om;
- struct my_data_struct my_data;
-
- /* Copy data from "my_data" to the end of an mbuf but only if there is enough room */
- space = OS_MBUF_TRAILINGSPACE(om);
- if (space >= sizeof(struct my_data_struct)) {
- memcpy(om->om_data, &my_data, sizeof(struct my_data_struct));
- }
-```
-
-
diff --git a/docs/os/core_os/mbuf/OS_MBUF_USRHDR.md b/docs/os/core_os/mbuf/OS_MBUF_USRHDR.md
deleted file mode 100644
index e54cbb7..0000000
--- a/docs/os/core_os/mbuf/OS_MBUF_USRHDR.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MBUF_USRHDR</font>
-
-```c
-OS_MBUF_USRHDR(__om)
-```
-
-Macro used to get a pointer to the user packet header of an mbuf.
-
-<br>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *). Must be head of chain (i.e. a packet header mbuf) |
-
-
-<br>
-
-#### Example
-
-```c
- struct os_mbuf *om
- struct user_header *hdr;
-
- hdr = OS_MBUF_USRHDR(om);
-```
-
-
-
diff --git a/docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md b/docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md
deleted file mode 100644
index ebc8611..0000000
--- a/docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MBUF_USRHDR_LEN</font>
-
-```c
-OS_MBUF_USRHDR_LEN(__om)
-```
-
-Macro used to retrieve the length of the user packet header in an mbuf.
-
-<br>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *). Must be head of chain (i.e. a packet header mbuf) |
-
-
-<br>
-
-#### Example
-
-```c
- uint16_t user_length;
- struct os_mbuf *om
- struct user_header *hdr;
-
- user_length = OS_MBUF_USRHDR_LEN(om);
-```
-
-
-
diff --git a/docs/os/core_os/mbuf/mbuf.md b/docs/os/core_os/mbuf/mbuf.md
deleted file mode 100644
index fd261d3..0000000
--- a/docs/os/core_os/mbuf/mbuf.md
+++ /dev/null
@@ -1,246 +0,0 @@
-# Mbufs
-
-The mbuf (short for memory buffer) is a common concept in networking stacks. The mbuf is used to hold packet data as it traverses the stack. The mbuf also generally stores header information or other networking stack information that is carried around with the packet. The mbuf and its associated library of functions were developed to make common networking stack operations (like stripping and adding protocol headers) efficient and as copy-free as possible.
-
-In its simplest form, an mbuf is a memory block with some space reserved for internal information and a pointer which is used to "chain" memory blocks together in order to create a "packet". This is a very important aspect of the mbuf: the ability to chain mbufs together to create larger "packets" (chains of mbufs).
-
-### Why use mbufs?
-
-The main reason is to conserve memory. Consider a networking protocol that generally sends small packets but occasionally sends large ones. The Bluetooth Low Energy (BLE) protocol is one such example. A flat buffer would need to be sized so that the maximum packet size could be contained by the buffer. With the mbuf, a number of mbufs can be chained together so that the occasional large packet can be handled while leaving more packet buffers available to the networking stack for smaller packets.
-
-### Packet Header mbuf
-
-Not all mbufs are created equal. The first mbuf in a chain of mbufs is a special mbuf called a "packet header mbuf". The reason that this mbuf is special is that it contains the length of all the data contained by the chain of mbufs (the packet length, in other words). The packet header mbuf may also contain a user defined structure (called a "user header") so that networking protocol specific information can be conveyed to various layers of the networking stack. Any mbufs that are part of the packet (i.e. in the mbuf chain but not the first one) are "normal" (i.e. non-packet header) mbufs. A normal mbuf does not have any packet header or user packet header structures in them; they only contain the basic mbuf header (`struct os_mbuf`). Figure 1 illustrates these two types of mbufs. Note that the numbers/text in parentheses denote the size of the structures/elements (in bytes) and that MBLEN is the memory block length of the memory pool used by the mbuf pool.
-
-
-
-### Normal mbuf
-
-Now let's take a deeper dive into the mbuf structure. Figure 2 illustrates a normal mbuf and breaks out the various fields in the `os_mbuf` structure.
-
-* The *om_data* field is a pointer to where the data starts inside the data buffer. Typically, mbufs that are allocated from the mbuf pool (discussed later) have their om_data pointer set to the start of the data buffer but there are cases where this may not be desirable (added a protocol header to a packet, for example).
-* The *om_flags* field is a set of flags used internally by the mbuf library. Currently, no flags have been defined.
-* The *om_pkthdr_len* field is the total length of all packet headers in the mbuf. For normal mbufs this is set to 0 as there is no packet or user packet headers. For packet header mbufs, this would be set to the length of the packet header structure (16) plus the size of the user packet header (if any). Note that it is this field which differentiates packet header mbufs from normal mbufs (i.e. if *om_pkthdr_len* is zero, this is a normal mbuf; otherwise it is a packet header mbuf).
-* The *om_len* field contains the amount of user data in the data buffer. When initially allocated, this field is 0 as there is no user data in the mbuf.
-* The *omp_pool* field is a pointer to the pool from which this mbuf has been allocated. This is used internally by the mbuf library.
-* The *omp_next* field is a linked list element which is used to chain mbufs.
-
-Figure 2 also shows a normal mbuf with actual values in the `os_mbuf` structure. This mbuf starts at address 0x1000 and is 256 bytes in total length. In this example, the user has copied 33 bytes into the data buffer starting at address 0x1010 (this is where om_data points). Note that the packet header length in this mbuf is 0 as it is not a packet header mbuf.
-
-
-
-Figure 3 illustrates the packet header mbuf along with some chained mbufs (i.e a "packet"). In this example, the user header structure is defined to be 8 bytes. Note that in figure 3 we show a number of different mbufs with varying *om_data* pointers and lengths since we want to show various examples of valid mbufs. For all the mbufs (both packet header and normal ones) the total length of the memory block is 128 bytes.
-
-
-
-### Mbuf pools
-
-Mbufs are collected into "mbuf pools" much like memory blocks. The mbuf pool itself contains a pointer to a memory pool. The memory blocks in this memory pool are the actual mbufs; both normal and packet header mbufs. Thus, the memory block (and corresponding memory pool) must be sized correctly. In other words, the memory blocks which make up the memory pool used by the mbuf pool must be at least: sizeof(struct os_mbuf) + sizeof(struct os_mbuf_pkthdr) + sizeof(struct user_defined_header) + desired minimum data buffer length. For example, if the developer wants mbufs to contain at least 64 bytes of user data and they have a user header of 12 bytes, the size of the memory block would be (at least): 64 + 12 + 16 + 8, or 100 bytes. Yes, this is a fair amount of overhead. However, the flexibility provided by the mbuf library usually outweighs overhead concerns.
-
-### Create mbuf pool
-
-Creating an mbuf pool is fairly simple: create a memory pool and then create the mbuf pool using that memory pool. Once the developer has determined the size of the user data needed per mbuf (this is based on the application/networking stack and is outside the scope of this discussion) and the size of the user header (if any), the memory blocks can be sized. In the example shown below, the application requires 64 bytes of user data per mbuf and also allocates a user header (called struct user_hdr). Note that we do not show the user header data structure as there really is no need; all we need to do is to account for it when creating the memory pool. In the example, we use the macro *MBUF_PKTHDR_OVERHEAD* to denote the amount of packet header overhead per mbuf and *MBUF_MEMBLOCK_OVERHEAD* to denote the total amount of overhead required per memory block. The macro *MBUF_BUF_SIZE* is used to denote the amount of payload that the application requires (aligned on a 32-bit boundary in this case). All this leads to the total memory block size required, denoted by the macro *MBUF_MEMBLOCK_OVERHEAD*.
-
-
-```c
-
-#define MBUF_PKTHDR_OVERHEAD sizeof(struct os_mbuf_pkthdr) + sizeof(struct user_hdr)
-#define MBUF_MEMBLOCK_OVERHEAD sizeof(struct os_mbuf) + MBUF_PKTHDR_OVERHEAD
-
-#define MBUF_NUM_MBUFS (32)
-#define MBUF_PAYLOAD_SIZE (64)
-#define MBUF_BUF_SIZE OS_ALIGN(MBUF_PAYLOAD_SIZE, 4)
-#define MBUF_MEMBLOCK_SIZE (MBUF_BUF_SIZE + MBUF_MEMBLOCK_OVERHEAD)
-#define MBUF_MEMPOOL_SIZE OS_MEMPOOL_SIZE(MBUF_NUM_MBUFS, MBUF_MEMBLOCK_SIZE)
-
-struct os_mbuf_pool g_mbuf_pool;
-struct os_mempool g_mbuf_mempool;
-os_membuf_t g_mbuf_buffer[MBUF_MEMPOOL_SIZE];
-
-void
-create_mbuf_pool(void)
-{
- int rc;
-
- rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
- MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
- assert(rc == 0);
-
- rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
- MBUF_NUM_MBUFS);
- assert(rc == 0);
-}
-
-```
-### Using mbufs
-
-The following examples illustrate typical mbuf usage. There are two basic mbuf allocation API: `os_mbuf_get()` and `os_mbuf_get_pkthdr()`. The first API obtains a normal mbuf whereas the latter obtains a packet header mbuf. Typically, application developers use `os_mbuf_get_pkthdr()` and rarely, if ever, need to call `os_mbuf_get()` as the rest of the mbuf API (e.g. `os_mbuf_append()`, `os_mbuf_copyinto()`, etc.) typically deal with allocating and chaining mbufs. It is recommended to use the provided API to copy data into/out of mbuf chains and/or manipulate mbufs.
-
-In `example1`, the developer creates a packet and then sends the packet to a networking interface. The code sample also provides an example of copying data out of an mbuf as well as use of the "pullup" api (another very common mbuf api).
-
-```c
-
-void
-mbuf_usage_example1(uint8_t *mydata, int mydata_length)
-{
- int rc;
- struct os_mbuf *om;
-
- /* get a packet header mbuf */
- om = os_mbuf_get_pkthdr(&g_mbuf_pool, sizeof(struct user_hdr));
- if (om) {
- /*
- * Copy user data into mbuf. NOTE: if mydata_length is greater than the
- * mbuf payload size (64 bytes using above example), mbufs are allocated
- * and chained together to accommodate the total packet length.
- */
- rc = os_mbuf_copyinto(om, 0, mydata, mydata_length);
- if (rc) {
- /* Error! Could not allocate enough mbufs for total packet length */
- return -1;
- }
-
- /* Send packet to networking interface */
- send_pkt(om);
- }
-}
-```
-
-In `example2` we show use of the pullup api as this illustrates some of the typical pitfalls developers encounter when using mbufs. The first pitfall is one of alignment/padding. Depending on the processor and/or compiler, the sizeof() a structure may vary. Thus, the size of *my_protocol_header* may be different inside the packet data of the mbuf than the size of the structure on the stack or as a global variable, for instance. While some networking protcols may align protocol information on convenient processor boundaries many others try to conserve bytes "on the air" (i.e inside the packet data). Typical methods used to deal with this are "packing" the structure (i.e. force compiler to not pad) or creating protocol headers that do not require padding. `example2` assumes that one of these methods was used when defining the *my_protocol_header* structure.
-
-Another common pitfall occurs around endianness. A network protocol may be little endian or big endian; it all depends on the protocol specification. Processors also have an endianness; this means that the developer has to be careful that the processor endianness and the protocol endianness are handled correctly. In `example2`, some common networking functions are used: `ntohs()` and `ntohl()`. These are shorthand for "network order to host order, short" and "network order to host order, long". Basically, these functions convert data of a certain size (i.e. 16 bits, 32 bits, etc) to the endianness of the host. Network byte order is big-endian (most significant byte first), so these functions convert big-endian byte order to host order (thus, the implementation of these functions is host dependent). Note that the BLE networking stack "on the air" format is least signigicant byte first (i.e. little endian), so a "bletoh" function would have to take little endian format and convert to host format.
-
-A long story short: the developer must take care when copying structure data to/from mbufs and flat buffers!
-
-A final note: these examples assume the same mbuf struture and definitions used in the first example.
-
-```c
-void
-mbuf_usage_example2(struct mbuf *rxpkt)
-{
- int rc;
- uint8_t packet_data[16];
- struct mbuf *om;
- struct my_protocol_header *phdr;
-
- /* Make sure that "my_protocol_header" bytes are contiguous in mbuf */
- om = os_mbuf_pullup(&g_mbuf_pool, sizeof(struct my_protocol_header));
- if (!om) {
- /* Not able to pull up data into contiguous area */
- return -1;
- }
-
- /*
- * Get the protocol information from the packet. In this example we presume that we
- * are interested in protocol types that are equal to MY_PROTOCOL_TYPE, are not zero
- * length, and have had some time in flight.
- */
- phdr = OS_MBUF_DATA(om, struct my_protocol_header *);
- type = ntohs(phdr->prot_type);
- length = ntohs(phdr->prot_length);
- time_in_flight = ntohl(phdr->prot_tif);
-
- if ((type == MY_PROTOCOL_TYPE) && (length > 0) && (time_in_flight > 0)) {
- rc = os_mbuf_copydata(rxpkt, sizeof(struct my_protocol_header), 16, packet_data);
- if (!rc) {
- /* Success! Perform operations on packet data */
- <... user code here ...>
- }
- }
-
- /* Free passed in packet (mbuf chain) since we don't need it anymore */
- os_mbuf_free_chain(om);
-}
-
-```
-
-<br>
-
-### Data Structures
-
-```c
-struct os_mbuf_pool {
- uint16_t omp_databuf_len;
- uint16_t omp_mbuf_count;
- struct os_mempool *omp_pool;
- STAILQ_ENTRY(os_mbuf_pool) omp_next;
-};
-```
-
-| **Element** | **Description** |
-|-----------|-------------|
-| omp_databuf_len | The length, in bytes, of the "data buffer" of the mbuf. The data buffer of the mbuf is everything except the os_mbuf structure (which is present in all types of mbufs)|
-| omp_mbuf_count | Total number of mbufs in the pool when allocated. This is NOT the number of free mbufs in the pool! |
-| omp_pool | The memory pool from which the mbufs are allocated |
-| omp_next | This is a linked list pointer which chains memory pools. It is used by the system memory pool library |
-
-<br>
-
-```c
-struct os_mbuf_pkthdr {
- uint16_t omp_len;
- uint16_t omp_flags;
- STAILQ_ENTRY(os_mbuf_pkthdr) omp_next;
-};
-```
-
-| **Element** | **Description** |
-|-----------|-------------|
-| omp_len | Length, in bytes, of the "packet". This is the sum of the user data in all the mbufs chained to the packet header mbuf (including the packet header mbuf)|
-| omp_flags | Packet header flags. |
-| omp_next | Linked list pointer to chain "packets". This can be used to add mbuf chains to a queue or linked list and is there for convenience. |
-
-<br>
-
-```c
-struct os_mbuf {
- uint8_t *om_data;
- uint8_t om_flags;
- uint8_t om_pkthdr_len;
- uint16_t om_len;
- struct os_mbuf_pool *om_omp;
- SLIST_ENTRY(os_mbuf) om_next;
- uint8_t om_databuf[0];
-};
-```
-
-| **Element** | **Description** |
-|-----------|-------------|
-| om_data | Pointer to start of user data in mbuf data buffer |
-| om_flags | mbuf flags field. Currently all flags unused. |
-| om_pkthdr_len | The total length of all packet headers in the mbuf (mbuf packet header plus user packet header), in bytes |
-| om_len | The length of the user data contained in this mbuf, in bytes |
-| om_omp | Memory pool pointer. This is the mbuf pool from which this mbuf was allocated. |
-| om_next | Pointer to next mbuf in packet chain |
-| om_databuf | mbuf data buffer (accessor to start of mbuf data buffer). Note that the mbuf data buffer refers to the start of either the user data in normal mbufs or the start of the os mbuf packet header for packet header mbufs |
-
-### List of Functions/Macros
-
-The functions/macros available in mbuf are:
-
-| **Function/Macro** | **Description** |
-|-----------|-------------|
-| [OS_MBUF_PKTHDR](OS_MBUF_PKTHDR.md) | Get a pointer to the os mbuf packet header of an mbuf. |
-| [OS_MBUF_PKTHDR_TO_MBUF](OS_MBUF_PKTHDR_TO_MBUF.md) | Get a pointer to the mbuf given a pointer to the os mbuf packet header. |
-| [OS_MBUF_PKTLEN](OS_MBUF_PKTLEN.md) | Get the length of an entire mbuf chain. |
-| [OS_MBUF_DATA](OS_MBUF_DATA.md) | Cast the data pointer of an mbuf to a given type. |
-| [OS_MBUF_USRHDR](OS_MBUF_USRHDR.md) | Get a pointer to the user packet header of an mbuf. |
-| [OS_MBUF_USRHDR_LEN](OS_MBUF_USRHDR_LEN.md) | Retrieve the length of the user packet header in an mbuf. |
-| [OS_MBUF_LEADINGSPACE](OS_MBUF_LEADINGSPACE.md) | Get the amount of leading space in an mbuf (in bytes). |
-| [OS_MBUF_TRAILINGSPACE](OS_MBUF_TRAILINGSPACE.md) | Get the amount of trailing space in an mbuf (in bytes). |
-| [os_mbuf_adj](os_mbuf_adj.md) | Trims the given number of bytes from either the head (if positive) or tail (if negative) of an mbuf chain. |
-| [os_mbuf_append](os_mbuf_append.md) | Appends a data buffer of the given length to the end of an mbuf chain. |
-| [os_mbuf_concat](os_mbuf_concat.md) | Attaches a second mbuf chain onto the end of the first. |
-| [os_mbuf_copydata](os_mbuf_copydata.md) | Copy data from an mbuf chain. |
-| [os_mbuf_copyinto](os_mbuf_copyinto.md) | Copies the contents of a flat buffer into an mbuf chain. |
-| [os_mbuf_dup](os_mbuf_dup.md) | Duplicate a chain of mbufs. |
-| [os_mbuf_extend](os_mbuf_extend.md) | Increases the length of an mbuf chain by the specified amount. |
-| [os_mbuf_free_chain](os_mbuf_free_chain.md) | Frees a chain of mbufs. |
-| [os_mbuf_get](os_mbuf_get.md) | Get an mbuf from the mbuf pool. |
-| [os_mbuf_get_pkthdr](os_mbuf_get_pkthdr.md) | Allocates a packet header mbuf from the given mbuf pool. Adds a user header to the packet header mbuf. |
-| [os_mbuf_memcmp](os_mbuf_memcmp.md) | Performs a memory compare of the specified region of an mbuf chain against a flat buffer. |
-| [os_mbuf_off](os_mbuf_off.md) | Given an offset in the packet, return the mbuf and the offset in that mbuf where byte 'off' is located. |
-| [os_mbuf_pool_init](os_mbuf_pool_init.md) | nitialize an mbuf pool. |
-| [os_mbuf_prepend](os_mbuf_prepend.md) | Increases the length of an mbuf chain by adding data to the front. |
-| [os_mbuf_pullup](os_mbuf_pullup.md) | Rearrange an mbuf chain so that the given length of bytes are contiguous and in the data area of an mbuf. |
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_adj.md b/docs/os/core_os/mbuf/os_mbuf_adj.md
deleted file mode 100644
index a3881b4..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_adj.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_mbuf_adj</font>
-
-```c
-void os_mbuf_adj(struct os_mbuf *mp, int req_len);
-```
-
-Trims *req_len* bytes from either the head (if positive) or tail (if negative) of an mbuf chain. Adjusts the packet length of the mbuf chain if *mp* points to a packet header mbuf. When trimming from the head, no mbufs are freed. When trimming from the tail, any mbufs of zero length left at the end of the chain are freed.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mp | Pointer to mbuf. Can be head of a chain of mbufs, a single mbuf or a packet header mbuf |
-| req_len | Number of bytes to trim from head or tail of mbuf
-
-
-<br>
-
-#### Returned values
-
-None
-
-#### Notes
-
-
-#### Example
-
-```c
- uint16_t pktlen;
- struct os_mbuf *om;
- struct my_pkt_header hdr;
-
- /* Get mbuf chain length */
- pktlen = OS_MBUF_PKTLEN(om);
-
- /* Strip header from mbuf chain */
- os_mbuf_adj(om, sizeof(struct my_pkt_header));
- pktlen -= sizeof(struct my_pkt_header);
-
- /* New packet length should be old packet length minus stripped header */
- assert(pktlen == OS_MBUF_PKTLEN(om));
-```
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_append.md b/docs/os/core_os/mbuf/os_mbuf_append.md
deleted file mode 100644
index 423409f..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_append.md
+++ /dev/null
@@ -1,60 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_mbuf_append</font>
-
-```c
-int os_mbuf_append(struct os_mbuf *om, const void *data, uint16_t len)
-```
-
-Appends a data buffer of length *len* to the end of an mbuf chain, adjusting packet length if *om* is a packet header mbuf. If not enough trailing space exists at the end of the mbuf chain, mbufs are allocated to hold the data.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf. Can be head of a chain of mbufs, a single mbuf or a packet header mbuf |
-| data | Pointer to data buffer to copy from |
-| len | Number of bytes to copy from data buffer to the end of the mbuf |
-
-
-<br>
-
-#### Returned values
-
-0: success
-OS_ENOMEM: Could not allocate enough mbufs to hold data.
-OS_EINVAL: *om* was NULL on entry.
-
-<br>
-
-#### Notes
-If not enough mbufs were available the packet header length of the mbuf may get adjusted even though the entire data buffer was not appended to the end of the mbuf.
-
-<br>
-
-If any mbufs are allocated, they are allocated from the same pool as *om*
-
-<br>
-
-#### Example
-
-```c
- int rc;
- uint16_t pktlen;
- struct os_mbuf *om;
- struct my_data_struct my_data;
-
- /* Get initial packet length */
- pktlen = OS_MBUF_PKTLEN(om);
-
- /* Append "my_data" to end of mbuf, freeing mbuf if unable to append all the data */
- rc = os_mbuf_append(om, &my_data, sizeof(struct my_pkt_header));
- if (rc) {
- os_mbuf_free_chain(om);
- }
- pktlen += sizeof(struct my_pkt_header);
-
- /* New packet length should be initial packet length plus length of "my_data" */
- assert(pktlen == OS_MBUF_PKTLEN(om));
-```
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_concat.md b/docs/os/core_os/mbuf/os_mbuf_concat.md
deleted file mode 100644
index 69df9f6..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_concat.md
+++ /dev/null
@@ -1,50 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_mbuf_concat</font>
-
-```c
-void os_mbuf_concat(struct os_mbuf *first, struct os_mbuf *second)
-```
-
-Attaches a second mbuf chain onto the end of the first. If the first chain contains a packet header, the header's length is updated. If the second chain has a packet header, its header is cleared.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| first | Pointer to first mbuf chain |
-| second | Pointer to second mbuf chain |
-
-<br>
-
-#### Returned values
-
-None
-
-<br>
-
-#### Notes
-No data is copied or moved nor are any mbufs freed.
-
-<br>
-
-#### Example
-
-```c
- uint16_t pktlen1;
- uint16_t pktlen2;
- struct os_mbuf *pkt1;
- struct os_mbuf *pkt2;
-
- /* Get initial packet lengths */
- pktlen1 = OS_MBUF_PKTLEN(pkt1);
- pktlen2 = OS_MBUF_PKTLEN(pkt2);
-
- /* Add pkt2 to end of pkt1 */
- os_mbuf_concat(pkt1, pkt2);
-
- /* New packet length should be sum of pkt1 and pkt2 */
- assert((pktlen1 + pktlen2) == OS_MBUF_PKTLEN(pkt1));
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_copydata.md b/docs/os/core_os/mbuf/os_mbuf_copydata.md
deleted file mode 100644
index ff2dcd0..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_copydata.md
+++ /dev/null
@@ -1,53 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_mbuf_copydata</font>
-
-```c
-int os_mbuf_copydata(const struct os_mbuf *m, int off, int len, void *dst)
-```
-
-Copy data from an mbuf chain starting *off* bytes from the beginning, continuing for *len* bytes, into the indicated buffer.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| m | Pointer to mbuf chain |
-| off | Start copy offset, in bytes, from beginning of mbuf chain |
-| len | Number of bytes to copy |
-| dst | Data buffer to copy into |
-
-<br>
-
-#### Returned values
-
-0: success.
--1: The mbuf does not contain enough data
-
-<br>
-
-
-#### Example
-
-```c
- int rc;
- struct os_mbuf *om;
- struct my_hdr_1 my_hdr1;
- struct my_hdr_2 my_hdr2;
-
- /* Header 1 and Header 2 are contiguous in packet at start. Retrieve them from the mbuf chain */
- rc = os_mbuf_copydata(om, 0, sizeof(struct my_hdr_1), &my_hdr1);
- if (rc) {
- /* error! */
- return -1;
- }
-
- rc = os_mbuf_copydata(om, sizeof(struct my_hdr_1), sizeof(struct my_hdr_2), &my_hdr2);
- if (rc) {
- /* error! */
- return -1;
- }
-
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_copyinto.md b/docs/os/core_os/mbuf/os_mbuf_copyinto.md
deleted file mode 100644
index 6c18f57..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_copyinto.md
+++ /dev/null
@@ -1,53 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_mbuf_copyinto</font>
-
-```c
-int os_mbuf_copyinto(struct os_mbuf *om, int off, const void *src, int len);
-```
-
-Copies the contents of a flat buffer into an mbuf chain, starting at the specified destination offset. If the mbuf is too small for the source data, it is extended as necessary. If the destination mbuf contains a packet header, the header length is updated.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf chain |
-| off | Start copy offset, in bytes, from beginning of mbuf chain |
-| src | Address from which bytes are copied |
-| len | Number of bytes to copy from src |
-
-<br>
-
-#### Returned values
-
-0: success.
-All other values indicate an error.
-
-<br>
-
-
-#### Example
-
-```c
- int rc;
- uint16_t pktlen;
- struct os_mbuf *om;
- struct my_data_struct my_data;
-
- /* Get initial packet length */
- pktlen = OS_MBUF_PKTLEN(om);
-
- /* Copy "my_data" into mbuf */
- rc = os_mbuf_copyinto(om, 0, &my_data, sizeof(struct my_data_struct));
- if (rc) {
- os_mbuf_free_chain(om);
- return;
- }
-
- /* Packet length should have increased by size of "my_data" */
- pktlen += sizeof(struct my_data_struct);
- assert(pktlen == OS_MBUF_PKTLEN(om));
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_dup.md b/docs/os/core_os/mbuf/os_mbuf_dup.md
deleted file mode 100644
index 13f9d9e..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_dup.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_mbuf_dup</font>
-
-```c
-struct os_mbuf *os_mbuf_dup(struct os_mbuf *om)
-```
-
-Duplicate a chain of mbufs. Return the start of the duplicated chain.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf chain to duplicate |
-
-<br>
-
-#### Returned values
-
-Pointer to the duplicated chain or NULL if not enough mbufs were available to duplicate the chain.
-
-<br>
-
-
-#### Example
-
-```c
- struct os_mbuf *om;
- struct os_mbuf *new_om;
-
- /* Make a copy of om, returning -1 if not able to duplicate om */
- new_om = os_mbuf_dup(om);
- if (!new_om) {
- return -1;
- }
-```
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_extend.md b/docs/os/core_os/mbuf/os_mbuf_extend.md
deleted file mode 100644
index 3986e37..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_extend.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_mbuf_extend</font>
-
-```c
-void *os_mbuf_extend(struct os_mbuf *om, uint16_t len);
-```
-
-Increases the length of an mbuf chain by the specified amount. If there is not sufficient room in the last buffer, a new buffer is allocated and appended to the chain. It is an error to request more data than can fit in a single buffer.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf chain |
-| len | Number of bytes to increase packet header |
-
-<br>
-
-#### Returned values
-
-Pointer to start of extended data. Caller is guaranteed that there are at least *len* bytes from this pointer to the end of the mbuf.
-
-Returns NULL if extension fails due to insufficient mbufs or *len* too large.
-<br>
-
-
-
-#### Example
-
-```c
- uint8_t *dptr;
- struct os_mbuf *om;
- struct my_data_struct my_data;
-
- /* Obtain enough room to add "my_data" to an mbuf chain */
- dptr = os_mbuf_extend(om, sizeof(struct my_data_struct));
- if (dptr) {
- memcpy(dptr, &my_data, sizeof(struct my_data_struct));
- }
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_free_chain.md b/docs/os/core_os/mbuf/os_mbuf_free_chain.md
deleted file mode 100644
index 660fa5a..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_free_chain.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_mbuf_free_chain</font>
-
-```c
-int os_mbuf_free_chain(struct os_mbuf *om);
-```
-
-Frees a chain of mbufs
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf chain |
-
-<br>
-
-#### Returned values
-
-0: success
-Any other value indicates error
-
-<br>
-
-#### Notes
-Note that for each mbuf in the chain, `os_mbuf_free()` is called.
-
-<br>
-
-#### Example
-
-```c
- int rc;
- struct os_mbuf *om;
-
- /* Free mbuf chain */
- rc = os_mbuf_free_chain(om);
- assert(rc == 0);
-```
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_get.md b/docs/os/core_os/mbuf/os_mbuf_get.md
deleted file mode 100644
index 96aa273..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_get.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mbuf_get</font>
-
-```c
-struct os_mbuf *os_mbuf_get(struct os_mbuf_pool *omp, uint16_t leadingspace)
-```
-
-Get an mbuf from the mbuf pool. The mbuf is allocated, and initialized prior to being returned. The *leadingspace* parameter allows the user to specify the amount of leading space in the allocated mbuf.
-
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf pool from which to allocate mbuf |
-| leadingspace | Amount of leading space in allocated mbuf. Request cannot exceed the mbuf data buffer size. |
-
-<br>
-
-#### Returned values
-
-Returns a pointer to the allocated mbuf or NULL if there are no mbufs available or *leadingspace* was too large.
-<br>
-
-#### Notes
-In most typical applications, the application developer does not need to call `os_mbuf_get()`; the other API will do this automatically. However, this API is provided for convenience as mbufs can also be a simple way to allocate temporary chunks of memory.
-
-<br>
-
-#### Example
-
-```c
- struct os_mbuf *om;
-
- /* Get an mbuf */
- om = os_mbuf_get(&g_mbuf_pool, 0);
- if (om) {
- /* we have allocated an mbuf from the pool */
- }
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md b/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md
deleted file mode 100644
index d975b4b..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mbuf_get_pkthdr</font>
-
-```c
-struct os_mbuf *os_mbuf_get_pkthdr(struct os_mbuf_pool *omp, uint8_t pkthdr_len);
-```
-
-Allocates a packet header mbuf from the mbuf pool pointed to by *omp*. Adds a user header of length *pkthdr_len* to packet header mbuf.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf pool from which to allocate mbuf |
-| pkthdr_len | The user header packet length to allocate for the packet header mbuf |
-
-<br>
-
-#### Returned values
-
-Returns a pointer to the allocated mbuf or NULL if there are no mbufs available or the user packet header was too large.
-
-<br>
-
-#### Notes
-The packet header mbuf returned will have its data pointer incremented by the sizeof(struct os_mbuf_pkthdr) as well as the amount of user header data (i.e. *pkthdr_len*). In other words, the data pointer is offset from the start of the mbuf by: sizeof(struct os_mbuf) + sizeof(struct os_mbuf_pkthdr) + pkthdr_len. The `om_pkthdr_len` element in the allocated mbuf is set to: sizeof(struct os_mbuf_pkthdr) + pkthdr_len.
-
-<br>
-
-#### Example
-
-```c
- struct os_mbuf *om;
- struct my_user_header my_hdr;
-
- /* Get a packet header mbuf with a user header in it */
- om = os_mbuf_get_pkthdr(&g_mbuf_pool, sizeof(struct my_user_header));
- if (om) {
- /* Packet header mbuf was allocated */
- }
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_memcmp.md b/docs/os/core_os/mbuf/os_mbuf_memcmp.md
deleted file mode 100644
index 20ca328..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_memcmp.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mbuf_memcmp</font>
-
-```c
-int os_mbuf_memcmp(const struct os_mbuf *om, int off, const void *data, int len)
-```
-
-Performs a memory compare of the specified region of an mbuf chain against a flat buffer.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf |
-| off | Offset, in bytes, from start of mbuf to start of comparison |
-| data | Pointer to flat data buffer to compare |
-| len | Number of bytes to compare |
-
-<br>
-
-#### Returned values
-A value of zero means the memory regions are identical; all other values represent either an error or a value returned from memcmp.
-
-<br>
-
-#### Notes
-This function will compare bytes starting from *off* bytes from the start of the mbuf chain with a data buffer.
-
-<br>
-
-#### Example
-
-```c
- int rc;
- struct os_mbuf *om;
- uint8_t my_data_buffer[32];
-
- /* Get a packet header mbuf with a user header in it */
- rc = os_mbuf_memcmp(om, 0, my_data_buffer, 32);
- if (!rc) {
- /* "my_data_buffer" and the data from offset 0 in the mbuf chain are identical! */
- }
-```
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_off.md b/docs/os/core_os/mbuf/os_mbuf_off.md
deleted file mode 100644
index 9c9f790..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_off.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mbuf_off</font>
-
-```c
-struct os_mbuf *os_mbuf_off(struct os_mbuf *om, int off, int *out_off)
-```
-
-Given an offset in the packet (i.e. user data byte offset in the mbuf chain), return the mbuf and the offset in that mbuf where byte 'off' is located. Note that the offset is 'returned' in *out_off*.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf |
-| off | Location in mbuf chain of desired byte offset |
-| out_off | Pointer to storage for the relative offset of the absolute location in the returned mbuf |
-
-<br>
-
-#### Returned values
-NULL if the offset is not within the mbuf chain or *om* points to NULL.
-
-<br>
-
-#### Notes
-The user is allowed to call this function with the length of the mbuf chain but no greater. This allows the user to get the mbuf and offset (in that mbuf) where the next user data byte should be written.
-
-While this api is provided to the user, other API are expected to be used by the applciation developer (i.e. `os_mbuf_append()` or `os_mbuf_copyinto()`).
-<br>
-
-#### Example
-
-```c
- int relative_offset;
- uint16_t pktlen;
- struct os_mbuf *om;
- struct os_mbuf *tmp;
-
- /* Append a new line character to end of mbuf data */
- pktlen = OS_MBUF_PKTLEN(om);
-
- relative_offset = 0;
- tmp = os_mbuf_off(om, pktlen, &relative_offset);
- if (tmp) {
- /* Offset found. */
- tmp->om_data[relative_offset] = '\n';
- } else {
- /*
- * This mbuf does not contain enough bytes so this is an invalid offset.
- * In other words, the mbuf is less than 62 bytes in length.
- */
- }
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_pool_init.md b/docs/os/core_os/mbuf/os_mbuf_pool_init.md
deleted file mode 100644
index b3ae463..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_pool_init.md
+++ /dev/null
@@ -1,64 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mbuf_pool_init</font>
-
-```c
-int os_mbuf_pool_init(struct os_mbuf_pool *omp, struct os_mempool *mp, uint16_t buf_len,
- uint16_t nbufs)
-```
-
-Initialize an mbuf pool
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| omp | Pointer to mbuf pool to initialize |
-| mp | Pointer to memory pool used by mbuf pool |
-| buf_len | The size of the memory blocks in the memory pool used by the mbuf pool |
-| nbufs | The number of mbufs in the pool |
-
-<br>
-
-#### Returned values
-0 on success; all other values indicate an error.
-
-<br>
-
-#### Notes
-The parameter *buf_len* is the total size of the memory block. This must accommodate the os_mbuf structure, the os_mbuf_pkthdr structure, any user headers plus the desired amount of user data.
-
-<br>
-
-#### Example
-
-```c
-#define MBUF_PKTHDR_OVERHEAD sizeof(struct os_mbuf_pkthdr) + sizeof(struct user_hdr)
-#define MBUF_MEMBLOCK_OVERHEAD sizeof(struct os_mbuf) + MBUF_PKTHDR_OVERHEAD
-
-#define MBUF_NUM_MBUFS (32)
-#define MBUF_PAYLOAD_SIZE (64)
-#define MBUF_BUF_SIZE OS_ALIGN(MBUF_PAYLOAD_SIZE, 4)
-#define MBUF_MEMBLOCK_SIZE (MBUF_BUF_SIZE + MBUF_MEMBLOCK_OVERHEAD)
-#define MBUF_MEMPOOL_SIZE OS_MEMPOOL_SIZE(MBUF_NUM_MBUFS, MBUF_MEMBLOCK_SIZE)
-
-struct os_mbuf_pool g_mbuf_pool;
-struct os_mempool g_mbuf_mempool;
-os_membuf_t g_mbuf_buffer[MBUF_MEMPOOL_SIZE];
-
-void
-create_mbuf_pool(void)
-{
- int rc;
-
- rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
- MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
- assert(rc == 0);
-
- rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
- MBUF_NUM_MBUFS);
- assert(rc == 0);
-}
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_prepend.md b/docs/os/core_os/mbuf/os_mbuf_prepend.md
deleted file mode 100644
index ab146df..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_prepend.md
+++ /dev/null
@@ -1,50 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mbuf_prepend</font>
-
-```c
-struct os_mbuf *os_mbuf_prepend(struct os_mbuf *om, int len)
-```
-
-Increases the length of an mbuf chain by adding data to the front. If there is insufficient room in the leading mbuf, additional mbufs are allocated and prepended as necessary. If this function fails to allocate an mbuf, the entire chain is freed.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf |
-| len | Length, in bytes, to prepend |
-
-<br>
-
-#### Returned values
-Pointer to mbuf at head of chain; NULL if not enough mbufs were available to accommodate *len*.
-
-<br>
-
-#### Notes
-If *om* is a packet header mbuf, the total length of the packet is adjusted by *len*. Note that the returned mbuf may not point to *om* if insufficient leading space was available in *om*.
-
-<br>
-
-#### Example
-
-```c
- uint16_t pktlen;
- struct os_mbuf *om;
- struct os_mbuf *tmp;
-
- /* Get initial packet length before prepend */
- pktlen = OS_MBUF_PKTLEN(om);
-
- tmp = os_mbuf_prepend(om, 32);
- if (!tmp) {
- /* Not able to prepend. The chain pointed to by *om has been freed */
- return -1;
- }
-
- /* The packet length should equal the original length plus what we prepended */
- assert((pktlen + 32) == OS_MBUF_PKTLEN(tmp));
-```
-
-
diff --git a/docs/os/core_os/mbuf/os_mbuf_pullup.md b/docs/os/core_os/mbuf/os_mbuf_pullup.md
deleted file mode 100644
index 3a9fdc4..0000000
--- a/docs/os/core_os/mbuf/os_mbuf_pullup.md
+++ /dev/null
@@ -1,50 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mbuf_pullup</font>
-
-```c
-struct os_mbuf *os_mbuf_pullup(struct os_mbuf *om, uint16_t len)
-```
-
-Rearrange an mbuf chain so that len bytes are contiguous, and in the data area of an mbuf (so that OS_MBUF_DATA() will work on a structure of size len.) Returns the resulting mbuf chain on success, free's it and returns NULL on failure.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| om | Pointer to mbuf |
-| len | Length, in bytes, to pullup (make contiguous in mbuf) |
-
-<br>
-
-#### Returned values
-Pointer to mbuf at head of chain; NULL if not enough mbufs were available to accommodate *len* or if the requested pullup size was too large.
-
-<br>
-
-#### Notes
-Hopefully it is apparent to the user that you cannot pullup more bytes than the mbuf can accommodate. Pullup does not allocate more than one mbuf; the entire pullup length must be contained within a single mbuf.
-
-The mbuf that is being pulled up into does not need to be a packet header mbuf; it can be a normal mbuf. The user should note that the maximum pullup length does depend on the type of mbuf being pulled up into (a packet header or normal mbuf).
-
-<br>
-
-#### Example
-
-```c
- struct os_mbuf *om;
- struct os_mbuf *tmp;
- struct my_header_struct my_header;
-
- /* Make sure "my_header" is contiguous in the mbuf */
- tmp = os_mbuf_pullup(om, sizeof(my_header_struct));
- if (!tmp) {
- /* Pullup failed. The chain pointed to by *om has been freed */
- return -1;
- }
-
- /* copy data from mbuf into header structure */
- memcpy(&my_header, tmp->om_data, sizeof(struct my_header_struct));
-```
-
-
diff --git a/docs/os/core_os/mbuf/pics/mbuf_fig1.png b/docs/os/core_os/mbuf/pics/mbuf_fig1.png
deleted file mode 100644
index ba7ab0f..0000000
--- a/docs/os/core_os/mbuf/pics/mbuf_fig1.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/core_os/mbuf/pics/mbuf_fig2.png b/docs/os/core_os/mbuf/pics/mbuf_fig2.png
deleted file mode 100644
index 68a9716..0000000
--- a/docs/os/core_os/mbuf/pics/mbuf_fig2.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/core_os/mbuf/pics/mbuf_fig3.png b/docs/os/core_os/mbuf/pics/mbuf_fig3.png
deleted file mode 100644
index 6d5ac5b..0000000
--- a/docs/os/core_os/mbuf/pics/mbuf_fig3.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md b/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
deleted file mode 100644
index dc7fc33..0000000
--- a/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MEMPOOL_BYTES</font>
-
-```c
-OS_MEMPOOL_BYTES(n,blksize)
-```
-
-Calculates how many bytes of memory is used by *n* number of elements, when individual element size is *blksize* bytes.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| n | Number of elements |
-| blksize | Size of an element is number of bytes |
-
-#### Returned values
-The number of bytes used by the memory pool.
-
-<br>
-#### Notes
-OS_MEMPOOL_BYTES is a macro and not a function.
-
-<br>
-#### Example
-
-Here we allocate memory to be used as a pool.
-
-```c
- void *nffs_file_mem;
-
- nffs_file_mem = malloc(OS_MEMPOOL_BYTES(nffs_config.nc_num_files, sizeof (struct nffs_file)));
- if (nffs_file_mem == NULL) {
- return FS_ENOMEM;
- }
-```
-
-
diff --git a/docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md b/docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md
deleted file mode 100644
index 577547e..0000000
--- a/docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">OS_MEMPOOL_SIZE</font>
-
-```c
-OS_MEMPOOL_SIZE(n,blksize)
-```
-
-Calculates the number of os_membuf_t elements used by *n* blocks of size *blksize* bytes.
-
-Note that os_membuf_t is used so that memory blocks are aligned on OS_ALIGNMENT boundaries.
-
-The *blksize* variable is the minimum number of bytes required for each block; the actual block size is padded so that each block is aligned on OS_ALIGNMENT boundaries.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| n | Number of elements |
-| blksize | Size of an element is number of bytes |
-
-#### Returned values
-The number of os_membuf_t elements used by the memory pool. Note that os_membuf_t is defined to be a unsigned, 32-bit integer when OS_ALIGNMENT is 4 and an unsigned, 64-bit integer when OS_ALIGNMENT is 8.
-
-<br>
-#### Notes
-OS_MEMPOOL_SIZE is a macro and not a function.
-
-<br>
-#### Example
-
-Here we define a memory buffer to be used by a memory pool using OS_MEMPOOL_SIZE
-
-```c
-#define NUM_BLOCKS (16)
-#define BLOCK_SIZE (32)
-
-os_membuf_t my_pool_memory[OS_MEMPOOL_SIZE(NUM_BLOCKS, BLOCK_SIZE)]
-```
-
-
diff --git a/docs/os/core_os/memory_pool/memory_pool.md b/docs/os/core_os/memory_pool/memory_pool.md
deleted file mode 100644
index 030599d..0000000
--- a/docs/os/core_os/memory_pool/memory_pool.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# Memory Pools
-
-
-A memory pool is a collection of fixed sized elements called memory blocks. Generally, memory pools are used when the developer wants to allocate a certain amount of memory to a given feature. Unlike the heap, where a code module is at the mercy of other code modules to insure there is sufficient memory, memory pools can insure sufficient memory allocation.
-
-
-### Description
-
-In order to create a memory pool the developer needs to do a few things. The first task is to define the memory pool itself. This is a data structure which contains information about the pool itself (i.e. number of blocks, size of the blocks, etc).
-
-```c
-struct os_mempool my_pool;
-```
-<br>
-The next order of business is to allocate the memory used by the memory pool. This memory can either be statically allocated (i.e. a global variable) or dynamically allocated (i.e. from the heap). When determining the amount of memory required for the memory pool, simply multiplying the number of blocks by the size of each block is not sufficient as the OS may have alignment requirements. The alignment size definition is named `OS_ALIGNMENT` and can be found in os_arch.h as it is architecture specific. The memory block alignment is usually for efficiency but may be due to other reasons. Generally, blocks are aligned on 32-bit boundaries. Note that memory blocks must also be of sufficient size to hold a list pointer as this is needed to chain memory blocks on the free list.
-
-In order to simplify this for the user two macros have been provided: `OS_MEMPOOL_BYTES(n, blksize)` and `OS_MEMPOOL_SIZE(n, blksize)`. The first macro returns the number of bytes needed for the memory pool while the second returns the number of `os_membuf_t` elements required by the memory pool. The `os_membuf_t` type is used to guarantee that the memory buffer used by the memory pool is aligned on the correct boundary.
-
-Here are some examples. Note that if a custom malloc implementation is used it must guarantee that the memory buffer used by the pool is allocated on the correct boundary (i.e. OS_ALIGNMENT).
-
-```c
-void *my_memory_buffer;
-my_memory_buffer = malloc(OS_MEMPOOL_BYTES(NUM_BLOCKS, BLOCK_SIZE));
-```
-
-```c
-os_membuf_t my_memory_buffer[OS_MEMPOOL_SIZE(NUM_BLOCKS, BLOCK_SIZE)];
-```
-<br>
-Now that the memory pool has been defined as well as the memory required for the memory blocks which make up the pool the user needs to initialize the memory pool by calling `os_mempool_init`.
-
-```c
-os_mempool_init(&my_pool, NUM_BLOCKS, BLOCK_SIZE, my_memory_buffer,
- "MyPool");
-```
-<br>
-Once the memory pool has been initialized the developer can allocate memory blocks from the pool by calling `os_memblock_get`. When the memory block is no longer needed the memory can be freed by calling `os_memblock_put`.
-
-### Data structures
-```c
-struct os_mempool {
- int mp_block_size;
- int mp_num_blocks;
- int mp_num_free;
- int mp_min_free;
- uint32_t mp_membuf_addr;
- STAILQ_ENTRY(os_mempool) mp_list;
- SLIST_HEAD(,os_memblock);
- char *name;
-};
-
-struct os_mempool_info {
- int omi_block_size;
- int omi_num_blocks;
- int omi_num_free;
- int omi_min_free;
- char omi_name[OS_MEMPOOL_INFO_NAME_LEN];
-};
-
-```
-<br>
-
-| **Element** | **Description** |
-|-----------|-------------|
-| mp_block_size | Size of the memory blocks, in bytes. This is not the actual number of bytes used by each block; it is the requested size of each block. The actual memory block size will be aligned to OS_ALIGNMENT bytes |
-| mp_num_blocks | Number of memory blocks in the pool |
-| mp_num_free | Number of free blocks left |
-| mp_min_free | Lowest number of free blocks seen |
-| mp_membuf_addr | The address of the memory block. This is used to check that a valid memory block is being freed. |
-| mp_list | List pointer to chain memory pools so they can be displayed by newt tools |
-| SLIST_HEAD(,os_memblock) | List pointer to chain free memory blocks |
-| name | Name for the memory block |
-
-
-### List of Functions/Macros
-
-The functions/macros available in mem_pool are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_memblock_get](os_memblock_get) | Allocate an element from the memory pool. |
-| [os_mempool_init](os_mempool_init) | Initializes the memory pool. |
-| [os_memblock_put](os_memblock_put) | Releases previously allocated element back to the pool. |
-| [os_mempool_info_get_next](os_mempool_info_get_next) | Retrieves memory pool information for the next memory pool. |
-| [OS_MEMPOOL_BYTES](OS_MEMPOOL_BYTES) | Calculates how many bytes of memory is used by n number of elements, when individual element size is blksize bytes. |
-| [OS_MEMPOOL_SIZE](OS_MEMPOOL_SIZE) | Calculates the number of os_membuf_t elements used by n blocks of size blksize bytes. |
-
-
diff --git a/docs/os/core_os/memory_pool/os_memblock_get.md b/docs/os/core_os/memory_pool/os_memblock_get.md
deleted file mode 100644
index e341d4f..0000000
--- a/docs/os/core_os/memory_pool/os_memblock_get.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_memblock_get</font>
-
-```c
-void *os_memblock_get(struct os_mempool *mp)
-```
-
-Allocate an element from the memory pool. If successful, you'll get a pointer to allocated element. If there are no elements available, you'll get NULL as response.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mp | Pool where element is getting allocated from |
-
-#### Returned values
-
-NULL: no elements available.
-<pointer>: pointer to allocated element.
-
-#### Notes
-
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- struct nffs_file *file;
-
- file = os_memblock_get(&nffs_file_pool);
- if (file != NULL) {
- memset(file, 0, sizeof *file);
- }
-
-```
-
-
diff --git a/docs/os/core_os/memory_pool/os_memblock_put.md b/docs/os/core_os/memory_pool/os_memblock_put.md
deleted file mode 100644
index 4aba497..0000000
--- a/docs/os/core_os/memory_pool/os_memblock_put.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_memblock_put</font>
-
-```c
-os_error_t os_memblock_put(struct os_mempool *mp, void *block_addr)
-```
-
-Releases previously allocated element back to the pool.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mp | Pointer to memory pool from which block was allocated |
-| block_addr | Pointer to element getting freed |
-
-<br>
-#### Returned values
-
-OS_OK: operation was a success:
-OS_INVALID_PARAM: If either mp or block_addr were NULL, or the block being freed was outside the range of the memory buffer or not on a true block size boundary.
-
-<br>
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- if (file != NULL) {
- rc = os_memblock_put(&nffs_file_pool, file);
- if (rc != 0) {
- /* Error freeing memory block */
- }
- }
-```
-
diff --git a/docs/os/core_os/memory_pool/os_mempool_info_get_next.md b/docs/os/core_os/memory_pool/os_mempool_info_get_next.md
deleted file mode 100644
index 8f5f2a3..0000000
--- a/docs/os/core_os/memory_pool/os_mempool_info_get_next.md
+++ /dev/null
@@ -1,70 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_mempool_info_get_next</font>
-
-```c
-struct os_mempool * os_mempool_info_get_next(struct os_mempool *mp, struct os_mempool_info *omi)
-```
-Populates the os_mempool_info structure pointed to by `omi` with memory pool information.
-The value of `mp` specifies the memory pool information to populate. If `mp` is **NULL**, it populates the information for the first memory pool on the memory pool list. If `mp` is not NULL, it populates the information for the next memory pool after `mp`.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `mp` | Pointer to the memory pool in the memory pool list from the previous `os_mempool_info_get_next` function call. The next memory pool after `mp` is populated. If `mp` is NULL, the first memory pool on the memory pool list is populated.|
-| `omi` | Pointer to `os_mempool_info` structure where memory information will be stored.|
-
-<br>
-#### Returned values
-
-* A pointer to the memory pool structure that was used to populate the memory pool information structure.
-
-* NULL indicates `mp` is the last memory pool on the list and `omi` is not populated with memory pool information.
-
-<br>
-#### Example
-
-```c
-
-shell_os_mpool_display_cmd(int argc, char **argv)
-{
- struct os_mempool *mp;
- struct os_mempool_info omi;
- char *name;
-
- name = NULL;
- found = 0;
-
- if (argc > 1 && strcmp(argv[1], "")) {
- name = argv[1];
- }
- console_printf("Mempools: \n");
- mp = NULL;
- console_printf("%32s %5s %4s %4s %4s\n", "name", "blksz", "cnt", "free",
- "min");
- while (1) {
- mp = o{_mempool_info_get_next(mp, &omi);
- if (mp == NULL) {
- break;
- }
- if (name) {
- if (strcmp(name, omi.omi_name)) {
- continue;
- } else {
- found = 1;
- }
- }
-
- console_printf("%32s %5d %4d %4d %4d\n", omi.omi_name,
- omi.omi_block_size, omi.omi_num_blocks,
- omi.omi_num_free, omi.omi_min_free);
- }
-
- if (name && !found) {
- console_printf("Couldn't find a memory pool with name %s\n",
- name);
- }
- return (0);
-}
-
-```
diff --git a/docs/os/core_os/memory_pool/os_mempool_init.md b/docs/os/core_os/memory_pool/os_mempool_init.md
deleted file mode 100644
index 809a067..0000000
--- a/docs/os/core_os/memory_pool/os_mempool_init.md
+++ /dev/null
@@ -1,53 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_mempool_init</font>
-
-```c
-os_error_t os_mempool_init(struct os_mempool *mp, int blocks, int block_size, void *membuf, char *name)
-```
-
-Initializes the memory pool. Memory pointed to by *membuf* is divided into *blocks* number of elements of size OS_ALIGN(*block_size*). The *name* is optional, and names the memory pool.
-
-It is assumed that the amount of memory pointed by *membuf* has at least *OS_MEMPOOL_BYTES(blocks, block_size)* number of bytes.
-
-*name* is not copied, so caller should make sure that the memory does not get reused.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mp | Memory pool being initialized |
-| blocks | Number of elements in the pool |
-| block_size | Minimum size of an individual element in pool |
-| membuf | Backing store for the memory pool elements |
-| name | Name of the memory pool |
-
-#### Returned values
-
-OS_OK: operation was successful.
-OS_INVALID_PARAM: invalid parameters. Block count or block size was negative, or membuf or mp was NULL.
-OS_MEM_NOT_ALIGNED: membuf was not aligned on correct byte boundary.
-
-#### Notes
-
-Note that os_mempool_init() does not allocate backing storage; *membuf* has to be allocated by the caller.
-
-It's recommended that you use *OS_MEMPOOL_BYTES()* or *OS_MEMPOOL_SIZE()* to figure out how much memory to allocate for the pool.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- void *nffs_file_mem;
-
- nffs_file_mem = malloc(OS_MEMPOOL_BYTES(nffs_config.nc_num_files, sizeof (struct nffs_file)));
-
- rc = os_mempool_init(&nffs_file_pool, nffs_config.nc_num_files,
- sizeof (struct nffs_file), nffs_file_mem,
- "nffs_file_pool");
- if (rc != 0) {
- /* Memory pool initialization failure */
- }
-
-```
-
-
diff --git a/docs/os/core_os/mqueue/mqueue.md b/docs/os/core_os/mqueue/mqueue.md
deleted file mode 100644
index 614d51b..0000000
--- a/docs/os/core_os/mqueue/mqueue.md
+++ /dev/null
@@ -1,96 +0,0 @@
-# Mqueue
-
-The mqueue construct allows a task to wake up when it receives data. Typically, this data is in the form of packets received over a network. A common networking stack operation is to put a packet on a queue and post an event to the task monitoring that queue. When the task handles the event, it processes each packet on the packet queue.
-
-<br>
-
-### Using Mqueue
-
-The following code sample demonstrates how to use an mqueue. In this example:
-
-* packets are put on a receive queue
-* a task processes each packet on the queue (increments a receive counter)
-
-Not shown in the code example is a call `my_task_rx_data_func`. Presumably, some other code will call this API.
-
-<br>
-
-
-```c
-uint32_t pkts_rxd;
-struct os_mqueue rxpkt_q;
-struct os_eventq my_task_evq;
-
-/**
- * Removes each packet from the receive queue and processes it.
- */
-void
-process_rx_data_queue(void)
-{
- struct os_mbuf *om;
-
- while ((om = os_mqueue_get(&rxpkt_q)) != NULL) {
- ++pkts_rxd;
- os_mbuf_free_chain(om);
- }
-}
-
-/**
- * Called when a packet is received.
- */
-int
-my_task_rx_data_func(struct os_mbuf *om)
-{
- int rc;
-
- /* Enqueue the received packet and wake up the listening task. */
- rc = os_mqueue_put(&rxpkt_q, &my_task_evq, om);
- if (rc != 0) {
- return -1;
- }
-
- return 0;
-}
-
-void
-my_task_handler(void *arg)
-{
- struct os_event *ev;
- struct os_callout_func *cf;
- int rc;
-
- /* Initialize eventq */
- os_eventq_init(&my_task_evq);
-
- /* Initialize mqueue */
- os_mqueue_init(&rxpkt_q, process_rx_data_queue, NULL);
-
- /* Process each event posted to our eventq. When there are no events to
- * process, sleep until one arrives.
- */
- while (1) {
- os_eventq_run(&my_task_evq);
- }
-}
-```
-
-### Data Structures
-
-```c
-struct os_mqueue {
- STAILQ_HEAD(, os_mbuf_pkthdr) mq_head;
- struct os_event mq_ev;
-};
-```
-
-<br>
-
-### List of Functions
-
-The functions available in Mqueue are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_mqueue_init](os_mqueue_init.md) | Initializes an mqueue. |
-| [os_mqueue_get](os_mqueue_get.md) | Retrieves a packet off an Mqueue. |
-| [os_mqueue_put](os_mqueue_put.md) | Adds a packet (i.e. packet header mbuf) to an mqueue. |
diff --git a/docs/os/core_os/mqueue/os_mqueue_get.md b/docs/os/core_os/mqueue/os_mqueue_get.md
deleted file mode 100644
index c29859d..0000000
--- a/docs/os/core_os/mqueue/os_mqueue_get.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mqueue_get</font>
-
-```c
-struct os_mbuf *os_mqueue_get(struct os_mqueue *mq)
-```
-
-Retrieves a packet off an mqueue. Returns a pointer to the mbuf at the head of the mbuf chain or **NULL** if no packets are on the queue.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `mq` | The mqueue to retrieve an mbuf from. |
-
-<br>
-
-#### Returned values
-
-The packet at the head of the queue or NULL if no packets are on the queue.
-
-<br>
-
-#### Example
-
-```c
-uint32_t pkts_rxd;
-struct os_mqueue rxpkt_q;
-
-void
-process_rx_data_queue(void)
-{
- struct os_mbuf *om;
-
- /* Drain all packets off queue and process them */
- while ((om = os_mqueue_get(&rxpkt_q)) != NULL) {
- ++pkts_rxd;
- os_mbuf_free_chain(om);
- }
-}
-```
diff --git a/docs/os/core_os/mqueue/os_mqueue_init.md b/docs/os/core_os/mqueue/os_mqueue_init.md
deleted file mode 100644
index ef876f3..0000000
--- a/docs/os/core_os/mqueue/os_mqueue_init.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mqueue_init</font>
-
-```c
-int
-os_mqueue_init(struct os_mqueue *mq, os_event_fn *ev_cb, void *arg)
-```
-
-Initializes an mqueue. An mqueue is a queue of mbufs that ties to a particular task's event queue. Mqueues form a helper API around a common paradigm: wait on an event queue until at least one packet is available, then process a queue of packets.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `mq` | The mqueue to initialize |
-| `ev_cb` | The callback to associate with the mqeueue event. Typically, this callback pulls each packet off the mqueue and processes them.
-| `arg` | The argument to associate with the mqueue event.
-
-@return 0 on success, non-zero on failure.
-
-
-Initializes an mqueue. Sets the event argument in the os event of the mqueue to `arg`.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| mq | Pointer to a mqueue structure |
-| arg | Event argument |
-
-<br>
-
-#### Returned values
-
-0: success. All other values indicate an error
-
-<br>
-
-#### Example
-
-```c
-/* Event callback to execute when a packet is received. */
-extern void process_rx_data_queue(void);
-
-/* Declare mqueue */
-struct os_mqueue rxpkt_q;
-
-/* Initialize mqueue */
-os_mqueue_init(&rxpkt_q, process_rx_data_queue, NULL);
-```
diff --git a/docs/os/core_os/mqueue/os_mqueue_put.md b/docs/os/core_os/mqueue/os_mqueue_put.md
deleted file mode 100644
index 3503073..0000000
--- a/docs/os/core_os/mqueue/os_mqueue_put.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mqueue_put</font>
-
-```c
-int os_mqueue_put(struct os_mqueue *mq, struct os_eventq *evq, struct os_mbuf *m)
-```
-
-Adds a packet (i.e. packet header mbuf) to an mqueue. The event associated with the mqueue gets posted to the specified eventq.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `mq` | The mbuf queue to append the mbuf to. |
-| `evq` | The event queue to post an event to. |
-| `m` | The mbuf to append to the mbuf queue. |
-
-<br>
-
-#### Returned values
-
-0: success
-
-OS_EINVAL: the mbuf is not a packet header mbuf.
-
-<br>
-
-#### Example
-
-```c
-int
-my_task_rx_data_func(struct os_mbuf *om)
-{
- int rc;
-
- rc = os_mqueue_put(&rxpkt_q, &my_task_evq, om);
- if (rc != 0) {
- return -1;
- }
-
- return 0;
-}
-```
diff --git a/docs/os/core_os/msys/msys.md b/docs/os/core_os/msys/msys.md
deleted file mode 100644
index 6c3b2ca..0000000
--- a/docs/os/core_os/msys/msys.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# Msys
-
-Msys stands for "system mbufs" and is a set of API built on top of the mbuf code. The basic idea behind msys is the following. The developer can create different size mbuf pools and register them with msys. The application then allocates mbufs using the msys API (as opposed to the mbuf API). The msys code will choose the mbuf pool with the smallest mbufs that can accommodate the requested size.
-
-Let us walk through an example where the user registers three mbuf pools with msys: one with 32 byte mbufs, one with 256 and one with 2048. If the user requests an mbuf with 10 bytes, the 32-byte mbuf pool is used. If the request is for 33 bytes the 256 byte mbuf pool is used. If an mbuf data size is requested that is larger than any of the pools (say, 4000 bytes) the largest pool is used. While this behaviour may not be optimal in all cases that is the currently implemented behaviour. All this means is that the user is not guaranteed that a single mbuf can hold the requested data.
-
-The msys code will not allocate an mbuf from a larger pool if the chosen mbuf pool is empty. Similarly, the msys code will not chain together a number of smaller mbufs to accommodate the requested size. While this behaviour may change in future implementations the current code will simply return NULL. Using the above example, say the user requests 250 bytes. The msys code chooses the appropriate pool (i.e. the 256 byte mbuf pool) and attempts to allocate an mbuf from that pool. If that pool is empty, NULL is returned even though the 32 and 2048 byte pools are not empty.
-
-Note that no added descriptions on how to use the msys API are presented here (other than in the API descriptions themselves) as the msys API is used in exactly the same manner as the mbuf API. The only difference is that mbuf pools are added to msys by calling `os_msys_register().`
-
-<br>
-
-### List of Functions
-
-The functions available in msys are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_msys_get](os_msys_get.md) | Retrieve an mbuf from the system mbuf pools with the given number of bytes available in the mbuf. |
-| [os_msys_get_pkthdr](os_msys_get_pkthdr.md) | Retrieve a packet header mbuf from the system mbuf pools with the given number of bytes available for the user header in the mbuf. |
-| [os_msys_register](os_msys_register.md) | Register an mbuf pool for use as a system mbuf pool. |
-| [os_msys_reset](os_msys_reset.md) | Resets msys module. |
diff --git a/docs/os/core_os/msys/os_msys_get.md b/docs/os/core_os/msys/os_msys_get.md
deleted file mode 100644
index b69c9a0..0000000
--- a/docs/os/core_os/msys/os_msys_get.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_msys_get</font>
-
-```c
-struct os_mbuf *os_msys_get(uint16_t dsize, uint16_t leadingspace)
-```
-
-Retrieve an mbuf from the system mbuf pools with *leadingspace* bytes available in the mbuf.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| dsize | Minimum requested size of mbuf. Actual mbuf allocated may not accommodate *dsize* |
-| leadingspace | Number of bytes for leading space in mbuf (space at start of mbuf) |
-
-<br>
-
-#### Returned values
-Pointer to mbuf or NULL if no mbufs were available.
-
-<br>
-
-#### Notes
-As described in the overview section, `os_msys_get()` may return an mbuf that is smaller than dsize, meaning that the mbuf user data buffer does not have enough contiguous space to hold *dsize* bytes.
-
-This API will not return an mbuf from a larger mbuf pool if the appropriate msys mbuf pool is empty. See the overview for more information.
-
-<br>
-
-#### Example
-
-```c
- struct os_mbuf *om;
-
- /* Allocate an mbuf with hopefully at least 100 bytes in its user data buffer */
- om = os_msys_get(100, 0);
- if (!om) {
- /* No mbufs available. */
- return -1;
- }
-}
-```
-
diff --git a/docs/os/core_os/msys/os_msys_get_pkthdr.md b/docs/os/core_os/msys/os_msys_get_pkthdr.md
deleted file mode 100644
index 38a5302..0000000
--- a/docs/os/core_os/msys/os_msys_get_pkthdr.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_msys_get_pkthdr</font>
-
-```c
-struct os_mbuf *os_msys_get_pkthdr(uint16_t dsize, uint16_t user_hdr_len)
-```
-
-Retrieve a packet header mbuf from the system mbuf pools with *user_hdr_len* bytes available for the user header in the mbuf.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| dsize | Minimum requested size of mbuf. Actual mbuf allocated may not accommodate *dsize* |
-| user_hdr_len | Size, in of bytes, of user header in the mbuf |
-
-<br>
-
-#### Returned values
-Pointer to mbuf or NULL if no mbufs were available.
-
-<br>
-
-#### Notes
-The same notes apply to this API as to `os_msys_get()`.
-
-<br>
-
-#### Example
-
-```c
- struct os_mbuf *om;
- struct my_user_hdr_struct my_usr_hdr;
-
- /*
- * Allocate an mbuf with hopefully at least 100 bytes in its user data buffer
- * and that has a user header of size sizeof(struct my_user_hdr_struct)
- */
- om = os_msys_get_pkthdr(100, sizeof(struct my_user_hdr_struct));
- if (!om) {
- /* No mbufs available. */
- return -1;
- }
-}
-```
-
diff --git a/docs/os/core_os/msys/os_msys_register.md b/docs/os/core_os/msys/os_msys_register.md
deleted file mode 100644
index 4125f22..0000000
--- a/docs/os/core_os/msys/os_msys_register.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_msys_register</font>
-
-```c
-int os_msys_register(struct os_mbuf_pool *new_pool)
-```
-
-Register an mbuf pool for use as a system mbuf pool. The pool should be initialized prior to registration.
-
-<br>
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| new_pool | Pointer to mbuf pool to add to system mbuf pools |
-
-<br>
-
-#### Returned values
-0 on success; all other values indicate an error.
-
-<br>
-
-#### Example
-
-```c
- rc = os_msys_register(&g_mbuf_pool);
- assert(rc == 0);
-```
-
diff --git a/docs/os/core_os/msys/os_msys_reset.md b/docs/os/core_os/msys/os_msys_reset.md
deleted file mode 100644
index 31805fd..0000000
--- a/docs/os/core_os/msys/os_msys_reset.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_msys_reset</font>
-
-```c
-void os_msys_reset(void)
-```
-
-Resets msys module. This de-registers all pools from msys but does nothing to the pools themselves (they still exist as mbuf pools).
-
-<br>
-
-#### Arguments
-
-None
-
-<br>
-
-#### Returned values
-
-None
-
-<br>
-
-#### Example
-
-```c
- os_msys_reset();
-```
-
diff --git a/docs/os/core_os/mutex/mutex.md b/docs/os/core_os/mutex/mutex.md
deleted file mode 100644
index 961ebc5..0000000
--- a/docs/os/core_os/mutex/mutex.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Mutex
-
-
-Mutex is short for "mutual exclusion"; a mutex provides mutually exclusive access to a shared resource. A mutex provides *priority inheritance* in order to prevent *priority inversion*. Priority inversion occurs when a higher priority task is waiting on a resource owned by a lower priority task. Using a mutex, the lower priority task will inherit the highest priority of any task waiting on the mutex.
-
-
-### Description
-
-The first order of business when using a mutex is to declare the mutex globally. The mutex needs to be initialized before it is used (see the examples). It is generally a good idea to initialize the mutex before tasks start running in order to avoid a task possibly using the mutex before it is initialized.
-
-When a task wants exclusive access to a shared resource it needs to obtain the mutex by calling *os_mutex_pend*. If the mutex is currently owned by a different task (a lower priority task), the requesting task will be put to sleep and the owners priority will be elevated to the priority of the requesting task. Note that multiple tasks can request ownership and the current owner is elevated to the highest priority of any task waitin on the mutex. When the task is done using the shared resource, it needs to release the mutex by called *os_mutex_release*. There needs to be one release per call to pend. Note that nested calls to *os_mutex_pend* are allowed but there needs to be one release per pend.
-
-The following example will illustrate how priority inheritance works. In this example, the task number is the same as its priority. Remember that the lower the number, the higher the priority (i.e. priority 0 is higher priority than priority 1). Suppose that task 5 gets ownership of a mutex but is preempted by task 4. Task 4 attempts to gain ownership of the mutex but cannot as it is owned by task 5. Task 4 is put to sleep and task 5 is temporarily raised to priority 4. Before task 5 can release the mutex, task 3 runs and attempts to acquire the mutex. At this point, both task 3 and task 4 are waiting on the mutex (sleeping). Task 5 now runs at priority 3 (the highest priority of all the tasks waiting on the mutex). When task 5 finally releases the mutex it will be preempted as two higher priority tasks are waiting for it.
-
-Note that when multiple tasks are waiting on a mutex owned by another task, once the mutex is released the highest priority task waiting on the mutex is run.
-
-### Data structures
-
-```c
-struct os_mutex
-{
- SLIST_HEAD(, os_task) mu_head;
- uint8_t _pad;
- uint8_t mu_prio;
- uint16_t mu_level;
- struct os_task *mu_owner;
-};
-```
-
-| Element | Description |
-|-----------|-------------|
-| mu_head | Queue head for list of tasks waiting on mutex |
-| _pad | Padding |
-| mu_prio | Default priority of owner of mutex. Used to reset priority of task when mutex released |
-| mu_level | Call nesting level (for nested calls) |
-| mu_owner | Pointer to task structure which owns mutex |
-
-### List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_mutex_init](os_mutex_init) | Initialize the mutex. Must be called before the mutex can be used. |
-| [os_mutex_pend](os_mutex_pend) | Acquire ownership of a mutex. |
-| [os_mutex_release](os_mutex_release) | Release ownership of a mutex. |
-
diff --git a/docs/os/core_os/mutex/os_mutex_init.md b/docs/os/core_os/mutex/os_mutex_init.md
deleted file mode 100644
index 284e225..0000000
--- a/docs/os/core_os/mutex/os_mutex_init.md
+++ /dev/null
@@ -1,39 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mutex_init</font>
-
-```c
-os_error_t os_mutex_init(struct os_mutex *mu)
-```
-
-Initialize the mutex. Must be called before the mutex can be used.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *mu| Pointer to mutex |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *mu is NULL on entry.
-
-OS_OK: mutex initialized successfully.
-
-#### Notes
-
-<Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).>
-
-#### Example
-
-
-```c
-struct os_mutex g_mutex1;
-os_error_t err;
-
-err = os_mutex_init(&g_mutex1);
-assert(err == OS_OK);
-```
-
-
-
diff --git a/docs/os/core_os/mutex/os_mutex_pend.md b/docs/os/core_os/mutex/os_mutex_pend.md
deleted file mode 100644
index 2b3af83..0000000
--- a/docs/os/core_os/mutex/os_mutex_pend.md
+++ /dev/null
@@ -1,49 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mutex_pend </font>
-
-```c
-os_error_t os_mutex_pend(struct os_mutex *mu, uint32_t timeout)
-```
-
-Acquire ownership of a mutex.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *mu | Pointer to mutex |
-| timeout | Timeout, in os ticks. A value of 0 means no timeout. A value of 0xFFFFFFFF means to wait forever. |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *mu is NULL on entry.
-
-OS_OK: mutex was successfully acquired.
-
-OS_TIMEOUT: the mutex was not available within the timeout specified.
-
-OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
-
-
-#### Notes
-
-If the mutex is owned by another task and the timeout is 0 the function returns immediately with the error code OS_TIMEOUT. The calling task *does not* own the mutex when this occurs.
-
-#### Example
-
-
-
-```c
-struct os_mutex g_mutex1;
-os_error_t err;
-
-err = os_mutex_pend(&g_mutex1, 0);
-assert(err == OS_OK);
-
-/* Perform operations requiring exclusive access */
-
-err = os_mutex_release(&g_mutex1);
-assert(err == OS_OK);
-```
-
-
diff --git a/docs/os/core_os/mutex/os_mutex_release.md b/docs/os/core_os/mutex/os_mutex_release.md
deleted file mode 100644
index 356ae49..0000000
--- a/docs/os/core_os/mutex/os_mutex_release.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_mutex_release</font>
-
-```c
-os_error_t os_mutex_release(struct os_mutex *mu)
-```
-
-Release ownership of a mutex
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *mu| Pointer to mutex |
-
-#### Returned values
-OS_INVALID_PARM: returned when *mu is NULL on entry.
-
-OS_OK: mutex initialized successfully.
-
-OS_BAD_MUTEX: The mutex was not owned by the task attempting to release it.
-
-OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
-
-
-#### Example
-
-
-```c
-struct os_mutex g_mutex1;
-os_error_t err;
-
-err = os_mutex_pend(&g_mutex1, 0);
-assert(err == OS_OK);
-
-/* Perform operations requiring exclusive access */
-
-err = os_mutex_release(&g_mutex1);
-assert(err == OS_OK);
-```
-
diff --git a/docs/os/core_os/mynewt_os.md b/docs/os/core_os/mynewt_os.md
deleted file mode 100644
index c25e3cd..0000000
--- a/docs/os/core_os/mynewt_os.md
+++ /dev/null
@@ -1,166 +0,0 @@
-# Mynewt Core OS
-
-The Mynewt Core OS is a multitasking, preemptive real-time operating system combining a scheduler with typical RTOS features such as mutexes, semaphores, memory pools, etc. The Mynewt Core OS also provides a number of useful utilities such as a task watchdog, networking stack memory buffers and time management API. Each of these features is described in detail in its own section of the manual.
-
-A multitasking, preemptive operating system is one in which a number of different tasks can be instantiated and assigned a priority, with higher priority tasks running before lower priority tasks. Furthermore, if a lower priority task is running and a higher priority task wants to run, the lower priority task is halted and the higher priority task is allowed to run. In other words, the lower priority task is preempted by the higher priority task.
-
-### Why use an OS?
-You may ask yourself "why do I need a multitasking preemptive OS"? The answer may indeed be that you do not. Some applications are simple and only require a polling loop. Others are more complex and may require that certain jobs are executed in a timely manner or before other jobs are executed. If you have a simple polling loop, you cannot move on to service a job until the current job is done being serviced. With the Mynewt OS, the application developer need not worry about certain jobs taking too long or not executing in a timely fashion; the OS provides mechanisms to deal with these situations. Another benefit of using an OS is that it helps shield application developers from other application code being written; the developer does not have to worry (or has to worry less) about other application code behaving badly and causing undesirable behavior or preventing their code from executing properly. Other benefits of using an OS (and the Mynewt OS in particular) is that it also provides features that the developer would otherwise need to create on his/her own.
-
-### Core OS Features
-
-<Insert basic feature descriptions, how the various pieces fit together etc., what's special in Mynewt OS>
-
-* [Scheduler/context switching](context_switch/context_switch.md)
-* [Time](time/os_time.md)
-* [Tasks](task/task.md)
-* [Event queues/callouts](event_queue/event_queue.md)
-* [Semaphores](semaphore/semaphore.md)
-* [Mutexes](mutex/mutex.md)
-* [Memory pools](memory_pool/memory_pool.md)
-* [Heap](heap/heap.md)
-* [Mbufs](mbuf/mbuf.md)
-* [Sanity](sanity/sanity.md)
-* [Callouts](callout/callout.md)
-* [Porting OS to other platforms](porting/port_os.md)
-
-
-### Basic OS Application Creation
-Creating an application using the Mynewt Core OS is a relatively simple task. The main steps are:
-
-1. Install the basic Newt Tool structure (build structure) for your application.
-2. Create your BSP (Board Support Package).
-3. In your application `main()` function, call the `sysinit()` function to initialize
-the system and packages, perform application specific initialization, then
-wait and dispatch events from the OS default event
-queue in an infinite loop. (See [System Configuration and Initialization](/os/modules//sysinitconfig/sysinitconfig.md) for more details.)
-
-
-Initializing application modules and tasks can get somewhat complicated with RTOS's similar to Mynewt. Care must be taken that the API provided by a task are initialized prior to being called by another (higher priority) task.
-
-For example, take a simple application with two tasks (tasks 1 and 2, with task 1 higher priority than task 2). Task 2 provides an API which has a semaphore lock and this semaphore is initialized by task 2 when the task handler for task 2 is called. Task 1 is expected to call this API.
-
-Consider the sequence of events when the OS is started. The scheduler starts running and picks the highest priority task (task 1 in this case). The task handler function for task 1 is called and will keep running until it yields execution. Before yielding, code in the task 1 handler function calls the API provided by task 2. The semaphore being accessed in the task 2 API has yet to be initialized since the task 2 handler function has not had a chance to run! This will lead to undesirable behavior and will need to be addressed by the application developer. Note that the Mynewt OS does guard against internal API being called before the OS has started (they will return error) but it does not safeguard application defined objects from access prior to initialization.
-
-### Example
-
-One way to avoid initialization issues like the one described above is for the application to
-initialize the objects that are accessed by multiple tasks before it initializes the tasks with the OS.
-
-The code example shown below illustrates this concept. The application initializes system and packages, calls an application specific "task initialization" function, and dispatches events from the default event queue. The application task initialization function is responsible for initializing all the data objects that each task exposes to the other tasks. The tasks themselves are also initialized at this time (by calling `os_task_init()`).
-
-
-In the example, each task works in a ping-pong like fashion: task 1 wakes up, adds a token to semaphore 1 and then waits for a token from semaphore 2. Task 2 waits for a token on semaphore 1 and once it gets it, adds a token to semaphore 2. Notice that the semaphores are initialized by the application specific task initialization functions and not inside the task handler functions. If task 2 (being lower in priority than task 1) had called os_sem_init() for task2_sem inside task2_handler(), task 1 would have called os_sem_pend() using task2_sem before task2_sem was initialized.
-
-
-```c
-
- struct os_sem task1_sem;
- struct os_sem task2_sem;
-
- /* Task 1 handler function */
- void
- task1_handler(void *arg)
- {
- while (1) {
- /* Release semaphore to task 2 */
- os_sem_release(&task1_sem);
-
- /* Wait for semaphore from task 2 */
- os_sem_pend(&task2_sem, OS_TIMEOUT_NEVER);
- }
- }
-
- /* Task 2 handler function */
- void
- task2_handler(void *arg)
- {
- struct os_task *t;
-
- while (1) {
- /* Wait for semaphore from task1 */
- os_sem_pend(&task1_sem, OS_TIMEOUT_NEVER);
-
- /* Release task2 semaphore */
- os_sem_release(&task2_sem);
- }
- }
-
-
- /* Initialize task 1 exposed data objects */
- void
- task1_init(void)
- {
- /* Initialize task1 semaphore */
- os_sem_init(&task1_sem, 0);
- }
-
- /* Initialize task 2 exposed data objects */
- void
- task2_init(void)
- {
- /* Initialize task1 semaphore */
- os_sem_init(&task2_sem, 0);
- }
-
- /**
- * init_app_tasks
- *
- * This function performs initializations that are required before tasks run.
- *
- * @return int 0 success; error otherwise.
- */
- static int
- init_app_tasks(void)
- {
- /*
- * Call task specific initialization functions to initialize any shared objects
- * before initializing the tasks with the OS.
- */
- task1_init();
- task2_init();
-
- /*
- * Initialize tasks 1 and 2 with the OS.
- */
- os_task_init(&task1, "task1", task1_handler, NULL, TASK1_PRIO,
- OS_WAIT_FOREVER, task1_stack, TASK1_STACK_SIZE);
-
- os_task_init(&task2, "task2", task2_handler, NULL, TASK2_PRIO,
- OS_WAIT_FOREVER, task2_stack, TASK2_STACK_SIZE);
-
- return 0;
- }
-
- /**
- * main
- *
- * The main function for the application. This function initializes the system and packages,
- * calls the application specific task initialization function, then waits and dispatches
- * events from the OS default event queue in an infinite loop.
- */
- int
- main(int argc, char **arg)
- {
-
- /* Perform system and package initialization */
- sysinit();
-
- /* Initialize application specific tasks */
- init_app_tasks();
-
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
- /* main never returns */
-}
-
-```
-
-### OS Functions
-
-
-The functions available at the OS level are:
-
-* [os_started](os_started.md)
-
diff --git a/docs/os/core_os/os_init.md b/docs/os/core_os/os_init.md
deleted file mode 100644
index eaad890..0000000
--- a/docs/os/core_os/os_init.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_init</font>
-
-```no-highlight
-void os_init(void)
-```
-
-Initializes the OS. Must be called before the OS is started (i.e. os_start() is called).
-
-<br>
-
-#### Arguments
-
-None
-
-<br>
-
-#### Returned values
-None
-
-<br>
-
-#### Notes
-
-The call to os_init performs architecture and bsp initializations and initializes the idle task.
-
-This function does not start the OS, the OS time tick interrupt, or the scheduler.
diff --git a/docs/os/core_os/os_start.md b/docs/os/core_os/os_start.md
deleted file mode 100644
index cc6db5e..0000000
--- a/docs/os/core_os/os_start.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_start</font>
-
-```no-highlight
-void os_start(void)
-```
-
-Starts the OS by initializing and enabling the OS time tick and starting the scheduler.
-
-This function does not return.
-
-<br>
-
-#### Arguments
-
-None
-
-<br>
-
-#### Returned values
-None (does not return).
-
-<br>
-
-#### Notes
-
-Once os_start has been called, context is switched to the highest priority task that was initialized prior to calling os_start.
-
diff --git a/docs/os/core_os/os_started.md b/docs/os/core_os/os_started.md
deleted file mode 100644
index 5584782..0000000
--- a/docs/os/core_os/os_started.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">os_started</font>
-
-```no-highlight
-int os_started(void)
-```
-
-Returns 'true' (1) if the os has been started; 0 otherwise.
-
-<br>
-
-#### Arguments
-
-None
-
-<br>
-
-#### Returned values
-Integer value with 0 meaning the OS has not been started and 1 indicating the OS has been started (i.e. os_start() has been called).
-
diff --git a/docs/os/core_os/porting/port_bsp.md b/docs/os/core_os/porting/port_bsp.md
deleted file mode 100644
index 9e79569..0000000
--- a/docs/os/core_os/porting/port_bsp.md
+++ /dev/null
@@ -1,417 +0,0 @@
-# BSP Porting
-
-### Introduction
-
-The Apache Mynewt core repo contains support for several different boards. For
-each supported board, there is a Board Support Package (BSP) package in the
-`hw/bsp` directory. If there isn't a BSP package for your hardware, then you
-will need to make one yourself. This document describes the process of
-creating a BSP package from scratch.
-
-While creating your BSP package, the following documents will probably come in handy:
-
-* The datasheet for the MCU you have chosen.
-* The schematic of your board.
-* The information on the CPU core within your MCU if it is not included in your MCU documentation.
-
-This document is applicable to any hardware, but it will often make reference
-to a specific board as an example. Our example BSP has the following
-properties:
-
-* **Name:** `hw/bsp/myboard`
-* **MCU:** Nordic nRF52
-
-### Download the BSP package template
-
-We start by downloading a BSP package template. This template will serve as a good starting point for our new BSP.
-
-Execute the `newt pkg new` command, as below:
-
-```
-$ newt pkg new -t bsp hw/bsp/myboard
-Download package template for package type bsp.
-Package successfuly installed into /home/me/myproj/hw/bsp/myboard.
-```
-
-Our new package has the following file structure:
-
-```
-$ tree hw/bsp/myboard
-hw/bsp/myboard
-├── README.md
-├── boot-myboard.ld
-├── bsp.yml
-├── include
-│ └── myboard
-│ └── bsp.h
-├── myboard.ld
-├── myboard_debug.sh
-├── myboard_download.sh
-├── pkg.yml
-├── src
-│ ├── hal_bsp.c
-│ └── sbrk.c
-└── syscfg.yml
-
-3 directories, 11 files
-```
-
-We will be adding to this package throughout the remainder of this document.
-See [Appendix A](#appendix-a-bsp-files) for a full list of files typically
-found in a BSP package.
-
-### Create a set of Mynewt targets
-
-We'll need two [targets](../../../../os/get_started/vocabulary/#target) to test
-our BSP as we go:
-
-1. Boot loader
-2. Application
-
-A minimal application is best, since we are just interested in getting the BSP
-up and running. A good app for our purposes is
-[blinky](../../tutorials/blinky).
-
-We create our targets with the following set of newt commands:
-
-```
-newt target create boot-myboard &&
-newt target set boot-myboard app=@apache-mynewt-core/apps/boot \
- bsp=hw/bsp/myboard \
- build_profile=optimized
-
-newt target create blinky-myboard &&
-newt target set blinky-myboard app=apps/blinky \
- bsp=hw/bsp/myboard \
- build_profile=debug
-```
-
-Which generates the following output:
-```
-Target targets/boot-myboard successfully created
-Target targets/boot-myboard successfully set target.app to @apache-mynewt-core/apps/boot
-Target targets/boot-myboard successfully set target.bsp to hw/bsp/myboard
-Target targets/boot-myboard successfully set target.build_profile to optimized
-Target targets/blinky-myboard successfully created
-Target targets/blinky-myboard successfully set target.app to apps/blinky
-Target targets/blinky-myboard successfully set target.bsp to hw/bsp/myboard
-Target targets/blinky-myboard successfully set target.build_profile to debug
-```
-
-### Fill in the `bsp.yml` file
-
-The template `hw/bsp/myboard/bsp.yml` file is missing some values that need to
-be added. It also assumes certain information that may not be appropriate for
-your BSP. We need to get this file into a usable state.
-
-Missing fields are indicated by the presence of `XXX` markers. Here are the
-first several lines of our `bsp.yml` file where all the incomplete fields are
-located:
-
-```
-bsp.arch: # XXX <MCU-architecture>
-bsp.compiler: # XXX <compiler-package>
-bsp.linkerscript:
- - 'hw/bsp/myboard/myboard.ld'
- # - XXX mcu-linker-script
-bsp.linkerscript.BOOT_LOADER.OVERWRITE:
- - 'hw/bsp/myboard/myboard/boot-myboard.ld'
- # - XXX mcu-linker-script
-```
-
-So we need to specify the following:
-
-* MCU architecture
-* Compiler package
-* MCU linker script
-
-Our example BSP uses an nRF52 MCU, which implements the `cortex_m4`
-architecture. We use this information to fill in the incomplete fields:
-
-``` hl_lines="1 2 5 8"
-bsp.arch: cortex_m4
-bsp.compiler: '@apache-mynewt-core/compiler/arm-none-eabi-m4'
-bsp.linkerscript:
- - 'hw/bsp/myboard/myboard.ld'
- - '@apache-mynewt-core/hw/mcu/nordic/nrf52xxx/nrf52.ld'
-bsp.linkerscript.BOOT_LOADER.OVERWRITE:
- - 'hw/bsp/myboard/boot-myboard.ld'
- - '@apache-mynewt-core/hw/mcu/nordic/nrf52xxx/nrf52.ld'
-```
-
-Naturally, these values must be adjusted accordingly for other MCU types.
-
-### Flash map
-
-At the bottom of the `bsp.yml` file is the flash map. The flash map partitions
-the BSP's flash memory into sections called areas. Flash areas are further
-categorized into two types: 1) system areas, and 2) user areas. These two area
-types are defined below.
-
-**System areas**
-
-* Used by Mynewt core components.
-* BSP support is mandatory in most cases.
-* Use reserved names.
-
-**User areas**
-
-* Used by application code and supplementary libraries.
-* Identified by user-assigned names.
-* Have unique user-assigned numeric identifiers for access by C code.
-
-The flash map in the template `bsp.yml` file is suitable for an MCU with 512kB
-of internal flash. You may need to adjust the area offsets and sizes if your
-BSP does not have 512kB of internal flash.
-
-The system flash areas are briefly described below:
-
-| Flash area | Description |
-|----------------------------|-------------|
-| `FLASH_AREA_BOOTLOADER` | Contains the Mynewt boot loader. |
-| `FLASH_AREA_IMAGE_0` | Contains the active Mynewt application image. |
-| `FLASH_AREA_IMAGE_1` | Contains the secondary image; used for image upgrade. |
-| `FLASH_AREA_IMAGE_SCRATCH` | Used by the boot loader during image swap. |
-
-### Add the MCU dependency to `pkg.yml`
-
-A package's dependencies are listed in its `pkg.yml` file. A BSP package
-always depends on its corresponding MCU package, so let's add that dependency
-to our BSP now. The `pkg.deps` section of our `hw/bsp/myboard/pkg.yml` file
-currently looks like this:
-
-```
-pkg.deps:
- # - XXX <MCU-package>
- - '@apache-mynewt-core/kernel/os'
- - '@apache-mynewt-core/libc/baselibc'
-```
-
-Continuing with our example nRF52 BSP, we replace the marked line as follows:
-
-``` hl_lines="2"
-pkg.deps:
- - '@apache-mynewt-core/hw/mcu/nordic/nrf52xxx'
- - '@apache-mynewt-core/kernel/os'
- - '@apache-mynewt-core/libc/baselibc'
-```
-
-Again, the particulars depend on the MCU that your BSP uses.
-
-### Check the BSP linker scripts
-
-Linker scripts are a key component of the BSP package. They specify how code
-and data are arranged in the MCU's memory. Our BSP package contains two linker
-scripts:
-
-| **Filename** | **Description** |
-|-------------------|-----------------|
-| `myboard.ld` | Linker script for Mynewt application images. |
-| `boot-myboard.ld` | Linker script for the Mynewt boot loader. |
-
-First, we will deal with the application linker script. You may have noticed
-that the `bsp.linkerscript` item in `bsp.yml` actually specifies two linker
-scripts:
-
-* BSP linker script (`hw/bsp/myboard.ld`)
-* MCU linker script (`@apache-mynewt-core/hw/mcu/nordic/nrf52xxx/nrf52.ld`)
-
-Both linker scripts get used in combination when you build a Mynewt image.
-Typically, all the complexity is isolated to the MCU linker script, while the
-BSP linker script just contains minimal size and offset information. This
-makes the job of creating a BSP package much simpler.
-
-Our `myboard.ld` file has the following contents:
-
-```
-MEMORY
-{
- FLASH (rx) : ORIGIN = 0x00008000, LENGTH = 0x3a000
- RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x10000
-}
-
-/* This linker script is used for images and thus contains an image header */
-_imghdr_size = 0x20;
-```
-
-Our task is to ensure the offset (`ORIGIN`) and size (`LENGTH`) values are
-correct for the `FLASH` and `RAM` regions. Note that the `FLASH` region does
-not specify the board's entire internal flash; it only describes the area of
-the flash dedicated to containing the running Mynewt image. The bounds of the
-`FLASH` region should match those of the `FLASH_AREA_IMAGE_0` area in the BSP's
-flash map.
-
-The `_imghdr_size` is always `0x20`, so it can remain unchanged.
-
-The second linker script, `boot-myboard.ld`, is quite similar to the first.
-The important difference is the `FLASH` region: it describes the area of flash
-which contains the boot loader rather than an image. The bounds of this region
-should match those of the `FLASH_AREA_BOOTLOADER` area in the BSP's flash map.
-For more information about the Mynewt boot loader, see
-[this page](../../modules/bootloader/bootloader/).
-
-### Copy the download and debug scripts
-
-The newt command line tool uses a set of scripts to load and run Mynewt images. It is the BSP package that provides these scripts.
-
-As with the linker scripts, most of the work done by the download and debug
-scripts is isolated to the MCU package. The BSP scripts are quite simple, and
-you can likely get away with just copying them from another BSP. The template
-`myboard_debug.sh` script indicates which BSP to copy from:
-
-```
-#!/bin/sh
-
-# This script attaches a gdb session to a Mynewt image running on your BSP.
-
-# If your BSP uses JLink, a good example script to copy is:
-# repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_debug.sh
-#
-# If your BSP uses OpenOCD, a good example script to copy is:
-# repos/apache-mynewt-core/hw/bsp/rb-nano2/rb-nano2_debug.sh
-```
-
-Our example nRF52 BSP uses JLink, so we will copy the nRF52dk BSP's scripts:
-```
-cp repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_debug.sh hw/bsp/myboard/myboard_debug.sh
-cp repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_download.sh hw/bsp/myboard/myboard_download.sh
-```
-
-### Fill in BSP functions and defines
-
-There are a few particulars missing from the BSP's C code. These areas are marked with `XXX` comments to make them easier to spot. The missing pieces are summarized in the table below:
-
-| File | Description | Notes |
-|------|-------------|-------|
-| `src/hal_bsp.c` | `hal_bsp_flash_dev()` needs to return a pointer to the MCU's flash object when `id == 0`. | The flash object is defined in MCU's `hal_flash.c` file. |
-| `include/bsp/bsp.h` | Define `LED_BLINK_PIN` to the pin number of the BSP's primary LED. | Required by the blinky application. |
-
-For our nRF52 BSP, we modify these files as follows:
-
-**src/hal_bsp.c:**
-``` hl_lines="1"
-#include "mcu/nrf52_hal.h"
-```
-``` hl_lines="7"
-const struct hal_flash *
-hal_bsp_flash_dev(uint8_t id)
-{
- switch (id) {
- case 0:
- /* MCU internal flash. */
- return &nrf52k_flash_dev;
-
- default:
- /* External flash. Assume not present in this BSP. */
- return NULL;
- }
-}
-```
-
-**include/bsp/bsp.h:**
-``` hl_lines="5"
-#define RAM_SIZE 0x10000
-
-/* Put additional BSP definitions here. */
-
-#define LED_BLINK_PIN 17
-```
-
-### Add startup code
-
-Now we need to add the BSP's assembly startup code. Among other things, this
-is the code that gets executed immediately on power up, before the Mynewt OS is
-running. This code must perform a few basic tasks:
-
-* Assign labels to memory region boundaries.
-* Define some interrupt request handlers.
-* Define the `Reset_Handler` function, which:
- * Zeroes the `.bss` section.
- * Copies static data from the image to the `.data` section.
- * Starts the Mynewt OS.
-
-This file is named according to the following pattern:
-`hw/bsp/myboard/src/arch/<ARCH>/gcc_startup_<MCU>.s`
-
-The best approach for creating this file is to copy from other BSPs. If there
-is another BSP that uses the same MCU, you might be able to use most or all of
-its startup file.
-
-For our example BSP, we'll just copy the nRF52dk BSP's startup code:
-```
-$ mkdir -p hw/bsp/myboard/src/arch/cortex_m4
-$ cp repos/apache-mynewt-core/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52.s hw/bsp/myboard/src/arch/cortex_m4/
-```
-
-### Satisfy MCU requirements
-
-The MCU package probably requires some build-time configuration. Typically, it
-is the BSP which provides this configuration. For example, many MCU packages
-depend on the `cmsis-core` package, which expects the BSP to provide a header
-file called `bsp/cmsis_nvic.h`. Completing this step will likely involve some
-trial and error as each unmet requirement gets reported as a build error.
-
-Our example nRF52 BSP requires the following changes:
-
-*1)* The nRF52 MCU package uses `cmsis-core`, so for our example we will copy
-the nRF52dk BSP's `cmsis_nvic.h` file to our BSP:
-
-```
-$ cp repos/apache-mynewt-core/hw/bsp/nrf52dk/include/bsp/cmsis_nvic.h hw/bsp/myboard/include/bsp/
-```
-
-*2)* Macro indicating MCU type. We add this to our BSP's `pkg.yml` file:
-
-``` hl_lines="2"
-pkg.cflags:
- - '-DNRF52'
-```
-
-*3)* Enable exactly one low-frequency timer setting in our BSP's `syscfg.yml`
-file. This is required by the nRF51 and nRF52 MCU packages:
-
-``` hl_lines="3"
-# Settings this BSP overrides.
-syscfg.vals:
- XTAL_32768: 1
-```
-
-### Test it
-
-Now it's finally time to test the BSP package. Build and load your boot and blinky targets as follows:
-
-```
-$ newt build boot-myboard
-$ newt load boot-myboard
-$ newt run blinky-myboard 0
-```
-
-If everything is correct, the blinky app should successfully build, and you should be presented with a gdb prompt. Type `c <enter>` (continue) to see your board's LED blink.
-
-### Appendix A: BSP files
-
-The table below lists the files required by all BSP packages. The naming scheme assumes a BSP called "myboard".
-
-| **File Path Name** | **Description** |
-|-----------|-------------|
-| `pkg.yml` | Defines a Mynewt package for the BSP. |
-| `bsp.yml` | Defines BSP-specific settings. |
-| `include/bsp/bsp.h` | Contains additional BSP-specific settings. |
-| `src/hal_bsp.c` | Contains code to initialize the BSP's peripherals. |
-| `src/sbrk.c` | Low level heap management required by `malloc()`. |
-| `src/arch/<ARCH>/gcc_startup_myboard.s` | Startup assembly code to bring up Mynewt |
-| `myboard.ld` | A linker script providing the memory map for a Mynewt application. |
-| `boot-myboard.ld` | A linker script providing the memory map for the Mynewt bootloader. |
-| `myboard_download.sh` | A bash script to download code onto your platform. |
-| `myboard_debug.sh` | A bash script to initiate a gdb session with your platform. |
-
-A BSP can also contain the following optional files:
-
-| **File Path Name** | **Description** |
-|-----------|-------------|
-| `split-myboard.ld` | A linker script providing the memory map for the "application" half of a [split image](../../modules/split/split/). |
-| `no-boot-myboard.ld` | A linker script providing the memory map for your bootloader |
-| `src/arch/<ARCH>/gcc_startup_myboard_split.s` | Startup assembly code to bring up the "application" half of a [split image](../../modules/split/split/). |
-| `myboard_download.cmd` | An MSDOS batch file to download code onto your platform; required for Windows support. |
-| `myboard_debug.cmd` | An MSDOS batch file to intiate a gdb session with your platform; required for Windows support. |
-
diff --git a/docs/os/core_os/porting/port_cpu.md b/docs/os/core_os/porting/port_cpu.md
deleted file mode 100644
index be77fde..0000000
--- a/docs/os/core_os/porting/port_cpu.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Porting Mynewt to a new CPU Architecture
-
-A new CPU architecture typically requires the following:
-
-* A new compiler
-* New architecture-specific code for the OS
-* Helper libraries to help others porting to the same architecture
-
-These are discussed below:
-
-### Create A New Compiler
-
-NOTE: Newt does not automatically install the compilers require to build all platforms. Its up to the user using their local machines package manager to install the compilers. The step described here just registers the compiler with newt.
-
-Create a new directory (named after the compiler you are adding). Copy the `pkg.yml` file from another compiler.
-
-Edit the `pkg.yml` file and change the configuration attributes to match your compiler. Most are self-explanatory paths to different compiler and linker tools. There are a few configuration attributes worth noting.
-
-| **Configuration Attributes** | **Description** |
-|-----------|-------------|
-| pkg.keywords | Specific keywords to help others search for this using newt |
-| compiler.flags.default | default compiler flags for this architecture |
-| compiler.flags.optimized | additional flags when the newt tool builds an optimized image |
-| compiler.flags.debug | additional flags when the newt tool builds a debug image|
-
-### Implement Architecture-specific OS code
-
-There are several architecture-specific code functions that are required when implementing a new architecture. You can find examples in the `sim` architecture within Mynewt.
-
-When porting to a new CPU architecture, use the existing architectures as samples when writing your implementation.
-
-Please contact the Mynewt development list for help and advice portingto new MCU.
-
diff --git a/docs/os/core_os/porting/port_mcu.md b/docs/os/core_os/porting/port_mcu.md
deleted file mode 100644
index 8fe5fbf..0000000
--- a/docs/os/core_os/porting/port_mcu.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Porting Mynewt to a new MCU
-
-Porting Mynewt to a new MCU is not a difficult task if the core CPU architectures is already supported.
-
-The depth of work depends on the amount of HAL (Hardware Abstraction Layer) support you need and provide in your port.
-
-To get started:
-
-* Create a `hw/mcu/mymcu` directory where `mymcu` is the MCU you are porting to. Replace the name `mymcu` with a description of the MCU you are using.
-* Create a `hw/mcu/mymcu/variant` directory where the variant is the specific variant of the part you are usuing. Many MCU parts have variants with different capabilities (RAM, FLASH etc) or different pinouts. Replace `variant` with a description of the variant of the part you are using.
-* Create a `hw/mcu/mymcu/variant/pkg.yml` file. Copy from another mcu and fill out the relevant information
-* Create `hw/mcu/mymcu/variant/include`,`hw/mcu/mymcu/variant/include/mcu`, and
-`hw/mcu/mymcu/variant/src` directories to contain the code for your mcu.
-
-At this point there are two main tasks to complete.
-
-* Implement any OS-specific code required by the OS
-* Implement the HAL functionality that you are looking for
-
-Please contact the Mynewt development list for help and advice porting to new MCU.
-
diff --git a/docs/os/core_os/porting/port_os.md b/docs/os/core_os/porting/port_os.md
deleted file mode 100644
index ff958f3..0000000
--- a/docs/os/core_os/porting/port_os.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Porting Mynewt OS
-
-This chapter describes how to adapt the Mynewt OS to different platforms.
-
-### Description
-
-The Mynewt OS is a complete multi-tasking environment with scheduler, time
-control, buffer management, and synchronization objects. it also includes
-libraries and services like console, command shell, image manager,
-bootloader, and file systems etc.
-
-The majority of this software is platform independent and requires no
-intervention to run on your platform, but some of the components require
-support from the underlying platform.
-
-The platform dependency of these components can fall into several categories:
-
-* **CPU Core Dependencies** -- Specific code or
-configuration to operate the CPU core within your target platform
-* **MCU Dependencies** -- Specific code or configuration to operate the MCU or
-SoC within your target platform
-* **BSP Dependencies** -- Specific code or configuration to accommodate the
-specific layout and functionality of your target platform
-
-### Board Support Package (BSP) Dependency
-
-With all of the functionality provided by the core, MCU, and MCU HAL (Hardware Abstraction Layer), there are still some things that must be specified for your particular system. This
-is provided in Mynewt to allow you the flexibility to design for the exact
-functionality, peripherals and features that you require in your product.
-
-In Mynewt, these settings/components are included in a Board Support Package
-(BSP). The BSP contains the information specific to running Mynewt on a target
-platform or hardware board. Mynewt supports some common open source hardware as well
-as the development boards for some common MCUs. These development systems
-might be enough for you to get your prototype up and running, but when building
-a product you are likely going to have your own board which is slightly different
-from those already supported by Mynewt.
-
-For example, you might decide on your system that 16 Kilobytes of flash space
-in one flash device is reserved for a flash file system. Or on your system
-you may decide that GPIO pin 5 of the MCU is connected to the system LED. Or
-you may decide that the OS Tick (the underlying time source for the OS) should
-run slower than the defaults to conserve battery power. These types of
-behaviors are specified in the BSP.
-
-The information provided in the BSP (what you need to specify to get a
-complete executable) can vary depending on the MCU and its underlying core
-architecture. For example, some MCUs have dedicated pins for UART, SPI etc,
-so there is no configuration required in the BSP when using these peripherals.
-However some MCUs have a pin multiplexor that allows the UART to be mapped to
-several different pins. For these MCUs, the BSP must specify if and where
-the UART pins should appear to match the hardware layout of your system.
-
-* If your BSP is already supported my Mynewt, there is no additional BSP work involved in porting to your platform. You need only to set the `bsp` attribute in your Mynewt target using the [newt command tool](../../../../newt/newt_intro).
-* If your BSP is not yet supported by Mynewt, you can add support following the instructions on [how to add BSP support to Mynewt](port_bsp.md)
-
-### MCU Dependency
-
-Some OS code depends on the MCU or SoC that the system contains. For example, the MCU may specify the potential memory map of the system - where code and data can reside.
-
-* If your MCU is already supported my Mynewt, there is no additional MCU work involved in porting to your platform. You need only to set the `arch` attribute in your Mynewt target using the [newt command tool](../../../../newt/newt_intro).
-* If your MCU is not yet supported by Mynewt, you can add support following the instructions on[how to add MCU support to Mynewt](port_mcu.md)
-
-
-### MCU HAL
-
-Mynewt's architecture supports a hardware abstraction layer (HAL) for common on or off-chip MCU peripherals such as GPIO, UARTs, flash memory etc. Even if your MCU is supported for the core OS, you may find that you need to implement the HAL functionality for a new peripheral. For a description of the HAL abstraction and implementation information,
-see the [HAL API](../../modules/hal/hal.md)
-
-### CPU Core Dependency
-
-Some OS code depends on the CPU core that your system is using. For example, a given CPU core has a specific assembly language instruction set, and may require special cross compiler or compiler settings to use the appropriate instruction set.
-
-* If your CPU architecture is already supported my Mynewt, there is no CPU core work involved in porting to your platform. You need only to set the `arch` and `compiler` attributes in your Mynewt target using the [newt command tool](../../../../newt/newt_intro).
-* If your CPU architecture is not supported by Mynewt, you can add support following the instructions on [how to add CPU architecture support to Mynewt](port_cpu.md)
-
diff --git a/docs/os/core_os/sanity/os_sanity_check_init.md b/docs/os/core_os/sanity/os_sanity_check_init.md
deleted file mode 100644
index 0678541..0000000
--- a/docs/os/core_os/sanity/os_sanity_check_init.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_sanity_check_init</font>
-
-```c
-int os_sanity_check_init(struct os_sanity_check *sc)
-```
-Initialize the sanity check pointed to by `sc`. Sets default values, and ensures
-memory is cleared out.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `sc` | Pointer to sanity check |
-
-<br>
-#### Returned values
-
-`OS_OK`: sanity check initialization is successful
-
-All other error codes indicate an error.
-
-<br>
-#### Example
-
-```c
- int rc;
-
- rc = os_sanity_task_check_init(&my_sanity_check);
- assert(rc == OS_OK);
-
-```
-
diff --git a/docs/os/core_os/sanity/os_sanity_check_register.md b/docs/os/core_os/sanity/os_sanity_check_register.md
deleted file mode 100644
index 7dd2f9b..0000000
--- a/docs/os/core_os/sanity/os_sanity_check_register.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_sanity_check_register</font>
-
-```c
-int os_sanity_check_register(struct os_sanity_check *sc)
-```
-Register the sanity check pointed to by `sc` with the sanity task. After registration
-the sanity task will check this sanity check with every run of the sanity task.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `sc` | Pointer to sanity check |
-
-<br>
-#### Returned values
-
-`OS_OK`: sanity check successfully registered
-
-All other error codes indicate an error.
-
-<br>
-#### Example
-
-```c
- int rc;
-
- rc = os_sanity_check_register(&my_sc);
- assert(rc == OS_OK);
-
-```
-
diff --git a/docs/os/core_os/sanity/os_sanity_check_reset.md b/docs/os/core_os/sanity/os_sanity_check_reset.md
deleted file mode 100644
index 884b005..0000000
--- a/docs/os/core_os/sanity/os_sanity_check_reset.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_sanity_check_reset</font>
-
-```c
-int os_sanity_check_reset(struct os_sanity_check *sc)
-```
-Reset the sanity check pointed to by sc. This tells the sanity task that
-this sanity check is considered valid for another `sc_checkin_itvl` time
-ticks.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `sc` | Pointer to sanity check |
-
-<br>
-#### Returned values
-
-`OS_OK`: sanity check reset successful
-
-All other error codes indicate an error.
-
-<br>
-#### Example
-
-```c
- int rc;
-
- rc = os_sanity_check_reset(&my_sc);
- assert(rc == OS_OK);
-
-```
-
diff --git a/docs/os/core_os/sanity/os_sanity_task_checkin.md b/docs/os/core_os/sanity/os_sanity_task_checkin.md
deleted file mode 100644
index 0053f1e..0000000
--- a/docs/os/core_os/sanity/os_sanity_task_checkin.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_sanity_task_checkin</font>
-
-```c
-int os_sanity_task_checkin(struct os_task *t)
-```
-Used by a task to check in to the sanity task. This informs the sanity task that
-*task* is still alive and working normally.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `t` | Pointer to task |
-
-<br>
-#### Returned values
-
-`OS_OK`: sanity check-in successful
-
-All other error codes indicate an error.
-
-<br>
-#### Example
-
-```c
- int rc;
-
- rc = os_sanity_task_checkin(&my_task);
- assert(rc == OS_OK);
-
-```
-
diff --git a/docs/os/core_os/sanity/sanity.md b/docs/os/core_os/sanity/sanity.md
deleted file mode 100644
index fd52d62..0000000
--- a/docs/os/core_os/sanity/sanity.md
+++ /dev/null
@@ -1,189 +0,0 @@
-# Sanity
-
-The Sanity task is a software watchdog task, which runs periodically to check
-system state, and ensure that everything is still operating properly.
-
-In a typical system design, there are multiple stages of watchdog:
-
-* Internal Watchdog
-
-* External Watchdog
-
-* Sanity Watchdog
-
-The _Internal Watchdog_ is typically an MCU watchdog, which is tickled in
-the core of the OS. The internal watchdog is tickled frequently, and is
-meant to be an indicator the OS is running.
-
-The _External Watchdog_ is a watchdog that's typically run slower. The
-purpose of an external watchdog is to provide the system with a hard reset
-when it has lost its mind.
-
-The _Sanity Watchdog_ is the least frequently run watchdog, and is meant as
-an application watchdog.
-
-This document is about the operation of the Mynewt Sanity Watchdog.
-
-## Description
-
-### Sanity Task
-
-Mynewt OS uses the OS Idle task to check sanity. The `SANITY_INTERVAL` syscfg setting specifies the interval in seconds to perform the sanity checks.
-
-By default, every operating system task provides the frequency it will
-check in with the sanity task, with the `sanity_itvl` parameter in the
-`os_task_init()` function:
-
-```c
-int os_task_init(struct os_task *t, char *name, os_task_func_t func,
- void *arg, uint8_t prio, os_time_t sanity_itvl, os_stack_t *bottom,
- uint16_t stack_size);
-```
-
-`sanity_itvl` is the time in OS time ticks that the task being created
-must register in with the sanity task.
-
-### Checking in with Sanity Task
-
-The task must then register in with the sanity task every `sanity_itvl`
-seconds. In order to do that, the task should call the `os_sanity_task_checkin`
-function, which will reset the sanity check associated with this task.
-Here is an example of a task that uses a callout to checkin with the
-sanity task every 50 seconds:
-
-```c
-#define TASK1_SANITY_CHECKIN_ITVL (50 * OS_TICKS_PER_SEC)
-struct os_eventq task1_evq;
-
-static void
-task1(void *arg)
-{
- struct os_task *t;
- struct os_event *ev;
- struct os_callout c;
-
- /* Get current OS task */
- t = os_sched_get_current_task();
-
- /* Initialize the event queue. */
- os_eventq_init(&task1_evq);
-
- /* Initialize the callout */
- os_callout_init(&c, &task1_evq, NULL);
-
- /* reset the callout to checkin with the sanity task
- * in 50 seconds to kick off timing.
- */
- os_callout_reset(&c, TASK1_SANITY_CHECKIN_ITVL);
-
- while (1) {
- ev = os_eventq_get(&task1_evq);
-
- /* The sanity timer has reset */
- if (ev->ev_arg == &c) {
- os_sanity_task_checkin(t);
- } else {
- /* not expecting any other events */
- assert(0);
- }
- }
-
- /* Should never reach */
- assert(0);
-}
-```
-
-### Registering a Custom Sanity Check
-
-If a particular task wants to further hook into the sanity framework to
-perform other checks during the sanity task's operation, it can do so by
-registering a `struct os_sanity_check` using the `os_sanity_check_register`
-function.
-
-```c
-static int
-mymodule_perform_sanity_check(struct os_sanity_check *sc, void *arg)
-{
- /* Perform your checking here. In this case, we check if there
- * are available buffers in mymodule, and return 0 (all good)
- * if true, and -1 (error) if not.
- */
- if (mymodule_has_buffers()) {
- return (0);
- } else {
- return (-1);
- }
-}
-
-static int
-mymodule_register_sanity_check(void)
-{
- struct os_sanity_check sc;
-
- os_sanity_check_init(&sc);
- /* Only assert() if mymodule_perform_sanity_check() fails 50
- * times. SANITY_TASK_INTERVAL is defined by the user, and
- * is the frequency at which the sanity_task runs in seconds.
- */
- OS_SANITY_CHECK_SETFUNC(&sc, mymodule_perform_sanity_check, NULL,
- 50 * SANITY_TASK_INTERVAL);
-
- rc = os_sanity_check_register(&sc);
- if (rc != 0) {
- goto err;
- }
-
- return (0);
-err:
- return (rc);
-}
-```
-
-In the above example, every time the custom sanity check
-`mymodule_perform_sanity_check` returns successfully (0),
-the sanity check is reset. In the `OS_SANITY_CHECK_SETFUNC` macro,
-the sanity checkin interval is specified as 50 * SANITY_TASK_INTERVAL
-(which is the interval at which the sanity task runs.) This means
-that the `mymodule_perform_sanity_check()` function needs to fail
-50 times consecutively before the sanity task will crash the system.
-
-**TIP:** When checking things like memory buffers, which can be temporarily
-be exhausted, it's a good idea to have the sanity check fail multiple
-consecutive times before crashing the system. This will avoid crashing
-for temporary failures.
-
-## Data structures
-
-### OS Sanity Check
-
-```c
-struct os_sanity_check {
- os_time_t sc_checkin_last;
- os_time_t sc_checkin_itvl;
- os_sanity_check_func_t sc_func;
- void *sc_arg;
-
- SLIST_ENTRY(os_sanity_check) sc_next;
-};
-```
-
-
-| **Element** | **Description** |
-|-----------|-------------|
-| `sc_checkin_last` | The last time this sanity check checked in with the sanity task, in OS time ticks. |
-| `sc_checkin_itvl` | How frequently the sanity check is supposed to check in with the sanity task, in OS time ticks. |
-| `sc_func` | If not `NULL`, call this function when running the sanity task. If the function returns 0, reset the sanity check. |
-| `sc_arg` | Argument to pass to `sc_func` when calling it. |
-| `sc_next` | Sanity checks are chained in the sanity task when `os_sanity_check_register()` is called. |
-
-
-## List of Functions
-
-The functions available in sanity are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_sanity_check_init](os_sanity_check_init.md) | Initialize the given sanity check. |
-| [os_sanity_check_register](os_sanity_check_register.md) | Register the given sanity check with the sanity task. |
-| [os_sanity_check_reset](os_sanity_check_reset.md) | Reset the given sanity check. |
-| [os_sanity_task_checkin](os_sanity_task_checkin.md) | Informs the sanity task that the given task is still alive and working normally. |
diff --git a/docs/os/core_os/semaphore/os_sem_init.md b/docs/os/core_os/semaphore/os_sem_init.md
deleted file mode 100644
index 7a17798..0000000
--- a/docs/os/core_os/semaphore/os_sem_init.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_sem_init</font>
-
-```c
-os_error_t os_sem_init(struct os_sem *sem, uint16_t tokens)
-```
-
-Initialize a semaphore with a given number of tokens. Should be called before the semaphore is used.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *sem | Pointer to semaphore |
-| tokens | Initial number of tokens allocated to semaphore |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *sem is NULL on entry.
-
-OS_OK: semaphore initialized successfully.
-
-#### Notes
-
-<Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).>
-
-#### Example
-
-The following example shows how to initialize a semaphore used for exclusive access.
-
-```c
-struct os_sem g_os_sem;
-os_error_t err;
-
-err = os_sem_init(&g_os_sem, 1);
-assert(err == OS_OK);
-```
-
-
diff --git a/docs/os/core_os/semaphore/os_sem_pend.md b/docs/os/core_os/semaphore/os_sem_pend.md
deleted file mode 100644
index 9ccf8bd..0000000
--- a/docs/os/core_os/semaphore/os_sem_pend.md
+++ /dev/null
@@ -1,45 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sem_pend </font>
-
-```c
-os_error_t os_sem_pend(struct os_sem *sem, uint32_t timeout)
-```
-
-Wait for a semaphore for a given amount of time.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *sem | Pointer to semaphore |
-| timeout | Amount of time, in os ticks, to wait for semaphore. A value of 0 means no wait. A value of 0xFFFFFFFF means wait forever. |
-
-#### Returned values
-
-OS_INVALID_PARM: returned when *sem is NULL on entry.
-
-OS_OK: semaphore acquired successfully.
-
-OS_TIMEOUT: the semaphore was not available within the timeout specified.
-
-OS_NOT_STARTED: Attempt to release a semaphore before os started.
-
-#### Notes
-
-If a timeout of 0 is used and the function returns OS_TIMEOUT, the semaphore was not available and was not acquired. No release of the semaphore should occur and the calling task does not own the semaphore.
-
-#### Example
-
-```c
-struct os_sem g_os_sem;
-os_error_t err;
-
-err = os_sem_pend(&g_os_sem, OS_TIMEOUT_NEVER);
-assert(err == OS_OK);
-
-/* Perform operations requiring semaphore lock */
-
-err = os_sem_release(&g_os_sem);
-assert(err == OS_OK);
-
-```
-
diff --git a/docs/os/core_os/semaphore/os_sem_release.md b/docs/os/core_os/semaphore/os_sem_release.md
deleted file mode 100644
index 3cb31f9..0000000
--- a/docs/os/core_os/semaphore/os_sem_release.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sem_release </font>
-
-```c
-os_error_t os_sem_release(struct os_sem *sem)
-```
-
-Release a semaphore that you are holding. This adds a token to the semaphore.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *sem | Pointer to semaphore |
-
-#### Returned values
-
-OS_NOT_STARTED: Called before os has been started.
-
-OS_INVALID_PARM: returned when *sem is NULL on entry.
-
-OS_OK: semaphore released successfully.
-
-#### Notes
-
-
-#### Example
-
-```c
-struct os_sem g_os_sem;
-os_error_t err;
-
-err = os_sem_pend(&g_os_sem, OS_TIMEOUT_NEVER);
-assert(err == OS_OK);
-
-/* Perform operations requiring semaphore lock */
-
-err = os_sem_release(&g_os_sem);
-assert(err == OS_OK);
-```
diff --git a/docs/os/core_os/semaphore/semaphore.md b/docs/os/core_os/semaphore/semaphore.md
deleted file mode 100644
index 9bcff62..0000000
--- a/docs/os/core_os/semaphore/semaphore.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Semaphore
-
-A semaphore is a structure used for gaining exclusive access (much like a mutex), synchronizing task operations and/or use in a "producer/consumer" roles. Semaphores like the ones used by the myNewt OS are called "counting" semaphores as they are allowed to have more than one token (explained below).
-
-
-### Description
-
-A semaphore is a fairly simple construct consisting of a queue for waiting tasks and the number of tokens currently owned by the semaphore. A semaphore can be obtained as long as there are tokens in the semaphore. Any task can add tokens to the semaphore and any task can request the semaphore, thereby removing tokens. When creating the semaphore, the initial number of tokens can be set as well.
-
-When used for exclusive access to a shared resource the semaphore only needs a single token. In this case, a single task "creates" the semaphore by calling *os_sem_init* with a value of one (1) for the token. When a task desires exclusive access to the shared resource it requests the semaphore by calling *os_sem_pend*. If there is a token the requesting task will acquire the semaphore and continue operation. If no tokens are available the task will be put to sleep until there is a token. A common "problem" with using a semaphore for exclusive access is called *priority inversion*. Consider the following scenario: a high and low priority task both share a resource which is locked using a semaphore. If the low priority task obtains the semaphore and then the high priority task requests the semaphore, the high priority task is now blocked until the low priority task releases the semaphore. Now suppose that there are tasks between the low priority task and the high priority task that want to run. These tasks will preempt the low priority task which owns the semaphore. Thus, the high priority task is blocked waiting for the low priority task to finish using the semaphore but the low priority task cannot run since other tasks are running. Thus, the high priority tasks is "inverted" in priority; in effect running at a much lower priority as normally it would preempt the other (lower priority) tasks. If this is an issue a mutex should be used instead of a semaphore.
-
-Semaphores can also be used for task synchronization. A simple example of this would be the following. A task creates a semaphore and initializes it with no tokens. The task then waits on the semaphore, and since there are no tokens, the task is put to sleep. When other tasks want to wake up the sleeping task they simply add a token by calling *os_sem_release*. This will cause the sleeping task to wake up (instantly if no other higher priority tasks want to run).
-
-The other common use of a counting semaphore is in what is commonly called a "producer/consumer" relationship. The producer adds tokens (by calling *os_sem_release*) and the consumer consumes them by calling *os_sem_pend*. In this relationship, the producer has work for the consumer to do. Each token added to the semaphore will cause the consumer to do whatever work is required. A simple example could be the following: every time a button is pressed there is some work to do (ring a bell). Each button press causes the producer to add a token. Each token consumed rings the bell. There will exactly the same number of bell rings as there are button presses. In other words, each call to *os_sem_pend* subtracts exactly one token and each call to *os_sem_release* adds exactly one token.
-
-### Data structures
-
-```c
-struct os_sem
-{
- SLIST_HEAD(, os_task) sem_head; /* chain of waiting tasks */
- uint16_t _pad;
- uint16_t sem_tokens; /* # of tokens */
-};
-```
-
-| Element | Description |
-|-----------|-------------|
-| sem_head | Queue head for list of tasks waiting on semaphore |
-| _pad | Padding for alignment |
-| sem_tokens | Current number of tokens |
-
-### List of Functions
-
-
-The functions available in semaphore are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_sem_init](os_sem_init) | Initialize a semaphore with a given number of tokens. |
-| [os_sem_pend](os_sem_pend) | Wait for a semaphore for a given amount of time. |
-| [os_sem_release](os_sem_release) | Release a semaphore that you are holding. This adds a token to the semaphore. |
-
-
diff --git a/docs/os/core_os/task/os_task_count.md b/docs/os/core_os/task/os_task_count.md
deleted file mode 100644
index 58524c4..0000000
--- a/docs/os/core_os/task/os_task_count.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_task_count</font>
-
-```c
-uint8_t os_task_count(void);
-```
-Returns the number of tasks that have been created.
-
-<br>
-#### Arguments
-
-None
-
-<br>
-#### Returned values
-
-unsigned 8-bit integer representing number of tasks created
-
-<br>
-#### Example
-
-```c
-
- uint8_t num_tasks;
-
- num_tasks = os_task_count();
-```
-
-
diff --git a/docs/os/core_os/task/os_task_info_get_next.md b/docs/os/core_os/task/os_task_info_get_next.md
deleted file mode 100644
index d1e5759..0000000
--- a/docs/os/core_os/task/os_task_info_get_next.md
+++ /dev/null
@@ -1,61 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_task_info_get_next</font>
-
-```c
-struct os_task *os_task_info_get_next(const struct os_task *prev, struct os_task_info *oti);
-```
-Populates the os task info structure pointed to by *oti* with task information.
-The task populating the *oti* structure is either the first task on the task
-list if *prev* is NULL, or the next task in the task list (the next pointer of
-*prev*).
-
-If there are no tasks initialized, NULL is returned. Otherwise, the task
-structure used to populate *oti* is returned.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| prev | Pointer to previous task in task list. If NULL, use first task on list |
-| oti | Pointer to `os_task_info` structure where task information will be stored |
-
-<br>
-#### Returned values
-
-Returns a pointer to the os task structure that was used to populate the task
-information structure. NULL means that no tasks were created.
-
-<br>
-#### Example
-
-```c
-
-void
-get_task_info(void)
-{
- struct os_task *prev_task;
- struct os_task_info oti;
-
- console_printf("Tasks: \n");
- prev_task = NULL;
- while (1) {
- prev_task = os_task_info_get_next(prev_task, &oti);
- if (prev_task == NULL) {
- break;
- }
-
- console_printf(" %s (prio: %u, tid: %u, lcheck: %lu, ncheck: %lu, "
- "flags: 0x%x, ssize: %u, susage: %u, cswcnt: %lu, "
- "tot_run_time: %lums)\n",
- oti.oti_name, oti.oti_prio, oti.oti_taskid,
- (unsigned long)oti.oti_last_checkin,
- (unsigned long)oti.oti_next_checkin, oti.oti_flags,
- oti.oti_stksize, oti.oti_stkusage, (unsigned long)oti.oti_cswcnt,
- (unsigned long)oti.oti_runtime);
-
- }
-}
-
-```
-
-
diff --git a/docs/os/core_os/task/os_task_init.md b/docs/os/core_os/task/os_task_init.md
deleted file mode 100644
index a8329be..0000000
--- a/docs/os/core_os/task/os_task_init.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_task_init</font>
-
-```c
-int os_task_init(struct os_task *t, char *name, os_task_func_t func, void *arg,
- uint8_t prio, os_time_t sanity_itvl, os_stack_t *stack_bottom,
- uint16_t stack_size)
-```
-
-Called to create a task. This adds the task object to the list of ready to run
-tasks.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| t | Pointer to task |
-| name | Task name |
-| func | Task function |
-| arg | Generic argument to pass to task |
-| prio | Priority of task |
-| sanity_itvl | The interval at which the sanity task will check to see if this task is sill alive |
-| stack_bottom | Pointer to bottom of stack. |
-| stack_size | The size of the stack. NOTE: this is not in bytes! It is the number of `os_stack_t` elements allocated (generally 32-bits each) |
-
-<br>
-#### Returned values
-
-OS_OK: task initialization successful.
-
-All other error codes indicate an internal error.
-
-<br>
-#### Example
-
-```c
-
- /* Create the task */
- int rc;
-
- os_stack_t my_task_stack[MY_STACK_SIZE];
-
- rc = os_task_init(&my_task, "my_task", my_task_func, NULL, MY_TASK_PRIO,
- OS_WAIT_FOREVER, my_task_stack, MY_STACK_SIZE);
- assert(rc == OS_OK);
-```
-
-
diff --git a/docs/os/core_os/task/os_task_remove.md b/docs/os/core_os/task/os_task_remove.md
deleted file mode 100644
index 02af47c..0000000
--- a/docs/os/core_os/task/os_task_remove.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> os_task_remove</font>
-
-```c
-int os_task_remove(struct os_task *t)
-```
-Removes a task, `t`, from the task list. A task cannot be removed when it is in one of the following states:
-
-* It is running - a task cannot remove itself.
-* It has not been initialized.
-* It is holding a lock on a semphore or mutex.
-* It is suspended waiting on a lock (semaphore or mutex) or for an event on an event queue.
-
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `t` | Pointer to the `os_task` structure for the task to be removed |
-
-<br>
-#### Returned values
-`OS_OK`: Task `t` is removed sucessfully.
-<br>`OS_INVALID_PARM`: Task `t` is the calling task. A task cannot remove itself.
-<br>`OS_NOT_STARTED`: Task `t` is not initialized.
-<br>`OS_EBUSY`: Task `t` is either holding a lock or suspended waiting for a lock or an event.
-<br>
-#### Example
-
-```c
-
-struct os_task worker_task;
-
-int
-remove_my_worker_task(void)
-{
- /* Add error checking code to ensure task can removed. */
-
- /* Call os_task_remove to remove the worker task */
- rc = os_task_remove(&worker_task);
- return rc;
-}
-```
-
diff --git a/docs/os/core_os/task/task.md b/docs/os/core_os/task/task.md
deleted file mode 100644
index 81d7422..0000000
--- a/docs/os/core_os/task/task.md
+++ /dev/null
@@ -1,229 +0,0 @@
-# Task
-
-A task, along with the scheduler, forms the basis of the Mynewt OS. A task
-consists of two basic elements: a task stack and a task function. The task
-function is basically a forever loop, waiting for some "event" to wake it up.
-There are two methods used to signal a task that it has work to do: event queues
-and semaphores (see the appropriate manual sections for descriptions of these
-features).
-
-The Mynewt OS is a multi-tasking, preemptive OS. Every task is assigned a task
-priority (from 0 to 255), with 0 being the highest priority task. If a higher
-priority task than the current task wants to run, the scheduler preempts the
-currently running task and switches context to the higher priority task. This is
-just a fancy way of saying that the processor stack pointer now points to the
-stack of the higher priority task and the task resumes execution where it left
-off.
-
-Tasks run to completion unless they are preempted by a higher priority task. The
-developer must insure that tasks eventually "sleep"; otherwise lower priority
-tasks will never get a chance to run (actually, any task lower in priority than
-the task that never sleeps). A task will be put to sleep in the following cases:
-it puts itself to sleep using `os_time_delay()`, it waits on an event queue
-which is empty or attempts to obtain a mutex or a semaphore that is currently
-owned by another task.
-
-Note that other sections of the manual describe these OS features in more
-detail.
-
-## Description
-
-In order to create a task two data structures need to be defined: the task
-object (struct os_task) and its associated stack. Determining the stack size can
-be a bit tricky; generally developers should not declare large local variables
-on the stack so that task stacks can be of limited size. However, all
-applications are different and the developer must choose the stack size
-accordingly. It is recommended to use `OS_TASK_STACK_DEFINE` macro to create a stack
-as this macro assures correct alignment.
-NOTE: be careful when declaring your stack! The stack is in units
-of `os_stack_t` sized elements (generally 32-bits). Looking at the example given
-below and assuming `os_stack_t` is defined to be a 32-bit unsigned value,
-"my_task_stack" will use 256 bytes.
-
-A task must also have an associated "task function". This is the function that
-will be called when the task is first run. This task function should never
-return!
-
-In order to inform the Mynewt OS of the new task and to have it added to the
-scheduler, the `os_task_init()` function is called. Once `os_task_init()` is
-called, the task is made ready to run and is added to the active task list. Note
-that a task can be initialized (started) before or after the os has started
-(i.e. before `os_start()` is called) but must be initialized after the os has
-been initialized (i.e. 'os_init' has been called). In most of the examples and
-current Mynewt projects, the os is initialized, tasks are initialized, and the
-the os is started. Once the os has started, the highest priority task will be
-the first task set to run.
-
-Information about a task can be obtained using the `os_task_info_get_next()`
-API. Developers can walk the list of tasks to obtain information on all created
-tasks. This information is of type `os_task_info` and is described below.
-
-The following is a very simple example showing a single application task. This
-task simply toggles an LED at a one second interval.
-
-```c
-/* Create a simple "project" with a task that blinks a LED every second */
-
-/* Define task stack and task object */
-#define MY_TASK_PRI (OS_TASK_PRI_HIGHEST)
-#define MY_STACK_SIZE (64)
-struct os_task my_task;
-OS_TASK_STACK_DEFINE(my_task_stack, MY_STACK_SIZE);
-
-/* This is the task function */
-void my_task_func(void *arg) {
- /* Set the led pin as an output */
- hal_gpio_init_out(LED_BLINK_PIN, 1);
-
- /* The task is a forever loop that does not return */
- while (1) {
- /* Wait one second */
- os_time_delay(1000);
-
- /* Toggle the LED */
- hal_gpio_toggle(LED_BLINK_PIN);
- }
-}
-
-/* This is the main function for the project */
-int main(int argc, char **argv)
-{
-
- /* Perform system and package initialization */
- sysinit();
-
- /* Initialize the task */
- os_task_init(&my_task, "my_task", my_task_func, NULL, MY_TASK_PRIO,
- OS_WAIT_FOREVER, my_task_stack, MY_STACK_SIZE);
-
- /* Process events from the default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
- /* main never returns */
-}
-```
-
-## Data structures
-
-```c
-/* The highest and lowest task priorities */
-#define OS_TASK_PRI_HIGHEST (0)
-#define OS_TASK_PRI_LOWEST (0xff)
-
-/* Task states */
-typedef enum os_task_state {
- OS_TASK_READY = 1,
- OS_TASK_SLEEP = 2
-} os_task_state_t;
-
-/* Task flags */
-#define OS_TASK_FLAG_NO_TIMEOUT (0x0001U)
-#define OS_TASK_FLAG_SEM_WAIT (0x0002U)
-#define OS_TASK_FLAG_MUTEX_WAIT (0x0004U)
-
-typedef void (*os_task_func_t)(void *);
-
-#define OS_TASK_MAX_NAME_LEN (32)
-```
-<br>
-```c
-struct os_task {
- os_stack_t *t_stackptr;
- os_stack_t *t_stacktop;
-
- uint16_t t_stacksize;
- uint16_t t_flags;
-
- uint8_t t_taskid;
- uint8_t t_prio;
- uint8_t t_state;
- uint8_t t_pad;
-
- char *t_name;
- os_task_func_t t_func;
- void *t_arg;
-
- void *t_obj;
-
- struct os_sanity_check t_sanity_check;
-
- os_time_t t_next_wakeup;
- os_time_t t_run_time;
- uint32_t t_ctx_sw_cnt;
-
- /* Global list of all tasks, irrespective of run or sleep lists */
- STAILQ_ENTRY(os_task) t_os_task_list;
-
- /* Used to chain task to either the run or sleep list */
- TAILQ_ENTRY(os_task) t_os_list;
-
- /* Used to chain task to an object such as a semaphore or mutex */
- SLIST_ENTRY(os_task) t_obj_list;
-};
-```
-
-| **Element** | **Description** |
-|-----------|-------------|
-| t_stackptr | Current stack pointer |
-| t_stacktop | The address of the top of the task stack. The stack grows downward |
-| t_stacksize | The size of the stack, in units of os_stack_t (not bytes!) |
-| t_flags | Task flags (see flag definitions) |
-| t_taskid | A numeric id assigned to each task |
-| t_prio | The priority of the task. The lower the number, the higher the priority |
-| t_state | The task state (see state definitions) |
-| t_pad | padding (for alignment) |
-| t_name | Name of task |
-| t_func | Pointer to task function |
-| t_obj | Generic object used by mutexes and semaphores when the task is waiting on a mutex or semaphore
-| t_sanity_check | Sanity task data structure |
-| t_next_wakeup | OS time when task is next scheduled to wake up |
-| t_run_time | The amount of os time ticks this task has been running |
-| t_ctx_sw_cnt | The number of times that this task has been run |
-| t_os_task_list | List pointer for global task list. All tasks are placed on this list |
-| t_os_list | List pointer used by either the active task list or the sleeping task list |
-| t_obj_list | List pointer for tasks waiting on a semaphore or mutex |
-
-<br>
-```c
-struct os_task_info {
- uint8_t oti_prio;
- uint8_t oti_taskid;
- uint8_t oti_state;
- uint8_t oti_flags;
- uint16_t oti_stkusage;
- uint16_t oti_stksize;
- uint32_t oti_cswcnt;
- uint32_t oti_runtime;
- os_time_t oti_last_checkin;
- os_time_t oti_next_checkin;
-
- char oti_name[OS_TASK_MAX_NAME_LEN];
-};
-```
-
-| **Element** | **Description** |
-|-----------|-------------|
-| oti_prio | Task priority |
-| oti_taskid | Task id |
-| oti_state | Task state |
-| oti_flags | Task flags |
-| oti_stkusage | Amount of stack used by the task (in os_stack_t units) |
-| oti_stksize | The size of the stack (in os_stack_t units) |
-| oti_cswcnt | The context switch count |
-| oti_runtime | The amount of time that the task has run (in os time ticks) |
-| oti_last_checkin | The time (os time) at which this task last checked in to the sanity task |
-| oti_next_checkin | The time (os time) at which this task last checked in to the sanity task |
-| oti_name | Name of the task |
-
-<br>
-## List of Functions
-
-The functions available in task are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_task_init](os_task_init.md) | Called to create a task. This adds the task object to the list of ready to run tasks. |
-| [os_task_count](os_task_count.md) | Returns the number of tasks that have been created. |
-| [os_task_info_get_next](os_task_info_get_next.md) | Populates the os task info structure given with task information. |
-| [os_task_remove](os_task_remove.md)| Removes a task from the task list.|
diff --git a/docs/os/core_os/time/os_get_uptime_usec.md b/docs/os/core_os/time/os_get_uptime_usec.md
deleted file mode 100644
index 4859196..0000000
--- a/docs/os/core_os/time/os_get_uptime_usec.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_get_uptime_usec</font>
-
-```c
-int64_t os_get_uptime_usec(void)
-```
-Gets the time duration, in microseconds, since boot.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-Time since boot in microseconds.
-
-#### Notes
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- int64_t time_since_boot;
- time_since_boot = os_get_uptime_usec();
-```
diff --git a/docs/os/core_os/time/os_gettimeofday.md b/docs/os/core_os/time/os_gettimeofday.md
deleted file mode 100644
index 22d10a3..0000000
--- a/docs/os/core_os/time/os_gettimeofday.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_gettimeofday</font>
-
-```c
-int os_gettimeofday(struct os_timeval *utctime, struct os_timezone *timezone);
-```
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| utctime | UTC time corresponding to wallclock time |
-| timezone | Timezone to convert UTC time to wallclock time |
-
-#### Returned values
-
-Returns 0 on success and non-zero on failure.
-
-#### Notes
-`utctime` or `timezone` may be NULL.
-
-The function is a no-op if both `utctime` and `timezone` are NULL.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- /*
- * Display wallclock time on the console.
- */
- int rc;
- struct os_timeval utc;
- struct os_timezone tz;
- char buf[DATETIME_BUFSIZE];
-
- rc = os_gettimeofday(&utc, &tz);
- if (rc == 0) {
- format_datetime(&utc, &tz, buf, sizeof(buf));
- console_printf("%s\n", buf);
- }
-
-```
-
diff --git a/docs/os/core_os/time/os_settimeofday.md b/docs/os/core_os/time/os_settimeofday.md
deleted file mode 100644
index c5fc186..0000000
--- a/docs/os/core_os/time/os_settimeofday.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_settimeofday</font>
-
-```c
-int os_settimeofday(struct os_timeval *utctime, struct os_timezone *timezone);
-```
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| utctime | UTC time corresponding to the wallclock time |
-| timezone | Timezone associated with the wallclock time |
-
-#### Returned values
-
-Returns 0 on success and non-zero on failure.
-
-#### Notes
-`utctime` may be NULL if only the timezone needs to be changed. This is useful when adjusting the `timezone` to account for daylight savings.
-
-`timezone` may be NULL if only the UTC time needs to be changed. This is useful when synchronizing Mynewt's time with an external time source like NTP.
-
-The function is a no-op if both `utctime` and `timezone` are NULL.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- int rc;
- parse_datetime(datestr, &utctime, &tz);
- rc = os_settimeofday(&utctime, &tz);
- if (rc == 0) {
- /* success */
- }
-```
-
diff --git a/docs/os/core_os/time/os_time.md b/docs/os/core_os/time/os_time.md
deleted file mode 100644
index 91ea56a..0000000
--- a/docs/os/core_os/time/os_time.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# OS_Time
-
-
-The system time for the Mynewt OS.
-
-## Description
-
-The Mynewt OS contains an incrementing time that drives the OS scheduler and time delays. The time is a fixed size (e.g. 32 bits) and will eventually wrap back to zero. The time to wrap from zero back to zero is called the **OS time epoch**.
-
-The frequency of the OS time tick is specified in the architecture-specific OS code `os_arch.h` and is named `OS_TICKS_PER_SEC`.
-
-The Mynewt OS also provides APIs for setting and retrieving the wallclock time (also known as local time or time-of-day in other operating systems).
-
-## Data Structures
-
-Time is stored in Mynewt as an `os_time_t` value.
-
-Wallclock time is represented using the `struct os_timeval` and `struct os_timezone` tuple.
-
-`struct os_timeval` represents the number of seconds elapsed since 00:00:00 Jan 1, 1970 UTC.
-<pre>
-struct os_timeval {
- int64_t tv_sec; /* seconds since Jan 1 1970 UTC */
- int32_t tv_usec; /* fractional seconds */
-};
-
-struct os_timeval tv = { 1457400000, 0 }; /* 01:20:00 Mar 8 2016 UTC */
-</pre>
-
-`struct os_timezone` is used to specify the offset of local time from UTC and whether daylight savings is in effect. Note that `tz_minuteswest` is a positive number if the local time is *behind* UTC and a negative number if the local time is *ahead* of UTC.
-<pre>
-struct os_timezone {
- int16_t tz_minuteswest;
- int16_t tz_dsttime;
-};
-
-/* Pacific Standard Time is 08:00 hours west of UTC */
-struct os_timezone PST = { 480, 0 };
-struct os_timezone PDT = { 480, 1 };
-
-/* Indian Standard Time is 05:30 hours east of UTC */
-struct os_timezone IST = { -330, 0 };
-</pre>
-
-## List of Functions
-
-The functions available in time are:
-
-| **Function** | **Description** |
-|-----------|-------------|
-| [os_time_advance](os_time_advance.md) | Increments the OS time tick for the system. |
-| [os_time_delay](os_time_delay.md) | Put the current task to sleep for the given number of ticks. |
-| [os_time_get](os_time_get.md) | Get the current value of OS time. |
-| [os_time_ms_to_ticks](os_time_ms_to_ticks.md) | Converts milliseconds to os ticks. |
-| [os_get_uptime_usec](os_get_uptime_usec.md) | Gets the time duration since boot. |
-| [os_gettimeofday](os_gettimeofday.md) | Populate the given timeval and timezone structs with current time data. |
-| [os_settimeofday](os_settimeofday.md) | Set the current time of day to the given time structs. |
-
-## List of Macros
-
-Several macros help with the evalution of times with respect to each other.
-
-* `OS_TIME_TICK_LT(t1,t2)` -- evaluates to true if t1 is before t2 in time.
-* `OS_TIME_TICK_GT(t1,t2)` -- evaluates to true if t1 is after t2 in time
-* `OS_TIME_TICK_GEQ(t1,t2)` -- evaluates to true if t1 is on or after t2 in time.
-
-NOTE: For all of these macros the calculations are done modulo 'os_time_t'.
-
-Ensure that comparison of OS time always uses the macros above (to compensate for the possible wrap of OS time).
-
-The following macros help adding or subtracting time when represented as `struct os_timeval`. All parameters to the following macros are pointers to `struct os_timeval`.
-
-- `os_timeradd(tvp, uvp, vvp)` -- Add `uvp` to `tvp` and store result in `vvp`.
-- `os_timersub(tvp, uvp, vvp)` -- Subtract `uvp` from `tvp` and store result in `vvp`.
-
-## Special Notes
-
-Its important to understand how quickly the time wraps especially when doing time comparison using the macros above (or by any other means).
-
-For example, if a tick is 1 millisecond and `os_time_t` is 32-bits the OS time will wrap back to zero in about 49.7 days or stated another way, the OS time epoch is 49.7 days.
-
-If two times are more than 1/2 the OS time epoch apart, any time comparison will be incorrect. Ensure at design time that comparisons will not occur between times that are more than half the OS time epoch.
-
diff --git a/docs/os/core_os/time/os_time_advance.md b/docs/os/core_os/time/os_time_advance.md
deleted file mode 100644
index fff1245..0000000
--- a/docs/os/core_os/time/os_time_advance.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_time_advance</font>
-
-```c
-void os_time_advance(int ticks)
-```
-Moves the OS time forward by the value specified in `ticks`. Typically, this is called in one place by the architecture specific OS code (kernel/os/src/arch) timer_handler which is in turn called by the BSP specific code assigned to drive the OS timer tick. See Porting Mynewt OS for details.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `ticks` | Number of ticks to move the OS time forward. |
-
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-
-#### Example
diff --git a/docs/os/core_os/time/os_time_delay.md b/docs/os/core_os/time/os_time_delay.md
deleted file mode 100644
index a9199ba..0000000
--- a/docs/os/core_os/time/os_time_delay.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_time_delay</font>
-
-```c
-void os_time_delay(int32_t ticks)
-```
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| ticks | Number of ticks to delay. Less than or equal to zero means no delay |
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-Passing `OS_TIMEOUT_NEVER` to this function will not block indefinitely but will return immediately. Passing delays larger than 1/2 the OS time epoch should be avoided; behavior is unpredictable.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- /* delay 3 seconds */
- int32_t delay = OS_TICKS_PER_SEC * 3;
- os_time_delay(delay);
-```
-
diff --git a/docs/os/core_os/time/os_time_get.md b/docs/os/core_os/time/os_time_get.md
deleted file mode 100644
index a6d17a8..0000000
--- a/docs/os/core_os/time/os_time_get.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_time_get</font>
-
-```c
-os_time_t os_time_get(void)
-```
-
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-The current value of the OS time
-
-#### Notes
-
-See the [Special Notes](os_time) on OS time epoch and comparison
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- os_time_t now = os_time_get();
-```
-
diff --git a/docs/os/core_os/time/os_time_ms_to_ticks.md b/docs/os/core_os/time/os_time_ms_to_ticks.md
deleted file mode 100644
index 4508012..0000000
--- a/docs/os/core_os/time/os_time_ms_to_ticks.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_time_ms_to_ticks</font>
-
-```c
-int os_time_ms_to_ticks(uint32_t ms, uint32_t *out_ticks)
-```
-Converts milliseconds to OS ticks.
-
-#### Arguments
-| Arguments | Description |
-|-----------|-------------|
-| `ms` | Number of milliseconds to convert to OS ticks. |
-| `out_ticks` | Pointer to an uint32_t to return the number of OS ticks for `ms` milliseconds.|
-
-N/A
-
-#### Returned values
-`0`: Success
-<br>`OS_EINVAL`: Number of ticks is too large to fit in an uint32_t.
-
-N/A
-
-#### Notes
-
-
-#### Example
-```c
-unint32_t num_ticks;
-os_time_ms_to_ticks(50, &num_ticks);
-```
diff --git a/docs/os/get_started/cross_tools.md b/docs/os/get_started/cross_tools.md
deleted file mode 100644
index b967d99..0000000
--- a/docs/os/get_started/cross_tools.md
+++ /dev/null
@@ -1,179 +0,0 @@
-# Installing the Cross Tools for ARM
-
-This page shows you how to install the tools to build, run, and debug Mynewt OS applications that run on supported ARM target boards. It shows you how to install the following tools on Mac OS, Linux and Windows:
-
-* ARM cross toolchain to compile and build Mynewt applications for the target boards.
-* Debuggers to load and debug applications on the target boards.
-
-<br>
-
-## Installing the ARM Cross Toolchain
-ARM maintains a pre-built GNU toolchain with gcc and gdb targeted at Embedded ARM Processors, namely Cortex-R/Cortex-M processor families. Mynewt OS has been tested with version 4.9 of the toolchain and we recommend you install this version to get started. Mynewt OS will eventually work with multiple versions available, including the latest releases.
-
-### Installing the ARM Toolchain For Mac OS X
-
-Add the **PX4/homebrew-px4** homebrew tap and install version 4.9 of the toolchain. After installing, check that the symbolic link that homebrew created points to the correct version of the debugger.
-
-```no-highlight
-$ brew tap PX4/homebrew-px4
-$ brew update
-$ brew install gcc-arm-none-eabi-49
-$ arm-none-eabi-gcc --version
-arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]
-Copyright (C) 2014 Free Software Foundation, Inc.
-This is free software; see the source for copying conditions. There is NO
-warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-$ ls -al /usr/local/bin/arm-none-eabi-gdb
-lrwxr-xr-x 1 aditihilbert admin 69 Sep 22 17:16 /usr/local/bin/arm-none-eabi-gdb -> /usr/local/Cellar/gcc-arm-none-eabi-49/20150609/bin/arm-none-eabi-gdb
-```
-**Note:** If no version is specified, brew will install the latest version available.
-
-<br>
-### Installing the ARM Toolchain For Linux
-
-On a Debian-based Linux distribution, gcc 4.9.3 for ARM can be installed with
-apt-get as documented below. The steps are explained in depth at
-[https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa](https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa).
-
-```no-highlight
-$ sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi
-$ sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
-$ sudo apt-get update
-$ sudo apt-get install gcc-arm-embedded
-```
-<br>
-### Installing the ARM Toolchain for Windows
-Step 1: Download and run the [installer](https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q2-update/+download/gcc-arm-none-eabi-4_9-2015q2-20150609-win32.exe) to install arm-none-eabi-gcc and arm-none-eabi-gdb. Select the default destination folder: **C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q2**.
-
-**Notes:**
-
-* Check the `Add path to environment variable` option before you click the `Finish` button for the installation.
-* You may select a different folder but the installation instructions use the default values.
-
-Step 2: Check that you are using the installed versions arm-none-eabi-gcc and arm-none-eabi-gdb. Open a MinGW terminal and run the `which` commands.
-
-**Note:** You must start a new MinGW terminal to inherit the new **Path** values.
-
-```no-highlight
-$ which arm-none-eabi-gcc
-/c/Program Files (x86)/GNU Tools ARM Embedded/4.9 2015q2/bin/arm-none-eabi-gcc
-$which arm-none-eabi-gdb
-/c/Program Files (x86)/GNU Tools ARM Embedded/4.9 2015q2/bin/arm-none-eabi-gdb
-```
-## Installing the Debuggers
-Mynewt uses, depending on the board, either the OpenOCD or SEGGER J-Link debuggers.
-<br>
-### Installing the OpenOCD Debugger
-OpenOCD (Open On-Chip Debugger) is open-source software that allows your
-computer to interface with the JTAG debug connector on a variety of boards. A
-JTAG connection lets you debug and test embedded target devices. For more on
-OpenOCD go to [http://openocd.org](http://openocd.org).
-
-OpenOCD version 0.10.0 with nrf52 support is required. A binary for this version is available to download for Mac OS, Linux, and Windows.
-
-<br>
-#### Installing OpenOCD on Mac OS
-Step 1: Download the [binary tarball for Mac OS](https://github.com/runtimeco/openocd-binaries/raw/master/openocd-bin-0.10.0-MacOS.tgz).
-
-Step 2: Change to the root directory:
-```no-highlight
-$cd /
-```
-<br>
-Step 3: Untar the tarball and install into ** /usr/local/bin**. You will need to replace ** ~/Downloads ** with the directory that the tarball is downloaded to.
-```no-highlight
-sudo tar -xf ~/Downloads/openocd-bin-0.10.0-MacOS.tgz
-```
-<br>
-Step 4: Check the OpenOCD version you are using.
-
-```no-highlight
-$which openocd
-/usr/local/bin/openocd
-$openocd -v
-Open On-Chip Debugger 0.10.0
-Licensed under GNU GPL v2
-For bug reports, read
-http://openocd.org/doc/doxygen/bugs.html
-```
-
-You should see version: **0.10.0**.
-
-If you see one of these errors:
-
-* Library not loaded: /usr/local/lib/libusb-0.1.4.dylib - Run `brew install libusb-compat`.
-* Library not loaded: /usr/local/opt/libftdi/lib/libftdi1.2.dylib - Run `brew install libftdi`.
-* Library not loaded: /usr/local/lib/libhidapi.0.dylib - Run `brew install hidapi`.
-
-<br>
-#### Installing OpenOCD on Linux
-Step 1: Download the [binary tarball for Linux](https://github.com/runtimeco/openocd-binaries/raw/master/openocd-bin-0.10.0-Linux.tgz)
-
-Step 2: Change to the root directory:
-```
-$cd /
-```
-<br>
-Step 3: Untar the tarball and install into ** /usr/local/bin**. You will need to replace ** ~/Downloads ** with the directory that the tarball is downloaded to.
-
-** Note:** You must specify the -p option for the tar command.
-
-```no-highlight
-$sudo tar -xpf ~/Downloads/openocd-bin-0.10.0-Linux.tgz
-```
-<br>
-Step 4: Check the OpenOCD version you are using:
-
-```no-highlight
-$which openocd
-/usr/local/bin/openocd
-$openocd -v
-Open On-Chip Debugger 0.10.0
-Licensed under GNU GPL v2
-For bug reports, read
-http://openocd.org/doc/doxygen/bugs.html
-```
-You should see version: **0.10.0**.
-
-If you see any of these error messages:
-
-* openocd: error while loading shared libraries: libhidapi-hidraw.so.0: cannot open shared object file: No such file or directory
-
-* openocd: error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directory
-
-run the following command to install the libraries:
-```no-highlight
-$sudo apt-get install libhidapi-dev:i386
-```
-<br>
-#### Installing OpenOCD on Windows
-Step 1: Download the [binary zip file for Windows](https://github.com/runtimeco/openocd-binaries/raw/master/openocd-0.10.0.zip).
-
-Step 2: Extract into the **C:\openocd-0.10.0** folder.
-
-Step 3: Add the path: ** C:\openocd-0.10.0\bin** to your Windows User **Path** environment variable. Note: You must add **bin** to the path.
-
-Step 4: Check the OpenOCD version you are using. Open a new MinGW terminal and run the following commands:
-
-**Note:** You must start a new MinGW terminal to inherit the new **Path** values.
-
-```no-highlight
-$which openocd
-/c/openocd-0.10.0/bin/openocd
-$openocd -v
-Open On-Chip Debugger 0.10.0
-Licensed under GNU GPL v2
-For bug reports, read
- http://openocd.org/doc/doxygen/bugs.html
-```
-You should see version: **0.10.0**.
-
-<br>
-###Installing SEGGER J-Link
-You can download and install Segger J-LINK Software and documentation pack from [SEGGER](https://www.segger.com/jlink-software.html).
-
-**Note:** On Windows, perform the following additonal steps:
-
-* Make note of the destination folder of your installation.
-* Add the installation destination folder path to your Windows user **Path** environment variable. You do not need to add **bin** to the path.
-* Open a new MinGW terminal to inherit the new **Path** values.
diff --git a/docs/os/get_started/docker.md b/docs/os/get_started/docker.md
deleted file mode 100644
index ede49b2..0000000
--- a/docs/os/get_started/docker.md
+++ /dev/null
@@ -1,106 +0,0 @@
-## Everything You Need in a Docker Container
-
-Docker provides a quick and easy way to get up and running with Mynewt. The
-newt command line tool and the entire build toolchain is available in a single
-docker container. The container is all that's needed to run your Mynewt based
-application in the simulator. Enabling USB2 with your docker installation will
-allow you to load your application on a supported device.
-
-Docker is the only supported option if you are working on a Windows machine. If you are using Mac OS X or Linux, you have the choice of installing a Docker container of tools and toolchains or installing them natively. This chapter describes how to set up the Docker image for all three platforms.
-
-<br>
-
-### Install Docker
-Install docker for your platform. [Mac OS X](https://www.docker.com/products/docker-toolbox) / [Windows](https://www.docker.com/products/docker-toolbox) / [Linux](https://docs.docker.com/engine/installation/linux/)
-
-#### Mac and Windows
-Mac and Windows require Docker Toolbox to interact with USB devices. Docker
-for Mac and Docker for Windows do not support USB. Docker Toolbox uses
-VirtualBox and allows you to map USB devices into docker containers as
-described below.
-
-Make sure to double click the Docker Quickstart Terminal application if you're
-on Mac or Windows.
-
-#### Linux
-The docker daemon listens on a Unix domain socket on Linux. That socket is
-owned by root, which means by default you must be root to start a container.
-Make sure to follow the optional step of adding yourself to the docker group so
-you can start the newt container as yourself.
-
-<br>
-
-### Use the newt wrapper script
-Use the newt wrapper script to invoke newt. Create the following file, name it
-`newt`, make it executable, and put it in your path. This will allow you to run newt as if it was natively installed. You can now follow the normal tutorials using the newt wrapper script.
-
-
-```bash
-#!/bin/bash
-
-if [ "$1" = "debug" ] || [ "$1" = "run" ]
-then
- ti="-ti"
-fi
-
-docker run -e NEWT_USER=$(id -u) -e NEWT_GROUP=$(id -g) -e NEWT_HOST=$(uname) $ti --rm --device=/dev/bus/usb --privileged -v $(pwd):/workspace -w /workspace mynewt/newt:latest /newt "$@"
-```
-
-<br>
-
-**Note 1:** Remember to point to the correct subdirectory level when invoking `newt`. For example, invoke it using `../newt` in the example below.
-
-```hl_lines="4"
-user@~/dockertest$ ls
-myproj newt
-user@~/dockertest$ cd myproj
-user@~/dockertest/myproj$ ../newt version
-Apache Newt version: 1.2.0
-```
-
-<br>
-
-**Note 2:** You can upgrade your container by running `docker pull mynewt/newt:latest` when updates are made available.
-
-
-
-<br>
-
-### Enable USB2 Support for Mac or Windows
-
-If you plan on loading your application on an actual device, do the steps below.
-
-<br>
-
-#### Install VirtualBox extension pack
-Docker uses a VirtualBox Linux VM to run containers. A free VirtualBox
-extension pack is required to enable USB2 support. Download the [VirtualBox Extension
-Pack](https://www.virtualbox.org/wiki/Downloads)
-version that matches your VirtualBox installation and double click to install
-
-<br>
-
-#### Enable USB2 and select your device
-
-* The "default" VM created by docker-machine must first be stopped before you
- can enable USB2. You have two options:
- * Run the command `docker-machine stop default` in the terminal window or
- * Use the VirtualBox UI. Right click on `default` -> Close -> Power Off
-
-* Enable USB2 using the VirtualBox UI. Select the "default"
- VM->Settings->Ports->USB2 to enable USB2. Add your device to the USB Device
- Filters to make the device visible in the docker container. See the image below.
-
-<img src="../pics/virtualbox_usb.jpg" width="728px" />
-
-* Restart the "default" VM. You have two options:
- * Run `docker-machine start default` in the terminal window or
- * Use the VirtualBox UI. Make sure the "default" machine is highlighted. Click the green "Start" button. Select "Headless Start".
-
-<br>
-
-**Note 3**: When working with actual hardware, remember that each board has an ID. If you swap boards and do not refresh the USB Device Filter on the VirtualBox UI, the ID might be stale and the Docker instance may not be able to see the board correctly. For example, you may see an error message like `Error: unable to find CMSIS-DAP device` when you try to load or run an image on the board. In that case, you need to click on the USB link in VirtualBox UI, remove the existing USB Device Filter (e.g. "Atmel Corp. EDBG CMSIS-DAP[0101]") by clicking on the "Removes selected USB filter" button, and add a new filter by clicking on the "Adds new USB filter" button.
-
-<br>
-
-
diff --git a/docs/os/get_started/get_started.md b/docs/os/get_started/get_started.md
deleted file mode 100644
index a3fd456..0000000
--- a/docs/os/get_started/get_started.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## Quick Start
-
-If you are curious about Mynewt and want to get a quick feel for the project, you've come to the right place. We have two options for you:
-
-<br>
-**Option 1 (Recommended)** allows you to install the Newt tool, instances of the Mynewt OS (for simulated targets), and toolchains for developing embedded software (e.g. GNU toolchain) natively on your laptop or computer. We have tried to make the process easy. For example, for the Mac OS we created brew formulas.
-
-We recommend this option if you are familiar with such environments or are concerned about performance on your machine. Follow the instructions in the [Native Install Option](native_install_intro.md) if you prefer this option.
-
-
-**Option 2** is an easy, self-contained way to get up and running with Mynewt - but has limitations! The Newt tool and build toolchains are all available in a single [All-in-one Docker Container](docker.md) that you can install on your laptop or computer.
-
-However, this is not a long-term option since support is not likely for all features useful or critical to embedded systems development. For example, USB device mapping available in the Docker toolkit is no longer available in the new Docker releases. The Docker option is also typically slower than the native install option.
-
-<br>
-
-
-You can then proceed with the instructions on how to [Create Your First Project](project_create.md) - on simulated hardware.
-
-Upon successful start, several tutorials await your eager attention!
-
-<br>
-
-**Send us an email on the dev@ mailing list if you have comments or suggestions!** If you haven't joined the mailing list, you will find the links [here](../../community.md).
-
-<br>
-
diff --git a/docs/os/get_started/native_install_intro.md b/docs/os/get_started/native_install_intro.md
deleted file mode 100644
index 7aa88d2..0000000
--- a/docs/os/get_started/native_install_intro.md
+++ /dev/null
@@ -1,26 +0,0 @@
-# Native Installation
-
-This section shows you how to install the tools to develop and build Mynewt OS applications on Mac OS, Linux, and Windows, and run and debug the applications on target boards. For Mac OS and Linux, you can also build Mynewt OS applications that run on Mynewt's simulated hardware. These applications run natively on Mac OS and Linux.
-
-The tools you need are:
-
-* Newt tool: Tool to create, build, load, and debug Mynewt OS applications.
-
- * See [Installing the Newt Tool on Mac OS](/newt/install/newt_mac.md) to install on Mac OS.
- * See [Installing the Newt Tool on Linux](/newt/install/newt_linux.md) to install on Linux.
- * See [Installing the Newt Tool on Windows](/newt/install/newt_windows.md) to install on Windows.
-
-
-
-* Native toolchain: Native toolchain to compile and build Mynewt OS applications that run on Mynewt's simulated hardware on Mac OS and Linux.
-
- (See [Installing Native Toolchain](/os/get_started/native_tools.md)).
-
-* Cross tools for ARM:
- * Cross toolchain for ARM to compile and build Mynewt OS applications for target boards.
- * Debuggers to load and debug applications on target boards.
-
- (See [Installing Cross Tools for ARMs](/os/get_started/cross_tools.md)).
-
-
-If you would like to use an IDE to develop and debug Mynewt applications, see [using an IDE to develop Mynewt Applications](/faq/ide.md). You must still perform the native installation outlined on this page.
diff --git a/docs/os/get_started/native_tools.md b/docs/os/get_started/native_tools.md
deleted file mode 100644
index d8170a0..0000000
--- a/docs/os/get_started/native_tools.md
+++ /dev/null
@@ -1,141 +0,0 @@
-# Installing Native Toolchain
-
-This page shows you how to install the toolchain to build Mynewt OS applications that run native on Mac OS and Linux. The applications run on Mynewt's simulated hardware. It also allows you to run the test suites for all packages that do not require HW support.
-
-**Note:** This is not supported on Windows.
-
-<br>
-
-## Setting Up the Toolchain for Mac
-
-### Installing Brew
-
-If you have not already installed Homebrew from the [`newt` tutorials pages](../../newt/install/newt_mac.md), install it.
-
-<br>
-
-### Installing gcc/libc
-
-OS X ships with a C compiler called Clang. To build applications for the Mynewt simulator with, a different compiler is used as default: gcc.
-
-```no-highlight
-$ brew install gcc
-...
-...
-==> Summary
-🍺 /usr/local/Cellar/gcc/5.2.0: 1353 files, 248M
-```
-
-<br>
-
-Check the gcc version you have installed (either using brew or previously installed). The brew-installed version can be checked using `brew list gcc`. The default compiler.yml configuration file in Mynewt expects version 5.x for Mac users, so if the installed version is 6.x and you wish to continue with this newer version, modify the `<mynewt-src-directory>/repos/apache-mynewt-core/compiler/sim/compiler.yml` file to change the default `gcc-5` defined there to `gcc-6`. In other words, replace the lines shown highlighted below:
-
-```hl_lines="2 3"
-# OS X.
-compiler.path.cc.DARWIN.OVERWRITE: "gcc-5"
-compiler.path.as.DARWIN.OVERWRITE: "gcc-5"
-compiler.path.objdump.DARWIN.OVERWRITE: "gobjdump"
-compiler.path.objsize.DARWIN.OVERWRITE: "objsize"
-compiler.path.objcopy.DARWIN.OVERWRITE: "gobjcopy"
-```
-with the following:
-
-```no-highlight
-compiler.path.cc.DARWIN.OVERWRITE: "gcc-6"
-compiler.path.as.DARWIN.OVERWRITE: "gcc-6”
-```
-
-<br>
-
-In case you wish to use Clang, you can change your `<mynewt-src-directory>/repos/apache-mynewt-core/compiler/sim/compiler.yml` to use Clang. Delete the gcc-5 DARWIN.OVERWRITE lines highlighted below.
-
-```hl_lines="2 3"
-# OS X.
-compiler.path.cc.DARWIN.OVERWRITE: "gcc-5"
-compiler.path.as.DARWIN.OVERWRITE: "gcc-5"
-compiler.path.objdump.DARWIN.OVERWRITE: "gobjdump"
-compiler.path.objsize.DARWIN.OVERWRITE: "objsize"
-compiler.path.objcopy.DARWIN.OVERWRITE: "gobjcopy"
-```
-
-<br>
-
-**NOTE:** Both the newer gcc 6.x and Clang report a few warnings but they can be ignored.
-
-<br>
-
-**FURTHER NOTE:** Mynewt developers mostly use gcc 5.x for sim builds; so it may take a little while to fix issues reported by the newer compiler. One option is to **disable warnings**. To do that, remove the `-Werror` flag as an option for the compiler in the `<mynewt-src-directory>/repos/apache-mynewt-core/compiler/sim/compiler.yml` file as shown below.
-
-```hl_lines="2"
-compiler.flags.base: >
- -m32 -Wall -ggdb
-```
-
-You may alternatively choose to **specify the precise warnings to ignore** depending on the error thrown by the compiler. For example, if you see a `[-Werror=misleading-indentation]` error while building the sim image, add `-Wno-misleading-indentation]` as a compiler flag in the same line from the `<mynewt-src-directory>/repos/apache-mynewt-core/compiler/sim/compiler.yml` file.
-
-```hl_lines="2"
-compiler.flags.base: >
- -m32 -Wall -Werror -ggdb -Wno-misleading-indentation
-```
-
-
-A third option is to simply **downgrade to gcc 5.x**.
-
-<br>
-
-### Installing gdb
-
-```no-highlight
-$ brew install gdb
-...
-...
-==> Summary
-🍺 /usr/local/Cellar/gdb/7.10.1: XXX files,YYM
-```
-
-<br>
-
-**NOTE:** When running a program with gdb, you may need to sign your gdb
-executable. [This page](https://gcc.gnu.org/onlinedocs/gnat_ugn/Codesigning-the-Debugger.html)
-shows a recipe for gdb signing. Alternately you can skip this step and
-continue without the ability to debug your mynewt application on your PC.*
-
-<br>
-
-## Setting Up the Toolchain for Linux
-
-The below procedure can be used to set up a Debian-based Linux system (e.g.,
-Ubuntu). If you are running a different Linux distribution, you will need to
-substitute invocations of _apt-get_ in the below steps with the package manager
-that your distro uses.
-
-<br>
-
-### Install gcc/libc that will produce 32-bit executables:
-```no-highlight
-$ sudo apt-get install gcc-multilib libc6-i386
-```
-
-<br>
-
-### Install gdb
-
-```no-highlight
-$ sudo apt-get install gdb
-
-Reading package lists... Done
-Building dependency tree
-Reading state information... Done
-Suggested packages:
- gdb-doc gdbserver
-The following NEW packages will be installed:
- gdb
-...
-Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
-Setting up gdb (7.7.1-0ubuntu5~14.04.2) ...
-
-```
-
-<br>
-
-At this point you have installed all the necessary software to build and run your first project on a simluator on your Mac OS or Linux computer. You may proceed to the [Create Your First Project](project_create.md) section or continue to the next section and install the cross tools for ARM.
diff --git a/docs/os/get_started/pics/ft232h.png b/docs/os/get_started/pics/ft232h.png
deleted file mode 100644
index f907f8f..0000000
--- a/docs/os/get_started/pics/ft232h.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/get_started/pics/m0pro.png b/docs/os/get_started/pics/m0pro.png
deleted file mode 100644
index e3ac967..0000000
--- a/docs/os/get_started/pics/m0pro.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/get_started/pics/nrf52dk.png b/docs/os/get_started/pics/nrf52dk.png
deleted file mode 100644
index 6b24805..0000000
--- a/docs/os/get_started/pics/nrf52dk.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/get_started/pics/virtualbox_usb.jpg b/docs/os/get_started/pics/virtualbox_usb.jpg
deleted file mode 100644
index 898c4a3..0000000
--- a/docs/os/get_started/pics/virtualbox_usb.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/get_started/project_create.md b/docs/os/get_started/project_create.md
deleted file mode 100644
index 7db8bc6..0000000
--- a/docs/os/get_started/project_create.md
+++ /dev/null
@@ -1,399 +0,0 @@
-## Creating Your First Mynewt Project
-
-This page shows you how to create a Mynewt project using the `newt` command-line tool. The project is a blinky application that toggles a pin. The application uses the Mynewt's simulated hardware and runs as a native application on Mac OS and Linux.
-
-**Note:** The Mynewt simulator is not yet supported on Windows. If you are using the native install option (not the Docker option), you will need to create the blinky application for a target board. We recommend that you read the section on creating a new project and fetching the source repository to understand the Mynewt repository structure, create a new project, and fetch the source dependencies before proceeding to one of the [Blinky Tutorials](/os/tutorials/blinky.md).
-
-This guide shows you how to:
-
-1. Create a new project and fetch the source repository and dependencies.
-2. Test the project packages. (Not supported on Windows.)
-3. Build and run the simulated blinky application. (Not supported on Windows.)
-
-
-<br>
-
-### Prerequisites
-* Have Internet connectivity to fetch remote Mynewt components.
-* Install the newt tool:
- * If you have taken the native install option, see the installation instructions for [Mac OS](../../newt/install/newt_mac.md), [Linux](../../newt/install/newt_linux.md), or [Windows](../../newt/install/newt_windows.md).
- * If you have taken the Docker option, you have already installed Newt.
-* Install the [native toolchain](native_tools.md) to compile and build a Mynewt native application.
-
-<br>
-
-### Creating a New Project and Fetching the Source Repository
-This section describes how to use the newt tool to create a new project and fetch the core mynewt source repository.
-
-<br>
-####Creating a New Project
-
-Choose a name for your project. We name the project `myproj`.
-
-<br>
-Run the `newt new myproj` command, from your **dev** directory, to create a new project:
-
-**Note:** This tutorial assumes you created a **dev** directory under your home directory.
-
-``` no-highlight
-$cd ~/dev
-$ newt new myproj
-Downloading project skeleton from apache/mynewt-blinky...
-Installing skeleton in myproj...
-Project myproj successfully created.
-```
-<br>
-
-The newt tool creates a project base directory name **myproj**. All newt tool commands are run from the project base directory. The newt tool populates this new project with a base skeleton of a new Apache Mynewt project in the project base directory. It has the following structure:
-
-**Note**: If you do not have `tree`, run `brew install tree` to install on Mac OS, `sudo apt-get install tree` to install on Linux, and `pacman -Su tree` from a MinGW terminal to install on Windows.
-
-```no-highlight
-$ cd myproj
-$ tree
-.
-├── DISCLAIMER
-├── LICENSE
-├── NOTICE
-├── README.md
-├── apps
-│ └── blinky
-│ ├── pkg.yml
-│ └── src
-│ └── main.c
-├── project.yml
-└── targets
- ├── my_blinky_sim
- │ ├── pkg.yml
- │ └── target.yml
- └── unittest
- ├── pkg.yml
- └── target.yml
-
-6 directories, 11 files
-```
-
-<br>
-
-
-The newt tool installs the following files for a project in the project base directory:
-
-1. The file `project.yml` contains the repository list that the project uses to fetch
-its packages. Your project is a collection of repositories. In this case, the project only
-comprises the core mynewt repository. Later, you will add more repositories to include other mynewt components.
-2. The file `apps/blinky/pkg.yml` contains the description of your application and its package dependencies.
-3. A `target` directory that contains the `my_blinky_sim` directory. The `my_blinky_sim` directory
-a target information to build a version of myproj. Use `newt target show` to see available build
-targets.
-4. A non-buildable target called `unittest`. This is used internally by `newt` and is not a formal build target.
-
-**Note:** The actual code and package files are not installed (except the template for `main.c`). See the next step to install the packages.
-
-<br>
-#### Fetching the Mynewt Source Repository and Dependencies
-
-By default, Mynewt projects rely on a single repository: **apache-mynewt-core** and uses the source in the master branch. If you need to use a different branch, you need to change the `vers` value in the project.yml file:
-
-```no-highlight
-repository.apache-mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: mynewt-core
-```
-
-Changing vers to 0-dev will put you on the latest master branch. **This branch may not be stable and you may encounter bugs or other problems.**
-
-**Note:** On Windows platforms, you will need to change vers to 0-dev and use the latest master branch. Release 1.0.0 is not supported on Windows.
-
-<br>
-Run the `newt install` command, from your project base directory (myproj), to fetch the source repository and dependencies.
-
-**Note:** It may take a while to download the apache-mynewt-core reposistory. Use the _-v_ (verbose) option to see the installation progress.
-
-```no-highlight
-$ newt install
-apache-mynewt-core
-```
-<br>
-**Note:** If you get the following error:
-
- ReadDesc: No matching branch for apache-mynewt-core repo
- Error: No matching branch for apache-mynewt-core repop
-
-You must edit the `project.yml` file and change the line `repo: incubator-mynewt-core` as shown in the following example to `repo: mynewt-core`:
-<br>
-```hl_lines="5"
-repository.apache-mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: incubator-mynewt-core
-```
-<br>
-
-View the core of the Apache Mynewt OS that is downloaded into your local directory.
-
-(The actual output will depend on what is in the latest 'master' branch)
-
-```no-highlight
-$ tree -L 2 repos/apache-mynewt-core/
-
-repos/apache-mynewt-core/
-├── CODING_STANDARDS.md
-├── DISCLAIMER
-├── LICENSE
-├── NOTICE
-├── README.md
-├── RELEASE_NOTES.md
-├── apps
-│ ├── blecent
-│ ├── blehci
-│ ├── bleprph
-│ ├── bleprph_oic
-│ ├── blesplit
-│ ├── bletest
-│ ├── bleuart
-│ ├── boot
-│ ├── btshell
-│ ├── fat2native
-│ ├── ffs2native
-│ ├── ocf_sample
-│ ├── slinky
-│ ├── slinky_oic
-│ ├── spitest
-│ ├── splitty
-│ ├── test
-│ ├── testbench
-│ └── timtest
-├── boot
-│ ├── boot_serial
-│ ├── bootutil
-│ ├── split
-│ └── split_app
-├── compiler
-│ ├── arm-none-eabi-m0
-│ ├── arm-none-eabi-m4
-│ ├── gdbmacros
-│ ├── mips
-│ ├── sim
-│ └── sim-mips
-├── crypto
-│ ├── mbedtls
-│ └── tinycrypt
-├── docs
-│ └── doxygen.xml
-├── encoding
-│ ├── base64
-│ ├── cborattr
-│ ├── json
-│ └── tinycbor
-├── fs
-│ ├── disk
-│ ├── fatfs
-│ ├── fcb
-│ ├── fs
-│ └── nffs
-├── hw
-│ ├── bsp
-│ ├── cmsis-core
-│ ├── drivers
-│ ├── hal
-│ ├── mcu
-│ └── scripts
-├── kernel
-│ └── os
-├── libc
-│ └── baselibc
-├── mgmt
-│ ├── imgmgr
-│ ├── mgmt
-│ ├── newtmgr
-│ └── oicmgr
-├── net
-│ ├── ip
-│ ├── nimble
-│ ├── oic
-│ └── wifi
-├── project.yml
-├── repository.yml
-├── sys
-│ ├── config
-│ ├── console
-│ ├── coredump
-│ ├── defs
-│ ├── flash_map
-│ ├── id
-│ ├── log
-│ ├── mfg
-│ ├── reboot
-│ ├── shell
-│ ├── stats
-│ └── sysinit
-├── targets
-│ └── unittest
-├── test
-│ ├── crash_test
-│ ├── flash_test
-│ ├── runtest
-│ └── testutil
-├── time
-│ └── datetime
-└── util
- ├── cbmem
- ├── crc
- └── mem
-
-94 directories, 9 files
-```
-
-<br>
-
-### Testing the Project Packages
-
-**Note**: This is not yet supported on Windows.
-
-You can use the newt tool to execute the unit tests in a package. For example, run the following command to test the `sys/config` package in the `apache-mynewt-core` repo:
-
-```no-highlight
-$ newt test @apache-mynewt-core/sys/config
-Testing package @apache-mynewt-core/sys/config/test-fcb
-Compiling bootutil_misc.c
-Compiling image_ec.c
-Compiling image_rsa.c
-Compiling image_validate.c
-
- ...
-
-Linking ~/dev/myproj/bin/targets/unittest/sys_config_test-fcb/app/sys/config/test-fcb/sys_config_test-fcb.elf
-Executing test: ~/dev/myproj/bin/targets/unittest/sys_config_test-fcb/app/sys/config/test-fcb/sys_config_test-fcb.elf
-Testing package @apache-mynewt-core/sys/config/test-nffs
-Compiling repos/apache-mynewt-core/encoding/base64/src/hex.c
-Compiling repos/apache-mynewt-core/fs/fs/src/fs_cli.c
-Compiling repos/apache-mynewt-core/fs/fs/src/fs_dirent.c
-Compiling repos/apache-mynewt-core/fs/fs/src/fs_mkdir.c
-Compiling repos/apache-mynewt-core/fs/fs/src/fs_mount.c
-Compiling repos/apache-mynewt-core/encoding/base64/src/base64.c
-Compiling repos/apache-mynewt-core/fs/fs/src/fs_file.c
-Compiling repos/apache-mynewt-core/fs/disk/src/disk.c
-Compiling repos/apache-mynewt-core/fs/fs/src/fs_nmgr.c
-Compiling repos/apache-mynewt-core/fs/fs/src/fsutil.c
-Compiling repos/apache-mynewt-core/fs/nffs/src/nffs.c
-
- ...
-
-Linking ~/dev/myproj/bin/targets/unittest/sys_config_test-nffs/app/sys/config/test-nffs/sys_config_test-nffs.elf
-Executing test: ~/dev/myproj/bin/targets/unittest/sys_config_test-nffs/app/sys/config/test-nffs/sys_config_test-nffs.elf
-Passed tests: [sys/config/test-fcb sys/config/test-nffs]
-All tests passed
-```
-
-**Note:** If you installed the latest gcc using homebrew on your Mac, you are probably running gcc-6. Make sure you change the compiler.yml configuration to specify that you are using gcc-6 (See [Native Install Option](native_tools.md)). You can also downgrade your installation to gcc-5 and use the default gcc compiler configuration for MyNewt:
-
-```no-highlight
-$ brew uninstall gcc-6
-$ brew link gcc-5
-```
-
-**Note:** If you are running the standard gcc for 64-bit machines, it does not support 32-bit. In that case you will see compilation errors. You need to install multilib gcc (e.g. gcc-multilib if you running on a 64-bit Ubuntu).
-
-
-<br>
-
-To test all the packages in a project, specify `all` instead of the package name.
-
-```no-highlight
-$ newt test all
-Testing package @apache-mynewt-core/boot/boot_serial/test
-Compiling repos/apache-mynewt-core/boot/boot_serial/test/src/boot_test.c
-Compiling repos/apache-mynewt-core/boot/boot_serial/test/src/testcases/boot_serial_setup.c
-
- ...
-
-Linking ~/dev/myproj/bin/targets/unittest/boot_boot_serial_test/app/boot/boot_serial/test/boot_boot_serial_test.elf
-
-...lots of compiling and testing...
-
-Linking ~/dev/myproj/bin/targets/unittest/util_cbmem_test/app/util/cbmem/test/util_cbmem_test.elf
-Executing test: ~/dev/myproj/bin/targets/unittest/util_cbmem_test/app/util/cbmem/test/util_cbmem_test.elf
-Passed tests: [boot/boot_serial/test boot/bootutil/test crypto/mbedtls/test encoding/base64/test encoding/cborattr/test encoding/json/test fs/fcb/test fs/nffs/test kernel/os/test net/ip/mn_socket/test net/nimble/host/test net/oic/test sys/config/test-fcb sys/config/test-nffs sys/flash_map/test sys/log/full/test util/cbmem/test]
-All tests passed
-
-```
-
-<br>
-
-### Building and Running the Simulated Blinky Application
-The section shows you how to build and run the blinky application to run on Mynewt's simulated hardware.
-
-**Note**: This is not yet supported on Windows. Refer to the [Blinky Tutorials](/os/tutorials/blinky.md) to create a blinky application for a target board.
-
-<br>
-####Building the Application
-To build the simulated blinky application, run `newt build my_blinky_sim`:
-
-```no-highlight
-$ newt build my_blinky_sim
-Building target targets/my_blinky_sim
-Compiling repos/apache-mynewt-core/hw/hal/src/hal_common.c
-Compiling repos/apache-mynewt-core/hw/drivers/uart/src/uart.c
-Compiling repos/apache-mynewt-core/hw/hal/src/hal_flash.c
-Compiling repos/apache-mynewt-core/hw/bsp/native/src/hal_bsp.c
-Compiling repos/apache-mynewt-core/hw/drivers/uart/uart_hal/src/uart_hal.c
-Compiling apps/blinky/src/main.c
-
- ...
-
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf
-Target successfully built: targets/my_blinky_sim
-
-```
-
-<br>
-
-#### Running the Blinky Application
-
-You can run the simulated version of your project and see the simulated LED blink.
-
-If you natively install the toolchain execute the binary directly:
-
-```no-highlight
-$ ./bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf
-hal_gpio set pin 1 to 0
-
-```
-<br>
-If you are using newt docker, use `newt run` to run the simulated binary.
-
-```no-highlight
-$ newt run my_blinky_sim
-Loading app image into slot 1
- ...
-Debugging ~/dev/myproj/bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf
- ...
-Reading symbols from /bin/targets/my_blinky_sim/app/apps/blinky/blinky.elf...done.
-(gdb)
-```
-Type `r` at the `(gdb)` prompt to run the project. You will see an output indicating that the hal_gpio pin is toggling between 1 and 0 in a simulated blink.
-
-
-Type `r` at the `(gdb)` prompt to run the project. You will see an output indicating that the `hal_gpio` pin is toggling between 1 and 0 in a simulated blink.
-
-<br>
-
-### Exploring other Mynewt OS Features
-
-Congratulations, you have created your first project! The blinky application
-is not terribly exciting when it is run in the simulator, as there is no LED to
-blink. Apache Mynewt has a lot more functionality than just running simulated
-applications. It provides all the features you'll need to cross-compile your
-application, run it on real hardware and develop a full featured application.
-
-If you're interested in learning more, a good next step is to dig in to one of
-the [tutorials](../tutorials/tutorials) and get a Mynewt project running on real hardware.
-
-Happy Hacking!
diff --git a/docs/os/get_started/serial_access.md b/docs/os/get_started/serial_access.md
deleted file mode 100644
index 2158407..0000000
--- a/docs/os/get_started/serial_access.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# Using the Serial Port with Mynewt OS
-
-Some of the projects and tutorials here will allow you to use a serial port
-to interact with your Mynewt project. While most modern PCs and laptops
-no longer have a true serial port, almost all can use their USB ports
-as serial ports.
-
-This will show you how to connect to some of the development boards
-we use via a serial port.
-
-The development boards covered here are:
-
-* Nordic Semiconductor NRF52dk
-* Arduino M0 Pro
-
-In order to communicate with these boards you will also need a USB<-->Serial
-converted. We'll be using the [AdaFruit FT232H Breakout Board](https://www.adafruit.com/products/2264) for
-this, but almost any similar board should work just as well. You will also
-need Minicom or a similar Serial communications application. We'll show you how
-to use the `screen` command built in to Mac OS X, but later tutorials will
-also show Minicom setup.
-
-So let's get started!
-
-<br>
-
-## Setup FT232H
-
-This is a great board because it's so easy to set up, and it can do Serial UART,
-SPI, I2C and GPIO as well. There's full documentation on the board [here](https://learn.adafruit.com/adafruit-ft232h-breakout/overview)
- but we're only covering the wiring for the Serial UART.
-
-Start by connecting a jumper wire to Pin D0. This will be the UART Tx pin,
-which we'll then connect to the Rx pin on the Development Board.
-
-Next connect a jumper wire to pin D1. This will be the UART Rx pin,
-which we'll connect to the Tx pin on the development board.
-
-Finally connect a jumper wire to the GND pin.
-
-It should look like this:
-
-
-
-<br>
-
-## Setup Nordic Semiconductor NRF52DK
-
-On the NRF52DK developer kit board, the Rx pin is P0.08, so you'll attach your
-jumper wire from the Tx pin (D0) of the FT232H board here.
-
-The TX Pin is pin P0.06, so you'll attache the jumper wire from the Rx Pin (D1)
-on the FT232H board here.
-
-Finally, the GND wire should go to the GND Pin on the NRF52DK. When you're
-done, your wiring should look like this:
-
-
-
-<br>
-
-## Setup Arduino M0 Pro
-
-On the Arduino M0 Pro, the Tx and Rx pins are clearly labeled as such, as is the GND
-pin. Just make sure you wire Rx from the FT232H to TX on the M0 Pro, and vice-versa.
-
-Your Arduino M0 Pro should look like this:
-
-
-
-<br>
-
-## Setup Serial Communications
-You will need to know the serial port to connect to and use a terminal program to connect to the board.
-
-### Example for Mac OS and Linux Platforms
-First check what USB devices are already connected before connecting the FT232H board to your computer. The ports are listed in the **/dev** directory and the format of the port name is platform dependent:
-
-* Mac OS uses the format `tty.usbserial-<some identifier>`.
-* Linux uses the format `TTYUSB<N>`, where `N` is a number. For example, TTYUSB2.
-
-<br>
-This example is run on a Mac OS system.
-
-Check what USB devices are already connected:
-<br>
-```no-highlight
-$ ls -la /dev/*usb*
-0 crw-rw-rw- 1 root wheel 20, 63 Nov 23 11:13 /dev/cu.usbmodem401322
-0 crw-rw-rw- 1 root wheel 20, 62 Nov 23 11:13 /dev/tty.usbmodem401322
-$
-```
-<br>
-Plug in the FT232H board and check the ports again:
-<br>
-```no-highlight
-$ ls -la /dev/*usb*
-0 crw-rw-rw- 1 root wheel 20, 63 Nov 23 11:13 /dev/cu.usbmodem401322
-0 crw-rw-rw- 1 root wheel 20, 65 Nov 23 11:26 /dev/cu.usbserial-0020124
-0 crw-rw-rw- 1 root wheel 20, 62 Nov 23 11:13 /dev/tty.usbmodem401322
-0 crw-rw-rw- 1 root wheel 20, 64 Nov 23 11:26 /dev/tty.usbserial-0020124
-$
-```
-<br>
-The FT232H is connected to `/dev/tty.usbserial-0020124` (The number after tty.usbserial will be different on your machine.)
-<br>
-Use the screen command to connect to the board:
-<br>
-```
-$ screen /dev/tty.usbserial-0020124 115200
-```
-<br>
-To exit out of `screen` you'll type `control-A` followed by `control-\` and you'll
-be back to a terminal prompt.
-
-<br>
-
-You can also use minicom:
-<br>
-```
-$ minicom -D /dev/tty.usbserial-0020124
-
-Welcome to minicom 2.7
-
-OPTIONS:
-Compiled on Nov 24 2015, 16:14:21.
-Port /dev/tty.usbserial-0020124, 09:57:17
-
-Press Meta-Z for help on special keys
-```
-<br>
-If there's no Mynewt app running, or the Mynewt app doesn't have the Shell and Console
-enabled, you won't see anything there, but you can always refer back to this page
-from later tutorials if you need to.
-
-<br>
-
-### Example for Windows Platforms
-
-First check what USB devices are already connected before connecting the FT232H board to your computer. You can locate the ports from a MinGW terminal or use the Windows Device Manager.
-
-On a MinGW terminal, the ports are listed in the /dev directory and the format of the port name is `ttyS<N>` where N is a number. You must map the port name to a Windows COM port: `/dev/ttyS<N>` maps to `COM<N+1>`. For example, `/dev/ttyS2` maps to `COM3`.
-
-Check what USB devices are already connected:
-<br>
-```no-highlight
-$ls -l /dev/ttyS*
-crw-rw-rw- 1 <user> None 117, 5 May 9 04:24 /dev/ttyS5
-$
-```
-<br>
-/dev/ttyS5 maps to the Windows COM6 port. You can run Windows Device Manager to confirm:
-
-<br>
-
-
-<br>
-
-Plug in the FT232H board and check the ports again:
-<br>
-```no-highlight
-$ls -l /dev/ttyS*
-ls -l /dev/ttyS*
-crw-rw-rw- 1 <user> None 117, 10 May 9 04:55 /dev/ttyS10
-crw-rw-rw- 1 <user> None 117, 5 May 9 04:55 /dev/ttyS5
-$
-```
-<br>
-The FT232H board is connected to port /dev/ttyS10 (or COM11):
-
-<br>
-
-
-
-<br>
-
-We use the PuTTY terminal application to connect to the board on the COM11 port:
-<br>
-
-
-
-<br>
-
-Press Open and you should get a terminal screen titled "COM11 - PuTTY"
-
-
-If there's no Mynewt app running, or the Mynewt app doesn't have the Shell and Console
-enabled, you won't see anything there, but you can always refer back to this page
-from later tutorials if you need to.
-
-<br>
-
-Now that you know how to communicate with your mynewt application, let's move on to
-creating one!
diff --git a/docs/os/get_started/vocabulary.md b/docs/os/get_started/vocabulary.md
deleted file mode 100644
index 410018c..0000000
--- a/docs/os/get_started/vocabulary.md
+++ /dev/null
@@ -1,186 +0,0 @@
-## Concepts
-
-This page is meant to introduce you to some of the concepts inherent to
-the Apache Mynewt Operating System, and *Newt* the tool that stitches a
-project built on Apache Mynewt together.
-
-### Project
-
-The project is the base directory of your embedded software tree. It is a
-workspace that contains a logical collection of source code, for one or
-more of your applications. A project consists of the following items:
-
-* Project Definition: defines project level dependencies, and parameters
- (located in ```project.yml```)
-* Packages
-
-[Packages](#package) are described in detail in the section below.
-
-Here is an example project definition file from the default Apache Mynewt
-project:
-
-```no-highlight
-$ more project.yml
-<snip>
-project.name: "my_project"
-
-project.repositories:
- - apache-mynewt-core
-
-# Use github's distribution mechanism for core ASF libraries.
-# This provides mirroring automatically for us.
-#
-repository.apache-mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: mynewt-core
-$
-```
-
-A couple of things to note in the project definition:
-
-* ```project.repositories```: Defines the remote repositories that this project
-relies upon.
-
-* ```repository.apache-mynewt-core```: Defines the repository information for
-the ```apache-mynewt-core``` repository.
-
-* ```vers=1-latest```: Defines the repository version. This string will use the
-latest stable version in the 'Master' github branch. To use the latest version in the
-master branch, just change it to ```vers=0-dev```. Note that this branch might not be stable.
-
-Repositories are versioned collections of packages.
-
-Projects can rely on remote repositories for functionality, and the newt tool
-will resolve those remote repositories, and download the correct version into
-your local source tree. Newly fetched repositories are put in the ```repos```
-directory of your project, and can be referenced throughout the system by using
-the ```@``` specifier.
-
-By default, the ```@apache-mynewt-core``` repository is included in every
-project. Apache Mynewt Core contains all the base functionality of the Apache
-Mynewt Operating System, including the Real Time Kernel, Bluetooth Networking
-Stack, Flash File System, Console, Shell and Bootloader.
-
-*NOTE:* Any project can be converted into a repository by providing it with a
-```repository.yml``` file and putting it up onto Github. More information
-about repositories can be found in the Newt documentation.
-
-
-### Package
-
-A package is a collection items that form a fundamental unit in the Mynewt
-Operating System. Packages can be:
-
-* Applications
-* Libraries
-* Compiler definitions
-* Targets
-
-A package is identified by having a ```pkg.yml``` file in it's base
-directory. Here is a sample ```pkg.yml``` file for the blinky applicaton:
-
-```no-highlight
-$ more pkg.yml
-<snip>
-pkg.name: apps/blinky
-pkg.type: app
-pkg.description: Basic example application which blinks an LED.
-pkg.author: "Apache Mynewt <dev@mynewt.apache.org>"
-pkg.homepage: "http://mynewt.apache.org/"
-pkg.keywords:
-
-pkg.deps:
- - "@apache-mynewt-core/libs/os"
- - "@apache-mynewt-core/hw/hal"
- - "@apache-mynewt-core/libs/console/full"
-```
-
-Packages have a few features worth noting:
-
-* Dependencies: Packages can rely upon other packages, and when they do
- they will inherit their functionality (header files, library definitions, etc.)
-* APIs: Packages can export named APIs, and they can require that certain
- APIs be present, in order to compile.
-
-Everything that newt knows about within a project's directory is a package. This
-makes it very clean and easy to write re-usable components, which can describe their
-Dependencies and APIs to the rest of the system.
-
-### Target
-
-A target in Apache Mynewt is very similar to a target in *make*. It is the collection
-of parameters that must be passed to Newt in order to generate a reproducible build. A
-target represents the top of the build tree, and any packages or parameters specified at
-the target level, cascade down to all dependencies.
-
-Targets are also packages, and are stored in the ```targets/``` directory at the base
-of your project. Most targets consist of:
-
-* ```app```: The application to build.
-* ```bsp```: The board support package to combine with that application
-* ```build_profile```: Either ```debug``` or ```optimized```.
-
-Targets can also have additional items specified, including:
-
-* ```aflags```: Any additional assembler flags you might want to specify to the build.
-* ```cflags```: Any additional compiler flags you might want to specify to the build.
-* ```lflags```: Any additional linker flags you might want to specify to the build.
-
-In order to create and manipulate targets, the *newt* tool offers a set of helper commands,
-you can find more information about these by issuing:
-
-```no-highlight
-$ newt target
-```no-highlight
-newt target
-Usage:
- newt target [flags]
- newt target [command]
-
-Available Commands:
- config View or populate a target's system configuration
- copy Copy target
- create Create a target
- delete Delete target
- dep View target's dependency graph
- revdep View target's reverse-dependency graph
- set Set target configuration variable
- show View target configuration variables
-
-Global Flags:
- -h, --help Help for newt commands
- -j, --jobs int Number of concurrent build jobs (default 8)
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
-
-Use "newt target [command] --help" for more information about a command.
-
-$
-```
-
-### Configuration
-
-Additional help topics:
-
-
-```no-highlight
-$ newt target config show <target-name>
-...
-* PACKAGE: sys/stats
- * Setting: STATS_CLI
- * Description: Expose the "stat" shell command.
- * Value: 0
- * Setting: STATS_NAMES
- * Description: Include and report the textual name of each statistic.
- * Value: 0
- * Setting: STATS_NEWTMGR
- * Description: Expose the "stat" newtmgr command.
- * Value: 0
-...
-$
-```
diff --git a/docs/os/introduction.md b/docs/os/introduction.md
deleted file mode 100644
index b226b96..0000000
--- a/docs/os/introduction.md
+++ /dev/null
@@ -1,71 +0,0 @@
-## Introduction
-
-### Welcome to Apache Mynewt
-
-Apache Mynewt is an operating system that makes it easy to develop
-applications for microcontroller environments where power and cost
-are driving factors. Examples of these devices are connected locks,
-lights, and wearables.
-
-Microcontroller environments have a number of characteristics that
-makes the operating system requirements for them unique:
-
-* Low memory footprint: memory on these systems range from
-8-16KB (on the low end) to 16MB (on the high end).
-
-* Reduced code size: code often runs out of flash, and total available code size ranges from 64-128KB to 16-32MB.
-
-* Low processing speed: processor speeds vary from 10-12MHz to 160-200MHz.
-
-* Low power operation: devices operate in mostly sleeping mode, in order to conserve
-battery power and maximize power usage.
-
-As more and more devices get connected, these interconnected devices perform complex tasks. To
-perform these tasks, you need low-level operational functionality built into the operating system.
-Typically, connected devices built with these microcontrollers perform a myriad of functions:
-
-* Networking Stacks: Bluetooth Low Energy and Thread
-
-* Peripherals: PWM to drive motors, ADCs to measure sensor data, and RTCs
-to keep time.
-
-* Scheduled Processing: actions must happen on a calendared or periodic basis.
-
-Apache Mynewt accomplishes all the above easily, by providing a complete
-operating system for constrained devices, including:
-
-* A fully open-source Bluetooth Low Energy stack with both Host and
-Controller implementations.
-
-* A pre-emptive, multi-tasking Real Time operating system kernel
-
-* A Hardware Abstraction Layer (HAL) that abstracts the MCU's
-peripheral functions, allowing developers to easily write cross-platform
-code.
-
-<br>
-
-### Newt
-In order to provide all this functionality, and operate in an
-extremely low resource environment, Mynewt provides a very fine-grained source
-package management and build system tool, called *newt*.
-
-You can install *newt* for [Mac OS](../newt/install/newt_mac/), [Linux](../newt/install/newt_linux/), or [Windows](../newt/install/newt_windows/).
-
-<br>
-
-### Newt Manager
-
-
-In order to enable a user to communicate with remote instances of Mynewt OS and query, configure, and operate them, Mynewt provides an application tool called Newt Manager or *newtmgr*.
-
-You can install *newtmgr* for [Mac OS](../newtmgr/install_mac/), [Linux](../newtmgr/install_linux/), or [Windows](../newtmgr/install_windows/).
-
-<br>
-
-### Build your first Mynewt App with Newt
-
-With the introductions out of the way, now is a good time to [get set up and
-started](/os/get_started/get_started/) with your first Mynewt application.
-
-Happy Hacking!
diff --git a/docs/os/modules/baselibc.md b/docs/os/modules/baselibc.md
deleted file mode 100644
index f53954b..0000000
--- a/docs/os/modules/baselibc.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# Baselibc
-
-Baselibc is a very simple libc for embedded systems geared primarily for 32-bit microcontrollers in the 10-100kB memory range. The library of basic system calls and facilities compiles to less than 5kB total on Cortex-M3, and much less if some functions aren't used.
-
-The code is based on klibc and tinyprintf modules, and licensed under the BSD license.
-
-Baselibc comes from https://github.com/PetteriAimonen/Baselibc.git
-
-### Description
-
-Mynewt OS can utilize libc which comes with compiler (e.g. newlib bundled with some binary distributions of arm-none-eabi-gcc). However, you may choose to replace the libc with baselibc for a reduced image size. Baselibc optimizes for size rather than performance, which is usually a more important goal in embedded environments.
-
-### How to switch to baselibc
-
-In order to switch from using libc to using baselibc you have to add the baselibc pkg as a dependency in the project pkg. Specifying this dependency ensures that the linker first looks for the functions in baselibc before falling back to libc while creating the executable. For example, project `boot` uses baselibc. Its project description file `boot.yml` looks like the following:
-
-```no-highlight
- project.name: boot
- project.identities: bootloader
- project.pkgs:
- - libs/os
- - libs/bootutil
- - libs/nffs
- - libs/console/stub
- - libs/util
- - libs/baselibc
- ```
-
-### List of Functions
-
-Documentation for libc functions is available from multiple places. One example are the on-line manual pages at [https://www.freebsd.org/cgi/man.cgi](#https://www.freebsd.org/cgi/man.cgi).
-
-baselibc supports most libc functionality; malloc(), printf-family, string handling, and conversion routines.
-
-There is some functionality which is not available, e.g. support for floating point numbers, and limited support for 'long long'.
diff --git a/docs/os/modules/bootloader/boot_build_status.md b/docs/os/modules/bootloader/boot_build_status.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_build_status.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_build_status_one.md b/docs/os/modules/bootloader/boot_build_status_one.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_build_status_one.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_clear_status.md b/docs/os/modules/bootloader/boot_clear_status.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_clear_status.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_copy_area.md b/docs/os/modules/bootloader/boot_copy_area.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_copy_area.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_copy_image.md b/docs/os/modules/bootloader/boot_copy_image.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_copy_image.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_erase_area.md b/docs/os/modules/bootloader/boot_erase_area.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_erase_area.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_fill_slot.md b/docs/os/modules/bootloader/boot_fill_slot.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_fill_slot.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_find_image_area_idx.md b/docs/os/modules/bootloader/boot_find_image_area_idx.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_find_image_area_idx.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_find_image_part.md b/docs/os/modules/bootloader/boot_find_image_part.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_find_image_part.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_find_image_slot.md b/docs/os/modules/bootloader/boot_find_image_slot.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_find_image_slot.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_go.md b/docs/os/modules/bootloader/boot_go.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_go.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_init_flash.md b/docs/os/modules/bootloader/boot_init_flash.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_init_flash.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_move_area.md b/docs/os/modules/bootloader/boot_move_area.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_move_area.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_read_image_header.md b/docs/os/modules/bootloader/boot_read_image_header.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_read_image_header.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_read_image_headers.md b/docs/os/modules/bootloader/boot_read_image_headers.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_read_image_headers.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_read_status.md b/docs/os/modules/bootloader/boot_read_status.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_read_status.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_select_image_slot.md b/docs/os/modules/bootloader/boot_select_image_slot.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_select_image_slot.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_slot_addr.md b/docs/os/modules/bootloader/boot_slot_addr.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_slot_addr.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_slot_to_area_idx.md b/docs/os/modules/bootloader/boot_slot_to_area_idx.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_slot_to_area_idx.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_swap_areas.md b/docs/os/modules/bootloader/boot_swap_areas.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_swap_areas.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_vect_delete_main.md b/docs/os/modules/bootloader/boot_vect_delete_main.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_vect_delete_main.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_vect_delete_test.md b/docs/os/modules/bootloader/boot_vect_delete_test.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_vect_delete_test.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_vect_read_main.md b/docs/os/modules/bootloader/boot_vect_read_main.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_vect_read_main.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_vect_read_one.md b/docs/os/modules/bootloader/boot_vect_read_one.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_vect_read_one.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_vect_read_test.md b/docs/os/modules/bootloader/boot_vect_read_test.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_vect_read_test.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/boot_write_status.md b/docs/os/modules/bootloader/boot_write_status.md
deleted file mode 100644
index e69de29..0000000
--- a/docs/os/modules/bootloader/boot_write_status.md
+++ /dev/null
diff --git a/docs/os/modules/bootloader/bootloader.md b/docs/os/modules/bootloader/bootloader.md
deleted file mode 100644
index 534ebbc..0000000
--- a/docs/os/modules/bootloader/bootloader.md
+++ /dev/null
@@ -1,565 +0,0 @@
-# Bootloader
-
-The "bootloader" is the code that loads the Mynewt OS image into memory and conducts some checks before allowing the OS to be run. It manages images for the embedded system and upgrades of those images using protocols over various interfaces (e.g. serial, BLE, etc.). Typically, systems with bootloaders have at least two program images coexisting on the same microcontroller, and hence must include branch code that performs a check to see if an attempt to update software is already underway and manage the progress of the process.
-
-The bootloader in the Apache Mynewt project verifies the cryptographic signature of the firmware image before running it. It maintains a detailed status log for each stage of the boot process. For verification of the authenticity of the OS image, it:
-
-
-The "secure bootloader" should be placed in protected memory on a given microcontroller.
-
-The Mynewt bootloader comprises two packages:
-
-* The bootutil library (boot/bootutil)
-* The boot application (apps/boot)
-
-The Mynewt code is thus structured so that the generic bootutil library performs most of the functions of a boot loader. The final step of actually jumping to the main image is kept out of the bootutil library. This last step should instead be implemented in an
-architecture-specific project. Boot loader functionality is separated in this
-manner for the following two reasons:
-
-1. By keeping architecture-dependent code separate, the bootutil library can be
- reused among several boot loaders.
-2. By excluding the last boot step from the library, the bootloader can be unit tested since a library can be unit tested but an applicant can't.
-
-### Limitations
-
-The boot loader currently only supports images with the following
-characteristics:
-
-* Built to run from flash.
-* Built to run from a fixed location (i.e., NOT position-independent).
-
-
-### Image Format
-
-The following definitions describe the image header format.
-
-```c
-#define IMAGE_MAGIC 0x96f3b83c
-#define IMAGE_MAGIC_NONE 0xffffffff
-
-struct image_version {
- uint8_t iv_major;
- uint8_t iv_minor;
- uint16_t iv_revision;
- uint32_t iv_build_num;
-};
-
-/** Image header. All fields are in little endian byte order. */
-struct image_header {
- uint32_t ih_magic;
- uint16_t ih_tlv_size; /* Trailing TLVs */
- uint8_t ih_key_id;
- uint8_t _pad1;
- uint16_t ih_hdr_size;
- uint16_t _pad2;
- uint32_t ih_img_size; /* Does not include header. */
- uint32_t ih_flags;
- struct image_version ih_ver;
- uint32_t _pad3;
-};
-```
-
-The `ih_hdr_size` field indicates the length of the header, and therefore the
-offset of the image itself. This field provides for backwards compatibility in
-case of changes to the format of the image header.
-
-The following are the image header flags available.
-
-```c
-#define IMAGE_F_PIC 0x00000001
-#define IMAGE_F_SHA256 0x00000002 /* Image contains hash TLV */
-#define IMAGE_F_PKCS15_RSA2048_SHA256 0x00000004 /* PKCS15 w/RSA and SHA */
-#define IMAGE_F_ECDSA224_SHA256 0x00000008 /* ECDSA256 over SHA256 */
-#define IMAGE_F_NON_BOOTABLE 0x00000010
-#define IMAGE_HEADER_SIZE 32
-```
-
-Optional type-length-value records (TLVs) containing image metadata are placed
-after the end of the image. For example, security data gets added as a footer at the end of the image.
-
-```c
-/** Image trailer TLV format. All fields in little endian. */
-struct image_tlv {
- uint8_t it_type; /* IMAGE_TLV_[...]. */
- uint8_t _pad;
- uint16_t it_len /* Data length (not including TLV header). */
-};
-
-/*
- * Image trailer TLV types.
- */
-#define IMAGE_TLV_SHA256 1 /* SHA256 of image hdr and body */
-#define IMAGE_TLV_RSA2048 2 /* RSA2048 of hash output */
-#define IMAGE_TLV_ECDSA224 3 /* ECDSA of hash output */
-```
-
-
-### Flash Map
-
-A Mynewt device's flash is partitioned according to its _flash map_. At a high
-level, the flash map maps numeric IDs to _flash areas_. A flash area is a
-region of disk with the following properties:
-
-1. An area can be fully erased without affecting any other areas.
-2. A write to one area does not restrict writes to other areas.
-
-The boot loader uses the following flash areas:
-
-```c
-#define FLASH_AREA_BOOTLOADER 0
-#define FLASH_AREA_IMAGE_0 1
-#define FLASH_AREA_IMAGE_1 2
-#define FLASH_AREA_IMAGE_SCRATCH 3
-```
-
-### Image Slots
-
-A portion of the flash memory is partitioned into two image slots: a primary
-slot and a secondary slot. The boot loader will only run an image from the
-primary slot, so images must be built such that they can run from that fixed
-location in flash. If the boot loader needs to run the image resident in the
-secondary slot, it must swap the two images in flash prior to booting.
-
-In addition to the two image slots, the boot loader requires a scratch area to
-allow for reliable image swapping.
-
-### Boot States
-
-Logically, you can think of a pair of flags associated with each image slot:
-pending and confirmed. On startup, the boot loader determines the state of the
-device by inspecting each pair of flags. These flags have the following
-meanings:
-
-* pending: image gets tested on next reboot; absent subsequent confirm command,
- revert to original image on second reboot.
-* confirmed: always use image unless excluded by a test image.
-
-In English, when the user wants to run the secondary image, they set the
-pending flag for the second slot and reboot the device. On startup, the boot
-loader will swap the two images in flash, clear the secondary slot's pending
-flag, and run the newly-copied image in slot 0. This is a temporary state; if
-the device reboots again, the boot loader swaps the images back to their
-original slots and boots into the original image. If the user doesn't want to
-revert to the original state, they can make the current state permanent by
-setting the confirmed flag in slot 0.
-
-Switching to an alternate image is a two-step process (set + confirm) to
-prevent a device from becoming "bricked" by bad firmware. If the device
-crashes immediately upon booting the second image, the boot loader reverts to
-the working image, rather than repeatedly rebooting into the bad image.
-
-The following set of tables illustrate the three possible states that the
-device can be in:
-
- | slot-0 | slot-1 |
- ---------------+--------+--------|
- pending | | |
- confirmed | X | |
- ---------------+--------+--------'
- Image 0 confirmed; |
- No change on reboot |
- ---------------------------------'
-
- | slot-0 | slot-1 |
- ---------------+--------+--------|
- pending | | X |
- confirmed | X | |
- ---------------+--------+--------'
- Image 0 confirmed; |
- Test image 1 on next reboot |
- ---------------------------------'
-
- | slot-0 | slot-1 |
- ---------------+--------+--------|
- pending | | |
- confirmed | | X |
- ---------------+--------+--------'
- Testing image 0; |
- Revert to image 1 on next reboot |
- ---------------------------------'
-
-
-### Boot Vector
-
-At startup, the boot loader determines which of the above three boot states a device is in by inspecting the boot vector. The boot vector consists of two
-records (called "image trailers"), one written at the end of each image slot.
-An image trailer has the following structure:
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ MAGIC (16 octets) ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ ~
- ~ Swap status (128 * min-write-size * 3) ~
- ~ ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Copy done | 0xff padding (up to min-write-sz - 1) ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Image OK | 0xff padding (up to min-write-sz - 1) ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-These records are at the end of each image slot. The offset immediately
-following such a record represents the start of the next flash area.
-
-Note: `min-write-size` is a property of the flash hardware. If the hardware
-allows individual bytes to be written at arbitrary addresses, then
-`min-write-size` is 1. If the hardware only allows writes at even addresses,
-then `min-write-size` is 2, and so on.
-
-The fields are defined as follows:
-
-1. MAGIC: The following 16 bytes, written in host-byte-order:
-
- const uint32_t boot_img_magic[4] = {
- 0xf395c277,
- 0x7fefd260,
- 0x0f505235,
- 0x8079b62c,
- };
-
-2. Swap status: A series of single-byte records. Each record corresponds to a
-flash sector in an image slot. A swap status byte indicate the location of
-the corresponding sector data. During an image swap, image data is moved one
-sector at a time. The swap status is necessary for resuming a swap operation
-if the device rebooted before a swap operation completed.
-
-3. Copy done: A single byte indicating whether the image in this slot is
-complete (`0x01=done, 0xff=not done`).
-
-4. Image OK: A single byte indicating whether the image in this slot has been
-confirmed as good by the user (`0x01=confirmed; 0xff=not confirmed`).
-
-The boot vector records are structured around the limitations imposed by flash
-hardware. As a consequence, they do not have a very intuitive design, and it
-is difficult to get a sense of the state of the device just by looking at the
-boot vector. It is better to map all the possible vector states to the swap types
-(None, Test, Revert) via a set of tables. These tables are reproduced below.
-In these tables, the "pending" and "confirmed" flags are shown for illustrative
-purposes; they are not actually present in the boot vector.
-
-
- State I
- | slot-0 | slot-1 |
- -----------------+--------+--------|
- magic | Unset | Unset |
- image-ok | Any | N/A |
- -----------------+--------+--------'
- pending | | |
- confirmed | X | |
- -----------------+--------+--------'
- swap: none |
- -----------------------------------'
-
-
- State II
- | slot-0 | slot-1 |
- -----------------+--------+--------|
- magic | Any | Good |
- image-ok | Any | N/A |
- -----------------+--------+--------'
- pending | | X |
- confirmed | X | |
- -----------------+--------+--------'
- swap: test |
- -----------------------------------'
-
-
- State III
- | slot-0 | slot-1 |
- -----------------+--------+--------|
- magic | Good | Unset |
- image-ok | 0xff | N/A |
- -----------------+--------+--------'
- pending | | |
- confirmed | | X |
- -----------------+--------+--------'
- swap: revert (test image running) |
- -----------------------------------'
-
-
- State IV
- | slot-0 | slot-1 |
- -----------------+--------+--------|
- magic | Good | Unset |
- image-ok | 0x01 | N/A |
- -----------------+--------+--------'
- pending | | |
- confirmed | X | |
- -----------------+--------+--------'
- swap: none (confirmed test image) |
- -----------------------------------'
-
-
-### High-level Operation
-
-With the terms defined, we can now explore the boot loader's operation. First,
-a high-level overview of the boot process is presented. Then, the following
-sections describe each step of the process in more detail.
-
-Procedure:
-
- A. Inspect swap status region; is an interrupted swap is being resumed?
- Yes: Complete the partial swap operation; skip to step C.
- No: Proceed to step B.
-
- B. Inspect boot vector; is a swap requested?
- Yes.
- 1. Is the requested image valid (integrity and security check)?
- Yes.
- a. Perform swap operation.
- b. Persist completion of swap procedure to boot vector.
- c. Proceed to step C.
- No.
- a. Erase invalid image.
- b. Persist failure of swap procedure to boot vector.
- c. Proceed to step C.
- No: Proceed to step C.
-
- C. Boot into image in slot 0.
-
-
-### Image Swapping
-
-The boot loader swaps the contents of the two image slots for two reasons:
-
-* User has issued an "image test" operation; the image in slot-1 should be
- run once (state II).
-* Test image rebooted without being confirmed; the boot loader should
- revert to the original image currently in slot-1 (state III).
-
-If the boot vector indicates that the image in the secondary slot should be
-run, the boot loader needs to copy it to the primary slot. The image currently
-in the primary slot also needs to be retained in flash so that it can be used
-later. Furthermore, both images need to be recoverable if the boot loader
-resets in the middle of the swap operation. The two images are swapped
-according to the following procedure:
-
- 1. Determine how many flash sectors each image slot consists of. This
- number must be the same for both slots.
- 2. Iterate the list of sector indices in descending order (i.e., starting
- with the greatest index); current element = "index".
- b. Erase scratch area.
- c. Copy slot1[index] to scratch area.
- d. Write updated swap status (i).
-
- e. Erase slot1[index]
- f. Copy slot0[index] to slot1[index]
- - If these are the last sectors (i.e., first swap being perfomed),
- copy the full sector *except* the image trailer.
- - Else, copy entire sector contents.
- g. Write updated swap status (ii).
-
- h. Erase slot0[index].
- i. Copy scratch area to slot0[index].
- j. Write updated swap status (iii).
-
- 3. Persist completion of swap procedure to slot 0 image trailer.
-
-The additional caveats in step 2f are necessary so that the slot 1 image trailer
-can be written by the user at a later time. With the image trailer unwritten,
-the user can test the image in slot 1 (i.e., transition to state II).
-
-The particulars of step 3 vary depending on whether an image is being tested or
-reverted:
-
- * test:
- o Write slot0.copy_done = 1
- (should now be in state III)
-
- * revert:
- o Write slot0.magic = BOOT_MAGIC
- o Write slot0.copy_done = 1
- o Write slot0.image_ok = 1
- (should now be in state IV)
-
-### Swap Status
-
-The swap status region allows the boot loader to recover in case it restarts in
-the middle of an image swap operation. The swap status region consists of a
-series of single-byte records. These records are written independently, and
-therefore must be padded according to the minimum write size imposed by the
-flash hardware. In the below figure, a `min-write-size` of 1 is assumed for
-simplicity. The structure of the swap status region is illustrated below. In
-this figure, a `min-write-size` of 1 is assumed for simplicity.
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |sec127,state 0 |sec127,state 1 |sec127,state 2 |sec126,state 0 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |sec126,state 1 |sec126,state 2 |sec125,state 0 |sec125,state 1 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |sec125,state 2 | |
- +-+-+-+-+-+-+-+-+ +
- ~ ~
- ~ [Records for indices 124 through 1 ~
- ~ ~
- ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ |sec000,state 0 |sec000,state 1 |sec000,state 2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-And now, in English...
-
-Each image slot is partitioned into a sequence of flash sectors. If we were to
-enumerate the sectors in a single slot, starting at 0, we would have a list of
-sector indices. Since there are two image slots, each sector index would
-correspond to a pair of sectors. For example, sector index 0 corresponds to
-the first sector in slot 0 and the first sector in slot 1. Furthermore, we
-impose a limit of 128 indices. If an image slot consists of more than 128
-sectors, the flash layout is not compatible with this boot loader. Finally,
-reverse the list of indices such that the list starts with index 127 and ends
-with 0. The swap status region is a representation of this reversed list.
-
-During a swap operation, each sector index transitions through four separate
-states:
-
- 0. slot 0: image 0, slot 1: image 1, scratch: N/A
- 1. slot 0: image 0, slot 1: N/A, scratch: image 1 (1->s, erase 1)
- 2. slot 0: N/A, slot 1: image 0, scratch: image 1 (0->1, erase 0)
- 3. slot 0: image 1, slot 1: image 0, scratch: N/A (s->0)
-
-Each time a sector index transitions to a new state, the boot loader writes a
-record to the swap status region. Logically, the boot loader only needs one
-record per sector index to keep track of the current swap state. However, due
-to limitations imposed by flash hardware, a record cannot be overwritten when
-an index's state changes. To solve this problem, the boot loader uses three
-records per sector index rather than just one.
-
-Each sector-state pair is represented as a set of three records. The record
-values map to the above four states as follows
-
- | rec0 | rec1 | rec2
- --------+------+------+------
- state 0 | 0xff | 0xff | 0xff
- state 1 | 0x01 | 0xff | 0xff
- state 2 | 0x01 | 0x02 | 0xff
- state 3 | 0x01 | 0x02 | 0x03
-
-The swap status region can accommodate 128 sector indices. Hence, the size of
-the region, in bytes, is `128 * min-write-size * 3`. The number 128 is chosen
-somewhat arbitrarily and will likely be made configurable. The only
-requirement for the index count is that is is great enough to account for a
-maximum-sized image (i.e., at least as great as the total sector count in an
-image slot). If a device's image slots use less than 128 sectors, the first
-record that gets written will be somewhere in the middle of the region. For
-example, if a slot uses 64 sectors, the first sector index that gets swapped is
-63, which corresponds to the exact halfway point within the region.
-
-
-### Reset Recovery
-
-If the boot loader resets in the middle of a swap operation, the two images may
-be discontiguous in flash. Bootutil recovers from this condition by using the
-boot vector to determine how the image parts are distributed in flash.
-
-The first step is determine where the relevant swap status region is located.
-Because this region is embedded within the image slots, its location in flash
-changes during a swap operation. The below set of tables map boot vector
-contents to swap status location. In these tables, the "source" field
-indicates where the swap status region is located.
-
- | slot-0 | scratch |
- ----------+------------+------------|
- magic | Good | Any |
- copy-done | 0x01 | N/A |
- ----------+------------+------------'
- source: none |
- ------------------------------------'
-
- | slot-0 | scratch |
- ----------+------------+------------|
- magic | Good | Any |
- copy-done | 0xff | N/A |
- ----------+------------+------------'
- source: slot 0 |
- ------------------------------------'
-
- | slot-0 | scratch |
- ----------+------------+------------|
- magic | Any | Good |
- copy-done | Any | N/A |
- ----------+------------+------------'
- source: scratch |
- ------------------------------------'
-
- | slot-0 | scratch |
- ----------+------------+------------|
- magic | Unset | Any |
- copy-done | 0xff | N/A |
- ----------+------------+------------|
- source: varies |
- ------------------------------------+------------------------------+
- This represents one of two cases: |
- o No swaps ever (no status to read, so no harm in checking). |
- o Mid-revert; status in slot 0. |
- -------------------------------------------------------------------'
-
-
-If the swap status region indicates that the images are not contiguous,
-bootutil completes the swap operation that was in progress when the system was
-reset. In other words, it applies the procedure defined in the previous
-section, moving image 1 into slot 0 and image 0 into slot 1. If the boot
-status file indicates that an image part is present in the scratch area, this
-part is copied into the correct location by starting at step e or step h in the
-area-swap procedure, depending on whether the part belongs to image 0 or image
-1.
-
-After the swap operation has been completed, the boot loader proceeds as though
-it had just been started.
-
-### Integrity Check
-
-An image is checked for integrity immediately before it gets copied into the
-primary slot. If the boot loader doesn't perform an image swap, then it
-doesn't perform an integrity check.
-
-During the integrity check, the boot loader verifies the following aspects of
-an image:
-
-* 32-bit magic number must be correct (0x96f3b83c).
-* Image must contain a SHA256 TLV.
-* Calculated SHA256 must matche SHA256 TLV contents.
-* Image *may* contain a signature TLV. If it does, its contents must be
- verifiable using a key embedded in the boot loader.
-
-### Image Signing and Verification
-
-As indicated above, the final step of the integrity check is signature
-verification. The boot loader can have one or more public keys embedded in it
-at build time. During signature verification, the boot loader verifies that an
-image was signed with a private key that corresponds to one of its public keys.
-The image signature TLV indicates the index of the key that is has been signed
-with. The boot loader uses this index to identify the corresponding public
-key.
-
-For information on embedding public keys in the boot loader, as well as
-producing signed images, see: boot/bootutil/signed_images.md
-
-
-* [boot_build_status](boot_build_status.md)
-* [boot_build_status_one](boot_build_status_one.md)
-* [boot_clear_status](boot_clear_status.md)
-* [boot_copy_area](boot_copy_area.md)
-* [boot_copy_image](boot_copy_image.md)
-* [boot_erase_area](boot_erase_area.md)
-* [boot_fill_slot](boot_fill_slot.md)
-* [boot_find_image_area_idx](boot_find_image_area_idx.md)
-* [boot_find_image_part](boot_find_image_part.md)
-* [boot_find_image_slot](boot_find_image_slot.md)
-* [boot_go](boot_go.md)
-* [boot_init_flash](boot_init_flash.md)
-* [boot_move_area](boot_move_area.md)
-* [boot_read_image_header](boot_read_image_header.md)
-* [boot_read_image_headers](boot_read_image_headers.md)
-* [boot_read_status](boot_read_status.md)
-* [boot_select_image_slot](boot_select_image_slot.md)
-* [boot_slot_addr](boot_slot_addr.md)
-* [boot_slot_to_area_idx](boot_slot_to_area_idx.md)
-* [boot_swap_areas](boot_swap_areas.md)
-* [boot_vect_delete_main](boot_vect_delete_main.md)
-* [boot_vect_delete_test](boot_vect_delete_test.md)
-* [boot_vect_read_main](boot_vect_read_main.md)
-* [boot_vect_read_one](boot_vect_read_one.md)
-* [boot_vect_read_test](boot_vect_read_test.md)
-* [boot_write_status](boot_write_status.md)
diff --git a/docs/os/modules/console/console.md b/docs/os/modules/console/console.md
deleted file mode 100644
index da32fa0..0000000
--- a/docs/os/modules/console/console.md
+++ /dev/null
@@ -1,251 +0,0 @@
-## Console
-
-The console is an operating system window where users interact with the OS subsystems or a console application. A user typically inputs text from a keyboard and reads the OS output text on a computer monitor. The text is sent as a sequence of characters between the user and the OS.
-
-You can configure the console to communicate via a UART or the SEGGER Real Time Terminal (RTT) . The `CONSOLE_UART` syscfg setting enables the communication via a UART and is enabled by default. The `CONSOLE_RTT` setting enables the communication via the RTT and is disabled by default. When the `CONSOLE_UART` setting is enabled, the following settings apply:
-
-* `CONSOLE_UART_DEV`: Specifies the UART device to use. The default is `uart0`.
-* `CONSOLE_UART_BAUD`: Specifies the UART baud rate. The default is 115200.
-* `CONSOLE_UART_FLOW_CONTROL`: Specifies the UART flow control. The default is `UART_FLOW_CONTROL_NONE`.
-* ` CONSOLE_UART_TX_BUF_SIZE`: Specifies the transmit buffer size and must be a power of 2. The default is 32.
-<br>
-
-The `CONSOLE_TICKS` setting enables the console to print the current OS ticks in each output line.
-
-**Notes:**
-
-* SEGGER RTT support is not available in the Mynewt 1.0 console package.
-* The console package is initialized during system initialization (sysinit) so you do not need to initialize the console. However, if you use the Mynewt 1.0 console API to read from the console, you will need to call the `console_init()` function to enable backward compatibility support.
-
-### Description
-
-In the Mynewt OS, the console library comes in three versions:
-
-* The `sys/console/full` package implements the complete console functionality and API.
-* The `sys/console/stub` package implements stubs for the API.
-* The `sys/console/minimal` package implements minimal console functionality of reading from and writing to console. It implements the `console_read()` and `console_write()` functions and stubs for all the other console functions.
-
-All the packages export the `console` API, and any package that uses the console API must list `console` as a requirement its `pkg.yml` file:
-
-```no-highlight
-
-pkg.name: sys/shell
-pkg.deps:
- - kernel/os
- - encoding/base64
- - time/datetime
- - util/crc
-pkg.req_apis:
- - console
-
-```
-<br>
-The project `pkg.yml` file also specifies the version of the console package to use.
-
-<br>
-#### Using the Full Console Package
-A project that requires the full console capability must list the `sys/console/full` package as a dependency in its `pkg.yml` file.
-
-An example is the `slinky` application. It requires the full console capability and has the following
-`pkg.yml` file:
-
-```no-highlight
-pkg.name: apps/slinky
-pkg.deps:
- - test/flash_test
- - mgmt/imgmgr
- - mgmt/newtmgr
- - mgmt/newtmgr/transport/nmgr_shell
- - kernel/os
- - boot/bootutil
- - sys/shell
- - sys/console/full
- ...
- - sys/id
-```
-
-<br>
-#### Using the Stub Console Package
-
-A project that uses console stub API must list the `sys/console/stub` package as a dependency in its `pkg.yml` file.
-
-Examples of when a project would use the console stubs might be:
-
-* A project may not have a physical console (e.g. a UART port to connect a terminal to)
-but may have a dependency on a package that has console capability.
-* A bootloader project where we want to keep the size of the image small. It includes
-the `kernel/os` package that can print out messages on a console (e.g. if there is a hard fault).
-However, we do not want to use any console I/O capability in this particular bootloader project to
-keep the size small.
-
-The project would use the console stub API and has the following `pkg.yml` file:
-
-Another example would be the bootloader project where we want to keep the size of the image small. It includes the `libs/os` pkg that can print out messages on a console (e.g. if there is a hard fault) and the `libs/util` pkg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead, and the pkg.yml file for the project boot pkg looks like the following:
-```no-highlight
-pkg.name: apps/boot
-pkg.deps:
- - boot/bootutil
- - kernel/os
- - sys/console/stub
-
-```
-<br>
-
-#### Using the Minimal Console Package
-
-There might be projects that need to read and write data on a serial connection but do not need the full console capability. An example might be a project that supports serial image upgrade but does not need full newtmgr capability. The project would use the console minimal API and has the following `pkg.yml` file:
-
-```no-highlight
-pkg.name: apps/boot
-pkg.type: app
-pkg.description: Boot loader application.
-pkg.author: "Apache Mynewt <dev@mynewt.apache.org>"
-pkg.homepage: "http://mynewt.apache.org/"
-pkg.keywords:
- - loader
-
-pkg.deps:
- - boot/bootutil
- - kernel/os
- - sys/console/stub
-
-pkg.deps.BOOT_SERIAL.OVERWRITE:
- - sys/console/minimal
- - boot/boot_serial
-
-```
-
-<br>
-#### Output to the Console
-
-You use the `console_write()` function to write raw output and the `console_printf()` function to write a C-style formatted string to the console.
-
-<br>
-#### Input from the Console
-
-The following syscfg settings control input from the console:
-
-* `CONSOLE_INPUT`: Enables input from the console. The setting is enabled by default.
-* `CONSOLE_ECHO`: Enables echoing of the received data back to the console. Echoing is enabled by default. Terminal programs expect this, and is a way for the user to know that the console is connected and responsive. You can also use the `console_echo()` function to set echo on or off programatically.
-* `CONSOLE_MAX_INPUT_LEN`: Specifies the maximum input line length.
-
-<br>
-The Mynewt 1.1 console package adds a new API for reading input data from the console. The package supports backward compatibility for the Mynewt 1.0 console API. The steps you use to receive data from the console for each API version are provided below.
-
-<br>
-##### Mynewt 1.0 Console API
-
-To use the Mynewt 1.0 console API for reading input from the console, you perform the follow steps:
-
-1. Call the `console_init()` function and pass either a pointer to a callback function or NULL for the argument. The console calls this callback function, if specified, when it receives a full line of data.
-
-2. Call the `console_read()` function to read the input data.
-
-**Note:** The `CONSOLE_COMPAT` syscfg setting must be set to 1 to enable backward compatibility support. The setting is enabled by default.
-
-<br>
-##### Mynewt 1.1 Console API
-
-Mynewt 1.1 console API adds the `console_set_queues(struct os_eventq *avail_queue, struct os_eventq *lines_queue)` function. An application or the package, such as the shell, calls this function to specify two event queues that the console uses to manage input data buffering and to send notification when a full line of data is received. The two event queues are used as follows:
-
-* **avail_queue**: Each event in this queue indicates that a buffer is available for the console to use for buffering input data.
-
- The caller must initialize the avail_queue and initialize and add an [os_event](/os/core_os/event_queue/event_queue.md) to the avail_queue before calling the `console_set_queues()` function. The fields for the event should be set as follows:
-
- * **`ev_cb`**: Pointer to the callback function to call when a full line of data is received.
- * **`ev_arg`**: Pointer to a `console_input` structure. This structure contains a data buffer to store the current input.
-
-
- The console removes an event from this queue and uses the `console_input` buffer from this event to buffer the received characters until it receives a new line, '/n', character. When the console receives a full line of data, it adds this event to the **lines_queue**.
-
-* **lines_queue**: Each event in this queue indicates a full line of data is received and ready for processing. The console adds an event to this queue when it receives a full line of data. This event is the same event that the console removes from the avail_queue.
-
- The task that manages the lines_queue removes an event from the queue and calls the event callback function to process the input line. The event callback function must add the event back to the avail_queue when it completes processing the current input data, and allows the console to use the `console_input` buffer set for this event to buffer input data.
-
-
- We recommend that you use the OS default queue for the lines_queue so that the callback is processed in the context of the OS main task. If you do not use the OS default event queue, you must initialize an event queue and create a task to process events from the queue.
-
- **Note**: If the callback function needs to read another line of input from the console while processing the current line, it may use the `console_read()` function to read the next line of input from the console. The console will need another `console_input` buffer to store the next input line, so two events, initialized with the pointers to the callback and the `console_input` buffer, must be added to the avail_queue.
-
-
-<br>
-Here is a code excerpt that shows how to use the `console_set_queues()` function. The example adds one event to the avail_queue and uses the OS default event queue for the lines_queue.
-
-```c
-
-static void myapp_process_input(struct os_event *ev);
-
-static struct os_eventq avail_queue;
-
-static struct console_input myapp_console_buf;
-
-static struct os_event myapp_console_event = {
- .ev_cb = myapp_process_input,
- .ev_arg = &myapp_console_buf
-};
-
-/* Event callback to process a line of input from console. */
-static void
-myapp_process_input(struct os_event *ev)
-{
- char *line;
- struct console_input *input;
-
- input = ev->ev_arg;
- assert (input != NULL);
-
- line = input->line;
- /* Do some work with line */
- ....
- /* Done processing line. Add the event back to the avail_queue */
- os_eventq_put(&avail_queue, ev);
- return;
-}
-
-static void
-myapp_init(void)
-{
- os_eventq_init(&avail_queue);
- os_eventq_put(&avail_queue, &myapp_console_event);
-
- console_set_queues(&avail_queue, os_eventq_dflt_get());
-}
-
-```
-
-
-<br>
-###Data structures
-
-The `struct console_input` data structure represents a console input buffer. Each event added to the console avail_queue must have the `ev_arg` field point to a `console_input` structure.
-
-
-```c
-
-struct console_input {
- char line[MYNEWT_VAL(CONSOLE_MAX_INPUT_LEN)];
-};
-
-```
-
-| Element | Description |
-|---------|-------------|
-| `line` | Data buffer that the console uses to save received characters until a new line is received.|
-
-
-### List of Functions
-
-The functions available in console are:
-
-| Function | Description |
-|---------|-------------|
-| [console_echo](console_echo.md) | Controls whether echoing is on or off for the console. |
-| [console_init (Mynewt 1.0 API)](console_init.md) | Initializes the console. |
-| [console_is_init](console_is_init.md) | Returns a value indicating whether the console has been initialized or not. |
-| [console_printf](console_printf.md) | Writes a formatted message instead of raw output to the console. |
-| [console_read](console_read.md) | Copies up the to given number of bytes to the input string. |
-| [console_set_queues](console_set_queues.md) | Specifies the event queues for the console to use to manage input data.
-| [console_write](console_write.md) | Queues characters to console display over serial port. |
-
-
-
diff --git a/docs/os/modules/console/console_echo.md b/docs/os/modules/console/console_echo.md
deleted file mode 100644
index 6d58c67..0000000
--- a/docs/os/modules/console/console_echo.md
+++ /dev/null
@@ -1,57 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_echo </font>
-
-```no-highlight
- void console_echo(int on)
-```
-
-Controls whether echoing is on or off for the console. When echoing is on, all characters received are transmitted back.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| on | 1 turns on echoing, 0 turns it off |
-
-
-#### Returned values
-
-None
-
-#### Notes
-
-#### Example
-
-Here is an example where newtmgr protocol handler is controlling whether echoing is on or off. Newtmgr, the tool, turns echoing off when it's transmitting large chunks of data to target board.
-
-```no-highlight
-static int
-nmgr_def_console_echo(struct nmgr_jbuf *njb)
-{
- int echo_on = 1;
- int rc;
- struct json_attr_t attrs[3] = {
- [0] = {
- .attribute = "echo",
- .type = t_integer,
- .addr.integer = &echo_on,
- .nodefault = 1
- },
- [1] = {
- .attribute = NULL
- }
- };
-
- rc = json_read_object(&njb->njb_buf, attrs);
- if (rc) {
- return OS_EINVAL;
- }
-
- if (echo_on) {
- console_echo(1);
- } else {
- console_echo(0);
- }
- return (0);
-}
-```
-
diff --git a/docs/os/modules/console/console_init.md b/docs/os/modules/console/console_init.md
deleted file mode 100644
index 6c02891..0000000
--- a/docs/os/modules/console/console_init.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_init </font>
-
-```no-highlight
- int
- console_init(console_rx_cb rx_cb)
-```
-This function is a Mynewt 1.0 Console API. This function only needs to be called if the Mynewt 1.0 console API is used to read input from the console input.
-
-If a callback function pointer of `type void (*console_rx_cb)(void)` is specfied, the callback is called when the console receives a full line of data.
-
-Note that this function is most likely getting called from an interrupt context.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| rx_cb | Function pointer, which gets called input is received. |
-
-#### Returned values
-
-Returns 0 on success.
-
-Non-zero on failure.
-
-#### Example
-
-```no-highlight
-int
-main(int argc, char **argv)
-{
- ....
-
- console_init(NULL);
-}
-```
diff --git a/docs/os/modules/console/console_is_init.md b/docs/os/modules/console/console_is_init.md
deleted file mode 100644
index c78d5ef..0000000
--- a/docs/os/modules/console/console_is_init.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_is_init </font>
-
-```no-highlight
- int console_is_init(void)
-```
-
-Returns whether console has been initialized or not.
-
-#### Arguments
-
-None
-
-#### Returned values
-
-1 if console has been initialized.
-
-0 if console has not been initialized.
-
-
-#### Example
-
-```no-highlight
-static int
-log_console_append(struct log *log, void *buf, int len)
-{
- ....
-
- if (!console_is_init()) {
- return (0);
- }
-
- /* print log entry to console */
- ....
-}
-```
-
diff --git a/docs/os/modules/console/console_printf.md b/docs/os/modules/console/console_printf.md
deleted file mode 100644
index 8eb2280..0000000
--- a/docs/os/modules/console/console_printf.md
+++ /dev/null
@@ -1,61 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> console_printf</font>
-
-```no-highlight
- void
- console_printf(const char *fmt, ...)
-```
-
-Writes a formatted message instead of raw output to the console. It first composes a C string containing text specified as arguments to the function or containing the elements in the variable argument list passed to it using snprintf or vsnprintf, respectively. It then uses function `console_write` to output the formatted data (messages) on the console.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fmt | Pointer to C string that contains a format string that follows the same specifications as format in printf. The string is printed to console. |
-| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. va_list is a special type defined in <cstdarg> in stdarg.h. |
-
-#### Returned values
-
-None
-
-#### Notes
-
-While `console_printf`, with its well understood formatting options in C, is more convenient and easy on the eyes than the raw output of `console_write`, the associated code size is considerably larger.
-
-#### Example
-Example #1:
-
-```no-highlight
-char adv_data_buf[32];
-
-void
-task()
-{
- char adv_data_buf[32];
-
- console_printf("%s", adv_data_buf);
-}
-```
-
-Example #2:
-
-```no-highlight
-struct exception_frame {
- uint32_t r0;
- uint32_t r1;
-
-struct trap_frame {
- struct exception_frame *ef;
- uint32_t r2;
- uint32_t r3;
-};
-
-void
-task(struct trap_frame *tf)
-{
- console_printf(" r0:%8.8x r1:%8.8x", tf->ef->r0, tf->ef->r1);
- console_printf(" r8:%8.8x r9:%8.8x", tf->r2, tf->r3);
-}
-```
-
diff --git a/docs/os/modules/console/console_read.md b/docs/os/modules/console/console_read.md
deleted file mode 100644
index acc99ab..0000000
--- a/docs/os/modules/console/console_read.md
+++ /dev/null
@@ -1,62 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_read </font>
-
-```c
-int console_read(char *str, int cnt, int *newline)
-```
-
-Copies up to *cnt* bytes of received data to buffer pointed by *str*. Function tries to break the input into separate lines; once it encounters a newline character, it replaces that with end-of-string and returns.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `str` | Buffer where data is copied to. |
-| `cnt` | Maximum number of characters to copy. |
-| `newline` | Pointer to an integer variable that is set to 1 when an newline character is received and set to 0 otherwise.
-
-
-#### Returned values
-
-Returns the number of characters copied. 0 if there was no data
-available, or if the first received character was '\n'.
-
-
-#### Example
-
-```c
-#define MAX_INPUT 128
-
-static void
-read_function(void *arg)
-{
- char buf[MAX_INPUT];
- int rc;
- int full_line;
- int off;
-
- off = 0;
- while (1) {
- rc = console_read(buf + off, MAX_INPUT - off, &full_line);
- if (rc <= 0 && !full_line) {
- continue;
- }
- off += rc;
- if (!full_line) {
- if (off == MAX_INPUT) {
- /*
- * Full line, no newline yet. Reset the input buffer.
- */
- off = 0;
- }
- continue;
- }
- /* Got full line - break out of the loop and process the input data */
- break;
- }
-
- /* Process the input line here */
- ....
-
- return;
-}
-```
diff --git a/docs/os/modules/console/console_set_queues.md b/docs/os/modules/console/console_set_queues.md
deleted file mode 100644
index 6d7c166..0000000
--- a/docs/os/modules/console/console_set_queues.md
+++ /dev/null
@@ -1,58 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_set_queues </font>
-
-```c
-void console_set_queues(struct os_eventq *avail, struct os_eventq *lines)
-```
-
-Sets the event queues that the console uses to manage input data buffering and to send notification when a full line of data is received.
-
-The caller must initialize the `avail` queue and add at least one event to the queue. The event `ev_cb` field should point to the callback function to call when a full line of data is received, and the event `ev_arg` should point to a `console_input` structure.
-
-The lines queue can be the OS default event queue or an event queue that the caller has initialized. If the OS default event queue is specified, events from this queue are processed in the context of the OS main task. If a different event queue is specified, the call must initialize the event queue and a task to process events from the queue.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `avail` | Event queue to queue available buffer events. An event indicates that the console can use the buffer from event data to buffer input data until a new line is received.
-| `lines` | Event queue to queue full line events. An event indicates that a full line of input is received and the event callback function can be called to process the input line.
-
-#### Returned values
-
-None
-
-#### Example
-
-```c
-
-#define MAX_CONSOLE_LINES 2
-
-static void myapp_process_input(struct os_event *ev);
-
-static struct os_eventq avail_queue;
-
-static void myapp_process_input(struct os_event *ev);
-
-static struct console_input myapp_console_buf;
-
-static struct console_input myapp_console_buf[MAX_CONSOLE_LINES];
-static struct os_event myapp_console_event[MAX_CONSOLE_LINES];
-
-
-int
-main(int argc, char **argv)
-{
- int i;
-
- os_eventq_init(&avail_queue);
-
- for (i = 0; i < MAX_CONSOLE_LINES; i++) {
- myapp_console_event[i].ev_cb = myapp_process_input;
- myapp_console_event[i].ev_arg = &myapp_console_buf[i];
- os_eventq_put(&avail_queue, &myapp_console_event[i]);
- }
-
- console_set_queues(&avail_queue, os_eventq_dflt_get());
-}
-
-```
diff --git a/docs/os/modules/console/console_write.md b/docs/os/modules/console/console_write.md
deleted file mode 100644
index 3d38529..0000000
--- a/docs/os/modules/console/console_write.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> console_write </font>
-
-```no-highlight
- void
- console_write(char *str, int cnt)
-```
-Queues characters to console display over serial port.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *str | pointer to the character or packet to be transmitted |
-| cnt | number of characters in *str* |
-
-#### Returned values
-
-N/A
-
-
-#### Example
-
-Here is an example of the function being used in an echo command with a newline at the end.
-
-```no-highlight
-static int
-shell_echo_cmd(int argc, char **argv)
-{
- int i;
-
- for (i = 1; i < argc; i++) {
- console_write(argv[i], strlen(argv[i]));
- console_write(" ", sizeof(" ")-1);
- }
- console_write("\n", sizeof("\n")-1);
-
- return (0);
-}
-```
-
diff --git a/docs/os/modules/devmgmt/customize_newtmgr.md b/docs/os/modules/devmgmt/customize_newtmgr.md
deleted file mode 100644
index 8f80a18..0000000
--- a/docs/os/modules/devmgmt/customize_newtmgr.md
+++ /dev/null
@@ -1,55 +0,0 @@
-## Customizing Newt Manager Usage with mgmt
-
-The **mgmt** package enables you to customize Newt Manager (in either the newtmgr or oicmgr framerwork) to only process the
-commands that your application uses. The newtmgr commands are divided into management groups.
-A manager package implements the commands for a group. It implements the handlers that
-process the commands for the group and registers the handlers with mgmt.
-When newtmgr or oicmgr receives a newtmgr command,
-it looks up the handler for the command (by management group id and command id) from mgmt and calls the
-handler to process the command.
-
-The system level management groups are listed in following table:
-<table style="width:90%" align="center">
-<tt>
-<td>Management Group</td>
-<td>newtmgr Commands</td>
-<td>Package</td>
-</tt>
-<tr>
-<td>MGMT_GROUP_ID_DEFAULT</td>
-<td>```echo``` ```taskstat``` ```mpstat``` ```datetime``` ```reset```</td>
-<td>mgmt/newtmgr/nmgr_os</td>
-</tr>
-<tr>
-<td>MGMT_GROUP_ID_IMAGE</td>
-<td>```image``` </td>
-<td>mgmt/imgmgr</td>
-</tr>
-<tr>
-<td>MGMT_GROUP_ID_STATS</td>
-<td>```stat``` </td>
-<td>sys/stats</td>
-</tr>
-<tr>
-<td>MGMT_GROUP_ID_CONFIG</td>
-<td>```config```</td>
-<td>sys/config</td>
-</tr>
-<tr>
-<td>MGMT_GROUP_ID_LOGS</td>
-<td>```log```</td>
-<td>sys/log</td>
-</tr>
-<tr>
-<td>MGMT_GROUP_ID_CRASH</td>
-<td>```crash```</td>
-<td>test/crash_test</td>
-</tr>
-<tr>
-<td>MGMT_GROUP_ID_RUNTEST</td>
-<td>```run```</td>
-<td>test/runtest</td>
-</tr>
-</table>
-Both newtmgr and ocimgr process the MGMT_GROUP_ID_DEFAULT commands by default. You can also
-use mgmt to add user defined management group commands.
diff --git a/docs/os/modules/devmgmt/device-mgmt.png b/docs/os/modules/devmgmt/device-mgmt.png
deleted file mode 100644
index 534d97f..0000000
--- a/docs/os/modules/devmgmt/device-mgmt.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/modules/devmgmt/newtmgr.md b/docs/os/modules/devmgmt/newtmgr.md
deleted file mode 100644
index 1a0d06a..0000000
--- a/docs/os/modules/devmgmt/newtmgr.md
+++ /dev/null
@@ -1,21 +0,0 @@
-## Newt Manager
-
-Newt Manager is the protocol that enables your Mynewt application to communicate remotely with your device running the Mynewt OS in order to configure, manage, conduct maintenance, and monitor it. The core device management module is called `mgmt` and offers multiple options for invoking the appropriate newt manager commands for various operations on the device e.g. enabling and collecting logs, configuring and retrieving stats, resetting the device etc.
-
-1. Use the `newtmgr` package if reduced code footprint is your primary requirement and you do not have interoperability requirements upstream for device information, discovery, and connectivity.
-2. Use the `oicmgr` package if interoperability and standards-based connectivity for device interaction is your primary requirement. This package supports the OIC (Open Interconnect Consortium) Specification 1.1.0 framework from Open Connectivity Foundation (OCF).
-
-### Invoking Newt Manager commands
-
-The diagram below indicates the two options available to the application developer to issue Newt Manager (`newtmgr`) commands on a Mynewt device. The application may leverage the `newtmgr` framework or the `oicmgr` framework to call the newtmgr commands. The latter is described in the next chapter.
-
-
-
-### newtmgr
-
-The newtmgr framework uses a simple request and response message format to send commands to the device. A message
-consists of an eight byte header and the message payload. The message header specifies the newtmgr command.
-The message payload contains the newtmgr request/response data and is encoded in
-CBOR (Concise Binary Object Representation) format. newtmgr supports BLE and serial connections.
-
-The newtmgr framework has a smaller code size and memory footprint than oicmgr but does not support open connectivity.
diff --git a/docs/os/modules/devmgmt/oicmgr.md b/docs/os/modules/devmgmt/oicmgr.md
deleted file mode 100644
index ffb6edc..0000000
--- a/docs/os/modules/devmgmt/oicmgr.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## Using the OIC Framework
-
-Apache Mynewt includes support for the OIC interoperability standard through the `oicmgr` framework. Mynewt defines and exposes oicmgr as an OIC Server resource with the following identity and properties:
-<br>
-<table style="width:50%" align="center">
-<tr>
-<td>**URI**</td>
-<td>/omgr</td>
-</tr>
-<tr>
-<td>**Resource Type**(rt)</td>
-<td>x.mynewt.nmgr</td>
-</tr>
-<td>**Interface**(if)</td>
-<td>oic.if_rw (default), oic.if.baseline</td>
-</tr>
-<td>**Discoverable**</td>
-<td>Yes</td>
-</tr>
-</table>
-The newtmgr application tool uses CoAP (Constrained Application Protocol) requests to send commands to oicmgr.
-It sends a CoAP request for **/omgr** as follows:
-
-* Specifies the newtmgr command to execute in the URI query string.
-* Uses a GET method for newtmgr commands that retreive information
-from your application, for example, the ```taskstat``` and ```mpstat``` commands.
-* Uses a PUT method for newtmgr commands that send data to or modify the state of your application,
-for example, the ```echo``` or ```datetime``` commands.
-* Sends the CBOR-encoded command request data in the CoAP message payload.
-
-The `oicmgr` framework supports transport over BLE, serial, and IP connections to the device.
diff --git a/docs/os/modules/drivers/driver.md b/docs/os/modules/drivers/driver.md
deleted file mode 100644
index f599842..0000000
--- a/docs/os/modules/drivers/driver.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# Drivers
-
-### Description
-
-Device drivers in the Mynewt context includes libraries that interface with devices external to the CPU. These devices are connected to the CPU via standard peripherals such as SPI, GPIO, I2C etc. Device drivers leverage the base HAL services in Mynewt to provide friendly abstractions to application developers.
-
-```no-highlight
-
-+———————————————————————————+
-| app |
-+———————————————————————————+
-| (n)drivers |
-+———————————————————————————+
-| HAL | BSP |
-+—————————————+—————————————+
-
-```
-
-* The Board Support Package (BSP) abstracts board specific configurations e.g. CPU frequency, input voltage, LED pins, on-chip flash map etc.
-
-* The Hardware Abstraction Layer (HAL) abstracts architecture-specific functionality. It initializes and enables components within a master processor. It is designed to be portable across all the various MCUs supported in Mynewt (e.g. Nordic's nRF51, Nordic's nRF52, NXP's MK64F12 etc.). It includes code that initializes and manages access to components of the board such as board buses (I2C, PCI, PCMCIA, etc.), off-chip memory (controllers, level 2+ cache, Flash, etc.), and off-chip I/O (Ethernet, RS-232, display, mouse, etc.)
-
-* The driver sits atop the BSP and HAL. It abstracts the common modes of operation for each peripheral device connected via the standard interfaces to the processor. There may be multiple driver implementations of differing complexities for a particular peripheral device. For example, for an Analog to Digital Converter (ADC) peripheral you might have a simple driver that does blocking ADC reads and uses the HAL only. You might have a more complex driver that can deal with both internal and external ADCs, and has chip specific support for doing things like DMA’ing ADC reads into a buffer and posting an event to a task every ’n’ samples. The drivers are the ones that register with the kernel’s power management APIs, and manage turning on and off peripherals and external chipsets, etc. The Mynewt core repository comes with a base set of drivers to help the user get started.
-
-
-### General design principles
-
-* Device drivers should have a consistent structure and unified interface whenever possible. For example, we have a top-level package, “adc”, which contains the interface for all ADC drivers, and then we have the individual implementation of the driver itself. The following source files point to this:
-
- * high-level ADC API: `hw/drivers/adc/include/adc/adc.h`
- * implementation of ADC for STM32F4: `hw/drivers/adc/adc_stm32f4/src/adc_stm32f4.c` (As of the 1.0.0-beta release, ADC for nRF51 and nRF52 are available at an external [repo](https://github.com/runtimeco/mynewt_nordic/tree/master/hw/drivers/adc). They are expected to be pulled into the core repo on Apache Mynewt after the license terms are clarified.). The only exported call in this example is `int stm32f4_adc_dev_init(struct os_dev *, void *)` which is passed as a function pointer to `os_dev_create()` in `hal_bsp.c`, when the adc device is created.
-
-* Device drivers should be easy to use. In Mynewt, creating a device initializes it as well, making it readily available for the user to open, use (e.g. read, configure etc.) and close. Creating a device is simple using `os_dev_create(struct os_dev *dev, char *name, uint8_t stage, uint8_t priority, os_dev_init_func_t od_init, void *arg)`. The `od_init` function is defined within the appropriate driver directory e.g. `stm32f4_adc_dev_init` in `hw/drivers/adc/adc_stm32f4/src/adc_stm32f4.c` for the ADC device initialization function.
-
-* The implementation should allow for builds optimized for minimal memory usage. Additional functionality can be enabled by writing a more complex driver (usually based on the simple implementation included by default in the core repository) and optionally compiling the relevant packages in. Typically, only a basic driver that addresses a device’s core functionality (covering ~90% of use cases) is included in the Mynewt core repository, thus keeping the footprint small.
-
-* The implementation should allow a user to be able to instantiate multiple devices of a certain kind. In the Mynewt environment the user can, for example, maintain separate contexts for multiple ADCs over different peripheral connections such as SPI, I2C etc. It is also possible for a user to use a single peripheral interface (e.g. SPI) to drive multiple devices (e.g. ADC), and in that case the device driver has to handle the proper synchronization of the various tasks.
-
-* Device drivers should be MCU independent. In Mynewt, device creation and operation functions are independent of the underlying MCU.
-* Device drivers should be able to offer high-level interfaces for generic operations common to a particular device group. An example of such a class or group of devices is a group for sensors with generic operations such as channel discovery, configure, and read values. The organization of the driver directory is work in progress - so we encourage you to hop on the dev@ mailing list and offer your insights!
-
-* Device drivers should be searchable. The plan is to have the newt tool offer a `newt pkg search` capability. This is work in progress. You are welcome to join the conversation on the dev@ mailing list!
-
-### Example
-
-The Mynewt core repo includes an example of a driver using the HAL to provide extra functionality - the UART driver. It uses HAL GPIO and UART to provide multiple serial ports on the NRF52 (but allowed on other platforms too.)
-
-The gist of the driver design is that there is an API for the driver (for use by applications), and then sub-packages to that driver that implement that driver API using the HAL and BSP APIs.
-
-### Implemented drivers
-
-Drivers live under `hw/drivers`. The current list of supported drivers includes:
-
-| Driver | Description |
-|---------|-------------|
-| [adc](adc.md) | TODO: ADC driver. |
-| [flash](flash.md) | SPI/I2C flash drivers. |
-| [lwip](lwip.md) | TODO: LWIP. |
-| [mmc](mmc.md) | MMC/SD card driver. |
-| [nimble](/network/ble/ble_intro/) | NIMBLE. |
-| [sensors](sensors.md) | TODO: sensors. |
-| [uart](uart.md) | TODO: UART driver. |
diff --git a/docs/os/modules/drivers/flash.md b/docs/os/modules/drivers/flash.md
deleted file mode 100644
index fdd0e5d..0000000
--- a/docs/os/modules/drivers/flash.md
+++ /dev/null
@@ -1,121 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">flash</font>
-
-The flash driver subsystem is a work in progress which aims at supporting
-common external SPI/I2C flash/eeprom memory chips. This is equivalent
-to what Linux calls `MTD` for `Memory Technology Devices`.
-
-At the moment the only `flash` device that is already supported is the
-AT45DBxxx SPI flash family with the `at45db` driver.
-
-The flash driver aims for full compatibility with the `hal_flash` API,
-which means initialization and usage can be performed by any `fs` that
-supports the `hal_flash` interface.
-
-#### Initialization
-
-To be compatible with the standard `hal_flash` interface, the `at45db` driver
-embeds a `struct hal_flash` to its own `struct at45db_dev`. The whole `at45db_dev`
-struct is shown below.
-
-```c
-struct at45db_dev {
- struct hal_flash hal;
- struct hal_spi_settings *settings;
- int spi_num;
- void *spi_cfg; /** Low-level MCU SPI config */
- int ss_pin;
- uint32_t baudrate;
- uint16_t page_size; /** Page size to be used, valid: 512 and 528 */
- uint8_t disable_auto_erase; /** Reads and writes auto-erase by default */
-};
-```
-
-To ease with initialization a helper function `at45db_default_config` was added.
-It returns an already initialized `struct at45db_dev` leaving the user with just
-having to provide the SPI related config.
-
-To initialize the device, pass the `at45db_dev` struct to `at45db_init`.
-
-```c
-int at45db_init(const struct hal_flash *dev);
-```
-
-For low-level access to the device the following functions are provided:
-
-```c
-int at45db_read(const struct hal_flash *dev, uint32_t addr, void *buf,
- uint32_t len);
-int at45db_write(const struct hal_flash *dev, uint32_t addr, const void *buf,
- uint32_t len);
-int at45db_erase_sector(const struct hal_flash *dev, uint32_t sector_address);
-int at45db_sector_info(const struct hal_flash *dev, int idx, uint32_t *address,
- uint32_t *sz);
-```
-
-Also, `nffs` is able to run on the device due to the fact that standard `hal_flash`
-interface compatibility is provided. Due to current limitations of `nffs`, it can
-only run on `at45db` if the internal flash of the MCU is not being used.
-
-#### Dependencies
-
-To include the `at45db` driver on a project, just include it as a dependency in your
-pkg.yml:
-
-```
-pkg.deps:
- - hw/drivers/flash/at45db
-```
-
-#### Header file
-
-The `at45db` SPI flash follows the standard `hal_flash` interface but requires
-that a special struct
-
-```c
-#include <at45db/at45db.h>
-```
-
-#### Example
-
-This following examples assume that the `at45db` is being used on a STM32F4 MCU.
-
-```c
-static const int SPI_SS_PIN = MCU_GPIO_PORTA(4);
-static const int SPI_SCK_PIN = MCU_GPIO_PORTA(5);
-static const int SPI_MISO_PIN = MCU_GPIO_PORTA(6);
-static const int SPI_MOSI_PIN = MCU_GPIO_PORTA(7);
-
-struct stm32f4_hal_spi_cfg spi_cfg = {
- .ss_pin = SPI_SS_PIN,
- .sck_pin = SPI_SCK_PIN,
- .miso_pin = SPI_MISO_PIN,
- .mosi_pin = SPI_MOSI_PIN,
- .irq_prio = 2
-};
-
-struct at45db_dev *my_at45db_dev = NULL;
-
-my_at45db_dev = at45db_default_config();
-my_at45db_dev->spi_num = 0;
-my_at45db_dev->spi_cfg = &spi_cfg;
-my_at45db_dev->ss_pin = spi_cfg.ss_pin;
-
-rc = at45db_init((struct hal_flash *) my_at45db_dev);
-if (rc) {
- /* XXX: error handling */
-}
-```
-
-The enable `nffs` to run on the `at45db`, the `flash_id` 0 needs to map to
-provide a mapping from 0 to this struct.
-
-```c
-const struct hal_flash *
-hal_bsp_flash_dev(uint8_t id)
-{
- if (id != 0) {
- return NULL;
- }
- return &my_at45db_dev;
-}
-```
diff --git a/docs/os/modules/drivers/mmc.md b/docs/os/modules/drivers/mmc.md
deleted file mode 100644
index 15c7c7f..0000000
--- a/docs/os/modules/drivers/mmc.md
+++ /dev/null
@@ -1,87 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">mmc</font>
-
-The MMC driver provides support for SPI based MMC/SDcard interfaces. It exports
-a `disk_ops` struct that can be used by any FS. Currently only `fatfs` can run
-over MMC.
-
-#### Initialization
-
-```c
-int mmc_init(int spi_num, void *spi_cfg, int ss_pin)
-```
-
-Initializes the mmc driver to be used by a FS.
-
-MMC uses the `hal_gpio` interface to access the SPI `ss_pin` and the `hal_spi`
-interface for the communication with the card. `spi_cfg` must be a hw dependent
-structure used by `hal_spi_init` to initialize the SPI subsystem.
-
-#### Dependencies
-
-To include the `mmc` driver on a project, just include it as a dependency in your
-pkg.yml:
-
-```
-pkg.deps:
- - hw/drivers/mmc
-```
-
-#### Returned values
-
-MMC functions return one of the following status codes:
-
-| Return code | Description |
-|----------------------|-------------------------------------------------------|
-| MMC\_OK | Success. |
-| MMC\_CARD_ERROR | General failure on the card. |
-| MMC\_READ_ERROR | Error reading from the card. |
-| MMC\_WRITE_ERROR | Error writing to the card. |
-| MMC\_TIMEOUT | Timed out waiting for the execution of a command. |
-| MMC\_PARAM_ERROR | An invalid parameter was given to a function. |
-| MMC\_CRC_ERROR | CRC error reading card. |
-| MMC\_DEVICE_ERROR | Tried to use an invalid device. |
-| MMC\_RESPONSE_ERROR | A command received an invalid response. |
-| MMC\_VOLTAGE_ERROR | The interface doesn't support the requested voltage. |
-| MMC\_INVALID_COMMAND | The interface haven't accepted some command. |
-| MMC\_ERASE_ERROR | Error erasing the current card. |
-| MMC\_ADDR_ERROR | Tried to access an invalid address. |
-
-#### Header file
-
-```c
-#include "mmc/mmc.h"
-```
-
-#### <a name="Example"></a>Example
-
-This example runs on the STM32F4-Discovery and prints out a listing of
-the root directory on the currently installed card.
-
-```c
-// NOTE: error handling removed for clarity!
-
-struct stm32f4_hal_spi_cfg spi_cfg = {
- .ss_pin = SPI_SS_PIN,
- .sck_pin = SPI_SCK_PIN,
- .miso_pin = SPI_MISO_PIN,
- .mosi_pin = SPI_MOSI_PIN,
- .irq_prio = 2
-};
-
-mmc_init(0, &spi_cfg, spi_cfg.ss_pin);
-disk_register("mmc0", "fatfs", &mmc_ops);
-
-fs_opendir("mmc0:/", &dir);
-
-while (1) {
- rc = fs_readdir(dir, &dirent);
- if (rc == FS_ENOENT) {
- break;
- }
-
- fs_dirent_name(dirent, sizeof(out_name), out_name, &u8_len);
- printf("%s\n", out_name);
-}
-
-fs_closedir(dir);
-```
diff --git a/docs/os/modules/elua/elua.md b/docs/os/modules/elua/elua.md
deleted file mode 100644
index 3c8f044..0000000
--- a/docs/os/modules/elua/elua.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# elua
-
-
-### Description
-
-This package contains a Lua interpreter. See http://lua.org for documentation of the language.
-
-You can execute lua scripts either from console with shell or start the execution programmatically.
-
-### Data structures
-
-### Notes
-
-Currently we don't have language extension modules which would go together with this one, but those should be added.
-
-### List of Functions
-
-| Function | Description |
-|---------|-------------|
-| [lua_init](lua_init.md) | Registers 'lua' command with shell. |
-| [lua_main](lua_main.md) | Executes lua script in current task's context. Arguments given are passed to lua interpreter. |
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
diff --git a/docs/os/modules/elua/lua_init.md b/docs/os/modules/elua/lua_init.md
deleted file mode 100644
index b0d1e93..0000000
--- a/docs/os/modules/elua/lua_init.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> lua_init </font>
-
-```no-highlight
- int
- lua_init(void)
-```
-
- Registers 'lua' command with shell. This function should be called while initializing the project, preferably after shell itself has been initialized.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-Returns
-
-#### Notes
-
-Calling this is meaningful only if you include the shell package in your project.
-
-#### Example
-
-```no-highlight
-int main(int argc, char **argv)
-{
- ...
- shell_task_init(SHELL_TASK_PRIO, shell_stack, SHELL_TASK_STACK_SIZE,
- SHELL_MAX_INPUT_LEN);
- ...
- lua_init();
- ...
-}
-```
-
-
diff --git a/docs/os/modules/elua/lua_main.md b/docs/os/modules/elua/lua_main.md
deleted file mode 100644
index 482f55c..0000000
--- a/docs/os/modules/elua/lua_main.md
+++ /dev/null
@@ -1,35 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> lua_main </font>
-
-```no-highlight
- int
- lua_main(int argc, char **argv)
-```
-
- Executes lua script in current task's context. Arguments given are passed to lua interpreter.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| argc | Number of elements in argv array |
-| argv | Array of character strings |
-
-#### Returned values
-
-Returns the return code from the lua interpreter.
-
-#### Notes
-
-
-#### Example
-
-```no-highlight
-static int
-lua_cmd(int argc, char **argv)
-{
- lua_main(argc, argv);
- return 0;
-}
-```
-
-
diff --git a/docs/os/modules/fcb/fcb.md b/docs/os/modules/fcb/fcb.md
deleted file mode 100644
index 45ff64d..0000000
--- a/docs/os/modules/fcb/fcb.md
+++ /dev/null
@@ -1,100 +0,0 @@
-# Flash Circular Buffer (FCB)
-
-Flash circular buffer provides an abstration through which you can treat flash like a FIFO. You append entries to the end, and read data from the beginning.
-
-### Description
-
-Elements in the flash contain the length of the element, the data within the element, and checksum over the element contents.
-
-Storage of elements in flash is done in a FIFO fashion. When user requests space for the next element, space is located at the end of the used area. When user starts reading, the first element served is the oldest element in flash.
-
-Elements can be appended to the end of the area until storage space is exhausted. User has control over what happens next; either erase oldest block of data, thereby freeing up some space, or stop writing new data until existing data has been collected. FCB treats underlying storage as an array of flash sectors; when it erases old data, it does this a sector at a time.
-
-Elements in the flash are checksummed. That is how FCB detects whether writing element to flash completed ok. It will skip over entries which don't have a valid checksum.
-
-### Usage
-
-To add an element to circular buffer:
-
-* Call fcb_append() to get the location where data can be written. If this fails due to lack of space, you can call fcb_rotate() to make some. And then call fcb_append() again.
-* Use flash_area_write() to write element contents.
-* Call fcb_append_finish() when done. This completes the entry by calculating the checksum.
-
-To read contents of the circular buffer:
-* Call fcb_walk() with a pointer to your callback function.
-* Within callback function copy in data from the element using flash_area_read(). You can tell when all data from within a sector has been read by monitoring returned element's area pointer. Then you can call fcb_rotate(), if you're done with that data.
-
-Alternatively:
-* Call fcb_getnext() with 0 in element offset to get the pointer to oldest element.
-* Use flash_area_read() to read element contents.
-* Call fcb_getnext() with pointer to current element to get the next one. And so on.
-
-### Data structures
-
-This data structure describes the element location in the flash. You would use it figure out what parameters to pass to flash_area_read() to read element contents. Or to flash_area_write() when adding a new element.
-
-```c
-struct fcb_entry {
- struct flash_area *fe_area;
- uint32_t fe_elem_off;
- uint32_t fe_data_off;
- uint16_t fe_data_len;
-};
-```
-
-| Element | Description |
-|---------|-------------|
-| fe_area | Pointer to info about the flash sector. Pass this to flash_area_xx() routines. |
-| fe_elem_off | Byte offset from the start of the sector to beginning of element. |
-| fe_data_off | Byte offset from start of the sector to beginning of element data. Pass this to to flash_area_xx() routines. |
-| fe_data_len | Number of bytes in the element. |
-
-
-The following data structure describes the FCB itself. First part should be filled in by the user before calling fcb_init(). The second part is used by FCB for its internal bookkeeping.
-```c
-struct fcb {
- /* Caller of fcb_init fills this in */
- uint32_t f_magic; /* As placed on the disk */
- uint8_t f_version; /* Current version number of the data */
- uint8_t f_sector_cnt; /* Number of elements in sector array */
- uint8_t f_scratch_cnt; /* How many sectors should be kept empty */
- struct flash_area *f_sectors; /* Array of sectors, must be contiguous */
-
- /* Flash circular buffer internal state */
- struct os_mutex f_mtx; /* Locking for accessing the FCB data */
- struct flash_area *f_oldest;
- struct fcb_entry f_active;
- uint16_t f_active_id;
- uint8_t f_align; /* writes to flash have to aligned to this */
-};
-```
-
-| Element | Description |
-|---------|-------------|
-| f_magic | Magic number in the beginning of FCB flash sector. FCB uses this when determining whether sector contains valid data or not. |
-| f_version | Current version number of the data. Also stored in flash sector header. |
-| f_sector_cnt | Number of elements in the f_sectors array. |
-| f_scratch_cnt | Number of sectors to keep empty. This can be used if you need to have scratch space for garbage collecting when FCB fills up. |
-| f_sectors | Array of entries describing flash sectors to use. |
-| f_mtx | Lock protecting access to FCBs internal data. |
-| f_oldest | Pointer to flash sector containing the oldest data. This is where data is served when read is started. |
-| f_active | Flash location where the newest data is. This is used by fcb_append() to figure out where the data should go to. |
-| f_active_id | Flash sectors are assigned ever-increasing serial numbers. This is how FCB figures out where oldest data is on system restart. |
-| f_align | Some flashes have restrictions on alignment for writes. FCB keeps a copy of this number for the flash here. |
-
-### List of Functions
-
-The functions available in this OS feature are:
-
-| Function | Description |
-|---------|-------------|
-| [fcb_init](fcb_init.md) | Initializes the FCB. After calling this, you can start reading/writing data from FCB. |
-| [fcb_append](fcb_append.md) | Start writing a new element to flash. |
-| [fcb_append_finish](fcb_append_finish.md) | Finalizes the write of new element. FCB computes the checksum over the element and updates it in flash. |
-| [fcb_walk](fcb_walk.md) | Walks over all log entries in FCB. |
-| [fcb_getnext](fcb_getnext.md) | Fills given FCB location with information about next element. |
-| [fcb_rotate](fcb_rotate.md) | Erase the oldest sector in FCB. |
-| [fcb_append_to_scratch](fcb_append_to_scratch.md) | If FCB uses scratch blocks, use reserve blocks when FCB is filled. |
-| [fcb_is_empty](fcb_is_empty.md) | Returns 1 if there are no elements stored in FCB, otherwise returns 0. |
-| [fcb_offset_last_n](fcb_offset_last_n.md) | Returns the offset of n-th last element. |
-| [fcb_clear](fcb_clear.md) | Wipes out all data in FCB. |
diff --git a/docs/os/modules/fcb/fcb_append.md b/docs/os/modules/fcb/fcb_append.md
deleted file mode 100644
index b79e75a..0000000
--- a/docs/os/modules/fcb/fcb_append.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_append</font>
-
-```no-highlight
-int fcb_append(struct fcb *fcb, uint16_t len, struct fcb_entry *append_loc);
-```
-
-Start writing a new element to flash. This routine reserves the space in the flash by writing out the element header.
-
-When writing the contents for the entry, use append_loc->fl_area and append_loc->fl_data_off as arguments to flash_area_write(). When finished, call fcb_append_finish() with append_loc as argument.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB where data is written to. |
-| len | Number of bytes to reserve for the element. |
-| loc | Pointer to fcb_entry. fcb_append() will fill this with info about where the element can be written to. |
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-FCB_ERR_NOSPACE is returned if FCB is full.
-
-#### Notes
-
-If FCB is full, you need to make more space. This can be done by calling fcb_rotate(). Or if you've reserved scratch sectors, you can take those into use by calling fcb_append_to_scratch().
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_append_finish.md b/docs/os/modules/fcb/fcb_append_finish.md
deleted file mode 100644
index ab44e3a..0000000
--- a/docs/os/modules/fcb/fcb_append_finish.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_append_finish</font>
-
-```no-highlight
-int fcb_append_finish(struct fcb *fcb, struct fcb_entry *append_loc);
-```
-
-Finalizes the write of new element. FCB computes the checksum over the element and updates it in flash.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB where data is written to. |
-| append_loc | Pointer to fcb_entry. Use the fcb_entry returned by fcb_append(). |
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-
-#### Notes
-
-You need to call fcb_append_finish() after writing the element contents. Otherwise FCB will consider this entry to be invalid, and skips over it when reading.
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_append_to_scratch.md b/docs/os/modules/fcb/fcb_append_to_scratch.md
deleted file mode 100644
index d23fdc1..0000000
--- a/docs/os/modules/fcb/fcb_append_to_scratch.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_append_to_scratch</font>
-
-```no-highlight
-int fcb_append_to_scratch(struct fcb *fcb);
-```
-
-This can be used if FCB created to have scratch block(s). Once FCB fills up with data, fcb_append() will fail. This routine can be called to start using the reserve block.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB. |
-
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-
-#### Notes
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_clear.md b/docs/os/modules/fcb/fcb_clear.md
deleted file mode 100644
index 9e15b28..0000000
--- a/docs/os/modules/fcb/fcb_clear.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_clear</font>
-
-```no-highlight
-int fcb_clear(struct fcb *fcb);
-```
-
-Wipes out all data in FCB.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB. |
-
-
-#### Returned values
-
-Returns 0 on success; non-zero otherwise.
-
-#### Notes
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_getnext.md b/docs/os/modules/fcb/fcb_getnext.md
deleted file mode 100644
index bd2b8c0..0000000
--- a/docs/os/modules/fcb/fcb_getnext.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_getnext</font>
-
-```no-highlight
-int fcb_getnext(struct fcb *, struct fcb_entry *loc);
-```
-
-Given element in location in loc, return with loc filled in with information about next element.
-
-If loc->le_elem_off is set to 0, fcb_getnext() will return info about the oldest element in FCB.
-
-Entry data can be read within the callback using flash_area_read(), using loc->fe_area, loc->fe_data_off, and loc->fe_data_len as arguments.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB where data is written to. |
-| loc | Info about element. On successful call
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-Returns FCB_ERR_NOVAR when there are no more elements left.
-
-#### Notes
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_init.md b/docs/os/modules/fcb/fcb_init.md
deleted file mode 100644
index 7ad76d5..0000000
--- a/docs/os/modules/fcb/fcb_init.md
+++ /dev/null
@@ -1,25 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_init</font>
-
-```no-highlight
-int fcb_init(struct fcb *);
-```
-
-Initializes FCB. This function walks through the given sectors, finding out how much data already exists in the flash.
-After calling this, you can start reading/writing data from FCB.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Structure describing the FCB. |
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-
-#### Notes
-
-User should fill in their portion of fcb before calling this function.
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_is_empty.md b/docs/os/modules/fcb/fcb_is_empty.md
deleted file mode 100644
index b18a598..0000000
--- a/docs/os/modules/fcb/fcb_is_empty.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_is_empty</font>
-
-```no-highlight
-int fcb_is_empty(struct fcb *fcb);
-```
-
-Returns 1 if there are no elements stored in FCB, otherwise returns 0.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB. |
-
-
-#### Returned values
-
-See description.
-
-#### Notes
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_offset_last_n.md b/docs/os/modules/fcb/fcb_offset_last_n.md
deleted file mode 100644
index 8eebb59..0000000
--- a/docs/os/modules/fcb/fcb_offset_last_n.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_offset_last_n</font>
-
-```no-highlight
-int fcb_offset_last_n(struct fcb *fcb, uint8_t entries, uint32_t *last_n_off);
-```
-
-Returns the offset of n-th last element.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB. |
-| entries | How many entries to leave. |
-| last_n_off | Returned offset. |
-
-
-#### Returned values
-
-0 on success; non-zero on failure.
-
-#### Notes
-
-Returned offset is relative to beginning of the sector where the element is.
-Therefore, n-th last element must be found within the last sector of FCB.
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_rotate.md b/docs/os/modules/fcb/fcb_rotate.md
deleted file mode 100644
index 2aebbea..0000000
--- a/docs/os/modules/fcb/fcb_rotate.md
+++ /dev/null
@@ -1,22 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_rotate</font>
-
-```no-highlight
-int fcb_rotate(struct fcb *fcb);
-```
-
-Erase the oldest sector in FCB.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB. |
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-
-#### Notes
-
-#### Example
-
diff --git a/docs/os/modules/fcb/fcb_walk.md b/docs/os/modules/fcb/fcb_walk.md
deleted file mode 100644
index 949c6f2..0000000
--- a/docs/os/modules/fcb/fcb_walk.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fcb_walk</font>
-
-```no-highlight
-typedef int (*fcb_walk_cb)(struct fcb_entry *loc, void *arg);
-
-int fcb_walk(struct fcb *fcb, struct flash_area *area, fcb_walk_cb cb,
- void *cb_arg);
-```
-
-Walks over all log entries in FCB. Callback function cb gets called for every entry. If cb wants to stop the walk, it should return a non-zero value.
-
-If specific flash_area is specified, only entries within that sector are walked over.
-
-Entry data can be read within the callback using flash_area_read(), using loc->fe_area, loc->fe_data_off, and loc->fe_data_len as arguments.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fcb | Points to FCB where data is written to. |
-| area | Optional. Pointer to specific entry in fcb's array of sectors. |
-| cb | Callback function which gets called for every valid entry fcb_walk encounters. |
-| cb_arg | Optional. Parameter which gets passed to callback function.
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-
-#### Notes
-
-#### Example
-
diff --git a/docs/os/modules/fs/fatfs.md b/docs/os/modules/fs/fatfs.md
deleted file mode 100644
index 4ec72ff..0000000
--- a/docs/os/modules/fs/fatfs.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# The FAT File System
-
-Mynewt provides an implementation of the FAT filesystem which is currently
-supported on MMC/SD cards.
-
-### Description
-
-> File Allocation Table (FAT) is a computer file system architecture and a family
-> of industry-standard file systems utilizing it. The FAT file system is a legacy
-> file system which is simple and robust. It offers good performance even in
-> lightweight implementations, but cannot deliver the same performance, reliability
-> and scalability as some modern file systems.
-
-### Configuration
-
-`fatfs` configuration can be tweaked by editing `fs/fatfs/include/fatfs/ffconf.h`.
-The current configuraton was chosen to minimize memory use and some options address
-limitations existing in the OS:
-
-* Write support is enabled by default (can be disabled to minimize memory use).
-* Long filename (up to 255) support is disabled.
-* When writing files, time/dates are not persisted due to current lack of a
- standard `hal_rtc` interface.
-* No unicode support. Vanilla config uses standard US codepage 437.
-* Formatting of new volumes is disabled.
-* Default number of volumes is configured to 1.
-
-### API
-
-To include `fatfs` on a project just include it as a dependency in your
-project:
-
-```
-pkg.deps:
- - fs/fatfs
-```
-
-It can now be used through the standard file system abstraction functions as
-described in [FS API](/os/modules/fs/fs/fs#API).
-
-#### Example
-
-An example of using `fatfs` on a MMC card is provided on the
-[MMC](/os/modules/drivers/mmc#Example) documentation.
diff --git a/docs/os/modules/fs/fs/fs.md b/docs/os/modules/fs/fs/fs.md
deleted file mode 100644
index 5cca0d6..0000000
--- a/docs/os/modules/fs/fs/fs.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# File System Abstraction
-
-Mynewt provides a file system abstraction layer (`fs/fs`) to allow client code to be file system agnostic. By accessing the file system via the `fs/fs` API, client code can perform file system operations without being tied to a particular implementation. When possible, library code should use the `fs/fs` API rather than accessing the underlying file system directly.
-
-### Description
-
-Applications should aim to minimize the amount of code which depends on a particular file system implementation. When possible, only depend on the
-`fs/fs` package.
-In terms of the Mynewt hierarchy, an **app** package must depend on a specific file system package, while **library** packages should only depend on `fs/fs`.
-
-Applications wanting to access a filesystem are required to include the necessary packages in their applications pkg.yml file.
-In the following example, the [`Newtron Flash File System`](../nffs/nffs.md)
-is used.
-
-```no-highlight
-# repos/apache-mynewt-core/apps/slinky/pkg.yml
-
-pkg.name: repos/apache-mynewt-core/apps/slinky
-pkg.deps:
- - fs/fs # include the file operations interfaces
- - fs/nffs # include the NFFS filesystem implementation
-```
-
-```
-# repos/apache-mynewt-core/apps/slinky/syscfg.yml
-# [...]
- # Package: apps/<example app>
-# [...]
- CONFIG_NFFS: 1 # initialize and configure NFFS into the system
-# NFFS_DETECT_FAIL: 1 # Ignore NFFS detection issues
-# NFFS_DETECT_FAIL: 2 # Format a new NFFS file system on failure to detect
-
-# [...]
-```
-Consult the documentation for [`nffs`](../nffs/nffs.md) for a more detailed explanation of NFFS_DETECT_FAIL
-
-Code which uses the file system after the system has been initialized need only depend on `fs/fs`. For example, the `libs/imgmgr` package is a library which provides firmware upload and download functionality via the use of a file system. This library is only used after the system has been initialized, and therefore only depends on the `fs/fs` package.
-
-```no-highlight
-# repos/apache-mynewt-core/libs/imgmgr/pkg.yml
-pkg.name: libs/imgmgr
-pkg.deps:
- - fs/fs
-
-# [...]
-```
-
-The `libs/imgmgr` package uses the `fs/fs` API for all file system operations.
-
-### Support for multiple filesystems
-
-When using a single filesystem/disk, it is valid to provide paths in the standard
-unix way, eg, `/<dir-name>/<file-name>`. When trying to run more than one filesystem
-or a single filesystem in multiple devices simultaneosly, an extra name has to be
-given to the disk that is being used. The abstraction for that was added as the
-`fs/disk` package which is a dependency of `fs/fs`. It adds the following extra
-user function:
-
-```c
-int disk_register(const char *disk_name, const char *fs_name, struct disk_ops *dops)
-```
-
-As an example os usage:
-
-```c
-disk_register("mmc0", "fatfs", &mmc_ops);
-disk_register("flash0", "nffs", NULL);
-```
-
-This registers the name `mmc0` to use `fatfs` as the filesystem and `mmc_ops` for
-the low-level disk driver and also registers `flash0` to use `nffs`. `nffs` is
-currently strongly bound to the `hal_flash` interface, ignoring any other possible
-`disk_ops` given.
-
-#### struct disk_ops
-
-To support a new low-level disk interface, the `struct disk_ops` interface must
-be implemented by the low-level driver. Currently only `read` and `write` are
-effectively used (by `fatfs`).
-
-```c
-struct disk_ops {
- int (*read)(uint8_t, uint32_t, void *, uint32_t);
- int (*write)(uint8_t, uint32_t, const void *, uint32_t);
- int (*ioctl)(uint8_t, uint32_t, void *);
- SLIST_ENTRY(disk_ops) sc_next;
-}
-```
-
-### Thread Safety
-
-All `fs/fs` functions are thread safe.
-
-### Header Files
-
-All code which uses the `fs/fs` package needs to include the following header:
-
-```c
-#include "fs/fs.h"
-```
-
-### Data Structures
-All `fs/fs` data structures are opaque to client code.
-
-```c
-struct fs_file;
-struct fs_dir;
-struct fs_dirent;
-```
-
-### <a name="API"></a>API
-
-Functions in `fs/fs` that indicate success or failure do so with the following set of return codes:
-
-* [Return Codes](fs_return_codes.md)
-
-The functions available in this OS feature are:
-
-| Function | Description |
-|---------|-------------|
-| [fs\_close](fs_close.md) | Closes the specified file and invalidates the file handle. |
-| [fs\_closedir](fs_closedir.md) | Closes the specified directory handle. |
-| [fs\_dirent\_is\_dir](fs_dirent_is_dir.md) | Tells you whether the specified directory entry is a sub-directory or a regular file. |
-| [fs\_dirent\_name](fs_dirent_name.md) | Retrieves the filename of the specified directory entry. |
-| [fs\_filelen](fs_filelen.md) | Retrieves the current length of the specified open file. |
-| [fs\_getpos](fs_getpos.md) | Retrieves the current read and write position of the specified open file. |
-| [fs\_mkdir](fs_mkdir.md) | Creates the directory represented by the specified path. |
-| [fs\_open](fs_open.md) | Opens a file at the specified path. |
-| [fs\_opendir](fs_opendir.md) | Opens the directory at the specified path. |
-| [fs\_read](fs_read.md) | Reads data from the specified file. |
-| [fs\_readdir](fs_readdir.md) | Reads the next entry in an open directory. |
-| [fs\_register](fs_register.md) | Registers a file system with the abstraction layer. |
-| [fs\_rename](fs_rename.md) | Performs a rename and/or move of the specified source path to the specified destination. |
-| [fs\_seek](fs_seek.md) | Positions a file's read and write pointer at the specified offset. |
-| [fs\_unlink](fs_unlink.md) | Unlinks the file or directory at the specified path. |
-| [fs\_write](fs_write.md) | Writes the supplied data to the current offset of the specified file handle. |
-
-Additional file system utilities that bundle some of the basic functions above are:
-
-| Function | Description |
-|---------|-------------|
-| [fsutil\_read\_file](fsutil_read_file.md) | Opens a file at the specified path, retrieve data from the file starting from the specified offset, and close the file and invalidate the file handle. |
-| [fsutil\_write\_file](fsutil_write_file.md) | Open a file at the specified path, write the supplied data to the current offset of the specified file handle, and close the file and invalidate the file handle. |
diff --git a/docs/os/modules/fs/fs/fs_close.md b/docs/os/modules/fs/fs/fs_close.md
deleted file mode 100644
index d546e74..0000000
--- a/docs/os/modules/fs/fs/fs_close.md
+++ /dev/null
@@ -1,61 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_close</font>
-
-```c
-int fs_close(struct fs_file *file)
-```
-
-Closes the specified file and invalidates the file handle.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| file | Pointer to the file to close |
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Notes
-
-If the file has already been unlinked, and the file has no other open handles, the `fs_close()` function causes the file to be deleted from the disk.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-The below code opens the file `/settings/config.txt` for reading, reads some data, and then closes the file.
-
-```c
-int
-read_config(void)
-{
- struct fs_file *file;
- uint32_t bytes_read;
- uint8_t buf[16];
- int rc;
-
- /* Open the file for reading. */
- rc = fs_open("/settings/config.txt", FS_ACCESS_READ, &file);
- if (rc != 0) {
- return -1;
- }
-
- /* Read up to 16 bytes from the file. */
- rc = fs_read(file, sizeof buf, buf, &bytes_read);
- if (rc == 0) {
- /* buf now contains up to 16 bytes of file data. */
- console_printf("read %u bytes\n", bytes_read)
- }
-
- /* Close the file. */
- fs_close(file);
-
- return rc == 0 ? 0 : -1;
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_closedir.md b/docs/os/modules/fs/fs/fs_closedir.md
deleted file mode 100644
index 46614f5..0000000
--- a/docs/os/modules/fs/fs/fs_closedir.md
+++ /dev/null
@@ -1,77 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_closedir</font>
-
-```c
-int fs_closedir(struct fs_dir *dir)
-```
-
-Closes the specified directory handle.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| dir | The name of the directory to close |
-
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-This example iterates through the contents of a directory, printing the name of each child node. When the traversal is complete, the code closes the directory handle.
-
-```c
-int
-traverse_dir(const char *dirname)
-{
- struct fs_dirent *dirent;
- struct fs_dir *dir;
- char buf[64];
- uint8_t name_len;
- int rc;
-
- rc = fs_opendir(dirname, &dir);
- if (rc != 0) {
- return -1;
- }
-
- /* Iterate through the parent directory, printing the name of each child
- * entry. The loop only terminates via a function return.
- */
- while (1) {
- /* Retrieve the next child node. */
- rc = fs_readdir(dir, &dirent);
- if (rc == FS_ENOENT) {
- /* Traversal complete. */
- return 0;
- } else if (rc != 0) {
- /* Unexpected error. */
- return -1;
- }
-
- /* Read the child node's name from the file system. */
- rc = fs_dirent_name(dirent, sizeof buf, buf, &name_len);
- if (rc != 0) {
- return -1;
- }
-
- /* Print the child node's name to the console. */
- if (fs_dirent_is_dir(dirent)) {
- console_printf(" dir: ");
- } else {
- console_printf("file: ");
- }
- console_printf("%s\n", buf);
- }
-}
-```
-
-
diff --git a/docs/os/modules/fs/fs/fs_dirent_is_dir.md b/docs/os/modules/fs/fs/fs_dirent_is_dir.md
deleted file mode 100644
index e615882..0000000
--- a/docs/os/modules/fs/fs/fs_dirent_is_dir.md
+++ /dev/null
@@ -1,75 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_dirent\_is\_dir</font>
-
-```c
-int fs_dirent_is_dir(const struct fs_dirent *dirent)
-```
-
-Tells you whether the specified directory entry is a sub-directory or a regular file.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| dirent | Pointer to the directory entry to query |
-
-
-#### Returned values
-
-* 1: The entry is a directory
-* 0: The entry is a regular file.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-This example iterates through the contents of a directory, printing the name of each child node. When the traversal is complete, the code closes the directory handle.
-
-```c
-int
-traverse_dir(const char *dirname)
-{
- struct fs_dirent *dirent;
- struct fs_dir *dir;
- char buf[64];
- uint8_t name_len;
- int rc;
-
- rc = fs_opendir(dirname, &dir);
- if (rc != 0) {
- return -1;
- }
-
- /* Iterate through the parent directory, printing the name of each child
- * entry. The loop only terminates via a function return.
- */
- while (1) {
- /* Retrieve the next child node. */
- rc = fs_readdir(dir, &dirent);
- if (rc == FS_ENOENT) {
- /* Traversal complete. */
- return 0;
- } else if (rc != 0) {
- /* Unexpected error. */
- return -1;
- }
-
- /* Read the child node's name from the file system. */
- rc = fs_dirent_name(dirent, sizeof buf, buf, &name_len);
- if (rc != 0) {
- return -1;
- }
-
- /* Print the child node's name to the console. */
- if (fs_dirent_is_dir(dirent)) {
- console_printf(" dir: ");
- } else {
- console_printf("file: ");
- }
- console_printf("%s\n", buf);
- }
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_dirent_name.md b/docs/os/modules/fs/fs/fs_dirent_name.md
deleted file mode 100644
index 9788dbc..0000000
--- a/docs/os/modules/fs/fs/fs_dirent_name.md
+++ /dev/null
@@ -1,83 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_dirent\_name</font>
-
-```c
-int fs_dirent_name(const struct fs_dirent *dirent, size_t max_len,
- char *out_name, uint8_t *out_name_len)
-```
-
-Retrieves the filename of the specified directory entry.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| dirent | Pointer to the directory entry to query |
-| max\_len | Size of the "out\_name" character buffer |
-| out\_name | On success, the entry's filename is written here; always null-terminated |
-| out\_name\_len | On success, contains the actual length of the filename, NOT including the null-terminator |
-
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Notes
-
-The retrieved filename is always null-terminated. To ensure enough space to hold the full filename plus a null-termintor, a destination buffer of size _filename-max-length + 1_ should be used.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-This example iterates through the contents of a directory, printing the name of each child node. When the traversal is complete, the code closes the directory handle.
-
-```c
-int
-traverse_dir(const char *dirname)
-{
- struct fs_dirent *dirent;
- struct fs_dir *dir;
- char buf[64];
- uint8_t name_len;
- int rc;
-
- rc = fs_opendir(dirname, &dir);
- if (rc != 0) {
- return -1;
- }
-
- /* Iterate through the parent directory, printing the name of each child
- * entry. The loop only terminates via a function return.
- */
- while (1) {
- /* Retrieve the next child node. */
- rc = fs_readdir(dir, &dirent);
- if (rc == FS_ENOENT) {
- /* Traversal complete. */
- return 0;
- } else if (rc != 0) {
- /* Unexpected error. */
- return -1;
- }
-
- /* Read the child node's name from the file system. */
- rc = fs_dirent_name(dirent, sizeof buf, buf, &name_len);
- if (rc != 0) {
- return -1;
- }
-
- /* Print the child node's name to the console. */
- if (fs_dirent_is_dir(dirent)) {
- console_printf(" dir: ");
- } else {
- console_printf("file: ");
- }
- console_printf("%s\n", buf);
- }
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_filelen.md b/docs/os/modules/fs/fs/fs_filelen.md
deleted file mode 100644
index 4efe8ca..0000000
--- a/docs/os/modules/fs/fs/fs_filelen.md
+++ /dev/null
@@ -1,58 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_filelen</font>
-
-```c
-int fs_filelen(const struct fs_file *file, uint32_t *out_len)
-```
-
-Retrieves the current length of the specified open file.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| file | Pointer to the file to query |
-| out\_len | On success, the number of bytes in the file gets written here |
-
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-```c
-int
-write_config(void)
-{
- struct fs_file *file;
- int rc;
-
- /* If the file doesn't exist, create it. If it does exist, truncate it to
- * zero bytes.
- */
- rc = fs_open("/settings/config.txt", FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE,
- &file);
- if (rc == 0) {
- /* Write 5 bytes of data to the file. */
- rc = fs_write(file, "hello", 5);
- if (rc == 0) {
- /* The file should now contain exactly five bytes. */
- assert(fs_filelen(file) == 5);
- }
-
- /* Close the file. */
- fs_close(file);
- }
-
- return rc == 0 ? 0 : -1;
-}
-```
-
-
diff --git a/docs/os/modules/fs/fs/fs_getpos.md b/docs/os/modules/fs/fs/fs_getpos.md
deleted file mode 100644
index a73a771..0000000
--- a/docs/os/modules/fs/fs/fs_getpos.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_getpos</font>
-
-```c
-uint32_t fs_getpos(const struct fs_file *file)
-```
-
-Retrieves the current read and write position of the specified open file.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| file | Pointer to the file to query |
-
-#### Returned values
-
-* The file offset, in bytes
-
-#### Notes
-
-If a file is opened in append mode, its write pointer is always positioned at the end of the file. Calling this function on such a file only indicates the read position.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
diff --git a/docs/os/modules/fs/fs/fs_mkdir.md b/docs/os/modules/fs/fs/fs_mkdir.md
deleted file mode 100644
index 12eb626..0000000
--- a/docs/os/modules/fs/fs/fs_mkdir.md
+++ /dev/null
@@ -1,60 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_mkdir</font>
-
-```c
-int fs_mkdir(const char *path)
-```
-
-Creates the directory represented by the specified path.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| path | The name of the directory to create |
-
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure.
-
-#### Notes
-
-All intermediate directories must already exist. The specified path must start with a '/' character.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-This example demonstrates creating a series of nested directories.
-
-```c
-int
-create_path(void)
-{
- int rc;
-
- rc = fs_mkdir("/data");
- if (rc != 0) goto err;
-
- rc = fs_mkdir("/data/logs");
- if (rc != 0) goto err;
-
- rc = fs_mkdir("/data/logs/temperature");
- if (rc != 0) goto err;
-
- rc = fs_mkdir("/data/logs/temperature/current");
- if (rc != 0) goto err;
-
- return 0;
-
-err:
- /* Clean up the incomplete directory tree, if any. */
- fs_unlink("/data");
- return -1;
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_open.md b/docs/os/modules/fs/fs/fs_open.md
deleted file mode 100644
index ec69386..0000000
--- a/docs/os/modules/fs/fs/fs_open.md
+++ /dev/null
@@ -1,78 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fs\_open</font>
-
-```c
-int fs_open(const char *filename, uint8_t access_flags,
- struct fs_file **out_file)
-```
-
-Opens a file at the specified path. The result of opening a nonexistent file depends on the access flags specified. All intermediate directories must already exist.
-
-The access flags are best understood by comparing them to their equivalent mode strings accepted by the C standard library function `fopen()`.
-The mode strings passed to `fopen()` map to `fs_open()`'s access flags as follows:
-
-```no-highlight
-"r" - FS_ACCESS_READ
-"r+" - FS_ACCESS_READ | FS_ACCESS_WRITE
-"w" - FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE
-"w+" - FS_ACCESS_READ | FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE
-"a" - FS_ACCESS_WRITE | FS_ACCESS_APPEND
-"a+" - FS_ACCESS_READ | FS_ACCESS_WRITE | FS_ACCESS_APPEND
-```
-
-#### Arguments
-
-| *Argument* | *Description* |
-|----------|-------------|
-| filename | Null-terminated string indicating the full path of the file to open |
-| access\_flags | Flags controlling file access; see above table |
- out\_file | On success, a pointer to the newly-created file handle gets written here |
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Notes
-
-* There is no concept of current working directory. Therefore all file names should start with '/'.
-
-* Always close files when you are done using them. If you forget to close a file, the file stays open forever. Do this too many times, and the underlying file system will run out of file handles, causing subsequent open operations to fail. This type of bug is known as a file handle leak or a file descriptor leak.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-The below code opens the file `/settings/config.txt` for reading, reads some data, and then closes the file.
-
-```c
-int
-read_config(void)
-{
- struct fs_file *file;
- uint32_t bytes_read;
- uint8_t buf[16];
- int rc;
-
- /* Open the file for reading. */
- rc = fs_open("/settings/config.txt", FS_ACCESS_READ, &file);
- if (rc != 0) {
- return -1;
- }
-
- /* Read up to 16 bytes from the file. */
- rc = fs_read(file, sizeof buf, buf, &bytes_read);
- if (rc == 0) {
- /* buf now contains up to 16 bytes of file data. */
- console_printf("read %u bytes\n", bytes_read)
- }
-
- /* Close the file. */
- fs_close(file);
-
- return rc == 0 ? 0 : -1;
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_opendir.md b/docs/os/modules/fs/fs/fs_opendir.md
deleted file mode 100644
index 89b4c48..0000000
--- a/docs/os/modules/fs/fs/fs_opendir.md
+++ /dev/null
@@ -1,83 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_opendir</font>
-
-```c
-int fs_opendir(const char *path, struct fs_dir **out_dir)
-```
-
-Opens the directory at the specified path. The directory's contents can be read with subsequent calls to fs\_readdir(). When you are done with the directory handle, close it with fs\_closedir().
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| path | The name of the directory to open |
-| out\_dir | On success, points to the directory handle |
-
-
-#### Returned values
-
-* 0 on success
-* FS\_ENOENT if the specified directory does not exist
-* Other [FS error code](fs_return_codes.md) on error.
-
-#### Notes
-
-* Unlinking files from the directory while it is open may result in unpredictable behavior during subsequent calls to `fs_readdir()`. New files can be created inside the directory without causing problems.
-
-* Always close a directory when you are done reading from it. If you forget to close a directory, the directory stays open forever. Do this too many times, and the underlying file system will run out of directory handles, causing subsequent open operations to fail. This type of bug is known as a file handle leak or a file descriptor leak.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-This example iterates through the contents of a directory, printing the name of each child node. When the traversal is complete, the code closes the directory handle.
-
-```c
-int
-traverse_dir(const char *dirname)
-{
- struct fs_dirent *dirent;
- struct fs_dir *dir;
- char buf[64];
- uint8_t name_len;
- int rc;
-
- rc = fs_opendir(dirname, &dir);
- if (rc != 0) {
- return -1;
- }
-
- /* Iterate through the parent directory, printing the name of each child
- * entry. The loop only terminates via a function return.
- */
- while (1) {
- /* Retrieve the next child node. */
- rc = fs_readdir(dir, &dirent);
- if (rc == FS_ENOENT) {
- /* Traversal complete. */
- return 0;
- } else if (rc != 0) {
- /* Unexpected error. */
- return -1;
- }
-
- /* Read the child node's name from the file system. */
- rc = fs_dirent_name(dirent, sizeof buf, buf, &name_len);
- if (rc != 0) {
- return -1;
- }
-
- /* Print the child node's name to the console. */
- if (fs_dirent_is_dir(dirent)) {
- console_printf(" dir: ");
- } else {
- console_printf("file: ");
- }
- console_printf("%s\n", buf);
- }
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_ops.md b/docs/os/modules/fs/fs/fs_ops.md
deleted file mode 100644
index d3d5007..0000000
--- a/docs/os/modules/fs/fs/fs_ops.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">struct fs\_ops</font>
-
-```c
-struct fs_ops {
- int (*f_open)(const char *filename, uint8_t access_flags,
- struct fs_file **out_file);
- int (*f_close)(struct fs_file *file);
- int (*f_read)(struct fs_file *file, uint32_t len, void *out_data,
- uint32_t *out_len);
- int (*f_write)(struct fs_file *file, const void *data, int len);
-
- int (*f_seek)(struct fs_file *file, uint32_t offset);
- uint32_t (*f_getpos)(const struct fs_file *file);
- int (*f_filelen)(const struct fs_file *file, uint32_t *out_len);
-
- int (*f_unlink)(const char *filename);
- int (*f_rename)(const char *from, const char *to);
- int (*f_mkdir)(const char *path);
-
- int (*f_opendir)(const char *path, struct fs_dir **out_dir);
- int (*f_readdir)(struct fs_dir *dir, struct fs_dirent **out_dirent);
- int (*f_closedir)(struct fs_dir *dir);
-
- int (*f_dirent_name)(const struct fs_dirent *dirent, size_t max_len,
- char *out_name, uint8_t *out_name_len);
- int (*f_dirent_is_dir)(const struct fs_dirent *dirent);
-
- const char *f_name;
-};
-```
-
-This data structure consists of a set of function pointers. Each function pointer corresponds to a file system operation. When registering a file system with the abstraction layer, each function pointer must be pointed at the corresponding routine in the custom file system package.
-
-The required behavior of each corresponding function is documented in the [file system abstraction layer API](fs.md#api).
-
-#### Header file
-
-```c
-#include "fs/fs_if.h"
-```
diff --git a/docs/os/modules/fs/fs/fs_read.md b/docs/os/modules/fs/fs/fs_read.md
deleted file mode 100644
index 60a9238..0000000
--- a/docs/os/modules/fs/fs/fs_read.md
+++ /dev/null
@@ -1,61 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_read</font>
-
-```c
-int fs_read(struct fs_file *file, uint32_t len, void *out_data, uint32_t *out_len)
-```
-
-Reads data from the specified file. If more data is requested than remains in the file, all available data is retrieved and a success code is returned.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| file | Pointer to the the file to read from |
-| len | The number of bytes to attempt to read |
-| out\_data | The destination buffer to read into
-| out\_len | On success, the number of bytes actually read gets written here. Pass null if you don't care. |
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-The below code opens the file `/settings/config.txt` for reading, reads some data, and then closes the file.
-
-```c
-int
-read_config(void)
-{
- struct fs_file *file;
- uint32_t bytes_read;
- uint8_t buf[16];
- int rc;
-
- /* Open the file for reading. */
- rc = fs_open("/settings/config.txt", FS_ACCESS_READ, &file);
- if (rc != 0) {
- return -1;
- }
-
- /* Read up to 16 bytes from the file. */
- rc = fs_read(file, sizeof buf, buf, &bytes_read);
- if (rc == 0) {
- /* buf now contains up to 16 bytes of file data. */
- console_printf("read %u bytes\n", bytes_read)
- }
-
- /* Close the file. */
- fs_close(file);
-
- return rc == 0 ? 0 : -1;
-}
-```
-
diff --git a/docs/os/modules/fs/fs/fs_readdir.md b/docs/os/modules/fs/fs/fs_readdir.md
deleted file mode 100644
index 36291a9..0000000
--- a/docs/os/modules/fs/fs/fs_readdir.md
+++ /dev/null
@@ -1,78 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs_readdir</font>
-
-```c
-int fs_readdir(struct fs_dir *dir, struct fs_dirent **out_dirent);
-```
-
-Reads the next entry in an open directory.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| dir | The directory handle to read from |
-| out\_dirent | On success, points to the next child entry in the specified directory |
-
-
-#### Returned values
-
-* 0 on success
-* FS\_ENOENT if there are no more entries in the parent directory
-* Other [FS error code](fs_return_codes.md) on error.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-This example iterates through the contents of a directory, printing the name of each child node. When the traversal is complete, the code closes the directory handle.
-
-```c
-int
-traverse_dir(const char *dirname)
-{
- struct fs_dirent *dirent;
- struct fs_dir *dir;
- char buf[64];
- uint8_t name_len;
- int rc;
-
- rc = fs_opendir(dirname, &dir);
- if (rc != 0) {
- return -1;
- }
-
- /* Iterate through the parent directory, printing the name of each child
- * entry. The loop only terminates via a function return.
- */
- while (1) {
- /* Retrieve the next child node. */
- rc = fs_readdir(dir, &dirent);
- if (rc == FS_ENOENT) {
- /* Traversal complete. */
- return 0;
- } else if (rc != 0) {
- /* Unexpected error. */
- return -1;
- }
-
- /* Read the child node's name from the file system. */
- rc = fs_dirent_name(dirent, sizeof buf, buf, &name_len);
- if (rc != 0) {
- return -1;
- }
-
- /* Print the child node's name to the console. */
- if (fs_dirent_is_dir(dirent)) {
- console_printf(" dir: ");
- } else {
- console_printf("file: ");
- }
- console_printf("%s\n", buf);
- }
-}
-```
-
diff --git a/docs/os/modules/fs/fs/fs_register.md b/docs/os/modules/fs/fs/fs_register.md
deleted file mode 100644
index 015be79..0000000
--- a/docs/os/modules/fs/fs/fs_register.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fs\_register</font>
-
-```c
-int fs_register(const struct fs_ops *fops)
-```
-
-Registers a file system with the abstraction layer. On success, all calls into `fs/fs` will use the registered file system.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|----------|-------------|
-| fops | A pointer to const [struct fs\_ops](fs_ops.md). Specifies which file system routines get mapped to the `fs/fs` API. All function pointers must be filled in. |
-
-#### Returned values
-
-* 0 on success
-* *FS\_EEXIST* if a file system has already been registered
-
-#### Notes
-
-Only one file system can be registered. The registered file system is mounted in the root directory (*/*).
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
diff --git a/docs/os/modules/fs/fs/fs_rename.md b/docs/os/modules/fs/fs/fs_rename.md
deleted file mode 100644
index a6874bb..0000000
--- a/docs/os/modules/fs/fs/fs_rename.md
+++ /dev/null
@@ -1,66 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_rename</font>
-
-```c
-int fs_rename(const char *from, const char *to)
-```
-
-Performs a rename and / or move of the specified source path to the specified destination. The source path can refer to a file or a directory.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| from | The source path |
-| to | The destination path |
-
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Notes
-
-The source path can refer to either a file or a directory. All intermediate directories in the destination path must already exist. If the source path refers to a file, the destination path must contain a full filename path, rather than just the new parent directory. If an object already exists at the specified destination path, this function causes it to be unlinked prior to the rename (i.e., the destination gets clobbered).
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-This example demonstrates how to use fs\_rename() to perform a log rotation. In this example, there is one primary log and three archived logs. `FS_ENOENT` errors returned by `fs_rename()` are ignored; it is not an error if an archived log was never created.
-
-```c
-int
-rotate_logs(void)
-{
- struct fs_file *file;
- int rc;
-
- /* Rotate each of the log files. */
- rc = fs_rename("/var/log/messages.2", "/var/log/messages.3")
- if (rc != 0 && rc != FS_ENOENT) return -1;
-
- rc = fs_rename("/var/log/messages.1", "/var/log/messages.2")
- if (rc != 0 && rc != FS_ENOENT) return -1;
-
- rc = fs_rename("/var/log/messages.0", "/var/log/messages.1")
- if (rc != 0 && rc != FS_ENOENT) return -1;
-
- rc = fs_rename("/var/log/messages", "/var/log/messages.0")
- if (rc != 0 && rc != FS_ENOENT) return -1;
-
- /* Now create the new log file. */
- rc = fs_open("/var/log/messages", FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE,
- &file);
- if (rc != 0) return -1;
-
- rc = fs_write(file, "Creating new log file.\n", 23);
- fs_close(file);
-
- return rc == 0 ? 0 : -1;
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_return_codes.md b/docs/os/modules/fs/fs/fs_return_codes.md
deleted file mode 100644
index 5830d71..0000000
--- a/docs/os/modules/fs/fs/fs_return_codes.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">fs/fs Return Codes</font>
-
-Functions in `fs/fs` that indicate success or failure do so with the following set of return codes:
-
-| Return code | Description |
-|----------------|----------------------------------------------|
-| FS\_EOK | Success |
-| FS\_ECORRUPT | File system corrupt |
-| FS\_EHW | Error accessing storage medium |
-| FS\_EOFFSET | Invalid offset |
-| FS\_EINVAL | Invalid argument |
-| FS\_ENOMEM | Insufficient memory |
-| FS\_ENOENT | No such file or directory |
-| FS\_EEMPTY | Specified region is empty (internal only) |
-| FS\_EFULL | Disk full |
-| FS\_EUNEXP | Disk contains unexpected metadata |
-| FS\_EOS | OS error |
-| FS\_EEXIST | File or directory already exists |
-| FS\_EACCESS | Operation prohibited by file open mode |
-| FS\_EUNINIT | File system not initialized |
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
diff --git a/docs/os/modules/fs/fs/fs_seek.md b/docs/os/modules/fs/fs/fs_seek.md
deleted file mode 100644
index 0ee0db0..0000000
--- a/docs/os/modules/fs/fs/fs_seek.md
+++ /dev/null
@@ -1,62 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_seek</font>
-
-```c
-int fs_seek(struct fs_file *file, uint32_t offset)
-```
-Positions a file's read and write pointer at the specified offset. The offset is expressed as the number of bytes from the start of the file (i.e., seeking to offset 0 places the pointer at the first byte in the file).
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| file | Pointer to the file to reposition |
-| offset | The 0-based file offset to seek to |
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Notes
-
-If a file is opened in append mode, its write pointer is always positioned at the end of the file. Calling this function on such a file only affects the read pointer.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-The following example reads four bytes from a file, starting at an offset of eight.
-
-```c
-int
-read_part1_middle(void)
-{
- struct fs_file *file;
- uint32_t bytes_read;
- uint8_t buf[4];
- int rc;
-
- rc = fs_open("/data/parts/1.bin", FS_ACCESS_READ, &file);
- if (rc == 0) {
- /* Advance to offset 8. */
- rc = fs_seek(file, 8);
- if (rc == 0) {
- /* Read bytes 8, 9, 10, and 11. */
- rc = fs_read(file, 4, buf, &bytes_read);
- if (rc == 0) {
- /* buf now contains up to 4 bytes of file data. */
- console_printf("read %u bytes\n", bytes_read)
- }
- }
-
- /* Close the file. */
- fs_close(file);
- }
-
- return rc == 0 ? 0 : -1;
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_unlink.md b/docs/os/modules/fs/fs/fs_unlink.md
deleted file mode 100644
index 8fddba9..0000000
--- a/docs/os/modules/fs/fs/fs_unlink.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_unlink</font>
-
-```c
-int fs_unlink(const char *filename)
-```
-
-Unlinks the file or directory at the specified path. This is the function to use if you want to delete a file or directory from the disk. If the path refers to a directory, all the directory's descendants are recursively unlinked. Any open file handles referring to an unlinked file remain valid, and can be read from and written to as long as they remain open.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| filename | The path of the file or directory to unlink |
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-The following example creates a file and then immediately unlinks it. By unlinking the file, this function prevents other OS tasks from accessing it. When the function closes the file, it is deleted from the disk.
-
-```c
-int
-process_data(void)
-{
- struct fs_file *file;
- int rc;
-
- /* If the file doesn't exist, create it. If it does exist, truncate it to
- * zero bytes.
- */
- rc = fs_open("/tmp/buffer.bin", FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE, &file);
- if (rc == 0) {
- /* Unlink the file so that other tasks cannot access it. */
- fs_unlink("/tmp/buffer.bin")
-
- /* <use the file as a data buffer> */
-
- /* Close the file. This operation causes the file to be deleted from
- * the disk because it was unlinked earlier (and it has no other open
- * file handles).
- */
- fs_close(file);
- }
-
- return rc == 0 ? 0 : -1;
-}
-```
diff --git a/docs/os/modules/fs/fs/fs_write.md b/docs/os/modules/fs/fs/fs_write.md
deleted file mode 100644
index d8f7b24..0000000
--- a/docs/os/modules/fs/fs/fs_write.md
+++ /dev/null
@@ -1,61 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fs\_write</font>
-
-```c
-int fs_write(struct fs_file *file, const void *data, int len)
-```
-
-Writes the supplied data to the current offset of the specified file handle.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| file | Pointer to the file to write to |
-| data | The data to write |
-| len | The number of bytes to write |
-
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Notes
-
-For files opened in append mode, the specified data is always written to the end.
-
-#### Header file
-
-```c
-#include "fs/fs.h"
-```
-
-#### Example
-
-```c
-int
-write_config(void)
-{
- struct fs_file *file;
- int rc;
-
- /* If the file doesn't exist, create it. If it does exist, truncate it to
- * zero bytes.
- */
- rc = fs_open("/settings/config.txt", FS_ACCESS_WRITE | FS_ACCESS_TRUNCATE,
- &file);
- if (rc == 0) {
- /* Write 5 bytes of data to the file. */
- rc = fs_write(file, "hello", 5);
- if (rc == 0) {
- /* The file should now contain exactly five bytes. */
- assert(fs_filelen(file) == 5);
- }
-
- /* Close the file. */
- fs_close(file);
- }
-
- return rc == 0 ? 0 : -1;
-}
-```
diff --git a/docs/os/modules/fs/fs/fsutil_read_file.md b/docs/os/modules/fs/fs/fsutil_read_file.md
deleted file mode 100644
index ac47b72..0000000
--- a/docs/os/modules/fs/fs/fsutil_read_file.md
+++ /dev/null
@@ -1,60 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fsutil\_read\_file</font>
-
-```c
-int fsutil_read_file(const char *path, uint32_t offset, uint32_t len,
- void *dst, uint32_t *out_len)
-```
-
-Calls fs\_open(), fs\_read(), and fs\_close() to open a file at the specified path, retrieve data from the file starting from the specified offset, and close the file and invalidate the file handle.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| path | Pointer to the directory entry to query |
-| offset | Position of the file's read pointer |
-| len | Number of bytes to attempt to read |
-| dst | Destination buffer to read into |
-| out\_len | On success, the number of bytes actually read gets written here. Pass null if you don't care. |
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Notes
-
-This is a convenience function. It is useful when the amount of data to be read from the file is small (i.e., all the data read can easily fit in a single buffer).
-
-#### Header file
-
-```c
-#include "fs/fsutil.h"
-```
-
-#### Example
-
-This example demonstrates reading a small text file in its entirety and printing its contents to the console.
-
-```c
-int
-print_status(void)
-{
- uint32_t bytes_read;
- uint8_t buf[16];
- int rc;
-
- /* Read up to 15 bytes from the start of the file. */
- rc = fsutil_read_file("/cfg/status.txt", 0, sizeof buf - 1, buf,
- &bytes_read);
- if (rc != 0) return -1;
-
- /* Null-terminate the string just read. */
- buf[bytes_read] = '\0';
-
- /* Print the file contents to the console. */
- console_printf("%s\n", buf);
-
- return 0;
-}
-```
diff --git a/docs/os/modules/fs/fs/fsutil_write_file.md b/docs/os/modules/fs/fs/fsutil_write_file.md
deleted file mode 100644
index b6d2790..0000000
--- a/docs/os/modules/fs/fs/fsutil_write_file.md
+++ /dev/null
@@ -1,52 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt">fsutil\_write\_file</font>
-
-```c
-int fsutil_write_file(const char *path, const void *data, uint32_t len)
-```
-
-Calls fs\_open(), fs\_write(), and fs\_close() to open a file at the specified path, write the supplied data to the current offset of the specified file handle, and close the file and invalidate the file handle. If the specified file already exists, it is truncated and overwritten with the specified data.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|-----------|-------------|
-| path | Pointer to the file to write to |
-| data | The data to write |
-| len | The number of bytes to write |
-
-#### Returned values
-
-* 0 on success
-* [FS error code](fs_return_codes.md) on failure
-
-#### Header file
-
-```c
-#include "fs/fsutil.h"
-```
-
-#### Example
-
-This example creates a 4-byte file.
-
-```c
-int
-write_id(void)
-{
- int rc;
-
- /* Create the parent directory. */
- rc = fs_mkdir("/cfg");
- if (rc != 0 && rc != FS_EALREADY) {
- return -1;
- }
-
- /* Create a file and write four bytes to it. */
- rc = fsutil_write_file("/cfg/id.txt", "1234", 4);
- if (rc != 0) {
- return -1;
- }
-
- return 0;
-}
-```
diff --git a/docs/os/modules/fs/nffs/nffs.md b/docs/os/modules/fs/nffs/nffs.md
deleted file mode 100644
index 8650a9a..0000000
--- a/docs/os/modules/fs/nffs/nffs.md
+++ /dev/null
@@ -1,83 +0,0 @@
-# Newtron Flash Filesystem (nffs)
-
-Mynewt includes the Newtron Flash File System (nffs). This file system is designed with two priorities that makes it suitable for embedded use:
-
-* Minimal RAM usage
-* Reliability
-
-Mynewt also provides an abstraction layer API (fs) to allow you to swap out nffs with a different file system of your choice.
-
-### Description
-
-#### Areas
-
-At the top level, an nffs disk is partitioned into *areas*. An area is a region of disk with the following properties:
-
-1. An area can be fully erased without affecting any other areas.
-2. Writing to one area does not restrict writes to other areas.
-
-**Regarding property 1:** Generally, flash hardware divides its memory space into "blocks." When erasing flash, entire blocks must be erased in a single operation; partial erases are not possible.
-
-**Regarding property 2:** Furthermore, some flash hardware imposes a restriction with regards to writes: writes within a block must be strictly sequential. For example, if you wish to write to the first 16 bytes of a block, you must write bytes 1 through 15 before writing byte 16. This restriction only applies at the block level; writes to one block have no effect on what parts of other blocks can be written.
-
-Thus, each area must comprise a discrete number of blocks.
-
-#### Initialization
-
-As part of overall system initialization, mynewt re-initialized the filesystem as follows:
-
-1. Restores an existing file system via detection.
-2. Creates a new file system via formatting.
-
-A typical initialization sequence is the following:
-
-1. Detect an nffs file system in a specific region of flash.
-2. If no file system was detected, if configured to do so, format a new file system in the same flash region.
-
-Note that in the latter case, the behavior is controlled with a variable in the syscfg.yml file. If NFFS_DETECT_FAIL is set to 1, the system ignores NFFS filesystem detection issues, but unless a new filesystem is formatted manually, all filesystem access will fail. If NFFS_DETECT_FAIL is set to 2, the system will format a new filesystem - note however this effectively deletes all existing data in the NFFS flash areas.
-
-Both methods require the user to describe how the flash memory should be divided into nffs areas. This is accomplished with an array of [struct nffs\_area\_desc](nffs_area_desc.md) configured as part of the BSP configureation.
-
-After nffs has been initialized, the application can access the file system via the [file system abstraction layer](../fs/fs.md).
-
-### Data Structures
-
-The `fs/nffs` package exposes the following data structures:
-
-| Struct | Description |
-|---------|-------------|
-| [struct nffs\_area\_desc](nffs_area_desc.md) | Descriptor for a single nffs area. |
-| [struct nffs\_config](nffs_config.md) | Configuration struct for nffs. |
-
-### API
-
-The functions available in this OS feature are:
-
-| Function | Description |
-|---------|-------------|
-| [nffs\_detect](nffs_detect.md) | Searches for a valid nffs file system among the specified areas. |
-| [nffs\_format](nffs_format.md) | Erases all the specified areas and initializes them with a clean nffs file system. |
-| [nffs\_init](nffs_init.md) | Initializes internal nffs memory and data structures. |
-
-### Miscellaneous measures
-
-* RAM usage:
- * 24 bytes per inode
- * 12 bytes per data block
- * 36 bytes per inode cache entry
- * 32 bytes per data block cache entry
-
-* Maximum filename size: 256 characters (no null terminator required)
-* Disallowed filename characters: '/' and '\0'
-
-### Internals
-
-nffs implementation details can be found here:
-
-* [nffs\_internals](nffs_internals.md)
-
-### Future enhancements
-
-* Error correction.
-* Encryption.
-* Compression.
diff --git a/docs/os/modules/fs/nffs/nffs_area_desc.md b/docs/os/modules/fs/nffs/nffs_area_desc.md
deleted file mode 100644
index 2069954..0000000
--- a/docs/os/modules/fs/nffs/nffs_area_desc.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">struct nffs\_area\_desc</font>
-
-```c
-struct nffs_area_desc {
- uint32_t nad_offset; /* Flash offset of start of area. */
- uint32_t nad_length; /* Size of area, in bytes. */
- uint8_t nad_flash_id; /* Logical flash id */
-};
-```
-
-Descriptor for a single nffs area. An area is a region of disk with the following properties:
-
-1. An area can be fully erased without affecting any other areas.
-2. Writing to one area does not restrict writes to other areas.
-
-**Regarding property 1:** Generally, flash hardware divides its memory space into "blocks." When erasing flash, entire blocks must be erased in a single operation; partial erases are not possible.
-
-**Regarding property 2:** Furthermore, some flash hardware imposes a restriction with regards to writes: writes within a block must be strictly sequential. For example, if you wish to write to the first 16 bytes of a block, you must write bytes 1 through 15 before writing byte 16. This restriction only applies at the block level; writes to one block have no effect on what parts of other blocks can be written.
-
-Thus, each area must comprise a discrete number of blocks.
-
-An array of area descriptors is terminated by an entry with a *nad_length* value of 0.
-
-#### Notes
-
-Typically, a product's flash layout is exposed via its BSP-specific `bsp_flash_dev()` function. This function retrieves the layout of the specified flash device resident in the BSP. The result of this function can then be converted into the `struct nffs_area_desc[]` that nffs requires.
-
-#### Header file
-
-```c
-#include "nffs/nffs.h"
-```
diff --git a/docs/os/modules/fs/nffs/nffs_config.md b/docs/os/modules/fs/nffs/nffs_config.md
deleted file mode 100644
index 8f518b5..0000000
--- a/docs/os/modules/fs/nffs/nffs_config.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">struct nffs\_config</font>
-
-```c
-struct nffs_config {
- /** Maximum number of inodes; default=1024. */
- uint32_t nc_num_inodes;
-
- /** Maximum number of data blocks; default=4096. */
- uint32_t nc_num_blocks;
-
- /** Maximum number of open files; default=4. */
- uint32_t nc_num_files;
-
- /** Inode cache size; default=4. */
- uint32_t nc_num_cache_inodes;
-
- /** Data block cache size; default=64. */
- uint32_t nc_num_cache_blocks;
-};
-```
-
-The file system is configured by populating fields in a global `struct nffs_config` instance. Each field in the structure corresponds to a setting. All configuration must be done prior to calling nffs\_init().
-
-Any fields that are set to 0 (or not set at all) inherit the corresponding default value. This means that it is impossible to configure any setting with a value of zero.
-
-#### Notes
-
-The global `struct nffs_config` instance is exposed in `nffs/nffs.h` as follows:
-
-```c
-extern struct nffs_config nffs_config;
-```
-
-#### Header file
-
-```c
-#include "nffs/nffs.h"
-```
diff --git a/docs/os/modules/fs/nffs/nffs_detect.md b/docs/os/modules/fs/nffs/nffs_detect.md
deleted file mode 100644
index 12d64dc..0000000
--- a/docs/os/modules/fs/nffs/nffs_detect.md
+++ /dev/null
@@ -1,73 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">nffs\_detect</font>
-
-```c
-int nffs_detect(const struct nffs_area_desc *area_descs)
-```
-
-Searches for a valid nffs file system among the specified areas. This function succeeds if a file system is detected among any subset of the supplied areas. If the area set does not contain a valid file system, a new one can be created via a separate call to nffs\_format().
-
-#### Arguments
-
-| *Argument* | *Description* |
-|---------------|-------------------------------|
-| area\_descs | The set of areas to search. This array must be terminated with a 0-length area. |
-
-#### Returned values
-
-* 0 on success
-* FS\_ECORRUPT if no valid file system was detected
-* Other [FS error code](../fs/fs_return_codes.md) on failure
-
-#### Header file
-
-```c
-#include "nffs/nffs.h"
-```
-
-#### Example
-
-```c
-/*** hw/hal/include/hal/flash_map.h */
-
-/*
- * Flash area types
- */
-#define FLASH_AREA_BOOTLOADER 0
-#define FLASH_AREA_IMAGE_0 1
-#define FLASH_AREA_IMAGE_1 2
-#define FLASH_AREA_IMAGE_SCRATCH 3
-#define FLASH_AREA_NFFS 4
-```
-
-```c
-/*** project/slinky/src/main.c */
-
-int
-main(int argc, char **argv)
-{
- int rc;
- int cnt;
-
- /* NFFS_AREA_MAX is defined in the BSP-specified bsp.h header file. */
- struct nffs_area_desc descs[NFFS_AREA_MAX];
-
- /* Initialize nffs's internal state. */
- rc = nffs_init();
- assert(rc == 0);
-
- /* Convert the set of flash blocks we intend to use for nffs into an array
- * of nffs area descriptors.
- */
- cnt = NFFS_AREA_MAX;
- rc = flash_area_to_nffs_desc(FLASH_AREA_NFFS, &cnt, descs);
- assert(rc == 0);
-
- /* Attempt to restore an existing nffs file system from flash. */
- if (nffs_detect(descs) == FS_ECORRUPT) {
- /* No valid nffs instance detected; format a new one. */
- rc = nffs_format(descs);
- assert(rc == 0);
- }
- /* [ ... ] */
-}
-```
diff --git a/docs/os/modules/fs/nffs/nffs_format.md b/docs/os/modules/fs/nffs/nffs_format.md
deleted file mode 100644
index c871b1f..0000000
--- a/docs/os/modules/fs/nffs/nffs_format.md
+++ /dev/null
@@ -1,72 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">nffs\_format</font>
-
-```c
-int nffs_format(const struct nffs_area_desc *area_descs)
-```
-
-Erases all the specified areas and initializes them with a clean nffs file system.
-
-#### Arguments
-
-| *Argument* | *Description* |
-|---------------|-------------------------------|
-| area\_descs | The set of areas to format |
-
-#### Returned values
-
-* 0 on success
-* [FS error code](../fs/fs_return_codes.md) on failure.
-
-#### Header file
-
-```c
-#include "nffs/nffs.h"
-```
-
-#### Example
-
-```c
-/*** hw/hal/include/hal/flash_map.h */
-
-/*
- * Flash area types
- */
-#define FLASH_AREA_BOOTLOADER 0
-#define FLASH_AREA_IMAGE_0 1
-#define FLASH_AREA_IMAGE_1 2
-#define FLASH_AREA_IMAGE_SCRATCH 3
-#define FLASH_AREA_NFFS 4
-```
-
-```c
-/*** project/slinky/src/main.c */
-
-int
-main(int argc, char **argv)
-{
- int rc;
- int cnt;
-
- /* NFFS_AREA_MAX is defined in the BSP-specified bsp.h header file. */
- struct nffs_area_desc descs[NFFS_AREA_MAX];
-
- /* Initialize nffs's internal state. */
- rc = nffs_init();
- assert(rc == 0);
-
- /* Convert the set of flash blocks we intend to use for nffs into an array
- * of nffs area descriptors.
- */
- cnt = NFFS_AREA_MAX;
- rc = flash_area_to_nffs_desc(FLASH_AREA_NFFS, &cnt, descs);
- assert(rc == 0);
-
- /* Attempt to restore an existing nffs file system from flash. */
- if (nffs_detect(descs) == FS_ECORRUPT) {
- /* No valid nffs instance detected; format a new one. */
- rc = nffs_format(descs);
- assert(rc == 0);
- }
- /* [ ... ] */
-}
-```
diff --git a/docs/os/modules/fs/nffs/nffs_init.md b/docs/os/modules/fs/nffs/nffs_init.md
deleted file mode 100644
index 3d1cd19..0000000
--- a/docs/os/modules/fs/nffs/nffs_init.md
+++ /dev/null
@@ -1,18 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">nffs\_init</font>
-
-```c
-int nffs_init(void)
-```
-
-Initializes internal nffs memory and data structures. This must be called before any nffs operations are attempted.
-
-#### Returned values
-
-* 0 on success
-* [FS error code](../fs/fs_return_codes.md) on failure
-
-#### Header file
-
-```c
-#include "nffs/nffs.h"
-```
diff --git a/docs/os/modules/fs/nffs/nffs_internals.md b/docs/os/modules/fs/nffs/nffs_internals.md
deleted file mode 100644
index e348a0e..0000000
--- a/docs/os/modules/fs/nffs/nffs_internals.md
+++ /dev/null
@@ -1,318 +0,0 @@
-# Internals of nffs
-### Disk structure
-On disk, each area is prefixed with the following header:
-
-```c
-/** On-disk representation of an area header. */
-struct nffs_disk_area {
- uint32_t nda_magic[4]; /* NFFS_AREA_MAGIC{0,1,2,3} */
- uint32_t nda_length; /* Total size of area, in bytes. */
- uint8_t nda_ver; /* Current nffs version: 0 */
- uint8_t nda_gc_seq; /* Garbage collection count. */
- uint8_t reserved8;
- uint8_t nda_id; /* 0xff if scratch area. */
-};
-```
-
-Beyond its header, an area contains a sequence of disk objects, representing the contents of the file system. There are two types of objects: *inodes* and *data blocks*. An inode represents a file or directory; a data block represents part of a file's contents.
-
-```c
-/** On-disk representation of an inode (file or directory). */
-struct nffs_disk_inode {
- uint32_t ndi_magic; /* NFFS_INODE_MAGIC */
- uint32_t ndi_id; /* Unique object ID. */
- uint32_t ndi_seq; /* Sequence number; greater supersedes
- lesser. */
- uint32_t ndi_parent_id; /* Object ID of parent directory inode. */
- uint8_t reserved8;
- uint8_t ndi_filename_len; /* Length of filename, in bytes. */
- uint16_t ndi_crc16; /* Covers rest of header and filename. */
- /* Followed by filename. */
-};
-```
-
-An inode filename's length cannot exceed 256 bytes. The filename is not null-terminated. The following ASCII characters are not allowed in a filename:
-
-* / (slash character)
-* \0 (NUL character)
-
-```c
-/** On-disk representation of a data block. */
-struct nffs_disk_block {
- uint32_t ndb_magic; /* NFFS_BLOCK_MAGIC */
- uint32_t ndb_id; /* Unique object ID. */
- uint32_t ndb_seq; /* Sequence number; greater supersedes lesser. */
- uint32_t ndb_inode_id; /* Object ID of owning inode. */
- uint32_t ndb_prev_id; /* Object ID of previous block in file;
- NFFS_ID_NONE if this is the first block. */
- uint16_t ndb_data_len; /* Length of data contents, in bytes. */
- uint16_t ndb_crc16; /* Covers rest of header and data. */
- /* Followed by 'ndb_data_len' bytes of data. */
-};
-```
-
-Each data block contains the ID of the previous data block in the file. Together, the set of blocks in a file form a reverse singly-linked list.
-
-The maximum number of data bytes that a block can contain is determined at initialization-time. The result is the greatest number which satisfies all of the following restrictions:
-
-* No more than 2048.
-* At least two maximum-sized blocks can fit in the smallest area.
-
-The 2048 number was chosen somewhat arbitrarily, and may change in the future.
-
-### ID space
-
-All disk objects have a unique 32-bit ID. The ID space is partitioned as
-follows:
-
-| ID range | Node type |
-|-----------------------------------|---------------------------|
-| 0x00000000 - 0x0fffffff | Directory inodes |
-| 0x10000000 - 0x7fffffff | File inodes |
-| 0x80000000 - 0xfffffffe | Data blocks |
-| 0xffffffff | Reserved (NFFS_ID_NONE) |
-
-### Scratch area
-
-A valid nffs file system must contain a single "scratch area." The scratch area does not contain any objects of its own, and is only used during garbage collection. The scratch area must have a size greater than or equal to each of the other areas in flash.
-
-### RAM representation
-
-Every object in the file system is stored in a 256-entry hash table. An object's hash key is derived from its 32-bit ID. Each list in the hash table is sorted by time of use; most-recently-used is at the front of the list. All objects are represented by the following structure:
-
-```c
-/**
- * What gets stored in the hash table. Each entry represents a data block or
- * an inode.
- */
-struct nffs_hash_entry {
- SLIST_ENTRY(nffs_hash_entry) nhe_next;
- uint32_t nhe_id; /* 0 - 0x7fffffff if inode; else if block. */
- uint32_t nhe_flash_loc; /* Upper-byte = area idx; rest = area offset. */
-};
-```
-
-For each data block, the above structure is all that is stored in RAM. To acquire more information about a data block, the block header must be read from flash.
-
-Inodes require a fuller RAM representation to capture the structure of the file system. There are two types of inodes: *files* and *directories*. Each inode hash entry is actually an instance of the following structure:
-
-```c
-/** Each inode hash entry is actually one of these. */
-struct nffs_inode_entry {
- struct nffs_hash_entry nie_hash_entry;
- SLIST_ENTRY(nffs_inode_entry) nie_sibling_next;
- union {
- struct nffs_inode_list nie_child_list; /* If directory */
- struct nffs_hash_entry *nie_last_block_entry; /* If file */
- };
- uint8_t nie_refcnt;
-};
-```
-
-A directory inode contains a list of its child files and directories (*fie\_child\_list*). These entries are sorted alphabetically using the ASCII character set.
-
-A file inode contains a pointer to the last data block in the file (*nie\_last\_block\_entry*). For most file operations, the reversed block list must be walked backwards. This introduces a number of speed inefficiencies:
-
-* All data blocks must be read to determine the length of the file.
-* Data blocks often need to be processed sequentially. The reversed nature of the block list transforms this from linear time to an O(n^2) operation.
-
-Furthermore, obtaining information about any constituent data block requires a separate flash read.
-
-### Inode cache and Data Block cache
-
-The speed issues are addressed by a pair of caches. Cached inodes entries contain the file length and a much more convenient doubly-linked list of cached data blocks. The benefit of using caches is that the size of the caches need not be proportional to the size of the file system. In other words, caches can address speed efficiency concerns without negatively impacting the file system's scalability.
-
-nffs requires both caches during normal operation, so it is not possible to disable them. However, the cache sizes are configurable, and both caches can be configured with a size of one if RAM usage must be minimized.
-
-The following data structures are used in the inode and data block caches.
-
-```c
-/** Full data block representation; not stored permanently in RAM. */
-struct nffs_block {
- struct nffs_hash_entry *nb_hash_entry; /* Points to real block entry. */
- uint32_t nb_seq; /* Sequence number; greater
- supersedes lesser. */
- struct nffs_inode_entry *nb_inode_entry; /* Owning inode. */
- struct nffs_hash_entry *nb_prev; /* Previous block in file. */
- uint16_t nb_data_len; /* # of data bytes in block. */
- uint16_t reserved16;
-};
-```
-
-```c
-/** Represents a single cached data block. */
-struct nffs_cache_block {
- TAILQ_ENTRY(nffs_cache_block) ncb_link; /* Next / prev cached block. */
- struct nffs_block ncb_block; /* Full data block. */
- uint32_t ncb_file_offset; /* File offset of this block. */
-};
-```
-
-```c
-/** Full inode representation; not stored permanently in RAM. */
-struct nffs_inode {
- struct nffs_inode_entry *ni_inode_entry; /* Points to real inode entry. */
- uint32_t ni_seq; /* Sequence number; greater
- supersedes lesser. */
- struct nffs_inode_entry *ni_parent; /* Points to parent directory. */
- uint8_t ni_filename_len; /* # chars in filename. */
- uint8_t ni_filename[NFFS_SHORT_FILENAME_LEN]; /* First 3 bytes. */
-};
-```
-
-```c
-/** Doubly-linked tail queue of cached blocks; contained in cached inodes. */
-TAILQ_HEAD(nffs_block_cache_list, nffs_block_cache_entry);
-
-/** Represents a single cached file inode. */
-struct nffs_cache_inode {
- TAILQ_ENTRY(nffs_cache_inode) nci_link; /* Sorted; LRU at tail. */
- struct nffs_inode nci_inode; /* Full inode. */
- struct nffs_cache_block_list nci_block_list; /* List of cached blocks. */
- uint32_t nci_file_size; /* Total file size. */
-};
-```
-
-Only file inodes are cached; directory inodes are never cached.
-
-Within a cached inode, all cached data blocks are contiguous. E.g., if the start and end of a file are cached, then the middle must also be cached. A data block is only cached if its owning file is also cached.
-
-Internally, cached inodes are stored in a singly-linked list, ordered by time of use. The most-recently-used entry is the first element in the list. If a new inode needs to be cached, but the inode cache is full, the least-recently-used entry is freed to make room for the new one. The following operations cause an inode to be cached:
-
-* Querying a file's length.
-* Seeking within a file.
-* Reading from a file.
-* Writing to a file.
-
-The following operations cause a data block to be cached:
-
-* Reading from the block.
-* Writing to the block.
-
-If one of the above operations is applied to a data block that is not currently cached, nffs uses the following procedure to cache the necessary block:
-
-1. If none of the owning inode's blocks are currently cached, allocate a cached block entry corresponding to the requested block and insert it into the inode's list.
-2. Else if the requested file offset is less than that of the first cached block, bridge the gap between the inode's sequence of cached blocks and the block that now needs to be cached. This is accomplished by caching each block in the gap, finishing with the requested block.
-3. Else (the requested offset is beyond the end of the cache),
- 1. If the requested offset belongs to the block that immediately follows the end of the cache, cache the block and append it to the list.
- 2. Else, clear the cache, and populate it with the single entry corresponding to the requested block.
-
-If the system is unable to allocate a cached block entry at any point during the above procedure, the system frees up other blocks currently in the cache. This is accomplished as follows:
-
-* Iterate the inode cache in reverse (i.e., start with the least-recently-used entry). For each entry:
- 1. If the entry's cached block list is empty, advance to the next entry.
- 2. Else, free all the cached blocks in the entry's list.
-
-Because the system imposes a minimum block cache size of one, the above procedure will always reclaim at least one cache block entry. The above procedure may result in the freeing of the block list that belongs to the very inode being operated on. This is OK, as the final block to get cached is always the block being requested.
-
-### Detection
-
-The file system detection process consists of scanning a specified set of flash regions for valid nffs areas, and then populating the RAM representation of the file system with the detected objects. Detection is initiated with the [nffs_detect()](nffs_detect.md) function.
-
-Not every area descriptor passed to `nffs_detect()` needs to reference a valid nffs area. Detection is successful as long as a complete file system is detected somewhere in the specified regions of flash. If an application is unsure where a file system might be located, it can initiate detection across the entire flash region.
-
-A detected file system is valid if:
-
-1. At least one non-scratch area is present.
-2. At least one scratch area is present (only the first gets used if there is more than one).
-3. The root directory inode is present.
-
-During detection, each indicated region of flash is checked for a valid area header. The contents of each valid non-scratch area are then restored into the nffs RAM representation. The following procedure is applied to each object in the area:
-
-1. Verify the object's integrity via a crc16 check. If invalid, the object is discarded and the procedure restarts on the next object in the area.
-2. Convert the disk object into its corresponding RAM representation and insert it into the hash table. If the object is an inode, its reference count is initialized to 1, indicating ownership by its parent directory.
-3. If an object with the same ID is already present, then one supersedes the other. Accept the object with the greater sequence number and discard the other.
-4. If the object references a nonexistent inode (parent directory in the case of an inode; owning file in the case of a data block), insert a temporary "dummy" inode into the hash table so that inter-object links can be maintained until the absent inode is eventually restored. Dummy inodes are identified by a reference count of 0.
-5. If a delete record for an inode is encountered, the inode's parent pointer is set to null to indicate that it should be removed from RAM.
-
-If nffs encounters an object that cannot be identified (i.e., its magic number is not valid), it scans the remainder of the flash area for the next valid magic number. Upon encountering a valid object, nffs resumes the procedure described above.
-
-After all areas have been restored, a sweep is performed across the entire RAM representation so that invalid inodes can be deleted from memory.
-
-For each directory inode:
-
-* If its reference count is 0 (i.e., it is a dummy), migrate its children to the */lost+found* directory, and delete it from the RAM representation. This should only happen in the case of file system corruption.
-* If its parent reference is null (i.e., it was deleted), delete it and all its children from the RAM representation.
-
-For each file inode:
-
-* If its reference count is 0 (i.e., it is a dummy), delete it from the RAM representation. This should only happen in the case of file system corruption. (We should try to migrate the file to the lost+found directory in this case, as mentioned in the todo section).
-
-When an object is deleted during this sweep, it is only deleted from the RAM representation; nothing is written to disk.
-
-When objects are migrated to the lost+found directory, their parent inode reference is permanently updated on the disk.
-
-In addition, a single scratch area is identified during the detection process. The first area whose *fda\_id* value is set to 0xff is designated as the file system scratch area. If no valid scratch area is found, the cause could be that the system was restarted while a garbage collection cycle was in progress. Such a condition is identified by the presence of two areas with the same ID. In such a case, the shorter of the two areas is erased and designated as the scratch area.
-
-### Formatting
-
-A new nffs file system is created via formatting. Formatting is achieved via the [nffs\_format()](nffs_format.md) function.
-
-During a successful format, an area header is written to each of the specified locations. One of the areas in the set is designated as the initial scratch area.
-
-### Flash writes
-
-The nffs implementation always writes in a strictly sequential fashion within an area. For each area, the system keeps track of the current offset. Whenever an object gets written to an area, it gets written to that area's current offset, and the offset is increased by the object's disk size.
-
-When a write needs to be performed, the nffs implementation selects the appropriate destination area by iterating though each area until one with sufficient free space is encountered.
-
-There is no write buffering. Each call to a write function results in a write operation being sent to the flash hardware.
-
-### New objects
-
-Whenever a new object is written to disk, it is assigned the following properties:
-
-* *ID:* A unique value is selected from the 32-bit ID space, as appropriate for the object's type.
-* *Sequence number:* 0
-
-When a new file or directory is created, a corresponding inode is written to flash. Likewise, a new data block also results in the writing of a corresponding disk object.
-
-### Moving/Renaming files and directories
-
-When a file or directory is moved or renamed, its corresponding inode is rewritten to flash with the following properties:
-
-* *ID:* Unchanged
-* *Sequence number:* Previous value plus one.
-* *Parent inode:* As specified by the move / rename operation.
-* *Filename:* As specified by the move / rename operation.
-
-Because the inode's ID is unchanged, all dependent objects remain valid.
-
-### Unlinking files and directories
-
-When a file or directory is unlinked from its parent directory, a deletion record for the unlinked inode gets written to flash. The deletion record is an inode with the following properties:
-
-* *ID:* Unchanged
-* *Sequence number:* Previous value plus one.
-* *Parent inode ID:* NFFS\_ID\_NONE
-
-When an inode is unlinked, no deletion records need to be written for the inode's dependent objects (constituent data blocks or child inodes). During the next file system detection, it is recognized that the objects belong to a deleted inode, so they are not restored into the RAM representation.
-
-If a file has an open handle at the time it gets unlinked, application code can continued to use the file handle to read and write data. All files retain a reference count, and a file isn't deleted from the RAM representation until its reference code drops to 0. Any attempt to open an unlinked file fails, even if the file is referenced by other file handles.
-
-### Writing to a file
-
-The following procedure is used whenever the application code writes to a file. First, if the write operation specifies too much data to fit into a single block, the operation is split into several separate write operations. Then, for each write operation:
-
-1. Determine which existing blocks the write operation overlaps (n = number of overwritten blocks).
-2. If *n = 0*, this is an append operation. Write a data block with the following properties:
- * *ID:* New unique value.
- * *Sequence number:* 0.
-3. Else *(n > 1)*, this write overlaps existing data.
- 1. For each block in *[1, 2, ... n-1]*, write a new block containing the updated contents. Each new block supersedes the block it overwrites. That is, each block has the following properties:
- * *ID:* Unchanged
- * *Sequence number:* Previous value plus one.
- 2. Write the nth block. The nth block includes all appended data, if any. As with the other blocks, its ID is unchanged and its sequence number is incremented.
-
-Appended data can only be written to the end of the file. That is, "holes" are not supported.
-
-### Garbage collection
-
-When the file system is too full to accommodate a write operation, the system must perform garbage collection to make room. The garbage collection procedure is described below:
-
-* The non-scratch area with the lowest garbage collection sequence number is selected as the "source area." If there are other areas with the same sequence number, the one with the smallest flash offset is selected.
-* The source area's ID is written to the scratch area's header, transforming it into a non-scratch ID. This former scratch area is now known as the "destination area."
-* The RAM representation is exhaustively searched for collectible objects. The following procedure is applied to each inode in the system:
- * If the inode is resident in the source area, copy the inode record to the destination area.
- * If the inode is a file inode, walk the inode's list of data blocks, starting with the last block in the file. Each block that is resident in the source area is copied to the destination area. If there is a run of two or more blocks that are resident in the source area, they are consolidated and copied to the destination area as a single new block (subject to the maximum block size restriction).
-* The source area is reformatted as a scratch sector (i.e., is is fully erased, and its header is rewritten with an ID of 0xff). The area's garbage collection sequence number is incremented prior to rewriting the header. This area is now the new scratch sector.
diff --git a/docs/os/modules/fs/otherfs.md b/docs/os/modules/fs/otherfs.md
deleted file mode 100644
index d2aa479..0000000
--- a/docs/os/modules/fs/otherfs.md
+++ /dev/null
@@ -1,63 +0,0 @@
-# Other File Systems
-
-Libraries use Mynewt's file system abstraction layer (`fs/fs`) for all file operations. Because clients use an abstraction layer, the underlying file system can be swapped out without affecting client code. This page documents the procedure for plugging a custom file system into the Mynewt file system abstraction layer.
-
-### 1. Specify `fs/fs` as a dependency of your file system package.
-
-The file system package must register itself with the `fs/fs` package, so it must specify `fs/fs` as a dependency. As an example, part of the Newtron Flash File System (nffs) `pkg.yml` is reproduced below. Notice the first item in the `pkg.deps` list.
-
-```no-highlight
-pkg.name: fs/nffs
-pkg.deps:
- - fs/fs
- - hw/hal
- - libs/os
- - libs/testutil
- - sys/log
-```
-
-### 2. Register your package's API with the `fs/fs` interface.
-
-The `fs/fs` package calls into the underlying file system via a collection of function pointers. To plug your file system into the `fs/fs` API, you must assign these function pointers to the corresponding routines in your file system package.
-
-For example, `nffs` registers itself with `fs/fs` as follows (from `fs/nffs/src/nffs.c`):
-
-```c
-static const struct fs_ops nffs_ops = {
- .f_open = nffs_open,
- .f_close = nffs_close,
- .f_read = nffs_read,
- .f_write = nffs_write,
-
- .f_seek = nffs_seek,
- .f_getpos = nffs_getpos,
- .f_filelen = nffs_file_len,
-
- .f_unlink = nffs_unlink,
- .f_rename = nffs_rename,
- .f_mkdir = nffs_mkdir,
-
- .f_opendir = nffs_opendir,
- .f_readdir = nffs_readdir,
- .f_closedir = nffs_closedir,
-
- .f_dirent_name = nffs_dirent_name,
- .f_dirent_is_dir = nffs_dirent_is_dir,
-
- .f_name = "nffs"
-};
-
-int
-nffs_init(void)
-{
- /* [...] */
- fs_register(&nffs_ops);
-}
-```
-
-### Header Files
-To gain access to `fs/fs`'s registration interface, include the following header:
-
-```c
-#include "fs/fs_if.h"
-```
diff --git a/docs/os/modules/hal/hal.md b/docs/os/modules/hal/hal.md
deleted file mode 100644
index 0a9533c..0000000
--- a/docs/os/modules/hal/hal.md
+++ /dev/null
@@ -1,66 +0,0 @@
-# Hardware Abstraction Layer
-
-### Description
-
-The Hardware Abstraction Layer (HAL) in Mynewt is a low-level, base peripheral abstraction. HAL provides a core set of services that is implemented for each MCU supported by Mynewt. Device drivers are typically the software libraries that initialize the hardware and manage access to the hardware by higher layers of software. In the Mynewt OS, the layers can be depicted in the following manner.
-
-```no-highlight
-
-+———————————————————————————+
-| app |
-+———————————————————————————+
-| (n)drivers |
-+———————————————————————————+
-| HAL | BSP |
-+—————————————+—————————————+
-
-```
-
-* The Board Support Package (BSP) abstracts board specific configurations e.g. CPU frequency, input voltage, LED pins, on-chip flash map etc.
-
-* The Hardware Abstraction Layer (HAL) abstracts architecture-specific functionality. It initializes and enables components within a master processor. It is designed to be portable across all the various MCUs supported in Mynewt (e.g. Nordic's nRF51, Nordic's nRF52, NXP's MK64F12 etc.). It includes code that initializes and manages access to components of the board such as board buses (I2C, PCI, PCMCIA, etc.), off-chip memory (controllers, level 2+ cache, Flash, etc.), and off-chip I/O (Ethernet, RS-232, display, mouse, etc.)
-
-* The driver sits atop the BSP and HAL. It abstracts the common modes of operation for each peripheral device connected via the standard interfaces to the processor. There may be multiple driver implementations of differing complexities for a particular peripheral device. The drivers are the ones that register with the kernel’s power management APIs, and manage turning on and off peripherals and external chipsets, etc.
-
-
-### General design principles
-
-* The HAL API should be simple. It should be as easy to implement for hardware as possible. A simple HAL API makes it easy to bring up new MCUs quickly.
-
-* The HAL API should portable across all the various MCUs supported in Mynewt (e.g. Nordic's nRF51, Nordic's nRF52, NXP's MK64F12 etc.).
-
-### Example
-
-A Mynewt contributor might write a light-switch driver that provides the functionality of an intelligent light
-switch. This might involve using a timer, a General Purpose Output (GPO)
-to set the light to the on or off state, and flash memory to log the times the
-lights were turned on or off. The contributor would like this package to
-work with as many different hardware platforms as possible, but can't
-possibly test across the complete set of hardware supported by Mynewt.
-
-**Solution**: The contributor uses the HAL APIs to control the peripherals.
-The Mynewt team ensures that the underlying HAL devices all work equivalently
-through the HAL APIs. The contributors library is independent of the specifics
-of the hardware.
-
-### Dependency
-
-To include the HAL within your project, simply add it to your package
-dependencies as follows:
-
-```no-highlight
-pkg.deps:
- . . .
- hw/hal
-```
-
-### Platform Support
-
-Not all platforms (MCU and BSP) support all HAL devices. Consult your MCU
-or BSP documentation to find out if you have hardware support for the
-peripherals you are interested in using. Once you verify support, then
-consult the MCU implementation and see if the specific HAL interface (xxxx) you are
-using is in the `mcu/<mcu-name>/src/hal_xxxx.c` implementation. Finally, you
-can build your project and ensure that there are no unresolved hal_xxxx
-externals.
-
diff --git a/docs/os/modules/hal/hal_api.md b/docs/os/modules/hal/hal_api.md
deleted file mode 100644
index 0b7d11f..0000000
--- a/docs/os/modules/hal/hal_api.md
+++ /dev/null
@@ -1,22 +0,0 @@
-
-# HAL Interfaces
-
-The HAL supports separate interfaces for many peripherals. A brief
-description of the interfaces are shown below.
-
-
-| **Hal Name** | ** Interface File ** | **Description ** |
-|--------------|----------------------|------------------|
-| [bsp](hal_bsp/hal_bsp.md) | [hal_bsp.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_bsp.h) | An hardware independent interface to identify and access underlying BSP.|
-| [flash api for apps to use](hal_flash/hal_flash.md) | [hal_flash.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_flash.h) | A blocking interface to access flash memory.|
-| [flash api for drivers to implement](hal_flash/hal_flash_int.md) | [flash_map.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_flash_int.h) | An interface to query information about the flash map (regions and sectors)|
-| [gpio](hal_gpio/hal_gpio.md) | [hal_gpio.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_gpio.h) | An interface for manipulating General Purpose Inputs and Outputs.|
-| [i2c](hal_i2c/hal_i2c.md) | [hal_i2c.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_i2c.h) | An interface for controlling Inter-Integrated-Circuit (i2c) devices.|
-| [OS tick](hal_os_tick/hal_os_tick.md) | [hal_os_tick.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_os_tick.h) | An interface to set up interrupt timers or halt CPU in terms of OS ticks.|
-| [spi](hal_spi/hal_spi.md) | [hal_spi.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_spi.h) | An interface for controlling Serial Peripheral Interface (SPI) devices.|
-| [system](hal_system/hal_sys.md) | [hal_system.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_system.h) | An interface for starting and resetting the system. |
-| [timer](hal_timer/hal_timer.md) | [hal_cputime.h](https://github.com/apache/incubator-mynewt-core/tree/develop/hw/hal/include/hal/hal_timer.h) | An interface for configuring and running HW timers|
-| [uart](hal_uart/hal_uart.md) | [hal_uart.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_uart.h) | An interface for communicating via asynchronous serial interface.|
-| [watchdog](hal_watchdog/hal_watchdog.md) | [hal_watchdog.h](https://github.com/apache/incubator-mynewt-core/blob/develop/hw/hal/include/hal/hal_watchdog.h) | An interface for enabling internal hardware watchdogs. |
-
-
diff --git a/docs/os/modules/hal/hal_bsp/hal_bsp.md b/docs/os/modules/hal/hal_bsp/hal_bsp.md
deleted file mode 100644
index 0380459..0000000
--- a/docs/os/modules/hal/hal_bsp/hal_bsp.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# hal_bsp
-
-
-This is the hardware independent BSP (Board Support Package) Interface for Mynewt.
-
-### Description
-
-Contains the basic operations to initialize, specify memory to include in coredump, configure interrupt priority etc.
-
-### Definition
-
-[hal_bsp.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_bsp.h)
-
-### Examples
-
-
-<br>
-
----------------------
diff --git a/docs/os/modules/hal/hal_creation.md b/docs/os/modules/hal/hal_creation.md
deleted file mode 100644
index 5eff52b..0000000
--- a/docs/os/modules/hal/hal_creation.md
+++ /dev/null
@@ -1,22 +0,0 @@
-
-# Creating New HAL Interfaces
-
-## HAL API
-
-A HAL always includes header file with function declarations
-for the HAL functionality in `/hw/hal/include/hal`.
-The first argument of all functions in the interface typically include the virtual
-device_id of the device you are controlling.
-
-For example, in [`hal_gpio.h`](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_gpio.h)
-the device enumeration is the first argument to most methods and called `pin`.
-
-```no-highlight
- void hal_gpio_write(int pin, int val);
-```
-
-The device_id (in this case called `pin`) is not a physical device
-(actual hardware pin), but a virtual pin which is defined by the
-implementation of the HAL (and documented in the implementation of the HAL).
-
-
diff --git a/docs/os/modules/hal/hal_flash/hal_flash.md b/docs/os/modules/hal/hal_flash/hal_flash.md
deleted file mode 100644
index 50ef1ae..0000000
--- a/docs/os/modules/hal/hal_flash/hal_flash.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# hal_flash
-
-The hardware independent interface to flash memory that is used by applications.
-
-### Description
-
-The API offers basic initialization, read, write, erase, sector erase, and other operations.
-
-### Definition
-
-[hal_flash.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_flash.h)
-
-### Examples
-
-
-
-
-
diff --git a/docs/os/modules/hal/hal_flash/hal_flash_int.md b/docs/os/modules/hal/hal_flash/hal_flash_int.md
deleted file mode 100644
index 3ca624a..0000000
--- a/docs/os/modules/hal/hal_flash/hal_flash_int.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# hal_flash_int
-
-The API that flash drivers have to implement.
-
-### Description
-
-The BSP for the hardware will implement the structs defined in this API.
-
-### Definition
-
-[hal_flash_int.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_flash_int.h)
-
-### Examples
-
-The Nordic nRF52 bsp implements the hal_flash_int API as seen in [hal_bsp.c](https://github.com/apache/incubator-mynewt-core/blob/master/hw/bsp/stm32f4discovery/src/hal_bsp.c)
-
-```
-const struct hal_flash *
-hal_bsp_flash_dev(uint8_t id)
-{
- /*
- * Internal flash mapped to id 0.
- */
- if (id != 0) {
- return NULL;
- }
- return &nrf52k_flash_dev;
-}
-
-```
-
-
-
diff --git a/docs/os/modules/hal/hal_gpio/hal_gpio.md b/docs/os/modules/hal/hal_gpio/hal_gpio.md
deleted file mode 100644
index 45cee90..0000000
--- a/docs/os/modules/hal/hal_gpio/hal_gpio.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# hal_gpio
-
-
-This is the hardware independent GPIO (General Purpose Input Output) Interface for Mynewt.
-
-### Description
-
-Contains the basic operations to set and read General Purpose Digital I/O Pins
-within a Mynewt system.
-
-Individual GPIOs are referenced in the APIs as `pins`. However, in this interface the `pins` are virtual GPIO pins. The MCU header file maps these virtual `pins` to the physical GPIO ports and pins.
-
-Typically, the BSP code may define named I/O pins in terms of these virtual `pins` to describe the devices attached to the physical pins.
-
-Here's a brief example so you can get the gist of the translation.
-
-Suppose my product uses the stm32F4xx processor. There already exists support for this processor within Mynewt. The processor has N ports (A,B,C..) of 16 GPIO pins per port. The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 and so on. The exact number of physical port (and virtual
-port pins) depends on the specific variant of the stm32F4xx.
-
-So if I want to turn on port B pin 3, that would be virtual pin 1*16 + 3 = 19.
-This translation is defined in the MCU implementation of
-[hal_gpio.c](https://github.com/apache/incubator-mynewt-core/blob/master/hw/mcu/stm/stm32f4xx/src/hal_gpio.c)
-for the stmf32F4xx. Each MCU will typically have a different translation method
-depending on its GPIO architecture.
-
-Now, when writing a BSP, it's common to give names to the relevant port pins that you are using. Thus, the BSP may define a mapping between a function and a virtual port pin in the `bsp.h` header file for the BSP. For example,
-
-```no-highlight
-#define SYSTEM_LED (37)
-#define FLASH_SPI_CHIP_SELECT (3)
-```
-
-would map the system indicator LED to virtual pin 37 which on the stm32F4xx would be Port C pin 5 and the chip select line for the external SPI flash to virtual pin 3 which on the stm32F4xxis port A pin 3.
-
-Said another way, in this specific system we get
-
-```no-highlight
-SYSTEM_LED --> hal_gpio virtual pin 37 --> port C pin 5 on the stm34F4xx
-```
-
-### Definition
-
-[hal_gpio.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_gpio.h)
-
-### Examples
-
-#### Blinky
-
-Blinky uses the hal_gpio to blink the system LED. The blinky source code is available in the
-[blinky repo](https://github.com/apache/incubator-mynewt-blinky/blob/master/apps/blinky/src/main.c).
-Examine how `blinky_task_handler` initializes and toggles the GPIO to control the LED.
-
-<br>
-
----------------------
-
diff --git a/docs/os/modules/hal/hal_i2c/hal_i2c.md b/docs/os/modules/hal/hal_i2c/hal_i2c.md
deleted file mode 100644
index c947357..0000000
--- a/docs/os/modules/hal/hal_i2c/hal_i2c.md
+++ /dev/null
@@ -1,94 +0,0 @@
-# hal_i2c
-
-The hardware independent interface to I2C Devices.
-
-### Description
-
-An Inter-Integrated Circuit (I²C ] I-squared-C) bus is a multi-master,
-multi-save serial interface used to connect components on a circuit board
-and often peripherals devices located off the circuit board.
-
-I2C is often though of as a 2-wire protocol because it uses two wires (SDA, SCL)
-to send data between devices.
-
-For a detailed description of I2C, see the [I²C wikipedia page](https://en.wikipedia.org/wiki/I²C)
-
-### Definition
-
-[hal_i2c.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_i2c.h)
-
-### HAL_I2C Theory Of Operation
-
-An I²C transaction typically involves acquiring the bus, sending and/or receiving
-data and release the bus. The bus acquisition portion is important because
-the bus is typically multi-master so other devices may be trying to read/write
-the same peripheral.
-
-HAL_I2C implements a master interface to the I²C bus. Typical usage of the
-interface would involve the following steps.
-
-Initialize an i2c device with:
- hal_i2c_init()
-
-When you wish to perform an i2c transaction, you call one or both of:
- hal_i2c_master_write();
- hal_i2c_master_read();
-
- These functions will issue a START condition, followed by the device's
-7-bit I2C address, and then send or receive the payload based on the data
-provided. This will cause a repeated start on the bus, which is valid in
-I2C specification, and the decision to use repeated starts was made to
-simplify the I2C HAL. To set the STOP condition at an appropriate moment,
-you set the `last_op` field to a `1` in either function.
-
-For example, in an I2C memory access you might write a register address and
-then read data back via:
- hal_i2c_write(); -- write to a specific register on the device
- hal_i2c_read(); --- read back data, setting 'last_op' to '1'
-
-An addition API was added called `hal_i2c_probe`. This command combines
-`hal_i2c_begin()`, `hal_i2c_read`, and `hal_i2c_end()` to try to read 0-bytes
-from a specific bus address. its intended to provide an easy way to probe
-the bus for a specific device. NOTE: if the device is write-only, it will
-not appear with this command.
-
-A slave API is pending for further release.
-
-### HAL_I2C Data
-
-Data to read/write is passed to the hal_i2c APIs via the
-
-```
-struct hal_i2c_master_data {
- uint8_t address; /* destination address */
- uint16_t len; /* number of bytes to transmit or receive */
- uint8_t *buffer; /* data buffer for transmit or receive */
-};
-```
-
-`buffer` is a pointer to the data to send. `len` is the number of bytes
-to send over the bus. `address` is a 7-bit bus address of the device.
-
-When I²C builds its address, it uses the 7-bit address plus a 1-bit R/W
-(read/write) indicator to identify the device and direction of the
-transaction. Thus when using this API, you should use a 7-bit address
-in the data structure and ensure that address is a value between 0-127.
-
-
-As an example, consider an I²C device address that looks like this:
-
-| B7 | B6 | B5 | B4 | B3 | B2 | B1 | B0 |
-|---|---|---|---|---|---|---|---|
-| 1 | 0 | 0 | 0 | 1 | 1 | 0 |R/W|
-|MSB| | | | | | |LSB|
-
-In the HAL_I2C API you would communicate with this device with address
-`0b1000110`, which is hex 0x46 or decimal 70. The I²C drive would add the R/W bit
-and transmit it as hex 0x8C (binary 10001100) or 0x8D (binary 10001101) depending whether it was a read or
-write command.
-
-
-
-
-
-
diff --git a/docs/os/modules/hal/hal_in_libraries.md b/docs/os/modules/hal/hal_in_libraries.md
deleted file mode 100644
index fb17270..0000000
--- a/docs/os/modules/hal/hal_in_libraries.md
+++ /dev/null
@@ -1,13 +0,0 @@
-
-# Using HAL in Your Libraries
-
-This page describes the recommended way to implement libraries that
-utilize HAL functionality.
-
-
-An example of the GPIO HAL being used by a driver for a UART bitbanger that programs the start bit, data bits, and stop bit can be seen in [hw/drivers/uart/uart_bitbang/src/uart_bitbang.c](https://github.com/apache/incubator-mynewt-core/blob/master/hw/drivers/uart/uart_bitbang/src/uart_bitbang.c)
-
-
-An example of the flash HAL being used by a file sytem can be seen in [fs/nffs/src/nffs_flash.c](https://github.com/apache/incubator-mynewt-core/blob/master/fs/nffs/src/nffs_flash.c).
-
-
diff --git a/docs/os/modules/hal/hal_os_tick/hal_os_tick.md b/docs/os/modules/hal/hal_os_tick/hal_os_tick.md
deleted file mode 100644
index 9fe957e..0000000
--- a/docs/os/modules/hal/hal_os_tick/hal_os_tick.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# hal_os_tick
-
-The hardware independent interface to set up interrupt timers or halt CPU in terms of OS ticks.
-
-### Description
-
-Set up the periodic timer to interrupt at a frequency of 'os_ticks_per_sec' using the following function call where 'prio' is the cpu-specific priority of the periodic timer interrupt.
-
-```c
-void os_tick_init(uint32_t os_ticks_per_sec, int prio);
-```
-
-You can halt CPU for up to `n` ticks:
-
-```c
-void os_tick_idle(os_time_t n);
-```
-
-The function implementations are in the mcu-specific directories such as `hw/mcu/nordic/nrf51xxx/src/hal_os_tick.c`.
-
-
-### Definition
-
-[hal_os_tick.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_os_tick.h)
-
-### Examples
-
-An example of the API being used by the OS kernel for the Cortex M0 architecture to initialize and start the system clock timer can be seen in [kernel/os/src/arch/cortex_m0/os_arch_arm.c](https://github.com/apache/incubator-mynewt-core/blob/master/kernel/os/src/arch/cortex_m0/os_arch_arm.c).
diff --git a/docs/os/modules/hal/hal_spi/hal_spi.md b/docs/os/modules/hal/hal_spi/hal_spi.md
deleted file mode 100644
index 9b329a8..0000000
--- a/docs/os/modules/hal/hal_spi/hal_spi.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# hal_spi
-
-
-SPI (Serial Peripheral Interface) is a synchronous 4-wire serial interface
-commonly used to connect components in embedded systems.
-
-For a detailed description of SPI, see [Wikipedia](https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus).
-
-### Description
-
-The Mynewt HAL interface supports the SPI master functionality with both blocking and non-blocking interface. SPI slave functionality is supported in non-blocking mode.
-
-
-### Definition
-
-[hal_spi.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_spi.h)
-
-### HAL_SPI Theory Of Operation
-
-SPI is called a 4-wire interface because of the 4 signals, MISO, MOSI, CLK,
-and SS. The SS signal (slave select) is an active low signal that activates
-a SPI slave device. This is how a master "addresses" a particular slave
-device. Often this signal is also referred to as "chip select" as it
-selects particular slave device for communications.
-
-The Mynewt SPI HAL has blocking and non-blocking transfers. Blocking means that the API call
-to transfer a byte will wait until the byte completes transmissions before
-the function returns. Blocking interface can be used for only the master slave SPI type.
-Non-blocking means he function returns control to the execution environment immediately after the API call and a callback function is executed at the completion of the transmission. Non-blocking interface can be used for both master and slave SPI types.
-
-
-The `hal_spi_config` method in the API above allows the SPI to be configured with appropriate settings for master or slave. It Must be called after the spi is initialized (i.e. after hal_spi_init is called) and when the spi is disabled (i.e. user must call hal_spi_disable if the spi has been enabled through hal_spi_enable prior to calling this function). It can also be used to reconfigure an initialized SPI (assuming it is disabled as described previously).
-
-```c
-int hal_spi_config(int spi_num, struct hal_spi_settings *psettings);
-```
-
-The SPI settings consist of the following:
-
-```c
-struct hal_spi_settings {
- uint8_t data_mode;
- uint8_t data_order;
- uint8_t word_size;
- uint32_t baudrate; /* baudrate in kHz */
-};
-```
-
-The Mynewt SPI HAL does not include built-in SS (Slave Select) signaling. It's up to the
-hal_spi user to control their own SS pins. Typically applications will do
-this with GPIO.
diff --git a/docs/os/modules/hal/hal_system/hal_sys.md b/docs/os/modules/hal/hal_system/hal_sys.md
deleted file mode 100644
index 4d34921..0000000
--- a/docs/os/modules/hal/hal_system/hal_sys.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# hal_system
-
-A hardware independent interface for starting and resetting the system.
-
-### Description
-
-The API allows the user to detect whether a debugger is connected, sissue a soft reset, and enumerate the reset causes. The functions are implemented in the MCU specific directories e.g. `hal_reset_cause.c`, `hal_system.c`, and `hal_system_start.c` in `/hw/mcu/nordic/nrf52xxx/src/` directory for Nordic nRF52 series of chips.
-
-### Definition
-
-[hal_system.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_system.h)
-
-### Examples
diff --git a/docs/os/modules/hal/hal_timer/hal_timer.md b/docs/os/modules/hal/hal_timer/hal_timer.md
deleted file mode 100644
index 224245a..0000000
--- a/docs/os/modules/hal/hal_timer/hal_timer.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# hal_timer
-
-The hardware independent timer structure and API to configure, initialize, and run timers.
-
-### Description
-
-The HAL timer structure is shown below. The user can declare as many of these structures as required. They are enqueued on a particular HW timer queue when the user calls the hal_timer_start or hal_timer_start_at API. The user must have called hal_timer_set_cb before starting a timer.
-
-NOTE: the user should not have to modify/examine the contents of this structure; the hal timer API should be used.
-
-```c
-struct hal_timer
-{
- void *bsp_timer; /* Internal platform specific pointer */
- hal_timer_cb cb_func; /* Callback function */
- void *cb_arg; /* Callback argument */
- uint32_t expiry; /* Tick at which timer should expire */
- TAILQ_ENTRY(hal_timer) link; /* Queue linked list structure */
-};
-```
-
-### Definition
-
-[hal_timer.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_timer.h)
-
-### Examples
-
diff --git a/docs/os/modules/hal/hal_uart/hal_uart.md b/docs/os/modules/hal/hal_uart/hal_uart.md
deleted file mode 100644
index ba8690b..0000000
--- a/docs/os/modules/hal/hal_uart/hal_uart.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# hal_uart
-
-
-The hardware independent UART interface for Mynewt.
-
-### Description
-
-Contains the basic operations to send and receive data over a UART
-(Universal Asynchronous Receiver Transmitter). It also includes the API to apply settings such as speed, parity etc. to the UART. The UART port should be closed before any reconfiguring.
-
-### Definition
-
-[hal_uart.h](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_uart.h)
-
-### Examples
-
-This example shows a user writing a character to the uart in blocking mode where the UART has to block until character has been sent.
-
-```no-highlight
-/* write to the console with blocking */
-{
- char *str = "Hello World!";
- char *ptr = str;
-
- while(*ptr) {
- hal_uart_blocking_tx(MY_UART, *ptr++);
- }
- hal_uart_blocking_tx(MY_UART, '\n');
-}
-```
-
-
diff --git a/docs/os/modules/hal/hal_watchdog/hal_watchdog.md b/docs/os/modules/hal/hal_watchdog/hal_watchdog.md
deleted file mode 100644
index 4ead735..0000000
--- a/docs/os/modules/hal/hal_watchdog/hal_watchdog.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# hal_watchdog
-
-
-The hardware independent interface to enable internal hardware watchdogs.
-
-### Description
-
-The `hal_watchdog_init` interface can be used to set a recurring watchdog timer to fire no sooner than in 'expire_secs' seconds.
-
-```c
-int hal_watchdog_init(uint32_t expire_msecs);
-```
-
-Watchdog needs to be then started with a call to `hal_watchdog_enable()`.
-Watchdog should be tickled periodically with a frequency smaller than 'expire_secs' using `hal_watchdog_tickle()`.
-
-
-### Definition
-
-[hal_watchdog](https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_watchdog.h)
-
-
-### Examples
-
-The OS initializes and starts a watchdog timer and tickles it periodically to check that the OS is running properly. This can be seen in [/kernel/os/src/os.c](https://github.com/apache/incubator-mynewt-core/blob/master/kernel/os/src/os.c).
-
-
-
diff --git a/docs/os/modules/imgmgr/imgmgr.md b/docs/os/modules/imgmgr/imgmgr.md
deleted file mode 100644
index f80be46..0000000
--- a/docs/os/modules/imgmgr/imgmgr.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Image Manager
-
-
-
-
-### Description
-
-This library accepts incoming image management commands from newtmgr and acts on them.
-
-Images can be uploaded, present images listed, and system can be told to switch to another image.
-
-Currently the package assumes that there are 2 image slots, one active one and another one in standby. When new image is uploaded, it replaces the one in standby slot. This is the model for scenario when MCU has internal flash only, it executes the code from that flash, and there is enough space to store 2 full images.
-
-Image manager interacts with bootloader by telling it to boot to a specific image. At the moment this has to be done by writing a file which contains a version number of the image to boot. Note that image manager itself does not replace the active image.
-
-Image manager also can upload files to filesystem as well as download them.
-
-Note that commands accessing filesystems (next boot target, file upload/download) will not be available unless project includes filesystem implementation.
-
-### Data structures
-
-N/A.
-
-### List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in imgmgr are:
-
-| Function | Description |
-|---------|-------------|
-| [imgr_ver_parse](imgr_ver_parse.md) | Parses character string containing specified image version number and writes that to given image_version struct. |
-| [imgr_ver_str](imgr_ver_str.md) | Takes version string from specified image_version struct and formats it into a printable string. |
diff --git a/docs/os/modules/imgmgr/imgmgr_module_init.md b/docs/os/modules/imgmgr/imgmgr_module_init.md
deleted file mode 100644
index 3c0dc54..0000000
--- a/docs/os/modules/imgmgr/imgmgr_module_init.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> imgmgr_module_init </font>
-
-```no-highlight
- void
- imgmgr_module_init(void)
-```
-
-Registers the image manager commands with the `mgmt` package. `sysinit()` automatically calls this function during
-system initialization.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-N/A
-
-#### Notes
-
diff --git a/docs/os/modules/imgmgr/imgr_ver_parse.md b/docs/os/modules/imgmgr/imgr_ver_parse.md
deleted file mode 100644
index 295da2f..0000000
--- a/docs/os/modules/imgmgr/imgr_ver_parse.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> imgr_ver_parse </font>
-
-```no-highlight
- int
- imgr_ver_parse(char *src, struct image_version *ver)
-```
-
- Parses character string containing image version number `src` and writes that to `ver`. Version number string should be in format <major>.<minor>.<revision>.<build_number>. Major and minor numbers should be within range 0-255, revision between 0-65535 and build_number 0-4294967295.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| src | Pointer to C string that contains version number being parsed |
-| ver | Image version number structure containing the returned value |
-
-#### Returned values
-
-0 on success and <0 if version number string could not be parsed.
-
-#### Notes
-
-Numbers within the string are separated by `.`. The first number is the major number, and must be provided. Rest of the numbers (minor etc.) are optional.
-
-#### Example
-
-```no-highlight
-int main(int argc, char **argv)
-{
- struct image_version hdr_ver;
- int rc;
- ...
-
- rc = imgr_ver_parse(argv[3], &hdr_ver);
- if (rc != 0) {
- print_usage(stderr);
- return 1;
- }
- ...
-}
-```
-
-
diff --git a/docs/os/modules/imgmgr/imgr_ver_str.md b/docs/os/modules/imgmgr/imgr_ver_str.md
deleted file mode 100644
index 0b9d992..0000000
--- a/docs/os/modules/imgmgr/imgr_ver_str.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> imgr_ver_str </font>
-
-```no-highlight
- int
- imgr_ver_str(struct image_version *ver, char *dst)
-```
-
- Takes the version string from `ver` and formats that into a printable string to `dst`. Caller must make sure that `dst` contains enough space to hold maximum length version string. The convenience defininition for max length version string is named `IMGMGR_MAX_VER_STR`.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| ver | Image version number structure containing the value being formatted |
-| dst | Pointer to C string where results will be stored |
-
-#### Returned values
-
-Function returns the number of characters filled into the destination string.
-
-#### Notes
-
-If build number is `0` in image version structure, it will be left out of the string.
-
-#### Example
-
-```no-highlight
-static void
-imgr_ver_jsonstr(struct json_encoder *enc, char *key,
- struct image_version *ver)
-{
- char ver_str[IMGMGR_MAX_VER_STR];
- int ver_len;
- ...
- ver_len = imgr_ver_str(ver, ver_str)
- ...
-}
-```
-
-
diff --git a/docs/os/modules/json/json.md b/docs/os/modules/json/json.md
deleted file mode 100644
index 4089030..0000000
--- a/docs/os/modules/json/json.md
+++ /dev/null
@@ -1,122 +0,0 @@
-# JSON
-
-JSON is a data interchange format. The description of this format can be found from IETF RFC 4627.
-
-## Description
-
-This package helps in converting between C data types and JSON data objects. It supports both encoding and decoding.
-
-## Data structures
-
-### Encoding
-
-```c
-/* Encoding functions */
-typedef int (*json_write_func_t)(void *buf, char *data,
- int len);
-
-struct json_encoder {
- json_write_func_t je_write;
- void *je_arg;
- int je_wr_commas:1;
- char je_encode_buf[64];
-};
-```
-Here's the data structure encoder funtions use, and it must be initialized by the caller. The key element is *je_write*, which is a function pointer which gets called whenever encoding routine is ready with encoded data. The element *je_arg* is passed to *je_write* as the first argument. The rest of the structure contents are for internal state management.
-This function should collect all the data encoder function generates. It can collect this data to a flat buffer, chain of mbufs or even stream through.
-
-```c
-/**
- * For encode. The contents of a JSON value to encode.
- */
-struct json_value {
- uint8_t jv_pad1;
- uint8_t jv_type;
- uint16_t jv_len;
-
- union {
- uint64_t u;
- float fl;
- char *str;
- struct {
- char **keys;
- struct json_value **values;
- } composite;
- } jv_val;
-};
-```
-This data structure is filled with data to be encoded. It is best to fill this using the macros *JSON_VALUE_STRING()* or *JSON_VALUE_STRINGN()* when value is string, *JSON_VALUE_INT()* when value is an integer, and so forth.
-
-### Decoding
-```c
-/* when you implement a json buffer, you must implement these functions */
-
-/* returns the next character in the buffer or '\0'*/
-typedef char (*json_buffer_read_next_byte_t)(struct json_buffer *);
-/* returns the previous character in the buffer or '\0' */
-typedef char (*json_buffer_read_prev_byte_t)(struct json_buffer *);
-/* returns the number of characters read or zero */
-typedef int (*json_buffer_readn_t)(struct json_buffer *, char *buf, int n);
-
-struct json_buffer {
- json_buffer_readn_t jb_readn;
- json_buffer_read_next_byte_t jb_read_next;
- json_buffer_read_prev_byte_t jb_read_prev;
-};
-```
-Function pointers within this structure are used by decoder when it is reading in more data to decode.
-
-```c
-struct json_attr_t {
- char *attribute;
- json_type type;
- union {
- int *integer;
- unsigned int *uinteger;
- double *real;
- char *string;
- bool *boolean;
- char *character;
- struct json_array_t array;
- size_t offset;
- } addr;
- union {
- int integer;
- unsigned int uinteger;
- double real;
- bool boolean;
- char character;
- char *check;
- } dflt;
- size_t len;
- const struct json_enum_t *map;
- bool nodefault;
-};
-```
-This structure tells the decoder about a particular name/value pair. Structure must be filled in before calling the decoder routine *json_read_object()*.
-
-| Element | Description |
-|---------|-------------|
-| attribute | Name of the value |
-| type | The type of the variable; see enum json_type |
-| addr | Contains the address where value should be stored |
-| dflt | Default value to fill in, if this name is not found |
-| len | Max number of bytes to read in for value |
-| nodefault | If set, default value is not copied name |
-
-## List of Functions
-
-Functions for encoding:
-
-| Function | Description |
-|---------|-------------|
-| [json_encode_object_start](json_encode_object_start.md) | This function starts the encoded JSON object. |
-| [json_encode_object_key](json_encode_object_key.md) | This function writes out a name for a field, followed by ":" character. |
-| [json_encode_object_entry](json_encode_object_entry.md) | This function writes out a name for a field, followed by ":" character, and the value itself. |
-| [json_encode_object_finish](json_encode_object_finish.md) | This function finalizes the encoded JSON object. |
-
-Functions for decoding:
-
-| Function | Description |
-|---------|-------------|
-| [json_read_object](json_read_object.md) | This function reads in JSON data stream, while looking for name/value pairs described in given attribites. |
diff --git a/docs/os/modules/json/json_encode_object_entry.md b/docs/os/modules/json/json_encode_object_entry.md
deleted file mode 100644
index c2124dc..0000000
--- a/docs/os/modules/json/json_encode_object_entry.md
+++ /dev/null
@@ -1,42 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> json_encode_object_entry </font>
-
-```no-highlight
- int json_encode_object_entry(struct json_encoder *encoder, char *key, struct json_value *val)
-```
-
-This function writes out a name for a field, followed by ":" character, and the value itself. How value is treated depends on the type of the value.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| encoder | json_encoder to use |
-| key | name to write out |
-| val | value to write out |
-
-
-#### Returned values
-
-0 on success.
-
-
-
-#### Example
-
-```c
-static int
-imgr_list(struct nmgr_jbuf *njb)
-{
- struct json_encoder *enc;
- struct json_value array;
-
- ...
-
- json_encode_object_start(enc);
- json_encode_object_entry(enc, "images", &array);
- json_encode_object_finish(enc);
-
- return 0;
-}
-
-```
diff --git a/docs/os/modules/json/json_encode_object_finish.md b/docs/os/modules/json/json_encode_object_finish.md
deleted file mode 100644
index 762a5c3..0000000
--- a/docs/os/modules/json/json_encode_object_finish.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> json_encode_object_finish </font>
-
-```no-highlight
- int json_encode_object_finish(struct json_encoder *encoder)
-```
-
-This function finalizes the encoded JSON object. This means writing out the last "}" character.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| encoder | json_encoder to use |
-
-
-#### Returned values
-
-0 on success.
-
-
-
-#### Example
-
-```c
-static int
-imgr_list(struct nmgr_jbuf *njb)
-{
- struct json_encoder *enc;
- struct json_value array;
-
- ...
-
- json_encode_object_start(enc);
- json_encode_object_entry(enc, "images", &array);
- json_encode_object_finish(enc);
-
- return 0;
-}
-
-```
diff --git a/docs/os/modules/json/json_encode_object_key.md b/docs/os/modules/json/json_encode_object_key.md
deleted file mode 100644
index 3432941..0000000
--- a/docs/os/modules/json/json_encode_object_key.md
+++ /dev/null
@@ -1,41 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> json_encode_object_key </font>
-
-```no-highlight
- int json_encode_object_key(struct json_encoder *encoder, char *key)
-```
-
-This function writes out a name for a field, followed by ":" character. You would use this e.g. when the value that follows is a JSON object.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| encoder | json_encoder to use |
-| key | name to write out |
-
-
-#### Returned values
-
-0 on success.
-
-
-
-#### Example
-
-```c
-int
-nmgr_def_taskstat_read(struct nmgr_jbuf *njb)
-{
- ...
-
- struct json_value jv;
-
- json_encode_object_start(&njb->njb_enc);
- JSON_VALUE_INT(&jv, NMGR_ERR_EOK);
- json_encode_object_entry(&njb->njb_enc, "rc", &jv);
-
- json_encode_object_key(&njb->njb_enc, "tasks");
- json_encode_object_start(&njb->njb_enc);
- ...
-}
-```
diff --git a/docs/os/modules/json/json_encode_object_start.md b/docs/os/modules/json/json_encode_object_start.md
deleted file mode 100644
index 62e9010..0000000
--- a/docs/os/modules/json/json_encode_object_start.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> json_encode_object_start </font>
-
-```no-highlight
- int json_encode_object_start(struct json_encoder *encoder)
-```
-
-This function starts the encoded JSON object. Usually this means writing out the initial "{" character.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| encoder | json_encoder to use |
-
-
-#### Returned values
-
-0 on success.
-
-
-
-#### Example
-
-```c
-static int
-imgr_list(struct nmgr_jbuf *njb)
-{
- struct json_encoder *enc;
- struct json_value array;
-
- ...
-
- json_encode_object_start(enc);
- json_encode_object_entry(enc, "images", &array);
- json_encode_object_finish(enc);
-
- return 0;
-}
-
-```
diff --git a/docs/os/modules/json/json_read_object.md b/docs/os/modules/json/json_read_object.md
deleted file mode 100644
index e8a6ddd..0000000
--- a/docs/os/modules/json/json_read_object.md
+++ /dev/null
@@ -1,60 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> json_read_object </font>
-
-```no-highlight
- int json_read_object(struct json_buffer *jb, const struct json_attr_t *attrs)
-```
-
-This function reads in JSON data stream, while looking for name/value pairs described in *attrs*. *attrs* is an array; end of the array is indicated by an entry with *NULL* as the name.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| jb | json_decoder to use |
-| attrs | array of attributes to look for |
-
-#### Returned values
-
-0 on success.
-
-
-
-#### Example
-
-```c
-
-static int
-imgr_upload(struct nmgr_jbuf *njb)
-{
- ...
- const struct json_attr_t off_attr[4] = {
- [0] = {
- .attribute = "off",
- .type = t_uinteger,
- .addr.uinteger = &off,
- .nodefault = true
- },
- [1] = {
- .attribute = "data",
- .type = t_string,
- .addr.string = img_data,
- .len = sizeof(img_data)
- },
- [2] = {
- .attribute = "len",
- .type = t_uinteger,
- .addr.uinteger = &size,
- .nodefault = true
- }
- };
- ...
-
- rc = json_read_object(&njb->njb_buf, off_attr);
- if (rc || off == UINT_MAX) {
- rc = OS_EINVAL;
- goto err;
- }
- ...
-}
-
-```
diff --git a/docs/os/modules/logs/logs.md b/docs/os/modules/logs/logs.md
deleted file mode 100644
index 36f0bda..0000000
--- a/docs/os/modules/logs/logs.md
+++ /dev/null
@@ -1,158 +0,0 @@
-## Logging
-
-Mynewt log package supports logging of information within a Mynewt application. It allows packages to define their own log streams with separate names. It also allows an application to control the output destination of logs.
-<br>
-### Description
-
-In the Mynewt OS, the log package comes in two versions:
-
-* The `sys/log/full` package implements the complete log functionality and API.
-
-* The `sys/log/stub` package implements stubs for the API.
-
-Both packages export the `log` API, and any package that uses the log API must list `log` as a requirement in its `pkg.yml` file as follows:
-
-```no-highlight
-pkg.req_apis:
- - log
-```
-
-<br>
-The application's `pkg.yml` file specifies the version of the log package to use.
-A project that requires the full logging capability must list the `sys/log/full` package as a dependency in its `pkg.yml` file:
-```no-highlight
-pkg.deps:
- - sys/log/full
-```
-<br>
-You can use the `sys/log/stub` package if you want to build your application without logging to reduce code size.
-
-<br>
-
-#### Syscfg Settings
-
-The `LOG_LEVEL` syscfg setting allows you to specify the level of logs to enable in your application. Only logs for levels higher or equal to the value of `LOG_LEVEL` are enabled. The amount of logs you include affects your application code size. `LOG_LEVEL: 0` specifies LOG_LEVEL_DEBUG and includes all logs. You set `LOG_LEVEL: 255` to disable all logging. The `#defines` for the log levels are specified in the `sys/log/full/include/log/log.h` file. For example the following setting corresponds to LOG_LEVEL_ERROR:
-
-```no-highlight
-syscfg.vals:
- LOG_LEVEL: 3
-```
-
-The `LOG_LEVEL` setting applies to all modules registered with the log package.
-
-<br>
-### Log
-
-Each log stream requires a `log` structure to define its logging properties.
-<br>
-
-### Log Handler
-
-To use logs, a log handler that handles the I/O from the log is required. The log package comes with three pre-built log handlers:
-
-* console -- streams log events directly to the console port. Does
-not support walking and reading.
-* cbmem -- writes/reads log events to a circular buffer. Supports walking
-and reading for access by newtmgr and shell commands.
-* fcb -- writes/reads log events to a [flash circular buffer](/os/modules/fcb/fcb.md). Supports walking and reading for access by newtmgr and shell commands.
-
-In addition, it is possible to create custom log handlers for other methods.
-Examples may include
-
-* Flash file system
-* Flat flash buffer
-* Streamed over some other interface
-
-To use logging, you typically do not need to create your own log handler. You can use one of the pre-built ones.
-
-A package or an application must define a variable of type `struct log` and register a log handler for it with the log package. It must call the `log_register()` function to specify the log handler to use:
-
-```c
-log_register(char *name, struct log *log, const struct log_handler *lh, void *arg, uint8_t level)
-
-```
-
-The parameters are:
-
-* `name`- Name of the log stream.
-* `log` - Log instance to register,
-* `lh` - Pointer to the log handler. You can specify one of the pre-built ones:
- * `&log_console_handler` for console
- * `&log_cbm_handler` for circular buffer
- * `&log_fcb_handler` for flash circular buffer
-* `arg` - Opaque argument that the specified log handler uses. The value of this argument depends on the log handler you specify:
- * NULL for the `log_console_handler`.
- * Pointer to an initialized `cbmem` structure (see `util/cbmem` package) for the `log_cbm_handler`.
- * Pointer to an initialized `fcb_log` structure (see `fs/fcb` package) for the `log_fcb_handler`.
-
-Typically, a package that uses logging defines a global variable, such as `my_package_log`, of type `struct log`. The package can call the `log_register()` function with default values, but usually an application will override the logging properties and where to log to. There are two ways a package can allow an application to override the values:
-
-* Define system configuration settings that an application can set and the package can then call the `log_register()` function with the configuration values.
-* Make the `my_package_log` variable external and let the application call the `log_register()` function to specify a log handler for its specific purpose.
-
-
-### Configuring Logging for Packages that an Application Uses
-Here is an example of how an application can set the log handlers for the logs of the packages that the application includes.
-
-In this example, the `package1` package defines the variable `package1_log` of type `struct log` and externs the variable. Similarly, the `package2` package defines the variable `package2_log` and externs the variable. The application sets logs for `package1` to use console and sets logs for `package2` to use a circular buffer.
-
-```c
-#include <package1/package1.h>
-#include <package2/package2.h>
-#include <util/cbmem.h>
-
-#include <log/log.h>
-
-static uint32_t cbmem_buf[MAX_CBMEM_BUF];
-static struct cbmem cbmem;
-
-
-void app_log_init(void)
-{
-
-
-
- log_register("package1_log", &package1_log, &log_console_handler, NULL, LOG_SYSLEVEL);
-
- cbmem_init(&cbmem, cbmem_buf, MAX_CBMEM_BUF);
- log_register("package2_log", &package2_log, &log_cbmem_handler, &cbmem, LOG_SYSLEVEL);
-
-}
-```
-
-<br>
-
-### Implementing a Package that Uses Logging
-This example shows how a package logs to console. The package registers default logging properties to use the console, but allows an application to override the values. It defines the `my_package_log` variable and makes it external so an application can override log handler.
-
-Make the `my_package_log` variable external:
-```c
-/* my_package.h*/
-
-/* pick a unique name here */
-extern struct log my_package_log;
-```
-
-<br>
-
-Define the `my_package_log` variable and register the console log handler:
-
-```c
-/* my_package.c */
-
-struct log my_package_log;
-
-{
- ...
-
- /* register my log with a name to the system */
- log_register("log", &my_package_log, &log_console_handler, NULL, LOG_LEVEL_DEBUG);
-
- LOG_DEBUG(&my_package_log, LOG_MODULE_DEFAULT, "bla");
- LOG_DEBUG(&my_package_log, LOG_MODULE_DEFAULT, "bab");
-}
-```
-
-### Log API and Log Levels
-For more information on the `log` API and log levels, see the `sys/log/full/include/log/log.h` header file.
-
diff --git a/docs/os/modules/sensor_framework/sensor_api.md b/docs/os/modules/sensor_framework/sensor_api.md
deleted file mode 100644
index b51aee4..0000000
--- a/docs/os/modules/sensor_framework/sensor_api.md
+++ /dev/null
@@ -1,264 +0,0 @@
-## Sensor API
-
-The sensor API implements the sensor abstraction and the functions:
-
-* For a sensor device driver package to initialize a sensor object with the device specific information.
-
-* For an application to read sensor data from a sensor and to configure a sensor for polling.
-
-A sensor is represented by the `struct sensor` object.
-
-### Sensor API Functions Used by a Sensor Device Driver Package
-
-
-A sensor device driver package must use the sensor API to initialize device specific information for a sensor object and to change sensor configuration types.
-
-#### Initializing a Sensor Object
-
-When the BSP or the sensor creator package creates an OS device for a sensor named `SENSORNAME`, it specifies the `<sensorname>_init()` callback function, that the device driver exports, for the `os_dev_create()` function to call to initialize the device. The `<sensorname>_init()` function must use the following sensor API functions to set the driver and interface information in the sensor object:
-
-* The `sensor_init()` function to initialize the `struct sensor` object for the device.
-
-* The `sensor_set_driver()` function to set the types that the sensor device supports and the sensor driver functions to read the sensor data from the device and to retrieve the value type for a given sensor type.
-
-* The `sensor_set_interface()` function to set the interface to use to communicate with the sensor device.
-
-**Notes**:
-
-* See the [Sensor Device Driver](/os/modules/sensor_framework/sensor_driver.md) page for the functions and data structures that a sensor driver package exports.
-
-* The `<sensorname>_init()` function must also call the `sensor_mgr_register()` function to register the sensor with the sensor manager. See the [Sensor Manager API](/os/modules/sensor_framework/sensor_manager_api.md) for details.
-
-<br>
-#### Setting the Configured Sensor Types
-
-The BSP, or the sensor creator package, also calls the `<sensorname>_config()` function to configure the sensor device with default values. The `<sensorname>_config()` function is exported by the sensor device driver and must call the sensor API `sensor_set_type_mask()` function to set the configured sensor types in the sensor object. The configured sensor types are a subset of the sensor types that the device supports. The sensor framework must know the sensor types that a sensor device is configured for because it only reads sensor data for the configured sensor types.
-
-**Note:** An application may also call the `<sensorname>_config()` function to configure the sensor device.
-
-### Sensor API Functions Used By an Application
-
-The sensor API provides the functions for an application to read sensor data from a sensor and to configure a sensor for polling.
-
-#### Reading Sensor Data
-
-An application calls the `sensor_read()` function to read sensor data from a sensor device. You specify a bit mask of the configured sensor types to read from a sensor device and a callback function to call when the sensor data is read. The callback is called for each specified configured type and the data read for that sensor type is passed to the callback.
-
-#### Setting a Poll Rate for A Sensor
-
-The sensor manager implements a poller that reads sensor data from a sensor at specified poll intervals. An application must call the `sensor_set_poll_rate_ms()` function to set the poll rate for a sensor in order for poller to poll the sensor.
-
-**Note:** An application needs to register a [sensor listener](/os/modules/sensor_framework/sensor_listener_api.md) to receive the sensor data that the sensor manager poller reads from a sensor.
-
-
-### Data Structures
-
-We list the main data structures that the sensor API uses and mention things to note. For more details, see the [sensor.h](https://github.com/apache/mynewt-core/blob/master/hw/sensor/include/sensor/sensor.h) include file.
-<br>
-
-#### Sensor Object
-
-The `struct sensor` data structure represents the sensor device. The sensor API, the [sensor manager API](/os/modules/sensor_framework/sensor_mgr_api.md), and the [sensor listener API](/os/modules/sensor_framework/sensor_listener_api.md) all operate on the `sensor` object abstraction. A sensor is maintained in the sensor manager global sensors list.
-
-
-```c
-struct sensor {
- /* The OS device this sensor inherits from, this is typically a sensor
- * specific driver.
- */
- struct os_dev *s_dev;
-
- /* The lock for this sensor object */
- struct os_mutex s_lock;
-
-
- /* A bit mask describing the types of sensor objects available from this
- * sensor. If the bit corresponding to the sensor_type_t is set, then this
- * sensor supports that variable.
- */
- sensor_type_t s_types;
-
- /* Sensor mask of the configured sensor type s*/
- sensor_type_t s_mask;
- /**
- * Poll rate in MS for this sensor.
- */
- uint32_t s_poll_rate;
-
- /* The next time at which we want to poll data from this sensor */
- os_time_t s_next_run;
-
- /* Sensor driver specific functions, created by the device registering the
- * sensor.
- */
- struct sensor_driver *s_funcs;
-
- /* Sensor last reading timestamp */
- struct sensor_timestamp s_sts;
-
- /* Sensor interface structure */
- struct sensor_itf s_itf;
-
- /* A list of listeners that are registered to receive data off of this
- * sensor
- */
- SLIST_HEAD(, sensor_listener) s_listener_list;
- /* The next sensor in the global sensor list. */
- SLIST_ENTRY(sensor) s_next;
-};
-
-```
-
-<br>
-
-**Note:** There are two fields, `s_types` and `s_mask`, of type `sensor_type_t`. The `s_types` field is a bit mask that specifies the sensor types that the sensor device supports. The `s_mask` field is a bit mask that specifies the sensor types that the sensor device is configured for. Only sensor data for a configured sensor type can be read.
-
-<br>
-#### Sensor Types
-
-The `sensor_type_t` type is an enumeration of a bit mask of sensor types, with each bit representing one sensor type. Here is an excerpt of the enumeration values. See the [sensor.h](https://github.com/apache/mynewt-core/blob/master/hw/sensor/include/sensor/sensor.h) for details:
-
-```c
-
-typedef enum {
- /* No sensor type, used for queries */
- SENSOR_TYPE_NONE = 0,
- /* Accelerometer functionality supported */
- SENSOR_TYPE_ACCELEROMETER = (1 << 0),
- /* Magnetic field supported */
- SENSOR_TYPE_MAGNETIC_FIELD = (1 << 1),
- /* Gyroscope supported */
- SENSOR_TYPE_GYROSCOPE = (1 << 2),
- /* Light supported */
- SENSOR_TYPE_LIGHT = (1 << 3),
- /* Temperature supported */
- SENSOR_TYPE_TEMPERATURE = (1 << 4),
-
- ....
-
- SENSOR_TYPE_USER_DEFINED_6 = (1 << 31),
- /* A selector, describes all sensors */
- SENSOR_TYPE_ALL = 0xFFFFFFFF
-
-} sensor_type_t;
-
-```
-
-<br>
-
-#### Sensor Interface
-
-The `struct sensor_itf` data structure represents the interface the sensor device driver uses to communicate with the sensor device.
-
-
-```c
-struct sensor_itf {
-
- /* Sensor interface type */
- uint8_t si_type;
-
- /* Sensor interface number */
- uint8_t si_num;
-
- /* Sensor CS pin */
- uint8_t si_cs_pin;
-
- /* Sensor address */
- uint16_t si_addr;
-};
-
-```
-
-The `si_cs_pin ` specifies the chip select pin and is optional. The `si_type` field must be of the following types:
-
-```c
-
-#define SENSOR_ITF_SPI (0)
-#define SENSOR_ITF_I2C (1)
-#define SENSOR_ITF_UART (2)
-
-```
-
-<br>
-#### Sensor Value Type
-
-The `struct sensor_cfg` data structure represents the configuration sensor type:
-
-```c
-/**
- * Configuration structure, describing a specific sensor type off of
- * an existing sensor.
- */
-struct sensor_cfg {
- /* The value type for this sensor (e.g. SENSOR_VALUE_TYPE_INT32).
- * Used to describe the result format for the value corresponding
- * to a specific sensor type.
- */
- uint8_t sc_valtype;
- /* Reserved for future usage */
- uint8_t _reserved[3];
-};
-
-```
-
-<br>
-Only the `sc_valtype` field is currently used and specifies the data value type of the sensor data. The valid value types are:
-
-
-```c
-
-/**
- * Opaque 32-bit value, must understand underlying sensor type
- * format in order to interpret.
- */
-#define SENSOR_VALUE_TYPE_OPAQUE (0)
-/**
- * 32-bit signed integer
- */
-#define SENSOR_VALUE_TYPE_INT32 (1)
-/**
- * 32-bit floating point
- */
-#define SENSOR_VALUE_TYPE_FLOAT (2)
-/**
- * 32-bit integer triplet.
- */
-#define SENSOR_VALUE_TYPE_INT32_TRIPLET (3)
-/**
- * 32-bit floating point number triplet.
- */
-#define SENSOR_VALUE_TYPE_FLOAT_TRIPLET (4)
-
-```
-<br>
-#### Sensor Driver Functions
-
-The `struct sensor_device` data structure represents the device driver functions. The sensor device driver must implement the functions and set up the function pointers.
-
-```
-struct sensor_driver {
- sensor_read_func_t sd_read;
- sensor_get_config_func_t sd_get_config;
-};
-```
-
-<br>
-
-
-<br>
-### List of Functions:
-
-These are the functions defined by the sensor API. Please see the [sensor.h](https://github.com/apache/mynewt-core/blob/master/hw/sensor/include/sensor/sensor.h) include file for details.
-
-| Function | Description |
-|---------|-------------|
-| sensor_init | Initializes a sensor. A sensor device driver uses this function. |
-| sensor_set_driver | Sets the sensor types that the sensor device supports, and the driver functions to read data and to get value type for a sensor type. A sensor device driver uses this function.|
-| sensor_set_interface| Sets the sensor interface to use to communicate with the sensor device. A sensor device driver uses this function.|
-| sensor_set_type_mask | Specifies the sensor types that a sensor device is configured for. A sensor device driver uses this function.|
-| sensor_read | Reads sensor data for the specified sensor types. An application uses this function.|
-|sensor_set_poll_rate_ms| Sets poll rate for the sensor manager to poll the sensor device. An application uses this function.|
-|sensor_lock| Locks the sensor object for exclusive access.|
-|sensor_unlock| Unlocks the sensor object. |
-|SENSOR_GET_DEV| Macro that the sensor device driver uses to retrieve the os_dev from the sensor object. |
-|SENSOR_GET_ITF| Macro that the sensor device driver uses to retrieve the sensor_itf from the sensor object.|
diff --git a/docs/os/modules/sensor_framework/sensor_create.md b/docs/os/modules/sensor_framework/sensor_create.md
deleted file mode 100644
index 4be5f63..0000000
--- a/docs/os/modules/sensor_framework/sensor_create.md
+++ /dev/null
@@ -1,215 +0,0 @@
-## Creating and Configuring a Sensor Device
-
-The steps to create and configure OS devices for onboard and off-board sensors are very similar. The BSP creates the OS devices for onboard sensors and the `hw/sensor/creator/` package creates the OS devices for off-board sensors.
-
-We discuss how a BSP creates a device for an onboard sensor and then discuss what the `hw/sensor/creator` package does differently to create an off-board sensor. We also discuss how an application can change the default configuration for a sensor device.
-
-<br>
-### Creating an Onboard Sensor
-<br>
-To create and initialize a sensor device named `SENSORNAME`, the BSP implements the following in the `hal_bsp.c` file.
-
-**Note**: All example excerpts are from the code that creates the LIS2DH12 onboard sensor in the nrf52_thingy BSP.
-
-<br>
-1. Define a `<SENSORNAME>_ONB` syscfg setting to specify whether the onboard sensor named `SENSORNAME` is enabled. The setting is disabled by default. The setting is used to conditionally include the code to create a sensor device for `SENSORNAME` when it is enabled by the application. For example:
-
-```no-highlight
-
-syscfg.defs:
- LIS2DH12_ONB:
- description: 'NRF52 Thingy onboard lis2dh12 sensor'
- value: 0
-```
-
-<br>
-2. Include the "<sensorname>/<sensorname>.h" header file. The BSP uses the functions and data structures that a device driver package exports. See the [Sensor Device Driver](/os/modules/sensor_framework/sensor_driver.md) page for details.
-
-<br>
-3. Declare a variable named `sensorname` of type `struct sensorname`. For example:
-
-```c
-
-#if MYNEWT_VAL(LIS2DH12_ONB)
-#include <lis2dh12/lis2dh12.h>
-static struct lis2dh12 lis2dh12;
-#endif
-
-```
-
-<br>
-4. Declare and specify the values for a variable of type `struct sensor_itf` that the sensor device driver uses to communicate with the sensor device. For example:
-
-```c
-
-#if MYNEWT_VAL(LIS2DH12_ONB)
-static struct sensor_itf i2c_0_itf_lis = {
- .si_type = SENSOR_ITF_I2C,
- .si_num = 0,
- .si_addr = 0x19
-<br>
-
-```
-
-<br>
-5. In the `hal_bsp_init()` function, create an OS device for the sensor device. Call the `os_dev_create()` function and pass the following to the function:
-
-* A pointer to the `sensorname` variable from step 3.
-* A pointer to the `<sensorname>_init()` callback function. Note that the device driver package exports this function.
-* A pointer to the `struct sensor_itf` variable from step 4.
-
-For example:
-
-```hl_lines="7 8 9 10 11"
-
-static void
-sensor_dev_create(void)
-{
- int rc;
- (void)rc;
-
-#if MYNEWT_VAL(LIS2DH12_ONB)
- rc = os_dev_create((struct os_dev *) &lis2dh12, "lis2dh12_0",
- OS_DEV_INIT_PRIMARY, 0, lis2dh12_init, (void *)&i2c_0_itf_lis);
- assert(rc == 0);
-#endif
-
-}
-
-void
-hal_bsp_init(void)
-{
- int rc;
-
- ...
-
-
- sensor_dev_create();
-
-}
-
-```
-<br>
-6. Define a `config_<sensorname>_sensor()` function to set the default configuration for the sensor. This function opens the OS device for the sensor device, initializes the a `cfg` variable of type `struct <sensorname>_cfg` with the default settings, calls the `<sensorname>_config()` driver function to configure the device, and closes the device. This function is called when the BSP is initialized during sysinit(). For example:
-
-```c
-
-int
-config_lis2dh12_sensor(void)
-{
-#if MYNEWT_VAL(LIS2DH12_ONB)
- int rc;
- struct os_dev *dev;
- struct lis2dh12_cfg cfg;
-
- dev = (struct os_dev *) os_dev_open("lis2dh12_0", OS_TIMEOUT_NEVER, NULL);
- assert(dev != NULL);
-
- memset(&cfg, 0, sizeof(cfg));
-
- cfg.lc_s_mask = SENSOR_TYPE_ACCELEROMETER;
- cfg.lc_rate = LIS2DH12_DATA_RATE_HN_1344HZ_L_5376HZ;
- cfg.lc_fs = LIS2DH12_FS_2G;
- cfg.lc_pull_up_disc = 1;
-
- rc = lis2dh12_config((struct lis2dh12 *)dev, &cfg);
- SYSINIT_PANIC_ASSERT(rc == 0);
-
- os_dev_close(dev);
-#endif
- return 0;
-}
-
-```
-
-<br>
-7. Add the following in the BSP `pkg.yml` file:
-
-* A conditional package dependency for the `hw/drivers/sensors/<sensorname>` package when the `<SENSORNAME>_ONB` setting is enabled.
-
-* The `config_<sensorname>_sensor` function with an init stage of 400 to the `pkg.init` parameter.
-
-For example:
-
-```no-highlight
-
-pkg.deps.LIS2DH12_ONB:
- - hw/drivers/sensors/lis2dh12
-
-pkg.init:
- config_lis2dh12_sensor: 400
-
-```
-<br>
-### Creating an Off-Board Sensor
-
-The steps to create an off-board sensor is very similar to the steps for a BSP. The `hw/sensor/creator/` package also declares the variables and implements the `config_<sensorname>_sensor()` function described for a BSP. The package does the following differently.
-
-**Note**: All example excerpts are from the code that creates the BNO055 off-board sensor in `hw/sensor/creator` package.
-
-<br>
-1. Define a `<SENSORNAME>_OFB` syscfg setting to specify whether the off-board sensor named `SENSORNAME` is enabled. This setting is disabled by default. The `hw/sensor/creator` package uses the setting to conditionally include the code to create the sensor device when it is enabled by the application.
-
-```no-highlight
-
-# Package: hw/sensor/creator
-
-syscfg.defs:
- ...
-
- BNO055_OFB:
- description: 'BNO055 is present'
- value : 0
-
- ...
-
-```
-
-<br>
-2. Add the calls to the `os_dev_create()` and the `config_<sensorname>_sensor()` functions in the `sensor_dev_create()` function defined in the `sensor_creator.c` file . The `sensor_dev_create()` function is the `hw/sensor/creator` package initialization function that `sysinit()` calls.
-
-For example:
-
-```c
-
-void
-sensor_dev_create(void)
-{
- int rc;
-
- ...
-
-#if MYNEWT_VAL(BNO055_OFB)
- rc = os_dev_create((struct os_dev *) &bno055, "bno055_0",
- OS_DEV_INIT_PRIMARY, 0, bno055_init, (void *)&i2c_0_itf_bno);
- assert(rc == 0);
-
- rc = config_bno055_sensor();
- assert(rc == 0);
-#endif
-
- ....
-
-}
-
-```
-
-<br>
-3. Add a conditional package dependency for the `hw/drivers/sensors/<sensorname>` package when the `<SENSORNAME>_OFB` setting is enabled. For example:
-
-```no-highlight
-
-pkg.deps.BNO055_OFB:
- - hw/drivers/sensors/bno055
-
-```
-
-<br>
-
-### Reconfiguring A Sensor Device by an Application
-
-The BSP and sensor creator package use a default configuration and enable all supported sensors on a sensor device by default. If the default configuration does not meet your application requirements, you may change the default configuration for a sensor device. As in the `config_<sensorname>_sensor` function, an application must open the OS device for the sensor, set up the values for the `<sensorname>_cfg` structure, call the `<sensorname>_config()` device driver function to change the configuration in the device, and close the OS device.
-
-We recommend that you copy the `config_<sensorname>_sensor()` function from the BSP or the sensor creator package in to your application code and change the desired settings. Note that you must keep all the fields in the `<sensorname>_cfg` structure initialized with the default values for the settings that you do not want to change.
-
-See the [Changing the Default Configuration for a Sensor Tutorial](/os/tutorials/sensors/sensor_offboard_config/) for more details on how to change the default sensor configuration from an application.
diff --git a/docs/os/modules/sensor_framework/sensor_driver.md b/docs/os/modules/sensor_framework/sensor_driver.md
deleted file mode 100644
index 0f211b2..0000000
--- a/docs/os/modules/sensor_framework/sensor_driver.md
+++ /dev/null
@@ -1,360 +0,0 @@
-## Sensor Device Driver
-
-A Mynewt sensor device driver uses the sensor framework abstraction and API to enable applications to access sensor data from any Mynewt sensor device using a common interface. The sensor device driver must also use the Mynewt HAL interface to communicate with and control a sensor device.
-
-This guide describes what a sensor device driver must implement to enable a sensor device within the sensor framework. For information on using the HAL API to communicate with a sensor device, see the [Hardware Layer Abstraction Guide](/os/modules/hal/hal.md).
-
-The `hw/drivers/sensors/<sensorname>` package implements the device driver for the sensor named `SENSORNAME`.
-
-**Note:** All example excerpts are from the BNO055 sensor device driver package.
-
-<br>
-### Initializing and Configuring a Sensor Device
-
-A driver package for a sensor named `SENSORNAME` must define and export the following data structures and functions to initialize and configure a device:
-
-* `struct <sensorname>`: This data structure represents a sensor device. The structure must include a `dev` field of type `struct os_dev` and a `sensor` field of type `struct sensor`. For example:
-
- struct bno055 {
- struct os_dev dev;
- struct sensor sensor;
- struct bno055_cfg cfg;
- os_time_t last_read_time;
- };
-
-* `struct <sensorname>_cfg`: This data structure defines the configuration for a sensor device. The structure fields are specific to the device. This is the data structure that a BSP, the sensor creator package, or an application sets to configure a sensor device. For example:
-
- struct bno055_cfg {
- uint8_t bc_opr_mode;
- uint8_t bc_pwr_mode;
- uint8_t bc_units;
- uint8_t bc_placement;
- uint8_t bc_acc_range;
- uint8_t bc_acc_bw;
-
- ...
-
- uint32_t bc_mask;
- };
-
-
-* `<sensorname>_init()`: This is the os device initialization callback of type `int (*os_dev_init_func_t)(struct os_dev *, void *)` that the `os_dev_create()` function calls to initialize the device. For example, the bno055 device driver package defines the following function:
-
- int bno055_init(struct os_dev *dev, void *arg)
-
-
- The BSP, which creates a device for an onboard sensor, and the sensor creator package, which creates a device for an off-board sensor, calls the `os_dev_create()` function and passes:
-
- * A pointer to a `struct <sensorname>` variable.
- * The `<sensorname>_init()` function pointer.
- * A pointer to a `struct sensor_itf` variable that specifies the interface the driver uses to communicate with the sensor device.
-
- See the [Creating Sensor Devices](/os/modules/sensor_framework/sensor_create.md) page for more details.
-
- The `os_dev_create()` function calls the `<sensorname>_init()` function with a pointer to the `struct <sensorname>` for the `dev` parameter and a pointer to the `struct sensor_itf` for the `arg` parameter.
-
-* `<sensorname>_config()`: This is the sensor configuration function that the BSP, sensor creator package, or an application calls to configure the sensor device. For example:
-
- int bno055_config(struct bno055 *bno055, struct bno055_cfg *cfg)
-
-<br>
-
-### Defining Functions to Read Sensor Data and Get Sensor Value Type
-
-A device driver must implement the following functions that the sensor API uses to read sensor data and to get the configuration value type for a sensor:
-
-* A function of type `int (*sensor_read_func_t)(struct sensor *, sensor_type_t, sensor_data_func_t, void *, uint32_t)` that the sensor framework uses to read a single value from a sensor for the specified sensor types. The device driver must implement this function such that it reads, for each sensor type set in the bit mask, a single value from the sensor and calls the `sensor_data_funct_t` callback with the opaque callback argument , the sensor data, and the sensor type.
-
-* A function of type `int (*sensor_get_config_func_t)(struct sensor *, sensor_type_t, struct sensor_cfg *)` that returns the value type for the specified sensor type. For example, the value type for a `SENSOR_VALUE_TYPE_TEMPERATURE` sensor might be `SENSOR_VALUE_TYPE_FLOAT` and the value type for a `SENSOR_TYPE_ACCELEROMETER` sensor might be `SENSOR_VALUE_TYPE_FLOAT_TRIPLET`.
-
-The driver initializes a `sensor_driver` structure, shown below, with the pointers to these functions:
-
-```c
-
-struct sensor_driver {
- sensor_read_func_t sd_read;
- sensor_get_config_func_t sd_get_config;
-};
-
-```
-
-For example:
-
-```c
-
-static int bno055_sensor_read(struct sensor *, sensor_type_t,
- sensor_data_func_t, void *, uint32_t);
-static int bno055_sensor_get_config(struct sensor *, sensor_type_t,
- struct sensor_cfg *);
-
-static const struct sensor_driver g_bno055_sensor_driver = {
- bno055_sensor_read,
- bno055_sensor_get_config
-};
-
-
-```
-
-<br>
-### Registering the Sensor in the Sensor Framework
-
-The device driver must initialize and register a `struct sensor` object with the sensor manager. See the [Sensor API](/os/modules/sensor_framework/sensor_api.md) and the [Sensor Manager API](/os/modules/sensor_framework/sensor_manager_api.md) pages for more details.
-
-
-The device driver `<sensorname>_init()` function initializes and registers a sensor object as follows:
-
-* Calls the `sensor_init()` function to initialize the `struct sensor` object.
-
-* Calls the `sensor_set_driver()` function to specify the sensor types that the sensor device supports, and the pointer to the `struct sensor_driver` variable that specifies the driver functions to read the sensor data and to get the value type for a sensor.
-
-* Calls the `sensor_set_interface()` function to set the interface that the device driver uses to communicate with the sensor device. The BSP, or sensor creator package for an off-board sensors, sets up the `sensor_itf` and passes it to the `<sensorname>_init()` function. The `sensor_set_interface()` functions saves this information in the sensor object. The device driver uses the `SENSOR_GET_ITF()` macro to retrieve the sensor_itf when it needs to communicate with the sensor device.
-
-* Calls the `sensor_mgr_register()` function to register the sensor with the sensor manager.
-
-For example:
-
-```hl_lines="13 20 25 31 32 33 34 35 41 46"
-
-int
-bno055_init(struct os_dev *dev, void *arg)
-{
- struct bno055 *bno055;
- struct sensor *sensor;
- int rc;
-
- if (!arg || !dev) {
- rc = SYS_ENODEV;
- goto err;
- }
-
- bno055 = (struct bno055 *) dev;
-
- rc = bno055_default_cfg(&bno055->cfg);
- if (rc) {
- goto err;
- }
-
- sensor = &bno055->sensor;
-
- /* Code to setup logging and stats may go here */
- ....
-
- rc = sensor_init(sensor, dev);
- if (rc != 0) {
- goto err;
- }
-
- /* Add the accelerometer/magnetometer driver */
- rc = sensor_set_driver(sensor, SENSOR_TYPE_ACCELEROMETER |
- SENSOR_TYPE_MAGNETIC_FIELD | SENSOR_TYPE_GYROSCOPE |
- SENSOR_TYPE_TEMPERATURE | SENSOR_TYPE_ROTATION_VECTOR |
- SENSOR_TYPE_GRAVITY | SENSOR_TYPE_LINEAR_ACCEL |
- SENSOR_TYPE_EULER, (struct sensor_driver *) &g_bno055_sensor_driver);
- if (rc != 0) {
- goto err;
- }
-
- /* Set the interface */
- rc = sensor_set_interface(sensor, arg);
- if (rc) {
- goto err;
- }
-
- rc = sensor_mgr_register(sensor);
- if (rc != 0) {
- goto err;
- }
-
- return (0);
-err:
- return (rc);
-}
-
-```
-<br>
-
-### Configuring the Sensor Device and Setting the Configured Sensor Types
-
-After the BSP, or the sensor creator package for an off-board sensor, creates the OS device for a sensor, it calls the `<sensorname>_config()` function to configure sensor device information such as mode, power mode, and to set the configured sensor types. The `<sensorname>_config()` function configures the settings on the sensor device. It must also call the `sensor_set_type_mask()` function to set the configured sensor types in the sensor object. The configured sensor types are a subset of the sensor types that the sensor device supports and the sensor framework only reads sensor data for configured sensor types.
-
-**Notes:**
-
-* The device driver uses the `SENSOR_GET_ITF()` macro to retrieve the sensor interface to communicate with the sensor.
-
-* If a sensor device has a chip ID that can be queried, we recommend that the device driver read and verify the chip ID with the data sheet.
-
-* An application may call the `<sensorname>_config()` function to configure the sensor device.
-
-For example:
-
-
-```hl_lines="7 9 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 37 38 39 40 41 42"
-
-int
-bno055_config(struct bno055 *bno055, struct bno055_cfg *cfg)
-{
- int rc;
- uint8_t id;
- uint8_t mode;
- struct sensor_itf *itf;
-
- itf = SENSOR_GET_ITF(&(bno055->sensor));
-
- /* Check if we can read the chip address */
- rc = bno055_get_chip_id(itf, &id);
- if (rc) {
- goto err;
- }
-
- if (id != BNO055_ID) {
- os_time_delay((OS_TICKS_PER_SEC * 100)/1000 + 1);
-
- rc = bno055_get_chip_id(itf, &id);
- if (rc) {
- goto err;
- }
-
- if(id != BNO055_ID) {
- rc = SYS_EINVAL;
- goto err;
- }
- }
-
- ....
-
- /* Other code to set the configuration on the sensor device. */
-
- ....
-
- rc = sensor_set_type_mask(&(bno055->sensor), cfg->bc_mask);
- if (rc) {
- goto err;
- }
-
- bno055->cfg.bc_mask = cfg->bc_mask;
-
- return 0;
-err:
- return rc;
-}
-
-```
-
-
-<br>
-### Implementing a Sensor Device Shell Command
-
-A sensor device driver package may optionally implement a sensor device shell command that retrieves and sets sensor device information to aid in testing and debugging. While the sensor framework [sensor shell command](/os/modules/sensor_framework/sensor_shell.md) reads sensor data for configured sensor types and is useful for testing an application, it does not access low level device information, such as reading register values and setting hardware configurations, that might be needed to test a sensor device or to debug the sensor device driver code. A sensor device shell command implementation is device specific but should minimally support reading sensor data for all the sensor types that the device supports because the sensor framework `sensor` shell command only reads sensor data for configured sensor types.
-
-The package should:
-
-* Name the sensor device shell command `<sensorname>`. For example, the sensor device shell command for the BNO055 sensor device is `bno055`.
-
-* Define a `<SENSORNAME>_CLI` syscfg setting to specify whether the shell command is enabled and disable the setting by default.
-
-* Export a `<sensorname>_shell_init()` function that an application calls to initialize the sensor shell command when the `SENSORNAME_CLI` setting is enabled.
-
-
-For an example on how to implement a sensor device shell command, see the [bno055 shell command](https://github.com/apache/mynewt-core/blob/master/hw/drivers/sensors/bno055/src/bno055_shell.c) source code. See the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055.md) for examples of the bno055 shell command.
-
-<br>
-
-### Defining Logs
-
-A sensor device driver should define logs for testing purposes. See the [Log OS Guide](os/modules/logs/logs.md) for more details on how to add logs. The driver should define a `<SENSORNAME>_LOG` syscfg setting to specify whether logging is enabled and disable the setting by default.
-
-Here is an example from the BNO055 sensor driver package:
-
-```hl_lines="1 2 3 5 6 7 8 9 10 11 12 13 14 28 29 30"
-
-#if MYNEWT_VAL(BNO055_LOG)
-#include "log/log.h"
-#endif
-
-if MYNEWT_VAL(BNO055_LOG)
-#define LOG_MODULE_BNO055 (305)
-#define BNO055_INFO(...) LOG_INFO(&_log, LOG_MODULE_BNO055, __VA_ARGS__)
-#define BNO055_ERR(...) LOG_ERROR(&_log, LOG_MODULE_BNO055, __VA_ARGS__)
-static struct log _log;
-#else
-#define BNO055_INFO(...)
-#define BNO055_ERR(...)
-#endif
-
- ...
-
-int
-bno055_init(struct os_dev *dev, void *arg)
-{
-
- ...
-
- rc = bno055_default_cfg(&bno055->cfg);
- if (rc) {
- goto err;
- }
-
-#if MYNEWT_VAL(BNO055_LOG)
- log_register(dev->od_name, &_log, &log_console_handler, NULL, LOG_SYSLEVEL);
-#endif
-
- ...
-}
-
-```
-
-
-<br>
-### Defining Stats
-
-A sensor device driver may also define stats for the sensor. See the [Stats OS Guide](os/modules/stats/stats.md) for more details on how to add stats. The driver should define a `<SENSORNAME>_STATS` syscfg setting to specify whether stats is enabled and disable the setting by default.
-
-Here is an example from the BNO055 sensor driver package:
-
-
-```hl_lines="1 2 3 5 6 7 8 9 11 12 13 14 16 17 18 29 30 31 32 33 34 35 36 37 38 39 "
-
-#if MYNEWT_VAL(BNO055_STATS)
-#include "stats/stats.h"
-#endif
-
-#if MYNEWT_VAL(BNO055_STATS)
-/* Define the stats section and records */
-STATS_SECT_START(bno055_stat_section)
- STATS_SECT_ENTRY(errors)
-STATS_SECT_END
-
-/* Define stat names for querying */
-STATS_NAME_START(bno055_stat_section)
- STATS_NAME(bno055_stat_section, errors)
-STATS_NAME_END(bno055_stat_section)
-
-/* Global variable used to hold stats data */
-STATS_SECT_DECL(bno055_stat_section) g_bno055stats;
-#endif
-
- ...
-
-
-int
-bno055_init(struct os_dev *dev, void *arg)
-{
-
- ...
-
-#if MYNEWT_VAL(BNO055_STATS)
- /* Initialise the stats entry */
- rc = stats_init(
- STATS_HDR(g_bno055stats),
- STATS_SIZE_INIT_PARMS(g_bno055stats, STATS_SIZE_32),
- STATS_NAME_INIT_PARMS(bno055_stat_section));
- SYSINIT_PANIC_ASSERT(rc == 0);
- /* Register the entry with the stats registry */
- rc = stats_register(dev->od_name, STATS_HDR(g_bno055stats));
- SYSINIT_PANIC_ASSERT(rc == 0);
-#endif
-
- ...
-}
-
-```
diff --git a/docs/os/modules/sensor_framework/sensor_framework.png b/docs/os/modules/sensor_framework/sensor_framework.png
deleted file mode 100644
index 8114e06..0000000
--- a/docs/os/modules/sensor_framework/sensor_framework.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/modules/sensor_framework/sensor_framework_overview.md b/docs/os/modules/sensor_framework/sensor_framework_overview.md
deleted file mode 100644
index bad49bf..0000000
--- a/docs/os/modules/sensor_framework/sensor_framework_overview.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Mynewt Sensor Framework Overview
-
-The Mynewt sensor framework is an abstraction layer between an application and sensor devices. The sensor framework provides the following support:
-
-* A set of APIs that allows developers to develop sensor device drivers within a common framework and enables application developers to develop applications that can access sensor data from any Mynewt sensor device using a common interface.
-
-* Support for onboard and off-board sensors.
-
-* An OIC sensor server that exposes sensors as OIC resources and handles OIC CoAP requests for the sensor resources. A developer can easily develop a MyNewt OIC sensor enabled application that serves sensor resource requests from OIC client applications.
-
-* A sensor shell command and optional sensor device driver shell commands to view sensor data and manage sensor device settings for testing and debugging sensor enabled applications and sensor device drivers.
-
-
-<br>
-
-
-
-## Overview of Sensor Support Packages
-
-
-In this guide and the package source code, we use `SENSORNAME` (all uppercase) to refer to a sensor product name. For each sensor named `SENSORNAME`:
-
-* The package name for the sensor device driver is `<sensorname>`. All functions and data structures that the sensor device driver exports are prefixed with `<sensorname>`.
-
-* All syscfg settings defined for the sensor are prefixed with `<SENSORNAME>`. For example:
- * The `<SENSORNAME>_CLI` syscfg setting defined in the device driver package to specify whether to enable the sensor device shell command.
- * The `<SENSORNAME>_ONB` syscfg setting defined in the BSP to specify whether the onboard sensor is enabled.
- * The `<SENSORNAME>_OFB` syscfg setting defined in the sensor creator package to specify whether to enable the off-board sensor.
-
-The following Mynewt packages provide sensor support and are needed to build a sensor enabled application.
-
-* `hw/sensor`: The sensor framework package. This package implements the [sensor framework APIs](/os/modules/sensor_framework/sensor_api.md), the [OIC sensor server](/os/modules/sensor_framework/sensor_oic.md), and the [sensor shell command](/os/modules/sensor_framework/sensor_shell.md).
-
-* `hw/sensor/creator`: The sensor creator package. This package supports off-board sensor devices. It creates the OS devices for the sensor devices that are enabled in an application and configures the sensor devices with default values. See the [Creating and Configuring a Sensor Device](/os/modules/sensor_framework/sensor_create.md) page for more information.
-
- **Note:** This package is only needed if you are building an application with off-board sensors enabled.
-
-* `hw/bsp/`: The BSP for boards that support onboard sensors. The BSP creates the OS devices for the onboard sensors that the board supports and configures the sensors with default values. See the [Creating and Configuring a Sensor Device](/os/modules/sensor_framework/sensor_create.md) page for more information.
-
-* `hw/drivers/sensors/*`: These are the sensor device driver packages. The `hw/drivers/sensors/<sensorname>` package is the device driver for a sensor named `SENSORNAME`. See the [Sensor Device Driver](/os/modules/sensor_framework/sensor_driver.md) page for more information.
-
diff --git a/docs/os/modules/sensor_framework/sensor_listener_api.md b/docs/os/modules/sensor_framework/sensor_listener_api.md
deleted file mode 100644
index 844c884..0000000
--- a/docs/os/modules/sensor_framework/sensor_listener_api.md
+++ /dev/null
@@ -1,53 +0,0 @@
-## Sensor Listener API
-
-The sensor listener API allows an application to register listeners for sensors and get notified whenever sensor data are read from the sensor devices. An application calls the `sensor_register_listener()` function to register a listener that specifies the callback function and the types of sensor data to listen for from a sensor device.
-
-When the `sensor_read()` function defined in the [sensor API](/os/modules/sensor_framework/sensor_api.md) is called to read the sensor data for the specified sensor types from a sensor, the `sensor_read()` function calls the listener callback, passing it the sensor data that is read from the sensor.
-
-An application calls the `sensor_unregister_listener()` function to unregister a listener if it no longer needs notifications when data is read from a sensor.
-
-An application can use listeners in conjunction with the sensor manager poller. An application can configure a polling interval for a sensor and register a listener for the sensor types it wants to listen for from the sensor. When the sensor manager poller reads the sensor data from the sensor at each polling interval, the listener callback is called with the sensor data passed to it.
-
-An application can also use listeners for other purposes. For example, an application that uses the OIC sensor server may want to register listeners. The OIC sensor server handles all the OIC requests for the sensor resources and an application does not know about the OIC requests. An application can install a listener if it wants to know about a request for a sensor resource or use the sensor data that the OIC sensor server reads from the sensor.
-
-
-### Data Structures
-
-The `struct sensor_listener` data structure represents a listener. You must initialize a listener structure with a bit mask of the sensor types to listen for from a sensor, a callback function that is called when sensor data is read for one of the sensor types, and an opaque argument to pass to the callback before you call the `sensor_register_listener()` function to register a listener.
-
-```c
-
-struct sensor_listener {
-{
- /* The type of sensor data to listen for, this is interpreted as a
- * mask, and this listener is called for all sensor types on this
- * sensor that match the mask.
- */
- sensor_type_t sl_sensor_type;
-
- /* Sensor data handler function, called when has data */
- sensor_data_func_t sl_func;
-
- /* Argument for the sensor listener */
- void *sl_arg;
-
- /* Next item in the sensor listener list. The head of this list is
- * contained within the sensor object.
- */
- SLIST_ENTRY(sensor_listener) sl_next;
-};
-
-```
-### List of Functions:
-
-These are the functions defined by the sensor listener API. Please see the [sensor.h](https://github.com/apache/mynewt-core/blob/master/hw/sensor/include/sensor/sensor.h) include file for details.
-
-
-| Function | Description |
-|---------|-------------|
-| sensor_register_listener | Registers the specified listener for a given sensor.|
-| sensor_unregister_listener | Unregisters the specified listener for a given sensor.|
-
-
-
-
diff --git a/docs/os/modules/sensor_framework/sensor_mgr_api.md b/docs/os/modules/sensor_framework/sensor_mgr_api.md
deleted file mode 100644
index 8861fc6..0000000
--- a/docs/os/modules/sensor_framework/sensor_mgr_api.md
+++ /dev/null
@@ -1,51 +0,0 @@
-## Sensor Manager API
-
-The sensor manager API manages the sensors that are enabled in an application. The API allows a sensor device to register itself with the sensor manager and an application to look up the sensors that are enabled. The sensor manager maintains a list of sensors, each represented by a `struct sensor` object defined in the the [Sensor API](/os/modules/sensor_framework/sensor_api.md).
-
-### Registering Sensors
-
-When the BSP or the sensor creator package creates a sensor device in the kernel, via the `os_dev_create()` function, the sensor device init function must initialize a `struct sensor` object and call the `sensor_mgr_register()` function to register itself with the sensor manager.
-
-### Looking Up Sensors
-
-An application uses the sensor manager API to look up the `struct sensor` object for a sensor. The [sensor API](/os/modules/sensor_framework/sensor_api.md) and the [sensor listener API](/os/modules/sensor_framework/sensor_listener_api.md) perform operations on a sensor object. The sensor manager API provides the following sensor lookup functions:
-
-
-* `sensor_mgr_find_next_bytype()`: This function returns the next sensor, on the sensors list, whose configured sensor types match one of the specified sensor types to search for. The sensor types to search are specified as a bit mask. You can use the function to search for the first sensor that matches or to iterate through the list and search for all sensors that match. If you are iterating through the list to find the next match, you must call the `sensor_mgr_lock()` function to lock the sensors list before you start the iteration and call the `sensor_mgr_unlock()` unlock the list when you are done. You do not need to lock the sensor list if you use the function to find the first match because the `sensor_mgr_find_next_bytype()` locks the sensors list before the search.
-
-* `sensor_mgr_find_next_bydevname()`: This function returns the sensor that matches the specified device name.
-
- **Note:** There should only be one sensor that matches a specified device name even though the function name suggests that there can be multiple sensors with the same device name.
-
-
-### Checking Configured Sensor Types
-
-An application may configure a sensor device to only support a subset of supported sensor types. The `sensor_mgr_match_bytype()` function allows an application
-to check whether a sensor is configured for one of the specified sensor types. The type to check is a bit mask and can include multiple types. The function returns a match when there is a match for one, not all, of the specified types in the bit mask.
-
-### Polling Sensors
-
-The sensor manager implements a poller that reads sensor data from sensors at specified poll rates. If an application configures a sensor to be polled, using the `sensor_set_poll_rate_ms()` function defined in the [sensor API](/os/modules/sensor_framework/sensor_api.md), the sensor manager poller will poll and read the configured sensor data from the sensor at the specified interval.
-
-The sensor manager poller uses an OS callout to set up a timer event to poll the sensors, and uses the default OS event queue and the OS main task to process timer events. The `SENSOR_MGR_WAKEUP_RATE` syscfg setting specifies the default wakeup rate the sensor manager poller wakes up to poll sensors. The sensor manager poller uses the poll rate for a sensor if the sensor is configured for a higher poll rate than the `SENSOR_MGR_WAKEUP_RATE` setting value.
-
-**Note:** An application needs to register a [sensor listener](/os/modules/sensor_framework/sensor_listener_api.md) to receive the sensor data that the sensor manager poller reads from a sensor.
-
-
-### Data Structures
-
-The sensor manager API uses the `struct sensor` and `sensor_type_t` types.
-
-
-### List of Functions:
-
-These are the functions defined by the sensor manager API. Please see the [sensor.h](https://github.com/apache/mynewt-core/blob/master/hw/sensor/include/sensor/sensor.h) include file for details.
-
-| Function | Description |
-|---------|-------------|
-|sensor_mgr_find_next_byname| Returns the next sensor from the sensor manager list that matches the specified device name. An application uses this function. <br><br> You must call the sensor_mgr_lock() function to lock the sensor manager list if you are iterating through the sensor manager list.|
-|sensor_mgr_find_next_bytype| Returns the next sensor from the sensor manager list that matches one of the specified sensor types. An application uses this function.<br><br>You must call the sensor_mgr_lock() function to lock the sensor manager list if you are iterating through the sensor manager list.|
-|sensor_mgr_lock| Locks the sensor manager list. An application uses this function. |
-|sensor_mgr_match_bytype| Indicates whether a given sensor is configured for one of the specified sensor types. An application uses this function. Note: The function takes a pointer to a variable with the bit mask of the types to match. |
-|sensor_mgr_register| Registers a sensor object. A sensor device driver uses this function.|
-|sensor_mgr_unlock| Unlocks the sensor manager list. An application uses this function.|
diff --git a/docs/os/modules/sensor_framework/sensor_oic.md b/docs/os/modules/sensor_framework/sensor_oic.md
deleted file mode 100644
index 70e5ee5..0000000
--- a/docs/os/modules/sensor_framework/sensor_oic.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## OIC Sensor Support
-
-The sensor framework provides support for an OIC enabled application to host the sensor devices as OIC resources. The sensor framework provides the following OIC support:
-
-* Creates OIC resources for each sensor device that is enabled in the application. It creates an OIC discoverable and observable resource for each sensor type that the sensor device is configured for.
-* Processes CoAP GET requests for the sensor OIC resources. It reads the sensor data samples, encodes the data, and sends back a response.
-
-The sensor package (`hw/sensor`) defines the following syscfg settings for OIC support:
-
-* `SENSOR_OIC`: This setting specifies whether to enable sensor OIC server support. The setting is enabled by default. The sensor package includes the `net/oic` package for the OIC support when this setting is enabled. The `OC_SERVER` syscfg setting that specifies whether to enable OIC server support in the `net/oic` package must also be enabled.
-* `SENSOR_OIC_OBS_RATE`: Sets the OIC server observation rate.
-
-An application defines an OIC application initialization handler that sets up the OIC resources it supports and calls the `oc_main_init()` function to initialize the OC server. The application must call the `sensor_oic_init()` function from the the OIC application initialization handler. The `sensor_oic_init()` function creates all the OIC resources for the sensors and registers request callbacks to process CoAP GET requests for the sensor OIC resources.
-
-See the [Enabling OIC Sensor Data Monitoring Tutorials](/os/tutorials/sensors/sensor_oic_overview.md) to run and develop sample OIC sensor server applications.
diff --git a/docs/os/modules/sensor_framework/sensor_shell.md b/docs/os/modules/sensor_framework/sensor_shell.md
deleted file mode 100644
index db056ee..0000000
--- a/docs/os/modules/sensor_framework/sensor_shell.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Sensor Shell Command
-
-The sensor framework, `hw/sensor`, package implements a `sensor` shell command. The command allows a user to view the sensors that are enabled in an application and to read the sensor data from the sensors. See the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055.md)
-
-The package defines the `SENSOR_CLI` syscfg setting to specify whether to enable to `sensor` shell command and enables the setting by default.
diff --git a/docs/os/modules/shell/shell.md b/docs/os/modules/shell/shell.md
deleted file mode 100644
index 12a2c04..0000000
--- a/docs/os/modules/shell/shell.md
+++ /dev/null
@@ -1,184 +0,0 @@
-# Shell
-
-The shell runs above the console and provides two functionalities:
-
-* Processes console input. See the [Enabling the Console and Shell tutorial](/os/tutorials/blinky_console.md) for example of the shell.
-* Implements the [newtmgr](../../../newtmgr/overview.md) line protocol over serial transport.
-
-The shell uses the OS default event queue for shell events and runs in the context of the main task. An application can, optionally, specify a dedicated event queue for the shell to use.
-
-The `sys/shell` package implements the shell. To use the shell you must:
-
-* Include the `sys/shell` package.
-* Set the `SHELL_TASK` syscfg setting value to 1 to enable the shell.
-
-**Note:** The functions for the shell API are only compiled and linked with the application when the `SHELL_TASK` setting is enabled. When you develop a package that supports shell commands, we recommend that your pakcage define:
-
-1. A syscfg setting that enables shell command processing for your package, with a restriction that when this setting is enabled, the `SHELL_TASK` setting must also be enabled.
-2. A conditional dependency on the `sys/shell` package when the setting defined in 1 above is enabled.
-
-Here are example definitions from the `syscfg.yml` and `pkg.yml` files for the `sys/log/full` package. It defines the `LOG_CLI` setting to enable the log command in the shell:
-
-```no-highlight
-# sys/log/full syscfg.yml
- LOG_CLI:
- description: 'Expose "log" command in shell.'
- value: 0
- restrictions:
- - SHELL_TASK
-
-# sys/log/full pkg.yml
-pkg.deps.LOG_CLI:
- - sys/shell
-
-```
-
-## Description
-
-### Processing Console Input Commands
-The shell's first job is to direct incoming commands to other subsystems. It parses the incoming character string into tokens and uses the first token to determine the subsystem command handler to call to process the command. When the shell calls the command handler, it passes the other tokens as arguments to the handler.
-
-#### Registering Command Handlers
-
-A package that implements a shell command must register a command handler to process the command.
-
-**New in release 1.1**: The shell supports the concept of modules and allows a package to group shell commands under a name space. To run a command in the shell, you enter the module name and the command name. You can set a default module, using the `select` command, so that you only need to enter the command name to run a command from the default module. You can switch the module you designate as the default module.
-
-There are two methods to register command handlers in Mynewt 1.1:
-
-* Method 1 (New in release 1.1): Define and register a set of commands for a module. This method allows grouping shell commands into namespaces. A package calls the `shell_register()` function to define a module and register the command handlers for the module.
-
- **Note:** The `SHELL_MAX_MODULES` syscfg setting specifies the maximum number of modules that can be registered. You can increase this value if your application and the packages it includes register more than the default value.
-
-* Method 2: Register a command handler without defining a module. A package calls the `shell_cmd_register()` function defined in Mynewt 1.0 to register a command handler. When a shell command is registered using this method, the command is automatically added to the `compat` module. The `compat` module supports backward compatibility for all the shell commands that are registered using the `shell_cmd_register()` function.
-
- **Notes:**
-
- * The `SHELL_COMPAT` syscfg setting must be set to 1 to enable backward compatibility support and the `shell_cmd_register()` function. Since Mynewt packages use method 2 to register shell commands and Mynewt plans to continue this support in future releases, you must keep the default setting value of 1.
-
- * The `SHELL_MAX_COMPAT_COMMANDS` syscfg setting specifies the maximum number of command handlers that can be registered using this method. You can increase this value if your application and the packages it includes register more than the default value.
-
-
-<br>
-####Enabling Help Information for Shell Commands
-
-The shell supports command help. A package that supports command help initializes the `struct shell_cmd` data structure with help text for the command before it registers the command with the shell. The `SHELL_CMD_HELP` syscfg setting enables or disbles help support for all shell commands. The feature is enabled by default.
-
-**Note:** A package that implements help for a shell command should only initialize the help data structures within the `#if MYNEWT_VAL(SHELL_CMD_HELP)` preprocessor directive.
-
-<br>
-
-#### Enabling the OS and Prompt Shell Modules
-The shell implements the `os` and `prompt` modules. These modules support the shell commands to view OS resources.
-
-The `os` module implements commands to list task and mempool usage information and to view and change the time of day. The `SHELL_OS_MODULE` syscfg setting enables or disables the module. The module is enabled by default.
-
-
-The `prompt` module implements the `ticks` command that controls whether to print the current os ticks in the prompt. The `SHELL_PROMPT_MODULE` syscfg setting enables or disables this module. The module is disabled by default.
-
-<br>
-#### Enabling Command Name Completion
-
-The shell supports command name completion. The `SHELL_COMPLETION` syscfg setting enables or disables the feature. The feature is enabled by default.
-
-<br>
-### Processing Newtmgr Line Protocol Over Serial Transport
-
-The shell's second job is to handle packet framing, encoding, and decoding of newtmgr protocol messages that are sent over the console. The Newtmgr serial transport package (`mgmt/newtmgr/transport/newtmgr_shell`) calls the `shell_nlip_input_register()` function to register a handler that the shell calls when it receives newtmgr request messages.
-
-The `SHELL_NEWTMGR` syscfg setting specifies whether newtmgr is enabled over shell. The setting is enabled by default.
-<br>
-
-## Data Structures
-<br>
-The `struct shell_cmd` data structure represents a shell command and is used to register a command.
-
-```no-highlight
-struct shell_cmd {
- const char *sc_cmd;
- shell_cmd_func_t sc_cmd_func;
- const struct shell_cmd_help *help;
-};
-```
-
-| Element | Description |
-|---------|-------------|
-| `sc_cmd` | Character string of the command name. |
-| `sc_cmd_func_t` | Pointer to the command handler that processes the command.|
-| `help` | Pointer to the shell_cmd_help structure. If the pointer is NULL, help information is not provided.|
-
-<br>
-
-The `sc_cmd_func_t` is the command handler function type.
-
-```c
-typedef int (*shell_cmd_func_t)(int argc, char *argv[]);
-```
-
-The `argc` parameter specifies the number of command line arguments and the `argv` parameter is an array of character pointers to the command arguments. The `SHELL_CMD_ARGC_MAX` syscfg setting specifies the maximum number of command line arguments that any shell command can have. This value must be increased if a shell command requires more than `SHELL_CMD_ARGC_MAX` number of command line arguments.
-
-<br>
-
-The `struct shell_module` data structure represents a shell module. It is used to register a shell module and the shell commands for the module.
-
-```c
-struct shell_module {
- const char *name;
- const struct shell_cmd *commands;
-};
-
-```
-
-| Element | Description |
-|---------|-------------|
-| `name` | Character string of the module name.|
-| `commands` | Array of `shell_cmd` structures that specify the commands for the module. The `sc_cmd`, `sc_cmd_func`, and `help` fields in the last entry must be set to NULL to indicate the last entry in the array.|
-
-**Note**: A command handler registered via the `shell_cmd_register()` function is automatically added to the `compat` module.
-
-<br>
-The `struct shell_param` and `struct shell_cmd_help` data structures hold help texts for a shell command.
-
-```c
-struct shell_param {
- const char *param_name;
- const char *help;
-};`
-
-```
-| Element | Description |
-|---------|-------------|
-| `param_name` | Character string of the command parameter name.|
-| `help` | Character string of the help text for the parameter.|
-
-<br>
-```c
-struct shell_cmd_help {
- const char *summary;
- const char *usage;
- const struct shell_param *params;
-};
-```
-
-| Element | Description |
-|---------|-------------|
-| `summary` | Character string of a short description of the command.|
-| `usage` | Character string of a usage description for the command.|
-| `params` | Array of `shell_param` structures that describe each parameter for the command. The last `struct shell_param` in the array must have the `param_name` and `help` fields set to NULL to indicate the last entry in the array. |
-
-<br>
-##List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions available in this OS feature are:
-
-| Function | Description |
-|---------|-------------|
-| [shell_cmd_register](shell_cmd_register.md) | Registers a handler for incoming console commands. |
-| [shell_evq_set](shell_evq_set.md) | Specifies a dedicated event queue for shell events. |
-| [shell_nlip_input_register](shell_nlip_input_register.md) | Registers a handler for incoming newtmgr messages. |
-| [shell_nlip_output](shell_nlip_output.md) | Queue outgoing newtmgr message for transmission. |
-| [shell_register](shell_register.md) |Registers a shell module and the commands for the module. |
-| [shell_register_app_cmd_handler](shell_register_app_cmd_handler.md) |Registers a command handler as an application handler. The shell calls this handler when a command does not have a handler registered.|
-| [shell_register_default_module](shell_register_default_module.md) |Registers a module with a specified name as the default module.|
diff --git a/docs/os/modules/shell/shell_cmd_register.md b/docs/os/modules/shell/shell_cmd_register.md
deleted file mode 100644
index c74fb50..0000000
--- a/docs/os/modules/shell/shell_cmd_register.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> shell_cmd_register </font>
-
-```no-highlight
-int shell_cmd_register(struct shell_cmd *sc)
-```
-
-Registers a handler for incoming shell commands. The function adds the shell command to the `compat` module.
-
-The caller must initialize the `shell_cmd` structure with the command name and the pointer to the command handler. The caller must not free the memory for the command name string because the shell keeps a reference to the memory for internal use.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `sc` | Pointer to the `shell_cmd` structure for the command to register. |
-
-#### Returned values
-
-Returns 0 on success.
-
-Non-zero on failure.
-<br>
-#### Notes
-
-The `SHELL_MAX_COMPAT_COMMANDS` syscfg setting specifies the maximum number of shell commands that the `compat` module supports. This function aborts if the number of handlers registered exceeds this limit. You can increase the value for this setting.
-
-<br>
-#### Example
-
-```no-highlight
-static int fs_ls_cmd(int argc, char **argv);
-
-static struct shell_cmd fs_ls_struct = {
- .sc_cmd = "ls",
- .sc_cmd_func = fs_ls_cmd
-};
-
-void
-fs_cli_init(void)
-{
- shell_cmd_register(&fs_ls_struct);
- ....
-}
-```
diff --git a/docs/os/modules/shell/shell_evq_set.md b/docs/os/modules/shell/shell_evq_set.md
deleted file mode 100644
index b0d9097..0000000
--- a/docs/os/modules/shell/shell_evq_set.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> shell_evq_set</font>
-
-```c
-void shell_evq_set(struct os_eventq *evq)
-```
-
-Specifies an event queue to use for shell events. You must create the event queue
-and the task to process events from the queue before calling this function.
-
-By default, shell uses the OS default event queue and executes in the context
-of the main task that Mynewt creates.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `evq` | Pointer to the event queue to use for shell events.|
-
-#### Returned values
-None
-
-#### Notes
-
diff --git a/docs/os/modules/shell/shell_nlip_input_register.md b/docs/os/modules/shell/shell_nlip_input_register.md
deleted file mode 100644
index bad5074..0000000
--- a/docs/os/modules/shell/shell_nlip_input_register.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> shell_nlip_input_register </font>
-
-```no-highlight
-int shell_nlip_input_register(shell_nlip_input_func_t nf, void *arg)
-```
-
-Registers a handler for incoming newtmgr messages. The shell receives the incoming data stream from the UART, and when it detects a NLIP frame, decodes the datagram, and calls the registered handler,`nf`.
-
-The handler function is of type `int (*shell_nlip_input_func_t)(struct os_mbuf *m, void *arg)`.
-The shell passes the incoming newtmgr message stored in a `os_mbuf` and the `arg` that was passed to the `shell_nlip_input_register()` function as arguments to the handler function.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `nf` | Handler for incoming newtmgr datagrams. |
-| `arg` | Argument that is passed to this handler, along with the datagram.|
-
-#### Returned values
-
-Returns 0 on success.
-
-Non-zero on failure.
-
-#### Example
-
-```no-highlight
-static int
-nmgr_shell_in(struct os_mbuf *m, void *arg)
-{
- ....
-}
-
-int
-nmgr_task_init(uint8_t prio, os_stack_t *stack_ptr, uint16_t stack_len)
-{
- int rc;
- ....
- rc = shell_nlip_input_register(nmgr_shell_in,
- (void *) &g_nmgr_shell_transport);
- if (rc != 0) {
- goto err;
- }
- ....
-}
-```
diff --git a/docs/os/modules/shell/shell_nlip_output.md b/docs/os/modules/shell/shell_nlip_output.md
deleted file mode 100644
index 2ad811e..0000000
--- a/docs/os/modules/shell/shell_nlip_output.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> shell_nlip_output </font>
-
-```no-highlight
-int shell_nlip_output(struct os_mbuf *m)
-```
-
-Queues the outgoing newtmgr message for transmission. The shell encodes the message, frames the message into packets, and writes each packet to the console.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| m | os_mbuf containing the message |
-
-#### Returned values
-
-Returns 0 on success.
-
-Non-zero on failure.
-
-#### Example
-
-```no-highlight
-static int
-nmgr_shell_out(struct nmgr_transport *nt, struct os_mbuf *m)
-{
- int rc;
-
- rc = shell_nlip_output(m);
- if (rc != 0) {
- goto err;
- }
-
- return (0);
-err:
- return (rc);
-}
-```
diff --git a/docs/os/modules/shell/shell_register.md b/docs/os/modules/shell/shell_register.md
deleted file mode 100644
index 1ee9d83..0000000
--- a/docs/os/modules/shell/shell_register.md
+++ /dev/null
@@ -1,96 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> shell_register </font>
-
-```c
-shell_register(const char *module_name, const struct shell_cmd *commands)
-```
-
-Registers a module named `module_name` and the commands that the module supports. The caller must allocate and not free the memory for the `module_name` and the array of `shell_cmd` structures for the command. The shell keeps references to these structures for internal use.
-
-Each entry in the `commands` array specifies a shell command for the module and must be initialized with the command name and the pointer to the command handler. The help field is initialized with help information if the command supports help.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `module_name` | Character string of the module name. |
-| `commands` | Array of `shell_cmd` structures that specify the commands for the module. The `sc_cmd`, `sc_cmd_func`, and `help` fields in the last entry must be set to NULL to indicate the last entry in the array.|
-
-#### Returned values
-
-Returns 0 on success.
-
-Non-zero on failure.
-<br>
-#### Notes
-The `SHELL_MAX_MODULES` syscfg setting specifies the maximum number of modules the shell supports. This function aborts if the number of registered modules exceeds this limit. You can increase the value for this setting.
-<br>
-#### Example
-This is an example excerpt that shows how to declare and initialize the data structures for a module and some shell commands for the. Variables for the help structures are only declared and intialized if the `SHELL_CMD_HELP` syscfg setting is enabled. The `sample_commands` array of `shell_cmd` structures are declared and initialized. The fields in the last entry are all set to NULL to indicate the last entry in the array.
-
-```c
-static int shell_sample_tasks_display_cmd(int argc, char **argv);
-static int shell_sample_mpool_display_cmd(int argc, char **argv);
-
-static const char *sample_module = "sample_module";
-
-/*
- * Initialize param and command help information if SHELL_CMD_HELP
- * is enabled.
- */
-
-#if MYNEWT_VAL(SHELL_CMD_HELP)
-static const struct shell_param sample_tasks_params[] = {
- {"", "task name"},
- {NULL, NULL}
-};
-
-static const struct shell_cmd_help sample_tasks_help = {
- .summary = "show tasks info",
- .usage = NULL,
- .params = sample_tasks_params,
-};
-
-static const struct shell_param sample_mpool_params[] = {
- {"", "mpool name"},
- {NULL, NULL}
-};
-
-static const struct shell_cmd_help sample_mpool_help = {
- .summary = "show system mpool",
- .usage = NULL,
- .params = sample_mpool_params,
-};
-
-#endif
-
-/*
- * Initialize an array of shell_cmd structures for the commands
- * in the os module.
- */
-static const struct shell_cmd sample_module_commands[] = {
- {
- .sc_cmd = "tasks",
- .sc_cmd_func = shell_sample_tasks_display_cmd,
-#if MYNEWT_VAL(SHELL_CMD_HELP)
- .help = &sample_tasks_help,
-#endif
- },
- {
- .sc_cmd = "sample_mpool",
- .sc_cmd_func = shell_sample_mpool_display_cmd,
-#if MYNEWT_VAL(SHELL_CMD_HELP)
- .help = &sample_mpool_help,
-#endif
- },
- { NULL, NULL, NULL },
-};
-
-
-void
-sample_module_init(void)
-{
- shell_register(sample_module, sample_module_commands);
-
-}
-```
diff --git a/docs/os/modules/shell/shell_register_app_cmd_handler.md b/docs/os/modules/shell/shell_register_app_cmd_handler.md
deleted file mode 100644
index 9272c2a..0000000
--- a/docs/os/modules/shell/shell_register_app_cmd_handler.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## <font color="#F2853F" style="font-size:24pt"> shell_register_app_cmd_handler </font>
-
-```c
-void shell_register_app_cmd_handler(struct shell_cmd *sc)
-```
-Registers a command handler as an application command handler. The shell calls the application command handler, if one is set, when it receives a command that does not have a handler registered. When you implement a shell command for your application, you can register an application command handler. You do not need to define a command name for the shell to use to lookup an application command handler.
-
-For example, if your application uses the `shell_cmd_register()` function to register a handler for the `myapp_cmd` shell command and the handler supports two subcommands, `subcmd1` and ``subcmd2`, then you would enter `myapp_cmd subcmd1` and `myapp_cmd subcmd2` in the shell to run the commands. If you register the handler as an application command handler, then you would enter `subcmd1` and `subcmd2` in the shell to run the commands.
-<br>
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `sc` | Pointer to the `shell_cmd` structure for the comman to register. |
-
-#### Returned values
-None
-
-#### Example
-
-```c
-
-static int myapp_cmd_handler(int argc, char **argv);
-
-static struct shell_cmd myapp_cmd = {
- .sc_cmd = "",
- .sc_cmd_func = myapp_cmd_handler
-};
-
-void
-myapp_shell_init(void)
-{
- shell_register_app_cmd_handler(&myapp_cmd);
- ....
-}
-```
diff --git a/docs/os/modules/shell/shell_register_default_module.md b/docs/os/modules/shell/shell_register_default_module.md
deleted file mode 100644
index c4c383e..0000000
--- a/docs/os/modules/shell/shell_register_default_module.md
+++ /dev/null
@@ -1,44 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> shell_register_default_module</font>
-
-```c
-void shell_register_default_module(const char *name)
-```
-
-Sets the module named `name` as the default module. You can enter the commands for the default module without entering the module name in the shell.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| `name` | Name of the module to set as the default |
-
-#### Returned values
-None
-<br>
-
-#### Example
-```c
-static int sample_cmd_handler(int argc, char **argv);
-
-static const char * module_name = "sample_module";
-static const struct shell_cmd sample_cmds[] = {
- {
- .sc_cmd = "mycmd",
- .sc_cmd_func = sample_cmd_handler,
- },
- {NULL, NULL, NULL},
-};
-
-int main (void)
-{
-
-
- /* Register the module and the commands for the module */
- shell_register(module_name, sample_cmds);
-
- /* Set this module as the default module */
- shell_register_default_module(module_name);
-
-}
-```
diff --git a/docs/os/modules/split/split.md b/docs/os/modules/split/split.md
deleted file mode 100644
index c79a1d5..0000000
--- a/docs/os/modules/split/split.md
+++ /dev/null
@@ -1,428 +0,0 @@
-# Split Images
-
-## Description
-
-The split image mechanism divides a target into two separate images: one
-capable of image upgrade; the other containing application code. By isolating
-upgrade functionality to a separate image, the application can support
-over-the-air upgrade without dedicating flash space to network stack and
-management code.
-
-## Concept
-
-Mynewt supports three image setups:
-
-| Setup | Description |
-|-----------|-------------|
-| Single | One large image; upgrade not supported. |
-| Unified | Two standalone images. |
-| Split | Kernel in slot 0; application in slot 1. |
-
-Each setup has its tradeoffs. The Single setup gives you the most flash space,
-but doesn't allow you to upgrade after manufacturing. The Unified setup allows
-for a complete failover in case a bad image gets uploaded, but requires a lot
-of redundancy in each image, limiting the amount of flash available to the
-application. The Split setup sits somewhere between these two options.
-
-Before exploring the split setup in more detail, it might be helpful to get a
-basic understanding of the Mynewt boot sequence. The boot process is
-summarized below.
-
-#### Boot Sequence - Single
-
-In the Single setup, there is no boot loader. Instead, the image is placed at
-address 0. The hardware boots directly into the image code. Upgrade is not
-possible because there is no boot loader to move an alternate image into place.
-
-#### Boot Sequence - Unified
-
-In the Unified setup, the boot loader is placed at address 0. At startup, the
-boot loader arranges for the correct image to be in image slot 0, which may
-entail swapping the contents of the two image slots. Finally, the boot loader
-jumps to the image in slot 0.
-
-#### Boot Sequence - Split
-
-The Split setup differs from the other setups mainly in that a target is not
-fully contained in a single image. Rather, the target is partitioned among two
-separate images: the _loader_, and the _application_. Functionality is divided
-among these two images as follows:
-
-1. Loader:
- * Mynewt OS.
- * Network stack for connectivity during upgrade e.g. BLE stack.
- * Anything else required for image upgrade.
-
-2. Application:
- * Parts of Mynewt not required for image upgrade.
- * Application-specific code.
-
-The loader image serves three purposes:
-
-1. *Second-stage boot loader:* it jumps into the application image at
- start up.
-2. *Image upgrade server:* the user can upgrade to a new loader + application
- combo, even if an application image is not currently running.
-3. *Functionality container:* the application image can directly access all the
- code present in the loader image
-
-From the perspective of the boot loader, a loader image is identical to a plain
-unified image. What makes a loader image different is a change to its start up
-sequence: rather than starting the Mynewt OS, it jumps to the application image
-in slot 1 if one is present.
-
-## Tutorial
-
-### Building a Split Image
-
-We will be referring to the nRF51dk for examples in this document. Let's take
-a look at this board's flash map (defined in `hw/bsp/nrf51dk/bsp.yml`):
-
-| Name | Offset | Size (kB) |
-|-----------------------|---------------|-----------|
-| Boot loader | 0x00000000 | 16 |
-| Reboot log | 0x00004000 | 16 |
-| Image slot 0 | 0x00008000 | 110 |
-| Image slot 1 | 0x00023800 | 110 |
-| Image scratch | 0x0003f000 | 2 |
-| Flash file system | 0x0003f800 | 2 |
-
-The application we will be building is [bleprph](../../tutorials/bleprph).
-First, we create a target to tie our BSP and application together.
-
-```
-newt target create bleprph-nrf51dk
-newt target set bleprph-nrf51dk \
- app=@apache-mynewt-core/apps/bleprph \
- bsp=@apache-mynewt-core/hw/bsp/nrf51dk \
- build_profile=optimized \
- syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0
-```
-The two syscfg settings disable bluetooth security and keep the code size down.
-
-We can verify the target using the `target show` command:
-
-```
-[~/tmp/myproj2]$ newt target show bleprph-nrf51dk
-targets/bleprph-nrf51dk
- app=@apache-mynewt-core/apps/bleprph
- bsp=@apache-mynewt-core/hw/bsp/nrf51dk
- build_profile=optimized
- syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0
-```
-
-Next, build the target:
-
-```
-[~/tmp/myproj2]$ newt build bleprph-nrf51dk
-Building target targets/bleprph-nrf51dk
-# [...]
-Target successfully built: targets/bleprph-nrf51dk
-```
-
-With our target built, we can view a code size breakdown using the `newt size <target>` command. In the interest of brevity, the smaller entries are excluded from the below output:
-
-```
-[~/tmp/myproj2]$ newt size bleprph-nrf51dk
-Size of Application Image: app
- FLASH RAM
- 2446 1533 apps_bleprph.a
- 1430 104 boot_bootutil.a
- 1232 0 crypto_mbedtls.a
- 1107 0 encoding_cborattr.a
- 2390 0 encoding_tinycbor.a
- 1764 0 fs_fcb.a
- 2959 697 hw_drivers_nimble_nrf51.a
- 4126 108 hw_mcu_nordic_nrf51xxx.a
- 8161 4049 kernel_os.a
- 2254 38 libc_baselibc.a
- 2612 0 libgcc.a
- 2232 24 mgmt_imgmgr.a
- 1499 44 mgmt_newtmgr_nmgr_os.a
- 23918 1930 net_nimble_controller.a
- 28537 2779 net_nimble_host.a
- 2207 205 sys_config.a
- 1074 197 sys_console_full.a
- 3268 97 sys_log.a
- 1296 0 time_datetime.a
-
-objsize
- text data bss dec hex filename
- 105592 1176 13392 120160 1d560 /home/me/tmp/myproj2/bin/targets/bleprph-nrf51dk/app/apps/bleprph/bleprph.elf
-
-```
-
-The full image text size is about 103kB (where 1kB = 1024 bytes). With an image slot size of 110kB,
-this leaves only about 7kB of flash for additional application code and data.
-Not good. This is the situation we would be facing if we were using the
-Unified setup.
-
-The Split setup can go a long way in solving our problem. Our unified bleprph
-image consists mostly of components that get used during an image upgrade. By
-using the Split setup, we turn the unified image into two separate images: the
-loader and the application. The functionality related to image upgrade can be
-delegated to the loader image, freeing up a significant amount of flash in the
-application image slot.
-
-Let's create a new target to use with the Split setup. We designate a target
-as a split target by setting the `loader` variable. In our example, we are
-going to use `bleprph` as the loader, and `splitty` as the application.
-`bleprph` makes sense as a loader because it contains the BLE stack and
-everything else required for an image upgrade.
-
-```
-newt target create split-nrf51dk
-newt target set split-nrf51dk \
- loader=@apache-mynewt-core/apps/bleprph \
- app=@apache-mynewt-core/apps/splitty \
- bsp=@apache-mynewt-core/hw/bsp/nrf51dk \
- build_profile=optimized \
- syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0
-```
-
-Verify that the target looks correct:
-
-```
-[~/tmp/myproj2]$ newt target show split-nrf51dk
-targets/split-nrf51dk
- app=@apache-mynewt-core/apps/splitty
- bsp=@apache-mynewt-core/hw/bsp/nrf51dk
- build_profile=optimized
- loader=@apache-mynewt-core/apps/bleprph
- syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_SM_LEGACY=0
-```
-
-Now, let's build the new target:
-
-```
-[~/tmp/myproj2]$ newt build split-nrf51dk
-Building target targets/split-nrf51dk
-# [...]
-Target successfully built: targets/split-nrf51dk
-```
-
-And look at the size breakdown (again, smaller entries are removed):
-
-```
-[~/tmp/myproj2]$ newt size split-nrf51dk
-Size of Application Image: app
- FLASH RAM
- 3064 251 sys_shell.a
-
-objsize
- text data bss dec hex filename
- 4680 112 17572 22364 575c /home/me/tmp/myproj2/bin/targets/split-nrf51dk/app/apps/splitty/splitty.elf
-
-Size of Loader Image: loader
- FLASH RAM
- 2446 1533 apps_bleprph.a
- 1430 104 boot_bootutil.a
- 1232 0 crypto_mbedtls.a
- 1107 0 encoding_cborattr.a
- 2390 0 encoding_tinycbor.a
- 1764 0 fs_fcb.a
- 3168 705 hw_drivers_nimble_nrf51.a
- 4318 109 hw_mcu_nordic_nrf51xxx.a
- 8285 4049 kernel_os.a
- 2274 38 libc_baselibc.a
- 2612 0 libgcc.a
- 2232 24 mgmt_imgmgr.a
- 1491 44 mgmt_newtmgr_nmgr_os.a
- 25169 1946 net_nimble_controller.a
- 31397 2827 net_nimble_host.a
- 2259 205 sys_config.a
- 1318 202 sys_console_full.a
- 3424 97 sys_log.a
- 1053 60 sys_stats.a
- 1296 0 time_datetime.a
-
-objsize
- text data bss dec hex filename
- 112020 1180 13460 126660 1eec4 /home/me/tmp/myproj2/bin/targets/split-nrf51dk/loader/apps/bleprph/bleprph.elf
-```
-
-The size command shows two sets of output: one for the application, and another
-for the loader. The addition of the split functionality did make bleprph
-slightly bigger, but notice how small the application is: 4.5 kB! Where before
-we only had 7 kB left, now we have 105.5 kB. Furthermore, all the
-functionality in the loader is available to the application at any time. For
-example, if your application needs bluetooth functionality, it can use the BLE
-stack present in the loader instead of containing its own copy.
-
-Finally, let's deploy the split image to our nRF51dk board. The procedure here
-is the same as if we were using the Unified setup, i.e., via either the `newt load` or `newt run` command.
-
-```
-[~/repos/mynewt/core]$ newt load split-nrf51dk 0
-Loading app image into slot 2
-Loading loader image into slot 1
-```
-
-### Image Management
-
-#### Retrieve Current State (image list)
-
-Image management in the split setup is a bit more complicated than in the
-unified setup. You can determine a device's image management state with the
-`newtmgr image list` command. Here is how a device responds to this command
-after our loader + application combo has been deployed:
-
-```
-[~/tmp/myproj2]$ newtmgr -c A600ANJ1 image list
-Images:
- slot=0
- version: 0.0.0
- bootable: true
- flags: active confirmed
- hash: 948f118966f7989628f8f3be28840fd23a200fc219bb72acdfe9096f06c4b39b
- slot=1
- version: 0.0.0
- bootable: false
- flags:
- hash: 78e4d263eeb5af5635705b7cae026cc184f14aa6c6c59c6e80616035cd2efc8f
-Split status: matching
-```
-
-There are several interesting things about this response:
-
-1. *Two images:* This is expected; we deployed both a loader image and an
-application image.
-2. *bootable flag:* Notice slot 0's bootable flag is set, while slot 1's is
-not. This tells us that slot 0 contains a loader and slot 1 contains an
-application. If an image is bootable, it can be booted directly from the boot
-loader. Non-bootable images can only be started from a loader image.
-3. *flags:* Slot 0 is `active` and `confirmed`; none of slot 1's flags are set.
-The `active` flag indicates that the image is currently running; the
-`confirmed` flag indicates that the image will continue to be used on
-subsequent reboots. Slot 1's lack of enabled flags indicates that the image is
-not being used at all.
-4. *Split status:* The split status field tells you if the loader and
-application are compatible. A loader + application combo is compatible only if
-both images were built at the same time with `newt`. If the loader and
-application are not compatible, the loader will not boot into the application.
-
-### Enabling a Split Application
-
-By default, the application image in slot 1 is disabled. This is indicated in
-the `image list` response above. When you deploy a loader / application combo
-to your device, the application image won't actually run. Instead, the loader
-will act as though an application image is not present and remain in "loader
-mode". Typically, a device in loader mode simply acts as an image management
-server, listening for an image upgrade or a request to activate the application
-image.
-
-Use the following command sequence to enable the split application image:
-
-1. Tell device to "test out" the application image on next boot (`newtmgr image test <application-image-hash>`).
-2. Reboot device (`newtmgr reset`).
-3. Make above change permanent (`newtmgr image confirm`).
-
-After the above sequence, a `newtmgr image list` command elicits the following response:
-
-```
-[~/tmp/myproj2]$ newtmgr -c A600ANJ1 image confirm
-Images:
- slot=0
- version: 0.0.0
- bootable: true
- flags: active confirmed
- hash: 948f118966f7989628f8f3be28840fd23a200fc219bb72acdfe9096f06c4b39b
- slot=1
- version: 0.0.0
- bootable: false
- flags: active confirmed
- hash: 78e4d263eeb5af5635705b7cae026cc184f14aa6c6c59c6e80616035cd2efc8f
-Split status: matching
-```
-
-The `active confirmed` flags value on both slots indicates that both images are
-permanently running.
-
-### Image Upgrade
-
-First, let's review of the image upgrade process for the Unified setup. The
-user upgrades to a new image in this setup with the following steps:
-
-#### Image Upgrade - Unified
-
-1. Upload new image to slot 1 (`newtmgr image upload <filename>`).
-2. Tell device to "test out" the new image on next boot (`newtmgr image test <image-hash>`).
-3. Reboot device (`newtmgr reset`).
-4. Make new image permanent (`newtmgr image confirm`).
-
-#### Image Upgrade - Split
-
-The image upgrade process is a bit more complicated in the Split setup. It is
-more complicated because two images need to be upgraded (loader and
-application) rather than just one. The split upgrade process is described
-below:
-
-1. Disable split functionality; we need to deactivate the application image in
- slot 1 (`newtmgr image test <current-loader-hash>`).
-2. Reboot device (`newtmgr reset`).
-3. Make above change permanent (`newtmgr image confirm`).
-4. Upload new loader to slot 1 (`newtmgr image upload <filename>`).
-5. Tell device to "test out" the new loader on next boot (`newtmgr image test <new-loader-hash>`).
-6. Reboot device (`newtmgr reset`).
-7. Make above change of loader permanent (`newtmgr image confirm`).
-8. Upload new application to slot 1 (`newtmgr image upload <filename>`).
-9. Tell device to "test out" the new application on next boot (`newtmgr image test <new-application-hash>`).
-10. Reboot device (`newtmgr reset`).
-11. Make above change of application permanent (`newtmgr image confirm`).
-
-When performing this process manually, it may be helpful to use `image list` to
-check the image management state as you go.
-
-## Syscfg
-
-Syscfg is Mynewt's system-wide configuration mechanism. In a split setup,
-there is a single umbrella syscfg configuration that applies to both the loader
-and the application. Consequently, overriding a value in an application-only
-package potentially affects the loader (and vice-versa).
-
-## Loaders
-
-The following applications have been enabled as loaders. You may choose to
-build your own loader application, and these can serve as samples.
-
-* @apache-mynewt-core/apps/slinky
-* @apache-mynewt-core/apps/bleprph
-
-## Split Apps
-
-The following applications have been enabled as split applications. If you
-choose to build your own split application these can serve as samples. Note
-that slinky can be either a loader image or an application image.
-
-* @apache-mynewt-core/apps/slinky
-* @apache-mynewt-core/apps/splitty
-
-## Theory of Operation
-
-A split image is built as follows:
-
-First newt builds the application and loader images separately to ensure they
-are consistent (no errors) and to generate elf files which can inform newt of
-the symbols used by each part.
-
-Then newt collects the symbols used by both application and loader in two ways.
-It collects the set of symbols from the `.elf` files. It also collects all the
-possible symbols from the `.a` files for each application.
-
-Newt builds the set of packages that the two applications share. It ensures
-that all the symbols used in those packages are matching. NOTE: because of
-features and #ifdefs, its possible for the two package to have symbols that are
-not the same. In this case newt generates an error and will not build a split
-image.
-
-Then newt creates the list of symbols that the two applications share from
-those packages (using the .elf files).
-
-Newt re-links the loader to ensure all of these symbols are present in the
-loader application (by forcing the linker to include them in the `.elf`).
-
-Newt builds a special copy of the loader.elf with only these symbols (and the
-handful of symbols discussed in the linking section above).
-
-Finally, newt links the application, replacing the common .a libraries with the
-special loader.elf image during the link.
diff --git a/docs/os/modules/stats/stats.md b/docs/os/modules/stats/stats.md
deleted file mode 100644
index a3a4bbc..0000000
--- a/docs/os/modules/stats/stats.md
+++ /dev/null
@@ -1,298 +0,0 @@
-
-# Statistics Module
-
-The statistics module allows application, libraries, or drivers to
-record statistics that can be shown via the Newtmgr tool and console.
-
-This allows easy integration of statistics for troubleshooting,
-maintenance, and usage monitoring.
-
-By creating and registering your statistics, they are automatically
-included in the Newtmgr shell and console APIs.
-
-### Implementation Details
-
-A statistic is an unsigned integer that can be set by the
-code. When building stats, the implementer chooses the size of the
-statistic depending on the frequency of the statistic and the
-resolution required before the counter wraps.
-
-Typically the stats are incremented upon code events; however, they are
-not limted to that purpose.
-
-Stats are organized into sections. Each section of stats has its own
-name and can be queried separately through the API. Each section of stats
-also has its own statistic size, allowing the user to separate large (64-bit)
-statistics from small (16 bit statistics). NOTE: It is not currently possible
-to group different size stats into the same section. Please ensure all stats
-in a section have the same size.
-
-Stats sections are currently stored in a single global stats group.
-
-Statistics are stored in a simple structure which contains a small
-stats header followed by a list of stats. The stats header contains:
-
-```no-highlight
-struct stats_hdr {
- char *s_name;
- uint8_t s_size;
- uint8_t s_cnt;
- uint16_t s_pad1;
-#if MYNEWT_VAL(STATS_NAMES)
- const struct stats_name_map *s_map;
- int s_map_cnt;
-#endif
- STAILQ_ENTRY(stats_hdr) s_next;
- };
-```
-
-The fields define with in the `#if MYNEWT_VAL(STATS_NAME)` directive are only inincluded when the `STATS_NAMES` syscfg setting is set to 1 and enables use statistic names.
-<br>
-
-#### Enabling Statistic Names
-
-By default, statistics are queried by number. You can use the `STATS_NAMES` syscfg setting to enable statistic names and view the results by name. Enabling statistic names provides better descriptions in the reported statistics, but takes code space to store the strings within the image.
-
-To enable statistic names, set the `STATS_NAMES` value to 1 in the application `syscfg.yml` file or use the `newt target set` command to set the syscfg setting value. Here are examples for each method:
-
-Method 1 - Set the value in the application `syscfg.yml` files:
-<br>
-```no-highlight
-
-# Package: apps/myapp
-
-syscfg.vals:
- STATS_NAMES: 1
-
-```
-<br>
-
-
-Method 2 - Set the target `syscfg` variable:
-
-```no-highlight
-
-newt target set myapp syscfg=STATS_NAMES=1
-
-```
-
-**Note:** This `newt target set` command only sets the syscfg variable for the `STATS_NAMES` setting as an example. For your target, you should set the syscfg variable with the other settings that you want to override.
-
-<br>
-
-### Adding Stats to your code.
-
-Creating new stats table requires the following steps.
-
-* Include the stats header file
-* Define a stats section
-* Declare an instance of the section
-* Define the stat sections names table
-* Implement stat in your code
-* Initialize the stats
-* Register the stats
-
-<br>
-
-#### Include the stats header file
-
-Add the stats library to your pkg.yml file for your package or app by adding
-this line to your package dependencies.
-
-```
-pkg.deps:
- - "@apache-mynewt-core/sys/stats"
-```
-
-<br>
-
-Add this include directive to code files using the stats library.
-
-```
-#include <stats/stats.h>
-```
-
-<br>
-
-#### Define a stats section
-
-You must use the `stats.h` macros to define your stats table. A
-stats section definition looks like this.
-
-```
-STATS_SECT_START(my_stat_section)
- STATS_SECT_ENTRY(attempt_stat)
- STATS_SECT_ENTRY(error_stat)
-STATS_SECT_END
-```
-
-<br>
-
-In this case we chose to make the stats 32-bits each. `stats.h` supports three
-different stats sizes through the following macros:
-
-* `STATS_SIZE_16` -- stats are 16 bits (wraps at 65536)
-* `STATS_SIZE_32` -- stats are 32 bits (wraps at 4294967296)
-* `STATS_SIZE_64` -- stats are 64-bits
-
-When this compiles/pre-processes, it produces a structure definition like this
-
-```
-struct stats_my_stat_section {
- struct stats_hdr s_hdr;
- uint32_t sattempt_stat;
- uint32_t serror_stat;
-};
-```
-
-<br>
-
-You can see that the defined structure has a small stats structure
-header and the two stats we have defined.
-
-Depending on whether these stats are used in multiple modules, you may need
-to include this definition in a header file.
-
-<br>
-
-#### Declaring a variable to hold the stats
-
-Declare the global variable to hold your statistics. Since it is possible to
-have multiple copies of the same section (for example a stat section for
-each of 5 identical peripherals), the variable name of the stats section
-must be unique.
-
-```
-STATS_SECT_DECL(my_stat_section) g_mystat;
-```
-
-<br>
-
-Again, if your stats section is used in multiple C files you will need to
-include the above definition in one of the C files and 'extern' this declaration
-in your header file.
-
-```
-extern STATS_SECT_DECL(my_stat_section) g_mystat;
-```
-
-<br>
-
-#### Define the stats section name table
-
-Whether or not you have `STATS_NAMES` enabled, you must define
-a stats name table. If `STATS_NAMES` is not enabled, this will
-not take any code space or image size.
-
-```
-/* define a few stats for querying */
-STATS_NAME_START(my_stat_section)
- STATS_NAME(my_stat_section, attempt_stat)
- STATS_NAME(my_stat_section, error_stat)
-STATS_NAME_END(my_stat_section)
-```
-
-<br>
-
-When compiled by the preprocessor, it creates a structure that looks like this.
-
-```
-struct stats_name_map g_stats_map_my_stat_section[] = {
- { __builtin_offsetof (struct stats_my_stat_section, sattempt_stat), "attempt_stat" },
- { __builtin_offsetof (struct stats_my_stat_section, serror_stat), "error_stat" },
-};
-```
-
-<br>
-
-This table will allow the UI components to find a nice string name for the
-stat.
-
-<br>
-
-#### Implement stats in your code.
-
-You can use the `STATS_INC` or `STATS_INCN` macros to increment your statistics
-within your C-code. For example, your code may do this:
-
-```
- STATS_INC(g_mystat, attempt_stat);
- rc = do_task();
- if(rc == ERR) {
- STATS_INC(g_mystat, error_stat);
- }
-```
-
-<br>
-
-#### Initialize the statistics
-
-You must initialize the stats so they can be operated on by the stats
-library. As per our example above, it would look like the following.
-
-This tells the system how large each statistic is and the number of
-statistics in the section. It also initialize the name information for
-the statistics if enabled as shown above.
-
-```
- rc = stats_init(
- STATS_HDR(g_mystat),
- STATS_SIZE_INIT_PARMS(g_mystat, STATS_SIZE_32),
- STATS_NAME_INIT_PARMS(my_stat_section));
- assert(rc == 0);
-```
-
-<br>
-
-#### Register the statistic section
-
-If you want the system to know about your stats, you must register them.
-
-```
- rc = stats_register("my_stats", STATS_HDR(g_mystat));
- assert(rc == 0);
-```
-
-<br>
-
-There is also a method that does initialization and registration at the
-same time, called `stats_init_and_reg`.
-
-<br>
-
-### Retrieving stats through console or Newtmgr
-
-If you enable console in your project you can see stats through the
-serial port defined.
-
-This is the stats as shown from the example above with names enabled.
-```
-stat my_stats
-12274:attempt_stat: 3
-12275:error_stat: 0
-```
-
-<br>
-
-This is the stats as shown from the example without names enabled.
-```
-stat my_stats
-29149:s0: 3
-29150:s1: 0
-```
-
-<br>
-
-### A note on multiple stats sections
-
-If you are implementing a device with multiple instances, you may
-want multiple stats sections with the exact same format.
-
-For example, suppose I write a driver for an external distance sensor. My
-driver supports up to 5 sensors and I want to record the stats of
-each device separately.
-
-This works identically to the example above, except you would need to
-register each one separately with a unique name. The stats system will
-not let two sections be entered with the same name.
-
diff --git a/docs/os/modules/sysinitconfig/sysconfig_error.md b/docs/os/modules/sysinitconfig/sysconfig_error.md
deleted file mode 100644
index 4ea9b02..0000000
--- a/docs/os/modules/sysinitconfig/sysconfig_error.md
+++ /dev/null
@@ -1,430 +0,0 @@
-## Validation and Error Messages
-
-With multiple packages defining and overriding system configuration settings, it
-is easy to introduce conflicts and violations that are difficult to find. The
-`newt build <target-name>` command validates the setting definitions and value
-overrides for all the packages in the target to ensure a valid and consistent build.
-It aborts the build when it detects violations or ambiguities between packages.
-The following sections describe the error conditions that newt detects and
-the error messages that it outputs. For most errors, newt also outputs
-the `Setting history` with the order of package overrides to help
-you resolve the errors.
-
-**Note:** The `newt target config <target-name>` command also detects
-errors and outputs error messages at the top of the command output.
-The command outputs the package setting definitions and values after it
-outputs the error messages. It is easy to miss the error messages at the top.
-
-
-### Value Override Violations
-
-The newt tool uses package priorities to resolve override conflicts. It uses
-the value override from the highest priority package when multiple
-packages override the same setting. Newt checks for the following
-override violations:
-
-* Ambiguity Violation - Two packages of the same priority override a setting with
-different values. And no higher priority package overrides the setting.
-* Priority Violation - A package overrides a setting defined by a package with higher or
-equal priority.
-
- **Note:** A package may override the default value for a setting that it defines. For example, a package defines a setting with a default value but needs to conditionally override the value based on another setting value.
-
-<br>
-####Example: Ambiguity Violation Error Message
-
-The following example shows the error message that newt outputs for an ambiguity violation:
-
-```no-highlight
-
-Error: Syscfg ambiguities detected:
- Setting: LOG_NEWTMGR, Packages: [apps/slinky, apps/splitty]
-Setting history (newest -> oldest):
- LOG_NEWTMGR: [apps/splitty:0, apps/slinky:1, sys/log/full:0]
-
-```
-
-The above error occurs because the `apps/slinky` and `apps/splitty` packages
-in the split image target both override the same setting with different
-values. The `apps/slinky` package sets the `sys/log/full` package `LOG_NEWTMGR`
-setting to 1, and the `apps/splitty` package sets the setting to 0. The
-overrides are ambiguous because both are `app` packages and
-have the same priority. The following are excerpts of the defintion
-and the two overrides from the `syscfg.yml` files that cause the error:
-
-
-```no-highlight
-
-#Package: sys/log/full
-syscfg.defs:
- LOG_NEWTMGR:
- description: 'Enables or disables newtmgr command tool logging'
- value: 0
-
-#Package: apps/slinky
-syscfg.vals:
- LOG_NEWTMGR: 1
-
-#Package: apps/splitty
-syscfg.vals:
- LOG_NEWTMGR: 0
-
-```
-
-#### Example: Priority Violation Error Message
-
-The following example shows the error message that newt outputs for a priority violation
-where a package tries to change the setting that was defined by another package at
-the same priority level:
-
-```no-highlight
-
-Error: Priority violations detected (Packages can only override settings defined by packages of lower priority):
- Package: mgmt/newtmgr overriding setting: LOG_NEWTMGR defined by sys/log/full
-
-Setting history (newest -> oldest):
- LOG_NEWTMGR: [sys/log/full:0]
-
-```
-
-The above error occurs because the `mgmt/newtmgr` lib package
-overrides the `LOG_NEWTMGR` setting that the `sys/log/full` lib package
-defines. The following are excerpts of the definition and the override from the
-`syscfg.yml` files that cause this error:
-
-```no-highlight
-
-#Package: sys/log/full
-syscfg.defs:
- LOG_NEWTMGR:
- description: 'Enables or disables newtmgr command tool logging'
- value: 0
-
-#Package: mgmt/newtmgr
-syscfg.vals:
- LOG_NEWTMGR: 1
-
-```
-<br>
-
-### Flash Area Violations
-
-For `flash_owner` type setting definitions, newt checks
-for the following violations:
-
-* An undefined flash area is assigned to a setting.
-* A flash area is assigned to multiple settings.
-
-#### Example: Undefined Flash Area Error Message
-
-The following example shows the error message that newt outputs for an undefined flash area.
-
-```no-highlight
-
-Building target targets/sim_slinky
-Error: Flash errors detected:
- Setting REBOOT_LOG_FLASH_AREA specifies unknown flash area: FLASH_AREA_NOEXIST
-
-Setting history (newest -> oldest):
- REBOOT_LOG_FLASH_AREA: [hw/bsp/native:FLASH_AREA_NOEXIST, sys/reboot:]
-
-```
-The above error occurs because the `hw/bsp/native` package assigns the
-undefined `FLASH_AREA_NOEXIST` flash area to the `sys/reboot` package
-`REBOOT_LOG_FLASH_AREA` setting. The following are excerpts of the definition
-and the override from the `syscfg.yml` files that cause the error:
-
-```no-highlight
-
-#Package: sys/reboot
-syscfg.defs:
- REBOOT_LOG_FLASH_AREA:
- description: 'Flash Area to use for reboot log.'
- type: flash_owner
- value:
-
-#Package: hw/bsp/native
-syscfg.vals:
- REBOOT_LOG_FLASH_AREA: FLASH_AREA_NOEXIST
-
-```
-
-#### Example: Multiple Flash Area Assignment Error Message
-
-The following example shows the error message that newt outputs when multiple
-settings are assigned the same flash area:
-
-```no-highlight
-
-Error: Flash errors detected:
- Multiple flash_owner settings specify the same flash area
- settings: REBOOT_LOG_FLASH_AREA, CONFIG_FCB_FLASH_AREA
- flash area: FLASH_AREA_NFFS
-
-Setting history (newest -> oldest):
- CONFIG_FCB_FLASH_AREA: [hw/bsp/native:FLASH_AREA_NFFS, sys/config:]
- REBOOT_LOG_FLASH_AREA: [apps/slinky:FLASH_AREA_NFFS, sys/reboot:]
-
-```
-
-The above error occurs because the `hw/bsp/native` package assigns
-the `FLASH_AREA_NFFS` flash area to the `sys/config/` package
-`CONFIG_FCB_FLASH_AREA` setting, and the `apps/slinky` package
-also assigns `FLASH_AREA_NFFS` to the `sys/reboot` package
-`REBOOT_LOG_FLASH_AREA` setting. The following are excerpts of the
-two definitions and the two overrides from the `syscfg.yml` files
-that cause the error:
-
-```no-highlight
-
-# Package: sys/config
-syscfg.defs.CONFIG_FCB:
- CONFIG_FCB_FLASH_AREA:
- description: 'The flash area for the Config Flash Circular Buffer'
- type: 'flash_owner'
- value:
-
-# Package: sys/reboot
-syscfg.defs:
- REBOOT_LOG_FLASH_AREA:
- description: 'The flash area for the reboot log'
- type: 'flash_owner'
- value:
-
-#Package: hw/bsp/native
-syscfg.vals:
- CONFIG_FCB_FLASH_AREA: FLASH_AREA_NFFS
-
-#Package: apps/slinky
-syscfg.vals:
- REBOOT_LOG_FLASH_AREA: FLASH_AREA_NFFS
-
-```
-<br>
-###Restriction Violations
-For setting definitions with `restrictions` specified, newt checks for
-the following violations:
-
-* A setting with a `$notnull` restriction does not have a value.
-* For a setting with expression restrictions, some required setting
-values in the expressions evaluate to false.
-
-#### Example: $notnull Restriction Violation Error Message
-
-The following example shows the error message that newt outputs when
-a setting with `$notnull` restriction does not have a value:
-
-```no-highlight
-
-Error: Syscfg restriction violations detected:
- NFFS_FLASH_AREA must not be null
-
-Setting history (newest -> oldest):
- NFFS_FLASH_AREA: [fs/nffs:]
-
-```
-
-The above error occurs because the `fs/nffs` package defines the `NFFS_FLASH_AREA`
-setting with a `$notnull` restriction and no packages override the setting. The
-following is an excerpt of the definition in the `syscfg.yml` file that causes the error:
-
-```no-highlight
-
-#Package: fs/nffs
-syscfg.defs:
- NFFS_FLASH_AREA:
- description: 'The flash area to use for the Newtron Flash File System'
- type: flash_owner
- value:
- restrictions:
- - $notnull
-```
-####Example: Expression Restriction Violation Error Message
-
-The following example shows the error message that newt outputs for
-an expression restriction violation:
-
-```no-highlight
-
-Error: Syscfg restriction violations detected:
- CONFIG_FCB=1 requires CONFIG_FCB_FLASH_AREA be set, but CONFIG_FCB_FLASH_AREA=
-
-Setting history (newest -> oldest):
- CONFIG_FCB: [targets/sim_slinky:1, sys/config:0]
- CONFIG_FCB_FLASH_AREA: [sys/config:]
-
-```
-
-The above error occurs because the `sys/config` package defines the `CONFIG_FCB` setting with
-a restriction that when set, requires that the `CONFIG_FCB_FLASH_AREA` setting must
-also be set. The following are excerpts of the definition and the override from the `syscfg.yml`
-files that cause the error:
-
-```no-highlight
-
-# Package: sys/config
-syscfg.defs:
- CONFIG_FCB:
- description: 'Uses Config Flash Circular Buffer'
- value: 0
- restrictions:
- - '!CONFIG_NFFS'
- - 'CONFIG_FCB_FLASH_AREA'
-
-# Package: targets/sim_slinky
-syscfg.vals:
- CONFIG_FCB: 1
-```
-<br>
-###Task Priority Violations
-
-For `task_priority` type setting definitions, newt checks for the following violations:
-
-* A task priority number is assigned to multiple settings.
-* The task priority number is greater than 239.
-
-#### Example: Duplicate Task Priority Assignment Error Message
-
-The following example shows the error message that newt outputs when
-a task priority number is assigned to multiple settings.
-
-**Note:** The settings used in this example are not actual `apps/slinky` and `sys/shell` settings.
-These settings are created for this example because currently only one Mynewt package
-defines a `task_priority` type setting.
-
-```no-highlight
-
-Error: duplicate priority value: setting1=SHELL_TASK_PRIORITY setting2=SLINKY_TASK_PRIORITY pkg1=apps/slinky pkg2=sys/shell value=1
-
-```
-
-The above error occurs because the `apps/slinky` package defines a `SLINKY_TASK_PRIORITY`
-setting with a default task priority of 1 and the `sys/shell` package also defines a
-`SHELL_TASK_PRIORITY` setting with a default task priority of 1.
-
-#### Example: Invalid Task Priority Error Message
-
-The following example shows the error message that newt outputs when
-a setting is assigned an invalid task priority value:
-
-```no-highlight
-
-Error: invalid priority value: value too great (> 239); setting=SLINKY_TASK_PRIORITY value=240 pkg=apps/slinky
-
-```
-
-The above error occurs because the `apps/slinky` package defines the `SLINKY_TASK_PRIORITY` setting
-with 240 for the default task priority value.
-
-**Note:** Newt does not output the `Setting history` with task priority violation error messages.
-
-
-<br>
-###Duplicate System Configuration Setting Definition
-
-A setting definition must be unique. Newt checks that only one package in the
-target defines a setting. The following example shows the error message that newt
-outputs when multiple packages define the `LOG_NEWTMGR` setting:
-
-```no-highlight
-
-Error: setting LOG_NEWTMGR redefined
-
-```
-**Note:** Newt does not output the `Setting history` with duplicate setting error messages.
-<br>
-###Override of Undefined System Configuration Setting
-
-The `newt build` command ignores overrides of undefined system configuration settings. The command does not print a warning when you run it with the default log level. If you override a setting and the value is not assigned to the setting, you may have misspelled the setting name or a package no longer defines the setting. You have two options to troubleshoot this problem:
-
-* Run the `newt target config show` command to see the configuration setting definitions and overrides.
-* Run the `newt build -ldebug` command to build your target with DEBUG log level.
-
-Note: The `newt build -ldebug` command generates lots of output and we recommend that you use the `newt target config show` command option.
-<br>
-####Example: Ignoring Override of Undefined Setting Message
-
-The following example shows that the `apps/slinky` application overrides the `LOG_NEWTMGR` setting but omits the **T** as an example of an error and overrides the misspelled **LOG_NEWMGR** setting. Here is an excerpt from its `syscfg.yml` file:
-```no-highlight
-#package: apps/slinky
-syscfg.vals:
- # Enable the shell task.
- SHELL_TASK: 1
- ...
-
- # Enable newtmgr commands.
- STATS_NEWTMGR: 1
- LOG_NEWMGR: 1
-
-```
-<br>
-The `newt target config show slinky_sim` command outputs the following WARNING message:
-
-```no-highlight
-
-2017/02/18 17:19:12.119 [WARNING] Ignoring override of undefined settings:
-2017/02/18 17:19:12.119 [WARNING] LOG_NEWMGR
-2017/02/18 17:19:12.119 [WARNING] NFFS_FLASH_AREA
-2017/02/18 17:19:12.119 [WARNING] Setting history (newest -> oldest):
-2017/02/18 17:19:12.119 [WARNING] LOG_NEWMGR: [apps/slinky:1]
-2017/02/18 17:19:12.119 [WARNING] NFFS_FLASH_AREA: [hw/bsp/native:FLASH_AREA_NFFS]
-
-```
-<br>
-
-The `newt build -ldebug slinky_sim` command outputs the following DEBUG message:
-```no-highlight
-
-2017/02/18 17:06:21.451 [DEBUG] Ignoring override of undefined settings:
-2017/02/18 17:06:21.451 [DEBUG] LOG_NEWMGR
-2017/02/18 17:06:21.451 [DEBUG] NFFS_FLASH_AREA
-2017/02/18 17:06:21.451 [DEBUG] Setting history (newest -> oldest):
-2017/02/18 17:06:21.451 [DEBUG] LOG_NEWMGR: [apps/slinky:1]
-2017/02/18 17:06:21.451 [DEBUG] NFFS_FLASH_AREA: [hw/bsp/native:FLASH_AREA_NFFS]
-
-```
-
-<br>
-#### BSP Package Overrides Undefined Configuration Settings
-
-You might see a warning that indicates your application's BSP package is overriding some undefined settings. As you can see from the previous example, the WARNING message shows that the `hw/bsp/native` package is overriding the undefined `NFFS_FLASH_AREA` setting. This is not an error because of the way a BSP package defines and assigns its flash areas to packages that use flash memory.
-
-A BSP package defines, in its `bsp.yml` file, a flash area map of the flash areas on the board. A package that uses flash memory must define a flash area configuration setting name. The BSP package overrides the package's flash area setting with one of the flash areas from its flash area map. A BSP package overrides the flash area settings for all packages that use flash memory because it does not know the packages that an application uses. When an application does not include one of these packages, the flash area setting for the package is undefined. You will see a message that indicates the BSP package overrides this undefined setting.
-
-Here are excerpts from the `hw/bsp/native` package's `bsp.yml` and `syscfg.yml` files for the `slinky_sim` target. The BSP package defines the flash area map in its `bsp.yml` file and overrides the flash area settings for all packages in its `syscfg.yml` file. The `slinky_sim` target does not use the `fs/nffs` package which defines the `NFFS_FLASH_AREA` setting. Newt warns that the `hw/bsp/native` packages overrides the undefined `NFFS_FLASH_AREA` setting.
-
-```no-highlights
-
-# hw/bsp/native bsp.yml
-bsp.flash_map:
- areas:
- # System areas.
- FLASH_AREA_BOOTLOADER:
- device: 0
- offset: 0x00000000
- size: 16kB
-
- ...
-
- FLASH_AREA_IMAGE_SCRATCH:
- device: 0
- offset: 0x000e0000
- size: 128kB
-
- # User areas.
- FLASH_AREA_REBOOT_LOG:
- user_id: 0
- device: 0
- offset: 0x00004000
- size: 16kB
- FLASH_AREA_NFFS:
- user_id: 1
- device: 0
- offset: 0x00008000
-
-# hw/bsp/native syscfg.yml
-syscfg.vals:
- NFFS_FLASH_AREA: FLASH_AREA_NFFS
- CONFIG_FCB_FLASH_AREA: FLASH_AREA_NFFS
- REBOOT_LOG_FLASH_AREA: FLASH_AREA_REBOOT_LOG
-```
diff --git a/docs/os/modules/sysinitconfig/sysinitconfig.md b/docs/os/modules/sysinitconfig/sysinitconfig.md
deleted file mode 100644
index a6241c0..0000000
--- a/docs/os/modules/sysinitconfig/sysinitconfig.md
+++ /dev/null
@@ -1,592 +0,0 @@
-## System Configuration and Initialization
-
-This guide describes how Mynewt manages system configuration and initialization. It shows you how to
-tell Mynewt to use default or customized values to initialize packages that you develop or use to build a target. This guide:
-
-* Assumes you have read the [Concepts](/os/get_started/vocabulary.md) section that describes the Mynewt
-package hierarchy and its use of the `pkg.yml` and `syscfg.yml` files.
-* Assumes you have read the [Newt Tool Theory of Operation](/newt/newt_operation.md) and are familiar with how newt determines
-package dependencies for your target build.
-* Covers only the system initialization for hardware independent packages. It does not cover the Board Support Package (BSP) and other hardware dependent system initialization.
-
-Mynewt defines several configuration parameters in the `pkg.yml` and `syscfg.yml` files. The newt tool uses this information to:
-
-* Generate a system initialization function that calls all the package-specific system initialization functions.
-* Generate a system configuration header file that contains all the package configuration settings and values.
-* Display the system configuration settings and values in the `newt target config` command.
-
-The benefits with this approach include:
-
-* Allows Mynewt developers to reuse other packages and easily change their configuration settings without updating source or header files when implementing new packages.
-* Allows application developers to easily view the system configuration settings and values and determine the values to override for a target build.
-
-<br>
-
-### System Configuration Setting Definitions and Values
-
-A package can optionally:
-
-* Define and expose the system configuration settings to allow other packages to override
-the default setting values.
-* Override the system configuration setting values defined by the packages that it depends on.
-
-You use the `defs` parameter in a `syscfg.yml` file to define the system configuration settings
-for a package. `defs` is a mapping (or associative array) of system configuration setting definitions. It
-has the following syntax:
-
-```no-highlight
-
-syscfg.defs:
- PKGA_SYSCFG_NAME1:
- description:
- value:
- type:
- restrictions:
- PKGA_SYSCFG_NAME2:
- description:
- value:
- type:
- restrictions:
-
-```
-
-<br>
-
-Each setting definition consists of the following key-value mapping:
-
-* A setting name for the key, such as `PKGA_SYSCFG_NAME1` in the syntax example above.
-**Note:** A system configuration setting name must be unique. The newt tool aborts the build
-when multiple packages define the same setting.
-* A mapping of fields for the value. Each field itself is a key-value pair of attributes. The field keys are `description`, `value`, `type`, and `restrictions`. They are described in
-following table:
-
-<table style="width:90%", align="center">
-<tr>
-<th>Field</th>
-<th>Description</th>
-</tr>
-<tr>
-<td><code>description</code></td>
-<td>Describes the usage for the setting. <b>This field is optional.</b></td>
-<tr>
-<td><code>value<code></td>
-<td>Specifies the default value for the setting. <b>This field is required.</b> The value depends on the <code>type</code> that you specify and can be an empty string.
-<tr>
-<td><code>type</code></td>
-<td>Specifies the data type for the <code>value</code> field. <b>This field is optional.</b> You can specify one of three types:
-<ul>
-<li><code>raw</code> - The <code>value</code> data is uninterpreted. This is the default <code>type</code>.</li>
-<li><code>task_priority</code> - Specifies a Mynewt task priority number. The task priority number assigned to each setting must be unique and between 0 and 239. <code>value</code> can be one of the following:
-<ul>
-<li>A number between 0 and 239 - The task priority number to use for the setting.</li>
-<li><code>any</code> - Specify <code>any</code> to have newt automatically assign a priority for the setting.
-newt alphabetically orders all system configuration settings of this type and assigns the next highest available
-task priority number to each setting. </li>
-</ul>
-</li>
-<li><code>flash_owner</code> - Specifies a flash area. The <code>value</code> should be the name of a flash area
-defined in the BSP flash map for your target board.
-</li>
-</ul>
-</td>
-</tr>
-<tr>
-<td><code>restrictions</code></td>
-<td>Specifies a list of restrictions on the setting value. <b>This field is optional.</b> You can specify two formats:
-<ul>
-<li><code>$notnull</code> - Specifies that the setting cannot have the empty string for a value. It essentially means that an empty string is not a sensible value and a package must override it with an appropriate value.
-<br>
-</li>
-<li><code>expression</code> - Specifies a boolean expression of the form <code>[!]<required-setting>[if <base-value>]</code>
-<br>Examples:
-<ul>
-<li><code>restrictions: !LOG_FCB</code> - When this setting is enabled, <code>LOG_FCB</code> must be disabled.
-<li><code>restrictions: LOG_FCB if 0 </code> - When this setting is disabled, <code>LOG_FCB</code> must be enabled.
-</ul>
-</li>
-</ul>
-</td>
-</tr>
-</table>
-
-<br>
-
-####Examples of Configuration Settings
-
-**Example 1:** The following example is an excerpt from the `sys/log/full` package `syscfg.yml` file. It defines the
-`LOG_LEVEL` configuration setting to specify the log level and the `LOG_NEWTMGR` configuration setting to specify whether
-to enable or disable the newtmgr logging feature.
-
-```no-highlight
-
-syscfg.defs:
- LOG_LEVEL:
- description: 'Log Level'
- value: 0
- type: raw
-
- ...
-
- LOG_NEWTMGR:
- description: 'Enables or disables newtmgr command tool logging'
- value: 0
-
-```
-
-<br>
-
-**Example 2:** The following example is an excerpt from the `net/nimble/controller` package `syscfg.yml` file. It defines the `BLE_LL_PRIO`
-configuration setting with a `task_priority` type and assigns task priority 0 to the BLE link layer task.
-
-```no-highlight
-
-syscfg.defs:
- BLE_LL_PRIO:
- description: 'BLE link layer task priority'
- type: 'task_priority'
- value: 0
-
-```
-
-<br>
-
-**Example 3:** The following example is an excerpt from the `fs/nffs` package `syscfg.yml` file.
-
-```no-highlight
-
-syscfg.defs:
- NFFS_FLASH_AREA:
- description: 'The flash area to use for the Newtron Flash File System'
- type: flash_owner
- value:
- restrictions:
- - $notnull
-```
-
-It defines the `NFFS_FLASH_AREA` configuration setting with a `flash_owner` type indicating that a flash area needs to be specified for the Newtron Flash File System. The flash areas are typically defined by the BSP in its `bsp.yml` file. For example, the `bsp.yml` for nrf52dk board (`hw/bsp/nrf52dk/bsp.yml`) defines an area named `FLASH_AREA_NFFS`:
-
-```no-highlight
- FLASH_AREA_NFFS:
- user_id: 1
- device: 0
- offset: 0x0007d000
- size: 12kB
-```
-The `syscfg.yml` file for the same board (`hw/bsp/nrf52dk/syscfg.yml`) specifies that the above area be used for `NFFS_FLASH_AREA`.
-
-```no-highlight
-syscfg.vals:
- CONFIG_FCB_FLASH_AREA: FLASH_AREA_NFFS
- REBOOT_LOG_FLASH_AREA: FLASH_AREA_REBOOT_LOG
- NFFS_FLASH_AREA: FLASH_AREA_NFFS
- COREDUMP_FLASH_AREA: FLASH_AREA_IMAGE_1
-```
-
-Note that the `fs/nffs/syscfg.yml` file indicates that the `NFFS_FLASH_AREA` setting cannot be a null string; so a higher priority package must set a non-null value to it. That is exactly what the BSP package does. For more on priority of packages in setting values, see the next section.
-
-<br>
-
-###Overriding System Configuration Setting Values
-
-A package may use the `vals` parameter in its `syscfg.yml` file to override the configuration values defined
-by other packages. This mechanism allows:
-
-* Mynewt developers to implement a package and easily override the system configuration setting values
- that are defined by the packages it depends on.
-* Application developers to easily and cleanly override default configuration settings in a single place and build a customized target. You can use the `newt target config show <target-name>` command to check all the system configuration setting definitions and
- values in your target to determine the setting values to override. See [newt target](/newt/command_list/newt_target.md).
-
-`vals` specifies the mappings of system configuration setting name-value pairs as follows:
-
-```no-highlight
-
-syscfg.vals:
- PKGA_SYSCFG_NAME1: VALUE1
- PKGA_SYSCFG_NAME2: VALUE2
- ...
- PKGN_SYSCFG_NAME1: VALUEN
-
-```
-**Note**: The newt tool ignores overrides of undefined system configuration settings.
-
-<br>
-
-####Resolving Override Conflicts
-
-The newt tool uses package priorities to determine whether a package can override a value and resolve conflicts when multiple packages override the same system configuration setting. The following rules apply:
-
-* A package can only override the default values of system configuration settings that
- are defined by lower priority packages.
-* When packages with different priorities override the same system configuration setting value, newt uses
- the value from the highest priority package.
-* Packages of equal priority cannot override the same system configuration setting with different values.
- newt aborts the build unless a higher priority package also overrides the value.
-
-The following package types are listed from highest to lowest priority:
-
-* Target
-* App
-* unittest - A target can include either an app or unit test package, but not both.
-* BSP
-* Lib - Includes all other system level packages such as os, lib, sdk, and compiler. (Note that a Lib package cannot override other Lib package settings.)
-
-It is recommended that you override defaults at the target level instead of updating individual
-package `syscfg.yml` files.
-
-<br>
-
-####Examples of Overrides
-
-**Example 4:** The following example is an excerpt from the `apps/slinky` package `syscfg.yml` file. The application package overrides,
-in addition to other packages, the `sys/log/full` package system configuration settings defined in **Example 1**. It changes the LOG_NEWTMGR system configuration setting value from `0` to `1`.
-
-```no-highlight
-
-syscfg.vals:
- # Enable the shell task.
- SHELL_TASK: 1
-
- ...
-
- # Enable newtmgr commands.
- STATS_NEWTMGR: 1
- LOG_NEWTMGR: 1
-
-```
-
-**Example 5:** The following example are excerpts from the `hw/bsp/native` package `bsp.yml` and `syscfg.yml` files.
-The package defines the flash areas for the BSP flash map in the `bsp.yml` file, and sets the `NFFS_FLASH_AREA`
-configuration setting value to use the flash area named `FLASH_AREA_NFFS` in the `syscfg.yml` file.
-
-```no-highlight
-
-bsp.flash_map:
- areas:
- # System areas.
- FLASH_AREA_BOOTLOADER:
- device: 0
- offset: 0x00000000
- size: 16kB
-
- ...
-
- # User areas.
- FLASH_AREA_REBOOT_LOG:
- user_id: 0
- device: 0
- offset: 0x00004000
- size: 16kB
- FLASH_AREA_NFFS:
- user_id: 1
- device: 0
- offset: 0x00008000
- size: 32kB
-
-
-syscfg.vals:
- NFFS_FLASH_AREA: FLASH_AREA_NFFS
-
-```
-
-<br>
-
-###Generated syscfg.h and Referencing System Configuration Settings
-
-The newt tool processes all the package `syscfg.yml` files and generates the
-`bin/<target-path>/generated/include/syscfg/syscfg.h` include file with `#define` statements for each system configuration
-setting defined. Newt creates a `#define` for a setting name as follows:
-
-* Adds the prefix `MYNEWT_VAL_`.
-* Replaces all occurrences of "/", "-", and " " in the setting name with "_".
-* Converts all characters to upper case.
-
-For example, the #define for my-config-name setting name is MYNEWT_VAL_MY_CONFIG_NAME.
-
-Newt groups the settings in `syscfg.h` by the packages that defined them. It also indicates the
-package that changed a system configuration setting value.
-
-You must use the `MYNEWT_VAL()` macro to reference a #define of a setting name in your header and source files.
-For example, to reference the `my-config-name` setting name, you use `MYNEWT_VAL(MY_CONFIG_NAME)`.
-
-**Note:** You only need to include `syscfg/syscfg.h` in your source files to access the `syscfg.h` file. The newt tool sets the correct include path to build your target.
-
-####Example of syscfg.h and How to Reference a Setting Name
-**Example 6**: The following example are excerpts from a sample `syscfg.h` file generated for an app/slinky target and
-from the `sys/log/full` package `log.c` file that shows how to reference a setting name.
-
-The `syscfg.h` file shows the `sys/log/full` package definitions and also indicates that `app/slinky`
-changed the value for the `LOG_NEWTMGR` settings.
-
-```no-highlight
-
-/**
- * This file was generated by Apache Newt version: 1.0.0-dev
- */
-
-#ifndef H_MYNEWT_SYSCFG_
-#define H_MYNEWT_SYSCFG_
-
-/**
- * This macro exists to ensure code includes this header when needed. If code
- * checks the existence of a setting directly via ifdef without including this
- * header, the setting macro will silently evaluate to 0. In contrast, an
- * attempt to use these macros without including this header will result in a
- * compiler error.
- */
-#define MYNEWT_VAL(x) MYNEWT_VAL_ ## x
-
-
- ...
-
-/*** kernel/os */
-#ifndef MYNEWT_VAL_MSYS_1_BLOCK_COUNT
-#define MYNEWT_VAL_MSYS_1_BLOCK_COUNT (12)
-#endif
-
-#ifndef MYNEWT_VAL_MSYS_1_BLOCK_SIZE
-#define MYNEWT_VAL_MSYS_1_BLOCK_SIZE (292)
-#endif
-
- ...
-
-/*** sys/log/full */
-
-#ifndef MYNEWT_VAL_LOG_LEVEL
-#define MYNEWT_VAL_LOG_LEVEL (0)
-#endif
-
- ...
-
-/* Overridden by apps/slinky (defined by sys/log/full) */
-#ifndef MYNEWT_VAL_LOG_NEWTMGR
-#define MYNEWT_VAL_LOG_NEWTMGR (1)
-#endif
-
-#endif
-
-```
-
-The `log_init()` function in the `sys/log/full/src/log.c` file initializes the `sys/log/full` package. It checks the
-`LOG_NEWTMGR` setting value, using `MYNEWT_VAL(LOG_NEWTMGR)`, to determine whether the target application
-has enabled the `newtmgr log` functionality. It only registers the the callbacks to process the
-`newtmgr log` commands when the setting value is non-zero.
-
-```no-highlight
-
-void
-log_init(void)
-{
- int rc;
-
- /* Ensure this function only gets called by sysinit. */
- SYSINIT_ASSERT_ACTIVE();
-
- (void)rc;
-
- if (log_inited) {
- return;
- }
- log_inited = 1;
- ...
-
-#if MYNEWT_VAL(LOG_NEWTMGR)
- rc = log_nmgr_register_group();
- SYSINIT_PANIC_ASSERT(rc == 0);
-#endif
-}
-
-```
-
-<br>
-
-### System Initialization
-
-During system startup, Mynewt creates a default event queue and a main task to process events from this queue.
-You can override the `OS_MAIN_TASK_PRIO` and `OS_MAIN_TASK_STACK_SIZE` setting values defined by the
-`kernel/os` package to specify different task priority and stack size values.
-
-Your application's `main()` function executes in the context of the main task and must perform the following:
-
-* At the start of `main()`, call the Mynewt `sysinit()` function to initialize
-the packages before performing any other processing.
-* At the end of `main()`, wait for and dispatch events from the default event queue in an infinite loop.
-
-**Note:** You must include the `sysinit/sysinit.h` header file to access the `sysinit()` function.
-
-Here is an example of a `main()` function:
-
-```no-highlight
-
-int
-main(int argc, char **argv)
-{
- /* First, call sysinit() to perform the system and package initialization */
- sysinit();
-
- ... other application initialization processing....
-
-
- /* Last, process events from the default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
- /* main never returns */
-}
-
-```
-<br>
-
-####Specifying Package Initialization Functions
-
-The `sysinit()` function calls the `sysinit_app()` function to perform system
-initialization for the packages in the target. You can, optionally,
-specify one or more package initialization functions
-that `sysinit_app()` calls to initialize a package.
-
-A package initialization function must have the following prototype:
-
-```no-highlight
-
-void init_func_name(void)
-
-```
-Package initialization functions are called in stages to ensure that lower priority
-packages are initialized before higher priority packages. A stage is an
-integer value, 0 or higher, that specifies when an initialization function is
-called. Mynewt calls the package initialization functions
-in increasing stage number order. The call order for initialization functions with the
-same stage number depends on the order the packages are processed,
-and you cannot rely on a specific call order for these functions.
-
-You use the `pkg.init` parameter in the
-`pkg.yml` file to specify an initialization function and the stage number to call the function.
-You can specify multiple initialization functions, with a different stage number for each function,
-for the parameter values. This feature allows packages with interdependencies to
-perform initialization in multiple stages.
-
-The `pkg.init` parameter has the following syntax in the `pkg.yml` file:
-
-```no-highlight
-
-pkg.init:
- pkg_init_func1_name: pkg_init_func1_stage
- pkg_init_func2_name: pkg_init_func2_stage
-
- ...
-
- pkg_init_funcN_name: pkg_init_funcN_stage
-
-```
-where `pkg_init_func#_name` is the C function name of an initialization function, and `pkg_init_func#_stage`
-is an integer value, 0 or higher, that indicates the stage when the `pkg_init_func#_name` function is called.
-
-
-**Note:** The `pkg.init_function` and `pkg.init_stage` parameters introduced in a previous release for
-specifying a package initialization function and a stage number are deprecated and have been
-retained to support the legacy format. They will not
-be maintained for future releases and we recommend that you migrate to use the `pkg.init` parameter.
-
-<br>
-
-#### Generated sysinit_app() Function
-
-The newt tool processes the `pkg.init` parameters in all the `pkg.yml` files for a target,
-generates the `sysinit_app()` function in the `<target-path>/generated/src/<target-name>-sysinit_app.c` file, and
-includes the file in the build. Here is an example `sysinit_app()` function:
-
-```no-highlight
-
-**
- * This file was generated by Apache Newt (incubating) version: 1.0.0-dev
- */
-
-#if !SPLIT_LOADER
-
-void split_app_init(void);
-void os_pkg_init(void);
-void imgmgr_module_init(void);
-
- ...
-
-void stats_module_init(void);
-
-void
-sysinit_app(void)
-{
-
- /*** Stage 0 */
- /* 0.0: kernel/os */
- os_pkg_init();
-
- /*** Stage 2 */
- /* 2.0: sys/flash_map */
- flash_map_init();
-
- /*** Stage 10 */
- /* 10.0: sys/stats/full */
- stats_module_init();
-
- /*** Stage 20 */
- /* 20.0: sys/console/full */
- console_pkg_init();
-
- /*** Stage 100 */
- /* 100.0: sys/log/full */
- log_init();
- /* 100.1: sys/mfg */
- mfg_init();
-
- ....
-
- /*** Stage 300 */
- /* 300.0: sys/config */
- config_pkg_init();
-
- /*** Stage 500 */
- /* 500.0: sys/id */
- id_init();
- /* 500.1: sys/shell */
- shell_init();
-
- ...
-
- /* 500.4: mgmt/imgmgr */
- imgmgr_module_init();
-
- /*** Stage 501 */
- /* 501.0: mgmt/newtmgr/transport/nmgr_shell */
- nmgr_shell_pkg_init();
-}
-#endif
-
-```
-
-
-<br>
-
-###Conditional Configurations
-You can use the system configuration setting values to conditionally specify parameter values
-in `pkg.yml` and `syscfg.yml` files. The syntax is:
-
-```no-highlight
-
-parameter_name.PKGA_SYSCFG_NAME:
- parameter_value
-
-```
-This specifies that `parameter_value` is only set for `parameter_name` if the `PKGA_SYSCFG_NAME` configuration setting value
-is non-zero. Here is an example from the `libs/os` package `pkg.yml` file:
-
-```
-pkg.deps:
- - sys/sysinit
- - util/mem
-
-pkg.deps.OS_CLI
- - sys/shell
-
-```
-This example specifies that the `os` package depends on the `sysinit` and `mem` packages, and also depends on the
-`shell` package when `OS_CLI` is enabled.
-
-The newt tool aborts the build when it detects circular conditional dependencies.
diff --git a/docs/os/modules/testutil/test_assert.md b/docs/os/modules/testutil/test_assert.md
deleted file mode 100644
index 44495ed..0000000
--- a/docs/os/modules/testutil/test_assert.md
+++ /dev/null
@@ -1,76 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> TEST_ASSERT</font>
-
-```no-highlight
-TEST_ASSERT(expression, fail_msg, ...)
-```
-```no-highlight
-TEST_ASSERT_FATAL(expression, fail_msg, ...)
-```
-
-Asserts that the specified condition is true. If the expression is true, nothing gets reported. *fail_msg* will be printed out if the expression is false. The expression argument is mandatory; the rest are optional. The fail_msg argument is a printf format string which specifies how the remaining arguments are parsed.
-
-`TEST_ASSERT_FATAL()` causes the current test case to be aborted, if expression fails.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| expression | Condition being tested. If it fails, test is considered a failure, and a message is printed out. |
-| fail_msg | Pointer to C string that contains a format string that follows the same specifications as format in printf. |
-| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. va_list is a special type defined in <cstdarg> in stdarg.h. |
-
-#### Returned values
-
-None
-
-#### Notes
-
-While `console_printf`, with its well understood formatting options in C, is more convenient and easy on the eyes than the raw output of `console_write`, the associated code size is considerably larger.
-
-#### Example
-Example #1:
-
-```no-highlight
-TEST_CASE(config_test_insert)
-{
- int rc;
-
- rc = conf_register(&config_test_handler);
- TEST_ASSERT(rc == 0);
-}
-```
-
-Example #2:
-
-```no-highlight
-TEST_CASE(nffs_test_unlink)
-{
- int rc;
-
- ....
-
- rc = nffs_format(nffs_area_descs);
- TEST_ASSERT_FATAL(rc == 0);
-
- ....
-}
-```
-
-Example #3:
-
-```no-highlight
-
-static int
-cbmem_test_case_1_walk(struct cbmem *cbmem, struct cbmem_entry_hdr *hdr,
- void *arg)
-{
- ....
-
- rc = cbmem_read(cbmem, hdr, &actual, 0, sizeof(actual));
- TEST_ASSERT_FATAL(rc == 1, "Couldn't read 1 byte from cbmem");
- TEST_ASSERT_FATAL(actual == expected,
- "Actual doesn't equal expected (%d = %d)", actual, expected);
-
- ....
-}
-```
diff --git a/docs/os/modules/testutil/test_case.md b/docs/os/modules/testutil/test_case.md
deleted file mode 100644
index 24bfd38..0000000
--- a/docs/os/modules/testutil/test_case.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> TEST_CASE </font>
-
-```no-highlight
-TEST_CASE(test_case_name)
-```
-
-Defines a test case function with the following type `int test_case_name(void)`. This can then be called from regression test's `TEST_SUITE()` function.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| test_case_name | Used as the function name for this test case. |
-
-#### Returned values
-
-Return value is 0 if the test case passed; nonzero if it failed. Generally, the return code is not used. It is expected that the case will pass/fail with tests done using `TEST_ASSERT()`.
-
-
-#### Example
-
-```no-highlight
-TEST_CASE(config_test_insert)
-{
- ....
-}
-```
diff --git a/docs/os/modules/testutil/test_decl.md b/docs/os/modules/testutil/test_decl.md
deleted file mode 100644
index a581ea5..0000000
--- a/docs/os/modules/testutil/test_decl.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> TEST_CASE_DECL </font>
-
-```no-highlight
-TEST_CASE_DECL(test_case_name)
-```
-
-Declares a test case function with the following type `int test_case_name(void)`. This can then be called from regression test's `TEST_SUITE()` function. This is only required if the test case function
-exists in a different file than the test suite. This will allow the test suite
-to find the test case
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| test_case_name | Used as the function name for this test case. |
-
-#### Returned values
-
-Return value is 0 if the test case passed; nonzero if it failed. Generally, the return code is not used. It is expected that the case will pass/fail with tests done using `TEST_ASSERT()`.
-
-
-#### Example file `test_cases.h`
-
-```no-highlight
-TEST_CASE_DECL(test_case_1)
-TEST_CASE_DECL(test_case_2)
-TEST_CASE_DECL(test_case_3)
-```
diff --git a/docs/os/modules/testutil/test_pass.md b/docs/os/modules/testutil/test_pass.md
deleted file mode 100644
index 0933ea6..0000000
--- a/docs/os/modules/testutil/test_pass.md
+++ /dev/null
@@ -1,29 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> TEST_PASS </font>
-
-```no-highlight
-TEST_PASS(msg, ...)
-```
-
-Reports a success result for the current test. This function is not normally needed, as all successful tests automatically write an empty pass result at completion. It is only needed when the success result report should contain text. The msg argument is a printf format string
- which specifies how the remaining arguments are parsed. The result file
- produced by this function contains the following text:
-```no-highlight
- |<file>:<line-number>| manual pass
- <msg>
-```
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| msg | This is a printf format string which specifies how the remaining arguments are parsed |
-| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. va_list is a special type defined in <cstdarg> in stdarg.h. |
-
-#### Returned values
-
-None
-
-#### Notes
-
-After this function is called, the remainder of the test case is not executed.
-
diff --git a/docs/os/modules/testutil/test_suite.md b/docs/os/modules/testutil/test_suite.md
deleted file mode 100644
index b333883..0000000
--- a/docs/os/modules/testutil/test_suite.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> TEST_SUITE </font>
-
-```no-highlight
-TEST_SUITE(test_suite_name)
-```
-
-Declares a test suite function with the following type `int test_suite_name(void)`. This can then be called from either *project/test*, or from main routine for package specific regression test.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| test_suite_name | Used as the function name for this test suite. |
-
-#### Returned values
-
-Return value is 0 if the test suite passed; nonzero if it failed. Generally, the return code is not used. It is expected that the individual test cases will pass/fail with tests done using `TEST_ASSERT()`.
-
-#### Example
-
-```no-highlight
-TEST_SUITE(os_sem_test_suite)
-{
- os_sem_test_basic();
- os_sem_test_case_1();
- os_sem_test_case_2();
- os_sem_test_case_3();
- os_sem_test_case_4();
-}
-```
diff --git a/docs/os/modules/testutil/testutil.md b/docs/os/modules/testutil/testutil.md
deleted file mode 100644
index 8d7f30a..0000000
--- a/docs/os/modules/testutil/testutil.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# testutil
-
-
-The testutil package is a test framework that provides facilities for specifying test cases and recording test results.
-
-You would use it to build regression tests for your library.
-
-### Description
-
-A package may optionally contain a set of test cases. Test cases are not normally compiled and linked when a package is built; they are only included
-when the "test" identity is specified. All of a package's test code goes in its `src/test` directory. For example, the nffs package's test code is located in the following directory:
-```no-highlight
- * fs/nffs/src/test/
-```
-This directory contains the source and header files that implement the nffs test code.
-
-The test code has access to all the header files in the following directories:
-```no-highlight
- * src
- * src/arch/<target-arch>
- * include
- * src/test
- * src/test/arch/<target-arch>
- * include directories of all package dependencies
-```
-Package test code typically depends on the testutil package, described later in this document.
-
-Some test cases or test initialization code may be platform-specific. In such cases, the platform-specific function definitions are placed in arch subdirectories within the package test directory.
-
-While building the test code (i.e., when the `test` identity is specified), the newt tool defines the `TEST` macro. This macro is defined during compilation of all C source files in all projects and packages.
-
-Tests are structured according to the following hierarchy:
-```no-highlight
- [test]
- / \
- [suite] [suite]
- / \ / \
- [case] [case] [case] [case]
-```
-
-I.e., a test consists of test suites, and a test suite consists of test cases.
-
-The test code uses testutil to define test suites and test cases.
-
-Regression test can then be executed using 'newt target test' command, or by including a call to your test suite from `project/test/src/test.c`.
-
-### Example
-
-[This Tutorial](../../tutorials/unit_test.md) shows how to create a test suite
-for a Mynewt package.
-
-### Data structures
-
-```no-highlight
-struct tu_config {
- int tc_print_results;
- int tc_system_assert;
-
- tu_case_init_fn_t *tc_case_init_cb;
- void *tc_case_init_arg;
-
- tu_case_report_fn_t *tc_case_fail_cb;
- void *tc_case_fail_arg;
-
- tu_case_report_fn_t *tc_case_pass_cb;
- void *tc_case_pass_arg;
-
- tu_suite_init_fn_t *tc_suite_init_cb;
- void *tc_suite_init_arg;
-
- tu_restart_fn_t *tc_restart_cb;
- void *tc_restart_arg;
-};
-extern struct tu_config tu_config;
-```
-The global `tu_config` struct contains all the testutil package's settings.
-This should be populated before `tu_init()` is called.
-
-### List of Functions
-
-<Comments such as these instructions are placed within angle brackets. List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the header has to have at least 2 words for the anchor to work - that's how it is. "no-highlight" disables syntax highlighting. You can enable it for a particular language by specifying what the language is instead of "no-highlight". Be warned that this highlighting or no-highlighting specification may not show up nicely on Mou.>
-
-The functions, and macros available in `testutil` are:
-
-| Function | Description |
-|---------|-------------|
-| [tu_init](tu_init.md) | Initializes the test framework according to the contents of the tu_config struct. |
-| [TEST_ASSERT](test_assert.md) | Asserts that the specified condition is true. |
-| [TEST_PASS](test_pass.md) | Reports a success result for the current test. |
-| [TEST_SUITE](test_suite.md) | Declares a test suite function. |
-| [TEST_CASE](test_case.md) | Defines a test case function. |
-| [TEST_CASE_DECL](test_decl.md) | Declares a test case function. his is only required if the test case function exists in a different file than the test suite. |
-| [tu_restart](tu_restart.md) | This function is used when a system reset is necessary to proceed with testing. |
diff --git a/docs/os/modules/testutil/tu_init.md b/docs/os/modules/testutil/tu_init.md
deleted file mode 100644
index f785cbb..0000000
--- a/docs/os/modules/testutil/tu_init.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> tu_init</font>
-
-```no-highlight
-int tu_init(void)
-```
-
-Initializes the test framework according to the contents of the `tu_config` struct. This function must be called before any tests are run.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-
-#### Example
-
-Here's an example of stand-alone code which allows the user to execute regression tests for sys/config package only.
-
-```no-highlight
-#ifdef PKG_TEST
-
-int
-main(int argc, char **argv)
-{
- tu_config.tc_print_results = 1;
- tu_init();
-
- conf_init();
- config_test_all();
-
- return tu_any_failed;
-}
-
-#endif
-```
diff --git a/docs/os/modules/testutil/tu_restart.md b/docs/os/modules/testutil/tu_restart.md
deleted file mode 100644
index 0f6dfd8..0000000
--- a/docs/os/modules/testutil/tu_restart.md
+++ /dev/null
@@ -1,31 +0,0 @@
-## <font color="F2853F" style="font-size:24pt"> tu_restart </font>
-
-```no-highlight
-void tu_restart(void)
-```
-
-This function is used when a system reset is necessary to proceed with testing. For example, the OS is designed to run forever once started, so a test which creates several OS tasks and then starts the OS has no means of completing. This function, when called from such a test, gracefully ends the current test case and proceeds to the next test case.
-
-The particulars of this function depend on whether it is called from a simulated environment. In a simulated environment, this function uses a `longjmp()` call to break out of the current test case.
-
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-Returns 0 on success; nonzero on failure.
-
-#### Example
-
-```no-highlight
-void
-os_test_restart(void)
-{
- ....
-
- tu_restart();
-}
-#endif
-```
diff --git a/docs/os/os_user_guide.md b/docs/os/os_user_guide.md
deleted file mode 100644
index f9b496a..0000000
--- a/docs/os/os_user_guide.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# OS User Guide
-
-This guide provides comprehensive information about Mynewt OS, the real-time operating system for embedded systems.
-It is intended both for an embedded real-time software developer as well as higher-level applications developer wanting to understand the features and benefits of the system.
-Mynewt OS is highly composable and flexible. Only those features actually used by the application are compiled into the run-time image. Hence, the actual size of Mynewt is completely determined by the application. The guide covers all the features and services available in the OS and contains several examples showing how they can be used.
-**Send us an email on the dev@ mailing list if you have comments or suggestions!** If you haven't joined the mailing list, you will find the links [here](../community.md).
-
-<br>
-
diff --git a/docs/os/tutorials/STM32F303.md b/docs/os/tutorials/STM32F303.md
deleted file mode 100644
index 883889c..0000000
--- a/docs/os/tutorials/STM32F303.md
+++ /dev/null
@@ -1,216 +0,0 @@
-## Blinky, your "Hello World!", on STM32F303 Discovery
-
-<br>
-
-### Objective
-
-Learn how to use packages from a default application repository of Mynewt to build your first *Hello World* application (Blinky) on a target board. Once built using the *newt* tool, this application will blink the LED lights on the target board.
-
-Create a project with a simple app that blinks an LED on the stmf303
-discovery board. In the process import some external libraries into your project. Download the application to the target and watch it blink!
-
-<br>
-
-### What you need
-
-* Discovery kit with STM32F303VC MCU
-* Laptop running Mac OSX.
-* It is assumed you have already installed newt tool.
-* It is assumed you already installed native tools as described [here](../get_started/native_tools.md)
-
-Also, we assume that you're familiar with UNIX shells. Let's gets started!
-
-<br>
-
-### Create a project
-
-Create a new project to hold your work. For a deeper understanding, you can read about project creation in
-[Get Started -- Creating Your First Project](../get_started/project_create.md)
-or just follow the commands below.
-
-If you've already created a project from another tutorial, you can re-use
-that project.
-
-```
-$ mkdir ~/dev
-$ cd ~/dev
-$ newt new myproj
-Downloading project skeleton from apache/incubator-mynewt-blinky...
-Installing skeleton in myproj...
-Project myproj successfully created.
-
-$ cd myproj
-
-```
-
-**Note:** Don't forget to change into the `myproj` directory.
-
-<br>
-
-### Import External STM32F3 Library support
-
-The STM32F303 support for Mynewt lives in an external repository. It's
-necessary to add another repository to the project. To do this,
-edit the file `project.yml` in the root directory of your project `myproj`
-
-This requires two changes to this file.
-
-1. You must define the properties of the external repository that you want
-to add
-2. You must include the repository in your project.
-
-Edit the file `project.yml` with your favorite editor and add the
-following repository details in the file (after the core
-repository). This gives newt the information to contact the repository
-and extract its contents. In this case, the repository is on github in
-the `runtimeco` collection. Its name is `mynewt-stm32f3` and we will accept
-any version up to the latest. You can look at the contents [here](https://github.com/runtimeco/mynewt_stm32f3).
-
-```
-repository.mynewt_stm32f3:
- type: github
- vers: 0-latest
- user: runtimeco
- repo: mynewt_stm32f3
-```
-
-<br>
-
-In the same file, add the following highlighted line to the
-`project.repositories` variable. This tells newt to download the
- repository contents into your project.
-
-```hl_lines="3"
-project.repositories:
- - apache-mynewt-core
- - mynewt_stm32f3
-```
-
-<br>
-
-### Install dependencies
-
-Now you can install this into the project using:
-
-```
-$ newt install -v
-Downloading repository description for apache-mynewt-core... success!
-...
-apache-mynewt-core successfully installed version 0.7.9-none
-...
-Downloading repository description for mynewt_stm32f3... success!
-Downloading repository mynewt_stm32f3
-...
-Resolving deltas: 100% (65/65), done.
-Checking connectivity... done.
-mynewt_stm32f3 successfully installed version 0.0.0-none
-```
-
-<br>
-
-
-### Create targets
-
-Create two targets to build using the stmf3 board support package and the
-app blinky example from mynewt. The output of these commands are not
-shown here for brevity.
-
-The first target is the application image itself. The second
-target is the bootloader which allows you to upgrade your mynewt
-applications.
-
-
-```
-$ newt target create stmf3_blinky
-$ newt target set stmf3_blinky build_profile=optimized
-$ newt target set stmf3_blinky bsp=@mynewt_stm32f3/hw/bsp/stm32f3discovery
-$ newt target set stmf3_blinky app=apps/blinky
-
-$ newt target create stmf3_boot
-$ newt target set stmf3_boot app=@apache-mynewt-core/apps/boot
-$ newt target set stmf3_boot bsp=@mynewt_stm32f3/hw/bsp/stm32f3discovery
-$ newt target set stmf3_boot build_profile=optimized
-
-$ newt target show
-
-targets/stmf3_blinky
- app=apps/blinky
- bsp=@mynewt_stm32f3/hw/bsp/stm32f3discovery
- build_profile=optimized
-targets/stmf3_boot
- app=apps/boot
- bsp=@mynewt_stm32f3/hw/bsp/stm32f3discovery
- build_profile=optimized
-```
-
-<br>
-
-### Build the target executables
-
-To build the images, use the `newt build` command below.
-
-```
-$ newt build stmf3_blinky
- ...
-Archiving stm32f3discovery.a
-Linking blinky.elf
-App successfully built: ~/dev/myproj/bin/stmf3_blinky/apps/blinky/blinky.elf
-
-$ newt build stmf3_boot
-Compiling log_shell.c
-Archiving log.a
-Linking boot.elf
-App successfully built: ~/dev/myproj/bin/stmf3_boot/apps/boot/boot.elf
-```
-
-<br>
-
-### Sign and create the blinky application image
-
-You must sign and version your application image to download it using newt. Use
-the `newt create-image` command to perform this action. Here we assign this
-image an arbitrary version `1.2.3`.
-
-```no-highlight
-$ newt create-image stmf3_blinky 1.2.3
-App image successfully generated: ~/dev/myproj/bin/stmf3_blinky/apps/blinky/blinky.img
-Build manifest:~/dev/myproj/bin/stmf3_blinky/apps/blinky/manifest.json
-```
-
-<br>
-
-### Configure the hardware
-
-
- The STM32F3DISCOVERY board includes an ST-LINK/V2 embedded debug tool interface that will be used to program/debug the board. To program the MCU on the board, simply plug in the two jumpers on CN4, as shown in the picture in red. If you want to learn more about the board you will find the User Manual at [http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf](http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf)
-
-* 
-
-<br>
-
-### Download the Images
-
-Use the `newt load` command to download the images to the target board.
-
-```
-$ newt -v load stmf3_boot
-$ newt -v load stmf3_blinky
-```
-
-<br>
-
-### Watch the LED blink
-
-Congratulations! You have built, downloaded, and run your first application using mynewt for the stm32f3 discovery board. One of the LEDs on the LED wheel should be blinking at 1 Hz.
-
-<br>
-
-### Want more?
-
-Want to make your board do something a little more exciting with the LEDs? Then try making the modifications to the Blinky app to make it a [pin-wheel app](pin-wheel-mods.md) and you can light all the LEDs in a pin-wheel fashion.
-
-We have more fun tutorials for you to get your hands dirty. Be bold and try other Blinky-like [tutorials](../tutorials/nRF52.md) or try enabling additional functionality such as [remote comms](project-slinky.md) on the current board.
-
-If you see anything missing or want to send us feedback, please do so by signing up for appropriate mailing lists on our [Community Page](../../community.md).
-
-Keep on hacking and blinking!
diff --git a/docs/os/tutorials/add_newtmgr.md b/docs/os/tutorials/add_newtmgr.md
deleted file mode 100644
index 33a3dea..0000000
--- a/docs/os/tutorials/add_newtmgr.md
+++ /dev/null
@@ -1,271 +0,0 @@
-
-## Enabling Newt Manager in Your Application
-
-<br>
-In order for your application to communicate with the newtmgr tool and process Newt Manager commands, you must
-enable Newt Manager device management and the support to process Newt Manager commands
-in your application. This tutorial explains how to add the support to your application.
-
-This tutorial assumes that you have read the [Device Management with Newt Manager](/os/modules/devmgmt/newtmgr/)
-guide and are familiar with the `newtmgr` and `oicmgr` frameworks and all the options that are available
-to customize your application.
-
-This tutorial shows you how to configure your application to:
-
-* Use the newtmgr framework.
-* Use serial transport to communicate with the newtmgr tool.
-* Support all Newt Manager commands.
-
-See [Other Configuration Options](#other-configuration-options) on how to customize your application.
-
-<br>
-
-### Prerequisites
-Ensure that you have met the following prerequisites before continuing with this tutorial:
-
-* Have Internet connectivity to fetch remote Mynewt components.
-* Have a cable to establish a serial USB connection between the board and the laptop.
-* Install the newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
-* Install the [newtmgr tool](../../newtmgr/install_mac.md).
-
-<br>
-
-### Use an Existing Project
-
-We assume that you have worked through at least some of the other tutorials and have an existing project.
-In this example, we modify the `btshell` app to enable Newt Manager support.
-We call our target `myble`. You can create the target using any name you choose.
-
-### Modify Package Dependencies and Configurations
-
-
-Add the following packages to the `pkg.deps` parameter in your target or application `pkg.yml` file:
-
-```no-highlight
-
-pkg.deps:
- - mgmt/newtmgr
- - mgmt/newtmgr/transport/nmgr_shell
- - mgmt/imgmgr
- - sys/log/full
- - sys/stats/full
- - sys/config
- - test/crash_test
- - test/runtest
-
-```
-Each package provides the following Newt Manager functionality:
-
-* `mgmt/newtmgr`: Supports the newtmgr framework and the
-Newt Manager `echo`, `taskstat` `mpstat`, `datetime`, and `reset` commands.
-* `mgmt/newtmgr/transport/nmgr_shell`: Supports serial transport.
-* `mgmt/imgmgr`: Supports the `newtmgr image` command
-* `sys/log/full` : Supports the `newtmgr log` command.
-* `sys/stats/full`: Supports the `newtmgr stat` command.
-* `sys/config`: Supports the `newtmgr config` command.
-* `test/crash_test`: Supports the `newtmgr crash` command.
-* `test/runtest`: Supports the `newt run` command.
-
-
-Add the following configuration setting values to the `syscfg.vals` parameter in the target or
-application `syscfg.yml` file:
-
-```no-highlight
-
-syscfg.vals:
- LOG_NEWTMGR: 1
- STATS_NEWTMGR: 1
- CONFIG_NEWTMGR: 1
- CRASH_TEST_NEWTMGR: 1
- RUNTEST_NEWTMGR: 1
- SHELL_TASK: 1
- SHELL_NEWTMGR: 1
-```
-<br>
-The first five configuration settings enable support for the Newt Manager `log`, `stat`, `config`, `crash`,
-and `run` commands. The `SHELL_TASK` setting enables the shell for serial transport. The `SHELL_NEWTMGR` setting enables newtmgr support in the shell.
-
-Note that you may need to override additional configuration settings that are specific to each package to customize the
-package functionality.
-
-<br>
-
-### Modify the Source
-
-By default, the `mgmt` package uses the Mynewt default event queue to receive request events from the newtmgr tool. These events are processed in the context of the application main task.
-
-You can specify a different event queue for the package to use. If you choose to use a dedicated event queue, you must create a task to process events from this event queue. The `mgmt` package executes and handles newtmgr request events in the context of this task. The `mgmt` package exports the `mgmt_evq_set()` function that allows you to specify an event queue.
-
-This example uses the Mynewt default event queue and you do not need to modify your application source.
-
-If you choose to use a different event queue, see [Events and Event Queues](event_queue.md) for details on how to initialize an event queue and create a task to process the events. You will also need to modify your `main.c` to add the call to the `mgmt_evq_set()` function as follows:
-
-Add the `mgmt/mgmt.h` header file:
-
-```no-highlight
-
-#include <mgmt/mgmt.h>
-
-```
-<br>
-Add the call to specify the event queue. In the `main()` function, scroll down to the `while (1) ` loop and add the following statement above the loop:
-
-```no-highlight
-
-mgmt_evq_set(&my_eventq)
-
-```
-where `my_eventq` is an event queue that you have initialized.
-
-### Build the Targets
-
-Build the two targets as follows:
-
-```
-$ newt build nrf52_boot
-<snip>
-App successfully built: ./bin/nrf52_boot/apps/boot/boot.elf
-$ newt build myble
-Compiling hci_common.c
-Compiling util.c
-Archiving nimble.a
-Compiling os.c
-<snip>
-```
-
-<br>
-
-### Create the Application Image
-
-Generate an application image for the `myble` target. You can use any version number you choose.
-
-```
-$ newt create-image myble 1.0.0
-App image successfully generated: ./bin/makerbeacon/apps/btshell/btshell.img
-Build manifest: ./bin/makerbeacon/apps/btshell/manifest.json
-```
-
-<br>
-
-### Load the Image
-
-Ensure the USB connector is in place and the power LED on the board is lit. Turn the power switch on your board off,
-then back on to reset the board after loading the image.
-
-```
-$ newt load nrf52_boot
-$ newt load myble
-```
-
-
-
-### Set Up a Connection Profile
-
-The newtmgr tool requires a connection profile in order to connect to your board. If you have not done so,
-follow the [instructions](../../newtmgr/command_list/newtmgr_conn.md) for setting up your connection profile.
-
-<br>
-
-### Communicate with Your Application
-
-Once you have a connection profile set up, you can connect to your device with ```newtmgr -c myconn <command>``` to run commands in your application.
-
-Issue the `echo` command to ensure that your application is communicating with the newtmgr tool:
-
-```no-highlight
-
-# newtmgr -c myconn echo hello
-hello
-
-```
-<br>
-Test your application to ensure that it can process a Newt Manager command that is supported by a different package.
-Issue the `stat` command to see the BLE stats.
-
-```no-highlight
-
-stat group: ble_att
- 0 error_rsp_rx
- 0 error_rsp_tx
- 0 exec_write_req_rx
- 0 exec_write_req_tx
- 0 exec_write_rsp_rx
- 0 exec_write_rsp_tx
- 0 find_info_req_rx
- 0 find_info_req_tx
- 0 find_info_rsp_rx
- 0 find_info_rsp_tx
- 0 find_type_value_req_rx
-
- ...
-
- 0 read_type_req_tx
- 0 read_type_rsp_rx
- 0 read_type_rsp_tx
- 0 write_cmd_rx
- 0 write_cmd_tx
- 0 write_req_rx
- 0 write_req_tx
- 0 write_rsp_rx
- 0 write_rsp_tx
-
-```
-
-Your application is now able to communicate with the newtmgr tool.
-
-<br>
-### Other Configuration Options
-
-This section explains how to customize your application to use other Newt Manager protocol options.
-
-#### Newtmgr Framework Transport Protocol Options
-The newtmgr framework currently supports BLE and serial transport protocols.
-To configure the transport protocols that are supported, modify the `pkg.yml`
-and `syscfg.yml` files as follows:
-
-* Add the `mgmt/newtmgr/transport/ble` package to the `pkg.deps` parameter to enable BLE transport.
-* Add the `mgmt/newtmgr/transport/nmgr_shell` package to
-the `pkg.deps` parameter, and add `SHELL_TASK: 1` and `SHELL_NEWTMGR` to the `syscfg.vals` parameter to enable serial transport when your application also uses the [Shell](/os/modules/shell/shell.md).
-* Add the `mgmt/newtmgr/transport/nmgr_uart` package to the `pkg.deps` parameter to enable serial transport over a UART port. You can use this package instead of the `nmgr_shell` package when your application does not use the [Shell](/os/modules/shell/shell.md) or you want to use a dedicated UART port to communicate with newtmgr. You can change the `NMGR_UART` and `NMGR_URART_SPEED` sysconfig values to specify a different port.
-
-<br>
-
-#### Oicmgr Framework Options
-
-To use the oicmgr framework instead of the newtmgr framework, modify the `pkg.yml` and `syscfg.yml` files
-as follows:
-
-* Add the `mgmt/oicmgr` package (instead of the `mgmt/newtmgr` and `mgmt/newtmgr/transport` packages
-as described previously) to the `pkg.deps` parameter.
-* Add `OC_SERVER: 1` to the `syscfg.vals` parameter.
-
-Oicmgr supports the IP, serial, and BLE transport protocols. To configure the transport protocols that are supported,
-set the configuration setting values in the `syscfg.vals` parameter as follows:
-
-* Add `OC_TRANSPORT_IP: 1` to enable IP transport.
-* Add `OC_TRANSPORT_GATT: 1` to enable BLE transport.
-* Add `OC_TRANSPORT_SERIAL: 1`, `SHELL_TASK: 1`, `SHELL_NEWTMGR:1` to enable serial transport.
-
-<br>
-
-#### Customize the Newt Manager Commands that Your Application Supports
-
-We recommend that you only enable support for the Newt Manager commands that your application uses
-to reduce your application code size. To configure the commands that are supported, set the configuration
-setting values in the `syscfg.vals` parameter as follows:
-
-
-* Add `LOG_NEWTMGR: 1` to enable support for the `newtmgr log` command.
-* Add `STATS_NEWTMGR: 1` to enable support for the `newtmgr stat` command.
-* Add `CONFIG_NEWTMGR: 1` to enable support for the `newtmgr config` command.
-* Add `CRASH_TEST_NEWTMGR: 1` to enable support for the `newtmgr crash` command.
-* Add `RUNTEST_NEWTMGR: 1` to enable support for the `newtmgr crash` command.
-
-Notes:
-
-* When you enable Newt Manager support, using either the newtmgr or oicmgr framework, your application automatically
-supports the Newt Manager `echo`, `taskstat`, `mpstat`, `datetime`, and `reset` commands. These
-commands cannot be configured individually.
-* The `mgmt/imgmgr` package does not provide a configuration setting to enable or disable support
-for the `newtmgr image` command. Do not specify the package in the `pkg.deps` parameter if
-your device has limited flash memory and cannot support Over-The-Air (OTA) firmware upgrades.
diff --git a/docs/os/tutorials/air_quality_ble.md b/docs/os/tutorials/air_quality_ble.md
deleted file mode 100644
index 5d4c8f2..0000000
--- a/docs/os/tutorials/air_quality_ble.md
+++ /dev/null
@@ -1,223 +0,0 @@
-## Air quality sensor project via Bluetooth
-
-This is a follow-on project to the [Basic Air Quality Sensor](air_quality_sensor.md) project; so it is
-assumed that you have worked through that project and have your CO<sub>2</sub> sensor working properly with
-your Arduino Primo board.
-
-So let's get started making this thing Bluetooth enabled!
-
-### Add Bluetooth GATT Services
-
-Since we already built the previous demo on the [bluetooth peripheral](bleprph/bleprph-app.md) basic
-app most of the bluetooth plumbing has already been taken care of for us. What's left is for us
-to add the required GATT services for advertising the Carbon Dioxide sensor so that
-other devices can get those values.
-
-First, we'll define the GATT Services in `apps/air_quality/src/bleprph.h`.
-
-```c
-/* Sensor Data */
-/* e761d2af-1c15-4fa7-af80-b5729002b340 */
-static const ble_uuid128_t gatt_svr_svc_co2_uuid =
- BLE_UUID128_INIT(0x40, 0xb3, 0x20, 0x90, 0x72, 0xb5, 0x80, 0xaf,
- 0xa7, 0x4f, 0x15, 0x1c, 0xaf, 0xd2, 0x61, 0xe7);
-#define CO2_SNS_TYPE 0xDEAD
-#define CO2_SNS_STRING "SenseAir K30 CO2 Sensor"
-#define CO2_SNS_VAL 0xBEAD
-
-uint16_t gatt_co2_val;
-```
-
-You can use any hex values you choose for the sensor type and sensor values, and you can
-even forget the sensor type and sensor string definitions altogether but they make
-the results look nice in our Bluetooth App for Mac OS X and iOS.
-
-Next we'll add those services to `apps/air_quality/src/gatt_svr.c`.
-
-```c
-static int
-gatt_svr_sns_access(uint16_t conn_handle, uint16_t attr_handle,
- struct ble_gatt_access_ctxt *ctxt,
- void *arg);
-
-static uint16_t gatt_co2_val_len;
-
-```
-
-Make sure it is added as *primary* service.
-
-```c
-static const struct ble_gatt_svc_def gatt_svr_svcs[] = {
- {
- /*** Service: Security test. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid = &gatt_svr_svc_sec_test_uuid.u,
- .characteristics = (struct ble_gatt_chr_def[]) { {
- /*** Characteristic: Random number generator. */
- .uuid = &gatt_svr_chr_sec_test_rand_uuid.u,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ | BLE_GATT_CHR_F_READ_ENC,
- }, {
- /*** Characteristic: Static value. */
- .uuid = &gatt_svr_chr_sec_test_static_uuid,.u
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ |
- BLE_GATT_CHR_F_WRITE | BLE_GATT_CHR_F_WRITE_ENC,
- }, {
- 0, /* No more characteristics in this service. */
- } },
- },
- {
- /*** CO2 Level Notification Service. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid = &gatt_svr_svc_co2_uuid.u,
- .characteristics = (struct ble_gatt_chr_def[]) { {
- .uuid = BLE_UUID16_DECLARE(CO2_SNS_TYPE),
- .access_cb = gatt_svr_sns_access,
- .flags = BLE_GATT_CHR_F_READ,
- }, {
- .uuid = BLE_UUID16_DECLARE(CO2_SNS_VAL),
- .access_cb = gatt_svr_sns_access,
- .flags = BLE_GATT_CHR_F_NOTIFY,
- }, {
- 0, /* No more characteristics in this service. */
- } },
- },
-
- {
- 0, /* No more services. */
- },
- };
-
-```
-
-Next we need to tell the GATT Server how to handle requests for CO<sub>2</sub> readings :
-
-```c
-sstatic int
-gatt_svr_sns_access(uint16_t conn_handle, uint16_t attr_handle,
- struct ble_gatt_access_ctxt *ctxt,
- void *arg)
-{
- uint16_t uuid16;
- int rc;
-
- uuid16 = ble_uuid_u16(ctxt->chr->uuid);
-
- switch (uuid16) {
- case CO2_SNS_TYPE:
- assert(ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR);
- rc = os_mbuf_append(ctxt->om, CO2_SNS_STRING, sizeof CO2_SNS_STRING);
- BLEPRPH_LOG(INFO, "CO2 SENSOR TYPE READ: %s\n", CO2_SNS_STRING);
- return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
-
- case CO2_SNS_VAL:
- if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
- rc = gatt_svr_chr_write(ctxt->om, 0,
- sizeof gatt_co2_val,
- &gatt_co2_val,
- &gatt_co2_val_len);
- return rc;
- } else if (ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR) {
- rc = os_mbuf_append(ctxt->om, &gatt_co2_val,
- sizeof gatt_co2_val);
- return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
- }
-
- default:
- assert(0);
- return BLE_ATT_ERR_UNLIKELY;
- }
-}
-```
-
-Now it's time to go into our `apps/air_quality/src/main.c` and change how we read CO<sub>2</sub> readings and
-respond to requests.
-
-We'll need a task handler with an event queue for the CO<sub>2</sub> readings -- they were handled by the shell task in the previous tutorial but now it needs to be replaced by a different handler as shown below.
-
-```c
-/* CO2 Task settings */
-#define CO2_TASK_PRIO 5
-#define CO2_STACK_SIZE (OS_STACK_ALIGN(336))
-struct os_eventq co2_evq;
-struct os_task co2_task;
-bssnz_t os_stack_t co2_stack[CO2_STACK_SIZE];
-```
-
-And of course we'll need to go to our `main()` and do all the standard task and event setup we
-normally do by adding the following. Again, remember to delete all the shell event queues and tasks.
-
-```c
-/* Initialize sensor eventq */
-os_eventq_init(&co2_evq);
-
-/* Create the CO2 reader task.
- * All sensor reading operations are performed in this task.
- */
-os_task_init(&co2_task, "sensor", co2_task_handler,
- NULL, CO2_TASK_PRIO, OS_WAIT_FOREVER,
- co2_stack, CO2_STACK_SIZE);
-
-```
-
-We'll also need to add a task handler -- since we initialized it above:
-
-```c
-/**
- * Event loop for the sensor task.
- */
-static void
-co2_task_handler(void *unused)
-{
- while (1) {
- co2_read_event();
- /* Wait 2 second */
- os_time_delay(OS_TICKS_PER_SEC * 2);
-
- }
-}
-```
-
-And finally, we'll take care of that `co2_read_event()` function:
-
-```c
-int
-co2_read_event(void)
-{
- int value;
- enum senseair_read_type type = SENSEAIR_CO2;
- uint16_t chr_val_handle;
- int rc;
-
- value = senseair_read(type);
- if (value >= 0) {
- console_printf("Got %d\n", value);
- } else {
- console_printf("Error while reading: %d\n", value);
- goto err;
- }
- gatt_co2_val = value;
- rc = ble_gatts_find_chr(&gatt_svr_svc_co2_uuid.u, BLE_UUID16_DECLARE(CO2_SNS_VAL), NULL, &chr_val_handle);
- assert(rc == 0);
- ble_gatts_chr_updated(chr_val_handle);
- return (0);
-err:
- return (rc);
-}
-```
-
-You'll notice that it looks eeirily similar to a portion of the shell event we created
-earlier. This one simply reads and updates the CO<sub>2</sub> value and sends that over BLE to any
-connected clients instead.
-
-We can now build, create-image and load the app onto our Arduino Primo board, and then
-connect and see the updated values! The image below shows the results using MyNewt Sensor Reader,
-a Mac OS X app developed for connecting to MyNewt devices over Bluetooth but you can also use LightBlue
-or any other application that can connect to, and read, Bluetooth data.
-
-
-
-Congratulations!!
-
-
diff --git a/docs/os/tutorials/air_quality_sensor.md b/docs/os/tutorials/air_quality_sensor.md
deleted file mode 100644
index 64291de..0000000
--- a/docs/os/tutorials/air_quality_sensor.md
+++ /dev/null
@@ -1,863 +0,0 @@
-## Air quality sensor project
-
-### Setting up source tree for stuff you need
-
-To start with, you need to create a new project under which you will do this development. So you type in:
-
-```no-highlight
- $ mkdir $HOME/src
- $ cd $HOME/src
- $ newt new air_quality
-```
-
-Let's say you are using Arduino Primo -- which is based on the Nordic Semi NRF52 chip -- as the platform.
-You know you need the board support package for that hardware. You can look up its location, add it your
-project, and fetch that along with the core OS components. Luckily, the Arduino Primo is supported in the
-Mynewt Core, so there's nothing much to do here.
-
-Your project.yml file should look like this:
-
-```no-highlight
- [user@IsMyLaptop:~/src/air_quality]$ emacs project.yml &
- [user@IsMyLaptop:~/src/air_quality]$ cat project.yml
- project.name: "air_quality"
-
- project.repositories:
- - apache-mynewt-core
-
- # Use github's distribution mechanism for core ASF libraries.
- # This provides mirroring automatically for us.
- #
- repository.apache-mynewt-core:
- type: github
- vers: 0-latest
- user: apache
- repo: mynewt-core
-
- [user@IsMyLaptop:~/src/air_quality]$ newt install
- apache-mynewt-core
- [user@IsMyLaptop:~/src/air_quality]$ ls repos/
- apache-mynewt-core
-```
-
-Good. You want to make sure you have all the needed bits for supporting your board;
-so you decide to build the blinky project for the platform first.
-
-Now create a target for it and build it. Easiest way to proceed is to copy the existing target for blinky, and modify it to build for Arduino Primo board.
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ newt target copy my_blinky_sim blink_primo
-Target successfully copied; targets/my_blinky_sim --> targets/blink_primo
-[user@IsMyLaptop:~/src/air_quality]$ newt target set blink_primo bsp=@apache-mynewt-core/hw/bsp/arduino_primo_nrf52
-Target targets/blink_nrf successfully set target.bsp to @apache-mynewt-core/hw/bsp/arduino_primo_nrf52
-[user@IsMyLaptop:~/src/air_quality]$ newt build blink_primo
-Compiling hal_bsp.c
-...
-Linking blinky.elf
-App successfully built: /Users/user/src/air_quality/bin/blink_primo/apps/blinky/blinky.elf
-```
-
-Good.
-
-You know that this platform uses bootloader, which means you have to create a target for that too.
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ newt target create boot_primo
-Target targets/boot_nrf successfully created
-[user@IsMyLaptop:~/src/air_quality]$ newt target show
-@apache-mynewt-core/targets/unittest
- bsp=hw/bsp/native
- build_profile=debug
- compiler=compiler/sim
-targets/blink_primo
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/arduino_primo_nrf52
- build_profile=debug
-targets/boot_primo
-targets/my_blinky_sim
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/native
- build_profile=debug
-[user@IsMyLaptop:~/src/air_quality]$ newt target set boot_primo bsp=@apache-mynewt-core/hw/bsp/arduino_primo_nrf52
-Target targets/boot_nrf successfully set target.bsp to @apache-mynewt-core/hw/bsp/arduino_primo_nrf52
-[user@IsMyLaptop:~/src/air_quality]$ newt target set boot_primo app=@apache-mynewt-core/apps/boot
-Target targets/boot_nrf successfully set target.app to @apache-mynewt-core/apps/boot
-[user@IsMyLaptop:~/src/air_quality]$ newt target set boot_primo build_profile=optimized
-Target targets/boot_nrf successfully set target.build_profile to optimized
-```
-
-And then build it, and load it onto the board.
-```no-highlight
-newt build boot_primo
-....
-Linking boot.elf
-App successfully built: /Users/user/src/air_quality/bin/boot_primo/apps/boot/boot.elf
-[user@IsMyLaptop:~/src/air_quality]
-$ newt load boot_primo
-```
-
-At this point, you may (or may not) see a bunch of error messages about not being able to connect to
-your board, not being able to load the image, etc. If that's the case, and you haven't already, you
-should most definitely go worth through the [blinky_primo](blinky_primo.md) tutorial so that you
-can properly communicate with your board.
-
-Next you must download the targets to board, and see that the LED actually blinks. You plug in the
-Arduino Primo board to your laptop, and say:
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ newt load blink_primo
-Loading app image into slot 1
-Error: couldn't open /Users/user/src/air_quality/bin/blink_primo/apps/blinky/blinky.img
-
-Error: exit status 1
-
-load - Load app image to target for <target-name>.
-
-Usage:
- newt load [flags]
-
-Examples:
- newt load <target-name>
-
-
-Global Flags:
- -l, --loglevel string Log level, defaults to WARN. (default "WARN")
- -o, --outfile string Filename to tee log output to
- -q, --quiet Be quiet; only display error output.
- -s, --silent Be silent; don't output anything.
- -v, --verbose Enable verbose output when executing commands.
-exit status 1
-```
-
-Ah. Forgot to create an image out of the blinky binary. Note that every time you want to build and
-load a new firmware image to a target board, you need to run 'create-image' on it.
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ newt create-image blink_primo 0.0.1
-App image successfully generated: /Users/user/src/air_quality/bin/blink_primo/apps/blinky/blinky.img
-Build manifest: /Users/user/src/air_quality/bin/blink_nrf/apps/blinky/manifest.json
-[user@IsMyLaptop:~/src/air_quality]$ newt load blink_primo
-```
-
-And it's blinking.
-
-Shortcut for doing build/create-image/load/debug steps all in one is 'newt run' command. Check
-out the usage from command line help.
-
-### Create test project
-
-Now that you have your system setup, you can start creating your own stuff.
-First you want to create a project for yourself - you could start by using blinky as a project
-template, but since we're going to want to be able to access the data via Bluetooth, let's
-use the `bleprph` Bluetooth Peripheral project instead.
-
-```no-highlight
- [user@IsMyLaptop:~/src/air_quality]$ mkdir apps/air_quality
- [user@IsMyLaptop:~/src/air_quality]$ cp repos/apache-mynewt-core/apps/bleprph/pkg.yml apps/air_quality/
- [user@IsMyLaptop:~/src/air_quality]$ cp -Rp repos/apache-mynewt-core/apps/bleprph/src apps/air_quality/
-```
-
-Then you modify the apps/air_quality/pkg.yml for air_quality in order to change the *pkg.name* to be *apps/air_quality*.
-You'll need to add the `@apache-mynewt-core/` path to all the package dependencies, since the app no longer
-resides within the apache-mynewt-core repository.
-
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ cat apps/air_quality/pkg.yml
-pkg.name: apps/air_quality
-pkg.type: app
-pkg.description: BLE Air Quality application.
-pkg.author: "Apache Mynewt <dev@mynewt.apache.org>"
-pkg.homepage: "http://mynewt.apache.org/"
-pkg.keywords:
-
-pkg.deps:
- - "@apache-mynewt-core/kernel/os"
- - "@apache-mynewt-core/sys/shell"
- - "@apache-mynewt-core/sys/stats/full"
- - "@apache-mynewt-core/sys/log/full"
- - "@apache-mynewt-core/mgmt/newtmgr"
- - "@apache-mynewt-core/mgmt/newtmgr/transport/ble"
- - "@apache-mynewt-core/net/nimble/controller"
- - "@apache-mynewt-core/net/nimble/host"
- - "@apache-mynewt-core/net/nimble/host/services/ans"
- - "@apache-mynewt-core/net/nimble/host/services/gap"
- - "@apache-mynewt-core/net/nimble/host/services/gatt"
- - "@apache-mynewt-core/net/nimble/host/store/ram"
- - "@apache-mynewt-core/net/nimble/transport/ram"
- - "@apache-mynewt-core/sys/console/full"
- - "@apache-mynewt-core/sys/sysinit"
- - "@apache-mynewt-core/sys/id"
-```
-
-And create a target for it:
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ newt target create air_q
-Target targets/air_q successfully created
-[user@IsMyLaptop:~/src/air_quality]$ newt target set air_q bsp=@apache-mynewt-core/hw/bsp/arduino_primo_nrf52
-Target targets/air_q successfully set target.bsp to @apache-mynewt-core/hw/bsp/arduino_primo_nrf52
-[user@IsMyLaptop:~/src/air_quality]$ newt target set air_q app=apps/air_quality
-Target targets/air_q successfully set target.app to apps/air_quality
-[user@IsMyLaptop:~/src/air_quality]$ newt target set air_q build_profile=debug
-Target targets/air_q successfully set target.build_profile to debug
-[user@IsMyLaptop:~/src/air_quality]$ newt build air_q
- ....
-Linking /Users/dsimmons/dev/myproj/bin/targets/air_q/app/apps/air_quality/air_quality.elf
-Target successfully built: targets/air_q
-```
-
-### Create packages for drivers
-
-One of the sensors you want to enable is SenseAir K30, which will connect to the board over a serial port.
-To start development of the driver, you first need to create a package description for it, and add stubs for sources.
-
-The first thing to do is to create the directory structure for your driver:
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ mkdir -p libs/my_drivers/senseair/include/senseair
-[user@IsMyLaptop:~/src/air_quality]$ mkdir -p libs/my_drivers/senseair/src
-```
-
-Now you can add the files you need. You'll need a pkg.yml to describe the driver, and then header stub followed by source stub.
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ cat libs/my_drivers/senseair/pkg.yml
-```
-
-```c
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
-pkg.name: libs/my_drivers/senseair
-pkg.description: Host side of the nimble Bluetooth Smart stack.
-pkg.author: "Apache Mynewt <dev@mynewt.apache.org>"
-pkg.homepage: "http://mynewt.apache.org/"
-pkg.keywords:
- - ble
- - bluetooth
-
-pkg.deps:
- - "@apache-mynewt-core/kernel/os"
-```
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ cat libs/my_drivers/senseair/include/senseair/senseair.h
-```
-
-```c
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied. See the License for the
- * specific language governing permissions and limitations
- * under the License.
-*/
-#ifndef _SENSEAIR_H_
-#define _SENSEAIR_H_
-
-void senseair_init(void);
-
-#endif /* _SENSEAIR_H_ */
-```
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ cat libs/my_drivers/senseair/src/senseair.c
-```
-
-```c
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied. See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-
-void
-senseair_init(void)
-{
-}
-```
-
-And add dependency to this package in your project yml file.
-
-Here's the listing from apps/air_quality/pkg.yml
-
-```no-highlight
-pkg.name: apps/air_quality
-pkg.type: app
-pkg.description: Air quality sensor test
-pkg.keywords:
-
-pkg.deps:
- - "@apache-mynewt-core/libs/console/full"
- - "@apache-mynewt-core/libs/newtmgr"
- - "@apache-mynewt-core/libs/os"
- - "@apache-mynewt-core/libs/shell"
- - "@apache-mynewt-core/sys/config"
- - "@apache-mynewt-core/sys/log/full"
- - "@apache-mynewt-core/sys/stats/full"
- - libs/my_drivers/senseair
-```
-
-And add a call to your main() to initialize this driver.
-
-```no-highlight
- [user@IsMyLaptop:~/src/air_quality]$ diff project/blinky/src/main.c project/air_quality/src/main.c
- 28a29
- > #include <senseair/senseair.h>
- 190a192
- > senseair_init();
- [user@IsMyLaptop:~/src/air_quality
-```
-
-The ble_prph app runs everything in one task handler. For this project, we're going to add a second
-task handler to respond to the shell, and then handle communicating with the senseair sensor for us.
-
-```c
-/** shell task settings. */
-#define SHELL_TASK_PRIO 2
-#define SHELL_STACK_SIZE (OS_STACK_ALIGN(336))
-
-struct os_eventq shell_evq;
-struct os_task shell_task;
-bssnz_t os_stack_t shell_stack[SHELL_STACK_SIZE];
-```
-That defines the task, now we need to initialize it, add a task handler, and we're going to
-use this task as our default task handler.
-
-```c
-/**
- * Event loop for the main shell task.
- */
-static void
-shell_task_handler(void *unused)
-{
- while (1) {
- os_eventq_run(&shell_evq);
- }
-}
-```
-And in your `main()` add:
-
-```c
- /* Initialize shell eventq */
- os_eventq_init(&shell_evq);
-
- /* Create the shell task.
- * All shell operations are performed in this task.
- */
- os_task_init(&shell_task, "shell", shell_task_handler,
- NULL, SHELL_TASK_PRIO, OS_WAIT_FOREVER,
- shell_stack, SHELL_STACK_SIZE);
-```
-Don't forget to change your default task handler!
-
-```c
- os_eventq_dflt_set(&shell_evq);
-```
-
-And then build it to make sure all goes well.
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ newt build air_q
-Compiling senseair.c
-Archiving senseair.a
-Linking air_quality.elf
-App successfully built: /Users/user/src/air_quality/bin/air_q/apps/air_quality/air_quality.elf
-```
-
-All looks good.
-
-### Add CLI commands for testing drivers
-
-While developing the driver, you want to issue operations from console asking it to do stuff. We'll assume that you've already worked through the tutorial
-on how to [enable the CLI](blinky_console.md), so all we'll need to do is add the propper values to the project's `syscfg.yml` file:
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ cat targets/air_q/syscfg.yml
-syscfg.vals:
- # Set as per blinky_primo
- OPENOCD_DEBUG: 1
- # Enable the shell task.
- SHELL_TASK: 1
- STATS_CLI: 1
- CONSOLE_TICKS: 1
- CONSOLE_PROMPT: 1
-```
-
-Then register your senseair command with the shell by adding the following to `libs/my_drivers/senseair/src/senseair.c`
-
-```c
-#include <syscfg/syscfg.h>
-#include <shell/shell.h>
-#include <console/console.h>
-#include <assert.h>
-
-
-static int senseair_shell_func(int argc, char **argv);
-static struct shell_cmd senseair_cmd = {
- .sc_cmd = "senseair",
- .sc_cmd_func = senseair_shell_func,
-};
-
-void
-senseair_init(void)
-{
- int rc;
-
- rc = shell_cmd_register(&senseair_cmd);
- assert(rc == 0);
-}
-
-static int
-senseair_shell_func(int argc, char **argv)
-{
- console_printf("Yay! Somebody called!\n");
- return 0;
-
-}
-```
-
-Now you can you build this, download to target, and start minicom on your console port. If you haven't already, familiarize yourself with
-the tutorial on how to connect a serial port to your board [here](../get_started/serial_access.md).
-
-You'll need to wire up your Board to a Serial converter first. On the Arduino Primo Board pin 1 is TX and pin 0 is RX so wire 1 to RX on your serial board, and 0 to TX on your serial board.
-
-```no-highlight
- [user@IsMyLaptop:~]$ minicom -D /dev/tty.usbserial-AH02MIE2
-
-
- Welcome to minicom 2.7
-
- OPTIONS:
- Compiled on Oct 12 2015, 07:48:30.
- Port /dev/tty.usbserial-AH02MIE2, 13:44:40
-
- Press CTRL-X Z for help on special keys
-
- ?
- 419: > ?
- Commands:
- 641: stat echo ? prompt ticks tasks
- 643: mempools date senseair
- 644: > senseair
- Yay! Somebody called!
- 1125: >
- 53611: > tasks
- Tasks:
- 54047: task pri tid runtime csw stksz stkuse lcheck ncheck flg
- 54057: idle 255 0 54048 66890 64 30 0 0 0
- 54068: ble_ll 0 1 9 64986 80 58 0 0 0
- 54079: bleprph 1 2 0 1 336 32 0 0 0
- 54090: shell 2 3 0 2077 336 262 0 0 0
- 54101: >
-```
-
-That's great. Your shell task is running, and is responding appropriately!
-You can connect the hardware to your board and start developing code for the driver itself.
-
-### Use of HAL for drivers
-
-The sensor has a serial port connection, and that's how you are going to connect to it. Your original BSP, hw/bsp/arduino_primo_nrf52, has two UARTs set up.
-We're using one for our shell/console. It also has a second UART set up as a 'bit-bang' UART but since the SenseAir only needs to
-communicate at 9600 baud, this bit-banged uart is plenty fast enough.
-
-You'll have to make a small change to the `syscfg.yml` file in your project's target directory to change the pin definitions
-for this second UART. Those changes are as follows:
-
-```no-highlight
- UART_0_PIN_TX: 23
- UART_0_PIN_RX: 24
-```
-
-With this in place, you can refer to serial port where your SenseAir sensor by a logical number. This makes the code more platform independent - you could connect this sensor to another board, like Olimex. You will also use the HAL UART abstraction to do the UART port setup and data transfer. That way you don't need to have any platform dependent pieces within your little driver.
-
-You will now see what the driver code ends up looking like. Here's the header file, filled in from the stub you created earlier.
-
-```c
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied. See the License for the
- * specific language governing permissions and limitations
- * under the License.
-*/
-#ifndef _SENSEAIR_H_
-#define _SENSEAIR_H_
-
-enum senseair_read_type {
- SENSEAIR_CO2,
-};
-
-int senseair_init(int uartno);
-
-int senseair_read(enum senseair_read_type);
-
-#endif /* _SENSEAIR_H_ */
-```
-
-As you can see, logical UART number has been added to the init routine. A 'read' function has been added,
-which is a blocking read. If you were making a commercial product, you would probably have a callback for reporting the results.
-
-
-And here is the source for the driver.
-
-```c
-/**
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied. See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-#include <string.h>
-
-#include <shell/shell.h>
-#include <console/console.h>
-#include <os/os.h>
-
-#include <hal/hal_uart.h>
-
-#include "senseair/senseair.h"
-
-static const uint8_t cmd_read_co2[] = {
- 0xFE, 0X44, 0X00, 0X08, 0X02, 0X9F, 0X25
-};
-
-static int senseair_shell_func(int argc, char **argv);
-static struct shell_cmd senseair_cmd = {
- .sc_cmd = "senseair",
- .sc_cmd_func = senseair_shell_func,
-};
-
-struct senseair {
- int uart;
- struct os_sem sema;
- const uint8_t *tx_data;
- int tx_off;
- int tx_len;
- uint8_t rx_data[32];
- int rx_off;
- int value;
-} senseair;
-
-static int
-senseair_tx_char(void *arg)
-{
- struct senseair *s = &senseair;
- int rc;
-
- if (s->tx_off >= s->tx_len) {
- /*
- * Command tx finished.
- */
- s->tx_data = NULL;
- return -1;
- }
-
- rc = s->tx_data[s->tx_off];
- s->tx_off++;
- return rc;
-}
-
-/*
- * CRC for modbus over serial port.
- */
-static const uint16_t mb_crc_tbl[] = {
- 0x0000, 0xcc01, 0xd801, 0x1400, 0xf001, 0x3c00, 0x2800, 0xe401,
- 0xa001, 0x6c00, 0x7800, 0xb401, 0x5000, 0x9c01, 0x8801, 0x4400
-};
-
-static uint16_t
-mb_crc(const uint8_t *data, int len, uint16_t crc)
-{
- while (len-- > 0) {
- crc ^= *data++;
- crc = (crc >> 4) ^ mb_crc_tbl[crc & 0xf];
- crc = (crc >> 4) ^ mb_crc_tbl[crc & 0xf];
- }
- return crc;
-}
-
-static int
-mb_crc_check(const void *pkt, int len)
-{
- uint16_t crc, cmp;
- uint8_t *bp = (uint8_t *)pkt;
-
- if (len < sizeof(crc) + 1) {
- return -1;
- }
- crc = mb_crc(pkt, len - 2, 0xffff);
- cmp = bp[len - 2] | (bp[len - 1] << 8);
- if (crc != cmp) {
- return -1;
- } else {
- return 0;
- }
-}
-
-static int
-senseair_rx_char(void *arg, uint8_t data)
-{
- struct senseair *s = (struct senseair *)arg;
- int rc;
-
- if (s->rx_off >= sizeof(s->rx_data)) {
- s->rx_off = 0;
- }
- s->rx_data[s->rx_off] = data;
- s->rx_off++;
-
- if (s->rx_off == 7) {
- rc = mb_crc_check(s->rx_data, s->rx_off);
- if (rc == 0) {
- s->value = s->rx_data[3] * 256 + s->rx_data[4];
- os_sem_release(&s->sema);
- }
- }
- return 0;
-}
-
-void
-senseair_tx(struct senseair *s, const uint8_t *tx_data, int data_len)
-{
- s->tx_data = tx_data;
- s->tx_len = data_len;
- s->tx_off = 0;
- s->rx_off = 0;
-
- hal_uart_start_tx(s->uart);
-}
-
-int
-senseair_read(enum senseair_read_type type)
-{
- struct senseair *s = &senseair;
- const uint8_t *cmd;
- int cmd_len;
- int rc;
-
- if (s->tx_data) {
- /*
- * busy
- */
- return -1;
- }
- switch (type) {
- case SENSEAIR_CO2:
- cmd = cmd_read_co2;
- cmd_len = sizeof(cmd_read_co2);
- break;
- default:
- return -1;
- }
- senseair_tx(s, cmd, cmd_len);
- rc = os_sem_pend(&s->sema, OS_TICKS_PER_SEC / 2);
- if (rc == OS_TIMEOUT) {
- /*
- * timeout
- */
- return -2;
- }
- return s->value;
-}
-
-static int
-senseair_shell_func(int argc, char **argv)
-{
- int value;
- enum senseair_read_type type;
-
- if (argc < 2) {
-usage:
- console_printf("%s co2\n", argv[0]);
- return 0;
- }
- if (!strcmp(argv[1], "co2")) {
- type = SENSEAIR_CO2;
- } else {
- goto usage;
- }
- value = senseair_read(type);
- if (value >= 0) {
- console_printf("Got %d\n", value);
- } else {
- console_printf("Error while reading: %d\n", value);
- }
- return 0;
-}
-
-int
-senseair_init(int uartno)
-{
- int rc;
- struct senseair *s = &senseair;
-
- rc = shell_cmd_register(&senseair_cmd);
- if (rc) {
- return rc;
- }
-
- rc = os_sem_init(&s->sema, 1);
- if (rc) {
- return rc;
- }
- rc = hal_uart_init_cbs(uartno, senseair_tx_char, NULL,
- senseair_rx_char, &senseair);
- if (rc) {
- return rc;
- }
- rc = hal_uart_config(uartno, 9600, 8, 1, HAL_UART_PARITY_NONE,
- HAL_UART_FLOW_CTL_NONE);
- if (rc) {
- return rc;
- }
- s->uart = uartno;
-
- return 0;
-}
-```
-
-And your modified main() for senseair driver init.
-
-```c
-int
-main(int argc, char **argv)
-{
- ....
- senseair_init(0);
- ....
- }
-```
-
-You can see from the code that you are using the HAL interface to open a UART port, and using OS
-semaphore as a way of blocking the task when waiting for read response to come back from the sensor.
-
-Now comes the fun part: Hooking up the sensor! It's fun because a) hooking up a sensor is always
-fun and b) the SenseAir sensor's PCB is entirely unlabeled, so you'll have to trust us on how to hook it up.
-
-So here we go.
-
-You'll have to do a little soldering. I soldered some header pins to the SenseAir K30 board to
-make connecting wires easier using standard jumper wires, but you can also just solder wires
-straight to the board if you prefer.
-
-Here's what your SenseAir board should look like once it's wired up:
-
-
-
-Now that you have that wired up, let's get the Arduino Primo wired up. A couple of things to note:
-
-* The Arduino Primo's 'console' UART is actually UART1.
-* The secondary (bit-banged) UART is UART0, so that's where we'll have to hook up the SenseAir.
-
-Here's what your Arduino Primo should now look like with everything wired in:
-
-
-
-Everything is wired and you're ready to go! Build and load your new app:
-
-```no-highlight
-$ newt build air_q
-Building target targets/air_q
-Compiling apps/air_quality/src/main.c
-Archiving apps_air_quality.a
-Linking myproj/bin/targets/air_q/app/apps/air_quality/air_quality.elf
-Target successfully built: targets/air_q
-$ newt create-image air_q 1.0.0
-App image succesfully generated: myproj/bin/targets/air_q/app/apps/air_quality/air_quality.img
-$ newt load air_q
-Loading app image into slot 1
-```
-
-Now, you should be able to connect to your serial port and read values:
-
-```
-user@IsMyLaptop:~]$ minicom -D /dev/tty.usbserial-AH02MIE2
-
-
- Welcome to minicom 2.7
-
- OPTIONS:
- Compiled on Oct 12 2015, 07:48:30.
- Port /dev/tty.usbserial-AH02MIE2, 13:44:40
-
- Press CTRL-X Z for help on special keys
-
- 1185: > ?
- Commands:
- 1382: stat echo ? prompt ticks tasks
- 1390: mempools date senseair
- 1395: > senseair
- senseair co2
- 2143: > senseair co2
- Got 973
-
-```
-
-And you're getting valid readings! Congratulations!
-
-Next we'll hook this all up via Bluetooth so that you can read those values remotely.
-
-
diff --git a/docs/os/tutorials/arduino_zero.md b/docs/os/tutorials/arduino_zero.md
deleted file mode 100644
index fdb1333..0000000
--- a/docs/os/tutorials/arduino_zero.md
+++ /dev/null
@@ -1,349 +0,0 @@
-## Blinky, your "Hello World!", on Arduino Zero
-
-This tutorial shows you how to create, build and run the Blinky application on an Arduino Zero board.
-
-### Prerequisites
-* Meet the prerequisites listed in [Project Blinky](/os/tutorials/blinky.md).
-* Have an Arduino Zero board.
-Note: There are many flavors of Arduino. Make sure you are using an Arduino Zero. See below for the versions of Arduino Zero that are compatible with this tutorial.
-* Install the [OpenOCD debugger](/os/get_started/cross_tools/).
-
-This tutorial uses the Arduino Zero Pro board. The tutorial has been tested on the following three Arduino Zero boards - Zero, M0 Pro, and Zero-Pro.
-
-<img src="https://www.arduino.cc/en/uploads/Main/Zero_Usb_Ports.jpg" alt="Drawing" style="width: 390px;"/>
-<img src="http://www.arduino.org/images/products/Arduino-M0Pro-flat.jpg" alt="Drawing" style="width: 310px;"/>
-<img src="http://www.arduino.org//images/products/ArduinoZeroPro-flat-org.jpg" alt="Drawing" style="width: 310px;"/>
-
-Mynewt has not been tested on Arduino M0 which has no internal debugger support.
-
-<br>
-
-### Create a Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [fetch external packages](#fetchexternal) if you already created a project.
-
-Run the following commands to create a new project:
-
-```no-highlight
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new myproj
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in myproj...
- Project myproj successfully created.
- $ cd myproj
- $ newt install
- apache-mynewt-core
- $
-```
-
-<br>
-
-### <a name="fetchexternal"></a> Fetch External Packages
-
-Mynewt uses source code provided directly from the chip manufacturer for
-low level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's github repository hosts such external third-party packages and the newt tool can fetch them.
-
-To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add
-the repository to the `project.yml` file in your base project directory.
-
-Here is an example ```project.yml``` file with the Arduino Zero repository
-added. The sections with ```mynewt_arduino_zero``` that need to be added to
-your project file are highlighted.
-
-**Note:** On Windows platforms: You need to set `vers` to `0-dev` and use the latest master branch for both repositories.
-
-```hl_lines="6 14 15 16 17 18"
-$ more project.yml
-project.name: "my_project"
-
-project.repositories:
- - apache-mynewt-core
- - mynewt_arduino_zero
-
-repository.apache-mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: mynewt-core
-
-repository.mynewt_arduino_zero:
- type: github
- vers: 1-latest
- user: runtimeco
- repo: mynewt_arduino_zero
-$
-```
-
-<br>
-Install the project dependencies using the `newt install` command (you can specify ```-v``` for verbose output):
-```no-highlight
-$ newt install
-apache-mynewt-core
-mynewt_arduino_zero
-$
-```
-
-<br>
-
-**NOTE:** If there has been a new release of a repo used in your project since you last installed it, the `1-latest` version for the repo in the `project.yml` file will refer to the new release and will not match the installed files. In that case you will get an error message saying so and you will need to run `newt upgrade` to overwrite the existing files with the latest codebase.
-
-<br>
-You need to create two targets for the Arduino Zero Pro board, one for the bootloader and one for the Blinky application.
-<br>
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `arduino_boot`.
-
-```no-highlight
-$ newt target create arduino_boot
-$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
-$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot
-$ newt target set arduino_boot build_profile=optimized
-Target targets/arduino_boot successfully set target.build_profile to optimized
-$ newt target set arduino_boot syscfg=BSP_ARDUINO_ZERO_PRO=1
-Target targets/arduino_boot successfully set target.syscfg to BSP_ARDUINO_ZERO_PRO=1
-$
-```
-**Note:** If you have an Arduino Zero instead of an Arduino Zero Pro or Arduino M0 Pro board, replace `BSP_ARDUINO_ZERO_PRO` with `BSP_ARDUINO_ZERO` in the last `newt target set` command.
-
-These commands perform the following:
-
-* Create a target named ```arduino_boot``` for the Arduino Zero Bootloader.
-* Set the application for the ```arduino_boot``` target to the default Apache Mynewt
- bootloader (```@apache-mynewt-core/apps/boot```)
-* Set the board support package for the target to
- ```@mynewt_arduino_zero/hw/bsp/arduino_zero```. This is a reference to the downloaded
- Arduino Zero support from Github.
-* Use the "optimized" build profile for the `arduino_boot` target. This
- instructs Newt to generate smaller and more efficient code for this target.
- This setting is necessary due to the bootloader's strict size constraints.
-* Sets the system configuration setting for Board Support Package to support the Arduino Zero Pro.
-
-See the [Concepts](../get_started/vocabulary.md) section for more information on setting options.
-<br>
-###Create a Target for the Blinky Application
-Run the following `newt target` commands to create the Blinky application target. We name the application target `arduino_blinky`.
-
-```no-highlight
-$ newt target create arduino_blinky
-Target targets/arduino_blinky successfully created
-$ newt target set arduino_blinky app=apps/blinky
-Target targets/arduino_blinky successfully set target.app to apps/blinky
-$ newt target set arduino_blinky bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
-Target targets/arduino_blinky successfully set target.bsp to @mynewt_arduino_zero/hw/bsp/arduino_zero
-$ newt target set arduino_blinky build_profile=debug
-Target targets/arduino_blinky successfully set target.build_profile to debug
-$ newt target set arduino_blinky syscfg=BSP_ARDUINO_ZERO_PRO=1
-Target targets/arduino_boot successfully set target.syscfg to BSP_ARDUINO_ZERO_PRO=1
-$
-```
-**Note:** If you have an Arduino Zero instead of a Arduino Zero Pro board, replace `BSP_ARDUINO_ZERO_PRO` with `BSP_ARDUINO_ZERO` in the last `newt target set` command.
-
-<br>
-
-
-### Build the Bootloader
-
-Run the `newt build arduino_boot` command to build the bootloader:
-
-```no-highlight
-$ newt build arduino_boot
-Building target targets/arduino_boot
-Compiling bin/targets/arduino_boot/generated/src/arduino_boot-sysinit-app.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling bin/targets/arduino_boot/generated/src/arduino_boot-sysflash.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/arc4.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
-
- ....
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/arduino_boot/app/apps/boot/boot.elf
-Target successfully built: targets/arduino_boot
-
-```
-<br>
-
-
-### Build the Blinky Application
-
-Run the `newt build arduino_blinky` command to build the Blinky application image:
-
-```no-highlight
-$ newt build arduino_blinky
-Building target targets/arduino_blinky
-Compiling repos/apache-mynewt-core/hw/hal/src/hal_flash.c
-Compiling apps/blinky/src/main.c
-Compiling repos/mynewt_arduino_zero/hw/mcu/atmel/samd21xx/src/sam0/drivers/i2s/i2s.c
-Compiling repos/mynewt_arduino_zero/hw/bsp/arduino_zero/src/hal_bsp.c
-Compiling repos/mynewt_arduino_zero/hw/mcu/atmel/samd21xx/src/sam0/drivers/i2s/i2s_callback.c
-Compiling repos/mynewt_arduino_zero/hw/mcu/atmel/samd21xx/src/sam0/drivers/nvm/nvm.c
-
- ...
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/arduino_blinky/app/apps/blinky/blinky.elf
-Target successfully built: targets/arduino_blinky
-```
-<br>
-### Connect to the Board
-
-Connect your computer to the Arduino Zero (from now on we'll call this the
-target) with a Micro-USB cable through the Programming Port as shown below.
-Mynewt will load the image onto the board and debug the target through this port. You should see a
-green LED come on that indicates the board has power.
-
-No external debugger is required. The Arduino Zero comes with an internal
-debugger that can be accessed by Mynewt.
-
-The images below show the Arduino Zero Programming Port.
-
-<img src="https://www.arduino.cc/en/uploads/Main/Zero_Usb_Ports.jpg" alt="Drawing" style="width: 400px;"/>
-<img src="http://www.arduino.org//images/products/ArduinoZeroPro-flat-org.jpg" alt="Drawing" style="width: 330px;"/>
-
-<br>
-
-### Load the Bootloader onto the Board
-
-Run the `newt load arduino_boot` command to load the bootloader onto the board:
-
-```no-highlight
-$ newt load arduino_boot
-Loading bootloader
-$
-```
-The bootloader is loaded onto your board succesfully when the `newt load` command returns to the command prompt after the `Loading bootloader` status message. You can proceed to load and run your Blinky application image (See [Run the Blinky Application](#runimage)).
-
-If the `newt load` command outputs the following error messages, you will need to erase the board.
-
-```
-$ newt load arduino_boot -v
-Loading bootloader
-Error: Downloading ~/dev/myproj/bin/targets/arduino_boot/app/apps/boot/boot.elf.bin to 0x0
-Open On-Chip Debugger 0.9.0 (2015-11-15-05:39)
-Licensed under GNU GPL v2
-For bug reports, read
- http://openocd.org/doc/doxygen/bugs.html
-Info : only one transport option; autoselect 'swd'
-adapter speed: 500 kHz
-adapter_nsrst_delay: 100
-cortex_m reset_config sysresetreq
-Info : CMSIS-DAP: SWD Supported
-Info : CMSIS-DAP: JTAG Supported
-Info : CMSIS-DAP: Interface Initialised (SWD)
-Info : CMSIS-DAP: FW Version = 01.1F.0118
-Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
-Info : CMSIS-DAP: Interface ready
-Info : clock speed 500 kHz
-Info : SWD IDCODE 0x0bc11477
-Info : at91samd21g18.cpu: hardware has 4 breakpoints, 2 watchpoints
-Error: Target not halted
-```
-<br>
-To erase your board, start a debug session and enter the highlighted commands at the `(gdb)` prompts:
-
-**Note:** On Windows, openocd and gdb are started in separate Windows Command Prompt terminals, and the terminals are automatically closed when you quit gdb. In addition, the output of openocd is logged to the openocd.log file in your project's base directory instead of the terminal.
-
-```hl_lines="2, 5, 14"
-$ newt debug arduino_blinky
-(gdb) mon at91samd chip-erase
-chip erased
-chip erased
-(gdb) x/32wx 0
-0x0: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
-0x10: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
-0x20: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
-0x30: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
-0x40: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
-0x50: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
-0x60: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
-0x70: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
-(gdb) q
-```
-<br>
-Run the `newt load arduino_boot` command again after erasing the board.
-
-<font color="#FF0000"> Reminder if you are using Docker: </font> When working with actual hardware, remember that each board has an ID. If you swap boards and do not refresh the USB Device Filter on the VirtualBox UI, the ID might be stale and the Docker instance may not be able to see the board correctly. For example, you may see an error message like `Error: unable to find CMSIS-DAP device` when you try to load or run an image on the board. In that case, you need to click on the USB link in VirtualBox UI, remove the existing USB Device Filter (e.g. "Atmel Corp. EDBG CMSIS-DAP[0101]") by clicking on the "Removes selected USB filter" button, and add a new filter by clicking on the "Adds new USB filter" button.
-
-<br>
-
-### <a name="runimage"></a>Run the Blinky Application
-
-After you load the bootloader successfully onto your board, you can load and run the Blinky application.
-
-Run the `newt run arduino_blinky 1.0.0` command to build the arduino_blinky target (if necessary), create an image with version 1.0.0, load the image onto the board, and start a debugger session.
-
-**Note** The output of the debug session below is for Mac OS and Linux platforms. On Windows, openocd and gdb are started in separate Windows Command Prompt terminals. The output of openocd is logged to the openocd.log file in your project's base directory and not to the terminal. The openocd and gdb terminals will close automatically when you quit gdb.
-<br>
-```no-highlight
-$ newt run arduino_blinky 1.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/arduino_blinky/app/apps/blinky/blinky.img
-Loading app image into slot 1
-[~/dev/myproj/repos/mynewt_arduino_zero/hw/bsp/arduino_zero/arduino_zero_debug.sh ~/dev/myproj/repos/mynewt_arduino_zero/hw/bsp/arduino_zero ~/dev/myproj/bin/targets/arduino_blinky/app/apps/blinky/blinky]
-Open On-Chip Debugger 0.9.0 (2015-11-15-13:10)
-Licensed under GNU GPL v2
-For bug reports, read
-http://openocd.org/doc/doxygen/bugs.html
-Info : only one transport option; autoselect 'swd'
-adapter speed: 500 kHz
-adapter_nsrst_delay: 100
-cortex_m reset_config sysresetreq
-Info : CMSIS-DAP: SWD Supported
-Info : CMSIS-DAP: JTAG Supported
-Info : CMSIS-DAP: Interface Initialised (SWD)
-Info : CMSIS-DAP: FW Version = 01.1F.0118
-Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
-Info : CMSIS-DAP: Interface ready
-Info : clock speed 500 kHz
-Info : SWD IDCODE 0x0bc11477
-Info : at91samd21g18.cpu: hardware has 4 breakpoints, 2 watchpoints
-target state: halted
-target halted due to debug-request, current mode: Thread
-xPSR: 0x21000000 pc: 0x0000fca6 psp: 0x20002408
-GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
-Copyright (C) 2014 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law. Type "show copying"
-and "show warranty" for details.
-This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
-Type "show configuration" for configuration details.
-For bug reporting instructions, please see:
-<http://www.gnu.org/software/gdb/bugs/>.
-Find the GDB manual and other documentation resources online at:
-<http://www.gnu.org/software/gdb/documentation/>.
-For help, type "help".
-Type "apropos word" to search for commands related to "word"...
-Reading symbols from ~/dev/myproj/bin/targets/arduino_blinky/app/apps/blinky/blinky.elf...(no debugging symbols found)...done.
-Info : accepting 'gdb' connection on tcp/3333
-Info : SAMD MCU: SAMD21G18A (256KB Flash, 32KB RAM)
-0x0000fca6 in os_tick_idle ()
-target state: halted
-target halted due to debug-request, current mode: Thread
-xPSR: 0x21000000 pc: 0x000000b8 msp: 0x20008000
-target state: halted
-target halted due to debug-request, current mode: Thread
-xPSR: 0x21000000 pc: 0x000000b8 msp: 0x20008000
-(gdb) r
-The "remote" target does not support "run". Try "help target" or "continue".
-(gdb) c
-Continuing.
-```
-
-<br>
-
-**NOTE:** The 1.0.0 is the version number to assign to the image. You may assign an arbitrary version number. If you are not providing remote upgrade, and are just developing locally, you can provide 1.0.0 for every image version.
-
-If you want the image to run without the debugger connected, simply quit the
-debugger and restart the board. The image you programmed will come and run on the Arduino on next boot!
-
-<br>
-You should see the LED blink!
diff --git a/docs/os/tutorials/ble_bare_bones.md b/docs/os/tutorials/ble_bare_bones.md
deleted file mode 100644
index 418929d..0000000
--- a/docs/os/tutorials/ble_bare_bones.md
+++ /dev/null
@@ -1,185 +0,0 @@
-## Set up a bare bones NimBLE application
-
-This tutorial explains how to set up a minimal application using the NimBLE
-stack. This tutorial assumes that you have already installed the newt tool and are familiar with its concepts.
-
-### Create a Mynewt project
-
-We start by creating a project space for your own application work using the
-Newt tool. We will call our project `my_proj`.
-
-```
-~/dev$ newt new my_proj1
-Downloading project skeleton from apache/mynewt-blinky...
-Installing skeleton in my_proj1...
-Project my_proj1 successfully created.
-```
-
-The above command created the following directory tree:
-```
-~/dev$ tree my_proj1
-my_proj1
-├── DISCLAIMER
-├── LICENSE
-├── NOTICE
-├── README.md
-├── apps
-│ └── blinky
-│ ├── pkg.yml
-│ └── src
-│ └── main.c
-├── project.yml
-└── targets
- ├── my_blinky_sim
- │ ├── pkg.yml
- │ └── target.yml
- └── unittest
- ├── pkg.yml
- └── target.yml
-
-6 directories, 11 files
-```
-
-Next, we need to retrieve the Mynewt repositories that our app will depend on.
-When you retrieve a repository, your project gains access to the libraries and
-applications that the repo contains.
-
-A new project automatically depends on the Apache Mynewt core repo
-(`apache-mynewt-core`). The core repo contains the Apache Mynewt operating
-system, NimBLE stack, and other system libraries. Later, our app may need
-packages from additional repos, but for now the core repo suits our needs.
-
-We download the dependent repos using the `newt install` command:
-```
-~/dev$ cd my_proj1
-~/dev/my_proj1$ newt install
-apache-mynewt-core
-```
-
-Now it's time to create your own app.
-
-### Create an application package
-
-```no-highlight
-~/dev/my_proj1$ newt pkg new apps/ble_app -t app
-Download package template for package type app.
-Package successfully installed into /home/me/dev/my_proj1/apps/ble_app.
-```
-
-You now have an application called `apps/ble_app`. It isn't terribly
-interesting as far as applications go, but it does all the configuration and
-set up required of a Mynewt app. It will be a useful starting point for our
-BLE application.
-
-### Create the target
-
-Now you have to create the target that ties your application to a BSP. We will
-call this target "ble\_tgt".
-
-```no-highlight
-~/dev/my_proj1$ newt target create ble_tgt
-Target targets/ble_tgt successfully created
-```
-
-We now have a new target:
-
-```
-~/dev/my_proj1]$ tree targets/ble_tgt
-targets/ble_tgt
-├── pkg.yml
-└── target.yml
-```
-
-We need to fill out a few details in our target before it is usable. At a
-minimum, a target must specify three bits of information:
-
-* Application pacakge
-* BSP package
-* Build profile
-
-The application package is straightforward; this is the ble_app package that we
-created in the previous step.
-
-For the BSP package, this tutorial chooses to target the nRF52dk BSP. If you
-would like to use a different platform, substitute the name of the appropriate
-BSP package in the command below.
-
-Finally, the build profile specifies the set of compiler and linker options to
-use during the build. Apache Mynewt supports two build profiles: `debug` and
-`optimized`.
-
-```no-highlight
-~/dev/my_proj1$ newt target set ble_tgt \
- app=apps/ble_app \
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk \
- build_profile=optimized
-Target targets/ble_tgt successfully set target.app to apps/ble_app
-Target targets/ble_tgt successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52dk
-Target targets/ble_tgt successfully set target.build_profile to optimized
-```
-
-### Enter BLE
-
-Since our application will support BLE functionality, we need to give it access
-to a BLE stack. We do this by adding the necessary NimBLE packages to the
-app's dependency list. To enable a combined host-controller in the app, add
-dependencies for the NimBLE controller, host, in-RAM transport, and persistence store to `apps/ble_app/pkg.yml`:
-
-```hl_lines="6 7 8"
-pkg.deps:
- - "@apache-mynewt-core/kernel/os"
- - "@apache-mynewt-core/sys/console/full"
- - "@apache-mynewt-core/sys/log/full"
- - "@apache-mynewt-core/sys/stats/full"
- - "@apache-mynewt-core/net/nimble/controller"
- - "@apache-mynewt-core/net/nimble/host"
- - "@apache-mynewt-core/net/nimble/host/store/config"
- - "@apache-mynewt-core/net/nimble/transport/ram"
-```
-
-**Important note:** The controller package affects system configuration, see
-[this page](../../../network/ble/ble_setup/ble_lp_clock/) for details.
-
-### Build the target
-
-Now would be a good time for a basic sanity check. Let's make sure the target builds.
-
-```
-~/dev/my_proj1$ newt build ble_tgt
-Building target targets/ble_tgt
-Compiling repos/apache-mynewt-core/hw/hal/src/hal_common.c
-Compiling repos/apache-mynewt-core/hw/drivers/uart/src/uart.c
-<...snip...>
-Linking /home/me/dev/my_proj1/bin/targets/ble_tgt/app/apps/ble_app/ble_app.elf
-Target successfully built: targets/ble_tgt
-```
-
-Now let's try running our minimal application on actual hardware. Attach the target device to your computer and run the application with `newt run`:
-
-```
-~/dev/my_proj1$ newt run ble_tgt 0
-App image succesfully generated: /home/me/dev/my_proj1/bin/targets/ble_tgt/app/apps/ble_app/ble_app.img
-<...snip...>
-Resetting target
-[Switching to Thread 57005]
-0x000000dc in ?? ()
-(gdb)
-```
-
-You can start the application by pressing `c <enter>` at the gdb prompt. When the excitement of watching the idle loop run wears off, quit gdb with `<ctrl-c> q <enter>`.
-
-If your target fails to build or run, you might want to revisit the [project
-blinky tutorial](../../../os/tutorials/blinky/) to see if there is a setup
-step you missed. You may also find help by posting a question to the [mailing
-list](../../community.md) or searching the archives.
-
-### Conclusion
-
-You now have a fully functional BLE app (never mind that it doesn't actually do
-anything yet!). With all the necessary infrastructure in place, you can now
-start turning this into a real application. A good next step would be to turn
-your app into a beaconing device. The
-[BLE iBeacon tutorial](../../../os/tutorials/ibeacon/) builds on this one and
-ends with a functioning iBeacon. For something a little more ambitious, the
-[BLE peripheral project tutorial](../../../os/tutorials/bleprph/bleprph-intro/)
-describes a NimBLE peripheral application in detail.
diff --git a/docs/os/tutorials/blehci_project.md b/docs/os/tutorials/blehci_project.md
deleted file mode 100644
index fd95691..0000000
--- a/docs/os/tutorials/blehci_project.md
+++ /dev/null
@@ -1,205 +0,0 @@
-## Use HCI access to NimBLE controller
-
-<br>
-
-This tutorial explains how to use the example application `blehci` included in the NimBLE stack to talk to the Mynewt NimBLE controller via the Host Controller Interface. You may build the Mynewt image using a laptop running any OS of your choice - Mac, Linux, or Windows.
-
-The host used in this specific example is the BlueZ Bluetooth stack. Since BlueZ is a Bluetooth stack for Linux kernel-based family of operating system, the tutorial expects a computer running Linux OS and with BlueZ installed to talk to the board with the Mynewt image.
-
-<br>
-
-### Prerequisites
-Ensure that you meet the following prerequisites before continuing with one of the tutorials.
-
-* Have Internet connectivity to fetch remote Mynewt components.
-* Have a board with BLE radio that is supported by Mynewt. We will use an nRF52 Dev board in this tutorial.
-* Have a USB TTL Serial Cable that supports hardware flow control such as ones found at [http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm](http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm) to establish a serial USB connection between the board and the laptop.
-* Install the newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
-* Install a BLE host such as BlueZ on a Linux machine to talk to the nrf52 board running Mynewt. Use `sudo apt-get install bluez` to install it on your Linux machine.
-
-<br>
-
-### Create a project
-
-Use the newt tool to create a new project directory containing a skeletal Mynewt framework. Change into the newly created directory.
-
-```
-$ newt new blehciproj
-Downloading project skeleton from apache/mynewt-blinky...
-Installing skeleton in blehciproj ...
-Project blehciproj successfully created.
-$ cd mblehciproj
-
-$ newt install
-apache-mynewt-core
-```
-
-<br>
-
-### Create targets
-
-You will create two targets - one for the bootloader, the other for the application. Then you will add the definitions for them. Note that you are using the example app `blehci` for the application target. Set the bsp to nrf52dk.
-
-**NOTE:** The preview version, nrf52pdk, is no longer supported. If you do not see PCA100040 on the top of your board, you have a preview version of the board and will need to upgrade your developer board before continuing.
-
-```
-$ newt target create nrf52_boot
-$ newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
-$ newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set nrf52_boot build_profile=optimized
-```
-```
-$ newt target create myble2
-$ newt target set myble2 bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set myble2 app=@apache-mynewt-core/apps/blehci
-$ newt target set myble2 build_profile=optimized
-```
-
-<br>
-
-Check that the targets are defined correctly.
-
-
-```
-$ newt target show
- targets/my_blinky_sim
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/native
- build_profile=debug
- targets/myble2
- app=@apache-mynewt-core/apps/blehci
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
- build_profile=optimized
- targets/nrf52_boot
- app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
- build_profile=optimized
-```
-
-<br>
-
-### Build targets
-
-Then build the two targets.
-
-```no-highlight
-$ newt build nrf52_boot
-<snip>
-Linking ~/dev/blehciproj/bin/targets/nrf52_boot/app/apps/boot/boot.elf
-Target successfully built: targets/nrf52_boot
-
-$ newt build myble2
-<snip>
-Linking ~/dev/blehciproj/bin/targets/myble2/app/apps/blehci/blehci.elf
-Target successfully built: targets/myble2
-$
-```
-
-
-<br>
-
-### Create the app image
-
-Generate a signed application image for the `myble2` target. The version number is arbitrary.
-
-```no-highlight
-$ newt create-image myble2 1.0.0
-App image succesfully generated: ~/dev/blehciproj/bin/targets/myble2/app/apps/blehci/blehci.img
-```
-
-<br>
-
-### Load the bootloader and the application image
-
-Make sure the USB connector is in place and the power LED on the board is lit. Use the Power ON/OFF switch to reset the board after loading the image.
-
-Load the bootloader:
-
-```no-highlight
-$ newt load nrf52_boot
-Loading bootloader
-$
-```
-<br>
-Load the application image:
-```no-highlight
-$ newt load myble2
-Loading app image into slot 1
-$
-```
-
-<br>
-
-### Establish serial connection
-
-Attach a serial port to your board by connecting the USB TTL Serial Cable. This should create /dev/ttyUSB0 (or similar) on your machine.
-
-**Note** Certain Linux OS versions have been observed to detect the nrf52 board as a mass storage device and the console access doesn’t work properly. In that case try powering the nrf52 board from your monitor or something other than your Linux computer/laptop when you set up the serial port for HCI communication.
-
-<br>
-
-### Open Bluetooth monitor btmon
-
-`btmon` is a BlueZ test tool to display all HCI commands and events in a human readable format. Start the btmon tool in a terminal window.
-
-```
-$ sudo btmon
-[sudo] password for admin:
-Bluetooth monitor ver 5.37
-```
-
-<br>
-
-### Attach the blehci device to BlueZ
-
-In a different terminal, attach the blehci device to the BlueZ daemon (substitute the correct /dev filename for ttyUSB0).
-
-```
-$ sudo btattach -B /dev/ttyUSB0 -S 1000000
-Attaching BR/EDR controller to /dev/ttyUSB0
-Switched line discipline from 0 to 15
-Device index 1 attached
-```
-
-The baud rate used to connect to the controller may be changed by overriding the default value of 1000000 in the `net/nimble/transport/uart/syscfg.yml`. Settings in the serial transport `syscfg.yml` file can be overridden by a higher priority package such as the application. So, for example, you may set the `BLE_HCI_UART_BAUD` to a different value in `apps/blehci/syscfg.yml`.
-
-If there is no CTS/RTS lines present in the test environment, flow control should be turned off. This can be done with
--N option for btattach. **Note:** -N option came with BlueZ ver 5.44.
-
-<br>
-
-### Start btmgmt to send commands
-
-In a third terminal, start btmgmt. This tool allows you to send commands to the blehci controller. Use the index number that shows up when you `btattach` in the previous step.
-
-```
-$ sudo btmgmt --index 1
-[sudo] password for admin:
-```
-
-Set your device address (you can substitute any static random address here).
-
-```
-[hci1]# static-addr cc:11:11:11:11:11
-Static address successfully set
-```
-
-Initialize the controller.
-
-```
-[hci1]# power on
-hci1 Set Powered complete, settings: powered le static-addr
-```
-
-Begin scanning.
-
-```
-[hci1]# find -l
-Discovery started
-hci1 type 6 discovering on
-hci1 dev_found: 58:EF:77:C8:8D:17 type LE Random rssi -78 flags 0x0000
-AD flags 0x06
-eir_len 23
-<snip>
-```
-
diff --git a/docs/os/tutorials/bleprph/bleprph-adv.md b/docs/os/tutorials/bleprph/bleprph-adv.md
deleted file mode 100644
index ac4f3bd..0000000
--- a/docs/os/tutorials/bleprph/bleprph-adv.md
+++ /dev/null
@@ -1,150 +0,0 @@
-## BLE Peripheral Project
-
-### Advertising
-
-<br>
-
-#### Overview
-
-
-A peripheral announces its presence to the world by broadcasting
-advertisements. An advertisement typically contains additional information
-about the peripheral sending it, such as the device name and an abbreviated
-list of supported services. The presence of this information helps a listening
-central to determine whether it is interested in connecting to the peripheral.
-Advertisements are quite limited in the amount of information they can contain,
-so only the most important information should be included.
-
-When a listening device receives an advertisement, it can choose to connect to
-the peripheral, or query the sender for more information. This second action
-is known as an *active scan*. A peripheral responds to an active scan with
-some extra information that it couldn't fit in its advertisement. This
-additional information is known as *scan response data*. *bleprph* does not
-configure any scan response data, so this feature is not discussed in the
-remainder of this tutorial.
-
-*bleprph* constantly broadcasts advertisements until a central connects to it.
-When a connection is terminated, *bleprph* resumes advertising.
-
-Let's take a look at *bleprph*'s advertisement code (*main.c*):
-
-<br>
-
-```c
-/**
- * Enables advertising with the following parameters:
- * o General discoverable mode.
- * o Undirected connectable mode.
- */
-static void
-bleprph_advertise(void)
-{
- struct ble_hs_adv_fields fields;
- int rc;
-
- /* Set the advertisement data included in our advertisements. */
- memset(&fields, 0, sizeof fields);
- fields.name = (uint8_t *)bleprph_device_name;
- fields.name_len = strlen(bleprph_device_name);
- fields.name_is_complete = 1;
- rc = ble_gap_adv_set_fields(&fields);
- if (rc != 0) {
- BLEPRPH_LOG(ERROR, "error setting advertisement data; rc=%d\n", rc);
- return;
- }
-
- /* Begin advertising. */
- rc = ble_gap_adv_start(BLE_GAP_DISC_MODE_GEN, BLE_GAP_CONN_MODE_UND,
- NULL, 0, NULL, bleprph_on_connect, NULL);
- if (rc != 0) {
- BLEPRPH_LOG(ERROR, "error enabling advertisement; rc=%d\n", rc);
- return;
- }
-}
-```
-
-Now let's examine this code in detail.
-
-<br>
-
-#### Setting advertisement data
-
-
-A NimBLE peripheral specifies what information to include in its advertisements with the following function:
-
-<br>
-
-```c
-int
-ble_gap_adv_set_fields(struct ble_hs_adv_fields *adv_fields)
-```
-
-<br>
-
-The *adv_fields* argument specifies the fields and their contents to include in
-subsequent advertisements. The Bluetooth [Core Specification
-Supplement](https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=302735)
-defines a set of standard fields that can be included in an advertisement; the
-member variables of the *struct ble_hs_adv_fields* type correspond to these
-standard fields. Information that doesn't fit neatly into a standard field
-should be put in the *manufacturing specific data* field.
-
-As you can see in the above code listing, the `struct ble_hs_adv_fields`
-instance is allocated on the stack. It is OK to use the stack for this struct
-and the data it references, as the `ble_gap_adv_set_fields()`
-function makes a copy of all the advertisement data before it returns.
-*bleprph* doesn't take full advantange of this; it stores its device name in a
-static array.
-
-The code sets three members of the *struct ble_hs_adv_fields* instance:
-
-* name
-* name\_len
-* name\_is\_complete
-
-The first two fields are used to communicate the device's name and are quite
-straight-forward. The third field requires some explanation. Bluetooth
-specifies two name-related advertisement fields: *Shortened Local Name* and
-*Complete Local Name*. Setting the `name_is_complete` variable to 1 or 0 tells
-NimBLE which of these two fields to include in advertisements. Some other
-advertisement fields also correspond to multiple variables in the field struct,
-so it is a good idea to review the *ble\_hs\_adv\_fields* reference to
-make sure you get the details right in your app.
-
-<br>
-
-#### Begin advertising
-
-
-An app starts advertising with the following function:
-
-<br>
-
-```c
-int
-ble_gap_adv_start(uint8_t discoverable_mode, uint8_t connectable_mode,
- uint8_t *peer_addr, uint8_t peer_addr_type,
- struct hci_adv_params *adv_params,
- ble_gap_conn_fn *cb, void *cb_arg)
-```
-
-This function allows a lot of flexibility, and it might seem daunting at first
-glance. *bleprph* specifies a simple set of arguments that is appropriate for
-most peripherals. When getting started on a typical peripheral, we recommend
-you use the same arguments as *bleprph*, with the exception of the last two
-(*cb* and *cb_arg*). These last two arguments will be specific to your app, so
-let's talk about them.
-
-*cb* is a callback function. It gets executed when a central connects to your
-peripheral after receiving an advertisement. The *cb_arg* argument gets passed
-to the *cb* callback. If your callback doesn't need the *cb_arg* parameter,
-you can do what *bleprph* does and pass *NULL*. Once a connection is
-established, the *cb* callback becomes permanently associated with the
-connection. All subsequent events related to the connection are communicated
-to your app via calls to this callback function. Connection callbacks are an
-important part of building a BLE app, and we examine *bleprph*'s connection
-callback in detail in the next section of this tutorial.
-
-<br>
-
-**One final note:** Your peripheral automatically stops advertising when a central connects to it. You can immediately resume advertising if you want to allow another central to connect, but you will need to do so explicitly by calling `ble_gap_adv_start()` again. Also, be aware NimBLE's default configuration only allows a single connection at a time. NimBLE supports multiple concurrent connections, but you must configure it to do so first.
diff --git a/docs/os/tutorials/bleprph/bleprph-app.md b/docs/os/tutorials/bleprph/bleprph-app.md
deleted file mode 100644
index 0cc3be5..0000000
--- a/docs/os/tutorials/bleprph/bleprph-app.md
+++ /dev/null
@@ -1,107 +0,0 @@
-## BLE Peripheral Project
-
-### Overview
-
-<br>
-
-Now that we've gone through how BLE Apps are contructed, how they function, and how all the parts fit together
-let's try out a BLE Peripheral App to see how it all works.
-
-<br>
-
-### Prerequisites
-
-<br>
-
-* You should have a BLE Central App of some sort to connect with. On Mac OS or iOS, you can use [LightBlue](https://itunes.apple.com/us/app/lightblue-explorer-bluetooth/id557428110?mt=8)
-which is a free app to browse and connect to BLE Peripheral devices.
-
-<br>
-
-### Create a New Target
-
-You can create a new project instead, but this tutorial will simply use the previously created btshell project and add a new target for the BLE Peripheral
-
-```no-highlight
-$ newt target create myperiph
-Target targets/myperiph successfully created
-$ newt target set myperiph bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-Target targets/myperiph successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set myperiph app=@apache-mynewt-core/apps/bleprph
-Target targets/myperiph successfully set target.app to @apache-mynewt-core/apps/bleprph
-$ newt target set myperiph build_profile=optimized
-Target targets/myperiph successfully set target.build_profile to optimized
-$ newt build myperiph
-Building target targets/myperiph
-...
-Linking ~/dev/nrf52dk/bin/targets/myperiph/app/apps/bleprph/bleprph.elf
-Target successfully built: targets/myperiph
-$ newt create-image myperiph 1.0.0
-App image succesfully generated: ~/dev/nrf52dk/bin/targets/myperiph/app/apps/bleprph/bleprph.img
-$ newt load myperiph
-Loading app image into slot 1
-```
-
-Now if you reset the board, and fire up your BLE Central App, you should see a new peripheral device called 'nimble-bleprph'.
-
-<br>
-
-
-
-<br>
-
-Now that you can see the device, you can begin to interact with the advertised service.
-
-Click on the device and you'll establish a connection.
-
-<br>
-
-
-
-<br>
-
-Now that you're connected, you can see the Services that are being advertised.
-
-Scroll to the bottom and you will see a Read Characteristic, and a Read/Write Characteristic.
-
-
-
-<br>
-
-Just click on the Read Write Characteristic and you will see the existing value.
-
-
-
-<br>
-
-Type in a new value.
-
-
-
-<br>
-
-And you will see the new value reflected.
-
-
-
-<br>
-
-If you still have your console connected, you will be able to see the connection requests, and pairing,
-happen on the device as well.
-
-<br>
-
-```hl_lines="1"
-258894:[ts=2022609336ssb, mod=64 level=1] connection established; status=0 handle=1 our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0 our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=1 peer_ota_addr=7f:be:d4:44:c0:d4 peer_id_addr_type=1 peer_id_addr=7f:be:d4:44:c0:d4 conn_itvl=24 conn_latency=0 supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
-258904:[ts=2022687456ssb, mod=64 level=1]
-258917:[ts=2022789012ssb, mod=64 level=1] mtu update event; conn_handle=1 cid=4 mtu=185
-258925:[ts=2022851508ssb, mod=64 level=1] subscribe event; conn_handle=1 attr_handle=14 reason=1 prevn=0 curn=0 previ=0 curi=1
-261486:[ts=2042859320ssb, mod=64 level=1] encryption change event; status=0 handle=1 our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0 our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=1 peer_ota_addr=7f:be:d4:44:c0:d4 peer_id_addr_type=1 peer_id_addr=7f:be:d4:44:c0:d4 conn_itvl=24 conn_latency=0 supervision_timeout=72 encrypted=1 authenticated=0 bonded=1
-261496:[ts=2042937440ssb, mod=64 level=1]
-```
-
-<br>
-
-Congratulations! You've just built and connected your first BLE Peripheral device!
-
-
diff --git a/docs/os/tutorials/bleprph/bleprph-chr-access.md b/docs/os/tutorials/bleprph/bleprph-chr-access.md
deleted file mode 100644
index 3865e12..0000000
--- a/docs/os/tutorials/bleprph/bleprph-chr-access.md
+++ /dev/null
@@ -1,248 +0,0 @@
-## BLE Peripheral Project
-
-### Characteristic Access
-
-<br>
-
-#### Review
-
-A characteristic's access callback implements its behavior. Recall that
-services and characteristics are registered with NimBLE via attribute tables.
-Each characteristic definition in an attribute table contains an *access_cb*
-field. The *access_cb* field is an application callback that gets executed
-whenever a peer device attempts to read or write the characteristic.
-
-Earlier in this tutorial, we looked at how *bleprph* implements the GAP
-service. Let's take another look at how *bleprph* specifies the first few
-characteristics in this service.
-
-<br>
-
-```c
-static const struct ble_gatt_svc_def gatt_svr_svcs[] = {
- {
- /*** Service: GAP. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid128 = BLE_UUID16(BLE_GAP_SVC_UUID16),
- .characteristics = (struct ble_gatt_chr_def[]) { {
- /*** Characteristic: Device Name. */
- .uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_DEVICE_NAME),
- .access_cb = gatt_svr_chr_access_gap,
- .flags = BLE_GATT_CHR_F_READ,
- }, {
- /*** Characteristic: Appearance. */
- .uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_APPEARANCE),
- .access_cb = gatt_svr_chr_access_gap,
- .flags = BLE_GATT_CHR_F_READ,
- }, {
- // [...]
-```
-
-As you can see, *bleprph* uses the same *access_cb* function for all the GAP
-service characteristics, but the developer could have implemented separate
-functions for each characteristic if they preferred. Here is the *access_cb*
-function that the GAP service characteristics use:
-
-<br>
-
-```c
-static int
-gatt_svr_chr_access_gap(uint16_t conn_handle, uint16_t attr_handle, uint8_t op,
- union ble_gatt_access_ctxt *ctxt, void *arg)
-{
- uint16_t uuid16;
-
- uuid16 = ble_uuid_128_to_16(ctxt->chr_access.chr->uuid128);
- assert(uuid16 != 0);
-
- switch (uuid16) {
- case BLE_GAP_CHR_UUID16_DEVICE_NAME:
- assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
- ctxt->chr_access.data = (void *)bleprph_device_name;
- ctxt->chr_access.len = strlen(bleprph_device_name);
- break;
-
- case BLE_GAP_CHR_UUID16_APPEARANCE:
- assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
- ctxt->chr_access.data = (void *)&bleprph_appearance;
- ctxt->chr_access.len = sizeof bleprph_appearance;
- break;
-
- case BLE_GAP_CHR_UUID16_PERIPH_PRIV_FLAG:
- assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
- ctxt->chr_access.data = (void *)&bleprph_privacy_flag;
- ctxt->chr_access.len = sizeof bleprph_privacy_flag;
- break;
-
- case BLE_GAP_CHR_UUID16_RECONNECT_ADDR:
- assert(op == BLE_GATT_ACCESS_OP_WRITE_CHR);
- if (ctxt->chr_access.len != sizeof bleprph_reconnect_addr) {
- return BLE_ATT_ERR_INVALID_ATTR_VALUE_LEN;
- }
- memcpy(bleprph_reconnect_addr, ctxt->chr_access.data,
- sizeof bleprph_reconnect_addr);
- break;
-
- case BLE_GAP_CHR_UUID16_PERIPH_PREF_CONN_PARAMS:
- assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
- ctxt->chr_access.data = (void *)&bleprph_pref_conn_params;
- ctxt->chr_access.len = sizeof bleprph_pref_conn_params;
- break;
-
- default:
- assert(0);
- break;
- }
-
- return 0;
-}
-```
-
-After you've taken a moment to examine the structure of this function, let's explore some details.
-
-<br>
-
-#### Function signature
-
-<br>
-
-```c
-static int
-gatt_svr_chr_access_gap(uint16_t conn_handle, uint16_t attr_handle, uint8_t op,
- union ble_gatt_access_ctxt *ctxt, void *arg)
-```
-
-A characteristic access function always takes this same set of parameters and
-always returns an int. The parameters to this function type are documented
-below.
-
-<br>
-
-| **Parameter** | **Purpose** | **Notes** |
-| ------------- | ----------- | --------- |
-| conn_handle | Indicates which connection the characteristic access was sent over. | Use this value to determine which peer is accessing the characteristic. |
-| attr_handle | The low-level ATT handle of the characteristic value attribute. | Can be used to determine which characteristic is being accessed if you don't want to perform a UUID lookup. |
-| op | Indicates whether this is a read or write operation | Valid values are:<br>*BLE_GATT_ACCESS_OP_READ_CHR*<br>*BLE_GATT_ACCESS_OP_WRITE_CHR* |
-| ctxt | Contains the characteristic value pointer that the application needs to access. | For characteristic accesses, use the *ctxt->chr_access* member; for descriptor accesses, use the *ctxt->dsc_access* member. |
-
-The return value of the access function tells the NimBLE stack how to respond
-to the peer performing the operation. A value of 0 indicates success. For
-failures, the function returns the specific ATT error code that the NimBLE
-stack should respond with. The ATT error codes are defined in
-[net/nimble/host/include/host/ble_att.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/include/host/ble_att.h).
-
-<br>
-
-#### Determine characteristic being accessed
-
-<br>
-
-```c
-{
- uint16_t uuid16;
-
- uuid16 = ble_uuid_128_to_16(ctxt->chr_access.chr->uuid128);
- assert(uuid16 != 0);
-
- switch (uuid16) {
- // [...]
-```
-
-This function uses the UUID to determine which characteristic is being
-accessed. There are two alternative methods *bleprph* could have used to
-accomplish this task:
-
-* Map characteristics to ATT handles during service registration; use the *attr_handle* parameter as a key into this table during characteristic access.
-* Implement a dedicated function for each characteristic; each function inherently knows which characteristic it corresponds to.
-
-All the GAP service characteristics have 16-bit UUIDs, so this function uses
-the *ble_uuid_128_to_16()* function to convert the 128-bit UUID to its
-corresponding 16-bit UUID. This conversion function returns the corresponding
-16-bit UUID on success, or 0 on failure. Success is asserted here to ensure
-the NimBLE stack is doing its job properly; the stack should only call this
-function for accesses to characteristics that it is registered with, and all
-GAP service characteristics have valid 16-bit UUIDs.
-
-<br>
-
-#### Read access
-
-<br>
-
-```c
- case BLE_GAP_CHR_UUID16_DEVICE_NAME:
- assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
- ctxt->chr_access.data = (void *)bleprph_device_name;
- ctxt->chr_access.len = strlen(bleprph_device_name);
- break;
-```
-
-This code excerpt handles read accesses to the device name characteristic. The
-*assert()* here is another case of making sure the NimBLE stack is doing its
-job; this characteristic was registered as read-only, so the stack should have
-prevented write accesses.
-
-To fulfill a characteristic read request, the application needs to assign the
-*ctxt->chr_access.data* field to point to the attribute data to respond with,
-and fill the *ctxt->chr_access.len* field with the length of the attribute data.
-*bleprph* stores the device name in read-only memory as follows:
-
-<br>
-
-```c
-const char *bleprph_device_name = "nimble-bleprph";
-```
-
-The cast to pointer-to-void is a necessary annoyance to remove the *const*
-qualifier from the device name variable. You will need to "cast away const"
-whenever you respond to read requests with read-only data.
-
-It is not shown in the above snippet, but this function ultimately returns 0.
-By returning 0, *bleprph* indicates that the characteristic data in
-*ctxt->chr_access* is valid and that NimBLE should include it in its response
-to the peer.
-
-<br>
-
-**A word of warning:** The attribute data that *ctxt->chr_access.data* points to
-must remain valid after the access function returns, as the NimBLE stack needs
-to use it to form a GATT read response. In other words, you must not
-allocate the characteristic value data on the stack of the access function.
-Two characteristic accesses never occur at the same time, so it is OK to use
-the same memory for repeated accesses.
-
-<br>
-
-#### Write access
-
-<br>
-
-```c
- case BLE_GAP_CHR_UUID16_RECONNECT_ADDR:
- assert(op == BLE_GATT_ACCESS_OP_WRITE_CHR);
- if (ctxt->chr_access.len != sizeof bleprph_reconnect_addr) {
- return BLE_ATT_ERR_INVALID_ATTR_VALUE_LEN;
- }
- memcpy(bleprph_reconnect_addr, ctxt->chr_access.data,
- sizeof bleprph_reconnect_addr);
- break;
-```
-
-This code excerpt handles writes to the reconnect address characteristic. This
-characteristic was registered as write-only, so the *assert()* here is just a
-safety precaution to ensure the NimBLE stack is doing its job.
-
-For writes, the roles of the *ctxt->chr_access.data* and *ctxt->chr_access.len*
-fields are the reverse of the read case. The NimBLE stack uses these fields to
-indicate the data written by the peer.
-
-Many characteristics have strict length requirements for write operations.
-This characteristic has such a restriction; if the written data is not a 48-bit
-BR address, the application tells NimBLE to respond with an invalid attribute
-value length error.
-
-For writes, the *ctxt->chr_access.data* pointer is only valid for the duration
-of the access function. If the application needs to save the written data, it
-should store it elsewhere before the function returns. In this case, *bleprph*
-stores the specified address in a global variable called
-*bleprph_reconnect_addr*.
diff --git a/docs/os/tutorials/bleprph/bleprph-conn.md b/docs/os/tutorials/bleprph/bleprph-conn.md
deleted file mode 100644
index ffbf7a1..0000000
--- a/docs/os/tutorials/bleprph/bleprph-conn.md
+++ /dev/null
@@ -1,156 +0,0 @@
-## BLE Peripheral Project
-
-### Connection callbacks
-
-<br>
-
-#### Overview
-
-
-Every BLE connection has a *connection callback* associated with it. A
-connection callback is a bit of application code which NimBLE uses to inform
-you of connection-related events. For example, if a connection is terminated,
-NimBLE lets you know about it with a call to that connection's callback.
-
-In the [advertising section](bleprph-adv/) of this tutorial, we saw how the
-application specifies a connection callback when it begins advertising. NimBLE
-uses this callback to notify the application that a central has connected to
-your peripheral after receiving an advertisement. Let's revisit how *bleprph* specifies its connection callback when advertising:
-
-<br>
-
-```c
- /* Begin advertising. */
- rc = ble_gap_adv_start(BLE_GAP_DISC_MODE_GEN, BLE_GAP_CONN_MODE_UND,
- NULL, 0, NULL, bleprph_on_connect, NULL);
- if (rc != 0) {
- BLEPRPH_LOG(ERROR, "error enabling advertisement; rc=%d\n", rc);
- return;
- }
-```
-
-<br>
-
-#### bleprph_on_connect()
-
-
-The `bleprph_on_connect()` function is *bleprph*'s connection callback; NimBLE
-calls this function when the advertising operation leads to connection
-establishment. Upon connecting, this callback becomes permanently associated
-with the connection; all subsequent events related to this connection are
-communicated through this callback.
-
-Now let's look at the function that *bleprph* uses for all its connection
-callbacks: `bleprph_on_connect()`.
-
-
-```c
-static int
-bleprph_on_connect(int event, int status, struct ble_gap_conn_ctxt *ctxt,
- void *arg)
-{
- switch (event) {
- case BLE_GAP_EVENT_CONN:
- BLEPRPH_LOG(INFO, "connection %s; status=%d ",
- status == 0 ? "up" : "down", status);
- bleprph_print_conn_desc(ctxt->desc);
- BLEPRPH_LOG(INFO, "\n");
-
- if (status != 0) {
- /* Connection terminated; resume advertising. */
- bleprph_advertise();
- }
- break;
- }
-
- return 0;
-}
-```
-
-<br>
-
-Connection callbacks are used to communicate a variety of events related to a
-connection. An application determines the type of event that occurred by
-inspecting the value of the *event* parameter. The full list of event codes
-can be found in [net/nimble/host/include/host/ble_gatt.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/include/host/ble_gatt.h).
-*bleprph* only concerns itself with a single event type: *BLE_GAP_EVENT_CONN*.
-This event indicates that a new connection has been established, or an existing
-connection has been terminated; the *status* parameter clarifies which. As you
-can see, *bleprph* uses the *status* parameter to determine if it should resume
-advertising.
-
-The *ctxt* parameter contains additional information about the connection
-event. *bleprph* does nothing more than log some fields of this struct, but
-some apps will likely want to perform further actions, e.g., perform service
-discovery on the connected device. The *struct ble_gap_conn_ctxt* type is
-defined as follows:
-
-```c
-struct ble_gap_conn_ctxt {
- struct ble_gap_conn_desc *desc;
-
- union {
- struct {
- struct ble_gap_upd_params *self_params;
- struct ble_gap_upd_params *peer_params;
- } update;
-
- struct ble_gap_sec_params *sec_params;
- };
-};
-```
-
-<br>
-
-As shown, a connection context object consists of two parts:
-
-* *desc:* The connection descriptor; indicates properties of the connection.
-* *anonymous union:* The contents are event-specific; check the *event* code to determine which member field (if any) is relevant.
-
-For events of type *BLE_GAP_EVENT_CONN*, the anonymous union is not used at all, so the only information carried by the context struct is the connection descriptor. The *struct ble_gap_conn_desc* type is defined as follows:
-
-```c
-struct ble_gap_conn_desc {
- uint8_t peer_addr[6];
- uint16_t conn_handle;
- uint16_t conn_itvl;
- uint16_t conn_latency;
- uint16_t supervision_timeout;
- uint8_t peer_addr_type;
-};
-```
-
-<br>
-
-We will examine these fields in a slightly different order from how they appear
-in the struct definition.
-
-<br>
-
-| *Field* | *Purpose* | *Notes* |
-| ------- | --------- | ------- |
-| peer\_addr | The 48-bit address of the peer device. | |
-| peer\_addr\_type | Whether the peer is using a public or random address. | The address type list is documented in [net/nimble/include/nimble/hci_common.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/include/nimble/hci_common.h). |
-| conn\_handle | The 16-bit handle associated with this connection. | This number is how your app and the NimBLE stack refer to this connection. |
-| conn\_itvl,<br>conn\_latency,<br>supervision\_timeout | Low-level properties of the connection. | |
-
-<br>
-
-#### Guarantees
-
-It is important to know what your application code is allowed to do from within
-a connection callback.
-
-**No restrictions on NimBLE operations**
-
-Your app is free to make calls into the NimBLE stack from within a connection
-callback. *bleprph* takes advantage of this freedom when it resumes
-advertising upon connection termination. All other NimBLE operations are also
-allowed (service discovery, pairing initiation, etc).
-
-**All context data is transient**
-
-Pointers in the context object point to data living on the stack. Your
-callback is free to read (or write, if appropriate) through these pointers, but
-you should not store these pointers for later use. If your application needs
-to retain some data from a context object, it needs to make a copy.
diff --git a/docs/os/tutorials/bleprph/bleprph-gap-event.md b/docs/os/tutorials/bleprph/bleprph-gap-event.md
deleted file mode 100644
index cedf219..0000000
--- a/docs/os/tutorials/bleprph/bleprph-gap-event.md
+++ /dev/null
@@ -1,161 +0,0 @@
-## BLE Peripheral Project
-
-### GAP Event callbacks
-
-<br>
-
-#### Overview
-
-
-Every BLE connection has a *GAP event callback* associated with it. A
-GAP event callback is a bit of application code which NimBLE uses to inform
-you of connection-related events. For example, if a connection is terminated,
-NimBLE lets you know about it with a call to that connection's callback.
-
-In the [advertising section](bleprph-adv/) of this tutorial, we saw how the
-application specifies a GAP event callback when it begins advertising. NimBLE
-uses this callback to notify the application that a central has connected to
-your peripheral after receiving an advertisement. Let's revisit how *bleprph* specifies its connection callback when advertising:
-
-<br>
-
-```c
- /* Begin advertising. */
- memset(&adv_params, 0, sizeof adv_params);
- adv_params.conn_mode = BLE_GAP_CONN_MODE_UND;
- adv_params.disc_mode = BLE_GAP_DISC_MODE_GEN;
- rc = ble_gap_adv_start(BLE_ADDR_TYPE_PUBLIC, 0, NULL, BLE_HS_FOREVER,
- &adv_params, bleprph_gap_event, NULL);
- if (rc != 0) {
- BLEPRPH_LOG(ERROR, "error enabling advertisement; rc=%d\n", rc);
- return;
- }
-```
-
-<br>
-
-#### bleprph_gap_event()
-
-
-The `bleprph_gap_event()` function is *bleprph*'s GAP event callback; NimBLE
-calls this function when the advertising operation leads to connection
-establishment. Upon connection establishment, this callback becomes
-permanently associated with the connection; all subsequent events related to
-this connection are communicated through this callback.
-
-Now let's look at the function that *bleprph* uses for all its connection
-callbacks: `bleprph_gap_event()`.
-
-
-```c
-/**
- * The nimble host executes this callback when a GAP event occurs. The
- * application associates a GAP event callback with each connection that forms.
- * bleprph uses the same callback for all connections.
- *
- * @param event The type of event being signalled.
- * @param ctxt Various information pertaining to the event.
- * @param arg Application-specified argument; unuesd by
- * bleprph.
- *
- * @return 0 if the application successfully handled the
- * event; nonzero on failure. The semantics
- * of the return code is specific to the
- * particular GAP event being signalled.
- */
-static int
-bleprph_gap_event(struct ble_gap_event *event, void *arg)
-{
- struct ble_gap_conn_desc desc;
- int rc;
-
- switch (event->type) {
- case BLE_GAP_EVENT_CONNECT:
- /* A new connection was established or a connection attempt failed. */
- BLEPRPH_LOG(INFO, "connection %s; status=%d ",
- event->connect.status == 0 ? "established" : "failed",
- event->connect.status);
- if (event->connect.status == 0) {
- rc = ble_gap_conn_find(event->connect.conn_handle, &desc);
- assert(rc == 0);
- bleprph_print_conn_desc(&desc);
- }
- BLEPRPH_LOG(INFO, "\n");
-
- if (event->connect.status != 0) {
- /* Connection failed; resume advertising. */
- bleprph_advertise();
- }
- return 0;
-
- case BLE_GAP_EVENT_DISCONNECT:
- BLEPRPH_LOG(INFO, "disconnect; reason=%d ", event->disconnect.reason);
- bleprph_print_conn_desc(&event->disconnect.conn);
- BLEPRPH_LOG(INFO, "\n");
-
- /* Connection terminated; resume advertising. */
- bleprph_advertise();
- return 0;
-
- case BLE_GAP_EVENT_CONN_UPDATE:
- /* The central has updated the connection parameters. */
- BLEPRPH_LOG(INFO, "connection updated; status=%d ",
- event->conn_update.status);
- rc = ble_gap_conn_find(event->connect.conn_handle, &desc);
- assert(rc == 0);
- bleprph_print_conn_desc(&desc);
- BLEPRPH_LOG(INFO, "\n");
- return 0;
-
- case BLE_GAP_EVENT_ENC_CHANGE:
- /* Encryption has been enabled or disabled for this connection. */
- BLEPRPH_LOG(INFO, "encryption change event; status=%d ",
- event->enc_change.status);
- rc = ble_gap_conn_find(event->connect.conn_handle, &desc);
- assert(rc == 0);
- bleprph_print_conn_desc(&desc);
- BLEPRPH_LOG(INFO, "\n");
- return 0;
-
- case BLE_GAP_EVENT_SUBSCRIBE:
- BLEPRPH_LOG(INFO, "subscribe event; conn_handle=%d attr_handle=%d "
- "reason=%d prevn=%d curn=%d previ=%d curi=%d\n",
- event->subscribe.conn_handle,
- event->subscribe.attr_handle,
- event->subscribe.reason,
- event->subscribe.prev_notify,
- event->subscribe.cur_notify,
- event->subscribe.prev_indicate,
- event->subscribe.cur_indicate);
- return 0;
- }
-
- return 0;
-}
-```
-
-<br>
-
-Connection callbacks are used to communicate a variety of events related to a
-connection. An application determines the type of event that occurred by
-inspecting the value of the *event->type* parameter. The full list of event
-codes can be found on the [GAP events](../../../network/ble/ble_hs/ble_gap/definitions/ble_gap_defs/) page.
-
-#### Guarantees
-
-It is important to know what your application code is allowed to do from within
-a connection callback.
-
-**No restrictions on NimBLE operations**
-
-Your app is free to make calls into the NimBLE stack from within a connection
-callback. *bleprph* takes advantage of this freedom when it resumes
-advertising upon connection termination. All other NimBLE operations are also
-allowed (service discovery, pairing initiation, etc).
-
-**All context data is transient**
-
-Pointers in the context object point to data living on the stack. Your
-callback is free to read (or write, if appropriate) through these pointers, but
-you should not store these pointers for later use. If your application needs
-to retain some data from a context object, it needs to make a copy.
diff --git a/docs/os/tutorials/bleprph/bleprph-intro.md b/docs/os/tutorials/bleprph/bleprph-intro.md
deleted file mode 100644
index b555d2f..0000000
--- a/docs/os/tutorials/bleprph/bleprph-intro.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## BLE Peripheral Project
-
-### Introduction
-
-<br>
-
-#### Overview
-
-*bleprph* is an example app included in the apache-mynewt-core repository. This app implements a simple BLE peripheral with the following properties:
-
-* Supports three services: GAP, GATT, and alert notification service (ANS).
-* Supports a single concurrent connection.
-* Automatically advertises connectability when not connected to a central device.
-
-This tutorial aims to provide a guided tour through the *bleprph* app source
-code. This document builds on some concepts described elsewhere in the Apache
-Mynewt documentation. Before proceeding with this tutorial, you might want to
-familiarize yourself with the following pages:
-
-* [Create Your First Mynewt Project](../../get_started/project_create/)
-* [BLE Bare Bones Application Tutorial](../../../os/tutorials/ble_bare_bones/)
-
-<br>
-
-#### Services, Characteristics, Descriptors
-
-A BLE peripheral interfaces with other BLE devices by exposing *services*,
-*characteristics*, and *descriptors*. All three of these entities are
-implemented at a lower layer via *attributes*. If you are not familiar with
-these concepts, you will probably want to check out this
-[overview](https://www.bluetooth.com/specifications/gatt/generic-attributes-overview)
-from the Bluetooth Developer's site before proceeding.
-
-Now let's dig in to some C code.
-<br>
-
diff --git a/docs/os/tutorials/bleprph/bleprph-svc-reg.md b/docs/os/tutorials/bleprph/bleprph-svc-reg.md
deleted file mode 100644
index 94e0590..0000000
--- a/docs/os/tutorials/bleprph/bleprph-svc-reg.md
+++ /dev/null
@@ -1,155 +0,0 @@
-## BLE Peripheral Project
-
-### Service Registration
-
-<br>
-
-#### Attribute Set
-
-The NimBLE host uses a table-based design for GATT server configuration. The
-set of supported attributes are expressed as a series of tables that resides in
-your C code. When possible, we recommend using a single monolithic table, as
-it results in code that is simpler and less error prone. Multiple tables
-can be used if it is impractical for the entire attribute set to live in one
-place in your code.
-
-*bleprph* uses a single attribute table located in the *gatt_svr.c* file,
-so let's take a look at that now. The attribute table is called
-`gatt_svr_svcs`; here are the first several lines from this table:
-
-<br>
-
-```c
-static const struct ble_gatt_svc_def gatt_svr_svcs[] = {
- {
- /*** Service: Security test. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid = &gatt_svr_svc_sec_test_uuid.u,
- .characteristics = (struct ble_gatt_chr_def[]) { {
- /*** Characteristic: Random number generator. */
- .uuid = &gatt_svr_chr_sec_test_rand_uuid.u,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ,
- }, {
- /*** Characteristic: Static value. */
- .uuid = &gatt_svr_chr_sec_test_static_uuid.u,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ,
- // [...]
-```
-
-<br>
-
-As you can see, the table is an array of service definitions (
-`struct ble_gatt_svc_def`). Let's now consider the contents of this table in more
-detail.
-
-A service definition consists of the following fields:
-
-| *Field* | *Meaning* | *Notes* |
-| ------- | --------- | ------- |
-| type | Specifies whether this is a primary or secondary service. | Secondary services are not very common. When in doubt, specify *BLE_GATT_SVC_TYPE_PRIMARY* for new services. |
-| uuid | The UUID of this characteristic. | This field accepts a pointer to a variable of type `ble_uuid_t`. You could directly use the `BLE_UUID16_DECLARE()` macro or to pass a pointer to a `ble_uuid16_t` variable you could type `&uuid_variable.u` |
-| characteristics | The array of characteristics that belong to this service. | |
-
-<br>
-
-A service is little more than a container of characteristics; the
-characteristics themselves are where the real action happens. A characteristic
-definition consists of the following fields:
-
-| *Field* | *Meaning* | *Notes* |
-| ------- | --------- | ------- |
-| uuid | The UUID of this characteristic. | This field accepts a pointer to a variable of type `ble_uuid_t`. You could directly use the `BLE_UUID16_DECLARE()` macro or to pass a pointer to a `ble_uuid16_t` variable you could type `&uuid_variable.u` |
-| access\_cb | A callback function that gets executed whenever a peer device accesses this characteristic. | *For reads:* this function generates the value that gets sent back to the peer.<br>*For writes:* this function receives the written value as an argument. |
-| flags | Indicates which operations are permitted for this characteristic. The NimBLE stack responds negatively when a peer attempts an unsupported operation. | The full list of flags can be found under `ble_gatt_chr_flags` in [nimble/host/include/host/ble_gatt.h](https://github.com/apache/mynewt-nimble/blob/master/nimble/host/include/host/ble_gatt.h).|
-
-The access callback is what implements the characteristic's behavior. Access
-callbacks are described in detail in the next section:
-[BLE Peripheral - Characteristic Access](bleprph-chr-access/).
-
-The service definition array and each characteristic definition array is
-terminated with an empty entry, represented with a 0. The below code listing
-shows the last service in the array, including terminating zeros for the
-characteristic array and service array.
-
-<br>
-
-```c hl_lines="16 21"
- {
- /*** Service: Security test. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid = &gatt_svr_svc_sec_test_uuid.u,
- .characteristics = (struct ble_gatt_chr_def[]) { {
- /*** Characteristic: Random number generator. */
- .uuid = &gatt_svr_chr_sec_test_rand_uuid.u,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ,
- }, {
- /*** Characteristic: Static value. */
- .uuid = &gatt_svr_chr_sec_test_static_uuid.u,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ,
- }, {
- 0, /* No more characteristics in this service. */
- } },
- },
-
- {
- 0, /* No more services. */
- },
-```
-
-<br>
-
-#### Registration function
-
-After you have created your service table, your app needs to register it with the NimBLE stack. This is done by calling the following function:
-
-```c
-int
-ble_gatts_add_svcs(const struct ble_gatt_svc_def *svcs)
-```
-
-The function parameters are documented below.
-
-| *Parameter* | *Meaning* | *Notes* |
-| ----------- | --------- | ------- |
-| svcs | An array of service definitions to queue for registration. This array must be terminated with an entry whose 'type' equals 0. | |
-
-The `ble_gatts_register_svcs()` function returns 0 on success, or a
-*BLE_HS_E[...]* error code on failure.
-
-The *bleprph* app registers its services as follows:
-
-```c
- rc = ble_gatts_add_svcs(gatt_svr_svcs);
- if (rc != 0) {
- return rc;
- }
-```
-
-More detailed information about the registration function can be found
-in the BLE User Guide: [ble_gatts_add_svcs](../../../network/ble/ble_hs/ble_gatts/functions/ble_gatts_add_svcs/).
-
-<br>
-
-#### Registration callback function
-
-It is possible to set a callback function that gets executed each time a service, characteristic, or descriptor is registered. This is done by setting the following attribute:
-
-```c
-ble_hs_cfg.gatts_register_cb = gatt_svr_register_cb;
-```
-In the above example `gatt_svr_register_cb` is the function that will be called. This line can be found in *bleprph*'s `main.c` file
-
-More detailed information about the registration callback function can be found
-in the [BLE User Guide](../../../network/ble/ble_intro/) (TBD).
-
-<br>
-
-#### Descriptors and Included Services
-
-Your peripheral can also expose descriptors and included services. These are
-less common, so they are not covered in this tutorial. For more information,
-see the [BLE User Guide](../../../network/ble/ble_intro/).
diff --git a/docs/os/tutorials/blinky.md b/docs/os/tutorials/blinky.md
deleted file mode 100644
index 9efbd33..0000000
--- a/docs/os/tutorials/blinky.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## Blinky, your "Hello World!" on a Target Board
-The set of Blinky tutorials show you how to create, build, and run a "Hello World" application that blinks a LED on the various target boards that Mynewt supports. The tutorials use the same Blinky application from the [Creating Your First Project](/os/get_started/project_create) tutorial.
-
-### Objective
-
-Learn how to use packages from a default application repository of Mynewt to build your first *Hello World* application (Blinky) on a target board. Once built using the *newt* tool, this application will blink a LED light on the target board.
-
-### Available Tutorials
-Tutorials are available for the following boards:
-
-* [Blinky on an Arduino Zero](/os/tutorials/arduino_zero.md)
-* [Blinky on an Arduino Primo](/os/tutorials/blinky_primo.md)
-* [Blinky on an Olimex](/os/tutorials/olimex.md)
-* [Blinky on a nRF52 Development Kit](/os/tutorials/nRF52.md)
-* [Blinky on a RedBear Nano 2](/os/tutorials/rbnano2.md)
-* [Blinky on a STM32F4-Discovery](/os/tutorials/blinky_stm32f4disc.md)
-
-We also have a tutorial that shows you how to add [Console and Shell to the Blinky Application](/os/tutorials/blinky_console.md).
-<br>
-### Prerequisites
-Ensure that you meet the following prerequisites before continuing with one of the tutorials.
-
-* Have Internet connectivity to fetch remote Mynewt components.
-* Have a computer to build a Mynewt application and connect to the board over USB.
-* Have a Micro-USB cable to connect the board and the computer.
-* Install the newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
-* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
-* Create a project space (directory structure) and populate it with the core code repository (apache-mynewt-core) or know how to as explained in [Creating Your First Project](/os/get_started/project_create).
-<br>
-###Overview of Steps
-These are the general steps to create, load and run the Blinky application on your board:
-
-* Create a project.
-* Define the bootloader and Blinky application targets for the board.
-* Build the bootloader target.
-* Build the Blinky application target and create an application image.
-* Connect to the board.
-* Load the bootloader onto the board.
-* Load the Blinky application image onto the board.
-* See the LED on your board blink.
-
-<br>
-
-After you try the Blinky application on your boards, checkout out other tutorials to enable additional functionality such as [remote comms](project-slinky.md) on the current board. If you have BLE (Bluetooth Low Energy) chip (e.g. nRF52) on your board, you can try turning it into an [iBeacon](ibeacon.md) or [Eddystone Beacon](eddystone.md)!
-
-If you see anything missing or want to send us feedback, please sign up for
-appropriate mailing lists on our [Community Page](../../community.md).
diff --git a/docs/os/tutorials/blinky_console.md b/docs/os/tutorials/blinky_console.md
deleted file mode 100644
index 304f669..0000000
--- a/docs/os/tutorials/blinky_console.md
+++ /dev/null
@@ -1,198 +0,0 @@
-## Enabling The Console and Shell for Blinky
-
-This tutorial shows you how to add the Console and Shell to the Blinky application and interact with it over a serial line connection.
-<br>
-
-### Prerequisites
-
-* Work through one of the Blinky Tutorials to create and build a Blinky application for one of the boards.
-* Have a [serial setup](/os/get_started/serial_access.md).
-
-<br>
-
-### Use an Existing Project
-
-Since all we're doing is adding the shell and console capability to blinky, we assume
-that you have worked through at least some of the other tutorials, and have an existing project.
-For this example, we'll be modifying the [blinky on nrf52](./nRF52.md) project to enable
-the shell and console connectivity. You can use blinky on a different board.
-
-<br>
-
-### Modify the Dependencies and Configuration
-
-Modify the package dependencies in your application target's `pkg.yml` file as follows:
-
-* Add the shell package: `@apache-mynewt-core/sys/shell`.
-* Replace the `@apache-mynewt-core/sys/console/stub` package with the `@apache-mynewt-core/sys/console/full` package.
-
- **Note**: If you are using version 1.1 or lower of blinky, the `@apache-mynewt-core/sys/console/full` package may be already listed as a dependency.
-
-The updated `pkg.yml` file should have the following two lines:
-
-```no-highlight
-pkg.deps:
- - "@apache-mynewt-core/sys/console/full"
- - "@apache-mynewt-core/sys/shell"
-```
-
-This lets the newt system know that it needs to pull in the code for the console and the shell.
-
-Modify the system configuration settings to enable Shell and Console ticks and prompt. Add the following to your application target's `syscfg.yml` file:
-
-```no-highlight
-syscfg.vals:
- # Enable the shell task.
- SHELL_TASK: 1
- SHELL_PROMPT_MODULE: 1
-```
-
-<br>
-
-### Use the OS Default Event Queue to Process Blinky Timer and Shell Events
-
-Mynewt creates a main task that executes the application `main()` function. It also creates an OS default event queue that packages can use to queue their events. Shell uses the OS default event queue for Shell events, and `main()` can process the events in the context of the main task.
-
-Blinky's main.c is very simple. It only has a `main()` function that executes an infinite loop to toggle the LED and sleep for one second. We will modify blinky:
-
-* To use os_callout to generate a timer event every one second instead of sleeping. The timer events are added to the OS default event queue.
-* To process events from the OS default event queue inside the infinite loop in `main()`.
-
-This allows the main task to process both Shell events and the timer events to toggle the LED from the OS default event queue.
-
-<br>
-
-### Modify main.c
-
-Initialize a os_callout timer and move the toggle code from the while loop in `main()` to the event callback function. Add the following code above the `main()` function:
-
-```c
-/* The timer callout */
-static struct os_callout blinky_callout;
-
-/*
- * Event callback function for timer events. It toggles the led pin.
- */
-static void
-timer_ev_cb(struct os_event *ev)
-{
- assert(ev != NULL);
-
- ++g_task1_loops;
- hal_gpio_toggle(g_led_pin);
-
- os_callout_reset(&blinky_callout, OS_TICKS_PER_SEC);
-}
-
-static void
-init_timer(void)
-{
- /*
- * Initialize the callout for a timer event.
- */
- os_callout_init(&blinky_callout, os_eventq_dflt_get(),
- timer_ev_cb, NULL);
-
- os_callout_reset(&blinky_callout, OS_TICKS_PER_SEC);
-}
-```
-
-In `main()`, add the call to the `init_timer()` function before the while loop and modify the while loop to process events from the OS default event queue:
-
-```c hl_lines="15 17"
-int
-main(int argc, char **argv)
-{
-
- int rc;
-
-#ifdef ARCH_sim
- mcu_sim_parse_args(argc, argv);
-#endif
-
- sysinit();
-
- g_led_pin = LED_BLINK_PIN;
- hal_gpio_init_out(g_led_pin, 1);
- init_timer();
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
- assert(0);
- return rc;
-}
-
-```
-<br>
-
-### Build, Run, and Upload the Blinky Application Target
-
-We're not going to build the bootloader here since we are assuming that you have already
-built and loaded it during previous tutorials.
-
-We will use the `newt run` command to build and deploy our improved blinky image. The run command performs the following tasks for us:
-
-1. Builds a binary Mynewt executable
-2. Wraps the executable in an image header and footer, turning it into a Mynewt image.
-3. Uploads the image to the target hardware.
-4. Starts a gdb process to remotely debug the Mynewt device.
-
-Run the `newt run nrf52_blinky 0` command. The `0` is the version number that should be written to the image header. Any version will do, so we choose 0.
-
-```no-highlight
-$ newt run nrf52_blinky 0
-
- ...
-
-Archiving util_mem.a
-Linking /home/me/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky/blinky.elf
-App image succesfully generated: /home/me/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky/blinky.elf
-Loading app image into slot 1
-[/home/me/dev/myproj/repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_debug.sh /home/me/dev/myproj/repos/apache-mynewt-core/hw/bsp/nrf52dk /home/me/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky]
-Debugging /home/me/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky/blinky.elf
-```
-
-<br>
-
-### Set Up a Serial Connection
-
-You'll need a Serial connection to see the output of your program. You can reference the [Serial Port Setup](../get_started/serial_access.md) Tutorial for more information on setting up your serial communication.
-
-<br>
-
-### Communicate with the Application
-
-Once you have a connection set up, you can connect to your device as follows:
-
-* On Mac OS and Linux platforms, you can run ```minicom -D /dev/tty.usbserial-<port> -b 115200``` to connect to the console of your app. Note that on Linux, the format of the port name is `/dev/ttyUSB<N>`, where N is a number.
-
-* On Windows, you can use a terminal application such as PuTTY to connect to the device.
-
-If you located your port from a MinGW terminal, the port name format is `/dev/ttyS<N>`, where `N` is a number. You must map the port name to a Windows COM port: `/dev/ttyS<N>` maps to `COM<N+1>`. For example, `/dev/ttyS2` maps to `COM3`.
-
-You can also use the Windows Device Manager to locate the COM port.
-
-<br>
-To test and make sure that the Shell is running, first just hit <return>:
-
-```no-highlight
-004543 shell>
-```
-
-You can try some commands:
-
-```no-highlight
-003005 shell> help
-003137 Available modules:
-003137 os
-003138 prompt
-003138 To select a module, enter 'select <module name>'.
-003140 shell> prompt
-003827 help
-003827 ticks shell ticks command
-004811 shell> prompt ticks off
-005770 Console Ticks off
-shell> prompt ticks on
-006404 Console Ticks on
-006404 shell>
-```
diff --git a/docs/os/tutorials/blinky_primo.md b/docs/os/tutorials/blinky_primo.md
deleted file mode 100644
index 6fe34dc..0000000
--- a/docs/os/tutorials/blinky_primo.md
+++ /dev/null
@@ -1,242 +0,0 @@
-## Blinky, your "Hello World!", on Arduino Primo
-
-This tutorial shows you how to create, build, and run the Blinky application on an Arduino Primo board.
-
-Note that the Mynewt OS will run on the nRF52 chip in the Arduino Primo board. However, the board support package for the Arduino Primo is different from the nRF52 dev kit board support package.
-<br>
-### Prerequisites
-
-* Meet the the prerequisites listed in [Project Blinky](/os/tutorials/blinky.md).
-* Have an Arduino Primo board.
-* Install a debugger. Choose one of the two options below: Option 1 requires additional hardware but very easy to set up.
-
-<br>
-##### Option 1
-* [Segger J-Link Debug Probe](https://www.segger.com/jlink-debug-probes.html) - any model (this tutorial has been tested with J-Link EDU and J-Link Pro)
-* [J-Link 9 pin Cortex-M Adapter](https://www.segger.com/jlink-adapters.html#CM_9pin) that allows JTAG, SWD and SWO connections between J-Link and Cortex M based target hardware systems
-* Install the [Segger JLINK Software and documentation pack](https://www.segger.com/jlink-software.html).
-
-##### Option 2
-This board requires a patch version of OpenOCD 0.10.0 that is in development. See [Install OpenOCD](/os/get_started/cross_tools.md) instructions to install it if you do not have this version installed.
-
-You can now use openocd to upload to Arduino Primo board via the USB port itself.
-
-### Create a Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already created a project.
-
-Run the following commands to create a new project:
-
-```no-highlight
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new myproj
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in myproj...
- Project myproj successfully created.
- $ cd myproj
- $ newt install
- apache-mynewt-core
- $
-```
-
-<br>
-### <a name="create_targets"></a>Create the Targets
-
-Create two targets for the Arduino Primo board - one for the bootloader and one for the Blinky application.
-
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `primo_boot`.
-
-```no-highlight
-$ newt target create primo_boot
-$ newt target set primo_boot app=@apache-mynewt-core/apps/boot bsp=@apache-mynewt-core/hw/bsp/arduino_primo_nrf52 build_profile=optimized
-```
-<br>
-Run the following `newt target` commands to create a target for the Blinky application. We name the target `primoblinky`.
-```no-highlight
-$ newt target create primoblinky
-$ newt target set primoblinky app=apps/blinky bsp=@apache-mynewt-core/hw/bsp/arduino_primo_nrf52 build_profile=debug
-```
-<br>
-If you are using openocd, run the following `newt target set` commands:
-
-```no-highlight
-$ newt target set primoblinky syscfg=OPENOCD_DEBUG=1
-$ newt target set primo_boot syscfg=OPENOCD_DEBUG=1
-```
-
-<br>
-You can run the `newt target show` command to verify the target settings:
-
-```no-highlight
-$ newt target show
-targets/my_blinky_sim
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/native
- build_profile=debug
-targets/primo_boot
- app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/arduino_primo_nrf52
- build_profile=optimized
-targets/primoblinky
- app=@apache-mynewt-core/apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/arduino_primo_nrf52
- build_profile=optimized
-```
-
-
-<br>
-
-### Build the Target Executables
-Run the `newt build primo_boot` command to build the bootloader:
-```no-highlight
-$ newt build primo_boot
-Building target targets/primo_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-
- ...
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/primo_boot/app/apps/boot/boot.elf
-Target successfully built: targets/primo_boot
-```
-<br>
-Run the `newt build primoblinky` command to build the Blinky application:
-
-```no-highlight
-$ newt build primoblinky
-Building target targets/primoblinky
-Compiling repos/apache-mynewt-core/hw/drivers/uart/src/uart.c
-Assembling repos/apache-mynewt-core/hw/bsp/arduino_primo_nrf52/src/arch/cortex_m4/gcc_startup_nrf52.s
-Compiling repos/apache-mynewt-core/hw/bsp/arduino_primo_nrf52/src/sbrk.c
-Compiling repos/apache-mynewt-core/hw/cmsis-core/src/cmsis_nvic.c
-Assembling repos/apache-mynewt-core/hw/bsp/arduino_primo_nrf52/src/arch/cortex_m4/gcc_startup_nrf52_split.s
-Compiling apps/blinky/src/main.c
-Compiling repos/apache-mynewt-core/hw/drivers/uart/uart_bitbang/src/uart_bitbang.c
-Compiling repos/apache-mynewt-core/hw/bsp/arduino_primo_nrf52/src/hal_bsp.c
-
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/primoblinky/app/apps/blinky/blinky.elf
-Target successfully built: targets/primoblinky
-```
-
-<br>
-
-### Sign and Create the Blinky Application Image
-
-Run the `newt create-image primoblinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
-
-```no-highlight
-$ newt create-image primoblinky 1.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/primoblinky/app/apps/blinky/blinky.img
-
-```
-
-<br>
-
-### Connect to the Board
-* Connect a micro USB cable to the Arduino Primo board and to your computer's USB port.
-* If you are using the Segger J-Link debug probe, connect the debug probe to the JTAG port on the Primo board using the Jlink 9-pin adapter and cable. Note that there are two JTAG ports on the board. Use the one nearest to the reset button as shown in the picture.
-
-
-
-**Note:** If you are using the OpenOCD debugger, you do not need to attach this connector.
-
-### Load the Bootloader
-Run the `newt load primo_boot` command to load the bootloader onto the board:
-
-```no-highlight
-$ newt load primo_boot
-Loading bootloader
-$
-```
-
-**Note:** If you are using OpenOCD on a Windows platform and you get an `unable to find CMSIS-DAP device` error, you will need to download and install the mbed Windows serial port driver from [https://developer.mbed.org/handbook/Windows-serial-configuration](https://developer.mbed.org/handbook/Windows-serial-configuration). Follow the instructions from the site to install the driver. Here are some additional notes about the installation:
-
-1. The instructions indicate that the mbed Windows serial port driver is not required for Windows 10. If you are using Windows 10 and get the `unable to find CMSIS-DAP device` error, we recommend that you install the driver.
-2. If the driver installation fails, we recommend that you download and install the Arduino Primo CMSIS-DAP driver. Perform the following steps:
-
- * Download the [Arduino Primo CMSIS-DAP driver](https://github.com/runtimeco/openocd-binaries/raw/master/arduino_primo_drivers.zip) and extract the zip file.
- * Start Device Manager.
- * Select **Other Devices** > **CMSIS-DAP CDC** > **Properties** > **Drivers** > **Update Driver...**.
- * Select **Browse my computer for driver software**.
- * Select the Arduino Driver folder where extracted the drivers to (check the include subfolders). Click **Next** to install the driver.
-
-
-Run the `newt load primo_boot` command again.
-
-<br>
-###Load the Blinky Application Image
-Run the `newt load primoblinky` command to load the Blinky application image onto the board.
-
-```no-highlight
-$ newt load primoblinky
-Loading app image into slot 1
-$
-```
-
-You should see the orange LED (L13), below the ON LED, on the board blink!
-
-Note: If the LED does not blink, try resetting the board.
-
-
-<br>
-###Erase Flash
-If you want to erase the flash and load the image again, use JLinkExe and issue the `erase` command when you are using the Jlink debug probe:
-
-**Note:** On Windows: Run the `jlink` command with the same arguments from a Windows Command Prompt terminal.
-<br>
-```no-highlight
-$ JLinkExe -device nRF52 -speed 4000 -if SWD
-SEGGER J-Link Commander V5.12c (Compiled Apr 21 2016 16:05:51)
-DLL version V5.12c, compiled Apr 21 2016 16:05:45
-
-Connecting to J-Link via USB...O.K.
-Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 15 2016 18:03:17
-Hardware version: V1.00
-S/N: 682863966
-VTref = 3.300V
-
-
-Type "connect" to establish a target connection, '?' for help
-J-Link>erase
-Cortex-M4 identified.
-Erasing device (0;?i?)...
-Comparing flash [100%] Done.
-Erasing flash [100%] Done.
-Verifying flash [100%] Done.
-J-Link: Flash download: Total time needed: 0.363s (Prepare: 0.093s, Compare: 0.000s, Erase: 0.262s, Program: 0.000s, Verify: 0.000s, Restore: 0.008s)
-Erasing done.
-J-Link>exit
-$
-```
-<br>
-
-If you are using the OpenOCD debugger, run the `newt debug primoblinky` command and issue the highlighted command at the (gdb) prompt:
-
-**Note:** The output of the debug session below is for Mac OS and Linux platforms. On Windows, openocd and gdb are started in separate Windows Command Prompt terminals, and the terminals are automatically closed when you quit gdb. In addition, the output of openocd is logged to the openocd.log file in your project's base directory instead of the terminal.
-
-```hl_lines="11"
-$newt debug primoblinky
-[~/dev/myproj/repos/apache-mynewt-core/hw/bsp/arduino_primo_nrf52/primo_debug.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/arduino_primo_nrf52 ~/dev/myproj/bin/targets/primoblinky/app/apps/blinky/blinky]
-Open On-Chip Debugger 0.10.0-dev-snapshot (2017-03-28-11:24)
-
- ...
-
-os_tick_idle (ticks=128)
- at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_os_tick.c:200
-warning: Source file is more recent than executable.
-200 if (ticks > 0) {
-(gdb) mon nrf52 mass_erase
-```
-<br>
diff --git a/docs/os/tutorials/blinky_sram_olimex.md b/docs/os/tutorials/blinky_sram_olimex.md
deleted file mode 100644
index dd2439d..0000000
--- a/docs/os/tutorials/blinky_sram_olimex.md
+++ /dev/null
@@ -1,168 +0,0 @@
-## Run Blinky from SRAM without bootloader
-
-### Objective
-
-To download an application image directly into the embedded SRAM in the microcontroller and run it without the bootloader. This tutorial describes how you do it on an Olimex STM32 board.
-
-### What you need
-
-1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
-2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
-3. USB A-B type cable to connect the debugger to your personal computer
-4. Personal Computer with Mac OS (Mac: OS X Yosemite Version 10.10.5) or Linux box (Ubuntu 14.10: Utopic Unicorn)
-5. An account on Github repository and *git* installed on your computer.
-6. It is assumed you have already installed newt tool.
-7. It is assumed you already installed native tools as described [here](../get_started/native_tools.md)
-
-Also, we assume that you're familiar with UNIX shells. Let's gets started!
-
-<br>
-
-
-### Prepare the Software
-
-* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory.
-
-<br>
-
-### Create a project
-
-Create a new project to hold your work. For a deeper understanding, you can read about project creation in
-[Get Started -- Creating Your First Project](../get_started/project_create.md)
-or just follow the commands below.
-
-```no-highlight
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new myproj
- Downloading project skeleton from apache/incubator-mynewt-blinky...
- Installing skeleton in myproj...
- Project myproj successfully created.
-
- $cd myproj
-
- $ newt install -v
- apache-mynewt-core
- Downloading repository description for apache-mynewt-core... success!
- ...
- apache-mynewt-core successfully installed version 0.7.9-none
-```
-
-<br>
-
-### Create a target
-
-Change directory to ~/dev/myproj directory and define the *blinky* target inside myproj, using the *newt* tool. Starting with the target name, assign specific aspects of the project, as shown below, to pull the appropriate packages and build the right bundle or list for the board. For example, we set the build_profile, board support package (bsp), and app.
-
-
-```no-highlight
- $ newt target create blinky
- $ newt target set blinky build_profile=debug
- $ newt target set blinky bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
- $ newt target set blinky app=apps/blinky
- $ newt target show blinky
- targets/blinky
- app=apps/blinky
- bsp=hw/bsp/olimex_stm32-e407_devboard
- build_profile=debug
-```
-
-<br>
-
-### Build the image
-
-Next, let's build the image for the above target. By default, the linker script within the `hw/bsp/olimex_stm32-e407_devboard` package builds an image for flash memory, which we don't want; instead, we want an image for the SRAM, so you need to switch that script with `run_from_sram.ld`.
-
-Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.*
-
-
-```no-highlight
- $ cd ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/
- $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
- (some diff will be displayed)
- $ cp run_from_sram.ld olimex_stm32-e407_devboard.ld
- $ cd ~/dev/myproj
- $ newt build blinky
- Compiling case.c
- Compiling suite.c
- ...
- Linking blinky.elf
- App successfully built:~/dev/myproj/bin/blinky/apps/blinky/blinky.elf
- $ ls ~/dev/myproj/bin/blinky/apps/blinky/
- blinky.elf blinky.elf.bin blinky.elf.cmd
- blinky.elf.lst blinky.elf.map
-```
-
-<br>
-
-### Prepare the hardware to boot from embedded SRAM
-
-* Locate the boot jumpers on the board.
-
-<br>
-
-
-
-
-<br>
-
-* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present.
-To locate the bootloader, the board searches in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we will configure it to boot from SRAM by jumpering **B0_1** and **B1_1**.
-
-* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
-
-* The red PWR LED should be lit.
-
-* Connect the JTAG connector to the SWD/JTAG interface on the board. The other end of the cable should be connected to the USB port or hub of your computer.
-
-<br>
-
-### Let's Go!
-
-* Ensure that you are in the blinky project directory with the *blinky.elf* executable. Run the debug command in the *newt* tool. You'll see some status messages as shown below. In case you need to halt the debugging session, you can issue an `-c "reset halt"` command.
-
-
-```no-highlight
- $ newt debug blinky
- Debugging with ~/dev/core/hw/bsp/olimex_...
- Debugging ~/dev/core/project/blinky/bin/blinky/blinky.elf
- GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
- Copyright (C) 2014 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 <http://gnu.org/licenses/gpl.html>
- ...
- (info)
- ...
- target state: halted
- target halted due to debug-request, current mode: Thread
- xPSR: 0x01000000 pc: 0x080003c0 msp: 0x10010000
- Info : accepting 'gdb' connection on tcp/3333
- Info : device id = 0x10036413
- Info : flash size = 1024kbytes
-```
-<br>
-
-Check the value of the msp (main service pointer) register. If it is not 0x10010000 as indicated above, you will have to manually set it after you open the gdb tool and load the image on it. For example,
-
-```no-highlight
- (gdb) set $msp=0x10010000
-```
-
-<br>
-
- Now load the image and type "c" or "continue" from the GNU debugger.
-
-```no-highlight
- (gdb) load ~/dev/myproj/bin/blinky/apps/blinky/blinky.elf
- Loading section .text, size 0x16b88 lma 0x20000000
- Loading section .ARM.exidx, size 0x18 lma 0x20016b88
- Loading section .data, size 0x9ec lma 0x20016ba0
- Start address 0x200004b8, load size 95628
- Transfer rate: 74 KB/sec, 3825 bytes/write.
- (gdb) c
- Continuing.
-```
-
-* Voilà! The board's LED should be blinking at 1 Hz. Success!
-
-<br>
-
diff --git a/docs/os/tutorials/blinky_stm32f4disc.md b/docs/os/tutorials/blinky_stm32f4disc.md
deleted file mode 100644
index a048618..0000000
--- a/docs/os/tutorials/blinky_stm32f4disc.md
+++ /dev/null
@@ -1,234 +0,0 @@
-## Blinky, your "Hello World!", on STM32F4-Discovery
-This tutorial shows you how to create, build, and run the Blinky application on the STM32F4-Discovery board.
-<br>
-
-<br>
-
-### Prerequisites
-
-* Meet the prerequisites listed in [Project Blinky](/os/tutorials/blinky.md).
-* Have a STM32F4-Discovery board.
-* Have a USB type A to Mini-B cable.
-* Install a patched version of OpenOCD 0.10.0 described in [Install OpenOCD](/os/get_started/cross_tools/).
-
-### Create a Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already have a project created.
-
-Run the following commands to create a new project:
-
-```no-highlight
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new myproj
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in myproj...
- Project myproj successfully created.
- $ cd myproj
- $ newt install
- apache-mynewt-core
- $
-```
-
-<br>
-
-### <a name="create_targets"></a>Create the Targets
-
-Create two targets for the STM32F4-Discovery board - one for the bootloader and one for the Blinky application.
-
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `stm32f4disc_boot`:
-
-```no-highlight
-$ newt target create stm32f4disc_boot
-$ newt target set stm32f4disc_boot app=@apache-mynewt-core/apps/boot
-$ newt target set stm32f4disc_boot bsp=@apache-mynewt-core/hw/bsp/stm32f4discovery
-$ newt target set stm32f4disc_boot build_profile=optimized
-```
-
-<br>
-Run the following `newt target` commands to create a target for the Blinky application. We name the target `stm32f4disc_blinky`:
-
-```no-highlight
-$ newt target create stm32f4disc_blinky
-$ newt target set stm32f4disc_blinky app=apps/blinky
-$ newt target set stm32f4disc_blinky bsp=@apache-mynewt-core/hw/bsp/stm32f4discovery
-$ newt target set stm32f4disc_blinky build_profile=debug
-```
-<br>
-You can run the `newt target show` command to verify the target settings:
-
-```no-highlight
-$ newt target show
-targets/my_blinky_sim
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/native
- build_profile=debug
-targets/stm32f4disc_blinky
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/stm32f4discovery
- build_profile=debug
-targets/stm32f4disc_boot
- app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/stm32f4discovery
- build_profile=optimized
-```
-<br>
-
-### Build the Target Executables
-
-Run the `newt build stm32f4disc_boot` command to build the bootloader:
-
-```no-highlight
-$ newt build stm32f4disc_boot
-Building target targets/stm32f4disc_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
- ...
-
-Archiving sys_flash_map.a
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/stm32f4disc_boot/app/apps/boot/boot.elf
-Target successfully built: targets/stm32f4disc_boot
-```
-
-<br>
-Run the `newt build stm32f4disc_blinky` command to build the Blinky application:
-
-```no-highlight
-$newt build stm32f4disc_blinky
-Building target targets/stm32f4disc_blinky
-Compiling apps/blinky/src/main.c
-Compiling repos/apache-mynewt-core/hw/bsp/stm32f4discovery/src/sbrk.c
-Compiling repos/apache-mynewt-core/hw/bsp/stm32f4discovery/src/system_stm32f4xx.c
-Compiling repos/apache-mynewt-core/hw/bsp/stm32f4discovery/src/hal_bsp.c
-Assembling repos/apache-mynewt-core/hw/bsp/stm32f4discovery/src/arch/cortex_m4/startup_STM32F40x.s
-Compiling repos/apache-mynewt-core/hw/cmsis-core/src/cmsis_nvic.c
-Compiling repos/apache-mynewt-core/hw/drivers/uart/src/uart.c
-Compiling repos/apache-mynewt-core/hw/drivers/uart/uart_hal/src/uart_hal.c
-Compiling repos/apache-mynewt-core/hw/hal/src/hal_common.c
-Compiling repos/apache-mynewt-core/hw/hal/src/hal_flash.c
-
- ...
-
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/stm32f4disc_blinky/app/apps/blinky/blinky.elf
-Target successfully built: targets/stm32f4disc_blinky
-```
-
-
-<br>
-
-### Sign and Create the Blinky Application Image
-
-Run the `newt create-image stm32f4disc_blinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
-
-```no-highlight
-$newt create-image stm32f4disc_blinky 1.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/stm32f4disc_blinky/app/apps/blinky/blinky.img
-```
-
-<br>
-
-### Connect to the Board
-
-Connect a USB type A to Mini-B cable from your computer to the port the board indicated on the diagram:
-
-<br>
-<br>
-
-
-<br>
-
-You should see the small PWR red LED light up.
-
-### Load the Bootloader and the Blinky Application Image
-
-Run the `newt load stm32f4disc_boot` command to load the bootloader onto the board:
-
-```no-highlight
-$newt load stm32f4disc_boot
-Loading bootloader
-```
-
-Note: If you are using Windows and get an `open failed` or `no device found` error, you will need to install the usb driver. Download [Zadig](http://zadig.akeo.ie) and run it:
-
-* Select Options > List All Devices.
-* Select `STM32 STLink` from the drop down menu.
-* Select the `WinUSB` driver.
-* Click Install Driver.
-* Run the `newt load stm32f4disc_boot` command again.
-
-Note: If you are running Linux and get an `open failed` message, there are two common issues with this board. If you have a board produced before mid-2016, it is likely that you have an older version of the ST-LINK programmer. To correct this, open the `repos/apache-mynewt-core/hw/bsp/stm32f4discovery/f4discovery.cfg` file in a text editor, and change the line:
-
-```no-highlight
-source [find interface/stlink-v2-1.cfg]
-```
-
-to:
-
-```no-highlight
-source [find interface/stlink-v2.cfg]
-```
-
-If you receive an error like `libusb_open() failed with LIBUSB_ERROR_ACCESS`, it means that your `udev` rules are not correctly set up for this device. You can find some example `udev` rules for ST-LINK programmers [here](https://github.com/texane/stlink/tree/master/etc/udev/rules.d).
-
-<br>
-Run the `newt load stm32f4disc_blinky` command to load the Blinky application image onto the board.
-```no-highlight
-$newt load stm32f4disc_blinky
-Loading app image into slot 1
-```
-
-You should see the small green LD4 LED on the board blink!
-
-Note: If the LED does not blink, try resetting your board.
-
-<br>
-
-If you want to erase the flash and load the image again, start a debug session, and enter `mon stm32f2x mass_erase 0` at the gdb prompt:
-
-**Note:** The output of the debug session below is for Mac OS and Linux platforms. On Windows, openocd and gdb are started in separate Windows Command Prompt terminals, and the terminals are automatically closed when you quit gdb. In addition, the output of openocd is logged to the openocd.log file in your project's base directory instead of the terminal.
-
-<br>
-```no-highlight
-$newt debug stm32f4disc_blinky
-[~/dev/myproj/repos/apache-mynewt-core/hw/bsp/stm32f4discovery/stm32f4discovery_debug.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/stm32f4discovery ~/dev/myproj/bin/targets/stm32f4disc_blinky/app/apps/blinky/blinky]
-Open On-Chip Debugger 0.10.0
-Licensed under GNU GPL v2
-For bug reports, read
- http://openocd.org/doc/doxygen/bugs.html
-Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
-adapter speed: 2000 kHz
-adapter_nsrst_delay: 100
-none separate
-Info : Unable to match requested speed 2000 kHz, using 1800 kHz
-Info : Unable to match requested speed 2000 kHz, using 1800 kHz
-Info : clock speed 1800 kHz
-Info : STLINK v2 JTAG v25 API v2 SWIM v14 VID 0x0483 PID 0x374B
-Info : using stlink api v2
-Info : Target voltage: 2.881129
-Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
-target halted due to debug-request, current mode: Thread
-
- ...
-
-Reading symbols from ~/dev/myproj/bin/targets/stm32f4disc_blinky/app/apps/blinky/blinky.elf...done.
-target halted due to debug-request, current mode: Thread
-xPSR: 0x41000000 pc: 0x08021e90 psp: 0x20002290
-Info : accepting 'gdb' connection on tcp/3333
-Info : device id = 0x10076413
-Info : flash size = 1024kbytes
-0x08021e90 in __WFI () at repos/apache-mynewt-core/hw/cmsis-core/src/ext/core_cmInstr.h:342
-342 __ASM volatile ("wfi");
-(gdb) mon stm32f2x mass_erase 0
-stm32x mass erase complete
-stm32x mass erase complete
-(gdb)
-```
diff --git a/docs/os/tutorials/blinky_windows.md b/docs/os/tutorials/blinky_windows.md
deleted file mode 100644
index c67c699..0000000
--- a/docs/os/tutorials/blinky_windows.md
+++ /dev/null
@@ -1,261 +0,0 @@
-## Project Blinky on a Windows Machine
-
-### Getting your Windows machine ready for simulated target
-
-The `newt` tool is the build software used to build Mynewt OS images or executables for any embedded hardware device/board, including the one for the current tutorial (STM32-E407 development board from Olimex). You can run the `newt` tool natively on a computer running any of the three Operating System machines - OSX, Linux, or Windows.
-
-However, Mynewt OS images for a simulated target are built on the Windows machine by using Linux versions of the build software (newt)in a virtual machine on your Windows box. The Linux VM is set up by installing the Docker Toolbox. Your Windows machine will communicate with the Linux VM via transient ssh connections. You will then download a Docker image (`newtvm.exe`)that allows you to run the newt commands in the Linux Docker instance. The Docker image contains:
-
-* The newt command-line tool
-* Go
-* A multilib-capable native gcc / glibc
-* An arm-none-eabi gcc
-* Native gdb
-
-The sequence of events when using the Docker image is as follows:
-
-1. A new docker environment is created in the Linux VM.
-2. The specified command with the newtvm prefix (`newtvm newt` command) is sent to the docker environment via ssh.
-3. The Linux command runs.
-4. The output from the command is sent back to Windows via ssh.
-5. The output is displayed in the Windows command prompt.
-
-
-#### Install Linux virtual machine
-
-* Download the Docker Toolbox for Windows (version 1.9.0c or later) from [https://www.docker.com/docker-toolbox](https://www.docker.com/docker-toolbox). The Docker toolbox creates a consistently reproducible and self-contained environment in Linux.
-
-* Run the Docker Toolbox installer. All the default settings are OK.
-
-* You may need to add "C:\Program Files\Git\usr\bin" to your PATH
-environment variable. To add to the PATH environment variable, right-click on the Start button in the bottom left corner. Choose System -> Advanced system settings -> Environment Variables. Click on the PATH variable under "System variables" and click Edit to check and add it if it is not already there.
-
-#### Install newtvm tool
-
-* From your base user (home) directory, pull or clone the latest code from the newt repository into the `newt` directory. It includes the executable `newtvm.exe` for the newtvm tool in the `newtvm` directory.
-```c
- C:\Users\admin> git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt newt
-```
- The newtvm tool is what allows you to run programs in the Linux docker
-instance.
-
-* Run the Docker Quickstart Terminal application inside the Docker folder under Programs. You can find it by clicking Start button -> All apps. By default, the Docker Toolbox installer creates a shortcut to this program on your desktop. Wait until you see an ASCII art whale displayed in the terminal window and the Docker prompt given.
-
-
-```c
- ## .
- ## ## ## ==
- ## ## ## ## ## ===
- /"""""""""""""""""\___/ ===
- ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
- \______ o __/
- \ \ __/
- \____\_______/
-
- docker is configured to use the default machine with IP 192.168.99.100
- For help getting started, check out the docs at https://docs.docker.com
-
- admin@dev1 MINGW64 ~ (master)
- $
-```
-
- The first time you run this, it may take several minutes to complete. You will need to run the Docker Quickstart Terminal once each time you
-restart your computer.
-
-* Open a command prompt (e.g., Windows-R, "cmd", enter). You execute the newt tool commands as though you were running newt in Linux, but you prefix each command with "newtvm". For example:
-```c
- C:\Users\admin\newt\newtvm> newtvm newt help
-```
-
- The newtvm tool will take a long time to run the first time you execute
-it. The delay is due to the fact that the tool must download the mynewt
-docker instance.
-
-* You are now ready to proceed to [building the image for the simulated target](#building-test-code-on-simulator).
-
-
-### Getting your Windows machine ready for hardware target
-
-When you want to produce images for actual hardware board on your Windows machine, go through the following setup procedure and then proceed to the [blinky project on the Olimex board](#Using-SRAM-to-make-LED-blink) with this method.
-
-#### Installing some prerequisites
-
-* You have to install the following if you do not have them already. The steps below indicate specific folders where each of these programs should be installed. You can choose different locations, but the remainder of this
-tutorial for a Windows machine assumes the specified folders.
-
- * win-builds-i686
- * win-builds-x86_64
- * MSYS
- * gcc for ARM
- * openocd
- * zadig
- * git
- * go
-
- - *win-builds (mingw64) 1.5 for i686*
-
- Download from [http://win-builds.org/doku.php/download_and_installation_from_windows](http://win-builds.org/doku.php/download_and_installation_from_windows). Install at: "C:\win-builds-i686".
-
- Be sure to click the i686 option (not x86_64). The defaults for all other options are OK. The installer will want to download a bunch of additional packages. They are not all necessary, but it is simplest to just accept the defaults.
-
- - *win-builds (mingw64) 1.5 for x86_64*
-
- Download from [http://win-builds.org/doku.php/download_and_installation_from_windows](http://win-builds.org/doku.php/download_and_installation_from_windows). Install at "C:\win-builds-x86_64"
-
- Run the installer a second time, but this time click the x86_64 option, NOT i686. The defaults for all other options are OK.
-
- - *MSYS*
-
- Start your download from [http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20111123.zip](http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20111123.zip)
-
- Unzip to "C:\msys"
-
- - *gcc for ARM, 4.9.3*
-
- Download the Windows installer from [https://launchpad.net/gcc-arm-embedded/+download](https://launchpad.net/gcc-arm-embedded/+download) and install at "C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3".
-
- - OpenOCD 0.8.0
-
- Download OpenOCD 0.8.0 from [http://www.freddiechopin.info/en/download/category/4-openocd](http://www.freddiechopin.info/en/download/category/4-openocd). Unzip to "C:\openocd".
-
- - Zadig 2.1.2
-
- Download it from [http://zadig.akeo.ie](http://zadig.akeo.ie) and install it at "C:\zadig".
-
- - Git
-
- Click on [https://git-scm.com/download/win](https://git-scm.com/download/win) to start the download. Install at "C:\Program Files (x86)\Git". Specify the "Use Git from the Windows Command Prompt" option. The defaults for all other options are OK.
-
- - Go
-
- Download the release for Microsoft Windows from [https://golang.org/dl/](https://golang.org/dl/) and install it "C:\Go".
-
-
-#### Creating local repository
-
-* The directory structure must be first readied for using Go. Go code must be kept inside a workspace. A workspace is a directory hierarchy with three directories at its root:
-
- * src contains Go source files organized into packages (one package per directory),
-
- * pkg contains package objects, and
-
- * bin contains executable commands.
-
- The GOPATH environment variable specifies the location of your workspace. First create a 'dev' directory and then a 'go' directory under it. Set the GOPATH environment variable to this directory and then proceed to create the directory for cloning the newt tool repository.
-```c
- $ cd c:\
- $ mkdir dev\go
- $ cd dev\go
-```
-* Set the following user environment variables using the steps outlined here.
-```c
- * GOPATH: C:\dev\go
- * PATH: C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\bin;%GOPATH%\bin;C:\win-builds-x86_64\bin;C:\win-builds-i686\bin;C:\msys\bin
-```
-Steps:
-
-1. Right-click the start button
-2. Click "Control panel"
-3. Click "System and Security"
-4. Click "System"
-5. Click "Advanced system settings" in the left panel
-6. Click the "Envoronment Variables..." button
-7. There will be two sets of environment variables: user variables
- in the upper half of the screen, and system variables in the lower
- half. Configuring the user variables is recommended and tested
- (though system variables will work as well).
-
-
-* Next, install godep. Note that the following command produces no output.
-```c
- $ go get github.com/tools/godep
-```
-* Set up the repository for the package building tool "newt" on your local machine. First create the appropriate directory for it and then clone the newt tool repository from the online apache repository (or its github.com mirror) into this newly created directory. Check the contents of the directory.
-```c
- $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt
- $ dir
- bin pkg src
- $ dir src
- git-wip-us.apache.org github.com gopkg.in
- $ dir
- newt
- $ cd newt
- $ dir
- Godeps README.md coding_style.txt newt.go
- LICENSE cli design.txt
-```
-* Check that newt is in place.
-```c
- $ dir $GOPATH\src\git-wip-us.apache.org\repos\asf\incubator-mynewt-newt.git\newt
- Godeps README.md coding_style.txt newt.go
- LICENSE cli design.txt
-```
-
-
-#### Building the newt tool
-
-* You will use Go to run the newt.go program to build the newt tool. The command used is `go install` which compiles and writes the resulting executable to an output file named `newt`. It installs the results along with its dependencies in $GOPATH/bin.
-```c
- $ go install
- $ ls "$GOPATH"/bin/
- godep incubator-mynewt-newt.git newt
-```
-* Try running newt using the compiled binary. For example, check for the version number by typing 'newt version'. See all the possible commands available to a user of newt by typing 'newt -h'.
-
- Note: If you are going to be be modifying the newt tool itself often and wish to compile the program every time you call it, you may want to define the newt environment variable that allows you to execute the command via `%newt%`. Use `set newt=go run %GOPATH%\src\github.com\mynewt\newt\newt.go` or set it from the GUI. Here, you use `go run` which runs the compiled binary directly without producing an executable.
-```c
- $ newt version
- Newt version: 1.0
- $ newt -h
- Newt allows you to create your own embedded project based on the Mynewt
- operating system. Newt provides both build and package management in a
- single tool, which allows you to compose an embedded workspace, and set
- of projects, and then build the necessary artifacts from those projects.
- For more information on the Mynewt operating system, please visit
- https://www.github.com/mynewt/documentation.
-
- Please use the newt help command, and specify the name of the command
- you want help for, for help on how to use a specific command
-
- Usage:
- newt [flags]
- newt [command]
-
- Examples:
- newt
- newt help [<command-name>]
- For help on <command-name>. If not specified, print this message.
-
-
- Available Commands:
- version Display the Newt version number.
- target Set and view target information
- egg Commands to list and inspect eggs on a nest
- nest Commands to manage nests & clutches (remote egg repositories)
- help Help about any command
-
- Flags:
- -h, --help=false: help for newt
- -l, --loglevel="WARN": Log level, defaults to WARN.
- -q, --quiet=false: Be quiet; only display error output.
- -s, --silent=false: Be silent; don't output anything.
- -v, --verbose=false: Enable verbose output when executing commands.
-
-
- Use "newt help [command]" for more information about a command.
-```
-* Without creating a project repository you can't do a whole lot with the Newt tool. So you'll have to wait till you have downloaded a nest to try out the tool.
-
-#### Getting the debugger ready
-
-* Use Zadig to configure the USB driver for your Olimex debugger. If your debugger is already set up, you can skip this step.
-
-1. Plug in your Olimex debugger.
-2. Start Zadig.
-3. Check the Options -> List All Devices checkbox.
-4. Select "Olimex OpenOCD JTAG ARM-USB-TINY-H" in the dropdown menu.
-5. Select the "WinUSB" driver.
-6. Click the "Install Driver" button.
-
-* Proceed to the section on how to [make an LED blink](#using-sram-to-make-led-blink) section.
-
diff --git a/docs/os/tutorials/codesize.md b/docs/os/tutorials/codesize.md
deleted file mode 100644
index f045ce9..0000000
--- a/docs/os/tutorials/codesize.md
+++ /dev/null
@@ -1,20 +0,0 @@
-## How to Reduce Application Code Size
-
-Gettng your application to fit in an image slot can be challenging,
-particularly on flash constrained hardware such as the nRF51. Below are
-some suggested system configuration settings that reduce the code size of your Mynewt image.
-
-
-|Setting | Description |
-| ------------------ | --------------------------------------------- |
-| LOG_LEVEL: 255 | Disable all logging. |
-| LOG_CLI: 0 | Disable log shell commands. |
-| STATS_CLI: 0 | Disable stats shell commands. |
-| SHELL_TASK: 0 | Disable the interactive shell. |
-| SHELL_OS_MODULE: 0 | Disable memory management shell commands. |
-| SHELL_CMD_HELP: 0 | Disable help for shell commands. |
-
-You can use the `newt target set` command to set the syscfg settings in the `syscfg.yml` file for the target. See the [Newt Tool Command Guide](/newt/command_list/newt_target) for the command syntax.
-
-**Note:** The `newt target set` command deletes all the current syscfg settings in the target `syscfg.yml` file and only sets the syscfg settings specified in the command. If you are experimenting with different settings to see how they affect the code size and do not want to reenter all the setting values in the `newt target set` command, you can use the `newt target amend` command. This command adds or updates only the settings specified in the command and does not overwrite other setting values. While you can also edit the target `syscfg.yml` file directly, we recommend that you use the `newt target` commands.
-
diff --git a/docs/os/tutorials/define_target.md b/docs/os/tutorials/define_target.md
deleted file mode 100644
index 5492e92..0000000
--- a/docs/os/tutorials/define_target.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## How to Define a Target
-
-What newt commands to use?
\ No newline at end of file
diff --git a/docs/os/tutorials/downloads/openocd-wnrf52.tgz b/docs/os/tutorials/downloads/openocd-wnrf52.tgz
deleted file mode 100644
index e8dfd7f..0000000
--- a/docs/os/tutorials/downloads/openocd-wnrf52.tgz
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/eddystone.md b/docs/os/tutorials/eddystone.md
deleted file mode 100644
index 6060fe1..0000000
--- a/docs/os/tutorials/eddystone.md
+++ /dev/null
@@ -1,345 +0,0 @@
-## BLE Eddystone
-
-<br>
-
-### Eddystone Beacon Protocol
-
-A beaconing device announces its presence to the world by broadcasting
-advertisements. The Eddystone protocol is built on top of the standard BLE
-advertisement specification. Eddystone supports multiple data packet types:
-
-* Eddystone-UID: a unique, static ID with a 10-byte Namespace component and a 6-byte Instance component.
-* Eddystone-URL: a compressed URL that, once parsed and decompressed, is directly usable by the client.
-* Eddystone-TLM: "telemetry" packets that are broadcast alongside the Eddystone-UID or Eddystone-URL packets and contains beacon’s “health status” (e.g., battery life).
-* Eddystone-EID to broadcast an ephemeral identifier that changes every few minutes and allow only parties that can resolve the identifier to use the beacon.
-
-[This page](https://developers.google.com/beacons/eddystone) describes the Eddystone open beacon format developed by Google.
-
-Apache Mynewt currently supports Eddystone-UID and Eddystone-URL formats only.
-This tutorial will explain how to get an Eddystone-URL beacon going on a
-peripheral device.
-
-<br>
-
-### Create an Empty BLE Application
-
-This tutorial picks up where the
-[BLE bare bones application tutorial](../../os/tutorials/ble_bare_bones.md)
-concludes. The first step in creating a beaconing device is to create an empty
-BLE app, as explained in that tutorial. Before proceeding, you should have:
-
-* An app called "ble_app".
-* A target called "ble_tgt".
-* Successfully executed the app on your target device.
-
-### Add beaconing
-
-Here is a brief specification of how we want our beaconing app to behave:
-
-1. Wait until the host and controller are in sync.
-2. Configure the NimBLE stack with an address to put in its advertisements.
-3. Advertise an eddystone URL beacon indefinitely.
-
-Let's take these one at a time.
-
-<br>
-#### 1. Wait for host-controller sync
-
-The first step, waiting for host-controller-sync, is mandatory in all BLE
-applications. The NimBLE stack is inoperable while the two components are out
-of sync. In a combined host-controller app, the sync happens immediately at
-startup. When the host and controller are separate, sync typically occurs
-in less than a second.
-
-We achieve this by configuring the NimBLE host with a callback function that
-gets called when sync takes place:
-
-
-```c hl_lines="1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 24"
-static void
-ble_app_set_addr()
-{ }
-
-static void
-ble_app_advertise();
-{ }
-
-static void
-ble_app_on_sync(void)
-{
- /* Generate a non-resolvable private address. */
- ble_app_set_addr();
-
- /* Advertise indefinitely. */
- ble_app_advertise();
-}
-
-int
-main(int argc, char **argv)
-{
- sysinit();
-
- ble_hs_cfg.sync_cb = ble_app_on_sync;
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-}
-```
-
-`ble_hs_cfg.sync_cb` points to the function that should be called when sync
-occurs. Our callback function, `ble_app_on_sync()`, kicks off the control flow
-that we specified above. Now we need to fill in the two stub functions.
-
-<br>
-#### 2. Configure the NimBLE stack with an address
-
-A BLE device needs an address to do just about anything. Some devices have a
-public Bluetooth address burned into them, but this is not always the case.
-Furthermore, the NimBLE controller might not know how to read an address out of
-your particular hardware. For a beaconing device, we generally don't care what
-address gets used since nothing will be connecting to us.
-
-A reliable solution is to generate a *non-resolvable private address* (nRPA)
-each time the application runs. Such an address contains no identifying
-information, and they are expected to change frequently.
-
-```c hl_lines="4 5 6 7 8 9 10 11"
-static void
-ble_app_set_addr(void)
-{
- ble_addr_t addr;
- int rc;
-
- rc = ble_hs_id_gen_rnd(1, &addr);
- assert(rc == 0);
-
- rc = ble_hs_id_set_rnd(addr.val);
- assert(rc == 0);
-}
-
-static void
-ble_app_advertise();
-{ }
-
-static void
-ble_app_on_sync(void)
-{
- /* Generate a non-resolvable private address. */
- ble_app_set_addr();
-
- /* Advertise indefinitely. */
- ble_app_advertise();
-}
-```
-
-Our new function, `ble_app_set_addr()`, makes two calls into the stack:
-
-* [`ble_hs_id_gen_rnd`](../../network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd.md): Generate an nRPA.
-* [`ble_hs_id_set_rnd`](../../network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd.md): Configure NimBLE to use the newly-generated address.
-
-You can click either of the function names for more detailed documentation.
-
-<br>
-#### 3. Advertise indefinitely
-
-The first step in advertising is to configure the host with advertising data.
-This operation tells the host what data to use for the contents of its
-advertisements. The NimBLE host provides special helper functions for
-configuring eddystone advertisement data:
-
-* [`ble_eddystone_set_adv_data_uid`](../../network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_uid.md)
-* [`ble_eddystone_set_adv_data_url`](../../network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_url.md)
-
-Our application will advertise eddystone URL beacons, so we are interested in
-the second function. We reproduce the function prototype here:
-
-```c
-int
-ble_eddystone_set_adv_data_url(
- struct ble_hs_adv_fields *adv_fields,
- uint8_t url_scheme,
- char *url_body,
- uint8_t url_body_len,
- uint8_t url_suffix
-)
-```
-
-We'll advertise the Mynewt URL: *https://mynewt.apache.org*. Eddystone beacons
-use a form of URL compression to accommodate the limited space available in
-Bluetooth advertisements. The `url_scheme` and `url_suffix` fields implement
-this compression; they are single byte fields which correspond to strings
-commonly found in URLs. The following arguments translate to the
-https://mynewt.apache.org URL:
-
-| Parameter | Value |
-|--------------|-------|
-| url_scheme | `BLE_EDDYSTONE_URL_SCHEME_HTTPS` |
-| url_body | "mynewt.apache" |
-| url_suffix | `BLE_EDDYSTONE_URL_SUFFIX_ORG` |
-
-```c
-static void
-ble_app_advertise(void)
-{
- struct ble_hs_adv_fields fields;
- int rc;
-
- /* Configure an eddystone URL beacon to be advertised;
- * URL: https://apache.mynewt.org
- */
- fields = (struct ble_hs_adv_fields){ 0 };
- rc = ble_eddystone_set_adv_data_url(&fields,
- BLE_EDDYSTONE_URL_SCHEME_HTTPS,
- "mynewt.apache",
- 13,
- BLE_EDDYSTONE_URL_SUFFIX_ORG);
- assert(rc == 0);
-
- /* TODO: Begin advertising. */
-}
-```
-
-Now that the host knows what to advertise, the next step is to actually begin
-advertising. The function to initiate advertising is:
-[`ble_gap_adv_start`](../../network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md).
-This function takes several parameters. For simplicity, we reproduce the
-function prototype here:
-
-```c
-int
-ble_gap_adv_start(
- uint8_t own_addr_type,
- const ble_addr_t *direct_addr,
- int32_t duration_ms,
- const struct ble_gap_adv_params *adv_params,
- ble_gap_event_fn *cb,
- void *cb_arg
-)
-```
-
-This function gives an application quite a bit of freedom in how advertising is
-to be done. The default values are mostly fine for our simple beaconing
-application. We will pass the following values to this function:
-
-
-| Parameter | Value | Notes |
-|-----------|-------|-------|
-| own_addr_type | BLE_OWN_ADDR_RANDOM | Use the nRPA we generated earlier. |
-| direct_addr | NULL | We are broadcasting, not targeting a peer. |
-| duration_ms | BLE_HS_FOREVER | Advertise indefinitely. |
-| adv_params | defaults | Can be used to specify low level advertising parameters. |
-| cb | NULL | We are non-connectable, so no need for an event callback. |
-| cb_arg | NULL | No callback implies no callback argument. |
-
-These arguments are mostly self-explanatory. The exception is `adv_params`,
-which can be used to specify a number of low-level parameters. For a beaconing
-application, the default settings are appropriate. We specify default settings
-by providing a zero-filled instance of the `ble_gap_adv_params` struct as our
-argument.
-
-```c hl_lines="4 19 20 21 22 23"
-static void
-ble_app_advertise(void)
-{
- struct ble_gap_adv_params adv_params;
- struct ble_hs_adv_fields fields;
- int rc;
-
- /* Configure an eddystone URL beacon to be advertised;
- * URL: https://apache.mynewt.org
- */
- fields = (struct ble_hs_adv_fields){ 0 };
- rc = ble_eddystone_set_adv_data_url(&fields,
- BLE_EDDYSTONE_URL_SCHEME_HTTPS,
- "mynewt.apache",
- 13,
- BLE_EDDYSTONE_URL_SUFFIX_ORG);
- assert(rc == 0);
-
- /* Begin advertising. */
- adv_params = (struct ble_gap_adv_params){ 0 };
- rc = ble_gap_adv_start(BLE_OWN_ADDR_RANDOM, NULL, BLE_HS_FOREVER,
- &adv_params, NULL, NULL);
- assert(rc == 0);
-}
-```
-
-### Conclusion
-
-That's it! Now when you run this app on your board, you should be able to see
-it with all your eddystone-aware devices. You can test it out with the
-`newt run` command.
-
-### Source Listing
-
-For reference, here is the complete application source:
-
-```c
-#include "sysinit/sysinit.h"
-#include "os/os.h"
-#include "console/console.h"
-#include "host/ble_hs.h"
-
-static void
-ble_app_set_addr(void)
-{
- ble_addr_t addr;
- int rc;
-
- rc = ble_hs_id_gen_rnd(1, &addr);
- assert(rc == 0);
-
- rc = ble_hs_id_set_rnd(addr.val);
- assert(rc == 0);
-}
-
-static void
-ble_app_advertise(void)
-{
- struct ble_gap_adv_params adv_params;
- struct ble_hs_adv_fields fields;
- int rc;
-
- /* Configure an eddystone URL beacon to be advertised;
- * URL: https://apache.mynewt.org
- */
- fields = (struct ble_hs_adv_fields){ 0 };
- rc = ble_eddystone_set_adv_data_url(&fields,
- BLE_EDDYSTONE_URL_SCHEME_HTTPS,
- "mynewt.apache",
- 13,
- BLE_EDDYSTONE_URL_SUFFIX_ORG);
- assert(rc == 0);
-
- /* Begin advertising. */
- adv_params = (struct ble_gap_adv_params){ 0 };
- rc = ble_gap_adv_start(BLE_OWN_ADDR_RANDOM, NULL, BLE_HS_FOREVER,
- &adv_params, NULL, NULL);
- assert(rc == 0);
-}
-
-static void
-ble_app_on_sync(void)
-{
- /* Generate a non-resolvable private address. */
- ble_app_set_addr();
-
- /* Advertise indefinitely. */
- ble_app_advertise();
-}
-
-int
-main(int argc, char **argv)
-{
- sysinit();
-
- ble_hs_cfg.sync_cb = ble_app_on_sync;
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-}
-```
diff --git a/docs/os/tutorials/event_queue.md b/docs/os/tutorials/event_queue.md
deleted file mode 100644
index 331ec4b..0000000
--- a/docs/os/tutorials/event_queue.md
+++ /dev/null
@@ -1,495 +0,0 @@
-
-## How to Use Event Queues to Manage Multiple Events
-
-### Introduction
-
-The event queue mechanism allows you to serialize incoming events for your task. You can use it to get information about hardware interrupts, callout expirations, and messages from other tasks.
-
-The benefit of using events for inter-task communication is that it can reduce the number of resources that need to be shared and locked.
-
-The benefit of processing interrupts in a task context instead of the interrupt context is that other interrupts and high priority tasks are not blocked waiting for the interrupt handler to complete processing. A task can also access other OS facilities and sleep.
-
-This tutorial assumes that you have read about [Event Queues](../core_os/event_queue/event_queue.md), the [Hardware Abstraction Layer](../modules/hal/hal.md), and [OS Callouts](../core_os/callout/callout.md) in the OS User's Guide.
-
-This tutorial shows you how to create an application that uses events for:
-
-* Inter-task communication
-* OS callouts for timer expiration
-* GPIO interrupts
-
-It also shows you how to:
-
-* Use the Mynewt default event queue and application main task to process your events.
-* Create a dedicated event queue and task for your events.
-
-To reduce an application's memory requirement, we recommend that you use the Mynewt default event queue if your application or package does not have real-time timing requirements.
-
-### Prerequisites
-
-Ensure that you have met the following prerequisites before continuing with this tutorial:
-
-* Install the newt tool.
-* Install the newtmgr tool.
-* Have Internet connectivity to fetch remote Mynewt components.
-* Install the compiler tools to support native compiling to build the project this tutorial creates.
-* Have a cable to establish a serial USB connection between the board and the laptop.
-
-### Example Application
-
-In this example, you will write an application, for the Nordic nRF52 board, that uses events from three input sources to toggle three GPIO outputs and light up the LEDs. If you are using a different board, you will need to adjust the GPIO pin numbers in the code example.
-
-The application handles events from three sources on two event queues:
-
-* Events generated by an application task at periodic intervals are added to the Mynewt default event queue.
-* OS callouts for timer events are added to the `my_timer_interrupt_eventq` event queue.
-* GPIO interrupt events are added to the `my_timer_interrupt_eventq` event queue.
-<br>
-#### Create the Project
-Follow the instructions in the [nRF52 tutorial](nRF52.md) to create a project.
-<br>
-#### Create the Application
-Create the `pkg.yml` file for the application:
-
-```no-highlight
-pkg.name: apps/eventq_example
-pkg.type: app
-
-pkg.deps:
- - kernel/os
- - hw/hal
- - sys/console/stub
-```
-<br>
-#### Application Task Generated Events
-
-The application creates a task that generates events, at periodic intervals, to toggle the LED at pin `TASK_LED`. The event is queued on the Mynewt default event queue and is processed in the context of the application main task.
-
-Declare and initialize the `gen_task_ev` event with the `my_ev_cb()` callback function to process the event:
-
-```c
-
-/* Callback function for application task event */
-static void my_ev_cb(struct os_event *);
-
-/* Initialize the event with the callback function */
-static struct os_event gen_task_ev = {
- .ev_cb = my_ev_cb,
-};
-
-```
-
-<br>
-Implement the `my_ev_cb()` callback function to process a task generated event and toggle the LED at pin `TASK_LED`:
-
-```c
-
-/* LED 1 (P0.17 on the board) */
-#define TASK_LED 17
-
-/*
- * Event callback function for events generated by gen_task. It toggles
- * the LED at pin TASK_LED.
- */
-static void my_ev_cb(struct os_event *ev)
-{
- assert(ev);
- hal_gpio_toggle(TASK_LED);
- return;
-}
-
-```
-<br>
-Create a task that generates an event at periodic intervals and adds, using the `os_eventq_put()` function, the event to the Mynewt default event queue:
-
-```c
-
-#define GEN_TASK_PRIO 3
-#define GEN_TASK_STACK_SZ 512
-
-static os_stack_t gen_task_stack[GEN_TASK_STACK_SZ];
-static struct os_task gen_task_str;
-
-/*
- * Task handler to generate an event to toggle the LED at pin TASK_LED.
- * The event is added to the Mynewt default event queue.
- */
-static void
-gen_task(void *arg)
-{
- while (1) {
- os_time_delay(OS_TICKS_PER_SEC / 4);
- os_eventq_put(os_eventq_dflt_get(), &gen_task_ev);
- }
-}
-
-static void
-init_tasks(void)
-{
-
- /* Create a task to generate events to toggle the LED at pin TASK_LED */
-
- os_task_init(&gen_task_str, "gen_task", gen_task, NULL, GEN_TASK_PRIO,
- OS_WAIT_FOREVER, gen_task_stack, GEN_TASK_STACK_SZ);
-
- ...
-
-}
-
-```
-<br>
-Implement the application `main()` function to call the `os_eventq_run()` function to dequeue an event from the Mynewt default event queue and call the callback function to process the event.
-
-```c
-
-int
-main(int argc, char **argv)
-{
- sysinit();
-
- init_tasks();
-
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
- assert(0);
-}
-
-```
-
-<br>
-#### OS Callout Timer Events
-
-Set up OS callout timer events. For this example, we use a dedicated event queue for timer events to show you how to create a dedicated event queue and a task to process the events.
-
-
-Implement the `my_timer_ev_cb()` callback function to process a timer event and toggle the LED at pin `CALLOUT_LED`:
-
-```c
-
-/* LED 2 (P0.18 on the board) */
-#define CALLOUT_LED 18
-
-/* The timer callout */
-static struct os_callout my_callout;
-
-/*
- * Event callback function for timer events. It toggles the LED at pin CALLOUT_LED.
- */
-static void my_timer_ev_cb(struct os_event *ev)
-{
- assert(ev != NULL);
-
- hal_gpio_toggle(CALLOUT_LED);
-
- os_callout_reset(&my_callout, OS_TICKS_PER_SEC / 2);
-}
-
-```
-<br>
-In the `init_tasks()` function, initialize the `my_timer_interrupt_eventq` event queue, create a task to process events from the queue, and initialize the OS callout for the timer:
-
-```c
-#define MY_TIMER_INTERRUPT_TASK_PRIO 4
-#define MY_TIMER_INTERRUPT_TASK_STACK_SZ 512
-
-static os_stack_t my_timer_interrupt_task_stack[MY_TIMER_INTERRUPT_TASK_STACK_SZ];
-static struct os_task my_timer_interrupt_task_str;
-
-static void
-init_tasks(void)
-{
- /* Use a dedicate event queue for timer and interrupt events */
-
- os_eventq_init(&my_timer_interrupt_eventq);
-
- /*
- * Create the task to process timer and interrupt events from the
- * my_timer_interrupt_eventq event queue.
- */
- os_task_init(&my_timer_interrupt_task_str, "timer_interrupt_task",
- my_timer_interrupt_task, NULL,
- MY_TIMER_INTERRUPT_TASK_PRIO, OS_WAIT_FOREVER,
- my_timer_interrupt_task_stack,
- MY_TIMER_INTERRUPT_TASK_STACK_SZ);
- /*
- * Initialize the callout for a timer event.
- * The my_timer_ev_cb callback function processes the timer events.
- */
- os_callout_init(&my_callout, &my_timer_interrupt_eventq,
- my_timer_ev_cb, NULL);
-
- os_callout_reset(&my_callout, OS_TICKS_PER_SEC);
-
-}
-```
-<br>
-Implement the `my_timer_interrupt_task()` task handler to dispatch events from the `my_timer_interrupt_eventq` event queue:
-
-```c
-
-static void
-my_timer_interrupt_task(void *arg)
-{
- while (1) {
- os_eventq_run(&my_timer_interrupt_eventq);
- }
-}
-
-```
-<br>
-#### Interrupt Events
-
-The application toggles the LED each time button 1 on the board is pressed. The interrupt handler generates an event when the GPIO for button 1 (P0.13) changes state. The events are added to the `my_timer_interrupt_eventq` event queue, the same queue as the timer events.
-
-Declare and initialize the `gpio_ev` event with the `my_interrupt_ev_cb()` callback function to process the event:
-
-```c
-static struct os_event gpio_ev {
- .ev_cb = my_interrupt_ev_cb,
-};
-
-```
-<br>
-Implement the `my_interrupt_ev_cb()` callback function to process an interrupt event and toggle the LED at pin `GPIO_LED`:
-
-```c
-
-/* LED 3 (P0.19 on the board) */
-#define GPIO_LED 19
-
-/*
- * Event callback function for interrupt events. It toggles the LED at pin GPIO_LED.
- */
-static void my_interrupt_ev_cb(struct os_event *ev)
-{
- assert(ev != NULL);
-
- hal_gpio_toggle(GPIO_LED);
-}
-```
-<br>
-
-Implement the `my_gpio_irq()` handler to post an interrupt event to the `my_timer_interrupt_eventq` event queue:
-
-```c
-static void
-my_gpio_irq(void *arg)
-{
- os_eventq_put(&my_timer_interrupt_eventq, &gpio_ev);
-}
-```
-<br>
-
-In the `init_tasks()` function, add the code to set up and enable the GPIO input pin for the button and initialize the GPIO output pins for the LEDs:
-
-```c
-/* LED 1 (P0.17 on the board) */
-#define TASK_LED 17
-
-/* 2 (P0.18 on the board) */
-#define CALLOUT_LED 18
-
-/* LED 3 (P0.19 on the board) */
-#define GPIO_LED 19
-
-/* Button 1 (P0.13 on the board) */
-#define BUTTON1_PIN 13
-
-void
-init_tasks()
-
- /* Initialize OS callout for timer events. */
-
- ....
-
- /*
- * Initialize and enable interrupts for the pin for button 1 and
- * configure the button with pull up resistor on the nrf52dk.
- */
- hal_gpio_irq_init(BUTTON1_PIN, my_gpio_irq, NULL, HAL_GPIO_TRIG_RISING, HAL_GPIO_PULL_UP);
-
- hal_gpio_irq_enable(BUTTON1_PIN);
-
- /* Initialize the GPIO output pins. Value 1 is off for these LEDs. */
-
- hal_gpio_init_out(TASK_LED, 1);
- hal_gpio_init_out(CALLOUT_LED, 1);
- hal_gpio_init_out(GPIO_LED, 1);
-}
-```
-<br>
-### Putting It All Together
-
-Here is the complete `main.c` source for your application. Build the application and load it on your board. The task LED (LED1) blinks at an interval of 250ms, the callout LED (LED2) blinks at an interval of 500ms, and the GPIO LED (LED3) toggles on or off each time you press Button 1.
-
-
-```c
-#include <os/os.h>
-#include <bsp/bsp.h>
-#include <hal/hal_gpio.h>
-#include <assert.h>
-#include <sysinit/sysinit.h>
-
-
-#define MY_TIMER_INTERRUPT_TASK_PRIO 4
-#define MY_TIMER_INTERRUPT_TASK_STACK_SZ 512
-
-#define GEN_TASK_PRIO 3
-#define GEN_TASK_STACK_SZ 512
-
-/* LED 1 (P0.17 on the board) */
-#define TASK_LED 17
-
-/* LED 2 (P0.18 on the board) */
-#define CALLOUT_LED 18
-
-/* LED 3 (P0.19 on the board) */
-#define GPIO_LED 19
-
-/* Button 1 (P0.13 on the board) */
-#define BUTTON1_PIN 13
-
-
-static void my_ev_cb(struct os_event *);
-static void my_timer_ev_cb(struct os_event *);
-static void my_interrupt_ev_cb(struct os_event *);
-
-static struct os_eventq my_timer_interrupt_eventq;
-
-static os_stack_t my_timer_interrupt_task_stack[MY_TIMER_INTERRUPT_TASK_STACK_SZ];
-static struct os_task my_timer_interrupt_task_str;
-
-static os_stack_t gen_task_stack[GEN_TASK_STACK_SZ];
-static struct os_task gen_task_str;
-
-static struct os_event gen_task_ev = {
- .ev_cb = my_ev_cb,
-};
-
-static struct os_event gpio_ev = {
- .ev_cb = my_interrupt_ev_cb,
-};
-
-
-static struct os_callout my_callout;
-
-/*
- * Task handler to generate an event to toggle the LED at pin TASK_LED.
- * The event is added to the Mynewt default event queue.
- */
-
-static void
-gen_task(void *arg)
-{
- while (1) {
- os_time_delay(OS_TICKS_PER_SEC / 4);
- os_eventq_put(os_eventq_dflt_get(), &gen_task_ev);
- }
-}
-
-/*
- * Event callback function for events generated by gen_task. It toggles the LED at pin TASK_LED.
- */
-static void my_ev_cb(struct os_event *ev)
-{
- assert(ev);
- hal_gpio_toggle(TASK_LED);
- return;
-}
-
-/*
- * Event callback function for timer events. It toggles the LED at pin CALLOUT_LED.
- */
-static void my_timer_ev_cb(struct os_event *ev)
-{
- assert(ev != NULL);
-
- hal_gpio_toggle(CALLOUT_LED);
- os_callout_reset(&my_callout, OS_TICKS_PER_SEC / 2);
-}
-
-/*
- * Event callback function for interrupt events. It toggles the LED at pin GPIO_LED.
- */
-static void my_interrupt_ev_cb(struct os_event *ev)
-{
- assert(ev != NULL);
-
- hal_gpio_toggle(GPIO_LED);
-}
-
-static void
-my_gpio_irq(void *arg)
-{
- os_eventq_put(&my_timer_interrupt_eventq, &gpio_ev);
-}
-
-
-
-static void
-my_timer_interrupt_task(void *arg)
-{
- while (1) {
- os_eventq_run(&my_timer_interrupt_eventq);
- }
-}
-
-void
-init_tasks(void)
-{
-
- /* Create a task to generate events to toggle the LED at pin TASK_LED */
-
- os_task_init(&gen_task_str, "gen_task", gen_task, NULL, GEN_TASK_PRIO,
- OS_WAIT_FOREVER, gen_task_stack, GEN_TASK_STACK_SZ);
-
-
- /* Use a dedicate event queue for timer and interrupt events */
- os_eventq_init(&my_timer_interrupt_eventq);
-
- /*
- * Create the task to process timer and interrupt events from the
- * my_timer_interrupt_eventq event queue.
- */
- os_task_init(&my_timer_interrupt_task_str, "timer_interrupt_task",
- my_timer_interrupt_task, NULL,
- MY_TIMER_INTERRUPT_TASK_PRIO, OS_WAIT_FOREVER,
- my_timer_interrupt_task_stack,
- MY_TIMER_INTERRUPT_TASK_STACK_SZ);
-
- /*
- * Initialize the callout for a timer event.
- * The my_timer_ev_cb callback function processes the timer event.
- */
- os_callout_init(&my_callout, &my_timer_interrupt_eventq,
- my_timer_ev_cb, NULL);
-
- os_callout_reset(&my_callout, OS_TICKS_PER_SEC);
-
- /*
- * Initialize and enable interrupt for the pin for button 1 and
- * configure the button with pull up resistor on the nrf52dk.
- */
- hal_gpio_irq_init(BUTTON1_PIN, my_gpio_irq, NULL, HAL_GPIO_TRIG_RISING, HAL_GPIO_PULL_UP);
-
- hal_gpio_irq_enable(BUTTON1_PIN);
-
- hal_gpio_init_out(TASK_LED, 1);
- hal_gpio_init_out(CALLOUT_LED, 1);
- hal_gpio_init_out(GPIO_LED, 1);
-}
-
-int
-main(int argc, char **argv)
-{
- sysinit();
-
- init_tasks();
-
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
- assert(0);
-}
-
-```
diff --git a/docs/os/tutorials/ibeacon.md b/docs/os/tutorials/ibeacon.md
deleted file mode 100644
index 5ae46a4..0000000
--- a/docs/os/tutorials/ibeacon.md
+++ /dev/null
@@ -1,296 +0,0 @@
-## BLE iBeacon
-
-This tutorial guides you through the process of creating an iBeacon application using NimBLE and Mynewt. At the conclusion of this tutorial, you will have a fully functional iBeacon app.
-
-### iBeacon Protocol
-
-A beaconing device announces its presence to the world by broadcasting
-advertisements. The iBeacon protocol is built on top of the standard BLE
-advertisement specification.
-[This page](http://www.warski.org/blog/2014/01/how-ibeacons-work/) provides a
-good summary of the iBeacon sub-fields.
-
-### Create an Empty BLE Application
-
-This tutorial picks up where the
-[BLE bare bones application tutorial](../../os/tutorials/ble_bare_bones.md)
-document concludes. The first step in creating a beaconing device is to create
-an empty BLE app, as explained in that tutorial. Before proceeding, you should
-have:
-
-* An app called "ble_app".
-* A target called "ble_tgt".
-* Successfully executed the app on your target device.
-
-### Add beaconing
-
-Here is a brief specification of how we want our beaconing app to behave:
-
-1. Wait until the host and controller are in sync.
-2. Configure the NimBLE stack with an address to put in its advertisements.
-3. Advertise indefinitely.
-
-Let's take these one at a time.
-
-<br>
-#### 1. Wait for host-controller sync
-
-The first step, waiting for host-controller-sync, is mandatory in all BLE
-applications. The NimBLE stack is inoperable while the two components are out
-of sync. In a combined host-controller app, the sync happens immediately at
-startup. When the host and controller are separate, sync typically occurs
-in less than a second.
-
-We achieve this by configuring the NimBLE host with a callback function that
-gets called when sync takes place:
-
-
-```c hl_lines="1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 24"
-static void
-ble_app_set_addr()
-{ }
-
-static void
-ble_app_advertise();
-{ }
-
-static void
-ble_app_on_sync(void)
-{
- /* Generate a non-resolvable private address. */
- ble_app_set_addr();
-
- /* Advertise indefinitely. */
- ble_app_advertise();
-}
-
-int
-main(int argc, char **argv)
-{
- sysinit();
-
- ble_hs_cfg.sync_cb = ble_app_on_sync;
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-}
-```
-
-`ble_hs_cfg.sync_cb` points to the function that should be called when sync
-occurs. Our callback function, `ble_app_on_sync()`, kicks off the control flow
-that we specified above. Now we need to fill in the two stub functions.
-
-<br>
-#### 2. Configure the NimBLE stack with an address
-
-A BLE device needs an address to do just about anything. Some devices have a
-public Bluetooth address burned into them, but this is not always the case.
-Furthermore, the NimBLE controller might not know how to read an address out of
-your particular hardware. For a beaconing device, we generally don't care what
-address gets used since nothing will be connecting to us.
-
-A reliable solution is to generate a *non-resolvable private address* (nRPA)
-each time the application runs. Such an address contains no identifying
-information, and they are expected to change frequently.
-
-```c hl_lines="4 5 6 7 8 9 10 11"
-static void
-ble_app_set_addr(void)
-{
- ble_addr_t addr;
- int rc;
-
- rc = ble_hs_id_gen_rnd(1, &addr);
- assert(rc == 0);
-
- rc = ble_hs_id_set_rnd(addr.val);
- assert(rc == 0);
-}
-
-static void
-ble_app_advertise();
-{ }
-
-static void
-ble_app_on_sync(void)
-{
- /* Generate a non-resolvable private address. */
- ble_app_set_addr();
-
- /* Advertise indefinitely. */
- ble_app_advertise();
-}
-```
-
-Our new function, `ble_app_set_addr()`, makes two calls into the stack:
-
-* [`ble_hs_id_gen_rnd`](../../network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd.md): Generate an nRPA.
-* [`ble_hs_id_set_rnd`](../../network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd.md): Configure NimBLE to use the newly-generated address.
-
-You can click either of the function names for more detailed documentation.
-
-<br>
-#### 3. Advertise indefinitely
-
-The first step in advertising is to configure the host with advertising data.
-This operation tells the host what data to use for the contents of its
-advertisements. The NimBLE host provides a special helper function for
-configuring iBeacon advertisement data:
-[`ble_ibeacon_set_adv_data`](../../network/ble/ble_hs/other/functions/ble_ibeacon_set_adv_data.md).
-
-If you follow the API link, you'll see that this function takes three parameters: a 128-bit UUID, a major version, and a minor version. This corresponds with the iBeacon specification, as these three items are the primary components in an iBeacon advertisement.
-
-For now, we'll advertise the following:
-
-* _UUID_: `11:11:11:11:11:11:11:11:11:11:11:11:11:11:11:11`
-* _Major_: 2
-* _Minor_: 10
-
-```c
-static void
-ble_app_advertise(void)
-{
- uint8_t uuid128[16];
- int rc;
-
- /* Fill the UUID buffer with a string of 0x11 bytes. */
- memset(uuid128, 0x11, sizeof uuid128);
-
- /* Major version=2; minor version=10. */
- rc = ble_ibeacon_set_adv_data(uuid128, 2, 10);
- assert(rc == 0);
-
- /* TODO: Begin advertising. */
-}
-```
-
-Now that the host knows what to advertise, the next step is to actually begin
-advertising. The function to initiate advertising is:
-[`ble_gap_adv_start`](../../network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md).
-This function takes several parameters. For simplicity, we reproduce the
-function prototype here:
-
-```c
-int
-ble_gap_adv_start(
- uint8_t own_addr_type,
- const ble_addr_t *direct_addr,
- int32_t duration_ms,
- const struct ble_gap_adv_params *adv_params,
- ble_gap_event_fn *cb,
- void *cb_arg
-)
-```
-
-This function gives an application quite a bit of freedom in how advertising is to be done. The default values are mostly fine for our simple beaconing application. We will pass the following values to this function:
-
-
-| Parameter | Value | Notes |
-|-----------|-------|-------|
-| own_addr_type | BLE_OWN_ADDR_RANDOM | Use the nRPA we generated earlier. |
-| direct_addr | NULL | We are broadcasting, not targeting a peer. |
-| duration_ms | BLE_HS_FOREVER | Advertise indefinitely. |
-| adv_params | defaults | Can be used to specify low level advertising parameters. |
-| cb | NULL | We are non-connectable, so no need for an event callback. |
-| cb_arg | NULL | No callback implies no callback argument. |
-
-These arguments are mostly self-explanatory. The exception is `adv_params`, which can be used to specify a number of low-level parameters. For a beaconing application, the default settings are appropriate. We specify default settings by providing a zero-filled instance of the `ble_gap_adv_params` struct as our argument.
-
-```c hl_lines="4 15 16 17 18 19"
-static void
-ble_app_advertise(void)
-{
- struct ble_gap_adv_params adv_params;
- uint8_t uuid128[16];
- int rc;
-
- /* Arbitrarily set the UUID to a string of 0x11 bytes. */
- memset(uuid128, 0x11, sizeof uuid128);
-
- /* Major version=2; minor version=10. */
- rc = ble_ibeacon_set_adv_data(uuid128, 2, 10);
- assert(rc == 0);
-
- /* Begin advertising. */
- adv_params = (struct ble_gap_adv_params){ 0 };
- rc = ble_gap_adv_start(BLE_OWN_ADDR_RANDOM, NULL, BLE_HS_FOREVER,
- &adv_params, NULL, NULL);
- assert(rc == 0);
-}
-```
-
-### Conclusion
-
-That's it! Now when you run this app on your board, you should be able to see
-it with all your iBeacon-aware devices. You can test it out with the
-`newt run` command.
-
-### Source Listing
-
-For reference, here is the complete application source:
-
-```c
-#include "sysinit/sysinit.h"
-#include "os/os.h"
-#include "console/console.h"
-#include "host/ble_hs.h"
-
-static void
-ble_app_set_addr(void)
-{
- ble_addr_t addr;
- int rc;
-
- rc = ble_hs_id_gen_rnd(1, &addr);
- assert(rc == 0);
-
- rc = ble_hs_id_set_rnd(addr.val);
- assert(rc == 0);
-}
-
-static void
-ble_app_advertise(void)
-{
- struct ble_gap_adv_params adv_params;
- uint8_t uuid128[16];
- int rc;
-
- /* Arbitrarily set the UUID to a string of 0x11 bytes. */
- memset(uuid128, 0x11, sizeof uuid128);
-
- /* Major version=2; minor version=10. */
- rc = ble_ibeacon_set_adv_data(uuid128, 2, 10);
- assert(rc == 0);
-
- /* Begin advertising. */
- adv_params = (struct ble_gap_adv_params){ 0 };
- rc = ble_gap_adv_start(BLE_OWN_ADDR_RANDOM, NULL, BLE_HS_FOREVER,
- &adv_params, NULL, NULL);
- assert(rc == 0);
-}
-
-static void
-ble_app_on_sync(void)
-{
- /* Generate a non-resolvable private address. */
- ble_app_set_addr();
-
- /* Advertise indefinitely. */
- ble_app_advertise();
-}
-
-int
-main(int argc, char **argv)
-{
- sysinit();
-
- ble_hs_cfg.sync_cb = ble_app_on_sync;
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-}
-```
diff --git a/docs/os/tutorials/lora/lorawanapp.md b/docs/os/tutorials/lora/lorawanapp.md
deleted file mode 100644
index b0f4332..0000000
--- a/docs/os/tutorials/lora/lorawanapp.md
+++ /dev/null
@@ -1,348 +0,0 @@
-## LoRaWAN App
-
-<br>
-
-### Objective
-
-The purpose of this tutorial is to demonstrate how to build the lora app shell application for either a class A or class C lora device and to perform basic functions such as joining and sending data packets to a lora gateway/server.
-
-NOTE: This tutorial presumes that you have a running lora gateway and lora network server. No description of the gateway/server is provided. It is expected that the user understands how to configure and operate the gateway/server so that it can communicate with a class A or class C device.
-
-<br>
-
-### Hardware needed
-
-* Telenor EE02 module
-* Segger J-Link or similar debugger
-* LORA gateway
-* Laptop running Mac OS
-* It is assumed you have already installed newt tool.
-* It is assumed you understand the basics of the mynewt OS
-* 3-wire serial cable to connect telenor module to your laptop
-* Some form of terminal emulation application running on your laptop.
-
-<br>
-
-### Create a project.
-
-Create a new project to hold your work. For a deeper understanding, you can read about project creation in
-[Get Started -- Creating Your First Project](../get_started/project_create.md)
-or just follow the commands below.
-
-```
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new mylora
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in mylora...
- Project mylora successfully created.
- $ cd mylora
-
-```
-
-<br>
-
-### Install Everything
-
-Now that you have defined the needed repositories, it's time to install everything so
-that you can get started.
-
-```
- $ newt install -v
- apache-mynewt-core
- Downloading repository description for apache-mynewt-core... success!
- ...
- apache-mynewt-core successfully installed version 1.2.0-none
- ...
-```
-
-<br>
-
-### Create the targets
-
-Create two targets - one for the bootloader and one for the lora app shell application.
-
-```no-highlight
-$ newt target create telee02_boot
-$ newt target set telee02_boot bsp=@apache-mynewt-core/hw/bsp/telee02
-$ newt target set telee02_boot app=@apache-mynewt-core/apps/boot
-$ newt target set telee02_boot build_profile=optimized
-
-$ newt target create lora_app_shell_telee02
-$ newt target set lora_app_shell_telee02 bsp=@apache-mynewt-core/hw/bsp/telee02
-$ newt target set lora_app_shell_telee02 app=@apache-mynewt-core/apps/lora_app_shell
-$ newt target set lora_app_shell_telee02 build_profile=optimized
-```
-The lora app shell application requires a few additional system configuration variables.
-Create and edit a file called syscfg.yml in dev/mylora/targets/lora_app_shell. The file
-contents should be the following:
-
-```
-### Package: targets/lora_app_shell_telee02
-
-syscfg.vals:
- SHELL_CMD_ARGC_MAX: "20"
- LORA_MAC_TIMER_NUM: "4"
- TIMER_4: "1"
-```
-
-You can now "display" the targets you created to make sure they are correct:
-
-```
-$ newt target show telee02_boot
-targets/telee02_boot
- app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/telee02
- build_profile=optimized
-
-$ newt target show lora_app_shell_telee02
-targets/lora_app_shell_telee02
- app=@apache-mynewt-core/apps/lora_app_shell
- bsp=@apache-mynewt-core/hw/bsp/telee02
- build_profile=optimized
- syscfg=LORA_MAC_TIMER_NUM=4:SHELL_CMD_ARGC_MAX=20:TIMER_4=1
-
-```
-
-<font color="#F2853F">
-Note: If you've already built and installed a bootloader for your ee02 module then you do
-not need to create a target for it here, or build and load it as below. </font>
-<br>
-
-### Build the target executables
-
-```
-$ newt clean telee02_boot
-$ newt build telee02_boot
-Building target targets/telee02_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-
- . . .
-
-Archiving telee02_boot-sysinit-app.a
-Archiving util_mem.a
-Linking /Users/wes/dev/wes/bin/targets/telee02_boot/app/apps/boot/boot.elf
-Target successfully built: targets/telee02_boot
-
-$ newt clean lora_app_shell_telee02
-$ newt build lora_app_shell_telee02
-Building target targets/lora_app_shell_telee02
-Assembling repos/apache-mynewt-core/hw/bsp/telee02/src/arch/cortex_m4/gcc_startup_nrf52_split.s
-Compiling repos/apache-mynewt-core/encoding/base64/src/hex.c
-Compiling repos/apache-mynewt-core/encoding/base64/src/base64.c
- . . .
-
-
-Archiving util_mem.a
-Archiving util_parse.a
-Linking /Users/wes/dev/wes/bin/targets/lora_app_shell_telee02/app/apps/lora_app_shell/lora_app_shell.elf
-Target successfully built: targets/lora_app_shell_telee0
-```
-<font color="#F2853F">
-Note: The newt clean step is not necessary but shown here for good measure. </font>
-<br>
-
-### Sign and create the application image
-
-You must sign and version your application image to download it using newt to the board.
-Use the newt create-image command to perform this action. You may assign an arbitrary
-version (e.g. 1.0.0) to the image.
-
-```
-$ newt create-image lora_app_shell_telee02 0.0.0
-App image succesfully generated: /Users/wes/dev/wes/bin/targets/lora_app_shell_telee02/app/apps/lora_app_shell/lora_app_shell.img
-```
-
-<font color="#F2853F">
-Note: Only the application image requires this step; the bootloader does not </font>
-<br>
-
-### Connect the board
-
-Connect the evaluation board via micro-USB to your PC via USB cable. Connect the Segger J-link debugger to the 9-pin
-SWD connector. Connect the UART pins (RX, TX and GND) to the board. Terminal settings 115200, N, 8, 1.
-
-<br>
-
-### Download bootloader and application
-
-
-<br>
-
-**Note:** If you want to erase the flash and load the image again, you can use JLinkExe to issue an `erase` command.
-
-```
-$ JLinkExe -device nRF52 -speed 4000 -if SWD
-SEGGER J-Link Commander V5.12c (Compiled Apr 21 2016 16:05:51)
-DLL version V5.12c, compiled Apr 21 2016 16:05:45
-
-Connecting to J-Link via USB...O.K.
-Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 15 2016 18:03:17
-Hardware version: V1.00
-S/N: 682863966
-VTref = 3.300V
-
-
-Type "connect" to establish a target connection, '?' for help
-J-Link>erase
-Cortex-M4 identified.
-Erasing device (0;?i?)...
-Comparing flash [100%] Done.
-Erasing flash [100%] Done.
-Verifying flash [100%] Done.
-J-Link: Flash download: Total time needed: 0.363s (Prepare: 0.093s, Compare: 0.000s, Erase: 0.262s, Program: 0.000s, Verify: 0.000s, Restore: 0.008s)
-Erasing done.
-J-Link>exit
-$
-```
-
-
-```
-$ newt load telee02_boot
-Loading bootloader
-$ newt load lora_app_shell_telee02
-Loading app image into slot 1
-```
-
-Assuming you attached the serial port and have a terminal up you should set the following output on the terminal:
-```
-000002 lora_app_shell
-```
-<br>
-### Shell Commands
-
-There are a number of shell commands that will allow you to join and send both unconfirmed and confirmed data. If you type 'help' in your terminal you will see the various commands displayed. Here is a screen shot of the output of help
-
-```
-000002 lora_app_shell
-help
-
-032766 help
-032766 stat
-032767 tasks
-032768 mpool
-032769 date
-032770 las_wr_mib
-032771 las_rd_mib
-032772 las_rd_dev_eui
-032773 las_wr_dev_eui
-032774 las_rd_app_eui
-032775 las_wr_app_eui
-032776 las_rd_app_key
-032777 las_wr_app_key
-032778 las_app_port
-032779 las_app_tx
-032780 las_join
-032781 las_link_chk
-032782 compat>
-```
-
-The following table lists the commands and gives a brief description of the commands. The lora commands are described in more detail later in the tutorial as well as their syntax (syntax not shown in the table).
-
-|Command|Description|
-|---|---|
-| help | Display list of available shell commands |
-| stat | Display statistics. Syntax: stat \<statistics group\>. 'stat' with no group displays avaialable groups |
-| tasks | Display OS tasks |
-| mpool | Displays OS memory pools and memory pool statistics |
-| date | Displays current date/time |
-| las_wr_mib | Write lora MIB |
-| las_rd_mib | Read lora MIB |
-| las_rd_dev_eui | Read lora device EUI |
-| las_wr_dev_eui | Write lora device EUI |
-| las_rd_app_eui | Read lora application EUI |
-| las_wr_app_eui | Write lora application EUI |
-| las_rd_app_key | Read lora application key |
-| las_wr_app_key | Write lora application key |
-| las_app_port | Open/close lora application port |
-| las_app_tx | Transmit on lora application port |
-| las_join | Perform a lora OTA join |
-| las_link_chk | Perform a lora link check |
-
-### OTA Join
-
-Before sending any application data a lora end device must be joined to its lora network. To perform a lora OTA (over-the-air) join there are some commands that must be issued prior to attempting to join. The reason for these commands is that a lora end device must be configured with a device EUI, application EUI and application key prior to performing an OTA join.
-
-```
-598763 compat> las_wr_app_eui 0x00:0x11:0x22:0x01:0x01:0x00:0x10:10
-
-623106 compat> las_wr_app_key 03:03:03:03:03:03:03:03:03:03:03:03:03:03:03:03
-
-623758 compat> las_wr_dev_eui 0x00:0x11:0x22:0x02:0x02:0x00:0x00:0x00
-
-630333 compat> las_join 1
-
-630634 Attempting to join...
-019802 compat> Join cb. status=0 attempts=1
-```
-If the join is successful the status returned should be 0. If it fails the status will be a non-zero lora status code (lora status error codes are described later in this tutorial).
-
-A note about "endianness" in the device EUI commands. The first three bytes of the EUI are the OUI and the last 5 bytes are unique (for that OUI). The above example assumes an OUI of 001122. This is not the same order as the address over the air as device addresses are sent "least significant byte" first (little endian). The same convention also applies to keys: they are in big-endian order in the command but sent little endian over the air.
-<br>
-
-### Opening/closing an application port
-
-Another step that must be performed prior to sending application data is to open an application port. All data frames containing application data are sent to a specific port. Port numbers are in the range 1 - 223 as port 0 is reserved for MLME-related activities. Ports 224-255 are reserved for future standardized application extensions.
-
-The lora app shell does not open any application ports by default.
-
-To open and/or close an application port the following commands are used. Note that the application port which you are using to send data must be open if you want to send data (or receive it).
-
-```
-115647 compat> las_app_port open 1
-
-150958 Opened app port 1
-150958 compat> las_app_port close 1
-
-151882 Closed app port 1
-```
-<br>
-
-### Sending data
-
-The lora app shell allows the user to send both unconfirmed and confirmed data. The command to send data is *las_app_tx \<port\> \<len\> \<type\>*
-
-NOTE: the current usage for this command shows an optional data rate and retries for this command. That feature has not been implemented and the command will not be accepted if they are separated.
-
-Where:
- port = port number on which to send
- len = size n bytes of app data
- type = 0 for unconfirmed, 1 for confirmed
-
- To send a confirmed data transmission of size 5 bytes on port 10 the command would be: las_app_tx 10 20 1
-
-Once the end device has sent the frame requested there should be a message which contains some additional information. Here is a screen shot using the above example. Note that there will be some delay between seeing the "Packet sent on port 10" message and the additional information as the additional information is the "confirmation" that the lora stack provides and the confirmation will not be returned until the lora stack is finished transmitting the frame and has received an acknowledgement or has finished waiting for all the receive windows.
-
-```
-449751 compat> las_app_tx 10 5 1
-
-452144 Packet sent on port 10
-452144 compat> Txd on port 10 type=conf status=0 len=5
-452325 dr:0
-452325 txpower:5
-452325 tries:1
-452326 ack_rxd:1
-452326 tx_time_on_air:330
-452327 uplink_cntr:0
-452327 uplink_freq:903500000
-```
-The information contained in the confirmation is the following:
-
-dr: The data rate on which the frame was sent.
-txpower: Transmit power level of the device.
-tries: # of attempts made to transmit the frame successfully.
-ack_rxd: Was an acknowledgement received (0 no 1 yes).
-tx_time_on_air: The on-air length of the frame (in milliseconds).
-uplink_cntr: The frame uplink counter that this frame used.
-uplink_freq: The frequency (logical) on which the frame was sent (in Hz).
-
-<br>
-
-
-<br>
-
-
-
-
diff --git a/docs/os/tutorials/nRF52.md b/docs/os/tutorials/nRF52.md
deleted file mode 100644
index d69031a..0000000
--- a/docs/os/tutorials/nRF52.md
+++ /dev/null
@@ -1,197 +0,0 @@
-## Blinky, your "Hello World!", on a nRF52 Development Kit
-This tutorial shows you how to create, build, and run the Blinky application on a nRF52 Development Kit.
-<br>
-
-Note that there are several versions of the nRF52 Development Kit in the market. The boards tested with this tutorial are listed under "Prerequisites".
-
-<br>
-
-### Prerequisites
-
-* Meet the prerequisites listed in [Project Blinky](/os/tutorials/blinky.md).
-* Have a nRF52 Development Kit (one of the following)
- * Nordic nRF52-DK Development Kit - PCA 10040
- * Rigado BMD-300 Evaluation Kit - BMD-300-EVAL-ES
-* Install the [Segger JLINK Software and documentation pack](https://www.segger.com/jlink-software.html).
-
-This tutorial uses the Nordic nRF52-DK board.
-
-### Create a Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already have a project created.
-
-Run the following commands to create a new project:
-
-```no-highlight
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new myproj
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in myproj...
- Project myproj successfully created.
- $ cd myproj
- $ newt install
- apache-mynewt-core
- $
-```
-
-<br>
-
-### <a name="create_targets"></a>Create the Targets
-
-Create two targets for the nRF52-DK board - one for the bootloader and one for the Blinky application.
-
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `nrf52_boot`:
-
-<font color="#F2853F">
-Note: This tutorial uses the Nordic nRF52-DK board. You must specify the correct bsp for the board you are using. </font>
-
-* For the Nordic Dev Kit choose @apache-mynewt-core/hw/bsp/nrf52dk instead (in the highlighted lines)
-* For the Rigado Eval Kit choose @apache-mynewt-core/hw/bsp/bmd300eval instead (in the highlighted lines)
-
-```hl_lines="3"
-$ newt target create nrf52_boot
-$ newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
-$ newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set nrf52_boot build_profile=optimized
-```
-
-<br>
-Run the following `newt target` commands to create a target for the Blinky application. We name the target `nrf52_blinky`.
-
-```hl_lines="3"
-$ newt target create nrf52_blinky
-$ newt target set nrf52_blinky app=apps/blinky
-$ newt target set nrf52_blinky bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set nrf52_blinky build_profile=debug
-```
-<br>
-You can run the `newt target show` command to verify the target settings:
-
-```no-highlight
-$ newt target show
-targets/nrf52_blinky
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
- build_profile=debug
-targets/nrf52_boot
- app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
- build_profile=optimized
-```
-<br>
-
-### Build the Target Executables
-
-Run the `newt build nrf52_boot` command to build the bootloader:
-
-```no-highlight
-$ newt build nrf52_boot
-Building target targets/nrf52_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
- ...
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/nrf52_boot/app/apps/boot/boot.elf
-Target successfully built: targets/nrf52_boot
-```
-
-<br>
-Run the `newt build nrf52_blinky` command to build the Blinky application:
-
-```no-highlight
-$ newt build nrf52_blinky
-Building target targets/nrf52_blinky
-Assembling repos/apache-mynewt-core/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52_split.s
-Compiling repos/apache-mynewt-core/hw/bsp/nrf52dk/src/sbrk.c
-Compiling repos/apache-mynewt-core/hw/cmsis-core/src/cmsis_nvic.c
-Compiling repos/apache-mynewt-core/hw/drivers/uart/uart_hal/src/uart_hal.c
-Assembling repos/apache-mynewt-core/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52.s
-Compiling apps/blinky/src/main.c
-
- ...
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky/blinky.elf
-Target successfully built: targets/nrf52_blinky
-```
-
-<br>
-
-### Sign and Create the Blinky Application Image
-
-Run the `newt create-image nrf52_blinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
-
-```no-highlight
-$ newt create-image nrf52_blinky 1.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky/blinky.img
-```
-
-<br>
-
-### Connect to the Board
-
-* Connect a micro-USB cable from your computer to the micro-USB port on the nRF52-DK board.
-* Turn the power on the board to ON. You should see the green LED light up on the board.
-
-### Load the Bootloader and the Blinky Application Image
-
-Run the `newt load nrf52_boot` command to load the bootloader onto the board:
-
-```no-highlight
-$ newt load nrf52_boot
-Loading bootloader
-$
-```
-<br>
-Run the `newt load nrf52_blinky` command to load the Blinky application image onto the board.
-```no-highlight
-$ newt load nrf52_blinky
-Loading app image into slot 1
-```
-
-You should see the LED1 on the board blink!
-
-Note: If the LED does not blink, try resetting your board.
-
-<br>
-
-If you want to erase the flash and load the image again, you can run `JLinkExe` to issue an `erase` command.
-
-**Note:** On Windows: Run the `jlink` command with the same arguments from a Windows Command Prompt terminal.
-
-<br>
-```no-highlight
-$ JLinkExe -device nRF52 -speed 4000 -if SWD
-SEGGER J-Link Commander V5.12c (Compiled Apr 21 2016 16:05:51)
-DLL version V5.12c, compiled Apr 21 2016 16:05:45
-
-Connecting to J-Link via USB...O.K.
-Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 15 2016 18:03:17
-Hardware version: V1.00
-S/N: 682863966
-VTref = 3.300V
-
-
-Type "connect" to establish a target connection, '?' for help
-J-Link>erase
-Cortex-M4 identified.
-Erasing device (0;?i?)...
-Comparing flash [100%] Done.
-Erasing flash [100%] Done.
-Verifying flash [100%] Done.
-J-Link: Flash download: Total time needed: 0.363s (Prepare: 0.093s, Compare: 0.000s, Erase: 0.262s, Program: 0.000s, Verify: 0.000s, Restore: 0.008s)
-Erasing done.
-J-Link>exit
-$
-```
diff --git a/docs/os/tutorials/nrf52_adc.md b/docs/os/tutorials/nrf52_adc.md
deleted file mode 100644
index 2336491..0000000
--- a/docs/os/tutorials/nrf52_adc.md
+++ /dev/null
@@ -1,875 +0,0 @@
-## Adding an Analog Sensor on nRF52
-
-<br>
-
-### Objective
-
-We will be adding an analog sensor to the NRF52DK development board and using the Analog to Digital Converter
-(ADC) to read the values from the sensor. It's also using Bluetooth to allow you to connect to the app and
-read the value of the sensor. Please see the following section for the required hardware
-in order to complete this tutorial.
-
-<br>
-
-### Hardware needed
-
-* nRF52 Development Kit (one of the following)
- * Dev Kit from Nordic - PCA 10040
- * Eval Kit from Rigado - BMD-300-EVAL-ES
-* eTape Liquid Sensor -- buy from [Adafruit](https://www.adafruit.com/products/1786)
-* Laptop running Mac OS
-* It is assumed you have already installed newt tool.
-* It is assumed you already installed native tools as described [here](../get_started/native_tools.md)
-
-<br>
-
-### Create a project.
-
-Create a new project to hold your work. For a deeper understanding, you can read about project creation in
-[Get Started -- Creating Your First Project](../get_started/project_create.md)
-or just follow the commands below.
-
-```
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new myadc
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in myadc...
- Project myadc successfully created.
- $ cd myadc
-
-```
-
-<br>
-
-### Add Additional Repositories
-
-The board-specific libraries for the NRF52dk board are in an external repository at present, so
-you'll need to include that remote repository and install it as well. If you're not familiar
-with using repositories, see the section on [repositories](repo/add_repos.md) before
-continuing. Or just copy and paste the following.
-
-In your `project.yml` file, add `mynewt_nordic` to the `project.repositories` section, and
-then add the proper repository definition. When you're done, your `project.yml` file
-should look like this:
-
-```hl_lines="5 15 16 17 18 19"
-project.name: "my_project"
-
-project.repositories:
- - apache-mynewt-core
- - mynewt_nordic
-
-# Use github's distribution mechanism for core ASF libraries.
-# This provides mirroring automatically for us.
-#
-repository.apache-mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: incubator-mynewt-core
-repository.mynewt_nordic:
- type: github
- vers: 1-latest
- user: runtimeco
- repo: mynewt_nordic
-```
-
-<br>
-
-### Install Everything
-
-Now that you have defined the needed repositories, it's time to install everything so
-that you can get started.
-
-```
- $ newt install -v
- apache-mynewt-core
- Downloading repository description for apache-mynewt-core... success!
- ...
- apache-mynewt-core successfully installed version 0.9.0-none
- ...
- mynewt_nordic
- Downloading repository description for mynewt_nordic... success!
- ...
- mynewt_nordic successfully installed version 0.9.9-none
-```
-
-<br>
-
-### Create the targets
-
-Create two targets - one for the bootloader and one for the nrf52 board.
-
-<font color="#F2853F">
-Note: The correct bsp must be chosen for the board you are using. </font>
-
-* For the Nordic Dev Kit choose @apache-mynewt-core/hw/bsp/nrf52dk instead (in the highlighted lines)
-* For the Rigado Eval Kit choose @apache-mynewt-core/hw/bsp/bmd300eval instead (in the highlighted lines)
-
-For the app itself we're going to extend the [bleprph](belpprph/bleprph-app.md) app so that we
-get the Bluetooth communications built in, so the first thing we'll need to do is copy that app
-into our own app directory:
-
-```no-highlight
-$ mkdir -p apps/nrf52_adc
-$ cp -Rp repos/apache-mynewt-core/apps/bleprph/* apps/nrf52_adc
-```
-
-Next, you'll modify the `pkg.yml` file for your app. Note the change in `pkg.name` and `pkg.description`. Also make sure that you specify the full path of all the packages with the prefix `@apache-mynewt-core/` as shown in the third highlighted line.
-
-```hl_lines="3 5 11"
-$ cat apps/nrf52_adc/pkg.yml
-...
-pkg.name: apps/nrf52_adc
-pkg.type: app
-pkg.description: Simple BLE peripheral application for ADC Sensors.
-pkg.author: "Apache Mynewt <dev@mynewt.incubator.apache.org>"
-pkg.homepage: "http://mynewt.apache.org/"
-pkg.keywords:
-
-pkg.deps:
- - "@apache-mynewt-core/boot/split"
- - "@apache-mynewt-core/kernel/os"
- - "@apache-mynewt-core/mgmt/imgmgr"
- - "@apache-mynewt-core/mgmt/newtmgr"
- - "@apache-mynewt-core/mgmt/newtmgr/transport/ble"
- - "@apache-mynewt-core/net/nimble/controller"
- - "@apache-mynewt-core/net/nimble/host"
- - "@apache-mynewt-core/net/nimble/host/services/ans"
- - "@apache-mynewt-core/net/nimble/host/services/gap"
- - "@apache-mynewt-core/net/nimble/host/services/gatt"
- - "@apache-mynewt-core/net/nimble/host/store/ram"
- - "@apache-mynewt-core/net/nimble/transport/ram"
- - "@apache-mynewt-core/sys/console/full"
- - "@apache-mynewt-core/sys/log/full"
- - "@apache-mynewt-core/sys/stats/full"
- - "@apache-mynewt-core/sys/sysinit"
- - "@apache-mynewt-core/sys/id"
-```
-
-Great! We have our very own app so let's make sure we have all of our targets set
-correctly:
-
-```hl_lines="3 8"
-$ newt target create nrf52_adc
-$ newt target set nrf52_adc app=apps/nrf52_adc
-Target targets/nrf52_adc successfully set target.app to apps/nrf52_adc
-$ newt target set nrf52_adc bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set nrf52_adc build_profile=debug
-
-$ newt target create nrf52_boot
-$ newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
-$ newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set nrf52_boot build_profile=optimized
-
-$ newt target show
-targets/nrf52_adc
- app=apps/nrf52_adc
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
- build_profile=debug
-targets/nrf52_boot
- app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
- build_profile=optimized
-```
-
-<font color="#F2853F">
-Note: If you've already built and installed a bootloader for your NRF52dk then you do
-not need to create a target for it here, or build and load it as below. </font>
-<br>
-
-### Build the target executables
-
-```
-$ newt build nrf52_boot
-...
-Compiling boot.c
-Archiving boot.a
-Linking boot.elf
-App successfully built: ~/dev/myadc/bin/nrf52_boot/apps/boot/boot.elf
-```
-```
-$ newt build nrf52_adc
-...
-Compiling main.c
-Archiving nrf52_adc.a
-Linking nrf52_adc.elf
-App successfully built: ~/dev/myadc/bin/nrf52_adc/apps/nrf52_adc/nrf52_adc.elf
-```
-
-<br>
-
-### Sign and create the nrf52_adc application image
-
-You must sign and version your application image to download it using newt to the board.
-Use the newt create-image command to perform this action. You may assign an arbitrary
-version (e.g. 1.0.0) to the image.
-
-```
-$ newt create-image nrf52_adc 1.0.0
-App image successfully generated: ~/dev/myadc/bin/nrf52_adc/apps/nrf52_adc/nrf52_adc.img
-Build manifest: ~/dev/myadc/bin/nrf52_adc/apps/nrf52_adc/manifest.json
-```
-
-<br>
-
-### Connect the board
-
-Connect the evaluation board via micro-USB to your PC via USB cable.
-
-<br>
-
-### Download to the target
-
-Download the bootloader first and then the nrf52_adc executable to the target platform.
-Don't forget to reset the board if you don't see the LED blinking right away!
-
-```
-$ newt load nrf52_boot
-$ newt load nrf52_adc
-```
-
-<br>
-
-**Note:** If you want to erase the flash and load the image again, you can use JLinkExe to issue an `erase` command.
-
-```
-$ JLinkExe -device nRF52 -speed 4000 -if SWD
-SEGGER J-Link Commander V5.12c (Compiled Apr 21 2016 16:05:51)
-DLL version V5.12c, compiled Apr 21 2016 16:05:45
-
-Connecting to J-Link via USB...O.K.
-Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 15 2016 18:03:17
-Hardware version: V1.00
-S/N: 682863966
-VTref = 3.300V
-
-
-Type "connect" to establish a target connection, '?' for help
-J-Link>erase
-Cortex-M4 identified.
-Erasing device (0;?i?)...
-Comparing flash [100%] Done.
-Erasing flash [100%] Done.
-Verifying flash [100%] Done.
-J-Link: Flash download: Total time needed: 0.363s (Prepare: 0.093s, Compare: 0.000s, Erase: 0.262s, Program: 0.000s, Verify: 0.000s, Restore: 0.008s)
-Erasing done.
-J-Link>exit
-$
-```
-<br>
-
-So you have a BLE app, but really all you've done is change the name of the **bleprph** app to **nrf52_adc** and load that.
-Not all that impressive, and it certainly won't read an Analog Sensor right now. So let's do that next. In order to
-read an ADC sensor, and since the ADC package is in an external, licensed, repository, we'll create a driver for it
-here in our app that will leverage the existing driver in the external repository. It adds another layer of
-indirection, but it will also give us a look at building our own driver, so we'll do it this way.
-
-<br>
-
-### Building a Driver
-
-The first thing to do is to create the directory structure for your driver:
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ mkdir -p libs/my_drivers/myadc/include/myadc
-[user@IsMyLaptop:~/src/air_quality]$ mkdir -p libs/my_drivers/myadc/src
-```
-
-Now you can add the files you need. You'll need a pkg.yml to describe the driver, and then header stub followed by source stub.
-
-```no-highlight
-[user@IsMyLaptop:~/src/air_quality]$ cat libs/my_drivers/myadc/pkg.yml
-```
-
-```c
-#
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-#
-pkg.name: libs/my_drivers/myadc
-pkg.deps:
- - "@apache-mynewt-core/hw/hal"
- - "@mynewt_nordic/hw/drivers/adc/adc_nrf52"
-```
-
-First, let's create the required header file `myadc.h` in the includes directory i.e. `libs/my_drivers/myadc/include/myadc/myadc.h`.
-It's a pretty straightforward header file, since we only need to do 2 things:
-
-* Initialize the ADC device
-* Read ADC Values
-
-
-```c
-#ifndef _NRF52_ADC_H_
-#define _NRF52_ADC_H_
-
-void * adc_init(void);
-int adc_read(void *buffer, int buffer_len);
-
-#endif /* _NRF52_ADC_H_ */
-
-```
-
-Next we'll need a corresponding source file `myadc.c` in the src directory. This is where
-we'll implement the specifics of the driver:
-
-```c
-
-#include <assert.h>
-#include <os/os.h>
-/* ADC */
-#include "myadc/myadc.h"
-#include "nrf.h"
-#include "app_util_platform.h"
-#include "app_error.h"
-#include <adc/adc.h>
-#include <adc_nrf52/adc_nrf52.h>
-#include "nrf_drv_saadc.h"
-
-
-#define ADC_NUMBER_SAMPLES (2)
-#define ADC_NUMBER_CHANNELS (1)
-
-nrf_drv_saadc_config_t adc_config = NRF_DRV_SAADC_DEFAULT_CONFIG;
-
-struct adc_dev *adc;
-uint8_t *sample_buffer1;
-uint8_t *sample_buffer2;
-
-static struct adc_dev os_bsp_adc0;
-static nrf_drv_saadc_config_t os_bsp_adc0_config = {
- .resolution = MYNEWT_VAL(ADC_0_RESOLUTION),
- .oversample = MYNEWT_VAL(ADC_0_OVERSAMPLE),
- .interrupt_priority = MYNEWT_VAL(ADC_0_INTERRUPT_PRIORITY),
-};
-void *
-adc_init(void)
-{
- int rc = 0;
-
- rc = os_dev_create((struct os_dev *) &os_bsp_adc0, "adc0",
- OS_DEV_INIT_KERNEL, OS_DEV_INIT_PRIO_DEFAULT,
- nrf52_adc_dev_init, &os_bsp_adc0_config);
- assert(rc == 0);
- nrf_saadc_channel_config_t cc = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
- cc.gain = NRF_SAADC_GAIN1_6;
- cc.reference = NRF_SAADC_REFERENCE_INTERNAL;
- adc = (struct adc_dev *) os_dev_open("adc0", 0, &adc_config);
- assert(adc != NULL);
- adc_chan_config(adc, 0, &cc);
- sample_buffer1 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- sample_buffer2 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- memset(sample_buffer1, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- memset(sample_buffer2, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- adc_buf_set(adc, sample_buffer1, sample_buffer2,
- adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- return adc;
-}
-
-
-int
-adc_read(void *buffer, int buffer_len)
-{
- int i;
- int adc_result;
- int my_result_mv = 0;
- int rc;
- for (i = 0; i < ADC_NUMBER_SAMPLES; i++) {
- rc = adc_buf_read(adc, buffer, buffer_len, i, &adc_result);
- if (rc != 0) {
- goto err;
- }
- my_result_mv = adc_result_mv(adc, 0, adc_result);
- }
- adc_buf_release(adc, buffer, buffer_len);
- return my_result_mv;
-err:
- return (rc);
-}
-```
-There's a lot going on in here, so let's walk through it step by step.
-
-First, we define a default configuration, with the resolution, oversample and interrupt priority. You'll see
-that these are `MYNEWT_VAL` values, which means that we'll define them shortly in
-a `syscfg.yml` file to be passed to the compiler at build time.
-
-```c
-static struct adc_dev os_bsp_adc0;
-static nrf_drv_saadc_config_t os_bsp_adc0_config = {
- .resolution = MYNEWT_VAL(ADC_0_RESOLUTION),
- .oversample = MYNEWT_VAL(ADC_0_OVERSAMPLE),
- .interrupt_priority = MYNEWT_VAL(ADC_0_INTERRUPT_PRIORITY),
-};
-```
-
-Next, in `adc_init()` , we need to tell the OS to create the device.
-
-```c
-void *
-adc_init(void)
-{
- int rc = 0;
-
- rc = os_dev_create((struct os_dev *) &os_bsp_adc0, "adc0",
- OS_DEV_INIT_KERNEL, OS_DEV_INIT_PRIO_DEFAULT,
- nrf52_adc_dev_init, &os_bsp_adc0_config);
- assert(rc == 0);
- nrf_saadc_channel_config_t cc = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN1);
- cc.gain = NRF_SAADC_GAIN1_6;
- cc.reference = NRF_SAADC_REFERENCE_INTERNAL;
- adc = (struct adc_dev *) os_dev_open("adc0", 0, &adc_config);
- assert(adc != NULL);
- adc_chan_config(adc, 0, &cc);
- sample_buffer1 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- sample_buffer2 = malloc(adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- memset(sample_buffer1, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- memset(sample_buffer2, 0, adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- adc_buf_set(adc, sample_buffer1, sample_buffer2,
- adc_buf_size(adc, ADC_NUMBER_CHANNELS, ADC_NUMBER_SAMPLES));
- return adc;
-}
-
-```
-A few things need to be said about this part, as it is the most confusing. First,
-we're using a **default** configuration for the ADC Channel via the `NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE`
-macro. The important part here is that we're actually using `AIN1`. I know what you're thinking, "But
-we want ADC-0!" and that's true. The board is actually labelled 'A0, A1, A2' etc., and the actual pin
-numbers are also listed on the board, which seems handy. At first. But it gets messy very quickly.
-
-If you try to use AIN0, and then go poke around in the registers while this is running,
-
-```
-(gdb) p/x {NRF_SAADC_Type}0x40007000
-...
- CH = {{
- PSELP = 0x1,
- PSELN = 0x0,
- CONFIG = 0x20000,
- LIMIT = 0x7fff8000
- },
-```
-
-You'll see that the pin for channel 0 is set to 1, which corresponds to AIN0, but that's **NOT**
-the same as A0 -- pin P0.03, the one we're using. For that, you use AIN1, which would set the
-pin value to 2. Messy. Someone, somewhere, thought this made sense.
-
-
-The only other thing to note here is that we're using the internal reference voltage, rather than
-setting our own. There's nothing wrong with that, but since we are, we'll have to crank up
-the gain a bit by using `NRF_SAADC_GAIN1_6`.
-
-Then, in `adc_read()` we will take readings, convert the raw readings to
-a millivolt equivalent, and return the result.
-
-```c
-int
-adc_read(void *buffer, int buffer_len)
-{
- int i;
- int adc_result;
- int my_result_mv = 0;
- int rc;
- for (i = 0; i < ADC_NUMBER_SAMPLES; i++) {
- rc = adc_buf_read(adc, buffer, buffer_len, i, &adc_result);
- if (rc != 0) {
- goto err;
- }
- my_result_mv = adc_result_mv(adc, 0, adc_result);
- }
- adc_buf_release(adc, buffer, buffer_len);
- return my_result_mv;
-err:
- return (rc);
-}
-```
-
-Finally, we'll need some settings for our driver, as mentioned earlier. In the `myadc` directory
-you'll need to add a `syscfg.yml` file:
-
-```no-highlight
-# Package: libs/my_driver/myadc
-
-syscfg.defs:
- ADC_0:
- description: 'TBD'
- value: 1
- ADC_0_RESOLUTION:
- description: 'TBD'
- value: 'SAADC_CONFIG_RESOLUTION'
- ADC_0_OVERSAMPLE:
- description: 'TBD'
- value: 'SAADC_CONFIG_OVERSAMPLE'
- ADC_0_INTERRUPT_PRIORITY:
- description: 'TBD'
- value: 'SAADC_CONFIG_IRQ_PRIORITY'
-```
-
-Once that's all done, you should have a working ADC Driver for your NRF52DK board. The last step in getting the driver set up is to include it in the package dependency defined by `pkg.deps` in the `pkg.yml` file of your app. Add it in `apps/nrf52_adc/pkg.yml` as shown by the highlighted line below.
-
-```hl_lines="29"
-# Licensed to the Apache Software Foundation (ASF) under one
-# <snip>
-
-pkg.name: apps/nrf52_adc
-pkg.type: app
-pkg.description: Simple BLE peripheral application for ADC sensor.
-pkg.author: "Apache Mynewt <dev@mynewt.incubator.apache.org>"
-pkg.homepage: "http://mynewt.apache.org/"
-pkg.keywords:
-
-pkg.deps:
- - "@apache-mynewt-core/boot/split"
- - "@apache-mynewt-core/kernel/os"
- - "@apache-mynewt-core/mgmt/imgmgr"
- - "@apache-mynewt-core/mgmt/newtmgr"
- - "@apache-mynewt-core/mgmt/newtmgr/transport/ble"
- - "@apache-mynewt-core/net/nimble/controller"
- - "@apache-mynewt-core/net/nimble/host"
- - "@apache-mynewt-core/net/nimble/host/services/ans"
- - "@apache-mynewt-core/net/nimble/host/services/gap"
- - "@apache-mynewt-core/net/nimble/host/services/gatt"
- - "@apache-mynewt-core/net/nimble/host/store/ram"
- - "@apache-mynewt-core/net/nimble/transport/ram"
- - "@apache-mynewt-core/sys/console/full"
- - "@apache-mynewt-core/sys/log/full"
- - "@apache-mynewt-core/sys/stats/full"
- - "@apache-mynewt-core/sys/sysinit"
- - "@apache-mynewt-core/sys/id"
- - libs/my_drivers/myadc
-```
-
-
-<br>
-
-### Creating the ADC Task
-
-Now that the driver is done, we'll need to add calls to the main app's `main.c` file, as well
-as a few other things. First, we'll need to update the includes, and add a task for our ADC
-sampling.
-
-
-```c
-#include "myadc/myadc.h"
-...
-/* ADC Task settings */
-#define ADC_TASK_PRIO 5
-#define ADC_STACK_SIZE (OS_STACK_ALIGN(336))
-struct os_eventq adc_evq;
-struct os_task adc_task;
-bssnz_t os_stack_t adc_stack[ADC_STACK_SIZE];
-```
-
-Next we'll need o initialize the task `event_q` so we'll add the highlighted code to `main()` as shown below:
-
-```c hl_lines="7 8 9 10 11 12 13 14 15"
- /* Set the default device name. */
- rc = ble_svc_gap_device_name_set("nimble-adc");
- assert(rc == 0);
-
- conf_load();
-
- /* Initialize adc sensor task eventq */
- os_eventq_init(&adc_evq);
-
- /* Create the ADC reader task.
- * All sensor operations are performed in this task.
- */
- os_task_init(&adc_task, "sensor", adc_task_handler,
- NULL, ADC_TASK_PRIO, OS_WAIT_FOREVER,
- adc_stack, ADC_STACK_SIZE);
-```
-We'll need that `adc_task_handler()` function to exist, and that's where we'll initialize the ADC Device
-and set the event handler. In the task's while() loop, we'll just make a call to `adc_sample()` to cause
-the ADC driver to sample the adc device.
-
-```c
-/**
- * Event loop for the sensor task.
- */
-static void
-adc_task_handler(void *unused)
-{
- struct adc_dev *adc;
- int rc;
- /* ADC init */
- adc = adc_init();
- rc = adc_event_handler_set(adc, adc_read_event, (void *) NULL);
- assert(rc == 0);
-
- while (1) {
- adc_sample(adc);
- /* Wait 2 second */
- os_time_delay(OS_TICKS_PER_SEC * 2);
- }
-}
-```
-
-Above the `adc_task_handler`, add code to handle the `adc_read_event()` calls:
-
-```c
-int
-adc_read_event(struct adc_dev *dev, void *arg, uint8_t etype,
- void *buffer, int buffer_len)
-{
- int value;
- uint16_t chr_val_handle;
- int rc;
-
- value = adc_read(buffer, buffer_len);
- if (value >= 0) {
- console_printf("Got %d\n", value);
- } else {
- console_printf("Error while reading: %d\n", value);
- goto err;
- }
- gatt_adc_val = value;
- rc = ble_gatts_find_chr(&gatt_svr_svc_adc_uuid.u, BLE_UUID16_DECLARE(ADC_SNS_VAL), NULL, &chr_val_handle);
- assert(rc == 0);
- ble_gatts_chr_updated(chr_val_handle);
- return (0);
-err:
- return (rc);
-}
-```
-This is where we actually read the ADC value and then update the BLE Characteristic for that value.
-
-But wait, we haven't defined those BLE services and characteristics yet! Right, so don't try to build and run this
-app just yet or it will surely fail. Instead, move on to the next section and get all of those services
-defined.
-
-<br>
-
-### Building the BLE Services
-
-If the nrf52_adc app is going to be a Bluetooth-enabled sensor app that will allow you to read the value of the eTape Water Level Sensor
-via Bluetooth we'll need to actually define those Services and Characteristics.
-
-As with the [ble peripheral](bleprph/bleprph-app.md) app, we will advertise a couple of values from our app. The first is
-not strictly necessary, but it will help us build an iOS app later. We've defined a service and the characteristics in
-that service in `bleadc.h` in the `apps/nrf52_adc/src/` directory as follows:
-
-```c
-/* Sensor Data */
-/* e761d2af-1c15-4fa7-af80-b5729002b340 */
-static const ble_uuid128_t gatt_svr_svc_adc_uuid =
- BLE_UUID128_INIT(0x40, 0xb3, 0x20, 0x90, 0x72, 0xb5, 0x80, 0xaf,
- 0xa7, 0x4f, 0x15, 0x1c, 0xaf, 0xd2, 0x61, 0xe7);
-#define ADC_SNS_TYPE 0xDEAD
-#define ADC_SNS_STRING "eTape Liquid Level Sensor"
-#define ADC_SNS_VAL 0xBEAD
-extern uint16_t gatt_adc_val;
-```
-
-The first is the UUID of the service, followed by the 2 characteristics we are going to offer.
-The first characteristic is going to advertise the *type* of sensor we are advertising, and
-it will be a read-only characteristic. The second characteristic will be the sensor value
-itself, and we will allow connected devices to 'subscribe' to it in order to get
-constantly-updated values.
-
-
-**Note:** You can choose any valid Characteristic UUIDs to go here. We're using these values
-for illustrative purposes only.
-
-The value that we'll be updating is also defined here as `gatt_adc_val`.
-
-If we then go look at `gatt_srv.c` we can see the structure of the service and
-characteristic offering that we set up:
-
-```c hl_lines="21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37"
-static const struct ble_gatt_svc_def gatt_svr_svcs[] = {
- {
- /*** Service: Security test. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid = &gatt_svr_svc_sec_test_uuid.u,
- .characteristics = (struct ble_gatt_chr_def[]) { {
- /*** Characteristic: Random number generator. */
- .uuid = &gatt_svr_chr_sec_test_rand_uuid.u,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ | BLE_GATT_CHR_F_READ_ENC,
- }, {
- /*** Characteristic: Static value. */
- .uuid = &gatt_svr_chr_sec_test_static_uuid.u,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ |
- BLE_GATT_CHR_F_WRITE | BLE_GATT_CHR_F_WRITE_ENC,
- }, {
- 0, /* No more characteristics in this service. */
- } },
- },
- {
- /*** ADC Level Notification Service. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid = &gatt_svr_svc_adc_uuid.u,
- .characteristics = (struct ble_gatt_chr_def[]) { {
- .uuid = BLE_UUID16_DECLARE(ADC_SNS_TYPE),
- .access_cb = gatt_svr_sns_access,
- .flags = BLE_GATT_CHR_F_READ,
- }, {
- .uuid = BLE_UUID16_DECLARE(ADC_SNS_VAL),
- .access_cb = gatt_svr_sns_access,
- .flags = BLE_GATT_CHR_F_NOTIFY,
- }, {
- 0, /* No more characteristics in this service. */
- } },
- },
-
- {
- 0, /* No more services. */
- },
-};
-```
-
-You should recognize the first services from the [BLE Peripheral](bleprph/bleprph-intro.md)
-tutorial earlier. We're just adding another Service, with 2 new Characteristics, to
-that application.
-
-We'll need to fill in the function that will be called for this service, `gatt_srv_sns_access`
-next so that the service knows what to do.
-
-```c
-static int
-gatt_svr_sns_access(uint16_t conn_handle, uint16_t attr_handle,
- struct ble_gatt_access_ctxt *ctxt,
- void *arg)
-{
- uint16_t uuid16;
- int rc;
-
- uuid16 = ble_uuid_u16(ctxt->chr->uuid);
-
- switch (uuid16) {
- case ADC_SNS_TYPE:
- assert(ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR);
- rc = os_mbuf_append(ctxt->om, ADC_SNS_STRING, sizeof ADC_SNS_STRING);
- BLEPRPH_LOG(INFO, "ADC SENSOR TYPE READ: %s\n", ADC_SNS_STRING);
- return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
-
- case ADC_SNS_VAL:
- if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
- rc = gatt_svr_chr_write(ctxt->om, 0,
- sizeof gatt_adc_val,
- &gatt_adc_val,
- NULL);
- return rc;
- } else if (ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR) {
- rc = os_mbuf_append(ctxt->om, &gatt_adc_val,
- sizeof gatt_adc_val);
- return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
- }
-
- default:
- assert(0);
- return BLE_ATT_ERR_UNLIKELY;
- }
-}
-
-```
-
-You can see that when request is for the `ADC_SNS_TYPE`, we return the
-Sensor Type we defined earlier. If the request if for `ADC_SNS_VAL` we'll return the
-`gatt_adc_val` value.
-
-Don't forget to include the `bleadc.h` include file at the top of the `gatt_svr.c` file!
-
-```hl_lines="8"
-#include <assert.h>
-#include <stdio.h>
-#include <string.h>
-#include "bsp/bsp.h"
-#include "host/ble_hs.h"
-#include "host/ble_uuid.h"
-#include "bleprph.h"
-#include "bleadc.h"
-```
-
-If you build, load and run this application now, you will see all those Services and Characteristics
-advertised, and you will even be able to read the "Sensor Type" String via the ADC_SNS_TYPE
-Characteristic.
-
-<br>
-
-
-### Adding the eTape Water Sensor
-
-Now that we have a fully functioning BLE App that we can subscribe to sensor
-values from, it's time to actually wire up the sensor!
-
-As previously mentioned, we're going to be using an eTape Water Level Sensor. You can
-get one from [Adafruit](https://www.adafruit.com/products/1786).
-
-We're going to use the sensor as a resistive sensor, and the setup is very simple.
-I'll be using a 'breadboard` to put this all together for illustrative purposes.
-First, attach a jumper-wire from Vdd on the board to the breadboard.
-Next, attach a jumper wire from pin P0.03 on the board to the breadboard. This will be
-our ADC-in. The sensor should have come with a 560 ohm resistor, so plug that
-into the board between Vdd and ADC-in holes. Finally, attach a jumper from
-GND on the board to your breadboard. At this point, your breadboard should look
-like this:
-
-
-
-Now attach one of the middle 2 leads from the sensor to ground on the breadboard and
-the other middle lead to the ADC-in on the breadboard. Your breadboard should now look
-like this:
-
-
-
-And your eTape Sensor should look like this (at least if you have it mounted in a
-graduated cylinder as I do).
-
-
-
-That concludes the hardware portion. Easy!
-
-At this point you should be able to build, create-image and load your application and see it properly
-sending readings.
-
-<br>
-
-
-### Conclusion
-
-Congratulations, you've now completed both a hardware project and a software project by connecting a
-sensor to your device and using Mynewt to read data from that sensor and send it via Bluetooth
-to a connected device. That's no small feat!
-
-If you see anything missing or want to send us feedback, please do so by signing up for
-appropriate mailing lists on our [Community Page](../../community.md).
-
-Keep on hacking and sensing!
-
-<br>
-
-### Note
-
-If you're wondering how to actually view these sensor readings via Bluetooth, you have a couple of
-options. On Mac OS or iOS you can download the [LightBlue app](https://itunes.apple.com/us/app/lightblue-explorer-bluetooth/id557428110?mt=8).
-This app lets you connect to, and interrogate, BLE devices like the one you just built.
-
-If you used the BLE Service and Characteristic UUIDs used in this tutorial, you can also download
-and use a Mac OS [MyNewt Sensor Reader App](https://dragonflyiot.com/MyNewtSensorReader.zip) (Zip Archive) that allows
-you to graph your data, etc. An iOS version is in Beta testing and should be available soon.
-
-
-
-Enjoy!
-
-
-
-
diff --git a/docs/os/tutorials/olimex.md b/docs/os/tutorials/olimex.md
deleted file mode 100644
index 235956f..0000000
--- a/docs/os/tutorials/olimex.md
+++ /dev/null
@@ -1,226 +0,0 @@
-## Blinky, your "Hello World!", on Olimex
-
-This tutorial shows you how to create, build, and run the Blinky application on an Olimex STM32-E407 board.
-<br>
-### Prerequisites
-
-* Meet the prerequisites listed in [Project Blinky](/os/tutorials/blinky.md).
-* Have a STM32-E407 development board from Olimex.
-* Have a ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
-* Have a USB A-B type cable to connect the debugger to your computer.
-* Install the [OpenOCD debugger](/os/get_started/cross_tools/).
-
-<br>
-### Create a Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already created a project.
-
-Run the following commands to create a new project:
-
-```no-highlight
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new myproj
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in myproj...
- Project myproj successfully created.
-
- $cd myproj
-
- $ newt install
- apache-mynewt-core
- $
-```
-
-<br>
-
-### <a name="create_targets"></a>Create the Targets
-
-Create two targets for the Olimex board - one for the bootloader and one for the Blinky application.
-
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `boot_olimex`.
-
-```no-highlight
-$ newt target create boot_olimex
-$ newt target set boot_olimex build_profile=optimized
-$ newt target set boot_olimex app=@apache-mynewt-core/apps/boot
-$ newt target set boot_olimex bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
-```
-
-<br>
-Run the following `newt target` commands to create a target for the Blinky application. We name the target `olimex_blinky`.
-
-```no-highlight
-$ newt target create olimex_blinky
-$ newt target set olimex_blinky build_profile=debug
-$ newt target set olimex_blinky bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
-$ newt target set olimex_blinky app=apps/blinky
-
-```
-
-<br>
-
-### Build the Bootloader
-Run the `newt build boot_olimex` command to build the bootloader:
-
-```no-highlight
-$ newt build boot_olimex
-Building target targets/boot_olimex
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling bin/targets/boot_olimex/generated/src/boot_olimex-sysflash.c
-
- ...
-
-Archiving libc_baselibc.a
-Archiving sys_flash_map.a
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/boot_olimex/app/apps/boot/boot.elf
-Target successfully built: targets/boot_olimex
-```
-<br>
-### Build the Blinky Application
-Run the `newt build olimex_blinky` command to build the blinky application:
-
-```no-highlight
-$ newt build olimex_blinky
-Building target targets/olimex_blinky
-Assembling repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/src/arch/cortex_m4/startup_STM32F40x.s
-Compiling repos/apache-mynewt-core/hw/drivers/uart/src/uart.c
-Compiling repos/apache-mynewt-core/hw/cmsis-core/src/cmsis_nvic.c
-Compiling repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/src/sbrk.c
-Compiling apps/blinky/src/main.c
-Compiling repos/apache-mynewt-core/hw/drivers/uart/uart_hal/src/uart_hal.c
-Compiling repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/src/hal_bsp.c
-Compiling repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/src/system_stm32f4xx.c
-Compiling repos/apache-mynewt-core/hw/hal/src/hal_common.c
-Compiling repos/apache-mynewt-core/hw/hal/src/hal_flash.c
-
- ...
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/olimex_blinky/app/apps/blinky/blinky.elf
-Target successfully built: targets/olimex_blinky
-
-```
-
-<br>
-
-### Sign and Create the Blinky Application Image
-Run the `newt create-image olimex_blinky 1.0.0` command to sign and create an image file for the blinky application. You may assign an arbitrary version (e.g. 1.0.0) number.
-
-
-```no-highlight
-$ newt create-image olimex_blinky 1.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/olimex_blinky/app/apps/blinky/blinky.img
-```
-<br>
-
-### Connect to the Board
-
-Configure the board to bootload from flash memory and to use USB-OTG2 for the power source. Refer to the following diagrams to locate the boot jumpers and power input select jumpers on the board.
-
-**Note:** The labels for the **USB-OTG1** and **USB-OTG2** ports on the diagram are reversed. The port labeled USB-OTG1 on the diagram is the USB-OTG2 port and the port labeled USB-OTG2 on the diagram is the USB-OTG1 port.
-<br>
-
-<p align="center">
-<img src="../pics/STM32-E407_top_small.jpg"></img>
-<br>
-<img src="../pics/STM32-E407_bot_small.jpg"></img>
-</p>
-
-<br>
-
-* Locate the boot jumpers on the lower right corner of the board. **B1_1/B1_0** and **B0_1/B0_0** are PTH jumpers to control the boot mode when a bootloader is present. These two jumpers must be moved together. The board searches for the bootloader in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we configure the board to boot from flash by jumpering **B0_0** and **B1_0**.
-**Note:** The markings on the board may not always be accurate, and you should always refer to the manual for the correct positioning.
-
-* Locate the **Power Input Select** jumpers on the lower left corner of the board. Set the Power Select jumpers to position 5 and 6 to use the USB-OTG2 port for the power source. If you would like to use a different power source, refer to the [OLIMEX STM32-E407 user manual](https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407.pdf) for pin specifications.
-
-* Connect the USB Micro-A cable to the USB-OTG2 port on the board.
-
-* Connect the JTAG connector to the JTAG/SWD interface on the board.
-
-* Connect the USB A-B cable to the ARM-USB-TINY-H connector and your computer.
-
-* Check that the red PWR LED lights up.
-<br>
-### Load the Bootloader and Blinky Application
-
-Run the `newt load boot_olimex` command to load the bootloader image onto the board:
-```no-highlight
-$newt load -v boot_olimex
-Loading bootloader
-Load command: ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard ~/dev/myproj/bin/targets/boot_olimex/app/apps/boot/boot
-Successfully loaded image.
-```
-
-Note: If you are using Windows and get a `no device found` error, you will need to install the usb driver. Download [Zadig](http://zadig.akeo.ie) and run it:
-
-* Select Options > List All Devices.
-* Select `Olimex OpenOCD JTAG ARM-USB-TINY-H` from the drop down menu.
-* Select the `WinUSB` driver.
-* Click Install Driver.
-* Run the `newt load boot_olimex` command again.
-
-<br>
-Run the `newt load olimex_blinky` command to load the blinky application image onto the board:
-```no-highlight
-newt load -v olimex_blinky
-Loading app image into slot 1
-Load command: ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/olimex_stm32-e407_devboard_download.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard ~/dev/myproj/bin/targets/olimex_blinky/app/apps/blinky/blinky
-Successfully loaded image.
-
-```
-<br>
-The LED should be blinking!
-
-<br>
-Let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor, severing the debug connection to the JTAG port. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board.
-
- The LED light will start blinking again. Success!
-
-If you want to download the image to flash and open a gdb session, use `newt debug blinky`.
-
-**Note:** The output of the debug session below is for Mac OS and Linux platforms. On Windows, openocd and gdb are started in separate Windows Command Prompt terminals, and the terminals are automatically closed when you quit gdb. In addition, the output of openocd is logged to the openocd.log file in your project's base directory instead of the terminal.
-
-<br>
-Type `c` to continue inside the gdb session.
-
-```no-highlight
- $ newt debug blinky
- Debugging with ~/dev/myproj/hw/bsp/olimex_stm32-e407_...
- Debugging ~/dev/myproj/project/blinky/bin/blinky/blinky.elf
- GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
- Copyright (C) 2014 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 <http://gnu.org/licenses/gpl.html>
- ...
- (info)
- ...
- target state: halted
- target halted due to debug-request, current mode: Thread
- xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000
- Info : accepting 'gdb' connection from 3333
- Info : device id = 0x10036413
- Info : flash size = 1024kbytes
- Reset_Handler () at startup_STM32F40x.s:199
- 199 ldr r1, =__etext
- (gdb)
-```
-
-<br>
-
-If you want to erase the flash and load the image again you may use the following commands from within gdb. `flash erase_sector 0 0 x` tells it to erase sectors 0 through x. When you ask it to display (in hex notation) the contents of the sector starting at location 'lma,' you should see all f's. The memory location 0x8000000 is the start or origin of the flash memory contents and is specified in the olimex_stm32-e407_devboard.ld linker script. The flash memory locations is specific to the processor.
-```no-highlight
- (gdb) monitor flash erase_sector 0 0 4
- erased sectors 0 through 4 on flash bank 0 in 2.296712s
- (gdb) monitor mdw 0x08000000 16
- 0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (gdb) monitor flash info 0
-```
diff --git a/docs/os/tutorials/ota_upgrade_nrf52.md b/docs/os/tutorials/ota_upgrade_nrf52.md
deleted file mode 100644
index 30bd974..0000000
--- a/docs/os/tutorials/ota_upgrade_nrf52.md
+++ /dev/null
@@ -1,200 +0,0 @@
-## Over-the-Air Image Upgrade
-Mynewt OS supports over-the-air image upgrades. This tutorial shows you how to use the newtmgr tool to upgrade an image on a device over BLE communication.
-
-To support over-the-air image upgrade over BLE, a device must be running a Mynewt application that has newtmgr image management over BLE transport enabled. For this tutorial, we use the [bleprph](/os/tutorials/bleprph/bleprph-app/) application, which includes image management over BLE functionality, on an nRF52-DK board. If you prefer to use a different BLE application, see [Enable Newt Manager in any app](/os/tutorials/add_newtmgr/) to enable newtmgr image management over BLE transport support in your application.
-
-**Note:** Over-the-air upgrade via newtmgr BLE transport is supported on Mac OS and Linux. It is not supported on Windows platforms.
-
-### Prerequisites
-Ensure that you meet the following prerequisites:
-
-* Have Internet connectivity to fetch remote Mynewt components.
-* Have a computer that supports Bluetooth to communicate with the board and to build a Mynewt application.
-* Have a Micro-USB cable to connect the board and the computer.
-* Have a Nordic nRF52-DK Development Kit - PCA 10040
-* Install the [Segger JLINK software and documentation pack](https://www.segger.com/jlink-software.html).
-* Install the newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
-* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
-* Read the [Bootloader](/os/modules/bootloader/bootloader) section and understand the Mynewt bootloader concepts.
-* Build and load the **bleprph** application on to an nRF52-DK board via a serial connection. See [BLE Peripheral App](/os/tutorials/bleprph/bleprph-app/).
-
-<br>
-### Reducing the Log Level
-
-You need to build your application with log level set to INFO or lower. The default log level for the **bleprph** app is set to DEBUG. The extra logging causes the communication to timeout. Perform the following to reduce the log level to INFO, build, and load the application.
-
-```no-highlight
-
-$ newt target amend myperiph syscfg="LOG_LEVEL=1"
-$ newt build myperiph
-$ newt create-image myperiph 1.0.0
-$ newt load myperiph
-
-```
-
-<br>
-### Upgrading an Image on a Device
-Once you have an application with newtmgr image management with BLE transport support running on a device, you can use the newtmgr tool to upgrade an image over-the-air.
-
-You must perform the following steps to upgrade an image:
-
-Step 1: Create a newtmgr connection profile to communicate with the device over BLE.
-<br>
-Step 2: Upload the image to the secondary slot (slot 1) on the device.
-<br>
-Step 3: Test the image.
-<br>
-Step 4: Confirm and make the image permanent.
-
-See the [Bootloader](/os/modules/bootloader/bootloader) section for more information on the bootloader, image slots, and boot states.
-
-<br>
-### Step 1: Creating a Newtmgr Connection Profile
-The **bleprph** application sets and advertises `nimble-bleprph` as its bluetooth device address. Run the `newtmgr conn add` command to create a newtmgr connection profile that uses this peer address to communicate with the device over BLE:
-<br>
-```no-highlight
-
-$ newtmgr conn add mybleprph type=ble connstring="peer_name=nimble-bleprph"
-Connection profile mybleprph successfully added
-
-```
-<br>
-Verify that the newtmgr tool can communicate with the device and check the image status on the device:
-<br>
-```no-highlight
-
-$ newtmgr image list -c mybleprph
-Images:
- slot=0
- version: 1.0.0
- bootable: true
- flags: active confirmed
- hash: b8d17c77a03b37603cd9f89fdcfe0ba726f8ddff6eac63011dee2e959cc316c2
-Split status: N/A (0)
-
-```
-The device only has an image loaded on the primary slot (slot 0). It does not have an image loaded on the secondary slot (slot 1).
-<br>
-### Step 2: Uploading an Image to the Device
-We create an image with version 2.0.0 for the bleprph application from the `myperiph` target and upload the new image. You can upload a different image.
-<br>
-```no-highlight
-
-$ newt create-image myperiph 2.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/myperiph/app/apps/bleprph/bleprph.img
-
-```
-<br>
-Run the `newtmgr image upload` command to upload the image:
-
-```no-highlight
-
-$ newtmgr image upload -c mybleprph ~/dev/myproj/bin/targets/myperiph/app/apps/bleprph/bleprph.img
-215
-429
-642
-855
-1068
-1281
-
-...
-
-125953
-126164
-126375
-126586
-126704
-Done
-```
-The numbers indicate the number of bytes that the newtmgr tool has uploaded.
-
-<br>
-Verify that the image uploaded to the secondary slot on the device successfully:
-<br>
-
-```no-highlight
-
-$ newtmgr image list -c mybleprph
-Images:
- slot=0
- version: 1.0.0
- bootable: true
- flags: active confirmed
- hash: b8d17c77a03b37603cd9f89fdcfe0ba726f8ddff6eac63011dee2e959cc316c2
- slot=1
- version: 2.0.0
- bootable: true
- flags:
- hash: 291ebc02a8c345911c96fdf4e7b9015a843697658fd6b5faa0eb257a23e93682
-Split status: N/A (0)
-
-```
-
-The device now has the uploaded image in the secondary slot (slot 1).
-<br>
-### Step 3: Testing the Image
-The image is uploaded to the secondary slot but is not yet active. You must run the `newtmgr image test` command to set the image status to **pending** and reboot the device. When the device reboots, the bootloader copies this image to the primary slot and runs the image.
-<br>
-```no-highlight
-
-$ newtmgr image test -c mybleprph 291ebc02a8c345911c96fdf4e7b9015a843697658fd6b5faa0eb257a23e93682
-Images:
- slot=0
- version: 1.0.0
- bootable: true
- flags: active confirmed
- hash: b8d17c77a03b37603cd9f89fdcfe0ba726f8ddff6eac63011dee2e959cc316c2
- slot=1
- version: 2.0.0
- bootable: true
- flags: pending
- hash: 291ebc02a8c345911c96fdf4e7b9015a843697658fd6b5faa0eb257a23e93682
-Split status: N/A (0)
-
-```
-The status of the image in the secondary slot is now set to **pending**.
-
-<br>
-Power the device OFF and ON and run the `newtmgr image list` command to check the image status on the device after the reboot:
-<br>
-```no-highlight
-
-$ newtmgr image list -c mybleprph
-Images:
- slot=0
- version: 2.0.0
- bootable: true
- flags: active
- hash: 291ebc02a8c345911c96fdf4e7b9015a843697658fd6b5faa0eb257a23e93682
- slot=1
- version: 1.0.0
- bootable: true
- flags: confirmed
- hash: b8d17c77a03b37603cd9f89fdcfe0ba726f8ddff6eac63011dee2e959cc316c2
-Split status: N/A (0)
-
-```
-The uploaded image is now active and running in the primary slot. The image, however, is not confirmed. The confirmed image is in the secondary slot. On the next reboot, the bootloader reverts to using the confirmed image. It copies the confirmed image to the primary slot and runs the image when the device reboots. You need to confirm and make the uploaded image in the primary slot permanent.
-<br>
-### Step 4: Confirming the Image
-Run the `newtmgr image confirm` command to confirm and make the uploaded image permanent. Since the uploaded image is currently the active image, you can confirm the image setup without specifying the image hash value in the command:
-
-```no-highlight
-
-$ newtmgr image confirm -c mybleprph
-Images:
- slot=0
- version: 2.0.0
- bootable: true
- flags: active confirmed
- hash: 291ebc02a8c345911c96fdf4e7b9015a843697658fd6b5faa0eb257a23e93682
- slot=1
- version: 1.0.0
- bootable: true
- flags:
- hash: b8d17c77a03b37603cd9f89fdcfe0ba726f8ddff6eac63011dee2e959cc316c2
-Split status: N/A (0)
-
-```
-
-The uploaded image is now the active and confirmed image. You have successfully upgraded an image over-the-air.
diff --git a/docs/os/tutorials/pics/BNO055_small.jpg b/docs/os/tutorials/pics/BNO055_small.jpg
deleted file mode 100644
index d8fd34a..0000000
--- a/docs/os/tutorials/pics/BNO055_small.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/LightBlue-1.jpg b/docs/os/tutorials/pics/LightBlue-1.jpg
deleted file mode 100644
index 87a305e..0000000
--- a/docs/os/tutorials/pics/LightBlue-1.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/LightBlue-2.jpg b/docs/os/tutorials/pics/LightBlue-2.jpg
deleted file mode 100644
index 715deff..0000000
--- a/docs/os/tutorials/pics/LightBlue-2.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/LightBlue-3.jpg b/docs/os/tutorials/pics/LightBlue-3.jpg
deleted file mode 100644
index 5ceb627..0000000
--- a/docs/os/tutorials/pics/LightBlue-3.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/LightBlue-4.jpg b/docs/os/tutorials/pics/LightBlue-4.jpg
deleted file mode 100644
index a8e35c3..0000000
--- a/docs/os/tutorials/pics/LightBlue-4.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/LightBlue-5.jpg b/docs/os/tutorials/pics/LightBlue-5.jpg
deleted file mode 100644
index 4a3cbbd..0000000
--- a/docs/os/tutorials/pics/LightBlue-5.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/LightBlue-6.jpg b/docs/os/tutorials/pics/LightBlue-6.jpg
deleted file mode 100644
index eb4ca4d..0000000
--- a/docs/os/tutorials/pics/LightBlue-6.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/MyNewtSensorReader.jpg b/docs/os/tutorials/pics/MyNewtSensorReader.jpg
deleted file mode 100644
index 997a359..0000000
--- a/docs/os/tutorials/pics/MyNewtSensorReader.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/MyNewtSensorReader006.jpg b/docs/os/tutorials/pics/MyNewtSensorReader006.jpg
deleted file mode 100644
index c15d69d..0000000
--- a/docs/os/tutorials/pics/MyNewtSensorReader006.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/NRF52_I2C_small.jpg b/docs/os/tutorials/pics/NRF52_I2C_small.jpg
deleted file mode 100644
index 3d2595c..0000000
--- a/docs/os/tutorials/pics/NRF52_I2C_small.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/STM32-E407_bot_small.jpg b/docs/os/tutorials/pics/STM32-E407_bot_small.jpg
deleted file mode 100755
index da1889e..0000000
--- a/docs/os/tutorials/pics/STM32-E407_bot_small.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/STM32-E407_top_small.jpg b/docs/os/tutorials/pics/STM32-E407_top_small.jpg
deleted file mode 100755
index 938a04b..0000000
--- a/docs/os/tutorials/pics/STM32-E407_top_small.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/STM32f3discovery_connector.png b/docs/os/tutorials/pics/STM32f3discovery_connector.png
deleted file mode 100644
index 1f4437a..0000000
--- a/docs/os/tutorials/pics/STM32f3discovery_connector.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/Senseair1.png b/docs/os/tutorials/pics/Senseair1.png
deleted file mode 100644
index 9b469b3..0000000
--- a/docs/os/tutorials/pics/Senseair1.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/Senseair2.png b/docs/os/tutorials/pics/Senseair2.png
deleted file mode 100644
index 38be672..0000000
--- a/docs/os/tutorials/pics/Senseair2.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/adc-demo-1.png b/docs/os/tutorials/pics/adc-demo-1.png
deleted file mode 100644
index 6e5de58..0000000
--- a/docs/os/tutorials/pics/adc-demo-1.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/adc-demo-2.png b/docs/os/tutorials/pics/adc-demo-2.png
deleted file mode 100644
index be2cce7..0000000
--- a/docs/os/tutorials/pics/adc-demo-2.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/arduino_wifi.png b/docs/os/tutorials/pics/arduino_wifi.png
deleted file mode 100644
index 8129686..0000000
--- a/docs/os/tutorials/pics/arduino_wifi.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/bottomview.png b/docs/os/tutorials/pics/bottomview.png
deleted file mode 100644
index c50a461..0000000
--- a/docs/os/tutorials/pics/bottomview.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/breadboard.png b/docs/os/tutorials/pics/breadboard.png
deleted file mode 100644
index 39a2b9d..0000000
--- a/docs/os/tutorials/pics/breadboard.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/device_manager_ft232H.png b/docs/os/tutorials/pics/device_manager_ft232H.png
deleted file mode 100755
index ce7bd59..0000000
--- a/docs/os/tutorials/pics/device_manager_ft232H.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/device_manager_no_ft232H.png b/docs/os/tutorials/pics/device_manager_no_ft232H.png
deleted file mode 100755
index ab4c2d4..0000000
--- a/docs/os/tutorials/pics/device_manager_no_ft232H.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/mkr1000-jlink.jpg b/docs/os/tutorials/pics/mkr1000-jlink.jpg
deleted file mode 100755
index cfa09ca..0000000
--- a/docs/os/tutorials/pics/mkr1000-jlink.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/mkr1000-serial.jpg b/docs/os/tutorials/pics/mkr1000-serial.jpg
deleted file mode 100755
index f4e3819..0000000
--- a/docs/os/tutorials/pics/mkr1000-serial.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/nrf52.JPG b/docs/os/tutorials/pics/nrf52.JPG
deleted file mode 100644
index 906dd43..0000000
--- a/docs/os/tutorials/pics/nrf52.JPG
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/nrf52.png b/docs/os/tutorials/pics/nrf52.png
deleted file mode 100644
index 9fb31fe..0000000
--- a/docs/os/tutorials/pics/nrf52.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/primo-jlink.jpg b/docs/os/tutorials/pics/primo-jlink.jpg
deleted file mode 100644
index 3f58af1..0000000
--- a/docs/os/tutorials/pics/primo-jlink.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/putty.png b/docs/os/tutorials/pics/putty.png
deleted file mode 100755
index 63c5f10..0000000
--- a/docs/os/tutorials/pics/putty.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/segger_sysview1.png b/docs/os/tutorials/pics/segger_sysview1.png
deleted file mode 100644
index e1bdcb0..0000000
--- a/docs/os/tutorials/pics/segger_sysview1.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/segger_sysview_recording.png b/docs/os/tutorials/pics/segger_sysview_recording.png
deleted file mode 100644
index e0a0e42..0000000
--- a/docs/os/tutorials/pics/segger_sysview_recording.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/segger_sysview_start_record.png b/docs/os/tutorials/pics/segger_sysview_start_record.png
deleted file mode 100644
index 3cb93f0..0000000
--- a/docs/os/tutorials/pics/segger_sysview_start_record.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/serial_conn.png b/docs/os/tutorials/pics/serial_conn.png
deleted file mode 100644
index 32f27c7..0000000
--- a/docs/os/tutorials/pics/serial_conn.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/smart_controller_accelerometer.png b/docs/os/tutorials/pics/smart_controller_accelerometer.png
deleted file mode 100644
index 732b63a..0000000
--- a/docs/os/tutorials/pics/smart_controller_accelerometer.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/smart_controller_main.png b/docs/os/tutorials/pics/smart_controller_main.png
deleted file mode 100644
index fb9718d..0000000
--- a/docs/os/tutorials/pics/smart_controller_main.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/stm32f4_disc.jpg b/docs/os/tutorials/pics/stm32f4_disc.jpg
deleted file mode 100755
index cbed05f..0000000
--- a/docs/os/tutorials/pics/stm32f4_disc.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/task_lesson.png b/docs/os/tutorials/pics/task_lesson.png
deleted file mode 100644
index 4b09506..0000000
--- a/docs/os/tutorials/pics/task_lesson.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/thingy.jpg b/docs/os/tutorials/pics/thingy.jpg
deleted file mode 100644
index d6d4b56..0000000
--- a/docs/os/tutorials/pics/thingy.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/thingy_jlink.jpg b/docs/os/tutorials/pics/thingy_jlink.jpg
deleted file mode 100644
index 75cfaac..0000000
--- a/docs/os/tutorials/pics/thingy_jlink.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pics/topview.png b/docs/os/tutorials/pics/topview.png
deleted file mode 100644
index e889ee0..0000000
--- a/docs/os/tutorials/pics/topview.png
+++ /dev/null
Binary files differ
diff --git a/docs/os/tutorials/pin-wheel-mods.md b/docs/os/tutorials/pin-wheel-mods.md
deleted file mode 100644
index f4a7f88..0000000
--- a/docs/os/tutorials/pin-wheel-mods.md
+++ /dev/null
@@ -1,99 +0,0 @@
-## Pin Wheel Modifications to "Blinky" on STM32F3 Discovery
-<br>
-### Objective
-
-Learn how to modify an existing app -- the [blinky](STM32F303.md) app -- to light all the LEDs on the STM32F3 Discovery board.
-
-<br>
-
-### What you need
-
-* Discovery kit with STM32F303VC MCU
-* Laptop running Mac OSX.
-* It is assumed you have already installed and run the [blinky](STM32F303.md) app succesfully.
-
-<br>
-
-Since you've already successfully created your blinky app project, you'll need to modify only one file, main.c, in order to get this app working.
-
-<br>
-
-The main.c file resides in the apps/blinky/src directory in your project folder so you can edit it with your favorite editor. You'll make the following changes:
-
-<br>
-
-Replace the line:
-
-
-```c
-int g_led_pin;
-```
-
-With the line:
-
-```c
-int g_led_pins[8] = {LED_BLINK_PIN_1, LED_BLINK_PIN_2, LED_BLINK_PIN_3, LED_BLINK_PIN_4, LED_BLINK_PIN_5, LED_BLINK_PIN_6, LED_BLINK_PIN_7, LED_BLINK_PIN_8};
-```
-
-So that you now have an array of all 8 LED Pins on the board.
-
-Delete the line:
-
-```c
-g_led_pin = LED_BLINK_PIN;
-```
-
-And in its place, add the following lines to initialize all the LED_PINS correctly:
-
-```c
-int x;
-for(x = 0; x < 8; x++){
- hal_gpio_init_out(g_led_pins[x], 1);
-}
-int p = 0;
-```
-
-We'll use that 'p' later. Next you'll want to change the line:
-
-```c
-os_time_delay(1000);
-```
-
-to a shorter time in order to make it a little more interesting. A full 1 second delay doesn't look great, so try 100 for starters and then you can adjust it to your liking.
-
-Finally, change the line:
-
-```c
-hal_gpio_toggle(g_led_pin);
-```
-
-to look like this:
-
-```c
-hal_gpio_toggle(g_led_pins[p++]);
-p = (p > 7) ? 0 : p;
-```
-
-<br>
-
-### Build the target and executables and download the images
-
-Run the same commands you used on the blinky app to build and load this one:
-
-```no-highlight
-$ newt create-image stmf3_blinky 1.2.3
-App image successfully generated: ~/dev/myproj/bin/stmf3_blinky/apps/blinky/blinky.img
-Build manifest:~/dev/myproj/bin/stmf3_blinky/apps/blinky/manifest.json
-$ newt -v load stmf3_boot
-$ newt -v load stmf3_blinky
-```
-
-<br>
-
-### Watch the LEDs go round and round
-
-The colored LEDs should now all light up in succession, and once they're all lit, they should then go off in the same order. This should repeat continuously.
-
-If you see anything missing or want to send us feedback, please do so by signing up for appropriate mailing lists on our [Community Page](../../community.md).
-
-Keep on hacking and blinking!
diff --git a/docs/os/tutorials/project-nrf52-slinky.md b/docs/os/tutorials/project-nrf52-slinky.md
deleted file mode 100644
index 1913474..0000000
--- a/docs/os/tutorials/project-nrf52-slinky.md
+++ /dev/null
@@ -1,223 +0,0 @@
-## Project Slinky using the Nordic nRF52 Board
-This tutorial shows you how to create, build and run the Slinky application and communicate with newtmgr for a Nordic nRF52 board.
-
-### Prerequisites
-* Meet the prerequisites listed in [Project Slinky](/os/tutorials/project-slinky.md).
-* Have a Nordic nRF52-DK board.
-* Install the [Segger JLINK Software and documentation pack](https://www.segger.com/jlink-software.html).
-
-### Create a New Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already have a project created or completed the [Sim Slinky](project-slinky.md) tutorial.
-
-Run the following commands to create a new project. We name the project `slinky`.
-
-```no-highlight
-$ newt new slinky
-Downloading project skeleton from apache/mynewt-blinky...
-...
-Installing skeleton in slink...
-Project slinky successfully created
-$ cd slinky
-$newt install
-apache-mynewt-core
-```
-
-<br>
-
-### <a name="create_targets"></a> Create the Targets
-
-Create two targets for the nRF52-DK board - one for the bootloader and one for the Slinky application.
-
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `nrf52_boot`.
-
-```no-highlight
-$ newt target create nrf52_boot
-$ newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set nrf52_boot build_profile=optimized
-$ newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
-```
-<br>
-Run the following `newt target` commands to create a target for the Slinky application. We name the target `nrf52_slinky`.
-
-```no-highlight
-$ newt target create nrf52_slinky
-$ newt target set nrf52_slinky bsp=@apache-mynewt-core/hw/bsp/nrf52dk
-$ newt target set nrf52_slinky build_profile=debug
-$ newt target set nrf52_slinky app=@apache-mynewt-core/apps/slinky
-```
-
-<br>
-
-### Build the Targets
-
-Run the `newt build nrf52_boot` command to build the bootloader:
-
-```no-highlight
-$ newt build nrf52_boot
-Building target targets/nrf52_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
- ...
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/slinky/bin/targets/nrf52_boot/app/apps/boot/boot.elf
-Target successfully built: targets/nrf52_boot
-```
-<br>
-
-Run the `newt build nrf52_slinky` command to build the Slinky application:
-
-```no-highlight
-$newt build nrf52_slinky
-Building target targets/nrf52_slinky
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/split/src/split.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/boot/split/src/split_config.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aesni.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
-Compiling repos/apache-mynewt-core/apps/slinky/src/main.c
-
- ...
-
-Archiving util_mem.a
-Linking ~/dev/slinky/bin/targets/nrf52_slinky/app/apps/slinky/slinky.elf
-Target successfully built: targets/nrf52_slinky
-```
-
-<br>
-
-### Sign and Create the Slinky Application Image
-
-Run the `newt create-image nrf52_slinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
-
-```no-highlight
-$ newt create-image nrf52_slinky 1.0.0
-App image succesfully generated: ~/dev/slinky/bin/targets/nrf52_slinky/app/apps/slinky/slinky.img
-$
-```
-<br>
-
-### Connect to the Board
-
-* Connect a micro-USB cable from your computer to the micro-USB port on the nRF52-DK board.
-* Turn the power on the board to ON. You should see the green LED light up on the board.
-
-<br>
-### Load the Bootloader and the Slinky Application Image
-
-Run the `newt load nrf52_boot` command to load the bootloader onto the board:
-
-```no-highlight
-$ newt load nrf52_boot
-Loading bootloader
-$
-```
-<br>
-Run the `newt load nrf52_slinky` command to load the Slinky application image onto the board:
-```no-highlight
-$ newt load nrf52_slinky
-Loading app image into slot 1
-$
-```
-<br>
-
-
-### Connect Newtmgr with the Board using a Serial Connection
-
-Set up a serial connection from your computer to the nRF52-DK board (See [Serial Port Setup](/os/get_started/serial_access.md)).
-
-Locate the port, in the /dev directory on your computer, that the serial connection uses. The format of the port name is platform dependent:
-
-* Mac OS uses the format `tty.usbserial-<some identifier>`.
-* Linux uses the format `TTYUSB<N>`, where `N` is a number. For example, TTYUSB2.
-* MinGW on Windows uses the format `ttyS<N>`, where `N` is a number. You must map the port name to a Windows COM port: `/dev/ttyS<N>` maps to `COM<N+1>`. For example, `/dev/ttyS2` maps to `COM3`.
-
- You can also use the Windows Device Manager to find the COM port number.
-
-<br>
-```no-highlight
-$ ls /dev/tty*usbserial*
-/dev/tty.usbserial-1d11
-$
-```
-<br>
-
-Setup a newtmgr connection profile for the serial port. For our example, the port is `/dev/tty.usbserial-1d11`.
-
-Run the `newtmgr conn add` command to define a newtmgr connection profile for the serial port. We name the connection profile `nrf52serial`.
-
-**Note**:
-
-* You will need to replace the `connstring` with the specific port for your serial connection.
-* On Windows, you must specify `COM<N+1>` for the connstring if `/dev/ttyS<N>` is the serial port.
-
-<br>
-```no-highlight
-$ newtmgr conn add nrf52serial type=serial connstring=/dev/tty.usbserial-1d11
-Connection profile nrf52serial successfully added
-$
-```
-
-<br>
-You can run the `newt conn show` command to see all the newtmgr connection profiles:
-
-```no-highlight
-$ newtmgr conn show
-Connection profiles:
- nrf52serial: type=serial, connstring='/dev/tty.usbserial-1d11'
- sim1: type=serial, connstring='/dev/ttys012'
-$
-```
-
-<br>
-### Use Newtmgr to Query the Board
-Run some newtmgr commands to query and receive responses back from the board (See the [Newt Manager Guide](../../newtmgr/overview) for more information on the newtmgr commands).
-
-
-Run the `newtmgr echo hello -c nrf52serial` command. This is the simplest command that requests the board to echo back the text.
-
-```no-highlight
-$ newtmgr echo hello -c nrf52serial
-hello
-$
-```
-<br>
-Run the `newtmgr image list -c nrf52serial` command to list the images on the board:
-
-```no-highlight
-$ newtmgr image list -c nrf52serial
-Images:
- slot=0
- version: 1.0.0
- bootable: true
- flags: active confirmed
- hash: f411a55d7a5f54eb8880d380bf47521d8c41ed77fd0a7bd5373b0ae87ddabd42
-Split status: N/A
-$
-```
-
-<br>
-Run the `newtmgr taskstat -c nrf52serial` command to display the task statistics on the board:
-
-```no-highlight
-$ newtmgr taskstat -c nrf52serial
- task pri tid runtime csw stksz stkuse last_checkin next_checkin
- idle 255 0 43484 539 64 32 0 0
- main 127 1 1 90 1024 353 0 0
- task1 8 2 0 340 192 114 0 0
- task2 9 3 0 340 64 31 0 0
-$
-```
diff --git a/docs/os/tutorials/project-sim-slinky.md b/docs/os/tutorials/project-sim-slinky.md
deleted file mode 100644
index 8231c86..0000000
--- a/docs/os/tutorials/project-sim-slinky.md
+++ /dev/null
@@ -1,119 +0,0 @@
-## Project Sim Slinky
-
-This tutorial shows you how to create, build and run the Slinky application and communicate with newtmgr for a simulated device. This is supported on Mac OS and Linux platforms.
-
-<br>
-### Prerequisites
-
-Meet the prerequisites listed in [Project Slinky](/os/tutorials/project-slinky.md).
-
-### Creating a new project
-
-Instructions for creating a project are located in the [Basic Setup](../get_started/project_create/) section of the [Mynewt Documentation](../introduction/)
-
-We will list only the steps here for brevity. We will name the project `slinky`.
-
-```no-highlight
-$ newt new slinky
-Downloading project skeleton from apache/mynewt-blinky...
-...
-Installing skeleton in slink...
-Project slinky successfully created
-$ cd slinky
-$newt install
-apache-mynewt-core
-```
-
-### Setting up your target build
-
-Create a target for `slinky` using the native bsp. We will list only the steps and suppress the tool output here for brevity.
-
-```no-highlight
- $ newt target create sim_slinky
- $ newt target set sim_slinky bsp=@apache-mynewt-core/hw/bsp/native
- $ newt target set sim_slinky build_profile=debug
- $ newt target set sim_slinky app=@apache-mynewt-core/apps/slinky
-```
-
-### Building Your target
-
-To build your target, use `newt build`. When complete, an executable file
-is created.
-
-```no-highlight
- $ newt build sim_slinky
- Building target targets/sim_slinky
- Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
- Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
- Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
- Compiling repos/apache-mynewt-core/boot/split/src/split.c
- Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
- Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
- Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
- Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aesni.c
- Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
- Compiling repos/apache-mynewt-core/boot/split/src/split_config.c
- Compiling repos/apache-mynewt-core/apps/slinky/src/main.c
-
- ...
-
- Archiving util_crc.a
- Archiving util_mem.a
- Linking ~/dev/slinky/bin/targets/sim_slinky/app/apps/slinky/slinky.elf
- Target successfully built: targets/sim_slinky
-
-```
-
-### Run the target
-
-Run the executable you have build for the simulated environment. The serial port name on which the simulated target is connected is shown in the output when mynewt slinky starts.
-
-```no-highlight
- $ ~/dev/slinky/bin/targets/sim_slinky/app/apps/slinky/slinky.elf
- uart0 at /dev/ttys005
-```
-
-<br>
-
-In this example, the slinky app opened up a com port `/dev/ttys005` for communications with newtmgr.
-
-**NOTE:** This application will block. You will need to open a new console (or execute this in another console) to continue the tutorial.*
-
-<br>
-
-### Setting up a connection profile
-
-You will now set up a connection profile using `newtmgr` for the serial port connection and start communicating with the simulated remote device.
-
-```no-highlight
- $ newtmgr conn add sim1 type=serial connstring=/dev/ttys005
- Connection profile sim1 successfully added
- $ newtmgr conn show
- Connection profiles:
- sim1: type=serial, connstring='/dev/ttys005'
-```
-
-### Executing newtmgr commands with the target
-
-You can now use connection profile `sim1` to talk to the running sim_slinky.
-As an example, we will query the running mynewt OS for the usage of its
-memory pools.
-
-```no-highlight
- $ newtmgr -c sim1 mpstat
- Return Code = 0
- name blksz cnt free min
- msys_1 292 12 10 10
-
-```
-
-As a test command, you can send an arbitrary string to the target and it
-will echo that string back in a response to newtmgr.
-
-```no-highlight
- $ newtmgr -c sim1 echo "Hello Mynewt"
- Hello Mynewt
-```
-
-In addition to these, you can also examine running tasks, statistics,
-logs, image status (not on sim), and configuration.
diff --git a/docs/os/tutorials/project-slinky.md b/docs/os/tutorials/project-slinky.md
deleted file mode 100644
index 57073cd..0000000
--- a/docs/os/tutorials/project-slinky.md
+++ /dev/null
@@ -1,36 +0,0 @@
-## Project Slinky
-
-The goal of the project is to use a sample application called "Slinky" included in the Mynewt repository to enable remote communications with a device running the Mynewt OS. The protocol for remote communications is called newt manager (newtmgr).
-
-If you have an existing project using a target that does not use the Slinky application and you wish to add newtmgr functionality to it, check out the tutorial titled [Enable newtmgr in any app](add_newtmgr.md).
-
-### Available Tutorials
-Tutorials are available for the following boards:
-
-* [Slinky on a simulated device](/os/tutorials/project-sim-slinky). This is supported on Mac OS and Linux platforms.
-* [Slinky on a nRF52](/os/tutorials/project-nrf52-slinky).
-* [Slinky on an Olimex](/os/tutorials/project-stm32-slinky).
-<br>
-### Prerequisites
-
-Ensure that you meet the following prerequisites before continuing with this tutorial:
-
-* Have Internet connectivity to fetch remote Mynewt components.
-* Have a computer to build a Mynewt application and connect to the board over USB.
-* Have a Micro-USB cable to connect the board and the computer.
-* Have a [serial port setup](/os/get_started/serial_access.md).
-* Install the newt tool and the toolchains (See [Basic Setup](/os/get_started/get_started.md)).
-* Install the [newtmgr tool](/newtmgr/install_mac.md).
-* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
-* Create a project space (directory structure) and populated it with the core code repository (apache-mynewt-core) or kn
-ow how to as explained in [Creating Your First Project](/os/get_started/project_create).
-
-### Overview of Steps
-
-* Install dependencies.
-* Define the bootloader and Slinky application target for the target board.
-* Build the bootloader target.
-* Build the Slinky application target and create an application image.
-* Set a up serial connection with the targets.
-* Create a connection profile using the newtmgr tool.
-* Use the newtmgr tool to communicate with the targets.
diff --git a/docs/os/tutorials/project-stm32-slinky.md b/docs/os/tutorials/project-stm32-slinky.md
deleted file mode 100644
index 72bf4e3..0000000
--- a/docs/os/tutorials/project-stm32-slinky.md
+++ /dev/null
@@ -1,245 +0,0 @@
-## Project Slinky Using Olimex Board
-
-This tutorial shows you how to create, build and run the Slinky application and communicate with newtmgr for an Olimex STM-E407 board.
-<br>
-###Prerequisites
-* Meet the prerequisites listed in [Project Slinky](/os/tutorials/project-slinky.md).
-* Have a STM32-E407 development board from Olimex.
-* Have a ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
-* Have a USB A-B type cable to connect the debugger to your computer.
-* Have a USB to TTL Serial Cable with female wiring harness.
-* Install the [OpenOCD debugger](/os/get_started/cross_tools/).
-
-### Create a New Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already have a project created or completed the [Sim Slinky](project-slinky.md) tutorial.
-
-```no-highlight
-$ newt new slinky
-Downloading project skeleton from apache/mynewt-blinky...
-...
-Installing skeleton in slink...
-Project slink successfully created
-$ cd slinky
-$newt install
-apache-mynewt-core
-```
-
-<br>
-
-### <a name="create_targets"></a> Create the Targets
-Create two targets for the STM32-E407 board - one for the bootloader and one for the Slinky application.
-
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `
-stm32_boot`.
-
-```no-highlight
-$ newt target create stm32_boot
-$ newt target set stm32_boot bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
-$ newt target set stm32_boot build_profile=optimized
-$ newt target set stm32_boot target.app=@apache-mynewt-core/apps/boot
-```
-<br>
-Run the following `newt target` commands to create a target for the Slinky application. We name the target `stm32_slinky`.
-
-```no-highlight
-$ newt target create stm32_slinky
-$ newt target set stm32_slinky bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
-$ newt target set stm32_slinky build_profile=debug
-$ newt target set stm32_slinky app=@apache-mynewt-core/apps/slinky
-```
-<br>
-
-### Build the Targets
-Run the `newt build stm32_boot` command to build the bootloader:
-
-```no-highlight
-$ newt build stm32_boot
-Building target targets/stm32_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
-
- ...
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/slinky/bin/targets/stm32_boot/app/apps/boot/boot.elf
-Target successfully built: targets/stm32_boot
-$
-```
-<br>
-Run the `newt build stm32_slinky` command to build the Slinky application:
-
-```no-highlight
-$newt build stm32_slinky
-Building target targets/stm32_slinky
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/boot/split/src/split.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/slinky/src/main.c
-
- ...
-
-Archiving util_crc.a
-Archiving util_mem.a
-Linking ~/dev/slinky/bin/targets/stm32_slinky/app/apps/slinky/slinky.elf
-Target successfully built: targets/stm32_slinky
-$
-```
-<br>
-### Sign and Create the Slinky Application Image
-
-Run the `newt create-image stm32_slinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
-
-```no-highlight
-newt create-image stm32_slinky 1.0.0
-App image succesfully generated: ~/dev/slinky/bin/targets/stm32_slinky/app/apps/slinky/slinky.img
-$
-```
-<br>
-
-
-### Connect to the Board
-
-* Connect the USB A-B type cable to the ARM-USB-TINY-H debugger connector.
-* Connect the ARM-USB-Tiny-H debugger connector to your computer and the board.
-* Connect the USB Micro-A cable to the USB-OTG2 port on the board.
-* Set the Power Sel jumper on the board to pins 5 and 6 to select USB-OTG2 as the power source. If you would like to use a different power source, refer to the [OLIMEX STM32-E407 user manual](https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407.pdf) for pin specifications.
-
-You should see a red LED light up on the board.
-
-<br>
-### Load the Bootloader and the Slinky Application Image
-
-Run the `newt load stm32_boot` command to load the bootloader onto the board:
-
-```no-highlight
-$ newt load stm32_boot
-Loading bootloader
-$
-```
-<br>
-Note: If you are using Windows and get a `no device found` error, you will need to install the usb driver. Download [Zadig](http://zadig.akeo.ie) and run it:
-
-* Select Options > List All Devices.
-* Select `Olimex OpenOCD JTAG ARM-USB-TINY-H` from the drop down menu.
-* Select the `WinUSB` driver.
-* Click Install Driver.
-* Run the `newt load stm32_boot` command again.
-
-<br>
-Run the `newt load stm32_slinky` command to load the Slinky application image onto the board:
-```no-highlight
-$ newt load stm32_slinky
-Loading app image into slot 1
-$
-```
-<br>
-
-### Connect Newtmgr with the Board using a Serial Connection
-
-Locate the PC6/USART6_TX (pin 3), PC7/USART6_RX (pin 4), and GND (pin 2) of the UEXT connector on the Olimex board. More information on the UEXT connector can be found at [https://www.olimex.com/Products/Modules/UEXT/](https://www.olimex.com/Products/Modules/UEXT/). The schematic of the board can be found at [https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407_sch.pdf](https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407_sch.pdf) for reference.
-
-
-
-
-* Connect the female RX pin of the USB-TTL serial cable to the TX (Pin 3) of the UEXT connector on the board.
-* Connect the female TX pin of the USB-TTL serial cable to the RX (Pin 4) of the UEXT connector on the board.
-* Connect the GND pin of the USB-TTL serial cable to the GND (Pin 2) of the UEXT connector on the board.
-
-<br>
-Locate the port, in the /dev directory on your computer, that the serial connection uses. The format of the port name is platform dependent:
-
-
-* Mac OS uses the format `tty.usbserial-<some identifier>`.
-* Linux uses the format `TTYUSB<N>`, where `N` is a number. For example, TTYUSB2.
-* MinGW on Windows uses the format `ttyS<N>`, where `N` is a number. You must map the port name to a Windows COM port: `/dev/ttyS<N>` maps to `COM<N+1>`. For example, `/dev/ttyS2` maps to `COM3`.
-
- You can also use the Windows Device Manager to find the COM port number.
-
-<br>
-```no-highlight
-$ ls /dev/tty*usbserial*
-/dev/tty.usbserial-1d13
-$
-```
-
-<br>
-Setup a newtmgr connection profile for the serial port. For our example, the port is `/dev/tty.usbserial-1d13`.
-
-Run the `newtmgr conn add` command to define a newtmgr connection profile for the serial port. We name the connection profile `stm32serial`.
-
-**Note**:
-
-* You will need to replace the `connstring` with the specific port for your serial connection.
-* On Windows, you must specify `COM<N+1>` for the connstring if `/dev/ttyS<N>` is the serial port.
-
-<br>
-```no-highlight
-$ newtmgr conn add stm32serial type=serial connstring=/dev/tty.usbserial-1d13
-Connection profile stm32serial successfully added
-$
-```
-<br>
-You can run the `newt conn show` command to see all the newtmgr connection profiles:
-
-```no-highlight
-$ newtmgr conn show
-Connection profiles:
- stm32serial: type=serial, connstring='/dev/tty.usbserial-1d13'
- sim1: type=serial, connstring='/dev/ttys012'
-$
-```
-
-<br>
-### Use Newtmgr to Query the Board
-Run some newtmgr commands to query and receive responses back from the board (See the [Newt Manager Guide](newtmgr/overview) for more information on the newtmgr commands).
-
-Run the `newtmgr echo hello -c stm32serial` command. This is the simplest command that requests the board to echo back the
- text.
-
-```no-highlight
-$ newtmgr echo hello -c stm32serial
-hello
-$
-```
-<br>
-Run the `newtmgr image list -c stm32serial` command to list the images on the board:
-
-```no-highlight
-$ newtmgr image list -c stm32serial
-Images:
- slot=0
- version: 1.0.0
- bootable: true
- flags: active confirmed
- hash: 9cf8af22b1b573909a8290a90c066d4e190407e97680b7a32243960ec2bf3a7f
-Split status: N/A
-$
-```
-
-
-<br>
-Run the `newtmgr taskstat -c stm32serial` command to display the task statistics on the board:
-
-```no-highlight
-$ newtmgr taskstat -c stm32serial
- task pri tid runtime csw stksz stkuse last_checkin next_checkin
- idle 255 0 157179 157183 64 25 0 0
- main 127 1 4 72 1024 356 0 0
- task1 8 2 0 158 192 114 0 0
- task2 9 3 0 158 64 30 0 0
-$
-```
-
-
diff --git a/docs/os/tutorials/rbnano2.md b/docs/os/tutorials/rbnano2.md
deleted file mode 100644
index 8a5bfe3..0000000
--- a/docs/os/tutorials/rbnano2.md
+++ /dev/null
@@ -1,195 +0,0 @@
-## Blinky, your "Hello World!", on RedBear Nano 2
-
-This tutorial shows you how to create, build and run the Blinky application on a RedBear Nano 2 board.
-<br>
-
-### Prerequisites
-
-* Meet the prerequisites listed in [Project Blinky](/os/tutorials/blinky.md).
-* Have a RedBear Nano 2 board.
-* Install a patched version of OpenOCD 0.10.0 described in [Install OpenOCD](/os/get_started/cross_tools/).
-
-### Create a Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already have a project created.
-
-Run the following commands to create a new project:
-
-```no-highlight
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new myproj
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in myproj...
- Project myproj successfully created.
- $ cd myproj
- $ newt install
- apache-mynewt-core
- $
-```
-
-<br>
-
-### <a name="create_targets"></a>Create the Targets
-
-Create two targets for the RedBear Nano 2 board - one for the bootloader and one for the Blinky application.
-
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `rbnano2_boot`:
-
-```no-highlight
-$ newt target create rbnano2_boot
-$ newt target set rbnano2_boot app=@apache-mynewt-core/apps/boot
-$ newt target set rbnano2_boot bsp=@apache-mynewt-core/hw/bsp/rb-nano2
-$ newt target set rbnano2_boot build_profile=optimized
-```
-
-<br>
-Run the following `newt target` commands to create a target for the Blinky application. We name the target `nrf52_blinky`.
-
-```no-highlight
-$ newt target create rbnano2_blinky
-$ newt target set rbnano2_blinky app=apps/blinky
-$ newt target set rbnano2_blinky bsp=@apache-mynewt-core/hw/bsp/rb-nano2
-$ newt target set rbnano2_blinky build_profile=debug
-```
-<br>
-You can run the `newt target show` command to verify the target settings:
-
-```no-highlight
-$ newt target show
-targets/rbnano2_blinky
- app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/rb-nano2
- build_profile=debug
-targets/rbnano2_boot
- app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/rb-nano2
- build_profile=optimized
-```
-<br>
-
-### Build the Target Executables
-
-Run the `newt build rbnano2_boot` command to build the bootloader:
-
-```no-highlight
-$newt build rbnano2_boot
-Building target targets/rbnano2_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
-
- ...
-
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/rbnano2_boot/app/apps/boot/boot.elf
-Target successfully built: targets/rbnano2_boot
-```
-
-<br>
-Run the `newt build rbnano2_blinky` command to build the Blinky application:
-
-```no-highlight
-$newt build rbnano2_blinky
-Building target targets/rbnano2_blinky
-Assembling repos/apache-mynewt-core/hw/bsp/rb-nano2/src/arch/cortex_m4/gcc_startup_nrf52_split.s
-Compiling repos/apache-mynewt-core/hw/drivers/uart/src/uart.c
-Compiling repos/apache-mynewt-core/hw/cmsis-core/src/cmsis_nvic.c
-Compiling repos/apache-mynewt-core/hw/bsp/rb-nano2/src/sbrk.c
-Compiling apps/blinky/src/main.c
-
- ...
-
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/rbnano2_blinky/app/apps/blinky/blinky.elf
-Target successfully built: targets/rbnano2_blinky
-
-```
-
-<br>
-
-### Sign and Create the Blinky Application Image
-
-Run the `newt create-image rbnano2_blinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
-
-```no-highlight
-$newt create-image rbnano2_blinky 1.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/rbnano2_blinky/app/apps/blinky/blinky.img
-```
-
-<br>
-
-### Connect to the Board
-
-Connect the RedBear Nano 2 USB to a USB port on your computer. You should see an orange LED light up on the board.
-
-
-### Load the Bootloader
-
-Run the `newt load rbnano2_boot` command to load the bootloader onto the board:
-
-```no-highlight
-$ newt load rbnano2_boot
-Loading bootloader
-$
-```
-<br>
-
-**Note:** On Windows platforms, if you get an `unable to find CMSIS-DAP device` error, you will need to download and install the mbed Windows serial port driver from [https://developer.mbed.org/handbook/Windows-serial-configuration](https://developer.mbed.org/handbook/Windows-serial-configuration). Follow the instructions from the site to install the driver. Here are some additional notes about the installation:
-
-1. The instructions indicate that the mbed Windows serial port driver is not required for Windows 10. If you are using Windows 10 and get the `unable to find CMSIS-DAP device` error, we recommend that you install the driver.
-2. If the driver installation fails, we recommend that you unplug the board, plug it back in, and retry the installation.
-
-Run the `newt load rbnano2_boot` command again.
-
-<br>
-####Clear the Write Protection on the Flash Memory
-The flash memory on the RedBear Nano 2 comes write protected from the factory. If you get an error loading the bootloader and you are using a brand new chip, you need to clear the write protection from the debugger and then load the bootloader again. Run the `newt debug rbnano2_blinky` command and issue the following commands at the highlighted (gdb) prompts.
-
-**Note:** The output of the debug session below is for Mac OS and Linux platforms. On Windows, openocd and gdb are started in separate Windows Command Prompt terminals, and the terminals are automatically closed when you quit gdb. In addition, the output of openocd is logged to the openocd.log file in your project's base directory instead of the terminal.
-
-<br>
-
-```hl_lines="8 9 11 14"
-$newt debug rbnano2_blinky
-[~/dev/myproj/repos/apache-mynewt-core/hw/bsp/rb-nano2/rb-nano2_debug.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/rb-nano2 ~/dev/myproj/bin/targets/rbnano2_blinky/app/apps/blinky/blinky]
-Open On-Chip Debugger 0.10.0-dev-snapshot (2017-03-28-11:24)
-Licensed under GNU GPL v2
-
- ...
-
-(gdb) set {unsigned long}0x4001e504=2
-(gdb) x/1wx 0x4001e504
-0x4001e504:0x00000002
-(gdb) set {unsigned long}0x4001e50c=1
-Info : SWD DPIDR 0x2ba01477
-Error: Failed to read memory at 0x00009ef4
-(gdb) x/32wx 0x00
-0x0:0xffffffff0xffffffff0xffffffff0xffffffff
-0x10:0xffffffff0xffffffff0xffffffff0xffffffff
-0x20:0xffffffff0xffffffff0xffffffff0xffffffff
-0x30:0xffffffff0xffffffff0xffffffff0xffffffff
-0x40:0xffffffff0xffffffff0xffffffff0xffffffff
-0x50:0xffffffff0xffffffff0xffffffff0xffffffff
-0x60:0xffffffff0xffffffff0xffffffff0xffffffff
-0x70:0xffffffff0xffffffff0xffffffff0xffffffff
-(gdb)
-```
-<br>
-### Load the Blinky Application Image
-<br>
-Run the `newt load rbnano2_blinky` command to load the Blinky application image onto the board:
-```no-highlight
-$ newt load rbnano2_blinky
-Loading app image into slot 1
-```
-
-You should see a blue LED on the board blink!
-
-Note: If the LED does not blink, try resetting your board.
diff --git a/docs/os/tutorials/repo/add_repos.md b/docs/os/tutorials/repo/add_repos.md
deleted file mode 100644
index 3027ff7..0000000
--- a/docs/os/tutorials/repo/add_repos.md
+++ /dev/null
@@ -1,317 +0,0 @@
-## Adding Repositories to your Project
-
-### What is a Repository
-
-A repository is a version-ed Mynewt project, which is a collection of Mynewt packages organized in a specific way for redistribution.
-
-What differentiates a repository from a Mynewt project is the presence of a
-`repository.yml` file describing the repository. This will be described
-below. For a basic understanding of repositories you may read the [Newt Tool Manual](../../../newt/newt_intro.md) and [How to create repos](create_repo.md).
-
-**Note:** For the remainder of this document we'll use the term repo as shorthand for a Mynewt repository.
-
-Repos are useful because they are an organized way for the community to share Mynewt packages and projects. In fact, the Mynewt-core is distributed as a repo.
-
-<br>
-
-### Why does Mynewt need additional repos?
-
-Repos add functionality not included in the Mynewt core. New repos might be created for several reasons.
-
-* **Expertise**. Individuals or organizations may have expertise that they want
-to share in the form of repos. For example a chip vendor may
-create a repo to hold the Mynewt support for their chips.
-* **Non-Core component**. Some components, although very useful to Mynewt users
-are not core to all Mynewt users. These are likely candidates to be held in
-different repos.
-* **Software licensing**. Some software have licenses that make them incompatible
-with the ASF (Apache Software Foundation) license policies. These may be
-valuable components to some Mynewt users, but cannot be contained in the `apache-Mynewt-core`.
-
-<br>
-
-### What Repos are in my Project
-
-The list of repos used by your project are contained within the
-`project.yml` file. An example can be seen by creating a new project:
-
-```no-highlight
-$ mkdir ~/dev
-$ cd ~/dev
-$ newt new myproj
-$ cd myproj
-```
-
-<br>
-
-View the `project.yml` section and you will see a line describing the repos:
-
-```no-highlight
-project.repositories:
- - apache-Mynewt-core
-```
-
-<br>
-
-By default, this newly created project uses a single repo called
-`apache-Mynewt-core`.
-
-If you wish to add additional repos, you would add
-additional lines to the `project.repositories` variable like this.
-
-``` hl_lines="3"
-project.repositories:
- - apache-Mynewt-core
- - another_repo_named_x
-```
-
-<br>
-
-### Repo Descriptors
-
-In addition to the repo name, the `project.yml` file must also contain
-a repo descriptor for each repository you include that gives `newt`
-information on obtaining the repo.
-
-In the same `myproj` above you will see the following repo descriptor.
-
-```no-highlight
-repository.apache-Mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: mynewt-core
-```
-
-A repo descriptor starts with `repository.<name>.`. In this example, the
-descriptor specifies the information for the `apache-Mynewt-core`.
-
-<br>
-
-The fields within the descriptor have the following definitions:
-
-* **type** -- The type of code storage the repo uses. The current version
-of `newt` only supports github. Future versions may support generic git or other
-code storage mechanisms.
-
-* **vers** -- The version of the repo to use for your project. A source
-code repository contains many versions of the source. This field is used to
-specify the one to use for this project. See the section on versions below
-for a detailed description of the format of this field.
-
-* **user** -- The username for the repo. On github, this is the name
-after `github.com` in the repo path. Consider the repository
-`https://github.com/apache/mynewt-core`. It has username `apache`.
-
-* **repo** -- The name of the repo. On github, this is the name after
-the username described above. Consider the repository
-`https://github.com/apache/mynewt-core`. It has path
-`mynewt-core`. This is a path to the source control
-and should not be confused with the name of the repo that you used in the
-`repository.<name>` declaration above. That name is contained elsewhere
-within the repo. See Below.
-
-<br>
-
-### Adding Existing Repos to my Project
-
-To add a new repo to your project, you have to complete two steps.
-
-* Edit the `project.yml` file and add a new repo descriptor. The previous
-section includes information on the field required in your repo descriptor.
-
-* Edit the `project.yml` file and add a new line to the `project.repositories`
-variable with the name of the repo you are adding.
-
-An example of a `project.yml` file with two repositories is shown below:
-
-```no-highlight
-project.name: "my_project"
-
-project.repositories:
- - apache-Mynewt-core
- - Mynewt_arduino_zero
-
-# Use github's distribution mechanism for core ASF libraries.
-# This provides mirroring automatically for us.
-#
-repository.apache-Mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: mynewt-core
-
-# a special repo to hold hardware specific stuff for arduino zero
-repository.Mynewt_arduino_zero:
- type: github
- vers: 1-latest
- user: runtimeco
- repo: Mynewt_arduino_zero
-```
-
-<br>
-
-### What Version of the Repo to use
-
-Mynewt repos are version-ed artifacts. They are stored in source control
-systems like github. The repo descriptor in your `project.yml` file must
-specify the version of the repo you will accept into your project.
-
-For now, we are at the beginnings of Mynewt. For testing and evaluation
-please use `1-latest` in the `vers` field in your repo descriptor.
-
-```
- vers:1-latest
-```
-
-See [Create a Repo](create_repo) for a description of the versioning system and all the possible ways to specify a version to use.
-
-<br>
-
-### Identifying a Repo
-
-A repo contains Mynewt packages organized in a specific way and stored in one of the supported code storage methods described above. In other words, it is a Mynewt project with an additional file `repository.yml` which describes the repo for use by `newt` (and humans browsing them). It contains a mapping of version numbers to the actual github branches containing the source code.
-
-Note that the `repository.yml` file lives only in the master branch of the git
-repository. `Newt` will always fetch this file from the master branch and then
-use that to determine the actual branch required depending on the version
-specified in your `project.yml` file. Special care should be taken to ensure that this file exists only in the master branch.
-
-Here is the `repository.yml` file from the apache-Mynewt-core:
-
-```no-highlight
-repo.name: apache-mynewt-core
-repo.versions:
- "0.0.0": "master"
- "0.0.1": "master"
- "0.7.9": "mynewt_0_8_0_b2_tag"
- "0.8.0": "mynewt_0_8_0_tag"
- "0.9.0": "mynewt_0_9_0_tag"
- "0.9.9": "mynewt_1_0_0_b1_tag"
- "0.9.99": "mynewt_1_0_0_b2_tag"
- "0.9.999": "mynewt_1_0_0_rc1_tag"
- "1.0.0": "mynewt_1_0_0_tag"
-
- "0-latest": "1.0.0" # 1.0.0
- "0-dev": "0.0.0" # master
-
- "0.8-latest": "0.8.0"
- "0.9-latest": "0.9.0"
- "1.0-latest": "1.0.0" # 1.0.0
-```
-
-<br>
-
-It contains the following:
-
-* **repo.name** The external name that is used to include the library in
-your `project.yml` file. This is the name you in include in the `project.repositories` variable when adding this repository to your project.
-* **repo.versions** A description of what versions to give the user depending
-on the settings in their `project.yml` file.
-
-<br>
-
-### Repo Version
-
-The repo version number resolves to an actual git branch depending on the mapping specified in `repository.yml` for that repo. The version field argument in your `project.yml` file supports multiple formats for flexibility:
-
-```no-highlight
-<major_num>.<minor_num>.<revision_num>
-```
-
-or
-
-```no-highlight
-<major_num>.<minor_num>-<stability string>
-```
-
-or
-
-```no-highlight
-<major_num>-<stability string>
-```
-
-<br>
-
-The stability string can be one of 3 pre-defined stability values.
-
-1. stable -- A stable release version of the repository
-2. dev -- A development version from the repository
-3. latest -- The latest from the repository
-
-In your `project.yml` file you can specify different combinations of
-the version number and stability value. For example:
-
-* `1-latest` -- The latest version with major number 1
-* `1.2-stable` -- The latest stable version with major and minor number 1.2
-* `1.2-dev` -- The development version from 1.2
-* `1.1.1` -- a specific version 1.1.1
-
-You cannot specify a stability string with a fully numbered version, e.g.
-
-```no-highlight
-1.2.8-stable
-```
-
-<br>
-
-### Repo Versions Available
-
-A `repository.yml` file contains information to match a version request
-into a git branch to fetch for your project.
-
-It's up to the repository maintainer to map these to branches of the
-repository. For example, let's say in a fictitious repository the following are
-defined.
-
-```no-highlight
-repo.versions:
- "0.8.0": "xxx_branch_0_8_0"
- "1.0.0": "xxx_branch_1_0_0"
- "1.0.2": "xxx_branch_1_0_2"
- "1.1.1": "xxx_branch_1_1_0"
- "1.1.2": "xxx_branch_1_1_2"
- "1.2.0": "xxx_branch_1_2_0"
- "1.2.1": "xxx_branch_1_2_1"
- "1.2-dev": "1.2.1"
- "1-dev": "1.2-dev"
- "1.2-stable": "1.2.0"
- "0-latest": "0.8.0"
- "1-latest": "1-dev"
- ....
-```
-
-When the `project.yml` file asks for `1.2-stable` it is resolved to version
-`1.2.0` (perhaps `1.2.1` is not stable yet), which in turn resolves to a specific
-branch `xxx_branch_1_2_0`. This is the branch that `newt` fetches into
-your project.
-
-**Note:** Make sure a repo version exists in the `repository.yml` file of a repo you wish to add. Otherwise Newt will not be able to resolve the version and will fail to fetch the repo into your project.
-
-<br>
-
-### How to find out what Repos are available for Mynewt components
-
-Currently, there is no `newt` command to locate/search Mynewt package
-repositories. However, since the `newt` tool supports only github,
-searching github by keyword is a satisfactory option until a search
-tool is created.
-
-When searching github, recall that a Mynewt repository must
-have a `repository.yml` file in its root directory. If you don't see
-that file, it's not a Mynewt repository and can't be included in your
-project via the newt tool.
-
-Once you find a repository, the github URL and `repository.yml` file
-should give you all the information to add it to your `project.yml` file.
-
-<br>
-
-
-
-
-
-
-
-
-
diff --git a/docs/os/tutorials/repo/create_repo.md b/docs/os/tutorials/repo/create_repo.md
deleted file mode 100644
index ccdc9ac..0000000
--- a/docs/os/tutorials/repo/create_repo.md
+++ /dev/null
@@ -1,173 +0,0 @@
-## Create a Repo out of a Project
-
-In order to create a repository out of a project, all you need to do is create a `repository.yml` file, and check it into the master branch of your project.
-
-**NOTE:** Currently only github source control service is supported by our package management system, but support for plain git will be added soon.
-
-The repository.yml defines all versions of the repository and the corresponding source control tags that these versions correspond to. As an example, if the repository.yml file has the following content, it means there is one version of the apache-mynewt-core operating system available, which is `0.0.0` (implying we haven't released yet!). Such a version number corresponds to the "develop" branch in this repository. `0-latest` would also resolved to this same `0.0.0` version. The next section explains the versioning system a bit more.
-
-```
-$ more repository.yml
-repo.name: apache-mynewt-core
-repo.versions:
- "0.0.0": "develop"
- "0-latest": "0.0.0"
-```
-
-<br>
-
-### Where should the repository.yml file be?
-
-The `repository.yml` file lives only in the master branch of the git
-repository. `Newt` will always fetch this file from the master branch and then
-use that to resolve the actual branch required depending on the version
-specified in the project. **Special care should be taken to ensure that this
-file exists only in the master branch.**
-
-Here is the `repository.yml` file from a certain snapshot of apache-Mynewt-core:
-
-```
-repo.name: apache-mynewt-core
-repo.versions:
- "0.7.9": "Mynewt_0_8_0_b2_tag"
- "0-latest": "0.7.9"
- "0.8-latest": "0.7.9"
-```
-
-<br>
-
-It contains the following:
-
-* **repo.name** The external name that is used to include the library in
-your `project.yml` file. This is the name you include in the `project.repositories`
-variable when adding this repository to your project.
-* **repo.versions** A description of what versions to give the user depending
-on the settings in their `project.yml` file. See below for a thorough description
-on versioning. Its a flexible mapping between version numbers and git branches.
-
-<br>
-
-### Repo Version Specification
-
-The version field argument for a repo has the following format:
-
-```no-highlight
-<major_num>.<minor_num>.<revision_num>
-```
-
-or
-
-```no-highlight
-<major_num>.<minor_num>-<stability string>
-```
-
-or
-
-```no-highlight
-<major_num>-<stability string>
-```
-
-<br>
-
-The stability string can be one of 3 pre-defined stability values.
-
-1. stable -- A stable release version of the repository
-2. dev -- A development version from the repository
-3. latest -- The latest from the repository
-
-In your `project.yml` file you can specify different combinations of
-the version number and stability value. For example:
-
-* `1-latest` -- The latest version with major number 1
-* `1.2-stable` -- The latest stable version with major and minor number 1.2
-* `1.2-dev` -- The development version from 1.2
-* `1.1.1` -- a specific version 1.1.1
-
-You **cannot** specify a stability string with a fully numbered version, e.g.
-
-```no-highlight
-1.2.8-stable
-```
-
-<br>
-
-### Repo Version Resolution
-
-A `repository.yml` file contains information to match this version request
-into a git branch to fetch for your project.
-
-It's up to you as the repository maintainer to map these to actual github branches of the repository. For example, let's say in a fictitious repository the following are defined.
-
-```no-highlight
-repo.versions:
- "0.8.0": "xxx_branch_0_8_0"
- "1.0.0": "xxx_branch_1_0_0"
- "1.0.2": "xxx_branch_1_0_2"
- "1.1.1": "xxx_branch_1_1_0"
- "1.1.2": "xxx_branch_1_1_2"
- "1.2.0": "xxx_branch_1_2_0"
- "1.2.1": "xxx_branch_1_2_1"
- "1.2-dev": "1.2.1"
- "1-dev": "1.2-dev"
- "1.2-stable": "1.2.0"
- "0-latest": "0.8.0"
- "1-latest": "1-dev"
- ....
-```
-
-When the `project.yml` file asks for `1.2-stable` it will be resolved to version
-`1.2.0` which in turn will resolve to a specific branch `xxx_branch_1_2_0`. This is the branch that `newt` will fetch into the project with that `project.yml` file.
-
-<br>
-
-### Dependencies on other repos
-
-Repositories can also have dependencies on other repositories. These
-dependencies should be listed out on a per-tag basis. So, for example,
-if apache-mynewt-core were to depend on sterlys-little-repo, you might
-have the following directives in the repository.yml:
-
-```
-develop.repositories:
- sterlys-little-repo:
- type: github
- vers: 0.8-latest
- user: sterlinghughes
- repo: sterlys-little-repo
-```
-
-<br>
-
-This would tell Newt that for anything that resolves to the develop
-branch, this repository requires the sterlys-little-repo repository.
-
-Dependencies are resolved circularly by the newt tool, and every dependent repository is placed as a sibling in the repos directory. Currently, if two repositories have the same name, they will conflict and bad things will happen.
-
-When a repository is installed to the repos/ directory, the current
-version of that repository is written to the "project.state" file. The
-project state file contains the currently installed version of any given
-repository. This way, the current set of repositories can be recreated
-from the project.state file reliably, whereas the project.yml file can
-have higher level directives (i.e. include 0.8-stable.)
-
-
-### Resolving dependencies
-
-At the moment, all dependencies must match, otherwise newt will provide
-an error. As an example, if you have a set of dependencies such that:
-
-```
-apache-mynewt-core depends on sterlys-little-repo 0.6-stable
-apache-mynewt-core depends on sterlys-big-repo 0.5.1
-sterlys-big-repo-0.5.1 depends on sterlys-little-repo 0.6.2
-```
-
-<br>
-
-where 0.6-stable is 0.6.3, the newt tool will try and resolve the dependency to
-sterlys-little-repo. It will notice that there are two conflicting
-versions of the same repository, and not perform installation.
-
-In the future Newt will be smarter about loading in all dependencies,
-and then looking to satisfy those dependencies to the best match of all
-potential options.
diff --git a/docs/os/tutorials/repo/private_repo.md b/docs/os/tutorials/repo/private_repo.md
deleted file mode 100644
index 0e64b3b..0000000
--- a/docs/os/tutorials/repo/private_repo.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## Accessing a private repository
-
-To access a private repository, newt needs to be configured with one of the following:
-
-* Access token for the repository
-* Basic auth login and password for the user
-
-
-**NOTE:** To create a github access token, see [
-https://help.github.com/articles/creating-an-access-token-for-command-line-use/](https://help.github.com/articles/creating-an-access-token-for-command-line-use/)
-
-There are two ways to specify this information, as shown below. In
-these examples, both a token and a login/password are specified, but you
-only need to specify one of these.
-
-1\. project.yml (probably world-readable and therefore not secure):
-
-```hl_lines="6 7 8"
- repository.my-private-repo:
- type: github
- vers: 0-dev
- user: owner-of-repo
- repo: repo-name
- token: '8ab6433f8971b05c2a9c3341533e8ddb754e404e'
- login: githublogin
- password: githubpassword
-```
-
-2\. $HOME/.newt/repos.yml
-
-```hl_lines="2 3 4"
- repository.my-private-repo:
- token: '8ab6433f8971b05c2a9c3341533e8ddb754e404e'
- login: githublogin
- password: githubpassword
-```
-
-If both a token and a login+password are specified, newt uses the token.
-If both the project.yml file and the private repos.yml file specify
-security credentials, newt uses the project.yml settings.
-
-**NOTE:** When newt downloads the actual repo content, as
-opposed to just the repository.yml file, it does not use the same
-mechanism. Instead, it invokes the git command line tool. This is an
-annoyance because the user cannot use the same access token for all git
-operations. This is something that will be fixed in the future.
-
diff --git a/docs/os/tutorials/repo/upgrade_repo.md b/docs/os/tutorials/repo/upgrade_repo.md
deleted file mode 100644
index c44fab8..0000000
--- a/docs/os/tutorials/repo/upgrade_repo.md
+++ /dev/null
@@ -1,14 +0,0 @@
-## Upgrade a repo
-
-In order to upgrade a previously installed repository, the "newt upgrade" command should be issued:
-
-```
-$ newt upgrade
-```
-
-<br>
-
-Newt upgrade will look at the current desired version in `project.yml`,
-and compare it to the version in `project.state`. If these two differ, it
-will upgrade the dependency. Upgrade works not just for the dependency
-in `project.yml`, but for all the sub-dependencies that they might have.
diff --git a/docs/os/tutorials/segger_rtt.md b/docs/os/tutorials/segger_rtt.md
deleted file mode 100644
index 2b16c23..0000000
--- a/docs/os/tutorials/segger_rtt.md
+++ /dev/null
@@ -1,87 +0,0 @@
-## SEGGER RTT Console
-
-<br>
-
-### Objective
-
-Sometimes you dont have UART on your board, or you want to use it for something else while still having newt logs/shell capability. With [SEGGER's RTT](https://www.segger.com/jlink-rtt.html) capability you can swap UART for RTT, which is a very high-speed memory-mapped I/O.
-
-<br>
-
-### Hardware needed
-
-You'll need a SEGGER J-Link programmer in order to use this advanced functionality. You might have an external J-Link programmer you're already using, or maybe your board has a dedicated J-Link onboard as some development kits do. Another possibilty is J-Link OB firmware available for some devices like the micro:bit.
-
-### Setup the target
-
-We'll assume you have an existing project with some kind of console/shell like [Blinky with console and shell](blinky_console.md) that we're switching over to RTT from UART.
-
-**Note:** We have tested RTT with J-Link version V6.14h. We recommend that you upgrade your J-Link if you have an earlier version of J-Link installed. Earlier versions of J-Link use the BUFFER_SIZE_DOWN value defined in hw/drivers/rtt/include/rtt/SEGGER_RTT_Conf.h for the maximum number of input characters. If an input line exceeds the BUFFER_SIZE_DOWN number of characters, RTT ignores the extra characters. The default value is 16 characters. For example, this limit causes shell commands with more than 16 characters of input to fail. You may set the Mynewt `RTT_BUFFER_SIZE_DOWN` syscfg setting in your target to increase this value if you do not upgrade your J-Link version.
-
-We can disable uart and enable rtt with the newt target command:
-
-```
-newt target amend nrf52_blinky syscfg=CONSOLE_UART=0
-newt target amend nrf52_blinky syscfg=CONSOLE_RTT=1
-```
-
-<br>
-
-### Run the target executables
-Now 'run' the newt target as you'll need an active debugger process to attach to:
-
-```
-$ newt run nrf52_blinky 0
-App image succesfully generated: ~/Downloads/myapp1/bin/targets/nrf52_blinky/app/apps/blinky/blinky.img
-Loading app image into slot 1
-[~Downloads/myapp1/repos/apache-mynewt-core/hw/bsp/nrf52-thingy/nrf52-thingy_debug.sh ~/Downloads/myapp1/repos/apache-mynewt-core/hw/bsp/nrf52-thingy ~/Downloads/myapp1/bin/targets/nrf52_blinky/app/apps/blinky/blinky]
-Debugging ~/Downloads/myapp1/bin/targets/nrf52_blinky/app/apps/blinky/blinky.elf
-GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
-Copyright (C) 2014 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law. Type "show copying"
-and "show warranty" for details.
-This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
-Type "show configuration" for configuration details.
-For bug reporting instructions, please see:
-<http://www.gnu.org/software/gdb/bugs/>.
-Find the GDB manual and other documentation resources online at:
-<http://www.gnu.org/software/gdb/documentation/>.
-For help, type "help".
-Type "apropos word" to search for commands related to "word"...
-Reading symbols from ~/Downloads/myapp1/bin/targets/nrf52_blinky/app/apps/blinky/blinky.elf...done.
-0x000000d8 in ?? ()
-Resetting target
-0x000000dc in ?? ()
-(gdb)
-```
-
-<br>
-
-### Connect to console
-
-In a seperate terminal window ```telnet localhost 19021``` and when you continue your gdb session you should see your output. If you're not familiar with telnet, when you're ready to exit you may by using the hotkey ctrl+] then typing quit
-
-```
-$ telnet localhost 19021
-Trying ::1...
-telnet: connect to address ::1: Connection refused
-Trying fe80::1...
-telnet: connect to address fe80::1: Connection refused
-Trying 127.0.0.1...
-Connected to localhost.
-Escape character is '^]'.
-SEGGER J-Link V6.14e - Real time terminal output
-SEGGER J-Link EDU V8.0, SN=268006294
-Process: JLinkGDBServer
-```
-
-Then you can interact with the device:
-```
-stat
-stat
-000262 Must specify a statistic name to dump, possible names are:
-000262 stat
-000262 compat>
-```
diff --git a/docs/os/tutorials/segger_sysview.md b/docs/os/tutorials/segger_sysview.md
deleted file mode 100644
index 1bb1855..0000000
--- a/docs/os/tutorials/segger_sysview.md
+++ /dev/null
@@ -1,78 +0,0 @@
-## SEGGER SystemView
-
-<br>
-### Objective
-
-With [SEGGER's SystemView](https://www.segger.com/systemview.html) you can "record data from the target system while it is running. The recorded data is analyzed and the system behavior is visualized in different views."
-
-<br>
-
-### Hardware needed
-
-You'll need a SEGGER J-Link programmer in order to use this advanced functionality. You might have an external J-Link programmer you're already using, or maybe your board has a dedicated J-Link onboard as some development kits do. Another possibilty is J-Link OB firmware available for some devices like the micro:bit.
-
-### Software needed
-
-* Download [SEGGER's SystemView app](https://www.segger.com/downloads/free-utilities/).
-* Copy the description file from sys/sysview/SYSVIEW_Mynewt.txt to the /Description/ directory of SystemView
-
-### Setup the target
-
-We'll assume you have an existing example we're enabling SystemView on, in this case [blinky on nrf52](nRF52.md). We can do so with the newt target amend command:
-```
-newt target amend blink_nordic syscfg=OS_SYSVIEW=1
-```
-
-<br>
-
-### Run the target executables
-Now 'run' the newt target as you'll need an active debugger process to attach to:
-
-```
-$ newt run blink_nordic 0
-App image succesfully generated: ~/Downloads/myproj/bin/targets/blink_nordic/app/apps/bleprph/bleprph.img
-Loading app image into slot 1
-[~/Downloads/myproj/repos/apache-mynewt-core/hw/bsp/nrf52-thingy/nrf52-thingy_debug.sh ~/Downloads/myproj/repos/apache-mynewt-core/hw/bsp/nrf52-thingy ~/Downloads/myproj/bin/targets/blink_nordic/app/apps/bleprph/bleprph]
-Debugging ~/Downloads/myproj/bin/targets/blink_nordic/app/apps/bleprph/bleprph.elf
-GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
-Copyright (C) 2014 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law. Type "show copying"
-and "show warranty" for details.
-This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
-Type "show configuration" for configuration details.
-For bug reporting instructions, please see:
-<http://www.gnu.org/software/gdb/bugs/>.
-Find the GDB manual and other documentation resources online at:
-<http://www.gnu.org/software/gdb/documentation/>.
-For help, type "help".
-Type "apropos word" to search for commands related to "word"...
-Reading symbols from ~/Downloads/myproj/bin/targets/blink_nordic/app/apps/bleprph/bleprph.elf...done.
-0x000000d8 in ?? ()
-Resetting target
-0x000000dc in ?? ()
-```
-
-<br>
-
-### Launch the app
-<br>
-Launch the app and press **OK** in the System Information dialog box.
-
-
-
-<br>
-
-Select ** Target > Start Recording ** and press **OK** in the Configuration dialog box.
-
-
-
-<br>
-
-You should see the recording for your Mynewt application.
-
-
-
-
-
diff --git a/docs/os/tutorials/sensors/sensor_bleprph_oic.md b/docs/os/tutorials/sensors/sensor_bleprph_oic.md
deleted file mode 100644
index afcd291..0000000
--- a/docs/os/tutorials/sensors/sensor_bleprph_oic.md
+++ /dev/null
@@ -1,267 +0,0 @@
-## Adding OIC Sensor Support to the bleprph_oic Application
-This tutorial shows you how to modify and add OIC sensor support to the **bleprph_oic** application. This tutorial assumes that have you completed the [Enabling OIC Sensor Data Monitoring in the sensors_test Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055_oic.md).
-
-Like the other off-board sensor tutorials, this tutorial uses an nRF52-DK board connected to an off-board BNO055 sensor device.
-
-This tutorial shows you how to:
-
-* Modify the bleprph_oic application to add OIC sensor support.
-* Create and build the target for the new application.
-* Use the Mynewt Smart Device Controller iOS or Android app to view the sensor data from the device.
-
-### Prerequisites
-
-* Read the [Overview of OIC Support in the Sensor Framework](/os/tutorials/sensors/sensor_oic_overview.md).
-* Complete the tasks described in the [Enabling OIC Sensor Data Monitoring in the sensors_test Application](/os/tutorials/sensors/sensor_nrf52_bno055_oic.md) tutorial.
-<br>
-### Overview on How to Add OIC Sensor Support to a BLE Application
-
-The sensor framework makes it very easy to add OIC sensor support to an existing BLE application. The sensor framework exports the `sensor_oic_init()` function that an application calls to create the OIC resources for the sensors and to set up the handlers to process CoAP requests for the resources.
-
-An application uses the `oc` server API in the `net/oic` package to implement OIC server functionality. An application defines an OIC application initialization handler that sets up the OIC resources it supports. The `oc_main_init()` function, that an application calls during initialization in `main()`, calls the OIC application handler.
-
-To add OIC sensor support, we modify the bleprph_oic application to call the `sensor_oic_init()` function in the OIC application initialization handler.
-
-<br>
-### Step 1: Copying the bleprph_oic source
-
-<br>
-1. Copy the @apache-mynewt-core/apps/bleprph_oic to a new package. We name the new package **apps/bleprph_oic_sensor**. From your project base directory, run the `newt pkg copy` command:
-
-```no-highlight
-
-$ newt pkg copy @apache-mynewt-core/apps/bleprph_oic @apache-mynewt-core/apps/bleprph_oic_sensor
-Copying package @apache-mynewt-core/apps/bleprph_oic to @apache-mynewt-core/apps/bleprph_oic_sensor
-
-```
-<br>
-2. The newt tools creates the `bleprph_oic_sensor` package in the `~/dev/myproj/repos/apache-mynewt-core/apps/bleprph_oic_sensor` directory. Go to the directory to update the package `pkg.yml` and source files.
-
-```no-highlight
-
-$ cd repos/apache-mynewt-core/apps/bleprph_oic_sensor
-
-```
-<br>
-
-### Step 2: Adding Package Dependencies
-
-Add the `hw/sensor/` and the `hw/sensor/creator` packages as dependencies in the `pkg.yml` file to include the sensor framework and off-board sensor support.
-
-**Note:** The `hw/sensor` package automatically includes the `net/oic` package when the `SENSOR_OIC` setting is enabled, so you do not need to include the `net/oic` package as a dependency in this package.
-
-```hl_lines="11 12"
-
-pkg.deps:
- - kernel/os
- - net/nimble/controller
- - net/nimble/host
- - net/nimble/host/services/gap
- - net/nimble/host/services/gatt
- - net/nimble/host/store/ram
- - net/nimble/transport/ram
-
- ...
- - hw/sensor
- - hw/sensor/creator
-
-```
-
-<br>
-### Step 3: Setting Syscfg Values to Enable OIC Support
-
-Add the following setting values to `syscfg.vals` in the `syscfg.yml` file:
-
-* `SENSOR_OIC: 1`: This setting enables OIC sensor support in the `hw/sensors` package.
-* `OC_SERVER: 1` : This setting enables OIC server support in the `net/oic` package.
-* `FLOAT_USER: 1`: This setting enables floating pointing support in the encoding/tinycbor package.
-* `ADVERTISE_128BIT_UUID: 1` and `ADVERTISE_16BIT_UUID: 0`: These settings enable BLE 128 bit UUID and disables 16 bit UUID advertisement. The IoTivity library that is used to build the OIC Apps on the iOS and Android devices only sees 128 bit UUID advertisements.
-
-```hl_lines="4 5 6 7 8"
-
-syscfg.vals:
- ...
-
- SENSOR_OIC: 1
- OC_SERVER: 1
- FLOAT_USER: 1
- ADVERTISE_128BIT_UUID: 1
- ADVERTISE_16BIT_UUID: 0
-
-```
-<br>
-### Step 4: Modifying main.c
-
-The bleprph_oic application defines the `omgr_app_init()` function for the OIC application initialization handler. The function creates an OIC light resource. We modify the function to call the `sensor_oic_init()` function to create the OIC sensor resources instead of creating the OIC light resource.
-
-We make the following modifications to main.c:
-
-* Add the sensor package header file.
-* Modify the `omgr_app_init()` function to call the `sensor_oic_init()` function, and delete the code to create the OIC light resource.
-* Delete the OIC application request handler functions that process the CoAP requests for the light resource.
-
-<br>
-#### Adding the Sensor Package Header File:
-
-Add the sensor package header file `sensor/sensor.h` below `#include "bleprph.h" ` file:
-
-
-```hl_lines="3"
-
-#include "bleprph.h"
-
-#include <sensor/sensor.h>
-
-```
-
-<br>
-
-#### Modifying the omgr_app_init() Function
-
-Make the following modifications to the `omgr_app_init()` function:
-
-<br>
-1. Delete the code segment that creates the OIC device and resource. The lines to delete are highlighted below:
-
-```hl_lines="4 7 8 9 10 11 12 13 14 15 16 17 18 19"
-
-static void
-omgr_app_init(void)
-{
- oc_resource_t *res;
-
- oc_init_platform("MyNewt", NULL, NULL);
- oc_add_device("/oic/d", "oic.d.light", "MynewtLed", "1.0", "1.0", NULL,
- NULL);
-
- res = oc_new_resource("/light/1", 1, 0);
- oc_resource_bind_resource_type(res, "oic.r.light");
- oc_resource_bind_resource_interface(res, OC_IF_RW);
- oc_resource_set_default_interface(res, OC_IF_RW);
-
- oc_resource_set_discoverable(res);
- oc_resource_set_periodic_observable(res, 1);
- oc_resource_set_request_handler(res, OC_GET, app_get_light);
- oc_resource_set_request_handler(res, OC_PUT, app_set_light);
- oc_add_resource(res);
-
-}
-
-```
-<br>
-2. Add the following `oc_add_device()` function call to create an OIC resource for the sensor device:
-
-```hl_lines="7"
-
-static void
-omgr_app_init(void)
-{
-
- oc_init_platform("MyNewt", NULL, NULL);
-
- oc_add_device("/oic/d", "oic.d.sensy", "sensy", "1.0", "1.0", NULL, NULL);
-
-}
-
-```
-<br>
-3. Add the call to the `sensor_oic_init()` function to initialize the sensor framework OIC server support:
-
-```hl_lines="9"
-
-static void
-omgr_app_init(void)
-{
-
- oc_init_platform("MyNewt", NULL, NULL);
-
- oc_add_device("/oic/d", "oic.d.sensy", "sensy", "1.0", "1.0", NULL, NULL);
-
- sensor_oic_init();
-
-}
-
-```
-
-<br>
-#### Deleting the app_get_light() and app_set_light() Functions
-
-Since we modify the application to no longer create an OIC light resource, the `app_get_light()` and the `app_set_light()` handler functions that process read and write requests are not used. We need to delete the functions to avoid compilation errors. Search for the two functions and delete them.
-
-<br>
-### Step 5: Creating and Building the Application Image
-
-In this step of the tutorial we create and build an application image for the bleprph_oic_sensor application to verify that the application serves sensor data over OIC correctly.
-
-We use the same syscfg settings from the [Enabling OIC Sensor Data Monitoring in the sensors_test Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055_oic.md).
-
-<br>
-1. From your project base directory, run the `newt create target ` command to create a new target named `nrf52_bleprph_oic_bno055`:
-
-```no-highlight
-
-$ newt target create nrf52_bleprph_oic_bno055
-Target targets/nrf52_bleprph_oic_bno055 successfully created
-```
-
-<br>
-2. Run the `newt target set` command to set the app, bsp, and build_profile variables for the target.
-
-```no-highlight
-
-$ newt target set nrf52_bleprph_oic_bno055 app=@apache-mynewt-core/apps/bleprph_oic_sensor bsp=@apache-mynewt-core/hw/bsp/nrf52dk build_profile=debug
-Target targets/nrf52_bleprph_oic_bno055 successfully set target.app to @apache-mynewt-core/apps/bleprph_oic_sensor
-Target targets/nrf52_bleprph_oic_bno055 successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52dk
-Target targets/nrf52_bleprph_oic_bno055 successfully set target.build_profile to debug
-$
-
-```
-<br>
-3. Run the `newt target set` command to set `I2C_0=1`, `BNO055_OFB=1`, `BLE_MAX_CONNECTIONS=4`, `MSYS_1_BLOCK_COUNT=52`, `MSYS_1_BLOCK_SIZE=100`, and `OC_APP_RESOURCES=11`.
-
-```no-highlight
-
-$ newt target set nrf52_bleprph_oic_bno055 syscfg=BNO055_OFB=1:I2C_0=1:BLE_MAX_CONNECTIONS=4:MSYS_1_BLOCK_COUNT=52:MSYS_1_BLOCK_SIZE=100:OC_APP_RESOURCES=11
-Target targets/nrf52_bleprph_oic_bno055 successfully set target.syscfg to BNO055_OFB=1:I2C_0=1:BLE_MAX_CONNECTIONS=4:MSYS_1_BLOCK_COUNT=52:MSYS_1_BLOCK_SIZE=100:OC_APP_RESOURCES=11
-$
-
-```
-<br>
-4. Run the `newt build nrf52_bleprph_oic_bno055` and `newt create-image nrf52_bleprph_oic_bno055 1.0.0` commands to build and create the application image.
-
-<br>
-### Step 6: Connecting the Sensor and Loading the Images to the Board
-
-Perform the following steps to reboot the board with the new images:
-
-1. Connect the BNO055 sensor to the nRF52-DK board. See the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_offboard_config.md) for instructions.
-
- **Note**: You do not need the serial connection from your computer directly to the nRF52-DK board because we are not using the shell to view the sensor data.
-
-2. Run the `newt load nrf52_boot` command to load the bootloader. You should already have this target built from the [Enabling an Off-Board Sensor in an Existing Application Tutorial](os/tutorials/sensors/sensor_nrf52_bno055.md).
-3. Run the `newt load nrf52_bno055_oic_test` command to load the application image.
-4. Power the device OFF and ON to reboot.
-
-<br>
-### Step 7: Viewing Sensor Data from the Mynewt Smart Device Controller
-
-Start the Mynewt Smart Device Controller app on your iOS or Android device to view the sensor data. You should already have the app installed from the [Enabling OIC Sensor Data Monitoring in the sensors_test Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055_oic.md).
-
-The Mynewt Smart Device Controller scans for the devices when it starts up and displays the sensors it can view. The following is an example from the Android App:
-<br>
-<p>
-<p align="center">
-<img src="../../pics/smart_controller_main.png"></img>
-</p>
-<br>
-
-1. Select `Accelerometer` to see the sensor data samples:
-<br>
-<p>
-<p align="center">
-<img src="../../pics/smart_controller_accelerometer.png"></img>
-</p>
-<p>
-<br>
-<br>
-2. Move your BNO055 sensor device around to see the values for the coordinates change.
diff --git a/docs/os/tutorials/sensors/sensor_nrf52_bno055.md b/docs/os/tutorials/sensors/sensor_nrf52_bno055.md
deleted file mode 100644
index c935aa1..0000000
--- a/docs/os/tutorials/sensors/sensor_nrf52_bno055.md
+++ /dev/null
@@ -1,469 +0,0 @@
-## Enabling an Off-Board Sensor in an Existing Application
-
-This tutorial shows you how to enable an existing application to run on a device with an off-board sensor device connected to it. It allows you to quickly bring up and run a Mynewt application on a device to view sensor data from a sensor device.
-
-We use the **sensors_test** application running on an nRF52-DK board to communicate, via the I2C interface, with the [Adafruit BNO055](https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview) sensor. The sensors_test application is a sample application that demonstrates all the features of the Mynewt sensor framework. The application includes the sensor framework `sensor` shell command that allows you to view the sensors and sensor data managed by the sensor framework, and the `bno055` shell command that allows you to control and query the BNO055 device and to view the sensor data.
-
-<br>
-
-This tutorial shows you how to:
-
-* Create and build the application and bootloader targets.
-* Connect a BNO055 sensor device to an nRF52-DK board.
-* Run `sensor` and `bno055` shell commands to view the sensor data and control the bno055 sensor device.
-
-### Prerequisites
-
-* Meet the prerequisites listed in [Sensor Tutorials](/os/tutorials/sensors/sensors.md).
-* Have a Nordic nRF52-DK board.
-* Have an [Adafruit BNO055](https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/overview) sensor.
-* Have a [serial port setup](/os/get_started/serial_access.md).
-* Install the [Segger JLINK software and documentation pack](https://www.segger.com/jlink-software.html).
-
-
-### Description of the Packages Needed for the Sample Application
-
-The sensors_test application includes all the packages, and sets the syscfg settings to values, that are required to enable the full set of sensor framework features. This tutorial uses a subset of the sensors_test application functionality because the objective of the tutorial is to show you how to quickly bring up the sensors_test application and use the `sensor` and `bno055` shell commands to view the sensor data from the BNO055 sensor. The instructions in this tutorial show the syscfg settings that must be enabled in the sensors_test application to demonstrate the examples shown. The instructions do not explicity exclude the packages or change the syscfg setting values to disable the functionality that is not used in the sensors_test application.
-
-For your reference, we describe the packages and the setting values that enable the application functionality that this tutorial demonstrates:
-
-* **hw/sensor**: The sensor framework package. This package defines the `SENSOR_CLI` setting that specifies whether the `sensor` shell command is enabled. This setting is enabled by default.
-
-* **hw/sensor/creator**: The sensor creator package. This package supports off-board sensor devices. This package creates the os devices in the kernel for the sensors and configures the sensor devices with default values. It defines a syscfg setting for each sensor device and uses the naming convention `<SENSORNAME>_OFB`. For example, the syscfg setting for the BNO055 sensor is `BNO055_OFB`. The `<SENSORNAME>_OFB` setting specifies whether the sensor named SENSORNAME is enabled. The setting is disabled by default. This package includes the sensor device driver package `hw/drivers/sensors/<sensorname>` and creates and configures a sensor named SENSORNAME when the `SENSORNAME_OFB` setting is enabled by the application.
-* **hw/drivers/sensors/bno055**: The driver package for the BNO055 sensor. The creator package adds this package as a package dependency when the `BNO055_OFB` setting is enabled. The driver package defines the `BNO055_CLI` setting that specfies whether the `bno055` shell command is enabled. This setting is disabled by default and is enabled by the application. The package also exports the `bno055_shell_init()` function that an application calls to initialize the driver shell support.
-
- **Note:** All sensor driver packages that support a sensor shell command define a syscfg setting to specify whether the shell command is enabled. They also export a shell initialization function that an application must call. The naming convention is `<SENSORNAME>_CLI` for the syscfg setting and `<sensorname>_shell_init()` for the initialization function.
-
-
-* **sys/shell** and **sys/console/full**: The shell and console packages for shell support over the console. The `SHELL_TASK` setting needs to be set to enable the shell support in the package. The sensors_test application enables this setting by default.
-<br>
-
-<br>
-### Step 1: Creating the Application Target
-In this step, you create a target for the sensors_test application that enables the BNO055 off-board sensor.
-
-To add the BNO055 sensor support, you create the application target with the following syscfg settings enabled:
-
-* `I2C_0`: Enables the I2C interface 0 in the nRF52 BSP HAL setting.
-* `BNO055_OFB`: Enables support for the BNO055 sensor in the sensor creator package (`hw/sensor/creator`).
-When this setting is enabled, the creator package performs the following:
-
- * Includes the BNO055 driver package (`hw/drivers/sensors/bno055`) as a package dependency.
- * Creates an os device for the sensor in the Mynewt kernel.
- * Configures the sensor device with default values.
-* `BNO055_CLI`: Enables the `bno055` shell command in the bno055 device driver package. The sensors_test application also uses this setting to conditionally include the call to the `bno055_shell_init()` function to initialize the shell support in the driver.
-
-
-**Note:** This tutorial uses the `sensor` and the `bno055` shell commands. The `SENSOR_CLI` setting, that specifies whether the `sensor` shell command is enabled, is enabled by default.
-
-<br>
-1. Run the `newt target create` command, from your project base directory, to create the target. We name the target `nrf52_bno055_test`:
-<br>
-```no-highlight
-
-$ newt target create nrf52_bno055_test
-Target targets/nrf52_bno055_test successfully created
-$
-
-```
-
-<br>
-2. Run the `newt target set` command to set the app, bsp, and build_profile variables for the target:
-<br>
-```no-highlight
-
-$ newt target set nrf52_bno055_test app=@apache-mynewt-core/apps/sensors_test bsp=@apache-mynewt-core/hw/bsp/nrf52dk build_profile=debug
-Target targets/nrf52_bno055_test successfully set target.app to @apache-mynewt-core/apps/sensors_test
-Target targets/nrf52_bno055_test successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52dk
-Target targets/nrf52_bno055_test successfully set target.build_profile to debug
-
-$
-```
-
-<br>
-3. Run the `newt target set` command to enable the `I2C_0`, `BNO055_OFB`, and `BBNO055_CLI` syscfg settings:
-
-```no-highlight
-
-$ newt target set nrf52_bno055_test syscfg=BNO055_OFB=1:I2C_0=1:BNO055_CLI=1
-Target targets/nrf52_bno055_test successfully set target.syscfg to BNO055_OFB=1:I2C_0=1:BNO055_CLI=1
-$
-
-```
-
-<br>
-### Step 2: <a name="create_targets"></a>Creating the Bootloader Target
-<br>
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `nrf52_boot`:
-<br>
-```no-highlight
-
-$ newt target create nrf52_boot
-Target targets/nrf52_boot successfully created
-$ newt target set nrf52_boot app=@apache-mynewt-core/apps/boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk build_profile=optimized
-Target targets/nrf52_boot successfully set target.app to @apache-mynewt-core/apps/boot
-Target targets/nrf52_boot successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52dk
-Target targets/nrf52_boot successfully set target.build_profile to optimized
-$
-
-```
-
-<br>
-### Step 3: Building the Bootloader and Application Image
-<br>
-1. Run the `newt build nrf52_boot` command to build the bootloader:
-
-```no-highlight
-$ newt build nrf52_boot
-Building target targets/nrf52_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
-
- ...
-
-Archiving sys_mfg.a
-Archiving sys_sysinit.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/nrf52_boot/app/apps/boot/boot.elf
-Target successfully built: targets/nrf52_boot
-```
-
-<br>
-2. Run the `newt build nrf52_bno055_test` command to build the sensors_test application:
-
-```no-highlight
-$ newt build nrf52_bno055_test
-Building target targets/nrf52_bno055_test
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
-Compiling repos/apache-mynewt-core/apps/sensors_test/src/misc.c
-Compiling repos/apache-mynewt-core/apps/sensors_test/src/gatt_svr.c
-Compiling repos/apache-mynewt-core/apps/sensors_test/src/main.c
-
- ...
-
-Compiling repos/apache-mynewt-core/hw/drivers/sensors/bno055/src/bno055.c
-Compiling repos/apache-mynewt-core/hw/drivers/sensors/bno055/src/bno055_shell.c
-
- ...
-
-Compiling repos/apache-mynewt-core/hw/sensor/src/sensor.c
-Compiling repos/apache-mynewt-core/hw/sensor/src/sensor_oic.c
-Compiling repos/apache-mynewt-core/hw/sensor/src/sensor_shell.c
-Compiling repos/apache-mynewt-core/hw/sensor/creator/src/sensor_creator.c
-
- ...
-
-Archiving util_mem.a
-Archiving util_parse.a
-Linking ~/dev/myproj/bin/targets/nrf52_bno055_test/app/apps/sensors_test/sensors_test.elf
-Target successfully built: targets/nrf52_bno055_test
-
-```
-<br>
-
-### Step 4: Creating an Application Image
-
-Run the `newt create-image` command to create an image file. You may assign an arbitrary version (e.g. 1.0.0) to the image.
-<br>
-```no-highlight
-
-$ newt create-image nrf52_bno055_test 1.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/nrf52_bno055_test/app/apps/sensors_test/sensors_test.img
-
-```
-<br>
-
-
-### Step 5: Connecting the BNO055 Sensor to the nRF52-DK Board
-Connect the pins from the BNO055 sensor to the nRF52-DK board as specified in the following table:
-
-|Lines| BNO055 Pin | nRF52-DK Pin|
-|-----|-------|---------|
-|Power| Vin | 5V |
-|Clock| SCL | P0.27|
-|Data | SDA | P0.26|
-|Ground| GND | GND|
-
-
-
-
-
-
-<br>
-### Step 6: Connecting the nRF52-DK Board to your Computer
-<br>
-1. Set up two connections between your computer and the nRF52-DK board:
-
-* A serial connection to communicate with the sensors_test application and view the sensor data and hardware information via the Mynewt shell.
-
- You can reference the [Serial Port Setup](../get_started/serial_access.md) tutorial for more information on setting up a serial communication.
-
-* A connection from your computer to the micro-USB port on the nRF52-DK board to power the board and to load the bootloader and application image.
-
-<br>
-2. Turn the power on the board to ON. You should see the green LED light up on the board.
-
-<br>
-### Step 7: Loading the Bootloader and the Application Image
-<br>
-1. Run the `newt load nrf52_boot` command to load the bootloader onto the board:
-<br>
-```no-highlight
-
-$ newt load nrf52_boot
-Loading bootloader
-$
-
-```
-<br>
-2. Run the `newt load nrf52_bno055_test` command to load the application image on to the board:
-<br>
-```no-highlight
-
-$ newt load nrf52_bno055_test
-Loading app image into slot 1
-$
-```
-<br>
-3. Power the nRF52-DK board OFF and ON.
-<br>
-### Step 8: Using a Terminal Emulator to Connect to the Application Console
-
-Start up a terminal emulator to connect the sensors_test application console. You can use one of the terminal emulators listed below or one of your choice:
-
-* On Mac OS and Linux platforms, you can run ```minicom -D /dev/tty.usbserial-<port> -b 115200``` to connect to the console of your app. Note that on Linux, the format of the port name is `/dev/ttyUSB<N>`, where N is a number.
-
-* On Windows, you can use a terminal application such as PuTTY to connect to the device.
-
- If you located your port from a MinGW terminal, the port name format is `/dev/ttyS<N>`, where `N` is a number. You must map the port name to a Windows COM port: `/dev/ttyS<N>` maps to `COM<N+1>`. For example, `/dev/ttyS2` maps to `COM3`.
-
- You can also use the Windows Device Manager to locate the COM port.
-
-<br>
-We use minicom for this tutorial. After minicom connects, enter <return> to ensure the shell is running. You should see the `compat>` prompt:
-
-```no-highlight
-
-Welcome to minicom 2.7.1
-
-OPTIONS:
-Compiled on May 17 2017, 15:29:14.
-Port /dev/tty.usbserial, 13:55:21
-
-Press Meta-Z for help on special keys
-
-
-010674 compat>
-```
-<br>
-### Step 9: Viewing the Registered Sensors and Sensor Data
-The sensor framework package implements the `sensor` shell command. This command allows you to:
-
-* List all the registered sensor devices.
-* View the sensor types that a registered sensor device supports.
-* Read sensor data samples.
-
-To view the command syntax, enter `sensor`
-
-```no-highlight
-
-002340 Possible commands for sensor are:
-002341 list
-002341 list of sensors registered
-002342 read <sensor_name> <type> [-n nsamples] [-i poll_itvl(ms)] [-d poll_du]
-002344 read <no_of_samples> from sensor<sensor_name> of type:<type> at pr
-002347 at <poll_interval> rate for <poll_duration>
-002348 type <sensor_name>
-002349 types supported by registered sensor
-002350 compat>
-
-```
-<br>
-#### Listing the Registered Sensors<br>
-You use the `sensor list` command to list all the registered sensor devices:
-<br>
-```no-highlight
-
-031798 compat> sensor list
-129441 sensor dev = bno055_0, configured type = 0x1 0x2 0x4 0x200 0x1000 0x2000
-129444 compat>
-
-```
-
-The output shows one sensor, **bno055_0**, registered, and the configured types for the sensor. A configure type is a subset of the types that a sensor supports.
-
-<br>
-
-#### Listing the Types that a Sensor Supports
-
-You use the `sensor type` command to list the types that a sensor supports:
-
-```no-highlight
-
-031822 compat> sensor type bno055_0
-033156 sensor dev = bno055_0,
-type =
-033157 accelerometer: 0x1
-033157 magnetic field: 0x2
-033158 gyroscope: 0x4
-033159 temperature: 0x10
-033160 vector: 0x200
-033160 accel: 0x1000
-033161 gravity: 0x2000
-033162 euler: 0x4000
-
-```
-
-<br>
-#### Viewing Sensor Data Samples
-You use the `sensor read` command to read data samples for a configured type. You can specify the number of samples to read, a poll interval, and a poll duration. You can only view sensor data for the sensor types that a sensor device is configured for.
-
-**Example 1:** Read 5 samples of accelerometer data from the **bno055_0** sensor:
-
-```no-highlight
-
-033163 compat> sensor read bno055_0 0x1 -n 5
-042974 ts: [ secs: 335 usecs: 745441 cputime: 336218225 ]
-042976 x = -0.519999968 y = -7.289999968 z = 6.489999776
-042978 ts: [ secs: 335 usecs: 771216 cputime: 336244000 ]
-042979 x = -0.529999968 y = -7.360000128 z = 6.559999936
-042981 ts: [ secs: 335 usecs: 794640 cputime: 336267424 ]
-042982 x = -0.529999968 y = -7.340000160 z = 6.480000032
-042983 ts: [ secs: 335 usecs: 810795 cputime: 336283579 ]
-042984 x = -0.519999968 y = -7.300000192 z = 6.530000224
-042986 ts: [ secs: 335 usecs: 833703 cputime: 336306487 ]
-042987 x = -0.510000000 y = -7.309999936 z = 6.380000128
-
-```
-
-Each sample contains two lines of output. The first line is the time when the sample is read. The second line is the sample data. For the example output:
-
-These two lines are for the first sample:
-<br>
-```no-highlight
-
-042974 ts: [ secs: 335 usecs: 745441 cputime: 336218225 ]
-042976 x = -0.519999968 y = -7.289999968 z = 6.489999776
-
-```
-<br>
-These two lines are for the last sample:
-<br>
-```no-highlight
-
-042986 ts: [ secs: 335 usecs: 833703 cputime: 336306487 ]
-042987 x = -0.510000000 y = -7.309999936 z = 6.380000128
-
-```
-<br>
-
-**Example 2:** Read the vector data at 20 ms poll interval. You can enter `ctrl-c`, `q <return>`, or `Q <return>` to stop the polling.
-<br>
-
-```no-highlight
-002350 compat> sensor read bno055_0 0x200 -i 20
-019271 ts: [ secs: 150 usecs: 560056 cputime: 151019584 ]
-019272 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019274 ts: [ secs: 150 usecs: 580598 cputime: 151040126 ]
-019275 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019277 ts: [ secs: 150 usecs: 604036 cputime: 151063564 ]
-019278 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019280 ts: [ secs: 150 usecs: 627474 cputime: 151087002 ]
-019281 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019283 ts: [ secs: 150 usecs: 650912 cputime: 151110440 ]
-019284 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019286 ts: [ secs: 150 usecs: 674350 cputime: 151133878 ]
-019287 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019289 ts: [ secs: 150 usecs: 697788 cputime: 151157316 ]
-019290 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019292 ts: [ secs: 150 usecs: 721225 cputime: 151180753 ]
-019293 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019295 ts: [ secs: 150 usecs: 744663 cputime: 151204191 ]
-019296 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019298 ts: [ secs: 150 usecs: 768101 cputime: 151227629 ]
-019299 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-019301 ts: [ secs: 150 usecs: 791539 cputime: 151251067 ]
-019302 x = 3.442626944 y = 0.026977540 z = 3.993286144 w = 0.829833984
-
-```
-<br>
-### Step 10: Controlling and Viewing Sensor Device Hardware and Sensor Data
-The BNO055 device driver implements the `bno055` shell command that allows you to:
-
-* Read sensor data samples for all the sensor types that the device supports.
-
- **Note:** The `sensor` shell command discussed previously only reads sensor data for configured sensor types.
-
-* Query the chip id, sensor revisions, content of registers, sensor offsets.
-* Reset the device.
-* Change the power mode.
-* Change the operation mode.
-<br>
-
-Enter `bno055` to see the command syntax:
-
-```no-highlight
-
-711258 bno055 cmd [flags...]
-711259 cmd:
-711259 r [n_samples] [ 0-acc | 1 -mag | 2 -gyro | 4 -tem|
- 9-quat | 26-linearacc | 27-gravity | 28-eul]
-
-711264 mode [0-config | 1-acc | 2 -mag | 3 -gyro | 4 -acc|
- 5-accgyro | 6-maggyro | 7 -amg | 8 -imuplus | 9 -com|
- 9-m4g |11-NDOF_FMC_OFF | 12-NDOF ]
-711269 chip_id
-711270 rev
-711270 reset
-711270 pmode [0-normal | 1-lowpower | 2-suspend]
-711272 sensor_offsets
-711272 dumpreg [addr]
-
-```
-
-<br>
-** Example 3: ** Query the device chip id:
-<br>
-
-```no-highlight
-
-711273 compat> bno055 chip_id
-769056 0xA0
-
-```
-
-<br>
-
-**Example 4:** View the sensor revisions:
-<br>
-
-```no-highlight
-
-827472 compat> bno055 rev
-862354 accel_rev:0xFB
-mag_rev:0x32
-gyro_rev:0x0F
-sw_rev:0x311
-bl_rev:0x15
-
-```
-<br>
-### Next Steps
-
-Now that you have successfully enabled an application to communicate with a sensor, We recommend that you:
-
-* Experiment with other `sensor` and `bno055` shell commands in this tutorial to view other types of sensor data.
-* Change the default configuration values for the sensor. See the [Changing the Default Configuration for a Sensor tutorial](/os/tutorials/sensors/sensor_offboard_config.md).
-* Try a different off-board sensor. You can follow most of the procedures in this tutorial to enable other sensors in the sensors_test application. The `syscfg.yml` file for the `hw/sensor/creator/` package specifies the off-board sensors that Mynewt currently supports. You will need to:
- * Enable the `<SENSORNAME>_OFB` setting to include the sensor driver package and to create and initialize the sensor device.
- * Enable the correct interface in the nRF52 BSP to communicate with the sensor device.
- * Enable the sensor device driver shell command if the driver supports the shell. You can check the `syscfg.yml` file for the sensor device driver package in the `hw/drivers/sensor/<sensorname>` directory.
-* Try one of the other sensor tutorials listed in the [Sensor Tutorials Overview](/os/tutorials/sensors/sensors.md).
diff --git a/docs/os/tutorials/sensors/sensor_nrf52_bno055_oic.md b/docs/os/tutorials/sensors/sensor_nrf52_bno055_oic.md
deleted file mode 100644
index d361c21..0000000
--- a/docs/os/tutorials/sensors/sensor_nrf52_bno055_oic.md
+++ /dev/null
@@ -1,103 +0,0 @@
-## Enabling OIC Sensor Data Monitoring in the sensors_test Application
-
-This tutorial shows you how to enable sensor data monitoring via the OIC protocol over BLE transport in the sensors_test application. It extends the example application in the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055.md) and assumes that you have worked through that tutorial.
-
-Like the other off-board sensor tutorials, this tutorial uses an nRF52-DK board connected to an off-board BNO055 sensor device.
-
-This tutorial shows you how to:
-
-* Create and build the target to enable sensor OIC support in the sensors_test application.
-* Use the Mynewt Smart Device Controller Android or iOS app to view the sensor data from the device.
-<br>
-
-### Prerequisite
-
-Read the [Overview of OIC Support in the Sensor Framework](/os/tutorials/sensors/sensor_oic_overview.md).
-
-### Step 1: Creating and Building the sensors_test Application Image
-
-In this step of the tutorial, we set the following syscfg settings to create a target for the sensors_test application.
-
-* `BNO055_OFB` and `I2C_0`: Set to 1 to enable the BNO055 off-board sensor device and the I2C interface 0 in the nRF52 BSP.
-* `BLE_MAX_CONNECTIONS`: Set the number of BLE connections to 4.
-* `MSYS_1_BLOCK_COUNT`: Set the number of entries for the mbuf pool to 52.
-* `MSYS_1_BLOCK_SIZE`: Set the size of mbuf entry to 100.
-* `OC_APP_RESOURCES`: Set the number of server resources to 12.
-
-**Note:** The `SENSOR_OIC`, `OC_SERVER`, `BLE_ROLE_PERIPHERAL` and `BLE_ROLE_BROADCASTER` syscfg settings must be enabled to add OIC sensor monitoring over BLE transport support to an application. You do not need to set these settings in the target because the `apps/sensors_test` package enables the `SENSORS_OIC` and `OC_SERVER` syscfg settings by default, and the `net/nimble` package enables the `BLE_ROLE_PERIPHERAL` and `BLE_ROLE_BROADCASTER` settings by default.
-
-<br>
-1. Run the `newt target create` command to create the target. We name the target `nrf52_bno055_oic_test`.
-<br>
-```no-highlight
-
-$ newt target create nrf52_bno055_oic_test
-Target targets/nrf52_bno055_oic_test successfully created
-$
-
-```
-<br>
-2. Run the `newt target set` command to set the app, bsp, and build_profile variables for the target:
-<br>
-```no-highlight
-
-$ newt target set nrf52_bno055_oic_test app=@apache-mynewt-core/apps/sensors_test bsp=@apache-mynewt-core/hw/bsp/nrf52dk build_profile=debug
-Target targets/nrf52_bno055_oic_test successfully set target.app to @apache-mynewt-core/apps/sensors_test
-Target targets/nrf52_bno055_oic_test successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52dk
-Target targets/nrf52_bno055_oic_test successfully set target.build_profile to debug
-$
-
-```
-<br>
-3. Run the `newt target set` command to set `I2C_0=1`, `BNO055_OFB=1`, `BLE_MAX_CONNECTIONS=4`, `MSYS_1_BLOCK_COUNT=52`, `MSYS_1_BLOCK_SIZE=100`, and `OC_APP_RESOURCES=11`.
-
-**Note:** If you want to disable the `sensor` and `bno055` shell commands, also set `SENSOR_CLI=0` and `BNO055_CLI=0`.
-
-
-```no-highlight
-
-$ newt target set nrf52_bno055_oic_test syscfg=BNO055_OFB=1:I2C_0=1:BLE_MAX_CONNECTIONS=4:MSYS_1_BLOCK_COUNT=52:MSYS_1_BLOCK_SIZE=100:OC_APP_RESOURCES=11
-Target targets/nrf52_bno055_oic_test successfully set target.syscfg to BNO055_OFB=1:I2C_0=1:BLE_MAX_CONNECTIONS=4:MSYS_1_BLOCK_COUNT=52:MSYS_1_BLOCK_SIZE=100:OC_APP_RESOURCES=11
-$
-
-```
-<br>
-4. Run the `newt build nrf52_bno055_oic_test` and `newt create-image nrf52_bno055_oic_test 1.0.0` commands to build and create the application image.
-
-<br>
-### Step 2: Connecting the Sensor and Loading the Images to the Board
-
-Perform the following steps to reboot the board with the new images:
-
-1. Connect the BNO055 sensor to the nRF52-DK board. See the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_offboard_config.md) for instructions.
-
- **Note**: You do not need the serial connection from your computer to the nRF52-DK board for this tutorial because we are not using the shell to view the sensor data.
-
-2. Run the `newt load nrf52_boot` command to load the bootloader.
-3. Run the `newt load nrf52_bno055_oic_test` command to load the application image.
-4. Power the device OFF and ON to reboot.
-
-<br>
-### Step 3: Viewing Sensor Data from the Mynewt Smart Device Controller
-
-Start the Mynewt Smart Device Controller app on your iOS or Android device to view the sensor data. If you have not installed the Mynewt Smart Device Controller follow the instructions in the [Sensor Tutorials Overview](/os/tutorials/sensors/sensors.md) to install the app, then continue with this step of the tutorial.
-
-<br>
-The Mynewt Smart Device Controller scans for the devices when it starts up and displays the sensors it can view. The following is an example from the Android App:
-<br>
-<p>
-<p align="center">
-<img src="../../pics/smart_controller_main.png"></img>
-</p>
-<br>
-
-2. Select `Accelerometer` to see the sensor data samples:
-<br>
-<p>
-<p align="center">
-<img src="../../pics/smart_controller_accelerometer.png"></img>
-</p>
-<p>
-<br>
-
-3. Move your BNO055 sensor device around to see the values for the coordinates change.
diff --git a/docs/os/tutorials/sensors/sensor_offboard_config.md b/docs/os/tutorials/sensors/sensor_offboard_config.md
deleted file mode 100644
index 91c1d49..0000000
--- a/docs/os/tutorials/sensors/sensor_offboard_config.md
+++ /dev/null
@@ -1,205 +0,0 @@
-## Changing the Default Configuration for a Sensor
-
-This tutorial shows you how to change default configuration values for an off-board sensor. It continues with the example in the [Enabling an Off-Board Sensor in an Existing Application tutorial](/os/tutorials/sensors/sensor_offboard_config.md).
-
-
-** Note:** You can also follow most of the instructions in this tutorial to change the default configuration for an onboard sensor. The difference is that the BSP, instead of the sensor creator package, creates and configures the onboard sensor devices in the `hal_bsp.c` file. You should check the BSP to determine whether the default configuration for a sensor meets your application requirements.
-
-### Prerequisite
-
-Complete the tasks described in the [Enabling an Off-Board Sensor in an Existing Application tutorial](/os/tutorials/sensors/sensor_offboard_config.md).
-
-### Overview on How to Initialize the Configuration Values for a Sensor
-
-The sensor creator package, `hw/sensor/creator`, creates, for each enabled sensor, an os device in the kernel for the sensor and initializes the sensor with its default configuration when the package is initialized. The steps to configure a sensor device are:
-
-1. Open the os device for the sensor.
-2. Initialize the sensor driver configuration data structure with default values.
-3. Call the `<sensorname>_config()` function that the sensor device driver package exports.
-4. Close the os device for the sensor.
-
-For the BNO055 sensor device, the creator package calls the local `config_bno055_sensor()` function to configure the sensor. A code excerpt for this function is shown below:
-
-```c
-static int
-config_bno055_sensor(void)
-{
- int rc;
- struct os_dev *dev;
- struct bno055_cfg bcfg;
-
- dev = (struct os_dev *) os_dev_open("bno055_0", OS_TIMEOUT_NEVER, NULL);
- assert(dev != NULL);
-
- bcfg.bc_units = BNO055_ACC_UNIT_MS2 | BNO055_ANGRATE_UNIT_DPS |
- BNO055_EULER_UNIT_DEG | BNO055_TEMP_UNIT_DEGC |
- BNO055_DO_FORMAT_ANDROID;
-
- bcfg.bc_opr_mode = BNO055_OPR_MODE_NDOF;
- bcfg.bc_pwr_mode = BNO055_PWR_MODE_NORMAL;
- bcfg.bc_acc_bw = BNO055_ACC_CFG_BW_125HZ;
- bcfg.bc_acc_range = BNO055_ACC_CFG_RNG_16G;
- bcfg.bc_mask = SENSOR_TYPE_ACCELEROMETER|
- SENSOR_TYPE_MAGNETIC_FIELD|
- SENSOR_TYPE_GYROSCOPE|
- SENSOR_TYPE_EULER|
- SENSOR_TYPE_GRAVITY|
- SENSOR_TYPE_LINEAR_ACCEL|
- SENSOR_TYPE_ROTATION_VECTOR;
-
- rc = bno055_config((struct bno055 *) dev, &bcfg);
-
- os_dev_close(dev);
- return rc;
-}
-
-```
-<br>
-### Changing the Default Configuration
-
-To change the default configuration, you can directly edit the fields in the `config_bno055_sensor()` function in the `hw/sensor/creator/sensor_creator.c` file or add code to your application to reconfigure the sensor during application initialization.
-
-This tutorial shows you how to add the code to the `apps/sensors_test/src/main.c` file to configure the sensor without the accelerometer sensor type. When you reconfigure a sensor in the application, you must initialize all the fields in the sensor configuration data structure even if you are not changing the default values.
-
-<br>
-#### Step 1: Adding the Sensor Device Driver Header File
-
-Add the bno055 device driver header file:
-
-```
-#include <bno055/bno055.h>
-
-```
-<br>
-#### Step 2: Adding a New Configuration Function
-
-Add the `sensors_test_config_bno055()` function and copy the code from the `config_bno055_sensor()` function in the `hw/sensor/creator/sensor_creator.c` file to the body of the `sensors_test_config_bno055()` function. The content of the `sensors_test_config_bno055()` function should look like the example below:
-
-```c
-static int
-sensors_test_config_bno055(void)
-{
- int rc;
- struct os_dev *dev;
- struct bno055_cfg bcfg;
-
- dev = (struct os_dev *) os_dev_open("bno055_0", OS_TIMEOUT_NEVER, NULL);
- assert(dev != NULL);
-
- bcfg.bc_units = BNO055_ACC_UNIT_MS2 | BNO055_ANGRATE_UNIT_DPS |
- BNO055_EULER_UNIT_DEG | BNO055_TEMP_UNIT_DEGC |
- BNO055_DO_FORMAT_ANDROID;
-
- bcfg.bc_opr_mode = BNO055_OPR_MODE_NDOF;
- bcfg.bc_pwr_mode = BNO055_PWR_MODE_NORMAL;
- bcfg.bc_acc_bw = BNO055_ACC_CFG_BW_125HZ;
- bcfg.bc_acc_range = BNO055_ACC_CFG_RNG_16G;
- bcfg.bc_use_ext_xtal = 1;
- bcfg.bc_mask = SENSOR_TYPE_ACCELEROMETER|
- SENSOR_TYPE_MAGNETIC_FIELD|
- SENSOR_TYPE_GYROSCOPE|
- SENSOR_TYPE_EULER|
- SENSOR_TYPE_GRAVITY|
- SENSOR_TYPE_LINEAR_ACCEL|
- SENSOR_TYPE_ROTATION_VECTOR;
-
- rc = bno055_config((struct bno055 *) dev, &bcfg);
-
- os_dev_close(dev);
- return rc;
-}
-
-```
-<br>
-#### Step 3: Changing the Default Configuration Settings
-
-Delete the `SENSOR_TYPE_ACCELEROMETER` type from the `bcfg.bc_mask` initialization setting values:
-
-```hl_lines="8"
-
-static int
-sensors_test_config_bno055(void)
-{
- int rc
- ...
-
- /* Delete the SENSOR_TYPE_ACCELEROMETER from the mask */
- bcfg.bc_mask = SENSOR_TYPE_MAGNETIC_FIELD|
- SENSOR_TYPE_GYROSCOPE|
- SENSOR_TYPE_EULER|
- SENSOR_TYPE_GRAVITY|
- SENSOR_TYPE_LINEAR_ACCEL|
- SENSOR_TYPE_ROTATION_VECTOR;
-
- rc = bno055_config((struct bno055 *) dev, &bcfg);
-
- os_dev_close(dev);
- return rc;
-
-```
-<br>
-
-#### Step 4: Calling the Configuration Function From main()
-
-Add the `int rc` declaration and the call to the `sensors_test_config_bno055()` function in `main()`:
-
-
-```c
-int
-main(int argc, char **argv)
-{
-
- /* Add rc for the return value from sensors_test_config_bno055() */
- int rc;
-
- ....
- /* Add call to sensors_test_config_bno055() and abort on error */
- rc = sensors_test_config_bno055();
- assert(rc == 0);
-
- /* log reboot */
- reboot_start(hal_reset_cause());
-
- /*
- * As the last thing, process events from default event queue.
- */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-
- return (0);
-}
-
-```
-<br>
-#### Step 5: Building a New Application Image
-
-Run the `newt build nrf52_bno055_test` and the `newt create-image nrf52_bno055_test 2.0.0` commands to rebuild and create a new application image.
-
-<br>
-#### Step 6: Loading the New Image and Rebooting the Device
-
-Run the `newt load nrf52_bno055_test` command and power the device OFF and On.
-
-<br>
-#### Step 7: Verifing the Sensor is Configured with the New Values
-
-Start a terminal emulator, and run the `sensor list` command to verify the accelerometer (0x1) is not configured. The `configured type` listed for the sensor should not have the value `0x1`.
-
-```hl_lines="2"
-
-045930 compat> sensor list
-046482 sensor dev = bno055_0, configured type = 0x2 0x4 0x200 0x1000 0x2000 0x4000
-046484 compat>
-
-```
-<br>
-#### Step 8: Verifying that the Accelerometer Data Samples Cannot be Read
-
-Run the `sensor read` command to read data samples from the accelerometer to verify that the sensor cannot be read:
-```no-highlight
-
-046484 compat> sensor read bno055_0 0x1 -n 5
-092387 Cannot read sensor bno055_0
-
-```
diff --git a/docs/os/tutorials/sensors/sensor_oic_overview.md b/docs/os/tutorials/sensors/sensor_oic_overview.md
deleted file mode 100644
index 1d0f615..0000000
--- a/docs/os/tutorials/sensors/sensor_oic_overview.md
+++ /dev/null
@@ -1,28 +0,0 @@
-## Enabling OIC Sensor Data Monitoring
-
-This tutorial shows you how to enable sensor data monitoring via the OIC protocol over BLE transport in an application. It extends the example application in the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055.md) and assumes that you have worked through that tutorial.
-
-This tutorial has two parts:
-
-* [Part 1](/os/tutorials/sensors/sensor_nrf52_bno055_oic.md) shows you how to enable OIC sensor support in the sensors_test application. The procedure only requires setting the appropriate syscfg setting values for the application target. The objective is to show you to quickly bring up the sensors_test application and view the sensor data with the Mynewt Smart Device Controller app that is available for iOS and Android devices.
-
-* [Part 2](/os/tutorials/sensors/sensor_bleprph_oic.md) shows you how to modify the bleprph_oic application code to add OIC sensor support. The objective is to show you how to use the Sensor Framework API and OIC server API to develop an OIC over BLE sensor server application.
-<br>
-### Prerequisites
-Ensure that you meet the following prerequisites before continuing with the tutorials:
-
-* Complete the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055.md).
-* Install the Mynewt Smart Device Controller on an iOS or Android Device. See the [Sensor Tutorials Overview](/os/tutorials/sensors/sensors.md) on how to install the Mynewt Smart Device Controller app.
-
-### Overview of OIC Support in the Sensor Framework
-
-The sensor framework provides support for a sensor enabled application to host the sensor devices as OIC resources. The sensor framework provides the following OIC support:
-
-* Creates OIC resources for each sensor device that is enabled in the application. It creates an OIC discoverable and observable resource for each sensor type that the sensor device is configured for.
-* Processes CoAP GET requests for the sensor OIC resources. It reads the sensor data samples, encodes the data, and sends back a response.
-
-The sensor package (`hw/sensor`) defines the following syscfg settings for OIC support:
-
-* `SENSOR_OIC`: This setting specifies whether to enable sensor OIC server support. The setting is enabled by default. The sensor package includes the `net/oic` package for the OIC support when this setting is enabled. The `OC_SERVER` syscfg setting that specifies whether to enable OIC server support in the `net/oic` package must also be enabled.
-* `SENSOR_OIC_OBS_RATE`: Sets the OIC server observation rate.
-
diff --git a/docs/os/tutorials/sensors/sensor_thingy_lis2dh12_onb.md b/docs/os/tutorials/sensors/sensor_thingy_lis2dh12_onb.md
deleted file mode 100644
index 916b84f..0000000
--- a/docs/os/tutorials/sensors/sensor_thingy_lis2dh12_onb.md
+++ /dev/null
@@ -1,689 +0,0 @@
-## Developing an Application for an Onboard Sensor
-
-This tutorial shows you how to develop a simple application for an onboard sensor. The Mynewt sensor framework enables you to easily and quickly develop Mynewt sensor applications. We assume that you have completed the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055.md) and are familiar with the sensor framework and sensor shell command.
-
-<br>
-This tutorial shows you how to:
-
-* Develop an application for the Nordic Thingy LIS2DH12 accelerometer onboard sensor with the sensor framework `sensor` shell command enabled to view sensor data.
-* Extend the application to use the sensor framework API to read the sensor data and output the data to the Mynewt console.
-
-### Prerequisites
-
-* Meet the prerequisites listed in the [Sensor Tutorials Overview](/os/tutorials/sensors/sensors.md).
-* Have a Nordic Thingy.
-* [Segger J-Link Debug Probe](https://www.segger.com/jlink-debug-probes.html).
-* [J-Link 9 pin Cortex-M Adapter](https://www.segger.com/jlink-adapters.html#CM_9pin) that allows JTAG, SWD and SWO connections between J-Link and Cortex M based target hardware systems.
-* Install the [Segger JLINK Software and documentation pack](https://www.segger.com/jlink-software.html).
-* Complete the [Enabling an Off-Board Sensor in an Existing Application Tutorial](/os/tutorials/sensors/sensor_nrf52_bno055.md).
-
-### Developing a Sensor Enabled Application with Shell Support
-
-We first develop a simple application with the LIS2DH12 onboard sensor on the Nordic Thingy and the `sensor` shell command enabled.
-
-<br>
-#### Step 1: Creating a New App Package
-
-We name the new app package `my_sensor_app`. From your project base directory, run the `newt pkg new` command to create a new app package. This tutorial uses ~/dev/myproj for the project.
-
-
-```no-highlight
-$ cd ~/dev/myproj
-$ newt pkg new -t app apps/my_sensor_app
-Download package template for package type app.
-Package successfuly installed into ~/dev/myproj/apps/my_sensor_app
-
-```
-<br>
-The newt tool creates a skeleton `my_sensor_app` package directory in the `~/dev/myproj/apps/` directory. Go to the `my_sensor_app` directory to update the package `pkg.yml` and source files.
-
-
-```no-highlight
-
-$ cd apps/my_sensor_app
-
-```
-
-<br>
-#### Step 2: Adding the Package Dependencies
-
-The my_sensor_app package requires the sensor framework, `hw/sensor`, package as a package dependency. Note that the BSP creates the sensor devices for the onboard sensors, so the `hw/sensor/creator` package that creates off-board sensor is not needed.
-
-Add the highlighted line to the `pkg.yml` file to add the `hw/sensor` package as package dependency:
-
-```hl_lines="6"
-
-pkg.deps:
- - "@apache-mynewt-core/kernel/os"
- - "@apache-mynewt-core/sys/console/full"
- - "@apache-mynewt-core/sys/log/full"
- - "@apache-mynewt-core/sys/stats/full"
- - "@apache-mynewt-core/hw/sensor"
-
-```
-<br>
-#### Step 3: Using the Skeleton main.c File
-
-The newt tool creates a skeleton main.c file in the `my_sensor_app/src` directory. The skeleton `main()` code shown is all you need to build an application that only uses the `sensor` shell command to read sensor data. You do not need to make any changes to the file. The sensor framework implements the `sensor` shell command and the shell package processes shell command events from the OS default event queue.
-
-
-```c
-
-int
-main(int argc, char **argv)
-{
- /* Perform some extra setup if we're running in the simulator. */
-#ifdef ARCH_sim
- mcu_sim_parse_args(argc, argv);
-#endif
-
- /* Initialize all packages. */
- sysinit();
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-
- return 0;
-}
-
-```
-
-<br>
-#### Step 4: Creating the Target for the my_sensor_app Application
-
-You create a target for the my_sensor_app to run on the Nordic Thingy. The following syscfg settings must be set:
-
-* `I2C_0=1` : Enables the I2C interface 0 for the nRF52 Thingy BSP HAL setting to communicate with the onboard sensor.
-* `LIS2DH12_ONB=1`: Enables the lis2dh12 onboard sensor support in the nRF52 Thingy BSP.
-
- A BSP with onboard sensors defines a syscfg setting for each onboard sensor it supports and uses the naming convention `<SENSORNAME>_ONB`. The `<SENSORNAME>_ONB` setting specifies whether the sensor named SENSORNAME is enabled. The setting is disabled by default. The BSP includes the sensor device driver package `hw/drivers/sensors/<sensorname>` and creates and configures the onboard sensor named SENSORNAME when the `<SENSORNAME>_ONB` setting is enabled by the application.
-
-* `SHELL_TASK=1`: Enables the shell task for the shell command support.
- Note that the `hw/sensor` package enables the `SENSOR_CLI` setting by default.
-* `SENSOR_OIC=0`: Disables the OIC sensor server support in the sensor framework.
-* `CONSOLE_RTT=1`: Enables console communication via the SEGGER RTT. The nRF52 Thingy does not have a UART so we use the RTT for the console.
-* `CONSOLE_UART=0`: Disables the console communication via a UART.
-
-**Note:** The lis2dh12 sensor device driver package, `/hw/driver/sensors/lis2dh12`, currently does not support a shell command to view information on the device.
-
-<br>
-1. Run the following newt commands to create the target and set the application and BSP.
-
-```no-highlight
-
-$ newt target create thingy_my_sensor
-Target targets/thingy_my_sensor successfully created
-$ newt target set thingy_my_sensor bsp=@apache-mynewt-core/hw/bsp/nrf52-thingy
-Target targets/thingy_my_sensor successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52-thingy
-$ newt target set thingy_my_sensor app=apps/my_sensor_app
-Target targets/thingy_my_sensor successfully set target.app to apps/my_sensor_app
-$ newt target set thingy_my_sensor build_profile=debug
-Target targets/thingy_my_sensor successfully set target.build_profile to debug
-
-```
-
-<br>
-2. Run the following `newt target set ` command to set the syscfg settings:
-
-```no-highlight
-
-$ newt target set thingy_my_sensor syscfg=I2C_0=1:LIS2DH12_ONB=1:SHELL_TASK=1:CONSOLE_RTT=1:CONSOLE_UART=0:SENSOR_OIC=0
-Target targets/thingy_my_sensor successfully set target.syscfg to I2C_0=1:LIS2DH12_ONB=1:SHELL_TASK=1:CONSOLE_RTT=1:CONSOLE_UART=0:SENSOR_OIC=0
-
-```
-
-<br>
-#### Step 5: Creating and Building the Bootloader Target
-
-Create a target for the bootloader for the nRF52 Thingy. We name the target `thingy_boot`.
-
-<br>
-1. Run the following `newt target` commands to create the target:
-
-```no-highlight
-
-$ newt target create thingy_boot
-Target targets/thingy_boot successfully created
-$ newt target set thingy_boot bsp=@apache-mynewt-core/hw/bsp/nrf52-thingy
-Target targets/thingy_boot successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52-thingy
-$ newt target set thingy_boot app=@apache-mynewt-core/apps/boot
-Target targets/thingy_boot successfully set target.app to @apache-mynewt-core/apps/boot
-$ newt target set thingy_boot build_profile=optimized
-Target targets/thingy_boot successfully set target.build_profile to optimized
-
-```
-
-<br>
-2. Run the `newt build` command to build the bootloader target:
-
-```no-highlight
-
-$ newt build thingy_boot
-Building target targets/thingy_boot
-
- ...
-
-Archiving thingy_boot-sysinit-app.a
-Archiving util_mem.a
-Linking ~/dev/myproj/bin/targets/thingy_boot/app/apps/boot/boot.elf
-Target successfully built: targets/thingy_boot
-
-```
-
-<br>
-#### Step 6: Connecting the Thingy to your Computer
-Perform the following steps to connect the Thingy to your computer:
-
-<br>
-1. Move the power switch to the left to power ON the Thingy:
-
-<br>
-
-<br>
-
-<br>
-2. Connect the debug probe to the JTAG port on the board using the Jlink 9-pin adapter and cable, and connect the probe to your computer.
-
-<br>
-
-<br>
-<p>
-<br>
-
-<br>
-#### Step 7: Loading the Image and Connecting to the Console via RTT
-
-To run the application, you need to load the bootloader on to the device, load the application image, and start a GDB debug process for RTT to attach to.
-
-<br>
-1. Run the `newt load` command to load the bootloader:
-
-```no-highlight
-
-$ newt load thingy_boot
-Loading bootloader
-
-```
-<br>
-2. Run the `newt run` command to build and create an image for the my_sensor_app, load the image, and start a GDB process to debug the application:
-
-```no-highlight
-
-$ newt run thingy_my_sensor 1.0.0
-Assembling repos/apache-mynewt-core/hw/bsp/nrf52-thingy/src/arch/cortex_m4/gcc_startup_nrf52_split.s
-Compiling repos/apache-mynewt-core/hw/cmsis-core/src/cmsis_nvic.c
-Assembling repos/apache-mynewt-core/hw/bsp/nrf52-thingy/src/arch/cortex_m4/gcc_startup_nrf52.s
-Compiling repos/apache-mynewt-core/encoding/base64/src/hex.c
-Compiling apps/my_sensor_app/src/main.c
-
- ...
-
-Archiving thingy_my_sensor-sysinit-app.a
-Archiving time_datetime.a
-Archiving util_cbmem.a
-Archiving util_crc.a
-Archiving util_mem.a
-Archiving util_parse.a
-Linking ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf
-App image succesfully generated: ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.img
-Loading app image into slot 1
-[~/dev/myproj/repos/apache-mynewt-core/hw/bsp/nrf52-thingy/nrf52-thingy_debug.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/nrf52-thingy ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app]
-Debugging ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf
-GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
-Copyright (C) 2014 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law. Type "show copying"
-and "show warranty" for details.
-This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
-Type "show configuration" for configuration details.
-For bug reporting instructions, please see:
-<http://www.gnu.org/software/gdb/bugs/>.
-Find the GDB manual and other documentation resources online at:
-<http://www.gnu.org/software/gdb/documentation/>.
-For help, type "help".
-Type "apropos word" to search for commands related to "word"...
-Reading symbols from ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf...done.
-os_tick_idle (ticks=24)
- at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_os_tick.c:204
-204 if (ticks > 0) {
-Resetting target
-0x000000dc in ?? ()
-(gdb)
-
-```
-
-<br>
-3. Enter `c <return>` in the (gdb) prompt to continue.
-
-<br>
-4. Run the following telnet command to connect to the Mynewt console via RTT and enter <return> to get the shell prompt after you are connected.
-
-```no-highlight
-
-$ telnet localhost 19021
-Trying ::1...
-telnet: connect to address ::1: Connection refused
-Trying 127.0.0.1...
-Connected to localhost.
-Escape character is '^]'.
-SEGGER J-Link V6.14h - Real time terminal output
-SEGGER J-Link ARM V10.0, SN=600000268
-Process: JLinkGDBServer
-
-011468 compat>
-
-```
-
-<br>
-#### Step 8: Viewing the list of Sensors and Sensor Data
-
-<br>
-1. Enter `sensor list` to see the sensors that are registered with the sensor manager. You should see the `lis2dh12_0` sensor. This sensor is only configured for the accelerometer (0x1).
-
-
-```no-highlight
-
-011468 compat> sensor list
-sensor list
-029706 sensor dev = lis2dh12_0, configured type = 0x1
-029707 compat>
-
-```
-
-<br>
-2. Enter the `sensor read` command to read some data samples from the accelerometer:
-
-```no-highlight
-
-029707 compat> sensor read lis2dh12_0 0x1 -n 5
-sensor read lis2dh12_0 0x1 -n 5
-042537 ts: [ secs: 331 usecs: 102682 cputime: 331436945 ]
-042537 x = 9.806650176 y = 58.839900992 z = -9894.910156
-042537 ts: [ secs: 331 usecs: 104832 cputime: 331439095 ]
-042537 x = 19.613300352 y = 98.066497804 z = -9924.330078
-042537 ts: [ secs: 331 usecs: 106988 cputime: 331441251 ]
-042537 x = 9.806650176 y = 49.033248902 z = -9904.716796
-042538 ts: [ secs: 331 usecs: 109137 cputime: 331443400 ]
-042538 x = 9.806650176 y = 29.419950496 z = -9904.716796
-042538 ts: [ secs: 331 usecs: 111288 cputime: 331445551 ]
-042538 x = 58.839900992 y = 0.000000000 z = -9816.457031
-042538 compat>
-
-
-```
-
-<br>
-### Extending the Application to Use the Sensor API to Read Sensor Data
-
-As this tutorial demonstrates so far, the Mynewt sensor framework enables you to easily and quickly develop an application with a sensor and view the sensor data from the `sensor` shell command. We now extend the application to use the sensor API to read the sensor data.
-
-There are two sensor functions that you can use to read data from a sensor device:
-
-* `sensor_register_listener()`: This function allows you to register a listener for a sensor device. You specify a bit mask of the types of sensor data to listen for and a callback to call when data is read from the sensor device. The listener callback is called whenever the `sensor_read()` function reads data for a sensor type from a sensor device that the listener is listening for.
-
- The sensor framework supports polling of sensor devices. For a sensor device that has a polling rate configured, the sensor framework poller reads sensor data for all the configured sensor types from the sensor device at each polling interval and calls the registered listener callbacks with the sensor data.
-
-* `sensor_read()`: This function reads sensor data from a sensor device and calls the specified user callback to receive the sensor data. You specify a bit mask of the types of sensor data to read from a sensor device and a callback. This callback is called for each sensor type you specify to read.
-
-
-We first extend the application to a register a sensor listener to demonstrate how to use the sensor framework polling support. We then extend the application to use the `sensor_read()` function instead of a listener. An application may not need to poll sensors. For example, an application that processes remote requests for sensor data might only read the sensor data when it receives a request.
-
-<br>
-#### Step 1: Modifying main.c to Add a Sensor Listener
-
-Add the following code to the `my_sensor_app/src/main.c` file:
-
-<br>
-1. Add the highlighted include files:
-
-```hl_lines="4 5 6 7"
-
-#include "sysinit/sysinit.h"
-#include "os/os.h"
-
-#include <defs/error.h>
-#include <sensor/sensor.h>
-#include <sensor/accel.h>
-#include <console/console.h>
-
-```
-
-<br>
-2. Add the `struct sensor * my_sensor`. This is the handle for the sensor that the sensor API uses to perform operations on the sensor. We set this variable when we lookup the sensor.
-
-```c
-
-static struct sensor *my_sensor;
-
-```
-<br>
-3. Declare and initialize a sensor listener. You specify a bit mask for the sensor types to listen for, the callback function, and an opaque argument to pass to the callback. You initialize the type to SENSOR_TYPE_ACCELEROMETER, the listener callback to the `read_accelerometer()` function, and the callback opaque argument to the LISTENER_CB value.
-
-**Note**: We define LISTENER_CB and READ_CB values because we also use the `read_accelerometer()` function as the callback for the `sensor_read()` function later in the tutorial. The LISTENER_CB or the READ_CB value is passed to the `read_accelerometer()` function to indicate whether it is invoked as a listener or a `sensor_read()` callback.
-
-```c
-
-#define LISTENER_CB 1
-#define READ_CB 2
-
-static int read_accelerometer(struct sensor* sensor, void *arg, void *databuf, sensor_type_t type);
-
-static struct sensor_listener listener = {
- .sl_sensor_type = SENSOR_TYPE_ACCELEROMETER,
- .sl_func = read_accelerometer,
- .sl_arg = (void *)LISTENER_CB,
-};
-
-```
-
-<br>
-4. Add the code for the `read_accelerometer()` function. The sensor data is stored in the `databuf` and `type` specifies the type of sensor data.
-
-```c
-
-static int
-read_accelerometer(struct sensor* sensor, void *arg, void *databuf, sensor_type_t type)
-{
-
- char tmpstr[13];
- struct sensor_accel_data *sad;
-
- if (!databuf) {
- return SYS_EINVAL;
-
- }
- sad = (struct sensor_accel_data *)databuf;
-
- if (!sad->sad_x_is_valid ||
- !sad->sad_y_is_valid ||
- !sad->sad_z_is_valid) {
-
- return SYS_EINVAL;
- }
-
- console_printf("%s: [ secs: %ld usecs: %d cputime: %u ]\n",
- ((int)arg == LISTENER_CB) ? "LISTENER_CB" : "READ_CB",
- (long int)sensor->s_sts.st_ostv.tv_sec,
- (int)sensor->s_sts.st_ostv.tv_usec,
- (unsigned int)sensor->s_sts.st_cputime);
-
- console_printf("x = %s ", sensor_ftostr(sad->sad_x, tmpstr, 13));
- console_printf("y = %s ", sensor_ftostr(sad->sad_y, tmpstr, 13));
- console_printf("z = %s\n\n", sensor_ftostr(sad->sad_z, tmpstr, 13));
- return 0;
-}
-
-```
-
-<br>
-5. Set the poll rate for the sensor to two seconds. The `sensor_set_poll_rate_ms()` function sets the poll rate for a named sensor.
-
-**Note:** You set the poll rate for a sensor programmatically and must set the poll rate to a non zero value in order for the sensor manager to poll the sensor. You may set a different poll rate for each sensor. The sensor framework also defines a `SENSOR_MGR_WAKEUP_RATE` syscfg setting that specifies the default rate that the sensor manager polls. The sensor manager uses the poll rate for a sesnor if a sensor is configured to poll more frequently than the `SENSOR_MGR_WAKEUP_RATE` setting value.
-
-```hl_lines="1 2 7 13 14"
-
-#define MY_SENSOR_DEVICE "lis2dh12_0"
-#define MY_SENSOR_POLL_TIME 2000
-
-int
-main(int argc, char **argv)
-{
- int rc
- ...
-
- /* Initialize all packages. */
- sysinit();
-
- rc = sensor_set_poll_rate_ms(MY_SENSOR_DEVICE, MY_SENSOR_POLL_TIME);
- assert(rc == 0);
-
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-
- return 0;
-}
-
-```
-
-<br>
-6. Look up the sensor by name to get the handle for the sensor and register a listener for the sensor.
-
-```hl_lines="9 10 11 12"
-
-int
-main(int argc, char **argv)
-{
- ...
-
- rc = sensor_set_poll_rate_ms(MY_SENSOR_DEVICE, MY_SENSOR_POLL_TIME);
- assert(rc == 0);
-
- my_sensor = sensor_mgr_find_next_bydevname(MY_SENSOR_DEVICE, NULL);
- assert(my_sensor != NULL);
- rc = sensor_register_listener(my_sensor, &listener);
- assert(rc == 0);
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-
- return 0;
-}
-
-```
-
-<br>
-#### Step 2: Rebuilding the Application and Connecting to Console
-
-<br>
-1. Run the `newt run` command to rebuild the application, create a new image, load the image, and start a GDB process:
-
-```no-highlight
-
-$ newt run thingy_my_sensor 2.0.0
-Compiling apps/my_sensor_app/src/main.c
-Archiving apps_my_sensor_app.a
-Linking ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf
-App image succesfully generated: ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.img
-Loading app image into slot 1
-[~/dev/myproj/repos/apache-mynewt-core/hw/bsp/nrf52-thingy/nrf52-thingy_debug.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/nrf52-thingy ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app]
-Debugging ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf
-GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
-
- ...
-
-Reading symbols from ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf...done.
-os_tick_idle (ticks=12)
- at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_os_tick.c:204
-204 if (ticks > 0) {
-Resetting target
-0x000000dc in ?? ()
-(gdb) c
-Continuing.
-
-```
-<br>
-2. Connect to the console via RTT:
-
-```no-highlight
-
-$ telnet localhost 19021
-
-Connected to localhost.
-Escape character is '^]'.
-SEGGER J-Link V6.14h - Real time terminal output
-J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 2 2017 12:22:13 V1.0, SN=682562963
-Process: JLinkGDBServer
-000003 LISTENER_CB: [ secs: 0 usecs: 23407 cputime: 331783 ]
-000003 x = 117.67980192 y = -19.61330035 z = -9885.103515
-
-000259 LISTENER_CB: [ secs: 2 usecs: 21190 cputime: 2327645 ]
-000259 x = 117.67980192 y = -9.806650176 z = -9914.523437
-
-000515 LISTENER_CB: [ secs: 4 usecs: 17032 cputime: 4323487 ]
-000515 x = 78.453201280 y = 0.000000000 z = -9924.330078
-
-000771 LISTENER_CB: [ secs: 6 usecs: 13131 cputime: 6319586 ]
-000771 x = 117.67980192 y = -19.61330035 z = -9914.523437
-
-001027 LISTENER_CB: [ secs: 8 usecs: 8810 cputime: 8315265 ]
-001027 x = 127.48645020 y = 0.000000000 z = -9924.330078
-
-001283 LISTENER_CB: [ secs: 10 usecs: 4964 cputime: 10311419 ]
-001283 x = 58.839900992 y = -9.806650176 z = -9885.103515
-
-```
-
-You should see the accelerometer sensor data output from the listener callback.
-
-<br>
-#### Step 3: Modifying main.c to Use sensor_read() Instead of a Listener
-
-Lets extend the application to use the `sensor_read()` function instead of a listener. We setup an OS callout to call the `sensor_read()` function for illustration purposes. A real application will most likely read the sensor data when it gets a request or some other event.
-
-<br>
-1. Add an OS callout and initialize an OS timer to fire every 5 seconds. The timer callback calls the `sensor_read()` function to read the sensor data. The `read_accelerometer()` callback is called when the sensor data is read. The READ_CB value is passed to the `read_accelerometer()` function and indicates that the callback is from the `sensor_read()` function and not from the listener.
-
-```c
-/*
- * Event callback function for timer events. The callback reads the sensor data
- */
-
-#define READ_SENSOR_INTERVAL (5 * OS_TICKS_PER_SEC)
-
-static struct os_callout sensor_callout;
-
-static void
-timer_ev_cb(struct os_event *ev)
-{
-
-
- assert(ev != NULL);
-
- /*
- * Read the accelerometer sensor. Pass the READ_CB value for the callback opaque
- * arg to indicate that it is the sensor_read() callback.
- */
- sensor_read(my_sensor, SENSOR_TYPE_ACCELEROMETER, read_accelerometer,
- (void *)READ_CB, OS_TIMEOUT_NEVER);
- os_callout_reset(&sensor_callout, READ_SENSOR_INTERVAL);
- return;
-}
-
-
-static void
-init_timer(void)
-{
- /*
- * Initialize the callout for a timer event.
- */
- os_callout_init(&sensor_callout, os_eventq_dflt_get(),
- timer_ev_cb, NULL);
-
- os_callout_reset(&sensor_callout, READ_SENSOR_INTERVAL);
- return;
-
-}
-
-```
-
-<br>
-2. Remove the listener registration and call the `init_timer()` function in `main()`. You can delete the `sensor_register_listener()` function call, but we call the `sensor_unregister_listener()` function to illustrate how to use this function.
-
-
-```hl_lines="10 11 13"
-
-int
-main(int argc, char **argv)
-{
- ...
-
- assert(my_sensor != NULL);
- rc = sensor_register_listener(my_sensor, &listener);
- assert(rc == 0);
-
- rc = sensor_unregister_listener(my_sensor, &listener);
- assert(rc == 0);
-
- init_timer();
-
- /* As the last thing, process events from default event queue. */
- while (1) {
- os_eventq_run(os_eventq_dflt_get());
- }
-
- return 0;
-}
-
-```
-
-<br>
-#### Step 4: Rebuilding the Application and Connecting to Console
-<br>
-1. Run the `newt run` command to rebuild the application, create an new image, and start a GDB process:
-
-```no-highlight
-
-$ newt run thingy_my_sensor 3.0.0
-Compiling apps/my_sensor_app/src/main.c
-Archiving apps_my_sensor_app.a
-Linking ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf
-App image succesfully generated: ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.img
-Loading app image into slot 1
-[~/dev/myproj/repos/apache-mynewt-core/hw/bsp/nrf52-thingy/nrf52-thingy_debug.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/nrf52-thingy ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app]
-Debugging ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf
-GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
-
- ...
-
-Reading symbols from ~/dev/myproj/bin/targets/thingy_my_sensor/app/apps/my_sensor_app/my_sensor_app.elf...done.
-os_tick_idle (ticks=12)
- at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_os_tick.c:204
-204 if (ticks > 0) {
-Resetting target
-0x000000dc in ?? ()
-(gdb) c
-Continuing.
-
-```
-
-<br>
-3. Connect to the console via RTT:
-
-```no-highlight
-
-$ telnet localhost 19021
-Trying ::1...
-telnet: connect to address ::1: Connection refused
-Trying 127.0.0.1...
-Connected to localhost.
-Escape character is '^]'.
-SEGGER J-Link V6.14h - Real time terminal output
-J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 2 2017 12:22:13 V1.0, SN=682562963
-Process: JLinkGDBServer
-
-
-000629 compat> READ_CB: [ secs: 5 usecs: 4088 cputime: 5295643 ]
-000642 x = 98.066497804 y = 0.000000000 z = -9806.650390
-
-001282 READ_CB: [ secs: 9 usecs: 992459 cputime: 10284014 ]
-001282 x = 117.67980192 y = -39.22660064 z = -9894.910156
-
-001922 READ_CB: [ secs: 14 usecs: 981159 cputime: 15272714 ]
-001922 x = 78.453201280 y = -29.41995049 z = -9885.103515
-
-002562 READ_CB: [ secs: 19 usecs: 970088 cputime: 20261643 ]
-002562 x = 107.87315366 y = -29.41995049 z = -9885.103515
-
-
-```
-
-You should see the accelerometer sensor data output from the sensor read data callback.
-
diff --git a/docs/os/tutorials/sensors/sensors.md b/docs/os/tutorials/sensors/sensors.md
deleted file mode 100644
index a4424c0..0000000
--- a/docs/os/tutorials/sensors/sensors.md
+++ /dev/null
@@ -1,43 +0,0 @@
-## Sensor Tutorials Overview
-
-This set of sensor tutorials allows you to explore the Mynewt Sensor Framework features and learn how to develop sensor-enabled Mynewt applications.
-
-The Mynewt Sensor framework supports:
-
-* Onboard and off-board sensors.
-* Retrieving sensor data and controlling sensor devices via the Mynewt OS Shell.
-* Retrieving sensor data over the OIC protocol and BLE transport.
-
-### Available Tutorials
-
-The tutorials are:
-
-* [Enabling an Off-Board Sensor in an Existing Application](/os/tutorials/sensors/sensor_nrf52_bno055.md) - This is an introductory tutorial that shows you to how to quickly bring up a sensor enabled application that retrieves data from a sensor device. We recommend that you work through this tutorial before trying one of the other tutorials.
-
-* [Changing the Default Configuration for a Sensor](/os/tutorials/sensors/sensor_offboard_config.md) - This tutorial shows you how to change the default configuration values for a sensor.
-
-* [Developing an Application for an Onboard Sensor](/os/tutorials/sensors/sensor_thingy_lis2dh12_onb.md) - This tutorial shows you how to develop a simple application for a device with an onboard sensor.
-
-* [Enabling OIC Sensor Data Monitoring in an Existing Application](/os/tutorials/sensors/sensor_oic_overview.md) - This tutorial shows you how to enable support for sensor data monitoring via OIC in an existing application.
-
-### Mynewt Smart Device Controller OIC App
-
-We use the `Mynewt Sensor Monitor` App on iOS or Android to retrieve and display sensor data from the Mynewt OS OIC sensor applications described in the OIC Sensor Data Monitoring tutorials. You can download the app from either the Apple Store or Google Play Store.
-
-**Note:** At the time of writing this tutorial, the iOS app was still in the queue waiting to be placed in the App Store. You can build the iOS app from source as indicated below.
-
-If you would like to contribute or modify the Mynewt Smart Device Controller App, see the [Android Sensor source](https://github.com/runtimeco/android_sensor) and [iOS Sensor source](https://github.com/runtimeco/iOS_oic) on github.
-
-<br>
-### Prerequisites
-Ensure that you meet the following prerequisites before continuing with one of the tutorials.
-
-* Have Internet connectivity to fetch remote Mynewt components.
-* Have a computer to build a Mynewt application and connect to the board over USB.
-* Have a Micro-USB cable to connect the board and the computer.
-* Install the newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
-* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
-* Create a project space (directory structure) and populate it with the core code repository (apache-mynewt-core) explained in [Creating Your First Project](/os/get_started/project_create).
-* Work through one of the [Blinky Tutorials](/os/tutorials/blinky.md).
-<br>
-
diff --git a/docs/os/tutorials/tasks_lesson.md b/docs/os/tutorials/tasks_lesson.md
deleted file mode 100644
index bb12e45..0000000
--- a/docs/os/tutorials/tasks_lesson.md
+++ /dev/null
@@ -1,247 +0,0 @@
-
-# Tasks and Priority Management
-**Target Platform: Arduino M0 Pro** (or legacy Arduino Zero or Zero Pro, but not Arduino M0)
-
-This lesson is designed to teach core OS concepts and strategies encountered when
-building applications using Mynewt. Specifically, this lesson will cover tasks,
-simple multitasking, and priority management running on an Arduino M0 Pro.
-
-## Prerequisites
-Before starting, you should read about Mynewt in the [*Introduction*](http://mynewt.apache.org/os/introduction/)
-section and complete the [*QuickStart*](http://mynewt.apache.org/os/get_started/get_started/)
-guide and the [*Blinky*](http://mynewt.apache.org/os/tutorials/arduino_zero/) tutorial.
-Furthermore, it may be helpful to take a peek at the [*task documentation*](http://mynewt.apache.org/os/core_os/task/task/)
-for additional insights.
-
-## Equipment
-You will need the following equipment:
-
-- Arduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0)
-- Computer with Mynewt installed
-- USB to Micro USB Cable
-
-## Build Your Application
-To save time, we will simply modify the Blinky application. We'll add the Task Management code to
-the Blinky application. Follow the [*Arduino Zero Blinky tutorial*](http://mynewt.apache.org/os/tutorials/arduino_zero/)
-to create a new project and build your bootloader and application. Finally, build and
-load the application to your Arduino to verify that everything is in order. Now let’s get started!
-
-## Default Main Task
-During Mynewt system startup, Mynewt creates a default main task and executes the application `main()` function in the context of this task. The main task priority defaults to 127 and can be configured with the `OS_MAIN_TASK_PRIO` system configuration setting.
-
-
-The blinky application only has the `main` task. The `main()` function executes an infinite loop that toggles the led and sleeps for one second.
-<br>
-##Create a New Task
-
-The purpose of this section is to give an introduction to the important aspects of tasks
-and how to properly initialize them. First, let’s define a second task called `work_task`
-in main.c (located in apps/blinky/src):
-
-```c
-struct os_task work_task;
-```
-
-A task is represented by the [*os_task*](http://mynewt.apache.org/os/core_os/task/task/#data-structures)
-struct which will hold the task’s information (name, state, priority, etc.). A task is made up of two
-main elements, a task function (also known as a task handler) and a task stack.
-
-Next, let’s take a look at what is required to initialize our new task.
-
-### Task Stack
-The task stack is an array of type `os_stack_t` which holds the program stack frames. Mynewt gives
-us the ability to set the stack size for a task giving the application developer room to optimize
-memory usage. Since we’re not short on memory, our `work_stack` is plenty large
-for the purpose of this lesson. Notice that the elements in our task stack are of type `os_stack_t`
-which are generally 32 bits, making our entire stack 1024 Bytes.
-
-```c
- #define WORK_STACK_SIZE OS_STACK_ALIGN(256)
-```
-
-
-Note: The `OS_STACK_ALIGN` macro is used to align the stack based on the hardware architecture.
-
-### Task Function
-
-A task function is essentially an infinite loop that waits for some “event” to wake it up. In general, the task function is where the majority of work is done by a task. Let’s write a task function for `work_task` called `work_task_handler()`:
-
-```c
-void
-work_task_handler(void *arg)
-{
- struct os_task *t;
-
- g_led_pin = LED_BLINK_PIN;
- hal_gpio_init_out(g_led_pin, 1);
-
- while (1) {
- t = os_sched_get_current_task();
- assert(t->t_func == work_task_handler);
- /* Do work... */
- }
-}
-```
-
-The task function is called when the task is initially put into the *running* state by the scheduler.
-We use an infinite loop to ensure that the task function never returns. Our assertion that the current
-task's handler is the same as our task handler is for illustration purposes only and does not need to
-be in most task functions.
-
-### Task Priority
-As a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher
-priority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we
-must choose a priority defined as a macro variable.
-
-Let’s set the priority of `work_task` to 0, because everyone knows that work is more important than blinking.
-```c
- #define WORK_TASK_PRIO (0)
-```
-
-### Initialization
-To initialize a new task we use [*os_task_init()*](http://mynewt.apache.org/os/core_os/task/os_task_init/)
-which takes a number of arguments including our new task function, stack, and priority.
-
-Add the `init_tasks()` function to initialize `work_task` to keep our main function clean.
-
-```c
-int
-init_tasks(void)
-{
- /* … */
- os_stack_t *work_stack;
- work_stack = malloc(sizeof(os_stack_t)*WORK_STACK_SIZE);
-
- assert(work_stack);
- os_task_init(&work_task, "work", work_task_handler, NULL,
- WORK_TASK_PRIO, OS_WAIT_FOREVER, work_stack,
- WORK_STACK_SIZE);
-
- return 0;
-}
-```
-<br>
-
-Add the call to `init_tasks()` in `main()` before the `while` loop:
-
-```c
-
-int
-main(int argc, char **argv)
-{
-
- ...
-
- /* Initialize the work task */
- init_tasks();
-
- while (1) {
- ...
- }
-}
-```
-
-<br>
-And that’s it! Now run your application using the newt run command.
-```
-$ newt run arduino_blinky 0.0.0
-```
-<br>
-When GDB appears press C then Enter to continue and … *wait, why doesn't our LED blink anymore?*
-
-<br>
-#### Review
-Before we run our new app, let’s review what we need in order to create a task. This is a general case for a new task called mytask:
-
- **1)** Define a new task, task stack, and priority:
-```c
-/* My Task */
-struct os_task mytask
-/* My Task Stack */
-#define MYTASK_STACK_SIZE OS_STACK_ALIGN(256)
-os_stack_t mytask_stack[MYTASK_STACK_SIZE];
-/* My Task Priority */
-#define MYTASK_PRIO (0)
-```
-**2)** Define task function:
-```c
-void
-mytask_handler(void *arg)
-{
- while (1) {
- /* ... */
- }
-}
-```
-**3)** Initialize the task:
-```c
-os_task_init(&mytask, "mytask", mytask_handler, NULL,
- MYTASK_PRIO, OS_WAIT_FOREVER, mytask_stack,
- MYTASK_STACK_SIZE);
-```
-
-## Task Priority, Preempting, and Context Switching
-
-A preemptive RTOS is one in which a higher priority task that is *ready to run* will preempt (i.e. take the
-place of) the lower priority task which is *running*. When a lower priority task is preempted by a higher
-priority task, the lower priority task’s context data (stack pointer, registers, etc.) is saved and the new
-task is switched in.
-
-In our example, `work_task` (priority 0) has a higher priority than the `main` task (priority 127). Since `work_task` is never put into a *sleep* state, it holds the processor focus on its context.
-
-Let’s give `work_task` a delay and some simulated work to keep it busy. The delay is measured in os ticks and the actual number of ticks per second is dependent on the board. We multiply `OS_TICKS_PER_SEC`, which is defined in the MCU, by the number of seconds we wish to delay.
-
-```c
-void
-work_task_handler(void *arg)
-{
- struct os_task *t;
-
- g_led_pin = LED_BLINK_PIN;
- hal_gpio_init_out(g_led_pin, 1);
-
- while (1) {
- t = os_sched_get_current_t:ask();
- assert(t->t_func == work_task_handler);
- /* Do work... */
- int i;
- for(i = 0; i < 1000000; ++i) {
- /* Simulate doing a noticeable amount of work */
- hal_gpio_write(g_led_pin, 1);
- }
- os_time_delay(3 * OS_TICKS_PER_SEC);
- }
-}
-```
-<br>
-In order to notice the LED changing, modify the time delay in `main()` to blink at a higher frequency.
-
-```c
-os_time_delay(OS_TICKS_PER_SEC/10);
-```
-<br>
-Before we run the app, let’s predict the behavior. With the newest additions to `work_task_handler()`,
-our first action will be to sleep for three seconds. This allows the `main` task, running `main()`, to take over the CPU and blink to its heart’s content. After three seconds, `work_task` will wake up and be made *ready to run*.
-This causes it to preempt the `main` task. The LED will then remain lit for a short period while `work_task`
-loops, then blink again for another three seconds while `work_task` sleeps.
-
-You should see that our prediction was correct!
-
-
-### Priority Management Considerations
-When projects grow in scope, from blinking LEDs into more sophisticated applications, the number of
-tasks needed increases alongside complexity. It remains important, then, that each of our tasks is
-capable of doing its work within a reasonable amount of time.
-
-Some tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore,
-the Shell task should be given a high priority. On the other hand, tasks which may be communicating over
-a network, or processing data, should be given a low priority in order to not hog the CPU.
-
-The diagram below shows the different scheduling patterns we would expect when we set the `work_task` priority higher and lower than the `main` task priority.
-
-
-
-In the second case where the `main` task has a higher priority, `work_task` runs and executes “work” when
-the `main` task sleeps, saving us idle time compared to the first case.
-
-**Note:** Defining the same priority for two tasks fires an assert in os_task_init() and must be avoided. Priority 127 is reserved for main task, 255 for idle task.
diff --git a/docs/os/tutorials/try_markdown.md b/docs/os/tutorials/try_markdown.md
deleted file mode 100644
index e35707c..0000000
--- a/docs/os/tutorials/try_markdown.md
+++ /dev/null
@@ -1,32 +0,0 @@
-## Try Markdown
-
-### Heading3
-
-#### Heading4
-
-- - -
-
-##### List
-
-* Start with one # for the largest heading (Heading1). The next smaller heading (Heading2) starts with ##. You can go all the way up to Heading 6 (######).
-
-* Heading4 (####) and Heading5 (#####) has been styled to show up underlined. Yes, it can be changed. If you are curious, you can look at the extra.css file in your repo branch.
-
-* It's **very** easy to do **bold** and *italics*.
-
-* See how this list has been made using *
-
-* Click on "Help" in Mou and then on "Markdown Syntax Reference".
-
-* <font color="red"> Substitute a sentence of your own here </font>
-
-* <font color="red"> Guinea Pig!!! </font>
-
----
-
-> <font color="red"> Note! </font>
->> You will not be able to see the change immediately by refreshing your browser right after editign the Markdown file. You can only push the change to the Apache repository. So continue with the steps in [how_to_edit_docs.md](how_to_edit_docs.md).
->>
->> You can see the change on the website if/when a doc builder on the project team merges your changes to the master branch and generates the pages for the website.
->>
->> You do have the option to download MkDocs and preview the change by hosting the pages locally using its built-in web server. The steps are described in [how_to_edit_docs.md](how_to_edit_docs.md).
diff --git a/docs/os/tutorials/tutorials.md b/docs/os/tutorials/tutorials.md
deleted file mode 100644
index 2ced955..0000000
--- a/docs/os/tutorials/tutorials.md
+++ /dev/null
@@ -1,82 +0,0 @@
-## Tutorials
-
-If the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner.
-
-The full list of tutorials can be seen in the navigation bar on the left. New ones are being constantly added and will show up there automatically.
-
-<br>
-
-### Prerequisites:
-
-* You have installed Docker container of Newt tool and toolchains or you have installed them natively on your machine
-* You have created a new project space (directory structure) and populated it with the core code repository (apache-mynewt-core) or know how to as explained in [Creating Your First Project](../get_started/project_create).
-* You have at least one of the supported development boards:
- * [Arduino Zero hardware](arduino_zero.md)
- * [Olimex/STM32F407ZGT6 Cortex-M4 hardware](olimex.md)
- * [nRF52 Development Kit from Nordic Semiconductor](nRF52.md)
-
-The Nordic nrf52 developer kit supports Bluetooth Low Energy. We are always looking to add new hardware to the list, so if you want to develop the required Board Support Package (bsp) and/or Hardware Abstraction Layer (HAL) for a new board, you can look [here](../core_os/porting/port_os/) to get started.
-
-
-<br>
-
-### Tutorial categories:
-
-The tutorials fall into a few broad categories. Some examples in each category are listed below.
-
-* Making an LED Blink (the "Hello World" equivalent in the electronics world)
- * [Blinky on Arduino Zero hardware](arduino_zero.md)
- * [Blinky on Olimex/STM32F407ZGT6 Cortex-M4 hardware](olimex.md)
- * [Blinky on nRF52 Development Kit from Nordic Semiconductor](nRF52.md) **Note:** This supports BLE.
- * [Blinky on Redbear Nano2](rbnano2.md)
-
-<br>
-
-* Navigating the Code and Adding Functionality
- * [Adding More Repositories to Your Project](repo/add_repos.md)
- * [Adding a Unit Test For a Package](unit_test.md)
-
-<br>
-
-* Using Newtmgr
- * [Enabling Remote Communication With a Device Running Mynewt OS](project-slinky.md)
-
-<br>
-
-* Bluetooth Low Energy
- * [Building a Bare Bones BLE Application](ble_bare_bones.md)
- * [Building a BLE iBeacon Application](ibeacon.md)
-
-<br>
-
-* OS Fundamentals
- * [Events and Event Queues](event_queue.md)
- * [Task and Priority Management](tasks_lesson.md)
-
-<br>
-
-* Remote Device Management
- * [Enabling Newt Manager in Any App](add_newtmgr.md)
- * [Upgrading an Image Over-The-Air](ota_upgrade_nrf52.md)
-
-<br>
-
-* Sensors
- * [Enabling an Off-Board Sensor in an Existing Application](sensors/sensor_nrf52_bno055.md)
- * [Developing an Application for an Onboard Sensor](sensors/sensor_thingy_lis2dh12_onb.md)
- * [Enabling OIC Sensor Data Monitoring](sensors/sensor_oic_overview.md)
-
-<br>
-
-* Tooling
- * [SEGGER RTT](segger_rtt.md)
- * [SEGGER SystemView](segger_sysview.md)
-
-<br>
-
-
-
-**Send us an email on the dev@ mailing list if you have comments or suggestions!** If you haven't joined the mailing list, you will find the links [here](../../community.md).
-
-<br>
-
diff --git a/docs/os/tutorials/unit_test.md b/docs/os/tutorials/unit_test.md
deleted file mode 100644
index 7b94709..0000000
--- a/docs/os/tutorials/unit_test.md
+++ /dev/null
@@ -1,331 +0,0 @@
-# Write a Test Suite for a Package
-
-This document guides the reader through creating a test suite for a Mynewt package.
-
-## Introduction
-
-Writing a test suite involves using the
-[`test/testutil`](../modules/testutil/testutil.md) package. The testutil
-library provides the functionality needed to define test suites and test cases.
-
-## Choose Your Package Under Test
-
-Choose the package you want to write a test suite for. In this tutorial, we
-will use the `time/datetime` in the apache-mynewt-core repo. Throughout this
-tutorial, we will be inside the apache-mynewt-core repo directory, unlike most
-tutorials which operate from the top-level project directory.
-
-## Create A Test Package
-
-Typically, a library has only one test package. The convention is name the
-test package by appending `/test` to the host library name. For example, the
-test package for `encoding/json` is `encoding/json/test`. The directory
-structure of the json package is shown below:
-
-```c
-encoding/json
-├── include
-│ └── json
-│ └── json.h
-├── pkg.yml
-├── src
-│ ├── json_decode.c
-│ └── json_encode.c
-└── test
- ├── pkg.yml
- └── src
- ├── test_json.c
- ├── test_json.h
- ├── test_json_utils.c
- └── testcases
- ├── json_simple_decode.c
- └── json_simple_encode.c
-```
-
-The top-level `test` directory contains the json test package. To create a
-test package for the datetime package, we need to create a similar package
-called `time/datetime/test`.
-
-```
-$ newt pkg new time/datetime/test -t unittest
-Download package template for package type pkg.
-Package successfuly installed into /home/me/mynewt-core/time/datetime/test.
-```
-
-We now have a test package inside `time/datetime`:
-
-```
-time/datetime
-├── include
-│ └── datetime
-│ └── datetime.h
-├── pkg.yml
-├── src
-│ └── datetime.c
-└── test
- ├── README.md
- ├── pkg.yml
- ├── src
- │ └── main.c
- └── syscfg.yml
-```
-
-There is one modification we need to make to the new package before we can
-start writing unit test code. A test package needs access to the code it will
-be testing, so we need to add a dependency on
-`@apache-mynewt-core/time/datetime` to our `pkg.yml` file:
-
-``` hl_lines="10"
-pkg.name: "time/datetime/test"
-pkg.type: unittest
-pkg.description: "Description of your package"
-pkg.author: "You <you@you.org>"
-pkg.homepage: "http://your-url.org/"
-pkg.keywords:
-
-pkg.deps:
- - '@apache-mynewt-core/test/testutil'
- - '@apache-mynewt-core/time/datetime'
-
-pkg.deps.SELFTEST:
- - '@apache-mynewt-core/sys/console/stub'
-```
-
-While we have the `pkg.yml` file open, let's take a look at what newt filled in automatically:
-
-* `pkg.type: unittest` designates this as a test package. A *test package* is
- special in that it can be built and executed using the `newt test` command.
-* A test package always depends on `@apache-mynewt-core/test/testutil`. The
- testutil library provides the tools necessary for verifying package behavior,
-* The `SELFTEST` suffix indicates that a setting should only be applied when the `newt test` command is used.
-
-Regarding the conditional dependency on `sys/console/stub`, the datetime
-package requires some form of console to function. In a regular application,
-the console dependency would be supplied by a higher order package. Because
-`newt test` runs the test package without an application present, the test
-package needs to supply all unresolved dependencies itself when run in
-self-test mode.
-
-## Create Your Test Suite Code
-
-We will be adding a *test suite* to the `main.c` file. The test suite will be empty for now. We also need to invoke the test suite from `main()`.
-
-Our `main.c` file now looks like this:
-
-```c
-#include "sysinit/sysinit.h"
-#include "testutil/testutil.h"
-
-TEST_SUITE(test_datetime_suite) {
- /* Empty for now; add test cases later. */
-}
-
-#if MYNEWT_VAL(SELFTEST)
-int
-main(int argc, char **argv)
-{
- /* Initialize all packages. */
- sysinit();
-
- test_datetime_suite();
-
- /* Indicate whether all test cases passed. */
- return tu_any_failed;
-}
-#endif
-```
-
-## Try It Out
-
-We now have a working test suite with no tests. Let's make sure we get a passing result when we run `newt test`:
-
-```
-$ newt test time/datetime
-<build output>
-Executing test: /home/me/mynewt-core/bin/targets/unittest/time_datetime_test/app/time/datetime/test/time_datetime_test.elf
-Passed tests: [time/datetime/test]
-All tests passed
-```
-
-## Create a Test
-
-To create a test within your test suite, there are two things to do.
-
-1. Implement the test case function using the `testutil` macros.
-2. Call the test case function from within the test suite.
-
-For this tutorial we will create a test case to verify the `datetime_parse()`
-function. The `datetime_parse()` function is declared as follows:
-
-``` c
-/**
- * Parses an RFC 3339 datetime string. Some examples of valid datetime strings
- * are:
- * 2016-03-02T22:44:00 UTC time (implicit)
- * 2016-03-02T22:44:00Z UTC time (explicit)
- * 2016-03-02T22:44:00-08:00 PST timezone
- * 2016-03-02T22:44:00.1 fractional seconds
- * 2016-03-02T22:44:00.101+05:30 fractional seconds with timezone
- *
- * On success, the two output parameters are filled in (tv and tz).
- *
- * @return 0 on success;
- * nonzero on parse error.
- */
-int
-datetime_parse(const char *input, struct os_timeval *tv, struct os_timezone *tz)
-```
-
-Our test case should make sure this function rejects invalid input, and that it
-parses valid input correctly. The updated `main.c` file looks like this:
-
-``` c
-#include "sysinit/sysinit.h"
-#include "testutil/testutil.h"
-#include "os/os_time.h"
-#include "datetime/datetime.h"
-
-TEST_SUITE(test_datetime_suite)
-{
- test_datetime_parse_simple();
-}
-
-TEST_CASE(test_datetime_parse_simple)
-{
- struct os_timezone tz;
- struct os_timeval tv;
- int rc;
-
- /*** Valid input. */
-
- /* No timezone; UTC implied. */
- rc = datetime_parse("2017-06-28T22:37:59", &tv, &tz);
- TEST_ASSERT_FATAL(rc == 0);
- TEST_ASSERT(tv.tv_sec == 1498689479);
- TEST_ASSERT(tv.tv_usec == 0);
- TEST_ASSERT(tz.tz_minuteswest == 0);
- TEST_ASSERT(tz.tz_dsttime == 0);
-
- /* PDT timezone. */
- rc = datetime_parse("2013-12-05T02:43:07-07:00", &tv, &tz);
- TEST_ASSERT_FATAL(rc == 0);
- TEST_ASSERT(tv.tv_sec == 1386236587);
- TEST_ASSERT(tv.tv_usec == 0);
- TEST_ASSERT(tz.tz_minuteswest == 420);
- TEST_ASSERT(tz.tz_dsttime == 0);
-
- /*** Invalid input. */
-
- /* Nonsense. */
- rc = datetime_parse("abc", &tv, &tz);
- TEST_ASSERT(rc != 0);
-
- /* Date-only. */
- rc = datetime_parse("2017-01-02", &tv, &tz);
- TEST_ASSERT(rc != 0);
-
- /* Zero month. */
- rc = datetime_parse("2017-00-28T22:37:59", &tv, &tz);
- TEST_ASSERT(rc != 0);
-
- /* 13 month. */
- rc = datetime_parse("2017-13-28T22:37:59", &tv, &tz);
- TEST_ASSERT(rc != 0);
-}
-
-#if MYNEWT_VAL(SELFTEST)
-int
-main(int argc, char **argv)
-{
- /* Initialize all packages. */
- sysinit();
-
- test_datetime_suite();
-
- /* Indicate whether all test cases passed. */
- return tu_any_failed;
-}
-#endif
-```
-
-Take a few minutes to review the above code. Then keep reading for some
-specifics.
-
-### Asserting
-
-The `test/testutil` package provides two tools for verifying the correctness of a package:
-
-* `TEST_ASSERT`
-* `TEST_ASSERT_FATAL`
-
-Both of these macros check if the supplied condition is true. They differ in
-how they behave when the condition is not true. On failure, `TEST_ASSERT`
-reports the error and proceeds with the remainder of the test case.
-`TEST_ASSERT_FATAL`, on the other hand, aborts the test case on failure.
-
-The general rule is to only use `TEST_ASSERT_FATAL` when subsequent assertions
-depend on the condition being checked. For example, when `datetime_parse()` is
-expected to succeed, the return code is checked with `TEST_ASSERT_FATAL`. If
-`datetime_parse()` unexpectedly failed, the contents of the `tv` and `tz`
-objects would be indeterminate, so it is desirable to abort the test instead of
-checking them and reporting spurious failures.
-
-### Scaling Up
-
-The above example is small and self contained, so it is reasonable to put
-everything in a single C file. A typical package will need a lot more test
-code, and it helps to follow some conventions to maintain organization. Let's
-take a look at a more realistic example. Here is the directory structure of
-the `fs/nffs/test` package:
-
-```
-fs/nffs/test
-├── pkg.yml
-└── src
- ├── nffs_test.c
- ├── nffs_test.h
- ├── nffs_test_debug.c
- ├── nffs_test_priv.h
- ├── nffs_test_system_01.c
- ├── nffs_test_utils.c
- ├── nffs_test_utils.h
- └── testcases
- ├── append_test.c
- ├── cache_large_file_test.c
- ├── corrupt_block_test.c
- ├── corrupt_scratch_test.c
- ├── gc_on_oom_test.c
- ├── gc_test.c
- ├── incomplete_block_test.c
- ├── large_system_test.c
- ├── large_unlink_test.c
- ├── large_write_test.c
- ├── long_filename_test.c
- ├── lost_found_test.c
- ├── many_children_test.c
- ├── mkdir_test.c
- ├── open_test.c
- ├── overwrite_many_test.c
- ├── overwrite_one_test.c
- ├── overwrite_three_test.c
- ├── overwrite_two_test.c
- ├── read_test.c
- ├── readdir_test.c
- ├── rename_test.c
- ├── split_file_test.c
- ├── truncate_test.c
- ├── unlink_test.c
- └── wear_level_test.c
-```
-
-The `fs/nffs/test` package follows these conventions:
-
-1. A maximum of one test case per C file.
-2. Each test case file goes in the `testcases` subdirectory.
-3. Test suites and utility functions go directly in the `src` directory.
-
-Test packages contributed to the Mynewt project should follow these conventions.
-
-## Congratulations
-
-Now you can begin the work of validating your packages.
diff --git a/docs/os/tutorials/wi-fi_on_arduino.md b/docs/os/tutorials/wi-fi_on_arduino.md
deleted file mode 100644
index 255a3fe..0000000
--- a/docs/os/tutorials/wi-fi_on_arduino.md
+++ /dev/null
@@ -1,324 +0,0 @@
-## Enable Wi-Fi on Arduino MKR1000
-
-This tutorial shows you how to enable Wi-Fi on an Arduino MKR1000 board and connect to a Wi-Fi network.
-
-### Prerequisites
-
-Ensure that you have met the following prerequisites before continuing with this tutorial:
-
-* Have an Arduino MKR1000 board.
-* Have Internet connectivity to fetch remote Mynewt components.
-* Have a computer to build a Mynewt application and connect to the board over USB.
-* Have a Micro-USB cable to connect the board and the computer.
-* Have local Wi-Fi network that the computer is connected to and that the MKR1000 board can join.
-* Have a [Serial Port Setup](/os/get_started/serial_access.md).
-* Have a [Segger J-Link Debug Probe](https://www.segger.com/jlink-debug-probes.html).
-* Have a [J-Link 9 pin Cortex-M Adapter](https://www.segger.com/jlink-adapters.html#CM_9pin) that allows JTAG, SWD and SWO connections between J-Link and Cortex M based target hardware systems
-* Install the [Segger JLINK Software and documentation pack](https://www.segger.com/jlink-software.html).
-* Install the Newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
-* Create a project space (directory structure) and populated it with the core code repository (apache-mynewt-core) or know how to as explained in [Creating Your First Project](/os/get_started/project_create).
-* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
-
-
-### Create a Project
-Create a new project if you do not have an existing one. You can skip this step and proceed to [fetch external packages](#
-fetchexternal) if you already created a project.
-
-Run the following commands to create a new project:
-
-```no-highlight
- $ mkdir ~/dev
- $ cd ~/dev
- $ newt new arduinowifi
- Downloading project skeleton from apache/mynewt-blinky...
- Installing skeleton in arduinowifi...
- Project arduinowifi successfully created.
- $ cd arduinowifi
- $ newt install
- apache-mynewt-core
- $
-```
-
-<br>
-
-
-### <a name="fetchexternal"></a> Fetch External Packages
-
-Mynewt uses source code provided directly from the chip manufacturer for
-low level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in
-the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's git
-hub repository hosts such external third-party packages and the Newt tool can fetch them.
-
-To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add
-the repository to the `project.yml` file in your base project directory.
-
-
-Mynewt uses source code provided directly from the chip manufacturer for
-low level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's github repository hosts such external third-party packages and the Newt tool can fetch them.
-
-To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add
-the repository to the `project.yml` file in your base project directory (`arduinowifi`).
-
-Here is an example ```project.yml``` file with the Arduino Zero repository
-added. The sections with ```mynewt_arduino_zero``` that need to be added to
-your project file are highlighted.
-
-**Note:** On Windows platforms: You need to set `vers` to `0-dev` and use the latest master branch for both repositories.
-
-```hl_lines="6 14 15 16 17 18"
-$ more project.yml
-project.name: "my_project"
-
-project.repositories:
- - apache-mynewt-core
- - mynewt_arduino_zero
-
-repository.apache-mynewt-core:
- type: github
- vers: 1-latest
- user: apache
- repo: mynewt-core
-
-repository.mynewt_arduino_zero:
- type: github
- vers: 1-latest
- user: runtimeco
- repo: mynewt_arduino_zero
-$
-```
-
-<br>
-<br>
-Install the project dependencies using the `newt install` command (you can specify ```-v``` for verbose output):
-```no-highlight
-$ newt install
-apache-mynewt-core
-mynewt_arduino_zero
-$
-```
-
-**NOTE:** If there has been a new release of a repo used in your project since you last installed it, the `1-latest` version for the repo in the `project.yml` file will refer to the new release and will not match the installed files. In that case you will get an error message saying so and you will need to run `newt upgrade` to overwrite the existing files with the latest codebase.
-
-<br>
-
-### Create a Target for the Bootloader
-You need to create two targets for the MKR1000 board, one for the bootloader and one for the `winc1500_wifi` application.
-<br>
-Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `mkr1000_boot`.
-
-```no-highlight
-$ newt target create mkr1000_boot
-$ newt target set mkr1000_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_mkr1000
-$ newt target set mkr1000_boot app=@apache-mynewt-core/apps/boot
-$ newt target set mkr1000_boot build_profile=optimized
-$ newt target set mkr1000_boot syscfg=BSP_ARDUINO_ZERO_PRO=1
-```
-
-<br>
-
-### Create a Target for the Wi-Fi Application
-Run the following `newt target` commands to create a target for the `winc1500_wifi` application in the arduino repository. We name the application target `mkr1000_wifi`.
-
-```
-$ newt target create mkr1000_wifi
-$ newt target set mkr1000_wifi app=@mynewt_arduino_zero/apps/winc1500_wifi
-$ newt target set mkr1000_wifi bsp=@mynewt_arduino_zero/hw/bsp/arduino_mkr1000
-$ newt target set mkr1000_wifi build_profile=debug
-$ newt target set mkr1000_boot syscfg=BSP_ARDUINO_ZERO_PRO=1
-```
-<br>
-### Build the Bootloader
-
-Run the `newt build mkr1000_boot` command to build the bootloader:
-
-```no-highlight
-$ newt build mkr1000_boot
-Building target targets/mkr1000_boot
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
-
- ...
-
-Archiving util_mem.a
-Linking ~/dev/arduinowifi/bin/targets/mkr1000_boot/app/apps/boot/boot.elf
-Target successfully built: targets/mkr1000_boot
-$
-```
-
-<br>
-
-### Build the Wi-Fi Application
-
-Run the `newt build mkr1000_wifi` command to build the wi-fi application image:
-
-```no-highlight
-$newt build mkr1000_wifi
-Building target targets/mkr1000_wifi
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
-Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
- ...
-
-Archiving util_mem.a
-Linking ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.elf
-Target successfully built: targets/mkr1000_wifi
-$
-```
-<br>
-### Sign and Create the Wi-Fi Application Image
-
-Run the `newt create-image mkr1000_wifi 1.0.0` command to sign and create an image file for the Wi-Fi application. You may assign an arbitrary version (e.g. 1.0.0) number.
-
-
-```no-highlight
-$newt create-image mkr1000_wifi 1.0.0
-Compiling bin/targets/mkr1000_wifi/generated/src/mkr1000_wifi-sysinit-app.c
-Archiving mkr1000_wifi-sysinit-app.a
-Linking ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.elf
-App image succesfully generated: ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.img
-$
-```
-
-<br>
-
-### Connect to the Board
-
-* Connect your computer to the MKR1000 board with the Micro-USB cable.
-* Connect the debug probe to the JTAG port on the board using the Jlink 9-pin adapter and cable.
-
-<br>
-
-<br>
-<p>
-<br>
-Mynewt will download and debug the target through this port. You should see a green LED come on and indicates the board has power.
-
-<br>
-
-
-### Load the Bootloader onto the Board
-
-Run the `newt load mkr1000_boot` command to load the bootloader onto the board:
-
-```no-highlight
-$ newt load mkr1000_boot
-Loading bootloader
-$
-```
-<br>
-
-### Load the Wi-Fi Application Image onto the Board
-Run the `newt load mkr1000_wifi` command to load the wifi application onto the board:
-
-```no-highlight
-$ newt load mkr1000_wifi
-Loading app image into slot 1
-$
-```
-
-<br>
-### Setup a Serial Connection Between Your Computer and the Board
-
-Set up a serial connection from your computer to the MKR1000 board (See [Serial Port Setup](/os/get_started/serial_access.md)). On the MKR1000 board, the TX pin is PIN 14 and the RX pin in PIN 13.
-<br>
-<br>
-
-<br>
-<p>
-<br>
-<br>
-Locate the port, in the /dev directory on your computer, that the serial connection uses. The format of the port name is
- platform dependent:
-
-
-* Mac OS uses the format `tty.usbserial-<some identifier>`.
-* Linux uses the format `TTYUSB<N>`, where `N` is a number. For example, TTYUSB2.
-* MinGW on Windows uses the format `ttyS<N>`, where `N` is a number. You must map the port name to a Windows COM port: `
-/dev/ttyS<N>` maps to `COM<N+1>`. For example, `/dev/ttyS2` maps to `COM3`.
-
- You can also use the Windows Device Manager to find the COM port number.
-
-<br>
-```no-highlight
-$ ls /dev/tty*usbserial*
-/dev/tty.usbserial-1d13
-$
-```
-
-
-### Start Wi-Fi via console
-
-Use a terminal emulation program to communicate with the board over the serial port. This tutorial shows a Minicom set up. Run the minicom command with the serial port you located on your computer:
-
-**Note:** On Windows, you can use the PuTTY application.
-
-```no-highlight
-$ minicom -D /dev/tty.usbserial-1d13 -b 115200
-```
-<br>
-Type `wifi start` to start Wi-Fi.
-
-```hl_lines="11"
-
-Welcome to minicom 2.7.1
-
-OPTIONS:
-Compiled on May 17 2017, 15:29:14.
-Port /dev/tty.usbserial, 15:12:10
-
-Press Meta-Z for help on special keys
-
-
-138465 compat> wifi start
-144570 compat> (APP)(INFO)Chip ID 1503a0
-(APP)(INFO)Firmware ver : 19.4.4
-(APP)(INFO)Min driver ver : 19.3.0
-(APP)(INFO)Curr driver ver: 19.3.0
-wifi_init : 0
-
-```
-<br>
-Connect to the local Wi-Fi network. Note that the MKR1000 board only supports 2.4 GHz Wi-Fi networks.
-
-Run the `wifi connect` command and specify your network <ssid> and <password>. After you are connected to your wi-fi network, run the `net service` command to start network services.
-
-```hl_lines="2 9"
-
-wifi connect <ssid> <password>
-037624 wifi_request_scan : 0
-037627 compat> scan_results 7: 0
-038454 wifi_connect : 0
-039451 connect_done : 0
-039958 dhcp done 192.168.0.135
-040169 get sys time response 2017.7.12-22.41.33
-net service
-
-```
-
-The board is connected to the network succesfully and has IP address: 192.168.0.135
-
-### Establish TCP Connection and Talk!
-
-From a terminal on your computer, telnet to ports 7, 9, or 19 using the IP address your board has been assigned. Type something on this terminal and see the console output (on minicom). Can you see the difference in the behaviors?
-
-```no-highlight
-
-$telnet 192.168.0.135 7
-Trying 192.168.0.135...
-Connected to 192.168.0.135.
-Escape character is '^]'.
-hello
-hello
-^]
-telnet> q
-$
-
-```
-
-One port echoes whatever is typed, one discards everything it gets, and the third spews out bits constantly. Type `wifi stop` to disable WiFi on the Arduino board.
diff --git a/mkdocs.yml b/mkdocs.yml
index b0cb4a6..d8439fe 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -18,588 +18,6 @@
- Community: 'community.md'
- Events: 'events.md'
- Documentation: 'documentation.md'
-- Mynewt Documentation:
- - toc: 'os/introduction.md'
- - Basic Setup:
- - toc: 'os/get_started/get_started.md'
- - Native Install Option:
- - toc: 'os/get_started/native_install_intro.md'
- - 'Install Newt on Mac': 'newt/install/newt_mac.md'
- - 'Install Newt on Linux': 'newt/install/newt_linux.md'
- - 'Install Newt on Windows': 'newt/install/newt_windows.md'
- - 'Install Native Toolchain': 'os/get_started/native_tools.md'
- - 'Install Cross Tools for ARM': 'os/get_started/cross_tools.md'
- - 'Docker Container Option': 'os/get_started/docker.md'
- - 'Create Your First Project': 'os/get_started/project_create.md'
- - 'Serial Port Setup': 'os/get_started/serial_access.md'
- - Concepts: 'os/get_started/vocabulary.md'
- - Tutorials:
- - toc: 'os/tutorials/tutorials.md'
- - Project Blinky:
- - toc: 'os/tutorials/blinky.md'
- - 'Blinky on Arduino Zero': 'os/tutorials/arduino_zero.md'
- - 'Blinky on Arduino Primo': 'os/tutorials/blinky_primo.md'
- - 'Blinky on Olimex': 'os/tutorials/olimex.md'
- - 'Blinky on nRF52 DK': 'os/tutorials/nRF52.md'
- - 'Blinky on RedBear Nano 2': 'os/tutorials/rbnano2.md'
- - 'Blinky on STM32F4-Discovery': 'os/tutorials/blinky_stm32f4disc.md'
- - 'Add Console and Shell to Blinky': 'os/tutorials/blinky_console.md'
- - 'Work with repositories':
- - toc: 'os/tutorials/repo/add_repos.md'
- - 'Upgrade a Repo': 'os/tutorials/repo/upgrade_repo.md'
- - 'Turn project into a Repo': 'os/tutorials/repo/create_repo.md'
- - 'Access a private Repo': 'os/tutorials/repo/private_repo.md'
- - Project Slinky for Remote Comms:
- - toc: 'os/tutorials/project-slinky.md'
- - 'Slinky on sim device': 'os/tutorials/project-sim-slinky.md'
- - 'Slinky on Nordic nRF52': 'os/tutorials/project-nrf52-slinky.md'
- - 'Slinky on Olimex': 'os/tutorials/project-stm32-slinky.md'
- - Bluetooth Low Energy:
- - 'BLE Bare Bones Application': 'os/tutorials/ble_bare_bones.md'
- - 'BLE iBeacon': 'os/tutorials/ibeacon.md'
- - 'BLE Eddystone': 'os/tutorials/eddystone.md'
- - 'BLE Peripheral Project':
- - toc: 'os/tutorials/bleprph/bleprph-intro.md'
- - 'Service Registration': 'os/tutorials/bleprph/bleprph-svc-reg.md'
- - 'Characteristic Access': 'os/tutorials/bleprph/bleprph-chr-access.md'
- - 'Advertising': 'os/tutorials/bleprph/bleprph-adv.md'
- - 'GAP Event Callbacks': 'os/tutorials/bleprph/bleprph-gap-event.md'
- - 'BLE Peripheral App' : 'os/tutorials/bleprph/bleprph-app.md'
- - 'BLE HCI interface': 'os/tutorials/blehci_project.md'
- - LoRa:
- - 'LoraWAN app': 'os/tutorials/lora/lorawanapp.md'
- - OS Fundamentals:
- - 'Events and Event Queues': 'os/tutorials/event_queue.md'
- - 'Tasks and Priority Management': 'os/tutorials/tasks_lesson.md'
- - Remote Device Management:
- - 'Enable Newt Manager in any app': 'os/tutorials/add_newtmgr.md'
- - 'Upgrade an Image Over-The-Air': 'os/tutorials/ota_upgrade_nrf52.md'
- - 'Sensors':
- - Sensor Framework:
- - toc: 'os/tutorials/sensors/sensors.md'
- - 'Enable an Off-Board Sensor in an Existing Application': 'os/tutorials/sensors/sensor_nrf52_bno055.md'
- - 'Change the Default Configuration For a Sensor': 'os/tutorials/sensors/sensor_offboard_config.md'
- - 'Develop an Application for an Onboard Sensor': 'os/tutorials/sensors/sensor_thingy_lis2dh12_onb.md'
- - 'Enable OIC Sensor Data Monitoring':
- - toc: 'os/tutorials/sensors/sensor_oic_overview.md'
- - Enable OIC Sensor Support in the sensors_test Application: 'os/tutorials/sensors/sensor_nrf52_bno055_oic.md'
- - Add OIC Sensor Support to the bleprph_oic Application: 'os/tutorials/sensors/sensor_bleprph_oic.md'
- - 'Air-quality Sensor project':
- - 'Basic Air Quality Sensor': 'os/tutorials/air_quality_sensor.md'
- - 'BLE-enabled Air Quality Sensor': 'os/tutorials/air_quality_ble.md'
- - 'Add an Analog Sensor': 'os/tutorials/nrf52_adc.md'
- - 'Tooling':
- - 'Segger RTT': 'os/tutorials/segger_rtt.md'
- - 'Segger Sysview': 'os/tutorials/segger_sysview.md'
- - 'Other':
- - 'How to Reduce Application Code Size': 'os/tutorials/codesize.md'
- - 'Write a Test Suite for a Package': 'os/tutorials/unit_test.md'
- - 'Enable Wi-Fi on Arduino MKR1000': 'os/tutorials/wi-fi_on_arduino.md'
- - OS User Guide:
- - toc: 'os/os_user_guide.md'
- - OS Core:
- - toc: 'os/core_os/mynewt_os.md'
- - 'Functions':
- - 'os_started': 'os/core_os/os_started.md'
- - Scheduler:
- - toc: 'os/core_os/context_switch/context_switch.md'
- - 'Functions':
- - 'os_sched': 'os/core_os/context_switch/os_sched.md'
- - 'os_arch_ctx_sw': 'os/core_os/context_switch/os_arch_ctx_sw.md'
- - 'os_sched_ctx_sw_hook': 'os/core_os/context_switch/os_sched_ctx_sw_hook.md'
- - 'os_sched_get_current_task': 'os/core_os/context_switch/os_sched_get_current_task.md'
- - 'os_sched_insert': 'os/core_os/context_switch/os_sched_insert.md'
- - 'os_sched_next_task': 'os/core_os/context_switch/os_sched_next_task.md'
- - 'os_sched_os_timer_exp': 'os/core_os/context_switch/os_sched_os_timer_exp.md'
- - 'os_sched_remove': 'os/core_os/context_switch/os_sched_remove.md'
- - 'os_sched_resort': 'os/core_os/context_switch/os_sched_resort.md'
- - 'os_sched_set_current_task': 'os/core_os/context_switch/os_sched_set_current_task.md'
- - 'os_sched_sleep': 'os/core_os/context_switch/os_sched_sleep.md'
- - 'os_sched_wakeup': 'os/core_os/context_switch/os_sched_wakeup.md'
- - CPU Time:
- - toc: 'os/core_os/cputime/os_cputime.md'
- - 'Functions':
- - 'os_cputime_delay_nsecs': 'os/core_os/cputime/os_cputime_delay_nsecs.md'
- - 'os_cputime_delay_ticks': 'os/core_os/cputime/os_cputime_delay_ticks.md'
- - 'os_cputime_delay_usecs': 'os/core_os/cputime/os_cputime_delay_usecs.md'
- - 'os_cputime_get32': 'os/core_os/cputime/os_cputime_get32.md'
- - 'os_cputime_init': 'os/core_os/cputime/os_cputime_init.md'
- - 'os_cputime_nsecs_to_ticks': 'os/core_os/cputime/os_cputime_nsecs_to_ticks.md'
- - 'os_cputime_ticks_to_nsecs': 'os/core_os/cputime/os_cputime_ticks_to_nsecs.md'
- - 'os_cputime_ticks_to_usecs': 'os/core_os/cputime/os_cputime_ticks_to_usecs.md'
- - 'os_cputime_timer_init': 'os/core_os/cputime/os_cputime_timer_init.md'
- - 'os_cputime_timer_relative': 'os/core_os/cputime/os_cputime_timer_relative.md'
- - 'os_cputime_timer_start': 'os/core_os/cputime/os_cputime_timer_start.md'
- - 'os_cputime_timer_stop': 'os/core_os/cputime/os_cputime_timer_stop.md'
- - 'os_cputime_usecs_to_ticks': 'os/core_os/cputime/os_cputime_usecs_to_ticks.md'
- - OS Time:
- - toc: 'os/core_os/time/os_time.md'
- - 'Functions':
- - 'os_time_advance': 'os/core_os/time/os_time_advance.md'
- - 'os_time_delay': 'os/core_os/time/os_time_delay.md'
- - 'os_time_get': 'os/core_os/time/os_time_get.md'
- - 'os_time_ms_to_ticks': 'os/core_os/time/os_time_ms_to_ticks.md'
- - 'os_get_uptime_usec': 'os/core_os/time/os_get_uptime_usec.md'
- - 'os_gettimeofday': 'os/core_os/time/os_gettimeofday.md'
- - 'os_settimeofday': 'os/core_os/time/os_settimeofday.md'
- - Tasks:
- - toc: 'os/core_os/task/task.md'
- - 'Functions':
- - 'os_task_count': 'os/core_os/task/os_task_count.md'
- - 'os_task_info_get_next': 'os/core_os/task/os_task_info_get_next.md'
- - 'os_task_init': 'os/core_os/task/os_task_init.md'
- - 'os_task_remove': 'os/core_os/task/os_task_remove.md'
- - Event Queues:
- - toc: 'os/core_os/event_queue/event_queue.md'
- - 'Functions':
- - 'os_eventq_init': 'os/core_os/event_queue/os_eventq_init.md'
- - 'os_eventq_inited': 'os/core_os/event_queue/os_eventq_inited.md'
- - 'os_eventq_get': 'os/core_os/event_queue/os_eventq_get.md'
- - 'os_eventq_put': 'os/core_os/event_queue/os_eventq_put.md'
- - 'os_eventq_remove': 'os/core_os/event_queue/os_eventq_remove.md'
- - 'os_eventq_dflt_get': 'os/core_os/event_queue/os_eventq_dflt_get.md'
- - 'os_eventq_designate': 'os/core_os/event_queue/os_eventq_designate.md'
- - 'os_eventq_run': 'os/core_os/event_queue/os_eventq_run.md'
- - Semaphores:
- - toc: 'os/core_os/semaphore/semaphore.md'
- - 'Functions':
- - 'os_sem_init': 'os/core_os/semaphore/os_sem_init.md'
- - 'os_sem_pend': 'os/core_os/semaphore/os_sem_pend.md'
- - 'os_sem_release': 'os/core_os/semaphore/os_sem_release.md'
- - Mutexes:
- - toc: 'os/core_os/mutex/mutex.md'
- - 'Functions':
- - 'os_mutex_init': 'os/core_os/mutex/os_mutex_init.md'
- - 'os_mutex_pend': 'os/core_os/mutex/os_mutex_pend.md'
- - 'os_mutex_release': 'os/core_os/mutex/os_mutex_release.md'
- - Memory Pools:
- - toc: 'os/core_os/memory_pool/memory_pool.md'
- - 'Functions/Macros':
- - 'os_memblock_get': 'os/core_os/memory_pool/os_memblock_get.md'
- - 'os_mempool_info_get_next': 'os/core_os/memory_pool/os_mempool_info_get_next.md'
- - 'os_mempool_init': 'os/core_os/memory_pool/os_mempool_init.md'
- - 'os_memblock_put': 'os/core_os/memory_pool/os_memblock_put.md'
- - 'OS_MEMPOOL_BYTES': 'os/core_os/memory_pool/OS_MEMPOOL_BYTES.md'
- - 'OS_MEMPOOL_SIZE': 'os/core_os/memory_pool/OS_MEMPOOL_SIZE.md'
- - Heap:
- - toc: 'os/core_os/heap/heap.md'
- - 'Functions':
- - 'os_free': 'os/core_os/heap/os_free.md'
- - 'os_malloc': 'os/core_os/heap/os_malloc.md'
- - 'os_realloc': 'os/core_os/heap/os_realloc.md'
- - Memory Buffers:
- - Mbuf:
- - toc: 'os/core_os/mbuf/mbuf.md'
- - 'Functions/Macros':
- - 'OS_MBUF_PKTHDR': 'os/core_os/mbuf/OS_MBUF_PKTHDR.md'
- - 'OS_MBUF_PKTHDR_TO_MBUF': 'os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md'
- - 'OS_MBUF_PKTLEN': 'os/core_os/mbuf/OS_MBUF_PKTLEN.md'
- - 'OS_MBUF_DATA': 'os/core_os/mbuf/OS_MBUF_DATA.md'
- - 'OS_MBUF_USRHDR': 'os/core_os/mbuf/OS_MBUF_USRHDR.md'
- - 'OS_MBUF_USRHDR_LEN': 'os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md'
- - 'OS_MBUF_LEADINGSPACE': 'os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md'
- - 'OS_MBUF_TRAILINGSPACE': 'os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md'
- - 'os_mbuf_adj': 'os/core_os/mbuf/os_mbuf_adj.md'
- - 'os_mbuf_append': 'os/core_os/mbuf/os_mbuf_append.md'
- - 'os_mbuf_concat': 'os/core_os/mbuf/os_mbuf_concat.md'
- - 'os_mbuf_copydata': 'os/core_os/mbuf/os_mbuf_copydata.md'
- - 'os_mbuf_copyinto': 'os/core_os/mbuf/os_mbuf_copyinto.md'
- - 'os_mbuf_dup': 'os/core_os/mbuf/os_mbuf_dup.md'
- - 'os_mbuf_extend': 'os/core_os/mbuf/os_mbuf_extend.md'
- - 'os_mbuf_free_chain': 'os/core_os/mbuf/os_mbuf_free_chain.md'
- - 'os_mbuf_get': 'os/core_os/mbuf/os_mbuf_get.md'
- - 'os_mbuf_get_pkthdr': 'os/core_os/mbuf/os_mbuf_get_pkthdr.md'
- - 'os_mbuf_memcmp': 'os/core_os/mbuf/os_mbuf_memcmp.md'
- - 'os_mbuf_off': 'os/core_os/mbuf/os_mbuf_off.md'
- - 'os_mbuf_pool_init': 'os/core_os/mbuf/os_mbuf_pool_init.md'
- - 'os_mbuf_prepend': 'os/core_os/mbuf/os_mbuf_prepend.md'
- - 'os_mbuf_pullup': 'os/core_os/mbuf/os_mbuf_pullup.md'
- - Msys:
- - toc: 'os/core_os/msys/msys.md'
- - 'Functions':
- - 'os_msys_get': 'os/core_os/msys/os_msys_get.md'
- - 'os_msys_get_pkthdr': 'os/core_os/msys/os_msys_get_pkthdr.md'
- - 'os_msys_register': 'os/core_os/msys/os_msys_register.md'
- - 'os_msys_reset': 'os/core_os/msys/os_msys_reset.md'
- - MQueue:
- - toc: 'os/core_os/mqueue/mqueue.md'
- - Functions:
- - 'os_mqueue_init': 'os/core_os/mqueue/os_mqueue_init.md'
- - 'os_mqueue_get': 'os/core_os/mqueue/os_mqueue_get.md'
- - 'os_mqueue_put': 'os/core_os/mqueue/os_mqueue_put.md'
- - Sanity:
- - toc: 'os/core_os/sanity/sanity.md'
- - 'Functions':
- - 'os_sanity_check_init': 'os/core_os/sanity/os_sanity_check_init.md'
- - 'os_sanity_check_register': 'os/core_os/sanity/os_sanity_check_register.md'
- - 'os_sanity_check_reset': 'os/core_os/sanity/os_sanity_check_reset.md'
- - 'os_sanity_task_checkin': 'os/core_os/sanity/os_sanity_task_checkin.md'
- - Callouts:
- - toc: 'os/core_os/callout/callout.md'
- - 'Functions':
- - 'os_callout_func_init': 'os/core_os/callout/os_callout_func_init.md'
- - 'os_callout_init': 'os/core_os/callout/os_callout_init.md'
- - 'os_callout_queued': 'os/core_os/callout/os_callout_queued.md'
- - 'os_callout_reset': 'os/core_os/callout/os_callout_reset.md'
- - 'os_callout_stop': 'os/core_os/callout/os_callout_stop.md'
- - Porting to your Platform:
- - toc: 'os/core_os/porting/port_os.md'
- - 'BSP Porting': 'os/core_os/porting/port_bsp.md'
- - 'MCU Porting': 'os/core_os/porting/port_mcu.md'
- - 'CPU Porting': 'os/core_os/porting/port_cpu.md'
- - Console:
- - toc: 'os/modules/console/console.md'
- - 'Functions':
- - 'console_echo': 'os/modules/console/console_echo.md'
- - 'console_init': 'os/modules/console/console_init.md'
- - 'console_is_init': 'os/modules/console/console_is_init.md'
- - 'console_printf': 'os/modules/console/console_printf.md'
- - 'console_read': 'os/modules/console/console_read.md'
- - 'console_set_queues': 'os/modules/console/console_set_queues.md'
- - 'console_write': 'os/modules/console/console_write.md'
- - Shell:
- - toc: 'os/modules/shell/shell.md'
- - 'Functions':
- - 'shell_cmd_register': 'os/modules/shell/shell_cmd_register.md'
- - 'shell_evq_set' : 'os/modules/shell/shell_evq_set.md'
- - 'shell_nlip_input_register': 'os/modules/shell/shell_nlip_input_register.md'
- - 'shell_nlip_output': 'os/modules/shell/shell_nlip_output.md'
- - 'shell_register': 'os/modules/shell/shell_register.md'
- - 'shell_register_app_cmd_handler': 'os/modules/shell/shell_register_app_cmd_handler.md'
- - 'shell_register_default_module': 'os/modules/shell/shell_register_default_module.md'
- - Split Images:
- - toc: 'os/modules/split/split.md'
- - Bootloader:
- - toc: 'os/modules/bootloader/bootloader.md'
- - 'Functions':
- - 'boot_build_status': 'os/modules/bootloader/boot_build_status.md'
- - 'boot_build_status_one': 'os/modules/bootloader/boot_build_status_one.md'
- - 'boot_clear_status': 'os/modules/bootloader/boot_clear_status.md'
- - 'boot_copy_area': 'os/modules/bootloader/boot_copy_area.md'
- - 'boot_copy_image': 'os/modules/bootloader/boot_copy_image.md'
- - 'boot_erase_area': 'os/modules/bootloader/boot_erase_area.md'
- - 'boot_fill_slot': 'os/modules/bootloader/boot_fill_slot.md'
- - 'boot_find_image_area_idx': 'os/modules/bootloader/boot_find_image_area_idx.md'
- - 'boot_find_image_part': 'os/modules/bootloader/boot_find_image_part.md'
- - 'boot_find_image_slot': 'os/modules/bootloader/boot_find_image_slot.md'
- - 'boot_go': 'os/modules/bootloader/boot_go.md'
- - 'boot_init_flash': 'os/modules/bootloader/boot_init_flash.md'
- - 'boot_move_area': 'os/modules/bootloader/boot_move_area.md'
- - 'boot_read_image_header': 'os/modules/bootloader/boot_read_image_header.md'
- - 'boot_read_image_headers': 'os/modules/bootloader/boot_read_image_headers.md'
- - 'boot_read_status': 'os/modules/bootloader/boot_read_status.md'
- - 'boot_select_image_slot': 'os/modules/bootloader/boot_select_image_slot.md'
- - 'boot_slot_addr': 'os/modules/bootloader/boot_slot_addr.md'
- - 'boot_slot_to_area_idx': 'os/modules/bootloader/boot_slot_to_area_idx.md'
- - 'boot_swap_areas': 'os/modules/bootloader/boot_swap_areas.md'
- - 'boot_vect_delete_main': 'os/modules/bootloader/boot_vect_delete_main.md'
- - 'boot_vect_delete_test': 'os/modules/bootloader/boot_vect_delete_test.md'
- - 'boot_vect_read_main': 'os/modules/bootloader/boot_vect_read_main.md'
- - 'boot_vect_read_one': 'os/modules/bootloader/boot_vect_read_one.md'
- - 'boot_vect_read_test': 'os/modules/bootloader/boot_vect_read_test.md'
- - 'boot_write_status': 'os/modules/bootloader/boot_write_status.md'
- - File System:
- - 'File System Abstraction':
- - toc: 'os/modules/fs/fs/fs.md'
- - 'Return Codes': 'os/modules/fs/fs/fs_return_codes.md'
- - 'Data Structures':
- - 'struct fs_ops': 'os/modules/fs/fs/fs_ops.md'
- - 'Functions':
- - 'fs_close': 'os/modules/fs/fs/fs_close.md'
- - 'fs_closedir': 'os/modules/fs/fs/fs_closedir.md'
- - 'fs_dirent_is_dir': 'os/modules/fs/fs/fs_dirent_is_dir.md'
- - 'fs_dirent_name': 'os/modules/fs/fs/fs_dirent_name.md'
- - 'fs_filelen': 'os/modules/fs/fs/fs_filelen.md'
- - 'fs_getpos': 'os/modules/fs/fs/fs_getpos.md'
- - 'fs_mkdir': 'os/modules/fs/fs/fs_mkdir.md'
- - 'fs_open': 'os/modules/fs/fs/fs_open.md'
- - 'fs_opendir': 'os/modules/fs/fs/fs_opendir.md'
- - 'fs_read': 'os/modules/fs/fs/fs_read.md'
- - 'fs_readdir': 'os/modules/fs/fs/fs_readdir.md'
- - 'fs_register': 'os/modules/fs/fs/fs_register.md'
- - 'fs_rename': 'os/modules/fs/fs/fs_rename.md'
- - 'fs_seek': 'os/modules/fs/fs/fs_seek.md'
- - 'fs_unlink': 'os/modules/fs/fs/fs_unlink.md'
- - 'fs_write': 'os/modules/fs/fs/fs_write.md'
- - 'fsutil_read_file': 'os/modules/fs/fs/fsutil_read_file.md'
- - 'fsutil_write_file': 'os/modules/fs/fs/fsutil_write_file.md'
- - 'FAT File System': 'os/modules/fs/fatfs.md'
- - 'Newtron Flash File System':
- - toc: 'os/modules/fs/nffs/nffs.md'
- - 'Data Structures':
- - 'struct nffs_area_desc': 'os/modules/fs/nffs/nffs_area_desc.md'
- - 'struct nffs_config': 'os/modules/fs/nffs/nffs_config.md'
- - 'Functions':
- - 'nffs_detect': 'os/modules/fs/nffs/nffs_detect.md'
- - 'nffs_format': 'os/modules/fs/nffs/nffs_format.md'
- - 'nffs_init': 'os/modules/fs/nffs/nffs_init.md'
- - 'Internals': 'os/modules/fs/nffs/nffs_internals.md'
- - 'Other File Systems': 'os/modules/fs/otherfs.md'
- - Hardware Abstraction Layer:
- - toc: 'os/modules/hal/hal.md'
- - 'API':
- - 'Summary': 'os/modules/hal/hal_api.md'
- - 'BSP': 'os/modules/hal/hal_bsp/hal_bsp.md'
- - 'Flash memory':
- - 'flash API for apps': 'os/modules/hal/hal_flash/hal_flash.md'
- - 'flash_int': 'os/modules/hal/hal_flash/hal_flash_int.md'
- - 'GPIO': 'os/modules/hal/hal_gpio/hal_gpio.md'
- - 'I2C': 'os/modules/hal/hal_i2c/hal_i2c.md'
- - 'OS Tick': 'os/modules/hal/hal_os_tick/hal_os_tick.md'
- - 'SPI': 'os/modules/hal/hal_spi/hal_spi.md'
- - 'System': 'os/modules/hal/hal_system/hal_sys.md'
- - 'Timer': 'os/modules/hal/hal_timer/hal_timer.md'
- - 'UART': 'os/modules/hal/hal_uart/hal_uart.md'
- - 'Watchdog': 'os/modules/hal/hal_watchdog/hal_watchdog.md'
- - 'Using HAL': 'os/modules/hal/hal_in_libraries.md'
- - 'Creating HAL': 'os/modules/hal/hal_creation.md'
- - Sensor Framework:
- - toc: 'os/modules/sensor_framework/sensor_framework_overview.md'
- - 'API':
- - 'Sensor API': 'os/modules/sensor_framework/sensor_api.md'
- - 'Sensor Manager API': 'os/modules/sensor_framework/sensor_mgr_api.md'
- - 'Sensor Listener API': 'os/modules/sensor_framework/sensor_listener_api.md'
- - 'OIC Sensor API': 'os/modules/sensor_framework/sensor_oic.md'
- - 'Sensor Shell': 'os/modules/sensor_framework/sensor_shell.md'
- - 'Sensor Device Driver': 'os/modules/sensor_framework/sensor_driver.md'
- - 'Creating and Configuring Sensor Devices': 'os/modules/sensor_framework/sensor_create.md'
- - Drivers:
- - toc: 'os/modules/drivers/driver.md'
- - 'Supported Drivers':
- #- 'adc': 'os/modules/drivers/adc.md'
- - 'flash': 'os/modules/drivers/flash.md'
- # - 'lwip': 'os/modules/drivers/lwip.md'
- - 'mmc': 'os/modules/drivers/mmc.md'
- - 'nimBLE': 'network/ble/ble_intro.md'
- #- 'sensors': 'os/modules/drivers/sensors.md'
- #- 'uart': 'os/modules/drivers/uart.md'
- - Test Utilities:
- - toc: 'os/modules/testutil/testutil.md'
- - 'Functions/Macros':
- - 'tu_init': 'os/modules/testutil/tu_init.md'
- - 'TEST_ASSERT': 'os/modules/testutil/test_assert.md'
- - 'TEST_PASS': 'os/modules/testutil/test_pass.md'
- - 'TEST_SUITE': 'os/modules/testutil/test_suite.md'
- - 'TEST_CASE': 'os/modules/testutil/test_case.md'
- - 'TEST_CASE_DECL': 'os/modules/testutil/test_decl.md'
- - 'tu_restart': 'os/modules/testutil/tu_restart.md'
- - Device Management with Newt Manager:
- - toc: 'os/modules/devmgmt/newtmgr.md'
- - 'Using Newt Manager in OIC framework': 'os/modules/devmgmt/oicmgr.md'
- - 'Customizing Newt Manager Usage with mgmt': 'os/modules/devmgmt/customize_newtmgr.md'
- - Image Manager:
- - toc: 'os/modules/imgmgr/imgmgr.md'
- - 'Functions':
- - 'imgr_ver_parse': 'os/modules/imgmgr/imgr_ver_parse.md'
- - 'imgr_ver_str': 'os/modules/imgmgr/imgr_ver_str.md'
- - 'Baselibc library': 'os/modules/baselibc.md'
- - JSON:
- - toc: 'os/modules/json/json.md'
- - 'Functions':
- - 'json_encode_object_entry': 'os/modules/json/json_encode_object_entry.md'
- - 'json_encode_object_finish': 'os/modules/json/json_encode_object_finish.md'
- - 'json_encode_object_key': 'os/modules/json/json_encode_object_key.md'
- - 'json_encode_object_start': 'os/modules/json/json_encode_object_start.md'
- - 'json_read_object': 'os/modules/json/json_read_object.md'
- - Flash Circular Buffer:
- - toc: 'os/modules/fcb/fcb.md'
- - 'Functions':
- - 'fcb_init': 'os/modules/fcb/fcb_init.md'
- - 'fcb_append': 'os/modules/fcb/fcb_append.md'
- - 'fcb_append_finish': 'os/modules/fcb/fcb_append_finish.md'
- - 'fcb_walk': 'os/modules/fcb/fcb_walk.md'
- - 'fcb_getnext': 'os/modules/fcb/fcb_getnext.md'
- - 'fcb_rotate': 'os/modules/fcb/fcb_rotate.md'
- - 'fcb_append_to_scratch': 'os/modules/fcb/fcb_append_to_scratch.md'
- - 'fcb_is_empty': 'os/modules/fcb/fcb_is_empty.md'
- - 'fcb_offset_last_n': 'os/modules/fcb/fcb_offset_last_n.md'
- - 'fcb_clear': 'os/modules/fcb/fcb_clear.md'
- - Stats:
- - toc: 'os/modules/stats/stats.md'
- - Logs:
- - toc: 'os/modules/logs/logs.md'
- - System Configuration And Initialization:
- - toc: 'os/modules/sysinitconfig/sysinitconfig.md'
- - 'Validation and Error Messages': 'os/modules/sysinitconfig/sysconfig_error.md'
- - BLE User Guide:
- - NimBLE Introduction: 'network/ble/ble_intro.md'
- - NimBLE Security: 'network/ble/ble_sec.md'
- - NimBLE Setup:
- - toc: 'network/ble/ble_setup/ble_setup_intro.md'
- - 'Configure clock for controller': 'network/ble/ble_setup/ble_lp_clock.md'
- - 'Configure device address': 'network/ble/ble_setup/ble_addr.md'
- - 'Configure sync callbacks': 'network/ble/ble_setup/ble_sync_cb.md'
- - NimBLE Host API:
- - toc: 'network/ble/ble_hs/ble_hs.md'
- - 'Return codes': 'network/ble/ble_hs/ble_hs_return_codes.md'
-
- - 'GAP':
- - toc: 'network/ble/ble_hs/ble_gap/ble_gap.md'
- - 'Definitions':
- - 'GAP definitions': 'network/ble/ble_hs/ble_gap/definitions/ble_gap_defs.md'
- - 'Functions':
- - 'ble_gap_adv_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_active.md'
- - 'ble_gap_adv_rsp_set_data': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_data.md'
- - 'ble_gap_adv_rsp_set_fields': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_fields.md'
- - 'ble_gap_adv_set_data': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_data.md'
- - 'ble_gap_adv_set_fields': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields.md'
- - 'ble_gap_adv_set_phys': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_phys.md'
- - 'ble_gap_adv_set_tx_power': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_tx_power.md'
- - 'ble_gap_adv_start': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md'
- - 'ble_gap_adv_stop': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_stop.md'
- - 'ble_gap_conn_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_active.md'
- - 'ble_gap_conn_cancel': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_cancel.md'
- - 'ble_gap_conn_find': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_find.md'
- - 'ble_gap_conn_rssi': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_rssi.md'
- - 'ble_gap_connect': 'network/ble/ble_hs/ble_gap/functions/ble_gap_connect.md'
- - 'ble_gap_ext_connect': 'network/ble/ble_hs/ble_gap/functions/ble_gap_ext_connect.md'
- - 'ble_gap_disc': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc.md'
- - 'ble_gap_ext_disc': 'network/ble/ble_hs/ble_gap/functions/ble_gap_ext_disc.md'
- - 'ble_gap_disc_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc_active.md'
- - 'ble_gap_disc_cancel': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc_cancel.md'
- - 'ble_gap_security_initiate': 'network/ble/ble_hs/ble_gap/functions/ble_gap_security_initiate.md'
- - 'ble_gap_set_event_cb': 'network/ble/ble_hs/ble_gap/functions/ble_gap_set_event_cb.md'
- - 'ble_gap_terminate': 'network/ble/ble_hs/ble_gap/functions/ble_gap_terminate.md'
- - 'ble_gap_update_params': 'network/ble/ble_hs/ble_gap/functions/ble_gap_update_params.md'
- - 'ble_gap_wl_set': 'network/ble/ble_hs/ble_gap/functions/ble_gap_wl_set.md'
- - 'ble_gap_set_priv_mode': 'network/ble/ble_hs/ble_gap/functions/ble_gap_set_priv_mode.md'
- - 'ble_gap_read_le_phy': 'network/ble/ble_hs/ble_gap/functions/ble_gap_read_le_phy.md'
- - 'ble_gap_set_prefered_default_le_phy': 'network/ble/ble_hs/ble_gap/functions/ble_gap_set_prefered_default_le_phy.md'
- - 'ble_gap_set_prefered_le_phy': 'network/ble/ble_hs/ble_gap/functions/ble_gap_set_prefered_le_phy.md'
-
- - 'GATT client':
- - toc: 'network/ble/ble_hs/ble_gattc/ble_gattc.md'
- - 'Definitions':
- - 'GATT client definitions': 'network/ble/ble_hs/ble_gattc/definitions/ble_gattc_defs.md'
- - 'Functions':
- - 'ble_gattc_disc_all_chrs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_chrs.md'
- - 'ble_gattc_disc_all_dscs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_dscs.md'
- - 'ble_gattc_disc_all_svcs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_svcs.md'
- - 'ble_gattc_disc_chrs_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_chrs_by_uuid.md'
- - 'ble_gattc_disc_svc_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_svc_by_uuid.md'
- - 'ble_gattc_exchange_mtu': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu.md'
- - 'ble_gattc_find_inc_svcs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_find_inc_svcs.md'
- - 'ble_gattc_indicate': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate.md'
- - 'ble_gattc_indicate_custom': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate_custom.md'
- - 'ble_gattc_notify': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify.md'
- - 'ble_gattc_notify_custom': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify_custom.md'
- - 'ble_gattc_read': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read.md'
- - 'ble_gattc_read_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_by_uuid.md'
- - 'ble_gattc_read_long': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_long.md'
- - 'ble_gattc_read_mult': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_mult.md'
- - 'ble_gattc_write': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write.md'
- - 'ble_gattc_write_flat': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_flat.md'
- - 'ble_gattc_write_long': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_long.md'
- - 'ble_gattc_write_no_rsp': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp.md'
- - 'ble_gattc_write_no_rsp_flat': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp_flat.md'
- - 'ble_gattc_write_reliable': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_reliable.md'
-
- - 'GATT server':
- - toc: 'network/ble/ble_hs/ble_gatts/ble_gatts.md'
- - 'Definitions':
- - 'GATT server definitions': 'network/ble/ble_hs/ble_gatts/definitions/ble_gatts_defs.md'
- - 'Functions':
- - 'ble_gatts_add_svcs': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_add_svcs.md'
- - 'ble_gatts_svc_set_visibility': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_svc_set_visibility.md'
- - 'ble_gatts_count_cfg': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_count_cfg.md'
- - 'ble_gatts_find_chr': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_chr.md'
- - 'ble_gatts_find_dsc': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_dsc.md'
- - 'ble_gatts_find_svc': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_svc.md'
-
- - 'Identity':
- - toc: 'network/ble/ble_hs/ble_hs_id/ble_hs_id.md'
- - 'Functions':
- - 'ble_hs_id_copy_addr': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_copy_addr.md'
- - 'ble_hs_id_gen_rnd': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd.md'
- - 'ble_hs_id_set_rnd': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd.md'
-
- - 'ATT':
- - toc: 'network/ble/ble_hs/ble_att/ble_att.md'
- - 'Functions':
- - 'ble_att_mtu': 'network/ble/ble_hs/ble_att/functions/ble_att_mtu.md'
- - 'ble_att_preferred_mtu': 'network/ble/ble_hs/ble_att/functions/ble_att_preferred_mtu.md'
- - 'ble_att_set_preferred_mtu': 'network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu.md'
- - 'ble_att_svr_read_local': 'network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local.md'
- - 'ble_att_svr_write_local': 'network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local.md'
- - 'Other':
- - toc: 'network/ble/ble_hs/other/other.md'
- - 'Functions':
- - 'ble_eddystone_set_adv_data_uid': 'network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_uid.md'
- - 'ble_eddystone_set_adv_data_url': 'network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_url.md'
- - 'ble_hs_evq_set': 'network/ble/ble_hs/other/functions/ble_hs_evq_set.md'
- - 'ble_hs_mbuf_att_pkt': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_att_pkt.md'
- - 'ble_hs_mbuf_from_flat': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_from_flat.md'
- - 'ble_hs_mbuf_to_flat': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_to_flat.md'
- - 'ble_hs_sched_reset': 'network/ble/ble_hs/other/functions/ble_hs_sched_reset.md'
- - 'ble_hs_synced': 'network/ble/ble_hs/other/functions/ble_hs_synced.md'
- - 'ble_ibeacon_set_adv_data': 'network/ble/ble_hs/other/functions/ble_ibeacon_set_adv_data.md'
- - 'ble_uuid_cmp': 'network/ble/ble_hs/other/functions/ble_uuid_cmp.md'
- - 'ble_uuid_init_from_buf': 'network/ble/ble_hs/other/functions/ble_uuid_init_from_buf.md'
- - 'ble_uuid_to_str': 'network/ble/ble_hs/other/functions/ble_uuid_to_str.md'
- - 'ble_uuid_u16': 'network/ble/ble_hs/other/functions/ble_uuid_u16.md'
-
- - btshell Usage API:
- - toc: 'network/ble/btshell/btshell_api.md'
- - 'GAP in btshell': 'network/ble/btshell/btshell_GAP.md'
- - 'GATT in btshell': 'network/ble/btshell/btshell_GATT.md'
- - 'Advertisement Data Fields': 'network/ble/btshell/btshell_advdata.md'
- - Bluetooth Mesh:
- - toc: 'network/ble/ble_mesh.md'
- - blemesh sample: 'network/ble/ble_blemesh.md'
- - Newt Tool Guide:
- - toc: 'newt/newt_intro.md'
- - Newt Theory of Ops: 'newt/newt_operation.md'
- - Command Guide:
- - toc: 'newt/newt_ops.md'
- - 'newt build': 'newt/command_list/newt_build.md'
- - 'newt clean': 'newt/command_list/newt_clean.md'
- - 'newt create-image': 'newt/command_list/newt_create_image.md'
- - 'newt debug': 'newt/command_list/newt_debug.md'
- - 'newt help': 'newt/command_list/newt_help.md'
- - 'newt info': 'newt/command_list/newt_info.md'
- - 'newt install': 'newt/command_list/newt_install.md'
- - 'newt load': 'newt/command_list/newt_load.md'
- - 'newt mfg': 'newt/command_list/newt_mfg.md'
- - 'newt new': 'newt/command_list/newt_new.md'
- - 'newt pkg': 'newt/command_list/newt_pkg.md'
- - 'newt resign-image': 'newt/command_list/newt_resign_image.md'
- - 'newt run': 'newt/command_list/newt_run.md'
- - 'newt size': 'newt/command_list/newt_size.md'
- - 'newt sync': 'newt/command_list/newt_sync.md'
- - 'newt target': 'newt/command_list/newt_target.md'
- - 'newt test': 'newt/command_list/newt_test.md'
- - 'newt upgrade': 'newt/command_list/newt_upgrade.md'
- - 'newt vals': 'newt/command_list/newt_vals.md'
- - 'newt version': 'newt/command_list/newt_version.md'
- - Newt Manager Guide:
- - toc: 'newtmgr/overview.md'
- - Command Guide:
- - 'newtmgr config': 'newtmgr/command_list/newtmgr_config.md'
- - 'newtmgr conn': 'newtmgr/command_list/newtmgr_conn.md'
- - 'newtmgr crash': 'newtmgr/command_list/newtmgr_crash.md'
- - 'newtmgr datetime': 'newtmgr/command_list/newtmgr_datetime.md'
- - 'newtmgr echo': 'newtmgr/command_list/newtmgr_echo.md'
- - 'newtmgr fs': 'newtmgr/command_list/newtmgr_fs.md'
- - 'newtmgr image': 'newtmgr/command_list/newtmgr_image.md'
- - 'newtmgr log': 'newtmgr/command_list/newtmgr_logs.md'
- - 'newtmgr mpstat': 'newtmgr/command_list/newtmgr_mpstats.md'
- - 'newtmgr reset': 'newtmgr/command_list/newtmgr_reset.md'
- - 'newtmgr run': 'newtmgr/command_list/newtmgr_run.md'
- - 'newtmgr stat': 'newtmgr/command_list/newtmgr_stat.md'
- - 'newtmgr taskstat': 'newtmgr/command_list/newtmgr_taskstats.md'
- - 'Install':
- - 'Install Newtmgr On Mac OS': 'newtmgr/install_mac.md'
- - 'Install Newtmgr On Linux': 'newtmgr/install_linux.md'
- - 'Install Newtmgr On Windows': 'newtmgr/install_windows.md'
- - Known Issues: 'known_issues.md'
-
-- Appendix:
- - 'Installing Previous Releases of Newt': 'newt/install/prev_releases.md'
- - 'Installing Previous Releases of Newtmgr': 'newtmgr/prev_releases.md'
- - 'Setting Up Go to Contribute to Newt and Newtmgr Tools': 'faq/go_env.md'
- - 'Using an IDE to Develop Mynewt Applications': 'faq/ide.md'
- - 'Edit Docs': 'faq/how_to_edit_docs.md'
- - 'FAQ': 'faq/answers.md'
markdown_extensions:
- toc:
@@ -633,14 +51,7 @@
- label: '1.3.0'
dir: 'v1_3_0'
latest: False
- doc_path: 'os/introduction'
- chapters:
- Chapter 1 - Get Started: 'The chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.'
- Chapter 2 - Get Acclimated: 'Delves deeper into the concepts crucial to the software development effort.'
- Chapter 3 - Newt Tool: 'Describes the command structure and details all the available commands to help you with your project.'
- Chapter 4 - Mynewt OS: 'Provides an overview of the features available and how to customize for your hardware and software application.'
- Chapter 5 - Modules: 'Lays out all the available modules such as HAL (Hardware Abstraction Layer), console, le system, networking stacks, and other middleware components.'
- Chapter 6 - Packaging it: 'Packages for distribution delineates the process of creating complete packages to load on your embedded device to get it up, connected, and ready for remote management.'
+ doc_path: 'latest'
events:
event 1:
title: '<a href="http://events.linuxfoundation.org/events/embedded-linux-conference">Embedded Linux Conference 2018</a>'
