You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by ad...@apache.org on 2016/11/15 19:28:41 UTC
[2/4] incubator-mynewt-site git commit: This closes #118. Updated
roadmap
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/latest/mkdocs/search_index.json b/latest/mkdocs/search_index.json
index a9c8a23..c1bb107 100644
--- a/latest/mkdocs/search_index.json
+++ b/latest/mkdocs/search_index.json
@@ -37,12 +37,12 @@
},
{
"location": "/about/",
- "text": "Roadmap\n\n\nSome upcoming features:\n\n\n\n\nHost-only BLE stack\n\n\nSerial upgrade of image in bootloader\n\n\nHAL redesign to abstract across a diverse set of chip peripherals (\nView discussion thread\n)\n\n\nHAL for SPI access (master and slave)\n\n\nAbility for drivers to turn on/off low power settings automatically\n\n\nSupport for Wi-Fi controllers via a socket interface\n\n\n\n\n The detailed roadmap is tracked on \nJIRA for Mynewt\n. \n\n\n\n\nFeature Request\n\n\nThe WISHLIST at the top of the roadmap on \nJIRA for Mynewt\n features all the new ideas awaiting discussion and review. Once the community decides to go ahead with a request, it is scheduled into a release. Generally, effort is made to schedule a requested feature into a particular version no later than 6 weeks prior to the planned release date.\n\n\nIf you have suggestions for a new feature, use case, or implementation improvements, file a JIRA ticket with Issue Type set to \"Wish\". Intro
duce it in the \ndev@\n mailing list with a link to the JIRA ticket. This assumes you have signed up for an account on JIRA and submitted a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project.\n\n\n\n\nFAQ\n\n\n Questions? \n Click \nhere",
+ "text": "Roadmap\n\n\nSome upcoming features:\n\n\n\n\nFull IP support\n\n\nLow power support with ability for drivers to turn on/off low power settings automatically\n\n\nSensor API, see \ndiscussion thread\n\n\nSupport for MIPS architecture\n\n\nSupport for additional boards\n\n\n\n\n The detailed roadmap is tracked on \nJIRA for Mynewt\n. \n\n\n\n\nFeature Request\n\n\nThe WISHLIST at the top of the roadmap on \nJIRA for Mynewt\n features all the new ideas awaiting discussion and review. Once the community decides to go ahead with a request, it is scheduled into a release. Generally, effort is made to schedule a requested feature into a particular version no later than 6 weeks prior to the planned release date.\n\n\nIf you have suggestions for a new feature, use case, or implementation improvements, file a JIRA ticket with Issue Type set to \"Wish\". Introduce it in the \ndev@\n mailing list with a link to the JIRA ticket. This assumes you have signed up for an accoun
t on JIRA and submitted a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project.\n\n\n\n\nFAQ\n\n\n Questions? \n Click \nhere",
"title": "About"
},
{
"location": "/about/#roadmap",
- "text": "Some upcoming features: Host-only BLE stack Serial upgrade of image in bootloader HAL redesign to abstract across a diverse set of chip peripherals ( View discussion thread ) HAL for SPI access (master and slave) Ability for drivers to turn on/off low power settings automatically Support for Wi-Fi controllers via a socket interface The detailed roadmap is tracked on JIRA for Mynewt .",
+ "text": "Some upcoming features: Full IP support Low power support with ability for drivers to turn on/off low power settings automatically Sensor API, see discussion thread Support for MIPS architecture Support for additional boards The detailed roadmap is tracked on JIRA for Mynewt .",
"title": "Roadmap"
},
{
@@ -862,7 +862,7 @@
},
{
"location": "/os/tutorials/repo/add_repos/",
- "text": "Adding Repositories to your Project\n\n\nWhat is a Repository\n\n\nA repository is a version-ed Mynewt project, which is a collection of Mynewt packages organized in a specific way for redistribution. \n\n\nWhat differentiates a repository from a Mynewt project is the presence of a\n\nrepository.yml\n file describing the repository. This will be described \nbelow. For a basic understanding of repositories you may read the \nNewt Tool Manual\n and \nHow to create repos\n.\n\n\nNote:\n For the remainder of this document we'll use the term repo as shorthand for a Mynewt repository.\n\n\nRepos 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.\n\n\n\n\nWhy does Mynewt need additional repos?\n\n\nRepos add functionality not included in the Mynewt core. New repos might be created for several reasons.\n\n\n\n\nExpertise\n. Individuals or organizations may have expe
rtise that they want\nto share in the form of repos. For example a chip vendor may\ncreate a repo to hold the Mynewt support for their chips.\n\n\nNon-Core component\n. Some components, although very useful to Mynewt users\nare not core to all Mynewt users. These are likely candidates to be held in \ndifferent repos.\n\n\nSoftware licensing\n. Some software have licenses that make them incompatible\nwith the ASF (Apache Software Foundation) license policies. These may be \nvaluable components to some Mynewt users, but cannot be contained in the \napache-Mynewt-core\n.\n\n\n\n\n\n\nWhat Repos are in my Project\n\n\nThe list of repos used by your project are contained within the \n\nproject.yml\n file. An example can be seen by creating a new project:\n\n\n$ mkdir ~/dev\n$ cd ~/dev\n$ newt new myproj\n$ cd myproj\n\n\n\n\n\n\n\nView the \nproject.yml\n section and you will see a line describing the repos:\n\n\nproject.repositories:\n - apache-Mynewt-core\n\n\n\n\n\n \n\n\nBy d
efault, this newly created project uses a single repo called \n\napache-Mynewt-core\n. \n\n\nIf you wish to add additional repos, you would add \nadditional lines to the \nproject.repositories\n variable like this.\n\n\nproject.repositories:\n - apache-Mynewt-core\n\n - another_repo_named_x\n\n\n\n\n\n\n\nRepo Descriptors\n\n\nIn addition to the repo name, the \nproject.yml\n file must also contain\na repo descriptor for each repository you include that gives \nnewt\n \ninformation on obtaining the repo.\n\n\nIn the same \nmyproj\n above you will see the following repo descriptor.\n\n\nrepository.apache-Mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core\n\n\n\n\n\nA repo descriptor starts with \nrepository.\nname\n.\n. In this example, the \ndescriptor specifies the information for the \napache-Mynewt-core\n.\n\n\n\n\nThe fields within the descriptor have the following definitions:\n\n\n\n\n\n\ntype\n -- The type of code sto
rage the repo uses. The current version\nof \nnewt\n only supports github. Future versions may support generic git or other\ncode storage mechanisms.\n\n\n\n\n\n\nvers\n -- The version of the repo to use for your project. A source\ncode repository contains many versions of the source. This field is used to \nspecify the one to use for this project. See the section on versions below \nfor a detailed description of the format of this field.\n\n\n\n\n\n\nuser\n -- The username for the repo. On github, this is the name\nafter \ngithub.com\n in the repo path. Consider the repository \n\nhttps://github.com/apache/incubator-mynewt-core\n. It has username \napache\n. \n\n\n\n\n\n\nrepo\n -- The name of the repo. On github, this is the name after\nthe username described above. Consider the repository \n\nhttps://github.com/apache/incubator-mynewt-core\n. It has username \n\nincubator-mynewt-core\n. This is a path to the source control\nand should not be confused with the name of th
e repo that you used in the \n\nrepository.\nname\n declaration above. That name is contained elsewhere\nwithin the repo. See Below.\n\n\n\n\n\n\n\n\nAdding Existing Repos to my Project\n\n\nTo add a new repo to your project, you have to complete two steps.\n\n\n\n\n\n\nEdit the \nproject.yml\n file and add a new repo descriptor. The previous\nsection includes information on the field required in your repo descriptor.\n\n\n\n\n\n\nEdit the \nproject/yml\n file and add a new line to the \nproject.repositories\n\nvariable with the name of the repo you are adding. \n\n\n\n\n\n\nAn example of a \nproject.yml\n file with two repositories is shown below:\n\n\nproject.name: \nmy_project\n\n\nproject.repositories:\n - apache-Mynewt-core\n - Mynewt_arduino_zero\n\n# Use github\ns distribution mechanism for core ASF libraries.\n# This provides mirroring automatically for us.\n#\nrepository.apache-Mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubat
or-mynewt-core\n\n# a special repo to hold hardware specific stuff for arduino zero\nrepository.Mynewt_arduino_zero:\n type: github\n vers: 0-latest\n user: runtimeinc\n repo: Mynewt_arduino_zero\n\n\n\n\n\n\n\nWhat Version of the Repo to use\n\n\nMynewt repos are version-ed artifacts. They are stored in source control \nsystems like github. The repo descriptor in your \nproject.yml\n file must\nspecify the version of the repo you will accept into your project.\n\n\nFor now, we are at the beginnings of Mynewt. For testing and evaluation\nplease use \n0-latest\n in the \nvers\n field in your repo descriptor.\n\n\n vers:0-latest\n\n\n\n\n\nSee \nCreate a Repo\n for a description of the versioning system and all the possible ways to specify a version to use.\n\n\n\n\nIdentifying a Repo\n\n\nA 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 a
dditional file \nrepository.yml\n which describes the repo for use by \nnewt\n (and humans browsing them). It contains a mapping of version numbers to the actual github branches containing the source code.\n\n\nNote that the \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 determine the actual branch required depending on the version\nspecified in your \nproject.yml\n file. Special care should be taken to ensure that this file exists only in the master branch.\n\n\nHere is the \nrepository.yml\n file from the 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 in include in the \nproj
ect.repositories\n variable when adding this repository to your 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. \n\n\n\n\n\n\nRepo Version\n\n\nThe repo version number resolves to an actual git branch depending on the mapping specified in \nrepository.yml\n for that repo. The version field argument in your \nproject.yml\n file supports multiple formats for flexibility:\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 -- A stable release version of the repository\n\n\ndev -- A development version from the repository\n\n\nlatest -- 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\n1.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 cannot 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 Versions Available\n\n\nA \nrepository.yml\n file contains information to match a version request\ninto a git branch to fetch for your project.\n\n\nIt's up to the repository maintainer to map these to branches of the \nrepository. For example, let's say in a fictitious repository the following are \ndefined.\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 is resolved to version\n\n1.2.0\n (perhaps \n1.2.1\n is not stable yet), which in turn resolves to a specific\nbranch \nxxx_branch_1_2_0\n. This is the branch that \nnewt\n fetches into \nyour project. \n\n\nNote:\n Make sure a repo version exists in the \nrepository.yml\n 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.\n\n\n\n\nHow to find out what Repos are available for Mynewt components\n\n\nCurrently, there is no \nnewt\n command to locate/search Mynewt package \nrepositories. However, since the \nnewt\n tool supports only github, \nsearching github by keyword is a satisfactory option until a search \ntool is created.\n\n\nWhen searching github, recall that a Mynewt repository must \
nhave a \nrepository.yml\n file in its root directory. If you don't see \nthat file, it's not a Mynewt repository and can't be included in your \nproject via the newt tool. \n\n\nOnce you find a repository, the github URL and \nrepository.yml\n file\nshould give you all the information to add it to your \nproject.yml\n file.",
+ "text": "Adding Repositories to your Project\n\n\nWhat is a Repository\n\n\nA repository is a version-ed Mynewt project, which is a collection of Mynewt packages organized in a specific way for redistribution. \n\n\nWhat differentiates a repository from a Mynewt project is the presence of a\n\nrepository.yml\n file describing the repository. This will be described \nbelow. For a basic understanding of repositories you may read the \nNewt Tool Manual\n and \nHow to create repos\n.\n\n\nNote:\n For the remainder of this document we'll use the term repo as shorthand for a Mynewt repository.\n\n\nRepos 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.\n\n\n\n\nWhy does Mynewt need additional repos?\n\n\nRepos add functionality not included in the Mynewt core. New repos might be created for several reasons.\n\n\n\n\nExpertise\n. Individuals or organizations may have expe
rtise that they want\nto share in the form of repos. For example a chip vendor may\ncreate a repo to hold the Mynewt support for their chips.\n\n\nNon-Core component\n. Some components, although very useful to Mynewt users\nare not core to all Mynewt users. These are likely candidates to be held in \ndifferent repos.\n\n\nSoftware licensing\n. Some software have licenses that make them incompatible\nwith the ASF (Apache Software Foundation) license policies. These may be \nvaluable components to some Mynewt users, but cannot be contained in the \napache-Mynewt-core\n.\n\n\n\n\n\n\nWhat Repos are in my Project\n\n\nThe list of repos used by your project are contained within the \n\nproject.yml\n file. An example can be seen by creating a new project:\n\n\n$ mkdir ~/dev\n$ cd ~/dev\n$ newt new myproj\n$ cd myproj\n\n\n\n\n\n\n\nView the \nproject.yml\n section and you will see a line describing the repos:\n\n\nproject.repositories:\n - apache-Mynewt-core\n\n\n\n\n\n \n\n\nBy d
efault, this newly created project uses a single repo called \n\napache-Mynewt-core\n. \n\n\nIf you wish to add additional repos, you would add \nadditional lines to the \nproject.repositories\n variable like this.\n\n\nproject.repositories:\n - apache-Mynewt-core\n\n - another_repo_named_x\n\n\n\n\n\n\n\nRepo Descriptors\n\n\nIn addition to the repo name, the \nproject.yml\n file must also contain\na repo descriptor for each repository you include that gives \nnewt\n \ninformation on obtaining the repo.\n\n\nIn the same \nmyproj\n above you will see the following repo descriptor.\n\n\nrepository.apache-Mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core\n\n\n\n\n\nA repo descriptor starts with \nrepository.\nname\n.\n. In this example, the \ndescriptor specifies the information for the \napache-Mynewt-core\n.\n\n\n\n\nThe fields within the descriptor have the following definitions:\n\n\n\n\n\n\ntype\n -- The type of code sto
rage the repo uses. The current version\nof \nnewt\n only supports github. Future versions may support generic git or other\ncode storage mechanisms.\n\n\n\n\n\n\nvers\n -- The version of the repo to use for your project. A source\ncode repository contains many versions of the source. This field is used to \nspecify the one to use for this project. See the section on versions below \nfor a detailed description of the format of this field.\n\n\n\n\n\n\nuser\n -- The username for the repo. On github, this is the name\nafter \ngithub.com\n in the repo path. Consider the repository \n\nhttps://github.com/apache/incubator-mynewt-core\n. It has username \napache\n. \n\n\n\n\n\n\nrepo\n -- The name of the repo. On github, this is the name after\nthe username described above. Consider the repository \n\nhttps://github.com/apache/incubator-mynewt-core\n. It has path \n\nincubator-mynewt-core\n. This is a path to the source control\nand should not be confused with the name of the re
po that you used in the \n\nrepository.\nname\n declaration above. That name is contained elsewhere\nwithin the repo. See Below.\n\n\n\n\n\n\n\n\nAdding Existing Repos to my Project\n\n\nTo add a new repo to your project, you have to complete two steps.\n\n\n\n\n\n\nEdit the \nproject.yml\n file and add a new repo descriptor. The previous\nsection includes information on the field required in your repo descriptor.\n\n\n\n\n\n\nEdit the \nproject/yml\n file and add a new line to the \nproject.repositories\n\nvariable with the name of the repo you are adding. \n\n\n\n\n\n\nAn example of a \nproject.yml\n file with two repositories is shown below:\n\n\nproject.name: \nmy_project\n\n\nproject.repositories:\n - apache-Mynewt-core\n - Mynewt_arduino_zero\n\n# Use github\ns distribution mechanism for core ASF libraries.\n# This provides mirroring automatically for us.\n#\nrepository.apache-Mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-m
ynewt-core\n\n# a special repo to hold hardware specific stuff for arduino zero\nrepository.Mynewt_arduino_zero:\n type: github\n vers: 0-latest\n user: runtimeinc\n repo: Mynewt_arduino_zero\n\n\n\n\n\n\n\nWhat Version of the Repo to use\n\n\nMynewt repos are version-ed artifacts. They are stored in source control \nsystems like github. The repo descriptor in your \nproject.yml\n file must\nspecify the version of the repo you will accept into your project.\n\n\nFor now, we are at the beginnings of Mynewt. For testing and evaluation\nplease use \n0-latest\n in the \nvers\n field in your repo descriptor.\n\n\n vers:0-latest\n\n\n\n\n\nSee \nCreate a Repo\n for a description of the versioning system and all the possible ways to specify a version to use.\n\n\n\n\nIdentifying a Repo\n\n\nA 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 addit
ional file \nrepository.yml\n which describes the repo for use by \nnewt\n (and humans browsing them). It contains a mapping of version numbers to the actual github branches containing the source code.\n\n\nNote that the \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 determine the actual branch required depending on the version\nspecified in your \nproject.yml\n file. Special care should be taken to ensure that this file exists only in the master branch.\n\n\nHere is the \nrepository.yml\n file from the apache-Mynewt-core:\n\n\nrepo.name: apache-mynewt-core\nrepo.versions:\n \n0.0.0\n: \ndevelop\n\n \n0.7.9\n: \nmynewt_0_8_0_b2_tag\n\n \n0.8.0\n: \nmynewt_0_8_0_tag\n\n \n0.9.0\n: \nmynewt_0_9_0_tag\n\n \n0.9.1\n: \nmaster\n\n \n0-latest\n: \n0.9.0\n\n \n0-dev\n: \n0.9.1\n\n \n0.8-latest\n: \n0.8.0\n\n \n0.9-latest\n: \n0.9.0\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 in include in the \nproject.repositories\n variable when adding this repository to your 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. \n\n\n\n\n\n\nRepo Version\n\n\nThe repo version number resolves to an actual git branch depending on the mapping specified in \nrepository.yml\n for that repo. The version field argument in your \nproject.yml\n file supports multiple formats for flexibility:\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 -- A stable release version of the repository\n\n\ndev -- A development version from
the repository\n\n\nlatest -- 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\n1.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 cannot 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 Versions Available\n\n\nA \nrepository.yml\n file contains information to match a version request\ninto a git branch to fetch for your project.\n\n\nIt's up to the repository maintainer to map these to branches of the \nrepository. For example, let's say in a fictitious repository the following are \ndefined.\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: \n
xxx_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 is resolved to version\n\n1.2.0\n (perhaps \n1.2.1\n is not stable yet), which in turn resolves to a specific\nbranch \nxxx_branch_1_2_0\n. This is the branch that \nnewt\n fetches into \nyour project. \n\n\nNote:\n Make sure a repo version exists in the \nrepository.yml\n 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.\n\n\n\n\nHow to find out what Repos are available for Mynewt components\n\n\nCurrently, there is no \nnewt\n command to locate/search Mynewt package \nrepositories. However, since the \nnewt\n
tool supports only github, \nsearching github by keyword is a satisfactory option until a search \ntool is created.\n\n\nWhen searching github, recall that a Mynewt repository must \nhave a \nrepository.yml\n file in its root directory. If you don't see \nthat file, it's not a Mynewt repository and can't be included in your \nproject via the newt tool. \n\n\nOnce you find a repository, the github URL and \nrepository.yml\n file\nshould give you all the information to add it to your \nproject.yml\n file.",
"title": "toc"
},
{
@@ -887,7 +887,7 @@
},
{
"location": "/os/tutorials/repo/add_repos/#repo-descriptors",
- "text": "In addition to the repo name, the project.yml file must also contain\na repo descriptor for each repository you include that gives newt \ninformation on obtaining the repo. In the same myproj above you will see the following repo descriptor. repository.apache-Mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core A repo descriptor starts with repository. name . . In this example, the \ndescriptor specifies the information for the apache-Mynewt-core . The fields within the descriptor have the following definitions: type -- The type of code storage the repo uses. The current version\nof newt only supports github. Future versions may support generic git or other\ncode storage mechanisms. vers -- The version of the repo to use for your project. A source\ncode repository contains many versions of the source. This field is used to \nspecify the one to use for this project. See the section on ve
rsions below \nfor a detailed description of the format of this field. user -- The username for the repo. On github, this is the name\nafter github.com in the repo path. Consider the repository https://github.com/apache/incubator-mynewt-core . It has username apache . repo -- The name of the repo. On github, this is the name after\nthe username described above. Consider the repository https://github.com/apache/incubator-mynewt-core . It has username incubator-mynewt-core . This is a path to the source control\nand should not be confused with the name of the repo that you used in the repository. name declaration above. That name is contained elsewhere\nwithin the repo. See Below.",
+ "text": "In addition to the repo name, the project.yml file must also contain\na repo descriptor for each repository you include that gives newt \ninformation on obtaining the repo. In the same myproj above you will see the following repo descriptor. repository.apache-Mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core A repo descriptor starts with repository. name . . In this example, the \ndescriptor specifies the information for the apache-Mynewt-core . The fields within the descriptor have the following definitions: type -- The type of code storage the repo uses. The current version\nof newt only supports github. Future versions may support generic git or other\ncode storage mechanisms. vers -- The version of the repo to use for your project. A source\ncode repository contains many versions of the source. This field is used to \nspecify the one to use for this project. See the section on ve
rsions below \nfor a detailed description of the format of this field. user -- The username for the repo. On github, this is the name\nafter github.com in the repo path. Consider the repository https://github.com/apache/incubator-mynewt-core . It has username apache . repo -- The name of the repo. On github, this is the name after\nthe username described above. Consider the repository https://github.com/apache/incubator-mynewt-core . It has path incubator-mynewt-core . This is a path to the source control\nand should not be confused with the name of the repo that you used in the repository. name declaration above. That name is contained elsewhere\nwithin the repo. See Below.",
"title": "Repo Descriptors"
},
{
@@ -902,7 +902,7 @@
},
{
"location": "/os/tutorials/repo/add_repos/#identifying-a-repo",
- "text": "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\nrepository. Newt will always fetch this file from the master branch and then\nuse that to determine the actual branch required depending on the version\nspecified 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: repo.name: apache-mynewt-core\nrepo.versions:\n 0.7.9 : Mynewt_0_8_0_b2_tag \n 0-latest : 0.7.9 \n 0.8-latest : 0.7.9 It contains the following:
repo.name The external name that is used to include the library in \nyour 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 \non the settings in their project.yml file.",
+ "text": "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\nrepository. Newt will always fetch this file from the master branch and then\nuse that to determine the actual branch required depending on the version\nspecified 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: repo.name: apache-mynewt-core\nrepo.versions:\n 0.0.0 : develop \n 0.7.9 : mynewt_0_8_0_b2_tag \n 0.8.0 : mynewt_0_8_0_tag \n 0.9.0 : mynewt_0_9
_0_tag \n 0.9.1 : master \n 0-latest : 0.9.0 \n 0-dev : 0.9.1 \n 0.8-latest : 0.8.0 \n 0.9-latest : 0.9.0 It contains the following: repo.name The external name that is used to include the library in \nyour 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 \non the settings in their project.yml file.",
"title": "Identifying a Repo"
},
{
@@ -922,42 +922,42 @@
},
{
"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.",
+ "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"
},
{
"location": "/os/tutorials/repo/upgrade_repo/#upgrade-a-repo",
- "text": "In order to upgrade a previously installed repository, the \"newt upgrade\" command should be issued: $ newt upgrade Newt upgrade will look at the current desired version in project.yml , \nand compare it to the version in project.state . If these two differ, it \nwill upgrade the dependency. Upgrade works not just for the dependency \nin project.yml , but for all the sub-dependencies that they might have.",
+ "text": "In order to upgrade a previously installed repository, the \"newt upgrade\" command should be issued: $ newt upgrade Newt upgrade will look at the current desired version in project.yml , \nand compare it to the version in project.state . If these two differ, it \nwill upgrade the dependency. Upgrade works not just for the dependency \nin project.yml , but for all the sub-dependencies that they might have. If you have changed any settings in the project.yml file, you should run newt upgrade to ensure that your repos are all up to date with the versions \nspecified in your project.yml file.",
"title": "Upgrade a repo"
},
{
"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 \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 package management system, but support for plain git will be added soon.\n\n\nThe 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 \n0.0.0\n (implying we haven't released yet!). Such a version number corresponds to the \"develop\" branch in this repository. \n0-latest\n would also resolved to this same \n0.0.0\n version. The 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 in include in the \nproject.repositories\n variable when adding this repository to your project.\n\n\nrepo.versions\n A d
escription 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 -- A stable release version of the repository\n\n\ndev -- A development version from the repository\n\n\nlatest -- 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\n1.2-stable\n -- The latest stable versio
n 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 of the repository. For example, let's say in a fictitious repository the following 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. This is the branch that \nnewt\n will 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 too
l, 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.\n\n\nWhen a repository is installed to the repos/ directory, the current \nversion of that repository is written to the \"project.state\" 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 project.state file reliably, whereas the project.yml 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-stabl
e 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.",
+ "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 in include in the \nproject.repositories\n \nvariable when adding this repository t
o your 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\n1.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-stab
le\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"
},
{
"location": "/os/tutorials/repo/create_repo/#create-a-repo-out-of-a-project",
- "text": "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\nrepo.name: apache-mynewt-core\nrepo.versions:\n 0.0.0 : develop \n 0-latest : 0.0.0",
+ "text": "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 \npackage management system, but support for plain git is planned for a future\nversion. The repository.yml defines all versions of the repository and the corresponding \nsource 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 \nof the apache-mynewt-core operating system available, which is 0.0.0 (implying we \nhaven't released yet!). Such a version number corresponds to the \"develop\" branch \nin this repository. 0-latest would also resolved to this same 0.0.0 version. \nThe next section explains the versioning system a bit more. $ more repository.yml\nrepo.name: apache-mynewt-core\nrepo.versions:\n 0.0.0 : develop \n
0-latest : 0.0.0",
"title": "Create a Repo out of a Project"
},
{
"location": "/os/tutorials/repo/create_repo/#where-should-the-repositoryyml-file-be",
- "text": "The repository.yml file lives only in the master branch of the git\nrepository. Newt 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. Special care should be taken to ensure that this\nfile 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\nrepo.versions:\n 0.7.9 : Mynewt_0_8_0_b2_tag \n 0-latest : 0.7.9 \n 0.8-latest : 0.7.9 It contains the following: repo.name The external name that is used to include the library in \nyour 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 \non the settings in their project.yml file. See below for a thorough description\non versioning.
Its a flexible mapping between version numbers and git branches.",
+ "text": "The repository.yml file lives only in the master branch of the git\nrepository. Newt 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. Special care should be taken to ensure that this\nfile 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\nrepo.versions:\n 0.7.9 : Mynewt_0_8_0_b2_tag \n 0-latest : 0.7.9 \n 0.8-latest : 0.7.9 It contains the following: repo.name The external name that is used to include the library in \nyour project.yml file. This is the name you in include in the project.repositories \nvariable when adding this repository to your project. repo.versions A description of what versions to give the user depending \non the settings in their project.yml file. See below for a thorough description\non versionin
g. Its a flexible mapping between version numbers and git branches.",
"title": "Where should the repository.yml file be?"
},
{
"location": "/os/tutorials/repo/create_repo/#repo-version-specification",
- "text": "The version field argument for a repo has the following format: major_num . minor_num . revision_num or major_num . minor_num - stability string or major_num - stability string The stability string can be one of 3 pre-defined stability values. stable -- A stable release version of the repository dev -- A development version from the repository latest -- The latest from the repository In your project.yml file you can specify different combinations of \nthe version number and stability value. For example: 0-latest -- The latest version with major number 0 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. 1.2.8-stable",
+ "text": "The version field argument for a repo has the following format: major_num . minor_num . revision_num or major_num . minor_num - stability string or major_num - stability string The stability string can be one of 3 pre-defined stability values. stable -- A stable release version of the repository dev -- A development version from the repository latest -- The latest from the repository In your project.yml file you can specify different combinations of \nthe version number and stability value. For example: 0-latest -- The latest version with major number 0 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. 1.2.8-stable",
"title": "Repo Version Specification"
},
{
"location": "/os/tutorials/repo/create_repo/#repo-version-resolution",
- "text": "A repository.yml file contains information to match this version request\ninto 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. repo.versions:\n 0.8.0 : xxx_branch_0_8_0 \n 1.0.0 : xxx_branch_1_0_0 \n 1.0.2 : xxx_branch_1_0_2 \n 1.1.1 : xxx_branch_1_1_0 \n 1.1.2 : xxx_branch_1_1_2 \n 1.2.0 : xxx_branch_1_2_0 \n 1.2.1 : xxx_branch_1_2_1 \n 1.2-dev : 1.2.1 \n 1-dev : 1.2-dev \n 1.2-stable : 1.2.0 \n 0-latest : 0.8.0 \n 1-latest : 1-dev \n .... 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.",
+ "text": "A repository.yml file contains information to match this version request\ninto a git branch to fetch for your project. It'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. repo.versions:\n 0.8.0 : xxx_branch_0_8_0 \n 1.0.0 : xxx_branch_1_0_0 \n 1.0.2 : xxx_branch_1_0_2 \n 1.1.1 : xxx_branch_1_1_0 \n 1.1.2 : xxx_branch_1_1_2 \n 1.2.0 : xxx_branch_1_2_0 \n 1.2.1 : xxx_branch_1_2_1 \n 1.2-dev : 1.2.1 \n 1-dev : 1.2-dev \n 1.2-stable : 1.2.0 \n 0-latest : 0.8.0 \n 1-latest : 1-dev \n .... 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 . \nThis is the branch that newt will then fetch into the project with that project.yml file.",
"title": "Repo Version Resolution"
},
{
"location": "/os/tutorials/repo/create_repo/#dependencies-on-other-repos",
- "text": "Repositories 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: develop.repositories:\n sterlys-little-repo:\n type: github\n vers: 0.8-latest\n user: sterlinghughes\n repo: sterlys-little-repo This would tell Newt that for anything that resolves to the develop \nbranch, 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 \nversion of that repository is written to the \"project.state\" file. The \nproject state file co
ntains the currently installed version of any given \nrepository. This way, the current set of repositories can be recreated \nfrom the project.state file reliably, whereas the project.yml file can \nhave higher level directives (i.e. include 0.8-stable.)",
+ "text": "Repositories 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: develop.repositories:\n sterlys-little-repo:\n type: github\n vers: 0.8-latest\n user: sterlinghughes\n repo: sterlys-little-repo This would tell Newt that for anything that resolves to the develop \nbranch, this repository requires the sterlys-little-repo repository. Dependencies 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. When a repository is installed to the repos/ directory, the current \nversion of that repository is written to the project.state file. The \nproject state fil
e contains the currently installed version of any given \nrepository. This way, the current set of repositories can be recreated \nfrom the project.state file reliably, whereas the project.yml file can \nhave higher level directives (i.e. include 0.8-stable.)",
"title": "Dependencies on other repos"
},
{
@@ -968,7 +968,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 building applications using Mynewt. Specifically, this lesson will cover tasks, simple 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 section and complete the \nQuickStart\n guide and the \nBlinky\n tutorial. Furthermore, it may be helpful to take a peek at the \ntask documentation\n for 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 as it has the basic task struc
ture already implemented. Follow the \nArduino Zero Blinky tutorial\n 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\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 and how to properly initialize them. First, let\u2019s define a second task called \nwork_task\n in 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 struct which will hold the task\u2019s 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.\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 stack frames. Mynewt give
s us the ability to set the stack size for a task giving the application developer room to optimize memory usage. Since we\u2019re not short on memory, our \nblinky_stack\n and \nwork_stack\n are plenty large for the purpose of this lesson. Notice that the elements in our task stack are of type \nos_stack_t\n which 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 Blinky app the task function, named \nblinky_task_handler()\n, is initially called when we call \nos_start()\n in \nmain()\n. In general, the task function is where the majority of work is done by a task. Let\u2019s write a task function for \nwork_task\n called \nwo
rk_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. 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.\n\n\nTask Priority\n\n\nAs 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.\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 which takes a number of arguments including our new task function, stack, and priority. Much like \nblinky_task\n, we\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 doe
sn'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 preemptive RTOS is one in which a higher priority task
that is \nready to run\n will preempt (i.e. take the place of) the lower priority task which is \nrunning\n. When a lower priority task is preempted by a higher priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new task 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 \nsleep\n state, holds the processor focus on its context. Let\u2019s give \nwork_task\n a delay and some simulated work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is dependent on the board. Therefore, we multiply \nOS_TICKS_PER_SEC\n, which is defined in the MCU, by the number 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_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, our first action will be to sleep for three seconds. This will allow \nblinky_task\n to take over the CPU and blink to its heart\u2019s content. After three seconds, \nwork_task\n will wake up and be made \nready to run\n, causing it to preempt \nblinky_task\n. The LED
will then remain lit for a short period while \nwork_task\n loops, 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 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.\n\n\nSome 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.\n\n\nThe diagram below showcases the different scheduling patterns we. would expect from swapping blinky and work tasks priorities.\n\n\n\n\nIn the second case where \nblinky_task\n h
as a higher priority, the \u201cwork\u201d done by \nwork_task\n would be executed 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 github 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 to use the \nconsole\n and \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 of work, such as one which rapidly polls a sensor for data. Much like \nblinky_task\n, Task A will loop 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 relatively infrequently, such as one which sends/receives data from the cloud. Like work_task, Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer_task after the 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 simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the simulation. After the second simulation, timer will again print simulation data then compare the two 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 mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been moved 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.\nBlueto
oth-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. In 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 and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences before 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 by Task B\u2019s long execution time. \nStarvation\n occurs when one task hogs the processor, essentially \u
201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period, Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained before, processes which are expected to run for long periods of time (e.g. network communication, data 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 millisecond delays when Task A is \nsleeping\n. Although having Task B only run during these delays slows its execution time, we benefit from un-starving Task A and using the processor at a higher efficiency.\n\n\nThe bottom line speedup gives us an immediate and clear indication that we have improved our ability to process work (i.e throughput). In our second run, we processed an additional 400,000 loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor foun
d in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities to a serial program. However, we accomplished this by simply setting priorities on a single core processor \u2013 not bad!\n\n\nNOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers to the change in execution time between a serial and parallel program executing over the same problem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect on 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 Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up only completing 18% of its work cycle after the second simulation. That would mean,
at that rate, 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, \nevent queues\n, \nsemaphores\n, and \nmutexes\n also add to tasks functionality, increasing our ability as the developer to control greater numbers of tasks more intricately. For example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging through either the built-in \nLogs\n module (not covered in this lesson) or through the serial console/shell can be very useful for debugging your application. In the end, the way you manage your tasks depends on the context of your application. You should assign priorities based on execution time, urgency, and frequency, among other things.\n\n\nKeep blin
king and happy hacking!",
- "title": "Lesson Unit on Tasks and Priority Management"
+ "title": "Tasks and Priority Management"
},
{
"location": "/os/tutorials/tasks_lesson/#core-os-lesson-tasks-and-priority-management",
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/STM32F303/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/STM32F303/index.html b/latest/os/tutorials/STM32F303/index.html
index 89a4b23..e5e4e8e 100644
--- a/latest/os/tutorials/STM32F303/index.html
+++ b/latest/os/tutorials/STM32F303/index.html
@@ -317,13 +317,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/add_newtmgr/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/add_newtmgr/index.html b/latest/os/tutorials/add_newtmgr/index.html
index bcc8fb0..2c5da97 100644
--- a/latest/os/tutorials/add_newtmgr/index.html
+++ b/latest/os/tutorials/add_newtmgr/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/air_quality_sensor/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/air_quality_sensor/index.html b/latest/os/tutorials/air_quality_sensor/index.html
index e1f1997..eb9f86f 100644
--- a/latest/os/tutorials/air_quality_sensor/index.html
+++ b/latest/os/tutorials/air_quality_sensor/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/arduino_zero/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/arduino_zero/index.html b/latest/os/tutorials/arduino_zero/index.html
index 3092377..cb8dbd7 100644
--- a/latest/os/tutorials/arduino_zero/index.html
+++ b/latest/os/tutorials/arduino_zero/index.html
@@ -303,13 +303,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/blehci_project/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/blehci_project/index.html b/latest/os/tutorials/blehci_project/index.html
index d1fbbf1..d59f5c1 100644
--- a/latest/os/tutorials/blehci_project/index.html
+++ b/latest/os/tutorials/blehci_project/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/bleprph/bleprph-adv/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/bleprph/bleprph-adv/index.html b/latest/os/tutorials/bleprph/bleprph-adv/index.html
index f7fe4b1..586580a 100644
--- a/latest/os/tutorials/bleprph/bleprph-adv/index.html
+++ b/latest/os/tutorials/bleprph/bleprph-adv/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/bleprph/bleprph-app/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/bleprph/bleprph-app/index.html b/latest/os/tutorials/bleprph/bleprph-app/index.html
index 12df937..543052a 100644
--- a/latest/os/tutorials/bleprph/bleprph-app/index.html
+++ b/latest/os/tutorials/bleprph/bleprph-app/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/bleprph/bleprph-chr-access/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/bleprph/bleprph-chr-access/index.html b/latest/os/tutorials/bleprph/bleprph-chr-access/index.html
index d5d3108..babee60 100644
--- a/latest/os/tutorials/bleprph/bleprph-chr-access/index.html
+++ b/latest/os/tutorials/bleprph/bleprph-chr-access/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/bleprph/bleprph-gap-event/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/bleprph/bleprph-gap-event/index.html b/latest/os/tutorials/bleprph/bleprph-gap-event/index.html
index 99707bd..2593b9f 100644
--- a/latest/os/tutorials/bleprph/bleprph-gap-event/index.html
+++ b/latest/os/tutorials/bleprph/bleprph-gap-event/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/bleprph/bleprph-intro/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/bleprph/bleprph-intro/index.html b/latest/os/tutorials/bleprph/bleprph-intro/index.html
index 5c9c701..bb13aef 100644
--- a/latest/os/tutorials/bleprph/bleprph-intro/index.html
+++ b/latest/os/tutorials/bleprph/bleprph-intro/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/bleprph/bleprph-svc-reg/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/bleprph/bleprph-svc-reg/index.html b/latest/os/tutorials/bleprph/bleprph-svc-reg/index.html
index f8709b8..2808994 100644
--- a/latest/os/tutorials/bleprph/bleprph-svc-reg/index.html
+++ b/latest/os/tutorials/bleprph/bleprph-svc-reg/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/bletiny_project/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/bletiny_project/index.html b/latest/os/tutorials/bletiny_project/index.html
index 94a089e..d794ee3 100644
--- a/latest/os/tutorials/bletiny_project/index.html
+++ b/latest/os/tutorials/bletiny_project/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/blinky_primo/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/blinky_primo/index.html b/latest/os/tutorials/blinky_primo/index.html
index a142bcc..ee8faf5 100644
--- a/latest/os/tutorials/blinky_primo/index.html
+++ b/latest/os/tutorials/blinky_primo/index.html
@@ -303,13 +303,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/blinky_sram_olimex/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/blinky_sram_olimex/index.html b/latest/os/tutorials/blinky_sram_olimex/index.html
index 931ca0b..cd3aaf0 100644
--- a/latest/os/tutorials/blinky_sram_olimex/index.html
+++ b/latest/os/tutorials/blinky_sram_olimex/index.html
@@ -303,13 +303,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/event_queue/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/event_queue/index.html b/latest/os/tutorials/event_queue/index.html
index 708eee3..cd6349a 100644
--- a/latest/os/tutorials/event_queue/index.html
+++ b/latest/os/tutorials/event_queue/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/ibeacon/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/ibeacon/index.html b/latest/os/tutorials/ibeacon/index.html
index 05e9280..a734dea 100644
--- a/latest/os/tutorials/ibeacon/index.html
+++ b/latest/os/tutorials/ibeacon/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/nRF52/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/nRF52/index.html b/latest/os/tutorials/nRF52/index.html
index 9cc7d08..8d804da 100644
--- a/latest/os/tutorials/nRF52/index.html
+++ b/latest/os/tutorials/nRF52/index.html
@@ -303,13 +303,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/olimex/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/olimex/index.html b/latest/os/tutorials/olimex/index.html
index 4f9b186..cd62631 100644
--- a/latest/os/tutorials/olimex/index.html
+++ b/latest/os/tutorials/olimex/index.html
@@ -303,13 +303,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/pin-wheel-mods/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/pin-wheel-mods/index.html b/latest/os/tutorials/pin-wheel-mods/index.html
index f3f841b..1aed53d 100644
--- a/latest/os/tutorials/pin-wheel-mods/index.html
+++ b/latest/os/tutorials/pin-wheel-mods/index.html
@@ -317,13 +317,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/project-slinky/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/project-slinky/index.html b/latest/os/tutorials/project-slinky/index.html
index e92b3fa..4441c32 100644
--- a/latest/os/tutorials/project-slinky/index.html
+++ b/latest/os/tutorials/project-slinky/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0e97d5b3/latest/os/tutorials/project-target-slinky/index.html
----------------------------------------------------------------------
diff --git a/latest/os/tutorials/project-target-slinky/index.html b/latest/os/tutorials/project-target-slinky/index.html
index 2a41726..2248599 100644
--- a/latest/os/tutorials/project-target-slinky/index.html
+++ b/latest/os/tutorials/project-target-slinky/index.html
@@ -248,13 +248,8 @@
-
-
- <li><a href="
- ../tasks_lesson/
-">A Sample Lesson</a>
-
-
+ <li >
+ <a href="../tasks_lesson/">Tasks and Priority Management</a>
</li>