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/03/23 19:27:50 UTC
[6/7] incubator-mynewt-site git commit: Broke NimBLE tutorial into
multiple sections. Added Newt tutorial and theory of ops. Rearranged
tutorials for better flow. This is work in progress.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/6dba32a6/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/mkdocs/search_index.json b/mkdocs/search_index.json
index 3e9356b..342b95c 100644
--- a/mkdocs/search_index.json
+++ b/mkdocs/search_index.json
@@ -516,6 +516,121 @@
"title": "Congratulations"
},
{
+ "location": "/os/tutorials/define_target/",
+ "text": "How to Define a Target\n\n\nWhat newt commands to use?",
+ "title": "Define a target"
+ },
+ {
+ "location": "/os/tutorials/define_target/#how-to-define-a-target",
+ "text": "What newt commands to use?",
+ "title": "How to Define a Target"
+ },
+ {
+ "location": "/os/tutorials/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.",
+ "title": "Add repo to project"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#adding-repositories-to-your-project",
+ "text": "",
+ "title": "Adding Repositories to your Project"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#what-is-a-repository",
+ "text": "A repository is a version-ed Mynewt project, which is a collection of Mynewt packages organized in a specific way for redistribution. What differentiates a repository from a Mynewt project is the presence of a repository.yml file describing the repository. This will be described \nbelow. For a basic understanding of repositories you may read the Newt Tool Manual and How to create repos . Note: For the remainder of this document we'll use the term repo as shorthand for a Mynewt repository. Repos are useful because they are an organized way for the community to share Mynewt packages and projects. In fact, the Mynewt-core is distributed as a repo.",
+ "title": "What is a Repository"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#why-does-mynewt-need-additional-repos",
+ "text": "Repos add functionality not included in the Mynewt core. New repos might be created for several reasons. Expertise . Individuals or organizations may have expertise that they want\nto share in the form of repos. For example a chip vendor may\ncreate a repo to hold the Mynewt support for their chips. Non-Core component . 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. Software licensing . 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 apache-Mynewt-core .",
+ "title": "Why does Mynewt need additional repos?"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#what-repos-are-in-my-project",
+ "text": "The list of repos used by your project are contained within the project.yml file. An example can be seen by creating a new project: $ mkdir ~/dev\n$ cd ~/dev\n$ newt new myproj\n$ cd myproj View the project.yml section and you will see a line describing the repos: project.repositories:\n - apache-Mynewt-core By default, this newly created project uses a single repo called apache-Mynewt-core . If you wish to add additional repos, you would add \nadditional lines to the project.repositories variable like this. project.repositories:\n - apache-Mynewt-core - another_repo_named_x",
+ "title": "What Repos are in my Project"
+ },
+ {
+ "location": "/os/tutorials/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.",
+ "title": "Repo Descriptors"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#adding-existing-repos-to-my-project",
+ "text": "To add a new repo to your project, you have to complete two steps. Edit the project.yml file and add a new repo descriptor. The previous\nsection includes information on the field required in your repo descriptor. Edit the project/yml file and add a new line to the project.repositories \nvariable with the name of the repo you are adding. An example of a project.yml file with two repositories is shown below: project.name: my_project \n\nproject.repositories:\n - apache-Mynewt-core\n - Mynewt_arduino_zero\n\n# Use github s 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-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",
+ "title": "Adding Existing Repos to my Project"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#what-version-of-the-repo-to-use",
+ "text": "Mynewt repos are version-ed artifacts. They are stored in source control \nsystems like github. The repo descriptor in your project.yml file must\nspecify the version of the repo you will accept into your project. For now, we are at the beginnings of Mynewt. For testing and evaluation\nplease use 0-latest in the vers field in your repo descriptor. vers:0-latest See Create a Repo for a description of the versioning system and all the possible ways to specify a version to use.",
+ "title": "What Version of the Repo to use"
+ },
+ {
+ "location": "/os/tutorials/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.",
+ "title": "Identifying a Repo"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#repo-version",
+ "text": "The repo version number resolves to an actual git branch depending on the mapping specified in repository.yml for that repo. The version field argument in your project.yml file supports multiple formats for flexibility: 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"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#repo-versions-available",
+ "text": "A repository.yml file contains information to match a version request\ninto a git branch to fetch for your project. It'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. 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 is resolved to version 1.2.0 (perhaps 1.2.1 is not stable yet), which in turn resolves to a specific\nbranch xxx_branch_1_2_0 . This is the branch that newt fetches into \nyour project. Note: Make sure a repo version exists in the repository.yml
file of a repo you wish to add. Otherwise Newt will not be able to resolve the version and will fail to fetch the repo into your project.",
+ "title": "Repo Versions Available"
+ },
+ {
+ "location": "/os/tutorials/add_repos/#how-to-find-out-what-repos-are-available-for-mynewt-components",
+ "text": "Currently, there is no newt command to locate/search Mynewt package \nrepositories. However, since the newt tool supports only github, \nsearching github by keyword is a satisfactory option until a search \ntool is created. When searching github, recall that a Mynewt repository must \nhave a repository.yml 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. Once you find a repository, the github URL and repository.yml file\nshould give you all the information to add it to your project.yml file.",
+ "title": "How to find out what Repos are available for Mynewt components"
+ },
+ {
+ "location": "/os/tutorials/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.",
+ "title": "Create a repo"
+ },
+ {
+ "location": "/os/tutorials/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",
+ "title": "Create a Repo out of a Project"
+ },
+ {
+ "location": "/os/tutorials/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.",
+ "title": "Where should the repository.yml file be?"
+ },
+ {
+ "location": "/os/tutorials/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",
+ "title": "Repo Version Specification"
+ },
+ {
+ "location": "/os/tutorials/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.",
+ "title": "Repo Version Resolution"
+ },
+ {
+ "location": "/os/tutorials/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.)",
+ "title": "Dependencies on other repos"
+ },
+ {
+ "location": "/os/tutorials/create_repo/#resolving-dependencies",
+ "text": "At the moment, all dependencies must match, otherwise newt will provide \nan error. As an example, if you have a set of dependencies such that: apache-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 where 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. In 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": "Resolving dependencies"
+ },
+ {
+ "location": "/os/tutorials/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.",
+ "title": "Upgrade a repo"
+ },
+ {
+ "location": "/os/tutorials/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.",
+ "title": "Upgrade a repo"
+ },
+ {
"location": "/os/tutorials/unit_test/",
"text": "Write a Test Suite for a Package\n\n\nThis document presents a tutorial which guides the reader through writing\na test suite for a Mynewt package (new or existing).\n\n\nIntroduction\n\n\nWriting a test suite involves using the \nlibs/testutil\n\n package within Mynewt core os. The \ntestutil\n library provides the interface to \nthe \nnewt\n command tool and also provides the compile time hooks to include\ntest suites into your code. Review the \n[\ntestutil\n introduction page ] (../modules/testutil/testutil.md)\nto learn about how the library works.\n\n\nIdentify Your Package\n\n\nIdentify the package for which you are writing a test suite. For this example\nwe will use \nlibs/json\n. To create a new package, see \nthis Tutorial\n.\n\n\nModify Pkg.yml\n\n\nEdit the package (\npkg.yml\n) file for your package and add the test dependency\nfor the Mynewt core OS \nlibs/testutil\n.\n\n\npkg\n.\ndeps\n.\nTEST\n:\n \n-\n \nlibs/testutil\n\n\n\n\n\n\nCreate Yo
ur Test Suite Template\n\n\nCreate a subdirectory \ntest\n under your package main directory. \nCreate a file pair for your test code and header files within the \ntest\n\ndirectory created above. Below shows the \nlibs/json\n directory within the \nMynewt core, including the test directory. In this example, we used the \nconvention \ntest_xxx.c/h\n (in this case \ntest_json\n).\n\n\n\u251c\u2500\u2500\n \nMSJSON_COPYING\n\n\n\u251c\u2500\u2500\n \ninclude\n\n\n\u2502\u00a0\u00a0\n \n\u2514\u2500\u2500\n \njson\n\n\n\u2502\u00a0\u00a0\n \n\u2514\u2500\u2500\n \njson\n.\nh\n\n\n\u251c\u2500\u2500\n \npkg\n.\nyml\n\n\n\u2514\u2500\u2500\n \nsrc\n\n \n\u251c\u2500\u2500\n \njson_decode\n.\nc\n\n \n\u251c\u2500\u2500\n \njson_encode\n.\nc\n\n \n\u2514\u2500\u2500\n \ntest\n\n \n\u251c\u2500\u2500\n \ntest_json\n.\nc\n\n \n\u2514\u2500\u2500\n \ntest_json\n.\nh\n\n\n\n\n\n\nCreate Your Test Suite Code\n\n\nEdit the \ntest_json.c\n file and add your test suite
definition. NOTE that \nthe test suite code requires \n#include \ntestutil/testutil.h\n to get the \nMynewt testutil definitions.\n\n\nYour test suite \ntest_json.c\n file contains at a minimum two functions:\n\n\n\n\nA test Suite which is empty for now, but will contain calls to your test\ncases. \n\n\nA main function which must be \n#ifdef\n'd using \nMYNEWT_SELFTEST\n to ensure\nthat is does not get compiled in when this test suite is run with \ntest suites from other packages \n\n\n\n\nBelow shows the contents of the \ntest_json.c\n file.\n\n\n#include \ntestutil/testutil.h\n\n\n\nTEST_SUITE\n(\ntest_json_suite\n) {\n \n/* empty for now, add test cases later */\n\n}\n\n\n#ifdef MYNEWT_SELFTEST\n\n\nint\n\n\nmain\n(\nint\n \nargc\n, \nchar\n \n**argv\n)\n{\n \ntu_config\n.\ntc_print_results\n \n=\n \n1\n;\n \ntu_init\n();\n \ntest_json_suite\n();\n \nreturn\n \ntu_any_failed\n;\n}\n\n#endif\n\n\n\n\n\n\nTry It Out\n\n\nAt this point, you have a working test suite
with \nno\n tests.\n\nThis will by default pass the test. Your output will look\nsomething like this.\n\n\nYou can use the \nnewt test\n command to run the unit tests for any package.\n\nJust include the package name. These unit tests run via the project \n\nunittest\n which is a native project automatically included in the core\nos package. Below shows some of the test output of this command.\n\n\n$\n \nnewt\n \ntest\n \nlibs/json\n\n\nArchiving\n \nutil\n.\na\n\n\nLinking\n \ntest_json\n\n\nTesting\n \npackage\n \nlibs/json\n\n\nTest\n ...\n/bin/unittest/libs/json/test_json\n \nok!\n\n\n\n\n\n\nCreate a Test\n\n\nTo create a test within your test suite, there are two things to do.\n\n\n\n\nAdd the functions to your test suite\n\n\nImplement the function using the \ntestutil\n macros\n\n\n\n\nFor this tutorial we will create two functions: one to test a simple json\nencode and one to test the decode of this simple message to ensure its \ncoherent.\n\n\nFollow These steps;\n\n\n
1. Create function prototypes in \ntest_json.h\n for your test functions. \nA macro in \ntestutil.h\n hides the actual prototype, but as of this writing\nthe prototype is \nint test_func(void);\n. \n\n\n#ifndef TEST_JSON_H\n\n\n#define TEST_JSON_H\n\n\n\nTEST_CASE_DECL\n(\ntest_json_simple_encode\n);\n\nTEST_CASE_DECL\n(\ntest_json_simple_decode\n);\n\n\n#endif /* TEST_JSON_H \n\n\n\n\n\n\n2. create a new file \ntest_json_simple.c\n to define these two functions. For\nnow you can stub these functions. Below shows the contents of this file. \nThe functions are defined using macros which reference back to the \n\ntestutil\n library so the test can be enumerated and recorded automatically.\n\n\n#include \ntestutil/testutil.h\n\n\n#include \ntest_json.h\n\n\n\nTEST_CASE\n(\ntest_json_simple_encode\n) {\n}\n\n\nTEST_CASE\n(\ntest_json_simple_decode\n) {\n}\n\n#endif /* TEST_JSON_H \n\n\n\n\n\n\n3. Add the tests to your test suite in \ntest_json.c\n as shown below.\n\n\nTEST_SUITE\n(\nt
est_json_suite\n) {\n \ntest_json_simple_encode\n();\n \ntest_json_simple_decode\n();\n}\n\n\n\n\n\nYour test suite should still pass as shown below\n\n\n$newt\n \ntest\n \nlibs/json\n\n\nTesting\n \npackage\n \nlibs/json\n\n\nTest\n ...\n/bin/unittest/libs/json/test_json\n \nok!\n\n\n\n\n\n\nAdd Contents to your Tests\n\n\nAt this point, you can add contents to your test and verify that \nthe test suites pass. For now, lets just add a simple failure to show\nwhat it would look like when running from Newt.\n\n\n\n\nEdit \ntest_json_simple.c\n and add a \nTEST_ASSERT\n to a test funtion. The\ntest assert will fail if its argument is \nfalse\n.\n\n\n\n\nTEST_CASE\n(\ntest_json_simple_encode\n) {\n \nTEST_ASSERT\n(\n0\n);\n}\n\n\n\n\n\nWhen running newt, you will see the test suite fails with something like\nthe message shown below.\n\n\nTesting\n \npackage\n \nlibs/json\n\n[\nFAIL\n] \ntest_json_suite/\n(\nnull\n) \n|test_json_simple\n.\nc\n:\n24\n|\n \nfailed\n \nassertion\
n: \n0\n\n\nError\n: \nTest\n \ncrashed\n: ..\n/bin/unittest/libs/json/test_json\n\n\nexit\n \nstatus\n \n1\n\n\n\n\n\n\nCongratulations\n\n\nNow you can begin the work of adding your test cases and test.\n\n\nTesting on your target",
"title": "Write a Test Suite for a Package"
@@ -611,64 +726,19 @@
"title": "Use of HAL for drivers"
},
{
- "location": "/os/tutorials/add_repos/",
- "text": "Additional Repositories\n\n\nWhat is a Repository\n\n\nA repository is a version-ed Mynewt project, which is a \ncollection of Mynewt packages organized in a specific\nway. \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. \nNote:\n For the remainder of this document we'll use the term repo as shorthand for a \nMynewt repository.\n\n\nRepos are useful because they are an organized way for the community\nto share Mynewt packages and projects. In fact, the Mynewt-core is \ndistributed 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 \nseveral reasons.\n\n\n\n\nExpertise\n. Individuals or organizations may have expertise 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 thei
r 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 default, this newly created project uses a single repo called \n\napache-Mynewt-core\n. \n\n\nIf you wish to add additional repos, yo
u would add \nadditional lines to the \nproject.repositories\n variable like this.\n\n\nproject.repositories:\n - apache-Mynewt-core\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 storage the repo uses. The current version\nof \nnewt\n only supports github. Future versions may support generic git or other\ncode sto
rage 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 the 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 if 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-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 below for a description of the version system.\n\n\n\n\nWhat is in a Repo\n\n\nA repo is a collection of Mynewt packages organized in a specific\nway and stored in one of the supported code storage methods described above. \n\n\nA repo is a Mynewt project with an additional file \nrepository.yml\n\nwhich describes the repo for use by \nnewt\n (and humans browsing them).\n\n\nThere is one key consideration for this \nrepository.yml\n file. The \n\nrepository.ym
l\n file only lives 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. Special 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 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 \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. 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\n\n\nThe version field argument in your \nproject.yml\n file 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 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 c
annot specify a stability string with a fully numbered version, e.g.\n\n\n1.2.8-stable\n\n\n\n\n\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\nIts 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 its resolved to version\n\n1.2.0\n (perhaps \n1.2.1\n is not stable yet), which resolves to a specific\nbr
anch \nxxx_branch_1_2_0\n. This is the branch that \nnewt\n fetches into \nyour 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": "Additional Repositories"
- },
- {
- "location": "/os/tutorials/add_repos/#additional-repositories",
- "text": "",
- "title": "Additional Repositories"
- },
- {
- "location": "/os/tutorials/add_repos/#what-is-a-repository",
- "text": "A repository is a version-ed Mynewt project, which is a \ncollection of Mynewt packages organized in a specific\nway. What differentiates a repository from a Mynewt project is the presence of a repository.yml file describing the repository. This will be described \nbelow. Note: For the remainder of this document we'll use the term repo as shorthand for a \nMynewt repository. Repos are useful because they are an organized way for the community\nto share Mynewt packages and projects. In fact, the Mynewt-core is \ndistributed as a repo.",
- "title": "What is a Repository"
- },
- {
- "location": "/os/tutorials/add_repos/#why-does-mynewt-need-additional-repos",
- "text": "Repos add functionality not included in the Mynewt core. New repos might be created for \nseveral reasons. Expertise . Individuals or organizations may have expertise 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. Non-Core component . 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. Software licensing . 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 apache-Mynewt-core .",
- "title": "Why does Mynewt need additional repos?"
- },
- {
- "location": "/os/tutorials/add_repos/#what-repos-are-in-my-project",
- "text": "The list of repos used by your project are contained within the project.yml file. An example can be seen by creating a new project: $ mkdir ~/dev\n$ cd ~/dev\n$ newt new myproj\n$ cd myproj View the project.yml section and you will see a line describing the repos: project.repositories:\n - apache-Mynewt-core By default, this newly created project uses a single repo called apache-Mynewt-core . If you wish to add additional repos, you would add \nadditional lines to the project.repositories variable like this. project.repositories:\n - apache-Mynewt-core\n - another_repo_named_x",
- "title": "What Repos are in my Project"
- },
- {
- "location": "/os/tutorials/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.",
- "title": "Repo Descriptors"
- },
- {
- "location": "/os/tutorials/add_repos/#adding-existing-repos-to-my-project",
- "text": "To add a new repo to your project, you have to complete two steps. Edit the project.yml file and add a new repo descriptor. The previous\nsection includes information on the field required in your repo descriptor. Edit the project/yml file and add a new line to the project.repositories \nvariable with the name of the repo you are adding. An example if a project.yml file with two repositories is shown below: project.name: my_project \n\nproject.repositories:\n - apache-Mynewt-core\n - Mynewt_arduino_zero\n\n# Use github s 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-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",
- "title": "Adding Existing Repos to my Project"
- },
- {
- "location": "/os/tutorials/add_repos/#what-version-of-the-repo-to-use",
- "text": "Mynewt repos are version-ed artifacts. They are stored in source control \nsystems like github. The repo descriptor in your project.yml file must\nspecify the version of the repo you will accept into your project. For now, we are at the beginnings of Mynewt. For testing and evaluation\nplease use 0-latest in the vers field in your repo descriptor. vers:0-latest See below for a description of the version system.",
- "title": "What Version of the Repo to use"
- },
- {
- "location": "/os/tutorials/add_repos/#what-is-in-a-repo",
- "text": "A repo is a collection of Mynewt packages organized in a specific\nway and stored in one of the supported code storage methods described above. A repo is a Mynewt project with an additional file repository.yml \nwhich describes the repo for use by newt (and humans browsing them). There is one key consideration for this repository.yml file. The repository.yml file only lives 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 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 th
e 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.",
- "title": "What is in a Repo"
+ "location": "/os/tutorials/bletiny_project/",
+ "text": "NimBLE project\n\n\nThis tutorial explains how to start BLE 4.2 on a board and start seeing some BLE related statistics.",
+ "title": "Enable BLE using nimBLE"
},
{
- "location": "/os/tutorials/add_repos/#repo-version",
- "text": "The version field argument in your project.yml file 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 A repository.yml file contains information to match this version request\ninto a git branch to fetch f
or your project. Its 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. 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 its resolved to version 1.2.0 (perhaps 1.2.1 is not stable yet), which resolves to a specific\nbranch xxx_branch_1_2_0 . This is the branch that newt fetches into \nyour project.",
- "title": "Repo Version"
- },
- {
- "location": "/os/tutorials/add_repos/#how-to-find-out-what-repos-are-available-for-mynewt-components",
- "text": "Currently, there is no newt command to locate/search Mynewt package \nrepositories. However, since the newt tool supports only github, \nsearching github by keyword is a satisfactory option until a search \ntool is created. When searching github, recall that a Mynewt repository must \nhave a repository.yml 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. Once you find a repository, the github URL and repository.yml file\nshould give you all the information to add it to your project.yml file.",
- "title": "How to find out what Repos are available for Mynewt components"
+ "location": "/os/tutorials/bletiny_project/#nimble-project",
+ "text": "This tutorial explains how to start BLE 4.2 on a board and start seeing some BLE related statistics.",
+ "title": "NimBLE project"
},
{
"location": "/os/tutorials/event_queue/",
"text": "How to define a task which uses event queues to manage multiple events\n\n\nIntroduction\n\n\nEvent queue is a mechanism by which you can serialize incoming events for your task. You can use it to get info about arrived hardware interrupts, callout expirations and messages from other tasks.\n\n\nThe benefit of doing inter-task communication this way is that there should be less resources that need to be locked.\n\n\nThe benefit of doing interrupt processing in a task context instead of inside an interrupt context is that you are not blocking other HW interrupts when doing the work. The same goes for high priority tasks in the system; they're blocked until the interrupt handler returns. From the task context you'll also be able to access other OS facilities; you can sleep while waiting for a lock, for example.\n\n\n\n\nExample app\n\n\nHere you are going to write an app which demonstrates the use of event queues for communication between tasks. You will also use
OS callouts for timer expiration and another event from a GPIO interrupt.\n\n\nYou will use inputs from 3 sources to toggle 3 GPIO outputs on my STM32F3discovery board.\n\n\n\n\nCreate project\n\n\nYou start by creating a project and populating it with repositories incubator-mynewt-core and mynewt_stm32f3. See \nSTM32F3 tutorial\n if you need help with this. You can also read the tutorial on \nAdditional Repositories\n for a more thorough understanding. \n\n\n \n\n\nCreate application\n\n\nHere's what the pkg.yml looks for the application.\n\n\n[marko@IsMyLaptop:~/src/events]$ cat apps/event_sample/pkg.yml\npkg.name: apps/event_sample\npkg.type: app\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/stub\n\n\n\n\n\n\n\n\nInitialize the event queue structure\n\n\nThis must be done before anyone tries to place events to the queue. Here it's done before any task gets created. Initialization is done by ca
lling \nos_eventq_init()\n.\n\n\n#define MY_TASK_PRIO 4\n\n\n#define MY_TASK_STACK_SZ 512\n\n\n\nstatic\n \nstruct\n \nos_eventq\n \nmy_eventq\n;\n\nstatic\n \nos_stack_t\n \nmy_task_stack\n[\nMY_TASK_STACK_SZ\n];\n\nstatic\n \nstruct\n \nos_task\n \nmy_task_str\n;\n\n\nvoid\n\n\ninit_tasks\n(\nvoid\n)\n{\n \nstruct\n \nos_task\n \ntaskid\n;\n\n \nos_eventq_init\n(\nmy_eventq\n);\n \nos_task_init\n(\nmy_task_str\n, \ntask\n, \nmy_task\n, \nNULL\n, \nMY_TASK_PRIO\n,\n \nOS_WAIT_FOREVER\n, \nmy_task_stack\n, \nMY_TASK_STACK_SZ\n);\n\n\n\n\n\n\n\nProcessing events\n\n\nHere event processing is done inside \nmy_task\n. The main loop of the task is pulling events from the queue, and then taking action. We look at the type of the event to figure out what to do.\n\n\nThe code snippet shows what the main loop of the event handler looks like. Events are removed from the head of the queue using os_eventq_get\n\n\nvoid\n\n\nmy_task\n(\nvoid\n \n*arg\n)\n{\n \nstruc
t\n \nos_event\n \n*ev\n;\n\n \nwhile\n (\n1\n) {\n \nev\n \n=\n \nos_eventq_get\n(\nmy_eventq\n);\n \nswitch\n (\nev-\nev_type\n) {\n \n/* more event types here */\n\n \ndefault\n:\n\n \nassert\n(\n0\n);\n }\n }\n}\n\n\n\n\n\n\n\nEvent types\n\n\nYou can define your own event types. Some numbers are already reserved by the OS, so you should not use those as your own types.\n\n\nReserved event types are defined in \nlibs/os/include/os/os_eventq.h\n. One example of a reserved type is OS_EVENT_T_TIMER, which is used as type in OS callouts.\n\n\nYou should start your event numbers from \nOS_EVENT_T_PERUSER\n, and go higher.\n\n\nYou are going to generate events from GPIO interrupt handler, from another task as well as from a callout. OS callout already has a type, but you'll need to define types for the other uses.\n\n\n#define MY_TASK_GPIO_EVENT (OS_EVENT_T_PERUSER)\n\n\n#define MY_TASK_TASK_EVENT (OS_EVENT_T_PERUSER + 1)\n\n\n\n\n
\n\n\n\nPosting events from another task\n\n\nEvents are posted to a queue by calling \nos_eventq_put()\n. You need to preallocate memory for the event structure. Here it's done by declaring the event structure as a global variable.\n\n\nNote that you can call \nos_eventq_put()\n with an event which has already been queued. In that case, the call has no effect; the position of the event is not changed within the queue.\n\n\nIn the code snippet we declare the os_event structure, and initialize it. We also create the event generating task, and periodically post event to the event queue.\n\n\n#define GEN_TASK_PRIO 3\n\n\n#define GEN_TASK_STACK_SZ 512\n\n\n\nstatic\n \nstruct\n \nos_event\n \ngen_task_ev\n;\n\nstatic\n \nos_stack_t\n \ngen_task_stack\n[\nGEN_TASK_STACK_SZ\n];\n\nstatic\n \nstruct\n \nos_task\n \ngen_task_str\n;\n\n\nvoid\n\n\ngen_task\n(\nvoid\n \n*arg\n)\n{\n \nwhile\n (\n1\n) {\n \nos_time_delay\n(\nOS_TICKS_PER_SEC\n \n/\n \n4\n);\n \nos_even
tq_put\n(\nmy_eventq\n, \ngen_task_ev\n);\n }\n}\n\n\nvoid\n\n\ninit_tasks\n(\nvoid\n)\n{\n \n/* .... */\n\n \ngen_task_ev\n.\nev_type\n \n=\n \nMY_TASK_TASK_EVENT\n;\n \nos_task_init\n(\ngen_task_str\n, \ngen_task\n, \ngen_task\n, \nNULL\n, \nGEN_TASK_PRIO\n,\n \nOS_WAIT_FOREVER\n, \ngen_task_stack\n, \nGEN_TASK_STACK_SZ\n);\n}\n\n\n\n\n\n\n\nCallout events\n\n\nYou can get timer events delivered to your task's event queue with OS callout. Check \ncallout documentation\n for description on how to use the API.\n\n\nFor this example, you'll use only one type of callout; so you can use the simpler structure.\n\n\nIn the code snippet we declare the os_callout structure and initialize it. Then we arm the timer.\n\n\nstatic\n \nstruct\n \nos_callout\n \nmy_callout\n;\n\n\nvoid\n\n\ninit_tasks\n(\nvoid\n)\n{\n \n/* .... */\n\n\n \nos_callout_init\n(\nmy_callout\n, \nmy_eventq\n, \nNULL\n);\n \nos_callout_reset\n(\nmy_callout\n, \nOS_TICKS_PER_SEC\n);\n}\n\n\n\n
\n\n\n\nPosting events from interrupt handler\n\n\nAnother place where posting events makes sense is from an interrupt handler. In this tutorial you will do it when GPIO changes state.\n\n\nYou'll use HAL GPIO interface to register a routine which is getting called from the interrupt handler context. This routine will then post event to your queue.\n\n\nOn STM32F3Discovery board, there is a button connected to PA0. The identifier for this GPIO pin is 0.\n\n\nstatic\n \nstruct\n \nos_event\n \ngpio_ev\n;\n\n\nvoid\n\n\ninit_tasks\n(\nvoid\n)\n{\n \n/* .... */\n\n\n \ngpio_ev\n.\nev_type\n \n=\n \nMY_TASK_GPIO_EVENT\n;\n \nhal_gpio_irq_init\n(\n0\n, \nmy_gpio_irq\n, \nNULL\n, \nGPIO_TRIG_RISING\n,\n \nGPIO_PULL_NONE\n);\n \nhal_gpio_irq_enable\n(\n0\n);\n}\n\n\nstatic\n \nvoid\n\n\nmy_gpio_irq\n(\nvoid\n \n*arg\n)\n{\n \nos_eventq_put\n(\nmy_eventq\n, \ngpio_ev\n);\n}\n\n\n\n\n\n\n\nEvent processing finalized\n\n\nNow that you are posting events from different so
urces, you will fill in the parts in the task main loop to trigger different behaviors depending on event type.\n\n\nYou'll drive different LEDs depending on what type of event arrived. LEDs on this board are connected to PE8, PE9, PE10 and so on. These have GPIO identifiers starting from 72 onwards.\n\n\n#define TASK_LED 72\n\n\n#define CALLOUT_LED 73\n\n\n#define GPIO_LED 74\n\n\n\nvoid\n\n\ninit_tasks\n(\nvoid\n)\n{\n \n/* .... */\n\n \nhal_gpio_init_out\n(\nTASK_LED\n, \n1\n);\n \nhal_gpio_init_out\n(\nCALLOUT_LED\n, \n1\n);\n \nhal_gpio_init_out\n(\nGPIO_LED\n, \n1\n);\n}\n\n\n\n\n\nAnd here is the new main loop for your task. Note that when callout event arrives, we re-arm the callout.\n\n\nvoid\n\n\nmy_task\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_event\n \n*ev\n;\n\n \nwhile\n (\n1\n) {\n \nev\n \n=\n \nos_eventq_get\n(\nmy_eventq\n);\n \nswitch\n (\nev-\nev_type\n) {\n \ncase\n \nMY_TASK_TASK_EVENT\n:\n \n
hal_gpio_toggle\n(\nTASK_LED\n);\n \nbreak\n;\n \ncase\n \nOS_EVENT_T_TIMER\n:\n \nhal_gpio_toggle\n(\nCALLOUT_LED\n);\n \nos_callout_reset\n(\nmy_callout\n, \nOS_TICKS_PER_SEC\n \n/\n \n2\n);\n \nbreak\n;\n \ncase\n \nMY_TASK_GPIO_EVENT\n:\n \nhal_gpio_toggle\n(\nGPIO_LED\n);\n \nbreak\n;\n \ndefault\n:\n\n \nassert\n(\n0\n);\n }\n }\n}\n\n\n\n\n\n\n\nNow you're done. Once you load this to your board, the task LED will blink at an interval of 250ms, the callout LED with an interval of 500ms, and the GPIO LED every time you press the button.\n\n\n\n\nCode for the example\n\n\n#include \nos/os.h\n\n\n#include \nbsp/bsp.h\n\n\n#include \nhal/hal_gpio.h\n\n\n#include \nassert.h\n\n\n\n\n#define MY_TASK_PRIO 4\n\n\n#define MY_TASK_STACK_SZ 512\n\n\n\n#define GEN_TASK_PRIO 3\n\n\n#define GEN_TASK_STACK_SZ 512\n\n\n\n#define MY_TASK_GPIO_EVENT (OS_EVENT_T_PERUSER)
\n\n\n#define MY_TASK_TASK_EVENT (OS_EVENT_T_PERUSER + 1)\n\n\n\n#define TASK_LED 72\n\n\n#define CALLOUT_LED 73\n\n\n#define GPIO_LED 74\n\n\n\nstatic\n \nstruct\n \nos_eventq\n \nmy_eventq\n;\n\nstatic\n \nos_stack_t\n \nmy_task_stack\n[\nMY_TASK_STACK_SZ\n];\n\nstatic\n \nstruct\n \nos_task\n \nmy_task_str\n;\n\n\nstatic\n \nstruct\n \nos_event\n \ngen_task_ev\n;\n\nstatic\n \nos_stack_t\n \ngen_task_stack\n[\nGEN_TASK_STACK_SZ\n];\n\nstatic\n \nstruct\n \nos_task\n \ngen_task_str\n;\n\n\nstatic\n \nstruct\n \nos_callout\n \nmy_callout\n;\n\n\nstatic\n \nstruct\n \nos_event\n \ngpio_ev\n;\n\n\nvoid\n\n\nmy_task\n(\nvoid\n \n*arg\n)\n{\n \nstruct\n \nos_event\n \n*ev\n;\n\n \nwhile\n (\n1\n) {\n \nev\n \n=\n \nos_eventq_get\n(\nmy_eventq\n);\n \nswitch\n (\nev-\nev_type\n) {\n \ncase\n \nMY_TASK_TASK_EVENT\n:\n \nhal_gpio_toggle\n(\nTASK_LED\n);\n \nbreak\n;\n \ncase\n \nOS_EVENT_T_TIMER\n:\n \nh
al_gpio_toggle\n(\nCALLOUT_LED\n);\n \nos_callout_reset\n(\nmy_callout\n, \nOS_TICKS_PER_SEC\n \n/\n \n2\n);\n \nbreak\n;\n \ncase\n \nMY_TASK_GPIO_EVENT\n:\n \nhal_gpio_toggle\n(\nGPIO_LED\n);\n \nbreak\n;\n \ndefault\n:\n\n \nassert\n(\n0\n);\n }\n }\n}\n\n\nstatic\n \nvoid\n\n\nmy_gpio_irq\n(\nvoid\n \n*arg\n)\n{\n \nos_eventq_put\n(\nmy_eventq\n, \ngpio_ev\n);\n}\n\n\nvoid\n\n\ngen_task\n(\nvoid\n \n*arg\n)\n{\n \nwhile\n (\n1\n) {\n \nos_time_delay\n(\nOS_TICKS_PER_SEC\n \n/\n \n4\n);\n \nos_eventq_put\n(\nmy_eventq\n, \ngen_task_ev\n);\n }\n}\n\n\nvoid\n\n\ninit_tasks\n(\nvoid\n)\n{\n \nos_eventq_init\n(\nmy_eventq\n);\n \nos_task_init\n(\nmy_task_str\n, \ntask\n, \nmy_task\n, \nNULL\n, \nMY_TASK_PRIO\n,\n \nOS_WAIT_FOREVER\n, \nmy_task_stack\n, \nMY_TASK_STACK_SZ\n);\n\n \ngen_task_ev\n.\nev_type\n \n=\n \nMY_TASK_TASK_EVENT\n;\n \nos_task_init\n(\ngen_task
_str\n, \ngen_task\n, \ngen_task\n, \nNULL\n, \nGEN_TASK_PRIO\n,\n \nOS_WAIT_FOREVER\n, \ngen_task_stack\n, \nGEN_TASK_STACK_SZ\n);\n\n \nos_callout_init\n(\nmy_callout\n, \nmy_eventq\n, \nNULL\n);\n \nos_callout_reset\n(\nmy_callout\n, \nOS_TICKS_PER_SEC\n);\n\n \ngpio_ev\n.\nev_type\n \n=\n \nMY_TASK_GPIO_EVENT\n;\n \nhal_gpio_irq_init\n(\n0\n, \nmy_gpio_irq\n, \nNULL\n, \nGPIO_TRIG_RISING\n,\n \nGPIO_PULL_NONE\n);\n \nhal_gpio_irq_enable\n(\n0\n);\n\n \nhal_gpio_init_out\n(\nTASK_LED\n, \n1\n);\n \nhal_gpio_init_out\n(\nCALLOUT_LED\n, \n1\n);\n \nhal_gpio_init_out\n(\nGPIO_LED\n, \n1\n);\n}\n\n\nint\n\n\nmain\n(\nint\n \nargc\n, \nchar\n \n**argv\n)\n{\n \nos_init\n();\n\n \ninit_tasks\n();\n \nos_start\n();\n \nassert\n(\n0\n);\n \nreturn\n \n0\n;\n}",
- "title": "A task to manage multiple events"
+ "title": "Add task to manage multiple events"
},
{
"location": "/os/tutorials/event_queue/#how-to-define-a-task-which-uses-event-queues-to-manage-multiple-events",
@@ -5611,16 +5681,191 @@
"title": "toc"
},
{
+ "location": "/network/ble/nimble_setup/",
+ "text": "Set up a NimBLE application\n\n\nThis tutorial explains how to setup an application using the Nimble stack. The end result will be a framework that you can use to create your own BLE application using the nimble stack.\n\n\nThis tutorial assumes that you have already installed a source tree and are familiar with the newt tools and concepts.\n\n\nCreate the application directory\n\n\n\n\nCreate the target\n\n\nThe first step will be to create the target that you will use to build your application. We will call this target \"ble_tgt\". Type the \nnewt target create ble_tgt\n command. You should get this:\n\n\n$ newt target create ble_tgt\nTarget targets/ble_tgt successfully created\n\n\n\n\n\nWhat this command just did was to create a directory called \nble_tgt\n in the targets directory of your project. Two files are created in that directory: pkg.yml and target.yml.\n\n\nThe target is not yet complete though! We need to set some target variables for this project
. Currently, the nimble stack has been ported to the Nordic nrf5x chipsets; specifically the nrf51 and nrf52. This application will use the nrf52 but we will also show the setup for the nrf51 in case your project uses that chip.\n\n\nHere is the command you will need to setup your target for the nrf52:\n\n\n$ newt target set ble_tgt app=apps/ble_app \\\n bsp=hw/bsp/nrf52pdk \\\n build_profile=optimized\nTarget targets/ble_tgt successfully set target.app to apps/ble_app\nTarget targets/ble_tgt successfully set target.bsp to hw/bsp/nrf52pdk\nTarget targets/ble_tgt successfully set target.build_profile to optimized\n\n\n\n\n\nHere is the command you will need to setup your target for the nrf51:\n\n\n$ newt target set ble_tgt app=apps/ble_app \\\n bsp=hw/bsp/nrf51dk \\\n build_profile=optimized\nTarget targets/ble_tgt successfully set target.app to apps/ble_
app\nTarget targets/ble_tgt successfully set target.bsp to hw/bsp/nrf51dk\nTarget targets/ble_tgt successfully set target.build_profile to optimized\n\n\n\n\n\n\n\nNimble stack initialization\n\n\nWe are now going to explain how to setup your application to initialize the nimble stack and to get the basic stack, and its required modules, initialized and up and running. Note that the code shown here is an example of what is required for nimble stack operation; it is not intended to dictate to the developer exactly how to organize/setup your code. For example, the code sample shows modification of main.c in the application /src folder. The developer has the flexibility to organize the code as they see fit so this code does not need to reside in /src/main.c nor in the main() function itself. The only possible issue is the order of some of the initializations. Where this order is important it is indicated in the tutorial.\n\n\nA note about the code samples: the main() function in each c
ode sample builds upon the previous example. However, code outside of main() shows only what we add for each step. The last code sample shows the entire main.c that we created.\n\n\nLet's start with a very basic main() function (shown below). In this main all we are doing is initializing the Mynewt OS and starting it.\n\n\n#include \nos/os.h\n\n\n\nint\n\n\nmain\n(\nvoid\n)\n{\n \n/* Initialize OS */\n\n \nos_init\n();\n\n \n/* Start the OS */\n\n \nos_start\n();\n\n \n/* os start should never return. If it does, this should be an error */\n\n \nassert\n(\n0\n);\n}\n\n\n\n\n\nThe Nimble stack requires a number of packages/modules to be initialized prior to being initialized. We are going to add these one by one to the application and describe each.\n\n\n\n\nAdd cputime\n\n\nThe Nimble stack requires \"cputime\". This is provided by the Mynewt HAL of the\nsame name. The cputime HAL provides a high resolution timer that is used by the\nnimble stack (as the BLE specif
ication requires a fairly high resolution timer\nand has fairly tight timing requirements). The cputime HAL allows the user to\nspecify the timer resolution as different applications may require a different\nresolution. While the Nimble stack does not require a specific timer resolution\nper se, a resolution that is too large may affect performance and power\nefficiency. A suggested clock rate for HAL cputime for the nimble stack is 1\nMHz, or 1 microsecond per cputime tick. This provides enough resolution for\nmost needs while providing the Nimble stack enough resolution to implement the\nBLE specification.\n\n\nAdd the initialization of cputime to your application:\n\n\n#include \nhal/hal_cputime.h\n\n\n\n\nint\n\n\nmain\n(\nvoid\n)\n{\n \nint\n \nrc\n;\n\n \n/* Initialize OS */\n\n \nos_init\n();\n\n\n \n/* Set cputime to count at 1 usec increments */\n\n\n \nrc\n \n=\n \ncputime_init\n(\n1000000\n);\n\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n\n \n/* Start the O
S */\n\n \nos_start\n();\n\n \n/* os start should never return. If it does, this should be an error */\n\n \nassert\n(\n0\n);\n}\n\n\n\n\n\n\n\nCreate the system memory buffer pool\n\n\nThe Nimble stack allocates packet buffers (called mbufs) from the system memory buffer pool (msys). The system memory buffer pool and mbufs are described in the OS manual; we suggest reading that section in order to become familiar with mbufs if you are not already familiar with them. Note that the application itself (the unique application code that you are writing) does not need to use mbufs and none of the BLE host API exposed to the application developer uses them. However, the Nimble stack does require the existence of the system memory pool.\n\n\nCreating the memory pool and registering it with the system memory buffer pool can be a bit tricky the first time. However, using the template provided below it should be much easier. The header file /net/nimble/include/nimble/ble.h, which sho
uld be included in main.c, contains some MBUF macros that you will need to create the memory pool used by msys. The macro \nBLE_MBUF_PAYLOAD_SIZE\n defines the maximum amount of user payload, plus overhead, that a link layer BLE PDU can contain. The macro \nBLE_MBUF_MEMBLOCK_OVERHEAD\n is the amount of overhead required by the Nimble stack in each memory block used by the mbuf pool. The macro \nMBUF_NUM_MBUFS\n defines the number of mbufs in the mbuf pool and is defined locally. The user must determine, based on application requirements and platform memory size, how many mbufs are required. For example, if your application expects to have many simultaneous connections you may want to increase the size of the mbuf pool. In the example below, we assume you are only using a small number of active connections (2 to 3).\n\n\nA note about the size of the mbufs and \nBLE_MBUF_PAYLOAD_SIZE\n. Msys allows for multiple mbuf pools of various size. Currently, the Nimble stack requires that msys
has an mbuf pool registered that can accommodate the maximum size BLE LL PDU. Thus, we only show the creation of one mbuf pool of maximum size mbufs which gets registered to the system mbuf memory pool. We plan on modifying the Nimble stack so that smaller mbufs can be used (to conserve memory) but at this point in time you cannot modify \nBLE_MBUF_PAYLOAD_SIZE\n. Furthermore, you cannot add a mbuf pool of smaller size elements to the msys pool as the msys code might then allocate a mbuf that is too small for the nimble stack.\n\n\n/* Create a mbuf pool of BLE mbufs */\n\n\n#define MBUF_NUM_MBUFS (8)\n\n\n#define MBUF_BUF_SIZE OS_ALIGN(BLE_MBUF_PAYLOAD_SIZE, 4)\n\n\n#define MBUF_MEMBLOCK_SIZE (MBUF_BUF_SIZE + BLE_MBUF_MEMBLOCK_OVERHEAD)\n\n\n#define MBUF_MEMPOOL_SIZE OS_MEMPOOL_SIZE(MBUF_NUM_MBUFS, MBUF_MEMBLOCK_SIZE)\n\n\n\n\nstruct\n \nos_mbuf_pool\n \ng_mbuf_pool\n;\n\nstruct\n \nos_mempool\n \ng_mbuf_mempool\n;\n\nos_membuf_t\n \ng_mbuf_buffer\n[\nMBUF_MEMPOOL_SIZ
E\n];\n\n\n\nint\n\n\nmain\n(\nvoid\n)\n{\n \nint\n \nrc\n;\n\n \n/* Initialize OS */\n\n \nos_init\n();\n\n \n/* Set cputime to count at 1 usec increments */\n\n \nrc\n \n=\n \ncputime_init\n(\n1000000\n);\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n\n \n/* Create memory pool for Nimble packets and register with Msys */\n\n\n \nrc\n \n=\n \nos_mempool_init\n(\ng_mbuf_mempool\n, \nMBUF_NUM_MBUFS\n,\n\n \nMBUF_MEMBLOCK_SIZE\n, \ng_mbuf_buffer\n[\n0\n], \nmbuf_pool\n);\n\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n\n\n \nrc\n \n=\n \nos_mbuf_pool_init\n(\ng_mbuf_pool\n, \ng_mbuf_mempool\n, \nMBUF_MEMBLOCK_SIZE\n,\n\n \nMBUF_NUM_MBUFS\n);\n\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n\n\n \nrc\n \n=\n \nos_msys_register\n(\ng_mbuf_pool\n);\n\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n\n \n/* Start the OS */\n\n \nos_start\n();\n\n \n/* os start should never return. If it does, this should be an error */\n\n \nassert\n(\n0
\n);\n}\n\n\n\n\n\n\n\nInitializing the device address\n\n\nThe BLE specification requires that devices have an address (called a device address). This address can be either a public device address or a random device address. The current Nimble stack implementation requires that these addresses be defined somewhere in the application; they are not defined within the Nimble stack itself. This was done so that the entire application could have access to these addresses. We expect that we will move these addresses into the Nimble stack in a future release.\n\n\nThe two variables that must be defined are named \ng_dev_addr\n (public device address) and \ng_random_addr\n (static random address). The device address must be initialized prior to initializing the Nimble stack. The random address does not have to be initialized ahead of time as it is possible to set the random address in the Nimble controller when it is running. In this example, we only initialize the device address. The comp
any OUI in this example is 0a:bb:cc; the unique portion is 11:22:33 for a device address equal to 0a:bb:cc:11:22:33. Note that we store the address in little endian order as BLE expects the OUI to be in the most significant bytes.\n\n\n/* Our global device address (public) */\n\n\nuint8_t\n \ng_dev_addr\n[\nBLE_DEV_ADDR_LEN\n];\n\n\n\n/* Our random address (static) */\n\n\nuint8_t\n \ng_random_addr\n[\nBLE_DEV_ADDR_LEN\n];\n\n\n\nint\n\n\nmain\n(\nvoid\n)\n{\n \nint\n \nrc\n;\n\n \n/* Initialize OS */\n\n \nos_init\n();\n\n \n/* Set cputime to count at 1 usec increments */\n\n \nrc\n \n=\n \ncputime_init\n(\n1000000\n);\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n \n/* Create memory pool for Nimble packets and register with Msys */\n\n \nrc\n \n=\n \nos_mempool_init\n(\ng_mbuf_mempool\n, \nMBUF_NUM_MBUFS\n,\n \nMBUF_MEMBLOCK_SIZE\n, \ng_mbuf_buffer\n[\n0\n], \nmbuf_pool\n);\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n \nrc\n \n=\n \nos_mbuf_pool_init\n(\
ng_mbuf_pool\n, \ng_mbuf_mempool\n, \nMBUF_MEMBLOCK_SIZE\n,\n \nMBUF_NUM_MBUFS\n);\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n \nrc\n \n=\n \nos_msys_register\n(\ng_mbuf_pool\n);\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n\n \n/* Initialize our device address */\n\n\n \ng_dev_addr\n[\n0\n] \n=\n \n0x33\n;\n\n \ng_dev_addr\n[\n1\n] \n=\n \n0x22\n;\n\n \ng_dev_addr\n[\n2\n] \n=\n \n0x11\n;\n\n \ng_dev_addr\n[\n3\n] \n=\n \n0xcc\n;\n\n \ng_dev_addr\n[\n4\n] \n=\n \n0xbb\n;\n\n \ng_dev_addr\n[\n5\n] \n=\n \n0x0a\n;\n\n\n \n/* Start the OS */\n\n \nos_start\n();\n\n \n/* os start should never return. If it does, this should be an error */\n\n \nassert\n(\n0\n);\n}\n\n\n\n\n\n\n\nInitializing the statistics package\n\n\nThe Nimble stack uses the statistics package and this must be initialized prior to initializing the Nimble stack. Initializing the statistics package is quite simple; all you need to do is call the initialization fu
nction \nstats_module_init()\n.\n\n\n#include \nstats/stats.h\n\n\n\n\nint\n\n\nmain\n(\nvoid\n)\n{\n \nint\n \nrc\n;\n\n \n/* Initialize OS */\n\n \nos_init\n();\n\n \n/* Set cputime to count at 1 usec increments */\n\n \nrc\n \n=\n \ncputime_init\n(\n1000000\n);\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n \n/* Create memory pool for Nimble packets and register with Msys */\n\n \nrc\n \n=\n \nos_mempool_init\n(\ng_mbuf_mempool\n, \nMBUF_NUM_MBUFS\n,\n \nMBUF_MEMBLOCK_SIZE\n, \ng_mbuf_buffer\n[\n0\n], \nmbuf_pool\n);\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n \nrc\n \n=\n \nos_mbuf_pool_init\n(\ng_mbuf_pool\n, \ng_mbuf_mempool\n, \nMBUF_MEMBLOCK_SIZE\n,\n \nMBUF_NUM_MBUFS\n);\n \nassert\n(\nrc\n \n==\n \n0\n);\n\n \nrc\n \n=\n \nos_msys_register\n(\ng_mbuf_pool\n);\n \nassert\
<TRUNCATED>