Mailing-List: contact commits-help@mynewt.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mynewt.incubator.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: aditi@apache.org
To: commits@mynewt.incubator.apache.org
Date: Mon, 28 Nov 2016 20:05:24 -0000
Message-Id: <5637e3659c3e44a1ab96fcee096362ec@git.apache.org>
In-Reply-To: <b57f009161fa4fcc80d83e16a5788130@git.apache.org>
References: <b57f009161fa4fcc80d83e16a5788130@git.apache.org>
Subject: [2/5] incubator-mynewt-site git commit: Tutorials added for console,
 serial port setup etc.
archived-at: Mon, 28 Nov 2016 20:05:44 -0000

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/22d098d8/latest/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/latest/mkdocs/search_index.json b/latest/mkdocs/search_index.json
index 8cbfaeb..a53ca84 100644
--- a/latest/mkdocs/search_index.json
+++ b/latest/mkdocs/search_index.json
@@ -406,6 +406,36 @@
             "title": "Complete"
         }, 
         {
+            "location": "/os/get_started/serial_access/", 
+            "text": "Using the Serial Port with Mynewt OS\n\n\nSome of the projects and tutorials here will allow you to use a serial port\nto interact with your Mynewt project. While most modern PCs and laptops\nno longer have a true serial port, almost all can use their USB ports\nas serial ports. \n\n\nThis will show you how to connect to some of the development boards\nwe use via a serial port. \n\n\nThe development boards covered here are:\n\n\n\n\nNordic Semiconductor NRF52dk\n\n\nArduino M0 Pro\n\n\n\n\nIn order to communicate with these boards you will also need a USB\n--\nSerial\nconverted. We'll be using the \nAdaFruit FT232H Breakout Board\n for\nthis, but almost any similar board should work just as well. You will also\nneed Minicom or a similar Serial communications application. We'll show you how\nto use the \nscreen\n command built in to Mac OS X, but later tutorials will\nalso show Minicom setup.\n\n\nSo let's get started!\n\n\n\n\nSetup FT232H\n\n\nThis is a great b
 oard because it's so easy to set up, and it can do Serial UART,\nSPI, I2C and GPIO as well. There's full documentation on the board \nhere\n\n but we're only covering the wiring for the Serial UART. \n\n\nStart by connecting a jumper wire to Pin D0. This will be the UART Tx pin, \nwhich we'll then connect to the Rx pin on the Development Board.\n\n\nNext connect a jumper wire to pin D1. This will be the UART Rx pin,\nwhich we'll connect to the Tx pin on the development board.\n\n\nFinally connect a jumper wire to the GND pin.\n\n\nIt should look like this:\n\n\n\n\n\n\nSetup Nordic Semiconductor NRF52DK\n\n\nOn the NRF52DK developer kit board, the Rx pin is P0.08, so you'll attach your\njumper wire from the Tx pin (D0) of the FT232H board here.\n\n\nThe TX Pin is pin P0.08, so you'll attache the jumper wire from the Rx Pin (D1)\non the FT232H board here. \n\n\nFinally, the GND wire should go to the GND Pin on the NRF52DK. When you're\ndone, your wiring should look like this:\n\n\n \
 n\n\n\n\nSetup Arduino M0 Pro\n\n\nOn the Arduino M0 Pro, the Tx and Rx pins are clearly labeled as such, as is the GND\npin. Just make sure you wire Rx from the FT232H to TX on the M0 Pro, and vice-versa.\n\n\nYour Arduino M0 Pro should look like this:\n\n\n\n\n\n\nSetup Serial Communications\n\n\nAs mentioned earlier, we'll be using the built in \nscreen\n command for this, but we'll still \nneed to know which serial port to connect to. So, before plugging in the FT232H Board, \ncheck to see what USB devices are already connected:\n\n\n$ ls -la /dev/*usb*\n0 crw-rw-rw-  1 root  wheel   20,  63 Nov 23 11:13 /dev/cu.usbmodem401322\n0 crw-rw-rw-  1 root  wheel   20,  62 Nov 23 11:13 /dev/tty.usbmodem401322\n$\n\n\n\n\n\nNow, plug in the FT232H board, and run that command again:\n\n\n$ ls -la /dev/*usb*\n0 crw-rw-rw-  1 root  wheel   20,  63 Nov 23 11:13 /dev/cu.usbmodem401322\n0 crw-rw-rw-  1 root  wheel   20,  65 Nov 23 11:26 /dev/cu.usbserial-0020124\n0 crw-rw-rw-  1 root  wheel   
 20,  62 Nov 23 11:13 /dev/tty.usbmodem401322\n0 crw-rw-rw-  1 root  wheel   20,  64 Nov 23 11:26 /dev/tty.usbserial-0020124\n$\n\n\n\n\n\nSo the FT232H is connected to \n/dev/tty.usbserial-0020124\n (The number after tty.usbserial\nwill be different on your machine.)\n\n\nSo let's connect to it:\n\n\n$ screen /dev/tty.usbserial-0020124 115200\n\n\n\n\n\nTo exit out of \nscreen\n you'll type \ncontrol-A\n followed by \ncontrol-\\\n and you'll\nbe back to a terminal prompt.\n\n\nIf you'd like to use Minicom:\n\n\n$ minicom -D /dev/tty.usbserial-0020124\n\n\n\n\n\nWelcome to minicom 2.7\n\n\nOPTIONS: \nCompiled on Nov 24 2015, 16:14:21.\nPort /dev/tty.usbserial-0020124, 09:57:17\n\n\nPress Meta-Z for help on special keys\n```\n\n\n\n\nIf there's no Mynewt app running, or the Mynewt app doesn't have the Shell and Console\nenabled, you won't see anything there, but you can always refer back to this page\nfrom later tutorials if you need to.\n\n\nNow that you know how to communicate with 
 your mynewt application, let's move on to\ncreating one!", 
+            "title": "Serial Port Setup"
+        }, 
+        {
+            "location": "/os/get_started/serial_access/#using-the-serial-port-with-mynewt-os", 
+            "text": "Some of the projects and tutorials here will allow you to use a serial port\nto interact with your Mynewt project. While most modern PCs and laptops\nno longer have a true serial port, almost all can use their USB ports\nas serial ports.   This will show you how to connect to some of the development boards\nwe 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\nconverted. We'll be using the  AdaFruit FT232H Breakout Board  for\nthis, but almost any similar board should work just as well. You will also\nneed Minicom or a similar Serial communications application. We'll show you how\nto use the  screen  command built in to Mac OS X, but later tutorials will\nalso show Minicom setup.  So let's get started!", 
+            "title": "Using the Serial Port with Mynewt OS"
+        }, 
+        {
+            "location": "/os/get_started/serial_access/#setup-ft232h", 
+            "text": "This is a great board because it's so easy to set up, and it can do Serial UART,\nSPI, I2C and GPIO as well. There's full documentation on the board  here \n 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, \nwhich 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,\nwhich 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:", 
+            "title": "Setup FT232H"
+        }, 
+        {
+            "location": "/os/get_started/serial_access/#setup-nordic-semiconductor-nrf52dk", 
+            "text": "On the NRF52DK developer kit board, the Rx pin is P0.08, so you'll attach your\njumper wire from the Tx pin (D0) of the FT232H board here.  The TX Pin is pin P0.08, so you'll attache the jumper wire from the Rx Pin (D1)\non the FT232H board here.   Finally, the GND wire should go to the GND Pin on the NRF52DK. When you're\ndone, your wiring should look like this:", 
+            "title": "Setup Nordic Semiconductor NRF52DK"
+        }, 
+        {
+            "location": "/os/get_started/serial_access/#setup-arduino-m0-pro", 
+            "text": "On the Arduino M0 Pro, the Tx and Rx pins are clearly labeled as such, as is the GND\npin. 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:", 
+            "title": "Setup Arduino M0 Pro"
+        }, 
+        {
+            "location": "/os/get_started/serial_access/#setup-serial-communications", 
+            "text": "As mentioned earlier, we'll be using the built in  screen  command for this, but we'll still \nneed to know which serial port to connect to. So, before plugging in the FT232H Board, \ncheck to see what USB devices are already connected:  $ ls -la /dev/*usb*\n0 crw-rw-rw-  1 root  wheel   20,  63 Nov 23 11:13 /dev/cu.usbmodem401322\n0 crw-rw-rw-  1 root  wheel   20,  62 Nov 23 11:13 /dev/tty.usbmodem401322\n$  Now, plug in the FT232H board, and run that command again:  $ ls -la /dev/*usb*\n0 crw-rw-rw-  1 root  wheel   20,  63 Nov 23 11:13 /dev/cu.usbmodem401322\n0 crw-rw-rw-  1 root  wheel   20,  65 Nov 23 11:26 /dev/cu.usbserial-0020124\n0 crw-rw-rw-  1 root  wheel   20,  62 Nov 23 11:13 /dev/tty.usbmodem401322\n0 crw-rw-rw-  1 root  wheel   20,  64 Nov 23 11:26 /dev/tty.usbserial-0020124\n$  So the FT232H is connected to  /dev/tty.usbserial-0020124  (The number after tty.usbserial\nwill be different on your machine.)  So let's connect to it:  $ screen /dev/tty
 .usbserial-0020124 115200  To exit out of  screen  you'll type  control-A  followed by  control-\\  and you'll\nbe back to a terminal prompt.  If you'd like to use Minicom:  $ minicom -D /dev/tty.usbserial-0020124  Welcome to minicom 2.7  OPTIONS: \nCompiled on Nov 24 2015, 16:14:21.\nPort /dev/tty.usbserial-0020124, 09:57:17  Press Meta-Z for help on special keys\n```   If there's no Mynewt app running, or the Mynewt app doesn't have the Shell and Console\nenabled, you won't see anything there, but you can always refer back to this page\nfrom later tutorials if you need to.  Now that you know how to communicate with your mynewt application, let's move on to\ncreating one!", 
+            "title": "Setup Serial Communications"
+        }, 
+        {
             "location": "/os/get_started/vocabulary/", 
             "text": "Concepts\n\n\nThis page is meant to introduce you to some of the concepts inherent to \nthe Apache Mynewt Operating System, and \nNewt\n the tool that stitches a \nproject built on Apache Mynewt together.\n\n\nProject\n\n\nThe project is the base directory of your embedded software tree.  It is a \nworkspace that contains a logical collection of source code, for one or \nmore of your applications.  A project consists of the following items:\n\n\n\n\nProject Definition: defines project level dependencies, and parameters\n    (located in \nproject.yml\n)\n\n\nPackages\n\n\n\n\nPackages\n are described in detail in the section below.  \n\n\nHere is an example project definition file from the default Apache Mynewt \nproject: \n\n\n$ more project.yml \n\nsnip\n\nproject.name: \nmy_project\n\n\nproject.repositories:\n    - apache-mynewt-core\n\n# Use github\ns distribution mechanism for core ASF libraries.\n# This provides mirroring automatically for us.\n#\nrepositor
 y.apache-mynewt-core:\n    type: github\n    vers: 0-latest\n    user: apache\n    repo: incubator-mynewt-core\n$ \n\n\n\n\n\nA couple of things to note in the project definition:\n\n\n\n\n\n\nproject.repositories\n: Defines the remote repositories that this project\nrelies upon.\n\n\n\n\n\n\nrepository.apache-mynewt-core\n: Defines the repository information for \nthe \napache-mynewt-core\n repository.\n\n\n\n\n\n\nvers=0-latest\n: Defines the repository version. This string will use the \nlatest code in the 'Master' github branch. To use the latest version in the \ndevelop branch, just change it to \nvers=0-dev\n\n\n\n\n\n\nRepositories are versioned collections of packages.  \n\n\nProjects can rely on remote repositories for functionality, and the newt tool \nwill resolve those remote repositories, and download the correct version into \nyour local source tree.  Newly fetched repositories are put in the \nrepos\n\ndirectory of your project, and can be referenced throughout the sy
 stem by using\nthe \n@\n specifier.  \n\n\nBy default, the \n@apache-mynewt-core\n repository is included in every \nproject.  Apache Mynewt Core contains all the base functionality of the Apache \nMynewt Operating System, including the Real Time Kernel, Bluetooth Networking \nStack, Flash File System, Console, Shell and Bootloader.\n\n\nNOTE:\n Any project can be converted into a repository by providing it with a \n\nrepository.yml\n file and putting it up onto Github.  More information\nabout repositories can be found in the Newt documentation.\n\n\nPackage\n\n\nA package is a collection items that form a fundamental unit in the Mynewt \nOperating System.  Packages can be:\n\n\n\n\nApplications\n\n\nLibraries\n\n\nCompiler definitions\n\n\nTargets\n\n\n\n\nA package is identified by having a \npkg.yml\n file in it's base \ndirectory.  Here is a sample \npkg.yml\n file for the blinky applicaton:\n\n\n$ more pkg.yml \n\nsnip\n\npkg.name: apps/blinky\npkg.type: app\npkg.description: 
 Basic example application which blinks an LED.\npkg.author: \nApache Mynewt \ndev@mynewt.incubator.apache.org\n\npkg.homepage: \nhttp://mynewt.apache.org/\n\npkg.keywords:\n\npkg.deps:\n    - \n@apache-mynewt-core/libs/os\n\n    - \n@apache-mynewt-core/hw/hal\n\n    - \n@apache-mynewt-core/libs/console/full\n\n\n\n\n\n\nPackages have a few features worth noting:\n\n\n\n\nDependencies: Packages can rely upon other packages, and when they do\n    they will inherit their functionality (header files, library definitions, etc.)\n\n\nAPIs: Packages can export named APIs, and they can require that certain \n    APIs be present, in order to compile.\n\n\nFeatures: Packages can operate differently depending on what named features are \n    present in the system.  Packages can also export features to the rest of the \n    Mynewt system.\n\n\n\n\nEverything that newt knows about within a project's directory is a package.  This \nmakes it very clean and easy to write re-usable components, which
  can describe their \nDependencies and APIs to the rest of the system.\n\n\nTarget\n\n\nA target in Apache Mynewt is very similar to a target in \nmake\n.  It is the collection\nof parameters that must be passed to Newt in order to generate a reproducible build.  A \ntarget represents the top of the build tree, and any packages or parameters specified at \nthe target level, cascade down to all dependencies.\n\n\nTargets are also packages, and are stored in the \ntargets/\n directory at the base \nof your project.  Most targets consist of: \n\n\n\n\napp\n: The application to build.\n\n\nbsp\n: The board support package to combine with that application\n\n\nbuild_profile\n: Either \ndebug\n or \noptimized\n. \n\n\n\n\nTargets can also have additional items specified, including: \n\n\n\n\ncflags\n: Any additional compiler flags you might want to specify to the build.\n\n\nfeatures\n: Any system level features you want to enable.\n\n\n\n\nIn order to create and manipulate targets, the \
 nnewt\n tool offers a set of helper commands,\nyou can find more information about these by issuing:\n\n\n$ newt target\n\n\nUsage:\n  newt target [flags]\n  newt target [command]\n\nAvailable Commands:\n  config      View target system configuration\n  copy        Copy target\n  create      Create a target\n  delete      Delete target\n  set         Set target configuration variable\n  show        View target configuration variables\n\nGlobal Flags:\n  -l, --loglevel string   Log level (default \nWARN\n)\n  -o, --outfile string    Filename to tee output to\n  -q, --quiet             Be quiet; only display error output\n  -s, --silent            Be silent; don\nt output anything\n  -v, --verbose           Enable verbose output when executing commands\n\nUse \nnewt target [command] --help\n for more information about a command.\n$ \n\n\n\n\n\nConfiguration\n\n\nThere are a lot of configuration options available when building your application in MyNewt. System Configuration options ar
 e set in \na file called \nsyscfg.yml\n and you will find these configuration files throughout the MyNewt packages. While you can edit these\nfiles directly to change some default settings, it is best to override the default settings in a \nsyscfg.yml\n file in your project\ndirectory rather than editing the package configurations directly.\n\n\nTo see all \nall\n the system configuration settings, simply type\n\n\n$ newt target config \ntarget-name\n\n...\n* PACKAGE: sys/stats\n  * Setting: STATS_CLI\n    * Description: Expose the \nstat\n shell command.\n    * Value: 0\n  * Setting: STATS_NAMES\n    * Description: Include and report the textual name of each statistic.\n    * Value: 0\n  * Setting: STATS_NEWTMGR\n    * Description: Expose the \nstat\n newtmgr command.\n    * Value: 0\n...\n$\n\n\n\n\n\nKeep in mind that this will only show the configuration options for any packages that are included in your applicaiton. \n\n\nIf you really want to see \nall\n the available configur
 ation options, you can go rough each package and look at the\n\nsyscfg.yml\n file in each.", 
             "title": "Concepts"
@@ -923,7 +953,7 @@
         {
             "location": "/os/tutorials/repo/upgrade_repo/", 
             "text": "Upgrade a repo\n\n\nIn order to upgrade a previously installed repository, the \"newt upgrade\" command should be issued:\n\n\n$ newt upgrade\n\n\n\n\n\n\n\nNewt upgrade will look at the current desired version in \nproject.yml\n, \nand compare it to the version in \nproject.state\n.  If these two differ, it \nwill upgrade the dependency.  Upgrade works not just for the dependency \nin \nproject.yml\n, but for all the sub-dependencies that they might have.\n\n\nIf you have changed any settings in the \nproject.yml\n file, you should run \n\nnewt upgrade\n to ensure that your repos are all up to date with the versions \nspecified in your \nproject.yml\n file.", 
-            "title": "Upgrade a repo"
+            "title": "Upgrade a Repo"
         }, 
         {
             "location": "/os/tutorials/repo/upgrade_repo/#upgrade-a-repo", 
@@ -933,7 +963,7 @@
         {
             "location": "/os/tutorials/repo/create_repo/", 
             "text": "Create a Repo out of a Project\n\n\nIn order to create a repository out of a project, all you need to do is create a \n\nrepository.yml\n file, and check it into the master branch of your project.\n\n\nNOTE:\n Currently only github source control service is supported by our \npackage management system, but support for plain git is planned for a future\nversion.\n\n\nThe \nrepository.yml\n defines all versions of the repository and the corresponding \nsource control tags that these versions correspond to.  As an example, if the \n\nrepository.yml\n file has the following content, it means there is one version \nof the apache-mynewt-core operating system available, which is \n0.0.0\n (implying we \nhaven't released yet!). Such a version number corresponds to the \"develop\" branch \nin this repository. \n0-latest\n would also resolved to this same \n0.0.0\n version. \nThe next section explains the versioning system a bit more.\n\n\n$ more repository.yml\nrepo.name
 : apache-mynewt-core\nrepo.versions:\n     \n0.0.0\n: \ndevelop\n\n     \n0-latest\n: \n0.0.0\n\n\n\n\n\n\n\n\nWhere should the repository.yml file be?\n\n\nThe \nrepository.yml\n file lives only in the master branch of the git\nrepository.  \nNewt\n will always fetch this file from the master branch and then\nuse that to resolve the actual branch required depending on the version\nspecified in the project.  \nSpecial care should be taken to ensure that this\nfile exists only in the master branch.\n\n\nHere is the \nrepository.yml\n file from a certain snapshot of apache-Mynewt-core:\n\n\nrepo.name: apache-mynewt-core\nrepo.versions:\n    \n0.7.9\n: \nMynewt_0_8_0_b2_tag\n\n    \n0-latest\n: \n0.7.9\n\n    \n0.8-latest\n: \n0.7.9\n\n\n\n\n\n\n\n\nIt contains the following:\n\n\n\n\nrepo.name\n The external name that is used to include the library in \nyour \nproject.yml\n file.   This is the name you include in the \nproject.repositories\n \nvariable when adding this repository to y
 our project.\n\n\nrepo.versions\n A description of what versions to give the user depending \non the settings in their \nproject.yml\n file.  See below for a thorough description\non versioning. Its a flexible mapping between version numbers and git branches.\n\n\n\n\n\n\nRepo Version Specification\n\n\nThe version field argument for a repo has the following format:\n\n\nmajor_num\n.\nminor_num\n.\nrevision_num\n\n\n\n\n\n\nor\n\n\nmajor_num\n.\nminor_num\n-\nstability string\n\n\n\n\n\n\nor \n\n\nmajor_num\n-\nstability string\n\n\n\n\n\n\n\n\nThe stability string can be one of 3 pre-defined stability values.\n\n\n\n\nstable\n -- A stable release version of the repository\n\n\ndev\n    -- A development version from the repository\n\n\nlatest\n -- The latest from the repository\n\n\n\n\nIn your \nproject.yml\n file you can specify different combinations of \nthe version number and stability value.  For example:\n\n\n\n\n0-latest\n      -- The latest version with major number 0\n\n\n
 1.2-stable\n    -- The latest stable version with major and minor number 1.2\n\n\n1.2-dev\n       -- The development version from 1.2\n\n\n1.1.1\n         -- a specific version 1.1.1\n\n\n\n\nYou \ncannot\n specify a stability string with a fully numbered version, e.g.\n\n\n1.2.8-stable\n\n\n\n\n\n\n\nRepo Version Resolution\n\n\nA \nrepository.yml\n file contains information to match this version request\ninto a git branch to fetch for your project.\n\n\nIt's up to you as the repository maintainer to map these to actual github branches \nof the repository.  For example, let's say in a fictitious repository the \nfollowing are defined.\n\n\nrepo.versions:\n    \n0.8.0\n: \nxxx_branch_0_8_0\n\n    \n1.0.0\n: \nxxx_branch_1_0_0\n\n    \n1.0.2\n: \nxxx_branch_1_0_2\n\n    \n1.1.1\n: \nxxx_branch_1_1_0\n\n    \n1.1.2\n: \nxxx_branch_1_1_2\n\n    \n1.2.0\n: \nxxx_branch_1_2_0\n\n    \n1.2.1\n: \nxxx_branch_1_2_1\n\n    \n1.2-dev\n: \n1.2.1\n\n    \n1-dev\n: \n1.2-dev\n\n    \n1.2-stable\
 n: \n1.2.0\n\n    \n0-latest\n: \n0.8.0\n\n    \n1-latest\n: \n1-dev\n\n    ....\n\n\n\n\n\nWhen the \nproject.yml\n file asks for \n1.2-stable\n it will be resolved to version\n\n1.2.0\n which in turn will resolve to a specific branch \nxxx_branch_1_2_0\n.\n\nThis is the branch that \nnewt\n will then fetch into the project with that \nproject.yml\n file.\n\n\n\n\nDependencies on other repos\n\n\nRepositories can also have dependencies on other repositories.  These \ndependencies should be listed out on a per-tag basis.  So, for example, \nif apache-mynewt-core were to depend on sterlys-little-repo, you might \nhave the following directives in the repository.yml:\n\n\ndevelop.repositories:\n    sterlys-little-repo:\n        type: github\n        vers: 0.8-latest\n        user: sterlinghughes\n        repo: sterlys-little-repo\n\n\n\n\n\n\n\nThis would tell Newt that for anything that resolves to the develop \nbranch, this repository requires the sterlys-little-repo repository. \n\n
 \nDependencies are resolved circularly by the newt tool, and every \ndependent repository is placed as a sibling in the repos directory. \nCurrently, if two repositories have the same name, they will conflict \nand bad things will happen.\n\n\nWhen a repository is installed to the repos/ directory, the current \nversion of that repository is written to the \nproject.state\n file.  The \nproject state file contains the currently installed version of any given \nrepository.  This way, the current set of repositories can be recreated \nfrom the \nproject.state\n file reliably, whereas the \nproject.yml\n file can \nhave higher level directives (i.e. include 0.8-stable.)\n\n\nResolving dependencies\n\n\nAt the moment, all dependencies must match, otherwise newt will provide \nan error.  As an example, if you have a set of dependencies such that:\n\n\napache-mynewt-core depends on sterlys-little-repo 0.6-stable\napache-mynewt-core depends on sterlys-big-repo 0.5.1\nsterlys-big-repo-0.5.1
  depends on sterlys-little-repo 0.6.2\n\n\n\n\n\n\n\nwhere 0.6-stable is 0.6.3, the newt tool will try and resolve the dependency to \nsterlys-little-repo.  It will notice that there are two conflicting \nversions of the same repository, and not perform installation.\n\n\nIn the future Newt will be smarter about loading in all dependencies, \nand then looking to satisfy those dependencies to the best match of all \npotential options.", 
-            "title": "Turn project into a repo"
+            "title": "Turn project into a Repo"
         }, 
         {
             "location": "/os/tutorials/repo/create_repo/#create-a-repo-out-of-a-project", 
@@ -967,7 +997,7 @@
         }, 
         {
             "location": "/os/tutorials/tasks_lesson/", 
-            "text": "Core OS Lesson: Tasks and Priority Management\n\n\nTarget Platform: Arduino M0 Pro\n (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nThis lesson is designed to teach core OS concepts and strategies encountered when \nbuilding applications using Mynewt. Specifically, this lesson will cover tasks, \nsimple multitasking, and priority management running on an Arduino M0 Pro.\n\n\nPrerequisites\n\n\nBefore starting, you should read about Mynewt in the \nIntroduction\n \nsection and complete the \nQuickStart\n \nguide and the \nBlinky\n tutorial. \nFurthermore, it may be helpful to take a peek at the \ntask documentation\n \nfor additional insights.\n\n\nEquipment\n\n\nYou will need the following equipment:\n\n\n\n\nArduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nComputer with Mynewt installed\n\n\nUSB to Micro USB Cable\n\n\n\n\nBuild Your Application\n\n\nTo save time, we will simply modify the Blinky app. We'll add the Tas
 k Management code to\nthe Blinky app. Follow the \nArduino Zero Blinky tutorial\n \nto create a new project and build your bootloader and application. Finally, build and \nload the application to your Arduino to verify that everything is in order. Now let\u2019s get started!\n\n\nCreate a New Task\n\n\nThe purpose of this section is to give an introduction to the important aspects of tasks \nand how to properly initialize them. First, let\u2019s define a second task called \nwork_task\n \nin main.c (located in apps/blinky/src):\n\n\nstruct\n \nos_task\n \nwork_task\n;\n\n\n\n\n\nA task is represented by the \nos_task\n\nstruct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two \nmain elements, a task function (also known as a task handler) and a task stack.\n\n\nNext, let\u2019s take a look at what is required to initialize our new task.\n\n\nTask Stack\n\n\nThe task stack is an array of type \nos_stack_t\n which holds the program sta
 ck frames. Mynewt gives \nus the ability to set the stack size for a task giving the application developer room to optimize \nmemory usage. Since we\u2019re not short on memory, our \nblinky_stack\n and \nwork_stack\n are plenty large \nfor the purpose of this lesson. Notice that the elements in our task stack are of type \nos_stack_t\n \nwhich are generally 32 bits, making our entire stack 1024 Bytes.\n\n\n  \n#define WORK_STACK_SIZE OS_STACK_ALIGN(256)\n\n  \nos_stack_t\n \nwork_stack\n[\nWORK_STACK_SIZE\n];\n\n\n\n\n\nNote: The \nOS_STACK_ALIGN\n macro is used to align the stack based on the hardware architecture.\n\n\nTask Function\n\n\nThe task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our \nBlinky app the task function, named \nblinky_task_handler()\n, is initially called when we call \nos_start()\n \nin \nmain()\n. In general, the task function is where the majority of work is done by a task. Let\u2019s write \na task fu
 nction for \nwork_task\n called \nwork_task_handler()\n:\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n    \nstruct\n \nos_task\n \n*t\n;\n\n    \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n    \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n    \nwhile\n (\n1\n) {\n        \nt\n \n=\n \nos_sched_get_current_task\n();\n        \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n        \n/* Do work... */\n\n    }\n}\n\n\n\n\n\nThe task function is called when the task is initially put into the \nrunning\n state by the scheduler. \nWe use an infinite loop to ensure that the task function never returns. Our assertion that the current \ntask's handler is the same as our task handler is for illustration purposes only and does not need to \nbe in most task functions.\n\n\nTask Priority\n\n\nAs a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher \npriority; the highest priority being 0 and the lowest 255. Thus, before initializing ou
 r task, we \nmust choose a priority defined as a macro variable.\n\n\nLet\u2019s set the priority of \nwork_task\n to 0, because everyone knows that work is more important than blinking.\n\n\n  \n#define WORK_TASK_PRIO (0)\n\n\n\n\n\n\nInitialization\n\n\nTo initialize a new task we use \nos_task_init()\n \nwhich takes a number of arguments including our new task function, stack, and priority. Much like \nblinky_task\n, \nwe\u2019re going to initialize \nwork_task\n inside \ninit_tasks\n to keep our main function clean.\n\n\nint\n\n\ninit_tasks\n(\nvoid\n)\n{\n    \n/* \u2026 */\n\n    \nos_task_init\n(\nwork_task\n, \nwork\n, \nwork_task_handler\n, \nNULL\n,\n            \nWORK_TASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nwork_stack\n,\n            \nWORK_STACK_SIZE\n);\n\n    \ntasks_initialized\n \n=\n \n1\n;\n    \nreturn\n \n0\n;\n}\n\n\n\n\n\nAnd that\u2019s it! Now run your application using the newt run command.\n\n\n$ newt run arduino_blinky 0.0.0\n\n\n\n\n\nWhen GDB appears press C
  then Enter to continue and \u2026 \nwait, why doesn't our LED blink anymore?\n\n\nReview\n\n\nBefore we run our new app, let\u2019s review what we need in order to create a task. This is a general case for a new task called mytask:\n\n\n1)\n   Define a new task, task stack, and priority:\n\n\n/* My Task */\n\n\nstruct\n \nos_task\n \nmytask\n\n\n/* My Task Stack */\n\n\n#define MYTASK_STACK_SIZE OS_STACK_ALIGN(256)\n\n\nos_stack_t\n \nmytask_stack\n[\nMYTASK_STACK_SIZE\n];\n\n/* My Task Priority */\n\n\n#define MYTASK_PRIO (0)\n\n\n\n\n\n\n2)\n Define task function:\n\n\nvoid\n \n\nmytask_handler\n(\nvoid\n \n*arg\n)\n{\n  \nwhile\n (\n1\n) {\n      \n/* ... */\n\n  }\n}\n\n\n\n\n\n3)\n Initialize task before calling \nos_start()\n:\n\n\nos_task_init\n(\nmytask\n, \nmytask\n, \nmytask_handler\n, \nNULL\n, \n            \nMYTASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nmytask_stack\n,\n            \nMYTASK_STACK_SIZE\n);\n\n\n\n\n\nTask Priority, Preempting, and Context Switching\n\n\nA preem
 ptive RTOS is one in which a higher priority task that is \nready to run\n will preempt (i.e. take the \nplace of) the lower priority task which is \nrunning\n. When a lower priority task is preempted by a higher \npriority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new \ntask is switched in.\n\n\nIn our example, \nwork_task\n has a higher priority than \nblinky_task\n and, because it is never put into a \n\nsleep\n state, holds the processor focus on its context. Let\u2019s give \nwork_task\n a delay and some simulated \nwork to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is \ndependent on the board. Therefore, we multiply \nOS_TICKS_PER_SEC\n, which is defined in the MCU, by the \nnumber of seconds we wish to delay.\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n    \nstruct\n \nos_task\n \n*t\n;\n\n    \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n    \nhal_gpio_init_o
 ut\n(\ng_led_pin\n, \n1\n);\n\n    \nwhile\n (\n1\n) {\n        \nt\n \n=\n \nos_sched_get_current_t\n:ask\n();\n        \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n        \n/* Do work... */\n\n        \nint\n \ni\n;\n        \nfor\n(\ni\n \n=\n \n0\n; \ni\n \n \n1000000\n; \n++i\n) {\n            \n/* Simulate doing a noticeable amount of work */\n\n            \nhal_gpio_set\n(\ng_led_pin\n);\n        }\n        \nos_time_delay\n(\n3\n*OS_TICKS_PER_SECOND\n);\n    }\n}\n\n\n\n\n\nIn order to notice the LED changing, modify the time delay in \nblinky_task_handler()\n to blink at a higher frequency.\n\n\nos_time_delay\n(\nOS_TICKS_PER_SEC/\n10\n);\n\n\n\n\n\nBefore we run the app, let\u2019s predict the behavior. With the newest additions to \nwork_task_handler()\n, \nour first action will be to sleep for three seconds. This will allow \nblinky_task\n to take over the CPU \nand blink to its heart\u2019s content. After three seconds, \nwork_task\n will wake up and be m
 ade \nready to run\n, \ncausing it to preempt \nblinky_task\n. The LED will then remain lit for a short period while \nwork_task\n \nloops, then blink again for another three seconds while \nwork_task\n sleeps. \n\n\nVoila, you should see that our prediction was correct! \n\n\nPriority Management Considerations\n\n\nWhen projects grow in scope, from blinking LEDs into more sophisticated applications, the number of \ntasks needed increases alongside complexity. It remains important, then, that each of our tasks is \ncapable of doing its work within a reasonable amount of time.\n\n\nSome tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, \nthe Shell task should be given a high priority. On the other hand, tasks which may be communicating over \na network, or processing data, should be given a low priority in order to not hog the CPU.\n\n\nThe diagram below showcases the different scheduling patterns we. would expect from swapping blink
 y and \nwork tasks priorities.\n\n\n\n\nIn the second case where \nblinky_task\n has a higher priority, the \u201cwork\u201d done by \nwork_task\n would be \nexecuted during the millisecond delays in \nblinky_task\n, saving us idle time compared to the first case.\n\n\nNote:\n Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.\n\n\nComparing Priority Strategies\n\n\nInstead of stepping through a bunch of changes to our blinky app, clone my task lesson application from \ngithub and copy an existing target.\n\n\nChange directory into apps and clone the repository to get our new\nfiles:\n\n\n$ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git\n\n\n\n\n\nChange directory back to your project root and copy  the arduino_blinky target to a new target called task_tgt.\n\n\n$\n \nnewt\n \ntarget\n \ncopy\n \narduino_blinky\n \ntask_tgt\n\n\n\n\n\n\nSet a new app location.\n\n\n$\n \nnewt\n \ntarget\n \nset\n \ntask_tgt\n 
 \napp=apps/mynewt_tasks_lesson\n\n\n\n\n\n\nNow let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing t\no use the \nconsole\n and \nshell\n \nto follow our tasks through execution.\n\n\nAdditionally, we have a number of different tasks:\n\n\n\n\n\n\nTask A\n (\na_task\n):\n\n\n\n\nPriority\n: 3 \u2192 2\n\n\nDescription\n: Task A is supposed to represent a task which frequently does a small amount \nof work, such as one which rapidly polls a sensor for data. Much like \nblinky_task\n, Task A will \nloop 10,000 times then wait 1 millisecond. Priority is changed by \ntimer_task\n after the first simulation.\n\n\n\n\n\n\n\n\nTask B\n (\nb_task\n):\n\n\n\n\nPriority\n: 2 \u2192 3\n\n\nDescription\n: Task B is supposed to represent a task which does a large amount of work \nrelatively infrequently, such as one which sends/receives data from the cloud. Like work_task, \nTask B will loop 1,000,000 times then wait 3 seconds. Priority is cha
 nged by timer_task after \nthe first simulation.\n\n\n\n\n\n\n\n\nTimer Task\n (\ntimer_task\n):\n\n\n\n\nPriority\n: 1\n\n\nDescription\n: With default settings, Timer Task will wait 20 seconds then print the first \nsimulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the \nsimulation. After the second simulation, timer will again print simulation data then compare the \ntwo and calculate a final speedup (simulation2 / simulation1).\n\n\n\n\n\n\n\n\nShell Task\n:\n\n\n\n\nPriority\n: 0\n\n\nDescription\n: Task used by Shell behind the scenes to communicate with the serial port.\n\n\n\n\n\n\n\n\nConnecting to the Serial Console\n\n\nBefore running our new app, we must first connect to the serial console. First make sure the \nmynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been \nmoved to master). \n\n\n$ cd repos/mynewt_arduino_zero\n$ git checkout develop\n\n\n\n\n\nOpen a new terminal window and
  list your serial connections to find our Arduino.\n\n\n$\n \nls\n \n/dev/tty\n.\n*\n\n\n\n/dev/tty\n.\nBluetooth-Incoming-Port\n \n/dev/tty\n.\nusbmodem14132\n\n\n\n\n\n\nIn the same window, connect to the serial port using a serial communication program. \nIn this case I\u2019ll be using mincom as it can scroll through output.\n\n\n$\n \nminicom\n \n-D\n \n/dev/tty\n.\nusbmodem14132\n \n-b\n \n115200\n\n\n\n\n\n\nIf you see minicom welcome you, you\u2019re ready to move on!\n\n\nOutput Analysis\n\n\nRun our new target, task_tgt, and you should see an output similar to this:\n\n\nStarting First Simulation...\n1:     Task B: 0% \n78:     Task B: 1% \n155:     Task B: 2% \n257:     Task B: 3% \n359:     Task B: 4% \n461:     Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n  Priority: 3\n  Loop count: 162849\n  Cycle count: 16.28\n  Run time: 1.40 sec\n\n \n Task B \n\n  Priority: 2\n  Loop count: 1345852\n  Cycle count: 1.34\n  Run time: 17.0 sec\n\n 
 Total loops: 1508709\n\n20023:   Switching priorities and restarting...\n20111:   Task A looped\n20113:     Task B: 0% \n20191:     Task B: 1% \n20297:   Task A looped\n20356:     Task B: 2% \n20483:   Task A looped\n20545:     Task B: 3% \n20669:   Task A looped\n20734:     Task B: 4% \n20855:   Task A looped\n20923:     Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n  Priority: 2\n  Loop count: 1080000\n  Cycle count: 108.0\n  Run time: 9.28 sec\n\n \n Task B \n\n  Priority: 3\n  Loop count: 830356\n  Cycle count: 0.83\n  Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26\n\n\n\n\n\nThe console output reaffirms our previous prediction and makes both the scheduling differences \nand subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences \nbefore we delve into efficiency.\n\n\nIn the first case, where Task B\u2019s priority is higher than that of Task A, we see A get 
 starved \nby Task B\u2019s long execution time. \nStarvation\n occurs when one task hogs the processor, essentially \n\u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, \nTask A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained \nbefore, processes which are expected to run for long periods of time (e.g. network communication, \ndata processing) should be given higher priorities in order to combat starvation.\n\n\nIn the second simulation with priorities swapped, we can see Task B only running during the \nmillisecond delays when Task A is \nsleeping\n. Although having Task B only run during these \ndelays slows its execution time, we benefit from un-starving Task A and using the processor \nat a higher efficiency.\n\n\nThe bottom line speedup gives us an immediate and clear indication that we have improved our \nability to process work (i.e throughput). In our second run,
  we processed an additional 400,000 \nloop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor \nfound in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities \nto a serial program. However, we accomplished this by simply setting priorities on a single core \nprocessor \u2013 not bad!\n\n\nNOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers \nto the change in execution time between a serial and parallel program executing over the same \nproblem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect \non scheduling and throughput in our specific context.\n\n\nEfficiency Isn\u2019t Everything\n\n\nUsing the processor during every OS tick isn\u2019t always the best course of action. If we modify \nTask A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our \nspeedup to 1.44. This, h
 owever, reduces our ability to process work from Task B who ends up \nonly completing 18% of its work cycle after the second simulation. That would mean, at that \nrate, Task B would take over a minute to finish one cycle.\n\n\nFeel free to play around with the testing parameters to study the different changes yourself!\n\n\nConclusion\n\n\nMoving forward, tasks are just the tip of the iceberg. The \nscheduler\n, \n\nevent queues\n, \n\nsemaphores\n, and \n\nmutexes\n also add to tasks functionality, \nincreasing our ability as the developer to control greater numbers of tasks more intricately. For \nexample, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities \nhave changed, allowing us us to use priorities dynamically. When running multiple tasks, logging \nthrough either the built-in \nLogs\n module \n(not covered in this lesson) or through the serial console/shell can be very useful for debugging \nyour application. In the end, the way you 
 manage your tasks depends on the context of your \napplication. You should assign priorities based on execution time, urgency, and frequency, among \nother things.\n\n\nKeep blinking and happy hacking!", 
+            "text": "Core OS Lesson: Tasks and Priority Management\n\n\nTarget Platform: Arduino M0 Pro\n (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nThis lesson is designed to teach core OS concepts and strategies encountered when \nbuilding applications using Mynewt. Specifically, this lesson will cover tasks, \nsimple multitasking, and priority management running on an Arduino M0 Pro.\n\n\nPrerequisites\n\n\nBefore starting, you should read about Mynewt in the \nIntroduction\n \nsection and complete the \nQuickStart\n \nguide and the \nBlinky\n tutorial. \nFurthermore, it may be helpful to take a peek at the \ntask documentation\n \nfor additional insights.\n\n\nEquipment\n\n\nYou will need the following equipment:\n\n\n\n\nArduino M0 Pro (or legacy Arduino Zero or Zero Pro, but not Arduino M0)\n\n\nComputer with Mynewt installed\n\n\nUSB to Micro USB Cable\n\n\n\n\nBuild Your Application\n\n\nTo save time, we will simply modify the Blinky app. We'll add the Tas
 k Management code to\nthe Blinky app. Follow the \nArduino Zero Blinky tutorial\n \nto create a new project and build your bootloader and application. Finally, build and \nload the application to your Arduino to verify that everything is in order. Now let\u2019s get started!\n\n\nCreate a New Task\n\n\nThe purpose of this section is to give an introduction to the important aspects of tasks \nand how to properly initialize them. First, let\u2019s define a second task called \nwork_task\n \nin main.c (located in apps/blinky/src):\n\n\nstruct\n \nos_task\n \nwork_task\n;\n\n\n\n\n\nA task is represented by the \nos_task\n \nstruct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two \nmain elements, a task function (also known as a task handler) and a task stack.\n\n\nNext, let\u2019s take a look at what is required to initialize our new task.\n\n\nTask Stack\n\n\nThe task stack is an array of type \nos_stack_t\n which holds the program st
 ack frames. Mynewt gives \nus the ability to set the stack size for a task giving the application developer room to optimize \nmemory usage. Since we\u2019re not short on memory, our \nblinky_stack\n and \nwork_stack\n are plenty large \nfor the purpose of this lesson. Notice that the elements in our task stack are of type \nos_stack_t\n \nwhich are generally 32 bits, making our entire stack 1024 Bytes.\n\n\n  \n#define WORK_STACK_SIZE OS_STACK_ALIGN(256)\n\n\n\n\n\n\nNote: The \nOS_STACK_ALIGN\n macro is used to align the stack based on the hardware architecture.\n\n\nTask Function\n\n\nThe task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our \nBlinky app the task function, named \nblinky_task_handler()\n, is initially called when we call \nos_start()\n \nin \nmain()\n. In general, the task function is where the majority of work is done by a task. Let\u2019s write \na task function for \nwork_task\n called \nwork_task_handler()\
 n:\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n    \nstruct\n \nos_task\n \n*t\n;\n\n    \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n    \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n    \nwhile\n (\n1\n) {\n        \nt\n \n=\n \nos_sched_get_current_task\n();\n        \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n        \n/* Do work... */\n\n    }\n}\n\n\n\n\n\nThe task function is called when the task is initially put into the \nrunning\n state by the scheduler. \nWe use an infinite loop to ensure that the task function never returns. Our assertion that the current \ntask's handler is the same as our task handler is for illustration purposes only and does not need to \nbe in most task functions.\n\n\nTask Priority\n\n\nAs a preemptive, multitasking RTOS, Mynewt decides which tasks to run based on which has a higher \npriority; the highest priority being 0 and the lowest 255. Thus, before initializing our task, we \nmust choose a priority defined as a macro
  variable.\n\n\nLet\u2019s set the priority of \nwork_task\n to 0, because everyone knows that work is more important than blinking.\n\n\n  \n#define WORK_TASK_PRIO (0)\n\n\n\n\n\n\nInitialization\n\n\nTo initialize a new task we use \nos_task_init()\n \nwhich takes a number of arguments including our new task function, stack, and priority. Much like \nblinky_task\n, \nwe\u2019re going to initialize \nwork_task\n inside \ninit_tasks\n to keep our main function clean. We'll set the task stack here and pass it to the \nos_task_init()\n function as well.\n\n\nint\n\n\ninit_tasks\n(\nvoid\n)\n{\n    \n/* \u2026 */\n\n    \nos_stack_t\n \n*work_stack\n;\n    \nwork_stack\n \n=\n \nmalloc\n(\nsizeof\n(\nos_stack_t\n)\n*WORK_STACK_SIZE\n);\n\n    \nassert\n(\npstack\n);\n    \nos_task_init\n(\nwork_task\n, \nwork\n, \nwork_task_handler\n, \nNULL\n,\n            \nWORK_TASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nwork_stack\n,\n            \nWORK_STACK_SIZE\n);\n\n    \ntasks_initialized\n \n=\n \n1
 \n;\n    \nreturn\n \n0\n;\n}\n\n\n\n\n\nAnd that\u2019s it! Now run your application using the newt run command.\n\n\n$ newt run arduino_blinky 0.0.0\n\n\n\n\n\nWhen GDB appears press C then Enter to continue and \u2026 \nwait, why doesn't our LED blink anymore?\n\n\nReview\n\n\nBefore we run our new app, let\u2019s review what we need in order to create a task. This is a general case for a new task called mytask:\n\n\n1)\n   Define a new task, task stack, and priority:\n\n\n/* My Task */\n\n\nstruct\n \nos_task\n \nmytask\n\n\n/* My Task Stack */\n\n\n#define MYTASK_STACK_SIZE OS_STACK_ALIGN(256)\n\n\nos_stack_t\n \nmytask_stack\n[\nMYTASK_STACK_SIZE\n];\n\n/* My Task Priority */\n\n\n#define MYTASK_PRIO (0)\n\n\n\n\n\n\n2)\n Define task function:\n\n\nvoid\n \n\nmytask_handler\n(\nvoid\n \n*arg\n)\n{\n  \nwhile\n (\n1\n) {\n      \n/* ... */\n\n  }\n}\n\n\n\n\n\n3)\n Initialize task before calling \nos_start()\n:\n\n\nos_task_init\n(\nmytask\n, \nmytask\n, \nmytask_handler\n, \nN
 ULL\n, \n            \nMYTASK_PRIO\n, \nOS_WAIT_FOREVER\n, \nmytask_stack\n,\n            \nMYTASK_STACK_SIZE\n);\n\n\n\n\n\nTask Priority, Preempting, and Context Switching\n\n\nA preemptive RTOS is one in which a higher priority task that is \nready to run\n will preempt (i.e. take the \nplace of) the lower priority task which is \nrunning\n. When a lower priority task is preempted by a higher \npriority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new \ntask is switched in.\n\n\nIn our example, \nwork_task\n has a higher priority than \nblinky_task\n and, because it is never put into a \n\nsleep\n state, holds the processor focus on its context. Let\u2019s give \nwork_task\n a delay and some simulated \nwork to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is \ndependent on the board. Therefore, we multiply \nOS_TICKS_PER_SEC\n, which is defined in the MCU, by the \nnumber of s
 econds we wish to delay.\n\n\nvoid\n\n\nwork_task_handler\n(\nvoid\n \n*arg\n)\n{\n    \nstruct\n \nos_task\n \n*t\n;\n\n    \ng_led_pin\n \n=\n \nLED_BLINK_PIN\n;\n    \nhal_gpio_init_out\n(\ng_led_pin\n, \n1\n);\n\n    \nwhile\n (\n1\n) {\n        \nt\n \n=\n \nos_sched_get_current_t\n:ask\n();\n        \nassert\n(\nt-\nt_func\n \n==\n \nwork_task_handler\n);\n        \n/* Do work... */\n\n        \nint\n \ni\n;\n        \nfor\n(\ni\n \n=\n \n0\n; \ni\n \n \n1000000\n; \n++i\n) {\n            \n/* Simulate doing a noticeable amount of work */\n\n            \nhal_gpio_set\n(\ng_led_pin\n);\n        }\n        \nos_time_delay\n(\n3\n*OS_TICKS_PER_SECOND\n);\n    }\n}\n\n\n\n\n\nIn order to notice the LED changing, modify the time delay in \nblinky_task_handler()\n to blink at a higher frequency.\n\n\nos_time_delay\n(\nOS_TICKS_PER_SEC/\n10\n);\n\n\n\n\n\nBefore we run the app, let\u2019s predict the behavior. With the newest additions to \nwork_task_handler()\n, \nour first action 
 will be to sleep for three seconds. This will allow \nblinky_task\n to take over the CPU \nand blink to its heart\u2019s content. After three seconds, \nwork_task\n will wake up and be made \nready to run\n, \ncausing it to preempt \nblinky_task\n. The LED will then remain lit for a short period while \nwork_task\n \nloops, then blink again for another three seconds while \nwork_task\n sleeps. \n\n\nVoila, you should see that our prediction was correct! \n\n\nPriority Management Considerations\n\n\nWhen projects grow in scope, from blinking LEDs into more sophisticated applications, the number of \ntasks needed increases alongside complexity. It remains important, then, that each of our tasks is \ncapable of doing its work within a reasonable amount of time.\n\n\nSome tasks, such as the Shell task, execute quickly and require almost instantaneous response. Therefore, \nthe Shell task should be given a high priority. On the other hand, tasks which may be communicating over \na networ
 k, or processing data, should be given a low priority in order to not hog the CPU.\n\n\nThe diagram below showcases the different scheduling patterns we. would expect from swapping blinky and \nwork tasks priorities.\n\n\n\n\nIn the second case where \nblinky_task\n has a higher priority, the \u201cwork\u201d done by \nwork_task\n would be \nexecuted during the millisecond delays in \nblinky_task\n, saving us idle time compared to the first case.\n\n\nNote:\n Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.\n\n\nComparing Priority Strategies\n\n\nInstead of stepping through a bunch of changes to our blinky app, clone my task lesson application from \ngithub and copy an existing target.\n\n\nChange directory into apps and clone the repository to get our new\nfiles:\n\n\n$ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git\n\n\n\n\n\nChange directory back to your project root and copy  the arduino_blinky target to
  a new target called task_tgt.\n\n\n$\n \nnewt\n \ntarget\n \ncopy\n \narduino_blinky\n \ntask_tgt\n\n\n\n\n\n\nSet a new app location.\n\n\n$\n \nnewt\n \ntarget\n \nset\n \ntask_tgt\n \napp=apps/mynewt_tasks_lesson\n\n\n\n\n\n\nNow let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead \nchoosing to use the \nconsole\n \nand \nshell\n to follow our tasks through execution.\n\n\nAdditionally, we have a number of different tasks:\n\n\n\n\n\n\nTask A\n (\na_task\n):\n\n\n\n\nPriority\n: 3 \u2192 2\n\n\nDescription\n: Task A is supposed to represent a task which frequently does a small amount \nof work, such as one which rapidly polls a sensor for data. Much like \nblinky_task\n, Task A will \nloop 10,000 times then wait 1 millisecond. Priority is changed by \ntimer_task\n after the first simulation.\n\n\n\n\n\n\n\n\nTask B\n (\nb_task\n):\n\n\n\n\nPriority\n: 2 \u2192 3\n\n\nDescription\n: Task B is supposed to represent a task which does a lar
 ge amount of work \nrelatively infrequently, such as one which sends/receives data from the cloud. Like work_task, \nTask B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after \nthe first simulation.\n\n\n\n\n\n\n\n\nTimer Task\n (\ntimer_task\n):\n\n\n\n\nPriority\n: 1\n\n\nDescription\n: With default settings, Timer Task will wait 20 seconds then print the first \nsimulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the \nsimulation. After the second simulation, timer will again print simulation data then compare the \ntwo and calculate a final speedup (simulation2 / simulation1).\n\n\n\n\n\n\n\n\nShell Task\n:\n\n\n\n\nPriority\n: 0\n\n\nDescription\n: Task used by Shell behind the scenes to communicate with the serial port.\n\n\n\n\n\n\n\n\nConnecting to the Serial Console\n\n\nBefore running our new app, we must first connect to the serial console. First make sure the \nmynewt_arduino_zero reposito
 ry is set to the develop branch. (Remove once changes have been \nmoved to master). \n\n\n$ cd repos/mynewt_arduino_zero\n$ git checkout develop\n\n\n\n\n\nYou should already be familiar with the \nSerial Port Setup and Configuration\n, but if\nyou're not, you can go there now and then come back. \n\n\nOutput Analysis\n\n\nRun our new target, task_tgt, and you should see an output similar to this:\n\n\nStarting First Simulation...\n1:     Task B: 0% \n78:     Task B: 1% \n155:     Task B: 2% \n257:     Task B: 3% \n359:     Task B: 4% \n461:     Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n  Priority: 3\n  Loop count: 162849\n  Cycle count: 16.28\n  Run time: 1.40 sec\n\n \n Task B \n\n  Priority: 2\n  Loop count: 1345852\n  Cycle count: 1.34\n  Run time: 17.0 sec\n\n Total loops: 1508709\n\n20023:   Switching priorities and restarting...\n20111:   Task A looped\n20113:     Task B: 0% \n20191:     Task B: 1% \n20297:   Task A looped\n20356:     Ta
 sk B: 2% \n20483:   Task A looped\n20545:     Task B: 3% \n20669:   Task A looped\n20734:     Task B: 4% \n20855:   Task A looped\n20923:     Task B: 5% \n\n\nsnip\n\n\n========== Timer Expired ==========\n\n \n Task A \n\n  Priority: 2\n  Loop count: 1080000\n  Cycle count: 108.0\n  Run time: 9.28 sec\n\n \n Task B \n\n  Priority: 3\n  Loop count: 830356\n  Cycle count: 0.83\n  Run time: 10.72 sec\n\n Total loops: 1910404\n\n40058:\n\n Final Speedup (Sim2 / Sim1): 1.26\n\n\n\n\n\nThe console output reaffirms our previous prediction and makes both the scheduling differences \nand subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences \nbefore we delve into efficiency.\n\n\nIn the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved \nby Task B\u2019s long execution time. \nStarvation\n occurs when one task hogs the processor, essentially \n\u201cstarving\u201d other tasks which also need to run. At the 
 end of the first 20 second simulation period, \nTask A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained \nbefore, processes which are expected to run for long periods of time (e.g. network communication, \ndata processing) should be given higher priorities in order to combat starvation.\n\n\nIn the second simulation with priorities swapped, we can see Task B only running during the \nmillisecond delays when Task A is \nsleeping\n. Although having Task B only run during these \ndelays slows its execution time, we benefit from un-starving Task A and using the processor \nat a higher efficiency.\n\n\nThe bottom line speedup gives us an immediate and clear indication that we have improved our \nability to process work (i.e throughput). In our second run, we processed an additional 400,000 \nloop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor \nfound in every modern PC, a 1.26 speedup would b
 e an ok result to adding multithreading capabilities \nto a serial program. However, we accomplished this by simply setting priorities on a single core \nprocessor \u2013 not bad!\n\n\nNOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers \nto the change in execution time between a serial and parallel program executing over the same \nproblem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect \non scheduling and throughput in our specific context.\n\n\nEfficiency Isn\u2019t Everything\n\n\nUsing the processor during every OS tick isn\u2019t always the best course of action. If we modify \nTask A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our \nspeedup to 1.44. This, however, reduces our ability to process work from Task B who ends up \nonly completing 18% of its work cycle after the second simulation. That would mean, at that \nrate, Task B would
  take over a minute to finish one cycle.\n\n\nFeel free to play around with the testing parameters to study the different changes yourself!\n\n\nConclusion\n\n\nMoving forward, tasks are just the tip of the iceberg. The \nscheduler\n, \n\nevent queues\n, \n\nsemaphores\n, and \n\nmutexes\n also add to tasks functionality, \nincreasing our ability as the developer to control greater numbers of tasks more intricately. For \nexample, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities \nhave changed, allowing us us to use priorities dynamically. When running multiple tasks, logging \nthrough either the built-in \nLogs\n module \n(not covered in this lesson) or through the serial console/shell can be very useful for debugging \nyour application. In the end, the way you manage your tasks depends on the context of your \napplication. You should assign priorities based on execution time, urgency, and frequency, among \nother things.\n\n\nKeep blinking
  and happy hacking!", 
             "title": "Tasks and Priority Management"
         }, 
         {
@@ -992,12 +1022,12 @@
         }, 
         {
             "location": "/os/tutorials/tasks_lesson/#create-a-new-task", 
-            "text": "The purpose of this section is to give an introduction to the important aspects of tasks \nand how to properly initialize them. First, let\u2019s define a second task called  work_task  \nin main.c (located in apps/blinky/src):  struct   os_task   work_task ;  A task is represented by the  os_task \nstruct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two \nmain elements, a task function (also known as a task handler) and a task stack.  Next, let\u2019s take a look at what is required to initialize our new task.", 
+            "text": "The purpose of this section is to give an introduction to the important aspects of tasks \nand how to properly initialize them. First, let\u2019s define a second task called  work_task  \nin main.c (located in apps/blinky/src):  struct   os_task   work_task ;  A task is represented by the  os_task  \nstruct which will hold the task\u2019s information (name, state, priority, etc.). A task is made up of two \nmain elements, a task function (also known as a task handler) and a task stack.  Next, let\u2019s take a look at what is required to initialize our new task.", 
             "title": "Create a New Task"
         }, 
         {
             "location": "/os/tutorials/tasks_lesson/#task-stack", 
-            "text": "The task stack is an array of type  os_stack_t  which holds the program stack frames. Mynewt gives \nus the ability to set the stack size for a task giving the application developer room to optimize \nmemory usage. Since we\u2019re not short on memory, our  blinky_stack  and  work_stack  are plenty large \nfor the purpose of this lesson. Notice that the elements in our task stack are of type  os_stack_t  \nwhich are generally 32 bits, making our entire stack 1024 Bytes.     #define WORK_STACK_SIZE OS_STACK_ALIGN(256) \n   os_stack_t   work_stack [ WORK_STACK_SIZE ];  Note: The  OS_STACK_ALIGN  macro is used to align the stack based on the hardware architecture.", 
+            "text": "The task stack is an array of type  os_stack_t  which holds the program stack frames. Mynewt gives \nus the ability to set the stack size for a task giving the application developer room to optimize \nmemory usage. Since we\u2019re not short on memory, our  blinky_stack  and  work_stack  are plenty large \nfor the purpose of this lesson. Notice that the elements in our task stack are of type  os_stack_t  \nwhich are generally 32 bits, making our entire stack 1024 Bytes.     #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.", 
             "title": "Task Stack"
         }, 
         {
@@ -1012,7 +1042,7 @@
         }, 
         {
             "location": "/os/tutorials/tasks_lesson/#initialization", 
-            "text": "To initialize a new task we use  os_task_init()  \nwhich takes a number of arguments including our new task function, stack, and priority. Much like  blinky_task , \nwe\u2019re going to initialize  work_task  inside  init_tasks  to keep our main function clean.  int  init_tasks ( void )\n{\n     /* \u2026 */ \n     os_task_init ( work_task ,  work ,  work_task_handler ,  NULL ,\n             WORK_TASK_PRIO ,  OS_WAIT_FOREVER ,  work_stack ,\n             WORK_STACK_SIZE );\n\n     tasks_initialized   =   1 ;\n     return   0 ;\n}  And that\u2019s it! Now run your application using the newt run command.  $ newt run arduino_blinky 0.0.0  When GDB appears press C then Enter to continue and \u2026  wait, why doesn't our LED blink anymore?", 
+            "text": "To initialize a new task we use  os_task_init()  \nwhich takes a number of arguments including our new task function, stack, and priority. Much like  blinky_task , \nwe\u2019re going to initialize  work_task  inside  init_tasks  to keep our main function clean. We'll set the task stack here and pass it to the  os_task_init()  function as well.  int  init_tasks ( void )\n{\n     /* \u2026 */ \n     os_stack_t   *work_stack ;\n     work_stack   =   malloc ( sizeof ( os_stack_t ) *WORK_STACK_SIZE );\n\n     assert ( pstack );\n     os_task_init ( work_task ,  work ,  work_task_handler ,  NULL ,\n             WORK_TASK_PRIO ,  OS_WAIT_FOREVER ,  work_stack ,\n             WORK_STACK_SIZE );\n\n     tasks_initialized   =   1 ;\n     return   0 ;\n}  And that\u2019s it! Now run your application using the newt run command.  $ newt run arduino_blinky 0.0.0  When GDB appears press C then Enter to continue and \u2026  wait, why doesn't our LED blink anymore?", 
             "title": "Initialization"
         }, 
         {
@@ -1032,12 +1062,12 @@
         }, 
         {
             "location": "/os/tutorials/tasks_lesson/#comparing-priority-strategies", 
-            "text": "Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from \ngithub and copy an existing target.  Change directory into apps and clone the repository to get our new\nfiles:  $ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git  Change directory back to your project root and copy  the arduino_blinky target to a new target called task_tgt.  $   newt   target   copy   arduino_blinky   task_tgt   Set a new app location.  $   newt   target   set   task_tgt   app=apps/mynewt_tasks_lesson   Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead choosing t\no use the  console  and  shell  \nto follow our tasks through execution.  Additionally, we have a number of different tasks:    Task A  ( a_task ):   Priority : 3 \u2192 2  Description : Task A is supposed to represent a task which frequently does a small amount \nof work, such as one which rapidly polls a sen
 sor for data. Much like  blinky_task , Task A will \nloop 10,000 times then wait 1 millisecond. Priority is changed by  timer_task  after the first simulation.     Task B  ( b_task ):   Priority : 2 \u2192 3  Description : Task B is supposed to represent a task which does a large amount of work \nrelatively infrequently, such as one which sends/receives data from the cloud. Like work_task, \nTask B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after \nthe first simulation.     Timer Task  ( timer_task ):   Priority : 1  Description : With default settings, Timer Task will wait 20 seconds then print the first \nsimulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the \nsimulation. After the second simulation, timer will again print simulation data then compare the \ntwo and calculate a final speedup (simulation2 / simulation1).     Shell Task :   Priority : 0  Description : Task used by Shell behind the 
 scenes to communicate with the serial port.", 
+            "text": "Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from \ngithub and copy an existing target.  Change directory into apps and clone the repository to get our new\nfiles:  $ cd apps\n$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git  Change directory back to your project root and copy  the arduino_blinky target to a new target called task_tgt.  $   newt   target   copy   arduino_blinky   task_tgt   Set a new app location.  $   newt   target   set   task_tgt   app=apps/mynewt_tasks_lesson   Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead \nchoosing to use the  console  \nand  shell  to follow our tasks through execution.  Additionally, we have a number of different tasks:    Task A  ( a_task ):   Priority : 3 \u2192 2  Description : Task A is supposed to represent a task which frequently does a small amount \nof work, such as one which rapidly polls a sen
 sor for data. Much like  blinky_task , Task A will \nloop 10,000 times then wait 1 millisecond. Priority is changed by  timer_task  after the first simulation.     Task B  ( b_task ):   Priority : 2 \u2192 3  Description : Task B is supposed to represent a task which does a large amount of work \nrelatively infrequently, such as one which sends/receives data from the cloud. Like work_task, \nTask B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after \nthe first simulation.     Timer Task  ( timer_task ):   Priority : 1  Description : With default settings, Timer Task will wait 20 seconds then print the first \nsimulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the \nsimulation. After the second simulation, timer will again print simulation data then compare the \ntwo and calculate a final speedup (simulation2 / simulation1).     Shell Task :   Priority : 0  Description : Task used by Shell behind the 
 scenes to communicate with the serial port.", 
             "title": "Comparing Priority Strategies"
         }, 
         {
             "location": "/os/tutorials/tasks_lesson/#connecting-to-the-serial-console", 
-            "text": "Before running our new app, we must first connect to the serial console. First make sure the \nmynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been \nmoved to master).   $ cd repos/mynewt_arduino_zero\n$ git checkout develop  Open a new terminal window and list your serial connections to find our Arduino.  $   ls   /dev/tty . *  /dev/tty . Bluetooth-Incoming-Port   /dev/tty . usbmodem14132   In the same window, connect to the serial port using a serial communication program. \nIn this case I\u2019ll be using mincom as it can scroll through output.  $   minicom   -D   /dev/tty . usbmodem14132   -b   115200   If you see minicom welcome you, you\u2019re ready to move on!", 
+            "text": "Before running our new app, we must first connect to the serial console. First make sure the \nmynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been \nmoved to master).   $ cd repos/mynewt_arduino_zero\n$ git checkout develop  You should already be familiar with the  Serial Port Setup and Configuration , but if\nyou're not, you can go there now and then come back.", 
             "title": "Connecting to the Serial Console"
         }, 
         {
@@ -1402,7 +1432,7 @@
         }, 
         {
             "location": "/os/tutorials/add_newtmgr/", 
-            "text": "Enabling Newt Manager (newtmgr) in a project\n\n\n\n\nThis tutorial explains how to add the newtmgr task to a project so that you can interact with your project over newtmgr.\n\n\n\n\nPre-Requisites\n\n\n\n\nEnsure you have installed \nnewt\n and that the \nnewt command is in your system path. \n\n\nEnsure that you have installed the newtmgr tool \nnewtmgr\n\n\nYou must have Internet connectivity to fetch remote Mynewt components.\n\n\nYou must \ninstall the compiler tools\n to \nsupport native compiling to build the project this tutorial creates.  \n\n\nYou must install the \nSegger JLINK package\n to load your project on the board.\n\n\nCable to establish a serial USB connection between the board and the laptop\n\n\n\n\n\n\nUse an existing project\n\n\nSince all we're doing is adding newtmgr capability to a project, we assume that you have worked through at least some of the other tutorials, and have an existing project.\nFor this example, we'll be modifying t
 he \nble_tiny\n project to enable newtmgr connectivity. We'll be calling our app myble as in that project as well. \nFeel free to use whatever project you'd like though.\n\n\nThe first thing you'll need to add is a new dependency for your app. In the repo for the bletiny app you'll need to add the following line to the pkg.yml file:\n\n\n - libs/newtmgr\n\n\n\n\n\nNow the application will know to pull in the newtmgr code.\n\n\n\n\nModify the source\n\n\nFirst, you'll need to include the newtmgr header file:\n\n\n#include \nnewtmgr/newtmgr.h\n\n\n\n\n\n\nNext, you'll need to declare a task for the newtmgr:\n\n\n#define NEWTMGR_TASK_PRIO (4)\n#define NEWTMGR_TASK_STACK_SIZE (OS_STACK_ALIGN(896))\nos_stack_t newtmgr_stack[NEWTMGR_TASK_STACK_SIZE];\n\n\n\n\n\nNext you'll scroll down (way down) to the \nmain()\n function and find the lines:\n\n\nrc = console_init(shell_console_rx_cb);\nassert(rc == 0);\n\n\n\n\n\nAfter those lines, add:\n\n\nnmgr_task_init(NEWTMGR_TASK_PRIO, newtmgr_stac
 k, NEWTMGR_TASK_STACK_SIZE);\n\n\n\n\n\nBuild targets\n\n\nThen build the two targets.\n\n\n$ newt build nrf52_boot\n\nsnip\n\nApp successfully built: ./bin/nrf52_boot/apps/boot/boot.elf\n$ newt build myble\nCompiling hci_common.c\nCompiling util.c\nArchiving nimble.a\nCompiling os.c\n\nsnip\n\n\n\n\n\n\n\n\nCreate the app image\n\n\nGenerate a signed application image for the \nmyble\n target. The version number is arbitrary.\n\n\n$ newt create-image myble 1.0.0\nApp image succesfully generated: ./bin/makerbeacon/apps/bletiny/bletiny.img\nBuild manifest: ./bin/makerbeacon/apps/bletiny/manifest.json\n\n\n\n\n\n\n\nLoad the image\n\n\nMake 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.\n\n\n$ newt load nrf52_boot\n$ newt load myble\n\n\n\n\n\n\n\nSet up newtmgr connection\n\n\nNewtmgr reqwiures a connection profile in order to connect to your board. If you haven't yet, follow the \ninst
 ructions\n for setting up your connection profile.\n\n\n\n\nConnecting with your app\n\n\nOnce you have a connection profile set up, you can connect to your device with \nnewtmgr -c myconn \ncommand\n to run commands agains your app. \n\n\nTo test and make sure that newtmgr is working, try the echo command:\n\n\n# newtmgr -c myconn echo hello\n{\nr\n: \nhello\n}\n\n\n\n\n\nNewtmgr wraped the response in valid JSON notation. Now let's look at some BLE stats using newtmgr:\n\n\nnewtmgr -c myconn stat ble_att\nReturn Code = 0\nStats Name: ble_att\n  prep_write_req_tx: 0\n  indicate_req_tx: 0\n  write_rsp_tx: 0\n  find_info_req_tx: 0\n  read_rsp_rx: 0\n  read_group_type_rsp_tx: 0\n  indicate_req_rx: 0\n  find_type_value_rsp_tx: 0\n  read_mult_rsp_tx: 0\n  exec_write_req_rx: 0\n  exec_write_rsp_tx: 0\n  error_rsp_tx: 0\n  find_type_value_rsp_rx: 0\n  read_type_req_tx: 0\n  read_type_rsp_rx: 0\n  read_rsp_tx: 0\n  read_blob_req_tx: 0\n  mtu_req_tx: 0\n  read_req_tx: 0\n  read_blob_rsp_tx:
  0\n  read_mult_req_rx: 0\n  write_req_tx: 0\n  prep_write_rsp_tx: 0\n  indicate_rsp_rx: 0\n  write_cmd_rx: 0\n  exec_write_rsp_rx: 0\n  find_info_req_rx: 0\n  mtu_rsp_rx: 0\n  prep_write_req_rx: 0\n  notify_req_rx: 0\n  read_group_type_rsp_rx: 0\n  prep_write_rsp_rx: 0\n  indicate_rsp_tx: 0\n  find_info_rsp_tx: 0\n  read_blob_req_rx: 0\n  read_group_type_req_rx: 0\n  write_cmd_tx: 0\n  mtu_req_rx: 0\n  read_mult_rsp_rx: 0\n  write_rsp_rx: 0\n  write_req_rx: 0\n  read_type_rsp_tx: 0\n  read_mult_req_tx: 0\n  error_rsp_rx: 0\n  find_info_rsp_rx: 0\n  find_type_value_req_tx: 0\n  read_req_rx: 0\n  read_type_req_rx: 0\n  notify_req_tx: 0\n  mtu_rsp_tx: 0\n  find_type_value_req_rx: 0\n  read_blob_rsp_rx: 0\n  read_group_type_req_tx: 0\n  exec_write_req_tx: 0\n\n\n\n\n\nYour application is now able to communicate via newtmgr!", 
+            "text": "Enabling Newt Manager (newtmgr) in a project\n\n\n\n\nThis tutorial explains how to add the newtmgr task to a project so that you can interact with your project over newtmgr.\n\n\n\n\nPre-Requisites\n\n\n\n\nEnsure you have installed \nnewt\n and that the \nnewt command is in your system path. \n\n\nEnsure that you have installed the newtmgr tool \nnewtmgr\n\n\nYou must have Internet connectivity to fetch remote Mynewt components.\n\n\nYou must \ninstall the compiler tools\n to \nsupport native compiling to build the project this tutorial creates.  \n\n\nYou must install the \nSegger JLINK package\n to load your project on the board.\n\n\nCable to establish a serial USB connection between the board and the laptop\n\n\n\n\n\n\nUse an existing project\n\n\nSince all we're doing is adding newtmgr capability to a project, we assume that you have worked through at least some of the other tutorials, and have an existing project.\nFor this example, we'll be modifying t
 he \nble_tiny\n project to enable newtmgr connectivity. We'll be calling our app myble as in that project as well. \nFeel free to use whatever project you'd like though.\n\n\nThe first thing you'll need to add is a new dependency for your app. In the repo for the bletiny app you'll need to add the following line to the pkg.yml file:\n\n\n - libs/newtmgr\n\n\n\n\n\nNow the application will know to pull in the newtmgr code.\n\n\n\n\nModify the source\n\n\nFirst, you'll need to include the newtmgr header file:\n\n\n#include \nnewtmgr/newtmgr.h\n\n\n\n\n\n\nNext, you'll need to declare a task for the newtmgr:\n\n\n#define NEWTMGR_TASK_PRIO (4)\n#define NEWTMGR_TASK_STACK_SIZE (OS_STACK_ALIGN(896))\nos_stack_t newtmgr_stack[NEWTMGR_TASK_STACK_SIZE];\n\n\n\n\n\nNext you'll scroll down (way down) to the \nmain()\n function and find the lines:\n\n\nrc = console_init(shell_console_rx_cb);\nassert(rc == 0);\n\n\n\n\n\nAfter those lines, add:\n\n\nnmgr_task_init(NEWTMGR_TASK_PRIO, newtmgr_stac
 k, NEWTMGR_TASK_STACK_SIZE);\n\n\n\n\n\nBuild targets\n\n\nThen build the two targets.\n\n\n$ newt build nrf52_boot\n\nsnip\n\nApp successfully built: ./bin/nrf52_boot/apps/boot/boot.elf\n$ newt build myble\nCompiling hci_common.c\nCompiling util.c\nArchiving nimble.a\nCompiling os.c\n\nsnip\n\n\n\n\n\n\n\n\nCreate the app image\n\n\nGenerate a signed application image for the \nmyble\n target. The version number is arbitrary.\n\n\n$ newt create-image myble 1.0.0\nApp image succesfully generated: ./bin/makerbeacon/apps/bletiny/bletiny.img\nBuild manifest: ./bin/makerbeacon/apps/bletiny/manifest.json\n\n\n\n\n\n\n\nLoad the image\n\n\nMake 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.\n\n\n$ newt load nrf52_boot\n$ newt load myble\n\n\n\n\n\n\n\nSet up newtmgr connection\n\n\nNewtmgr requires a connection profile in order to connect to your board. If you haven't yet, follow the \ninstr
 uctions\n for setting up your connection profile.\n\n\n\n\nConnecting with your app\n\n\nOnce you have a connection profile set up, you can connect to your device with \nnewtmgr -c myconn \ncommand\n to run commands agains your app. \n\n\nTo test and make sure that newtmgr is working, try the echo command:\n\n\n# newtmgr -c myconn echo hello\n{\nr\n: \nhello\n}\n\n\n\n\n\nNewtmgr wraped the response in valid JSON notation. Now let's look at some BLE stats using newtmgr:\n\n\nnewtmgr -c myconn stat ble_att\nReturn Code = 0\nStats Name: ble_att\n  prep_write_req_tx: 0\n  indicate_req_tx: 0\n  write_rsp_tx: 0\n  find_info_req_tx: 0\n  read_rsp_rx: 0\n  read_group_type_rsp_tx: 0\n  indicate_req_rx: 0\n  find_type_value_rsp_tx: 0\n  read_mult_rsp_tx: 0\n  exec_write_req_rx: 0\n  exec_write_rsp_tx: 0\n  error_rsp_tx: 0\n  find_type_value_rsp_rx: 0\n  read_type_req_tx: 0\n  read_type_rsp_rx: 0\n  read_rsp_tx: 0\n  read_blob_req_tx: 0\n  mtu_req_tx: 0\n  read_req_tx: 0\n  read_blob_rsp_tx: 
 0\n  read_mult_req_rx: 0\n  write_req_tx: 0\n  prep_write_rsp_tx: 0\n  indicate_rsp_rx: 0\n  write_cmd_rx: 0\n  exec_write_rsp_rx: 0\n  find_info_req_rx: 0\n  mtu_rsp_rx: 0\n  prep_write_req_rx: 0\n  notify_req_rx: 0\n  read_group_type_rsp_rx: 0\n  prep_write_rsp_rx: 0\n  indicate_rsp_tx: 0\n  find_info_rsp_tx: 0\n  read_blob_req_rx: 0\n  read_group_type_req_rx: 0\n  write_cmd_tx: 0\n  mtu_req_rx: 0\n  read_mult_rsp_rx: 0\n  write_rsp_rx: 0\n  write_req_rx: 0\n  read_type_rsp_tx: 0\n  read_mult_req_tx: 0\n  error_rsp_rx: 0\n  find_info_rsp_rx: 0\n  find_type_value_req_tx: 0\n  read_req_rx: 0\n  read_type_req_rx: 0\n  notify_req_tx: 0\n  mtu_rsp_tx: 0\n  find_type_value_req_rx: 0\n  read_blob_rsp_rx: 0\n  read_group_type_req_tx: 0\n  exec_write_req_tx: 0\n\n\n\n\n\nYour application is now able to communicate via newtmgr!", 
             "title": "Enable newtmgr in any app"
         }, 
         {
@@ -1442,7 +1472,7 @@
         }, 
         {
             "location": "/os/tutorials/add_newtmgr/#set-up-newtmgr-connection", 
-            "text": "Newtmgr reqwiures a connection profile in order to connect to your board. If you haven't yet, follow the  instructions  for setting up your connection profile.", 
+            "text": "Newtmgr requires a connection profile in order to connect to your board. If you haven't yet, follow the  instructions  for setting up your connection profile.", 
             "title": "Set up newtmgr connection"
         }, 
         {
@@ -1451,8 +1481,58 @@
             "title": "Connecting with your app"
         }, 
         {
+            "location": "/os/tutorials/add_shell/", 
+            "text": "Enabling The Console and Shell in a project\n\n\n\n\nThis tutorial explains how to add the Console and Shell task to a project so that you \ncan interact with your project over a serial line connection.\n\n\n\n\nPre-Requisites\n\n\n\n\nEnsure you have installed \nnewt\n and that the \nnewt command is in your system path. \n\n\nYou must have Internet connectivity to fetch remote Mynewt components.\n\n\nYou must \ninstall the compiler tools\n to \nsupport native compiling to build the project this tutorial creates.  \n\n\nYou must install the \nSegger JLINK package\n to \nload your project on the board.\n\n\nCable to establish a serial USB connection between the board and the laptop\n\n\n\n\n\n\nUse an existing project\n\n\nSince all we're doing is adding the shell and console capability to a project, we assume \nthat you have worked through at least some of the other tutorials, and have an existing project.\nFor this example, we'll be modifying the \nble_tiny\n p
 roject to enable \nthe shell and console connectivity. We'll be calling our app myble as in that project as well. \nFeel free to use whatever project you'd like though.\n\n\n\n\nModify the Dependencies and Configuration\n\n\nThe first thing you'll need to add is a few new dependencies for your app. To add shell support to \nyour app make sure the following \npkg.deps\n are defined in your target's pkg.yml file:\n\n\npkg.deps:\n    - \n@apache-mynewt-core/sys/console/full\n\n    - \n@apache-mynewt-core/sys/shell\n\n    - \n@apache-mynewt-core/sys/sysinit\n\n\n\n\n\n\nThis lets the newt system know that it needs to pull in the code for the console and the shell.\n\n\nNow we'll need to modify the settings for the app to turn on the shell, etc. by modifying the\n\nsyscfg.yml\n file for your target. (Remember, these files are in the targets/\n directory.)\nIf there isn't a \nsyscfg.yml\n file in your target's directory, you will need to create one.\n\n\n# Package: apps/bletiny\n\nsyscfg.
 vals:\n    # Enable the shell task.\n    SHELL_TASK: 1\n    # Enable Console OS Ticks\n    CONSOLE_TICKS: 1\n    # Enable Console Prompt\n    CONSOLE_PROMPT: 1 \n\n\n\n\n\nBuild targets\n\n\nWe're not going to build the bootloader here since we are assuming that you have already\nbuilt and loaded it during previous tutorials.\n\n\n$ newt build myble\nArchiving cbmem.a\nCompiling crc16.c\nCompiling crc8.c\nArchiving crc.a\nCompiling mem.c\nArchiving mem.a\nLinking ~/dev/myproj/bin/targets/myble/app/apps/bletiny/bletiny.elf\nTarget successfully built: targets/myble\n\n\n\n\n\n\n\nCreate the app image\n\n\nGenerate a signed application image for the \nmyble\n target. The version number is arbitrary.\n\n\n$ newt create-image myble 1.0.0\nApp image succesfully generated: ~/dev/myproj/bin/targets/myble/app/apps/bletiny/bletiny.img\n\n\n\n\n\n\n\nLoad the image\n\n\nMake 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.\n\n\n$ newt load myble\n\n\n\n\n\n\n\nSet up Serial connection\n\n\nYou'll need a Serial connection to see the output of your program. You can reference the \nSerial Port Setup\n \nTutorial for more information on setting up your serial communications.\n\n\n\n\nConnecting with your app\n\n\nOnce you have a connection set up, you can connect to your device with \nminicom -D /dev/tty.usbmodem\nport\n -b 115200\n to run connect\nto the console of your app. \n\n\nTo test and make sure that the Shell is running, first just hit \n:\n\n\n3534: \n\n\n\n\n\n\nRemember, we turned the CONSOLE_PROMPT and the CONSOLE_TICKS on earlier. You can try some commands now:\n\n\n3609: \n ?\nCommands:\n8841:     echo         ?    prompt     ticks     tasks  mempools\n8843:     date         b\n8844: \n ticks off\n Console Ticks off\n \n prompt off\n Prompt now off.\nticks on\n33383: Console Ticks on\n\n33568:\nprompt on\n39108: Prompt now on.\n39108:", 
+            "title": "Enable the OS Shell and Console"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#enabling-the-console-and-shell-in-a-project", 
+            "text": "This tutorial explains how to add the Console and Shell task to a project so that you \ncan interact with your project over a serial line connection.", 
+            "title": "Enabling The Console and Shell in a project"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#pre-requisites", 
+            "text": "Ensure you have installed  newt  and that the \nnewt command is in your system path.   You must have Internet connectivity to fetch remote Mynewt components.  You must  install the compiler tools  to \nsupport native compiling to build the project this tutorial creates.    You must install the  Segger JLINK package  to \nload your project on the board.  Cable to establish a serial USB connection between the board and the laptop", 
+            "title": "Pre-Requisites"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#use-an-existing-project", 
+            "text": "Since all we're doing is adding the shell and console capability to a project, we assume \nthat you have worked through at least some of the other tutorials, and have an existing project.\nFor this example, we'll be modifying the  ble_tiny  project to enable \nthe shell and console connectivity. We'll be calling our app myble as in that project as well. \nFeel free to use whatever project you'd like though.", 
+            "title": "Use an existing project"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#modify-the-dependencies-and-configuration", 
+            "text": "The first thing you'll need to add is a few new dependencies for your app. To add shell support to \nyour app make sure the following  pkg.deps  are defined in your target's pkg.yml file:  pkg.deps:\n    -  @apache-mynewt-core/sys/console/full \n    -  @apache-mynewt-core/sys/shell \n    -  @apache-mynewt-core/sys/sysinit   This lets the newt system know that it needs to pull in the code for the console and the shell.  Now we'll need to modify the settings for the app to turn on the shell, etc. by modifying the syscfg.yml  file for your target. (Remember, these files are in the targets/  directory.)\nIf there isn't a  syscfg.yml  file in your target's directory, you will need to create one.  # Package: apps/bletiny\n\nsyscfg.vals:\n    # Enable the shell task.\n    SHELL_TASK: 1\n    # Enable Console OS Ticks\n    CONSOLE_TICKS: 1\n    # Enable Console Prompt\n    CONSOLE_PROMPT: 1", 
+            "title": "Modify the Dependencies and Configuration"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#build-targets", 
+            "text": "We're not going to build the bootloader here since we are assuming that you have already\nbuilt and loaded it during previous tutorials.  $ newt build myble\nArchiving cbmem.a\nCompiling crc16.c\nCompiling crc8.c\nArchiving crc.a\nCompiling mem.c\nArchiving mem.a\nLinking ~/dev/myproj/bin/targets/myble/app/apps/bletiny/bletiny.elf\nTarget successfully built: targets/myble", 
+            "title": "Build targets"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#create-the-app-image", 
+            "text": "Generate a signed application image for the  myble  target. The version number is arbitrary.  $ newt create-image myble 1.0.0\nApp image succesfully generated: ~/dev/myproj/bin/targets/myble/app/apps/bletiny/bletiny.img", 
+            "title": "Create the app image"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#load-the-image", 
+            "text": "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.  $ newt load myble", 
+            "title": "Load the image"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#set-up-serial-connection", 
+            "text": "You'll need a Serial connection to see the output of your program. You can reference the  Serial Port Setup  \nTutorial for more information on setting up your serial communications.", 
+            "title": "Set up Serial connection"
+        }, 
+        {
+            "location": "/os/tutorials/add_shell/#connecting-with-your-app", 
+            "text": "Once you have a connection set up, you can connect to your device with  minicom -D /dev/tty.usbmodem port  -b 115200  to run connect\nto the console of your app.   To test and make sure that the Shell is running, first just hit  :  3534:    Remember, we turned the CONSOLE_PROMPT and the CONSOLE_TICKS on earlier. You can try some commands now:  3609:   ?\nCommands:\n8841:     echo         ?    prompt     ticks     tasks  mempools\n8843:     date         b\n8844:   ticks off\n Console Ticks off\n   prompt off\n Prompt now off.\nticks on\n33383: Console Ticks on\n\n33568:\nprompt on\n39108: Prompt now on.\n39108:", 
+            "title": "Connecting with your app"
+        }, 
+        {
             "location": "/os/tutorials/bletiny_project/", 
-            "text": "Check stats on a BLE device\n\n\n\n\nThis tutorial explains how to run an example BLE app on a board and command it to scan and spew some stats. The stats will be seen over a serial port, not a BLE wireless connection.\n\n\n\n\nPre-Requisites\n\n\n\n\nEnsure you have installed \nnewt\n and that the \nnewt command is in your system path. \n\n\nYou must have Internet connectivity to fetch remote Mynewt components.\n\n\nYou must \ninstall the compiler tools\n to \nsupport native compiling to build the project this tutorial creates.  \n\n\nYou must install the \nSegger JLINK package\n to load your project on the board.\n\n\nYou have a board with BLE radio that is supported by Mynewt. We will use an nRF52 Dev board in this tutorial.\n\n\nCable to establish a serial USB connection between the board and the laptop\n\n\n\n\n\n\nCreate a project\n\n\nUse the Newt tool to create a new project directory containing a skeletal Mynewt framework. Change into the newly created 
 direc

<TRUNCATED>