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/12/20 01:16:29 UTC
[14/22] incubator-mynewt-site git commit: Added a tutorial to add
console to blinky. Updated newt documentation. Added a Latest News button on
front page
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8da4f0a3/latest/mkdocs/search_index.json
----------------------------------------------------------------------
diff --git a/latest/mkdocs/search_index.json b/latest/mkdocs/search_index.json
index 0885113..6121487 100644
--- a/latest/mkdocs/search_index.json
+++ b/latest/mkdocs/search_index.json
@@ -886,6 +886,61 @@
"title": "Let's Go!"
},
{
+ "location": "/os/tutorials/blinky_console/",
+ "text": "Enabling The Console and Shell for Blinky\n\n\n\n\nThis tutorial explains how to add the Console and Shell task to the blinky app so that you \ncan interact with it over a serial line connection.\n\n\n\n\nPre-Requisites\n\n\n\n\nEnsure you have installed \nnewt\n and that the \nnewt command is in your system path. \n\n\nYou must have Internet connectivity to fetch remote Mynewt components.\n\n\nYou must \ninstall the compiler tools\n to \nsupport native compiling to build the project this tutorial creates. \n\n\nYou must install the \nSegger JLINK package\n to \nload your project on the board.\n\n\nCable to establish a serial USB connection between the board and the laptop\n\n\n\n\n\n\nUse an existing project\n\n\nSince all we're doing is adding the shell and console capability to blinky, we assume \nthat you have worked through at least some of the other tutorials, and have an existing project.\nFor this example, we'll be modifying the \nblinky on nrf52\n proj
ect to enable \nthe shell and console connectivity. Feel free to use whatever version of blinky you'd like though.\n\n\n\n\nModify the Dependencies and Configuration\n\n\nThe first thing you'll need to add is a few new dependencies for your app. To add shell support to \nyour app make sure the following \npkg.deps\n are defined in your target's pkg.yml file:\n\n\npkg.deps:\n - \n@apache-mynewt-core/sys/console/full\n\n - \n@apache-mynewt-core/sys/shell\n\n - \n@apache-mynewt-core/sys/sysinit\n\n\n\n\n\n\nThis lets the newt system know that it needs to pull in the code for the console and the shell.\n\n\nNow we'll need to modify the settings for the app to turn on the shell, etc. by modifying the\n\nsyscfg.yml\n file for your target. (Remember, these files are in the targets/\n directory.)\nIf there isn't a \nsyscfg.yml\n file in your target's directory, you will need to create one.\n\n\n# Package: apps/bletiny\n\nsyscfg.vals:\n # Enable the shell task.\n SHELL_TASK: 1
\n # Enable Console OS Ticks\n CONSOLE_TICKS: 1\n # Enable Console Prompt\n CONSOLE_PROMPT: 1 \n\n\n\n\n\nAdd an Event Queue\n\n\nBlinky is a small app that doesn't make use of tasks or an event queue as many other apps do, so\nwe'll have to modify the source for the app in order to add one. \n\n\n/* System event queue task handler */\n\n\n#define SYSEVQ_PRIO (1)\n\n\n#define SYSEVQ_STACK_SIZE OS_STACK_ALIGN(512)\n\n\nstatic\n \nstruct\n \nos_task\n \ntask_sysevq\n;\n\nos_stack_t\n \nsysevq_stack\n[\nSYSEVQ_STACK_SIZE\n];\n\n\n/* Event queue for events handled by the system (shell, etc.) */\n\n\nstatic\n \nstruct\n \nos_eventq\n \nsys_evq\n;\n\n\n\n\n\nWe define a new \nos_task\n a task stack (\nsysevq_stack\n) and new system event queue \n(\nsys_evq\n) so that the shell and console will have an event queue to run in.\n\n\nNext we go down to our \ninit_tasks()\n function and initialize it\n\n\nos_task_init\n(\ntask_sysevq\n, \nsysevq\n, \nsysevq_handler\n, \nNULL\n,\n
\nSYSEVQ_PRIO\n, \nOS_WAIT_FOREVER\n, \nsysevq_stack\n, \nSYSEVQ_STACK_SIZE\n);\n\nos_eventq_init\n(\nsys_evq\n);\n\nos_eventq_dflt_set\n(\nsys_evq\n);\n\n\n\n\n\nThis will initialize the task, initialize the event queue, and then set the new event queue as\nthe default event queue. \n\n\nBuild targets\n\n\nWe're not going to build the bootloader here since we are assuming that you have already\nbuilt and loaded it during previous tutorials.\n\n\n$ newt build blinky\nArchiving cbmem.a\nCompiling crc16.c\nCompiling crc8.c\nArchiving crc.a\nCompiling mem.c\nArchiving mem.a\nLinking ~/dev/myproj/bin/targets/blinky/app/apps/blinky/blinky.elf\nTarget successfully built: targets/blinky\n\n\n\n\n\n\n\nCreate the app image\n\n\nGenerate a signed application image for the \nblinky\n target. The version number is arbitrary.\n\n\n$ newt create-image blinky 1.0.0\nApp image succesfully generated: ~/dev/myproj/bin/targets/blinky/app/apps/blinky/blinky.img\n\n\n\n\n\n\n\nLoad the i
mage\n\n\nMake sure the USB connector is in place and the power LED on the board is lit. Use the Power ON/OFF switch to reset the board after loading the image.\n\n\n$ newt load blinky\n\n\n\n\n\n\n\nSet up Serial connection\n\n\nYou'll need a Serial connection to see the output of your program. You can reference the \nSerial Port Setup\n \nTutorial for more information on setting up your serial communications.\n\n\n\n\nConnecting with your app\n\n\nOnce you have a connection set up, you can connect to your device with \nminicom -D /dev/tty.usbmodem\nport\n -b 115200\n to run connect\nto the console of your app. \n\n\nTo test and make sure that the Shell is running, first just hit \n:\n\n\n3534: \n\n\n\n\n\n\nRemember, we turned the CONSOLE_PROMPT and the CONSOLE_TICKS on earlier. You can try some commands now:\n\n\n3609: \n ?\nCommands:\n8841: echo ? prompt ticks tasks mempools\n8843: date b\n8844: \n ticks off\n Console Ticks off\n \n prompt off
\n Prompt now off.\nticks on\n33383: Console Ticks on\n\n33568:\nprompt on\n39108: Prompt now on.\n39108: \n\n\n\n\n\n\nAnd there you have the Console and Shell working in an app that previously had no event queue!",
+ "title": "Add Console and Shell to Blinky"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#enabling-the-console-and-shell-for-blinky",
+ "text": "This tutorial explains how to add the Console and Shell task to the blinky app so that you \ncan interact with it over a serial line connection.",
+ "title": "Enabling The Console and Shell for Blinky"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#pre-requisites",
+ "text": "Ensure you have installed newt and that the \nnewt command is in your system path. You must have Internet connectivity to fetch remote Mynewt components. You must install the compiler tools to \nsupport native compiling to build the project this tutorial creates. You must install the Segger JLINK package to \nload your project on the board. Cable to establish a serial USB connection between the board and the laptop",
+ "title": "Pre-Requisites"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#use-an-existing-project",
+ "text": "Since all we're doing is adding the shell and console capability to blinky, we assume \nthat you have worked through at least some of the other tutorials, and have an existing project.\nFor this example, we'll be modifying the blinky on nrf52 project to enable \nthe shell and console connectivity. Feel free to use whatever version of blinky you'd like though.",
+ "title": "Use an existing project"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#modify-the-dependencies-and-configuration",
+ "text": "The first thing you'll need to add is a few new dependencies for your app. To add shell support to \nyour app make sure the following pkg.deps are defined in your target's pkg.yml file: pkg.deps:\n - @apache-mynewt-core/sys/console/full \n - @apache-mynewt-core/sys/shell \n - @apache-mynewt-core/sys/sysinit This lets the newt system know that it needs to pull in the code for the console and the shell. Now we'll need to modify the settings for the app to turn on the shell, etc. by modifying the syscfg.yml file for your target. (Remember, these files are in the targets/ directory.)\nIf there isn't a syscfg.yml file in your target's directory, you will need to create one. # Package: apps/bletiny\n\nsyscfg.vals:\n # Enable the shell task.\n SHELL_TASK: 1\n # Enable Console OS Ticks\n CONSOLE_TICKS: 1\n # Enable Console Prompt\n CONSOLE_PROMPT: 1",
+ "title": "Modify the Dependencies and Configuration"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#add-an-event-queue",
+ "text": "Blinky is a small app that doesn't make use of tasks or an event queue as many other apps do, so\nwe'll have to modify the source for the app in order to add one. /* System event queue task handler */ #define SYSEVQ_PRIO (1) #define SYSEVQ_STACK_SIZE OS_STACK_ALIGN(512) static struct os_task task_sysevq ; os_stack_t sysevq_stack [ SYSEVQ_STACK_SIZE ]; /* Event queue for events handled by the system (shell, etc.) */ static struct os_eventq sys_evq ; We define a new os_task a task stack ( sysevq_stack ) and new system event queue \n( sys_evq ) so that the shell and console will have an event queue to run in. Next we go down to our init_tasks() function and initialize it os_task_init ( task_sysevq , sysevq , sysevq_handler , NULL ,\n SYSEVQ_PRIO , OS_WAIT_FOREVER , sysevq_stack , SYSEVQ_STACK_SIZE ); os_eventq_init ( sys_evq ); os_eventq_dflt_set ( sys_evq ); This will initialize the task, initialize the event queue, and
then set the new event queue as\nthe default event queue.",
+ "title": "Add an Event Queue"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#build-targets",
+ "text": "We're not going to build the bootloader here since we are assuming that you have already\nbuilt and loaded it during previous tutorials. $ newt build blinky\nArchiving cbmem.a\nCompiling crc16.c\nCompiling crc8.c\nArchiving crc.a\nCompiling mem.c\nArchiving mem.a\nLinking ~/dev/myproj/bin/targets/blinky/app/apps/blinky/blinky.elf\nTarget successfully built: targets/blinky",
+ "title": "Build targets"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#create-the-app-image",
+ "text": "Generate a signed application image for the blinky target. The version number is arbitrary. $ newt create-image blinky 1.0.0\nApp image succesfully generated: ~/dev/myproj/bin/targets/blinky/app/apps/blinky/blinky.img",
+ "title": "Create the app image"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#load-the-image",
+ "text": "Make sure the USB connector is in place and the power LED on the board is lit. Use the Power ON/OFF switch to reset the board after loading the image. $ newt load blinky",
+ "title": "Load the image"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#set-up-serial-connection",
+ "text": "You'll need a Serial connection to see the output of your program. You can reference the Serial Port Setup \nTutorial for more information on setting up your serial communications.",
+ "title": "Set up Serial connection"
+ },
+ {
+ "location": "/os/tutorials/blinky_console/#connecting-with-your-app",
+ "text": "Once you have a connection set up, you can connect to your device with minicom -D /dev/tty.usbmodem port -b 115200 to run connect\nto the console of your app. To test and make sure that the Shell is running, first just hit : 3534: Remember, we turned the CONSOLE_PROMPT and the CONSOLE_TICKS on earlier. You can try some commands now: 3609: ?\nCommands:\n8841: echo ? prompt ticks tasks mempools\n8843: date b\n8844: ticks off\n Console Ticks off\n prompt off\n Prompt now off.\nticks on\n33383: Console Ticks on\n\n33568:\nprompt on\n39108: Prompt now on.\n39108: And there you have the Console and Shell working in an app that previously had no event queue!",
+ "title": "Connecting with your app"
+ },
+ {
"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 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"
@@ -9887,7 +9942,7 @@
},
{
"location": "/newt/newt_intro/",
- "text": "Newt Tool\n\n\nIntroduction\n\n\nNewt is a smart build and package management system for embedded contexts. It is a single tool that accomplishes both the following goals:\n\n\n\n\nsource package management \n\n\nbuild, debug and install.\n\n\n\n\nRationale\n\n\nIn order for the Mynewt operating system to work well for constrained environments across the many different types of microcontroller applications (from doorbells to medical devices to power grids), a system is needed that lets you select which packages to install and which packages to build.\n\n\nThe build systems for embedded devices are often fairly complicated and not well served for this purpose. For example, autoconf is designed for detecting system compatibility issues but not well suited when it comes to tasks like:\n\n\n\n\nBuilding for multiple targets\n\n\nDeciding what to build in and what not to build in\n\n\nManaging dependencies between components\n\n\n\n\nFortunately, solutions addressi
ng these very issues can be found in source package management systems in higher level languages such as Javascript \n(Node), Go, PHP and Ruby. We decided to fuse their source management \nsystems with a make system built for embedded systems and create Newt.\n\n\nBuild System\n\n\nA good build system must allow the user to take a few common steps while developing embedded applications:\n\n\n\n\nGenerate full flash images\n\n\nDownload debug images to a target board using a debugger\n\n\nConditionally compile libraries \n code based upon build settings\n\n\n\n\nNewt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:\n\n\n$ tree -L 3 \n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\n\u251c\u2500\u2500 apps\n\n\u2502 \u2514\u2500\u2500 blinky\n\u2502 \u251c\u2500\u2500 pkg.yml\n\u2502 \u2514\u25
00\u2500 src\n\u251c\u2500\u2500 project.yml\n\n\u2514\u2500\u2500 targets\n\n \u251c\u2500\u2500 my_blinky_sim\n \u2502 \u251c\u2500\u2500 pkg.yml\n \u2502 \u2514\u2500\u2500 target.yml\n \u2514\u2500\u2500 unittest\n \u251c\u2500\u2500 pkg.yml\n \u2514\u2500\u2500 target.yml\n\n6 directories, 10 files\n\n\n\n\n\n\n\nWhen Newt sees a directory tree that contains a \"project.yml\" file, it is smart enough to recognize it as the base directory of a project, and \nautomatically builds a package tree. It also recognizes two important package directories in the package tree - \"apps\" and \"targets\". More on these directories in \nNewt Theory of Ops\n.\n\n\nWhen Newt is told to build a project, it recursively resolves all package dependencies and generates artifacts that are placed in the bin/ directory at the top-level of the project. The artifact directory is prefixed by the target name being built - \nmy_blinky_sim\n for example:\n\n\n$ tree bin\n
bin\n\u2514\u2500\u2500 my_blinky_sim\n \u251c\u2500\u2500 apps\n \u2502\u00a0\u00a0 \u2514\u2500\u2500 blinky\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.a\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.a.cmd\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.cmd\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.dSYM\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 Contents\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 Info.plist\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 Resources\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 DWARF\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 blinky.elf\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.lst\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 main.d\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 main.o\n \
u2502\u00a0\u00a0 \u2514\u2500\u2500 main.o.cmd\n \u251c\u2500\u2500 hw\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 bsp\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 native\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.d\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.o\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.o.cmd\n\nsnip\n\n\n\n\n\n\n\n\nMore operations using Newt\n\n\nOnce a target has been built, Newt allows additional operations on the target. \n\n\n\n\ndownload\n: Download built target to board\n\n\ndebug\n: Open debugger session to target\n\n\nsize\n: Get size of target components\n\n\ncreate-image\n: Add image header to the binary image\n\n\n\n\nFor more details on how Newt works, go to \nNewt - Theory of Operations\n.\n\n\n\n\nSource Management and Repositories\n\n\nThe other major element of the Newt tool is the ability to create reusable source distributions from
a collection of code. \nA project can be a reusable container of source code.\n In other words, projects can be versioned and redistributed, not packages. A project bundles together packages that are typically needed to work together in a product e.g. RTOS core, filesystem APIs, and networking stack.\n\n\nA project that has been made redistributable is known as a \nrepository\n. \nRepositories can be added to your local project by adding them into your project.yml file. Here is an example of the blinky project's yml file which relies on apache-mynewt-core:\n\n\n$ more project.yml\n\nsnip\n\nproject.repositories:\n - apache-mynewt-core\n\n# Use github\ns distribution mechanism for core ASF libraries.\n# This provides mirroring automatically for us.\n#\nrepository.apache-mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core\n\n\n\n\n\n\n\nWhen you specify this repository in the blinky's project file, you can then use the Newt t
ool to install dependencies:\n\n\n$ newt install\nDownloading repository description for apache-mynewt-core... success!\nDownloading repository incubator-mynewt-core (branch: develop) at \nhttps://github.com/apache/incubator-mynewt-core.git\nCloning into \n\n/var/folders/7l/7b3w9m4n2mg3sqmgw2q1b9p80000gn/T/newt-repo814721459\n...\nremote: Counting objects: 17601, done.\nremote: Compressing objects: 100% (300/300), done.\nremote: Total 17601 (delta 142), reused 0 (delta 0), pack-reused 17284\nReceiving objects: 100% (17601/17601), 6.09 MiB | 3.17 MiB/s, done.\nResolving deltas: 100% (10347/10347), done.\nChecking connectivity... done.\nRepos successfully installed\n\n\n\n\n\n\n\nNewt will install this repository in the \n/repos directory. In the case of blinky, the directory structure ends up looking like:\n\n\n$ tree -L 2\n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 apps\n\u2502 \u2514\u
2500\u2500 blinky\n\u251c\u2500\u2500 project.state\n\u251c\u2500\u2500 project.yml\n\u251c\u2500\u2500 repos\n\u2502 \u2514\u2500\u2500 apache-mynewt-core\n\u2514\u2500\u2500 targets\n \u251c\u2500\u2500 my_blinky_sim\n \u2514\u2500\u2500 unittest\n\n\n\n\n\n\n\nIn order to reference the installed repositories in packages, the \"@\" notation should be specified in the repository specifier. As an example, the apps/blinky application has the following dependencies in its pkg.yml file. This tells the build system to look in the base directory of repos/apache-mynewt-core for the \nlibs/os\n, \nhw/hal\n, and \nlibs/console/full\n packages.\n\n\n$ more apps/blinky/pkg.yml\n\nsnip\n\npkg.deps:\n - \n@apache-mynewt-core/libs/os\n\n - \n@apache-mynewt-core/hw/hal\n\n - \n@apache-mynewt-core/libs/console/full\n\n\n\n\n\n\n\n\nAutocompletion in Bash\n\n\nNewt has the ability to autocomplete within \nbash\n. The following instructions allow MAC users to enable autocompl
ete within \nbash\n.\n\n\n\n\nInstall the autocomplete tools for bash via \nbrew install bash-completion\n\n\nTell your shell to use newt for autocompletion of newt via \ncomplete -C \"newt complete\" newt\n. You can add this to your .bashrc or other init file to have it automatically set for all bash shells.\n\n\n\n\nNotes:\n\n\n\n\nAutocomplete will give you flag hints, but only if you type a '-'. \n\n\nAutocomplete will not give you completion hints for the flag arguments (those optional things after the flag like \n-l DEBUG\n)\n\n\nAutocomplete uses newt to parse the project to find targets and libs.",
+ "text": "Newt Tool\n\n\nIntroduction\n\n\nNewt is a smart build and package management system for embedded contexts. It is a single tool that accomplishes both the following goals:\n\n\n\n\nsource package management \n\n\nbuild, debug and install.\n\n\n\n\nRationale\n\n\nIn order for the Mynewt operating system to work well for constrained environments across the many different types of microcontroller applications (from doorbells to medical devices to power grids), a system is needed that lets you select which packages to install and which packages to build.\n\n\nThe build systems for embedded devices are often fairly complicated and not well served for this purpose. For example, autoconf is designed for detecting system compatibility issues but not well suited when it comes to tasks like:\n\n\n\n\nBuilding for multiple targets\n\n\nDeciding what to build in and what not to build in\n\n\nManaging dependencies between components\n\n\n\n\nFortunately, solutions addressi
ng these very issues can be found in source package management systems in higher level languages such as Javascript \n(Node), Go, PHP and Ruby. We decided to fuse their source management \nsystems with a make system built for embedded systems and create Newt.\n\n\nBuild System\n\n\nA good build system must allow the user to take a few common steps while developing embedded applications:\n\n\n\n\nGenerate full flash images\n\n\nDownload debug images to a target board using a debugger\n\n\nConditionally compile libraries \n code based upon build settings\n\n\n\n\nNewt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:\n\n\n$ tree -L 3 \n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\n\u251c\u2500\u2500 apps\n\n\u2502 \u2514\u2500\u2500 blinky\n\u2502 \u251c\u2500\u2500 pkg.yml\n\u2502 \u2514\u25
00\u2500 src\n\u251c\u2500\u2500 project.yml\n\n\u2514\u2500\u2500 targets\n\n \u251c\u2500\u2500 my_blinky_sim\n \u2502 \u251c\u2500\u2500 pkg.yml\n \u2502 \u2514\u2500\u2500 target.yml\n \u2514\u2500\u2500 unittest\n \u251c\u2500\u2500 pkg.yml\n \u2514\u2500\u2500 target.yml\n\n6 directories, 10 files\n\n\n\n\n\n\n\nWhen Newt sees a directory tree that contains a \"project.yml\" file, it is smart enough to recognize it as the base directory of a project, and \nautomatically builds a package tree. It also recognizes two important package directories in the package tree - \"apps\" and \"targets\". More on these directories in \nNewt Theory of Ops\n.\n\n\nWhen Newt is told to build a project, it recursively resolves all package dependencies and generates artifacts that are placed in the bin/ directory at the top-level of the project. The artifact directory is prefixed by the target name being built - \nmy_blinky_sim\n for example:\n\n\n$ tree bin\n
bin\n\u2514\u2500\u2500 my_blinky_sim\n \u251c\u2500\u2500 apps\n \u2502\u00a0\u00a0 \u2514\u2500\u2500 blinky\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.a\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.a.cmd\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.cmd\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.dSYM\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 Contents\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 Info.plist\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 Resources\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 DWARF\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 blinky.elf\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 blinky.elf.lst\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 main.d\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 main.o\n \
u2502\u00a0\u00a0 \u2514\u2500\u2500 main.o.cmd\n \u251c\u2500\u2500 hw\n \u2502\u00a0\u00a0 \u251c\u2500\u2500 bsp\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 native\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.d\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.o\n \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 hal_bsp.o.cmd\n\nsnip\n\n\n\n\n\n\n\n\nMore operations using Newt\n\n\nOnce a target has been built, Newt allows additional operations on the target. \n\n\n\n\nload\n: Download built target to board\n\n\ndebug\n: Open debugger session to target\n\n\nsize\n: Get size of target components\n\n\ncreate-image\n: Add image header to the binary image\n\n\nrun\n: Build, create image, load, and finally open a debug session with the target\n\n\n\n\nFor more details on how Newt works, go to \nNewt - Theory of Operations\n.\n\n\n\n\nSource Management and Repositories\n\n\nThe other major
element of the Newt tool is the ability to create reusable source distributions from a collection of code. \nA project can be a reusable container of source code.\n In other words, projects can be versioned and redistributed, not packages. A project bundles together packages that are typically needed to work together in a product e.g. RTOS core, filesystem APIs, and networking stack.\n\n\nA project that has been made redistributable is known as a \nrepository\n. \nRepositories can be added to your local project by adding them into your project.yml file. Here is an example of the blinky project's yml file which relies on apache-mynewt-core:\n\n\n$ more project.yml\n\nsnip\n\nproject.repositories:\n - apache-mynewt-core\n\n# Use github\ns distribution mechanism for core ASF libraries.\n# This provides mirroring automatically for us.\n#\nrepository.apache-mynewt-core:\n type: github\n vers: 0-latest\n user: apache\n repo: incubator-mynewt-core\n\n\n\n\n\n\n\nWhen y
ou specify this repository in the blinky's project file, you can then use the Newt tool to install dependencies:\n\n\n$ newt install\nDownloading repository description for apache-mynewt-core... success!\nDownloading repository incubator-mynewt-core (branch: develop) at \nhttps://github.com/apache/incubator-mynewt-core.git\nCloning into \n\n/var/folders/7l/7b3w9m4n2mg3sqmgw2q1b9p80000gn/T/newt-repo814721459\n...\nremote: Counting objects: 17601, done.\nremote: Compressing objects: 100% (300/300), done.\nremote: Total 17601 (delta 142), reused 0 (delta 0), pack-reused 17284\nReceiving objects: 100% (17601/17601), 6.09 MiB | 3.17 MiB/s, done.\nResolving deltas: 100% (10347/10347), done.\nChecking connectivity... done.\nRepos successfully installed\n\n\n\n\n\n\n\nNewt will install this repository in the \n/repos directory. In the case of blinky, the directory structure ends up looking like:\n\n\n$ tree -L 2\n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2
500 NOTICE\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 apps\n\u2502 \u2514\u2500\u2500 blinky\n\u251c\u2500\u2500 project.state\n\u251c\u2500\u2500 project.yml\n\u251c\u2500\u2500 repos\n\u2502 \u2514\u2500\u2500 apache-mynewt-core\n\u2514\u2500\u2500 targets\n \u251c\u2500\u2500 my_blinky_sim\n \u2514\u2500\u2500 unittest\n\n\n\n\n\n\n\nIn order to reference the installed repositories in packages, the \"@\" notation should be specified in the repository specifier. As an example, the apps/blinky application has the following dependencies in its pkg.yml file. This tells the build system to look in the base directory of repos/apache-mynewt-core for the \nlibs/os\n, \nhw/hal\n, and \nlibs/console/full\n packages.\n\n\n$ more apps/blinky/pkg.yml\n\nsnip\n\npkg.deps:\n - \n@apache-mynewt-core/libs/os\n\n - \n@apache-mynewt-core/hw/hal\n\n - \n@apache-mynewt-core/libs/console/full\n\n\n\n\n\n\n\n\nAutocompletion in Bash\n\n\nNewt has the ability to autocompl
ete within \nbash\n. The following instructions allow MAC users to enable autocomplete within \nbash\n.\n\n\n\n\nInstall the autocomplete tools for bash via \nbrew install bash-completion\n\n\nTell your shell to use newt for autocompletion of newt via \ncomplete -C \"newt complete\" newt\n. You can add this to your .bashrc or other init file to have it automatically set for all bash shells.\n\n\n\n\nNotes:\n\n\n\n\nAutocomplete will give you flag hints, but only if you type a '-'. \n\n\nAutocomplete will not give you completion hints for the flag arguments (those optional things after the flag like \n-l DEBUG\n)\n\n\nAutocomplete uses newt to parse the project to find targets and libs.",
"title": "toc"
},
{
@@ -9912,7 +9967,7 @@
},
{
"location": "/newt/newt_intro/#more-operations-using-newt",
- "text": "Once a target has been built, Newt allows additional operations on the target. download : Download built target to board debug : Open debugger session to target size : Get size of target components create-image : Add image header to the binary image For more details on how Newt works, go to Newt - Theory of Operations .",
+ "text": "Once a target has been built, Newt allows additional operations on the target. load : Download built target to board debug : Open debugger session to target size : Get size of target components create-image : Add image header to the binary image run : Build, create image, load, and finally open a debug session with the target For more details on how Newt works, go to Newt - Theory of Operations .",
"title": "More operations using Newt"
},
{
@@ -9927,7 +9982,7 @@
},
{
"location": "/newt/newt_operation/",
- "text": "Newt Tool - Theory of Operations\n\n\nNewt has a fairly smart package manager that can read a directory tree, build a dependency tree, and emit the right build artifacts.\n\n\nBuilding dependencies\n\n\nNewt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:\n\n\n$ tree -L 3 \n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\n\u251c\u2500\u2500 apps\n\n\u2502 \u2514\u2500\u2500 blinky\n\u2502 \u251c\u2500\u2500 pkg.yml\n\u2502 \u2514\u2500\u2500 src\n\u251c\u2500\u2500 project.yml\n\n\u2514\u2500\u2500 targets\n\n \u251c\u2500\u2500 my_blinky_sim\n \u2502 \u251c\u2500\u2500 pkg.yml\n \u2502 \u2514\u2500\u2500 target.yml\n \u2514\u2500\u2500 unittest\n \u251c\u2500\u2500 pkg.yml\n \u2514\u2500\u2500 target.yml\n\n6 directories, 10 files\n\n\
n\n\n\n\n\nWhen Newt sees a directory tree that contains a \"project.yml\" file it knows that it is in the base directory of a project, and automatically builds a package tree. You can see that there are two essential package directories, \"apps\" and \"targets.\" \n\n\n\n\n\"apps\" Package Directory\n\n\napps\n is where applications are stored, and applications are where the main() function is contained. Along with the \ntargets\n directory, \napps\n represents the top-level of the build tree, and define the dependencies and features for the rest of the system.\n\n\nThe app definition is contained in a \npkg.yml\n file. An example of blinky's \npkg.yml\n file is:\n\n\n$ more apps/blinky/pkg.yml\n\nsnip\n\npkg.name: apps/blinky\npkg.vers: 0.8.0\npkg.description: Basic example application which blinks an LED.\npkg.author: \nApache Mynewt \ndev@mynewt.incubator.apache.org\n\npkg.homepage: \nhttp://mynewt.apache.org/\n\npkg.repository:\npkg.keywords:\n\npkg.deps:\n - \n@apache-myn
ewt-core/libs/os\n\n - \n@apache-mynewt-core/hw/hal\n\n - \n@apache-mynewt-core/libs/console/full\n\n\n\n\n\n\n\n\nThis file says that the name of the package is apps/blinky, and it \ndepends on libs/os, hw/hal and libs/console/full packages.\n\n\nNOTE:\n @apache-mynewt-core is a repository descriptor, and this will be \ncovered in the \"repository\" section. \n\n\n\n\n\"targets\" Package Directory\n\n\ntargets\n is where targets are stored, and each target is a collection of parameters that must be passed to Newt in order to generate a reproducible build. Along with the \napps\n directory, \ntargets\n represents the top of the build tree. Any packages or parameters specified at the target level cascades down to all dependencies.\n\n\nMost targets consist of:\n\n\n\n\napp: The application to build\n\n\nbsp: The board support package to combine with that application\n\n\nbuild_profile: Either debug or optimized.\n\n\n\n\nThe \nmy_blinky_sim\n target in the example below has t
he following settings:\n\n\n$ newt target show\ntargets/my_blinky_sim\n app=apps/blinky\n bsp=@apache-mynewt-core/hw/bsp/native\n build_profile=debug\n$ ls my_blinky_sim/\npkg.yml target.yml\n\n\n\n\n\nIn general, the three basic parameters of a target (\napp\n, \nbsp\n, and \nbuild_profile\n) are stored in the \ntarget.yml\n file in that target's build directory under \ntargets\n. You will also see a \npkg.yml\n file in the same directory. Since targets are packages, a \npkg.yml\n is expected. It contains typical package descriptors, dependencies, and additional parameters such as the following:\n\n\n\n\nCflags: Any additional compiler flags you might want to specify to the build\n\n\nAflags: Any additional assembler flags you might want to specify to the build\n\n\nLflags: Any additional linker flags you might want to specify to the build\n\n\nfeatures: Any system level features you want to enable.\n\n\n\n\n\n\nResolving dependencies\n\n\nWhen newt is told to build a
project, it will:\n\n\n\n\nfind the top-level project.yml file\n\n\nrecurse the packages in the package tree, and build a list of all \nsource packages\n\n\n\n\nNewt then looks at the target that the user set, for example, blinky_sim:\n\n\n$ more targets/my_blinky_sim/\npkg.yml target.yml\n$ more targets/my_blinky_sim/target.yml\n### Target: targets/my_blinky_sim\ntarget.app: \napps/blinky\n\ntarget.bsp: \n@apache-mynewt-core/hw/bsp/native\n\ntarget.build_profile: \ndebug\n\n\n\n\n\n\n\n\nThe target specifies two major things:\n\n\n\n\nApplication (target.app): The application to build\n\n\nBoard Support Package (target.bsp): The board support package to build \nalong with that application.\n\n\n\n\nNewt goes and builds the dependency tree specified by all the packages. While building this tree, it does a few other things:\n\n\n\n\nAny package that depends on another package, automatically gets the include directories from the package it includes. Include directories in the\nne
wt structure must always be prefixed by the package name. For example, libs/os has the following include tree and its include directory files contains the package name \"os\" before any header files. This is so in order to avoid any header file conflicts.\n\n\n\n\n$ tree\n.\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 include\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 arch\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m0\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m4\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 sim\n\u25
02\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 endian.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_callout.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_cfg.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_eventq.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_heap.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_malloc.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mbuf.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mempool.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mutex.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sanity.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sched.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sem.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_task.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_test.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_time.h
\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 queue.h\n\u251c\u2500\u2500 pkg.yml\n\u2514\u2500\u2500 src\n \u251c\u2500\u2500 arch\n\nsnip\n\n\n\n\n\n\n\n\n\n\n\n\nAPI requirements are validated. Packages can export APIs they \nimplement, (i.e. pkg.api: hw-hal-impl), and other packages can require \nthose APIs (i.e. pkg.req_api: hw-hal-impl).\n\n\n\n\n\n\n\"Features\" options are supported. Packages can change what dependencies \nthey have, or what flags they are using based upon what features are enabled in the system. As an example, many packages will add additional software, based on whether the shell package is present. To do this, they can overwrite cflags or deps based upon the shell \"feature.\"\n\n\n\n\n\n\npkg.cflags.SHELL: -DSHELL_PRESENT\n\n\n\n\n\n\n\nIn order to properly resolve all dependencies in the build system, Newt recursively processes the package dependencies until there are no new dependencies or features (because features can add dependencies.) And it b
uilds a big list of all the packages that need to be build.\n\n\nNewt then goes through this package list, and builds every package into \nan archive file.\n\n\nNOTE:\n The Newt tool generates compiler dependencies for all of these packages, and only rebuilds the packages whose dependencies have changed. Changes in package \n project dependencies are also taken into account. It is smart, after all!\n\n\nProducing artifacts\n\n\nOnce Newt has built all the archive files, it then links the archive files together. The linkerscript to use is specified by the board support package (BSP.)\n\n\nNOTE: One common use of the \"features\" option above is to overwrite \nwhich linkerscript is used, based upon whether or not the BSP is being \nbuild for a raw image, bootable image or bootloader itself.\n\n\nThe newt tool places all of it's artifacts into the bin/ directory at \nthe top-level of the project, prefixed by the target name being built, \nfor example:\n\n\n$ tree -L 4 bin/\nbin/\n\u25
14\u2500\u2500 my_blinky_sim\n \u251c\u2500\u2500 apps\n \u2502 \u2514\u2500\u2500 blinky\n \u2502 \u251c\u2500\u2500 blinky.a\n \u2502 \u251c\u2500\u2500 blinky.a.cmd\n \u2502 \u251c\u2500\u2500 blinky.elf\n \u2502 \u251c\u2500\u2500 blinky.elf.cmd\n \u2502 \u251c\u2500\u2500 blinky.elf.dSYM\n \u2502 \u251c\u2500\u2500 blinky.elf.lst\n \u2502 \u251c\u2500\u2500 main.d\n \u2502 \u251c\u2500\u2500 main.o\n \u2502 \u2514\u2500\u2500 main.o.cmd\n \u251c\u2500\u2500 hw\n \u2502 \u251c\u2500\u2500 bsp\n \u2502 \u2502 \u2514\u2500\u2500 native\n \u2502 \u251c\u2500\u2500 hal\n \u2502 \u2502 \u251c\u2500\u2500 flash_map.d\n \u2502 \u2502 \u251c\u2500\u2500 flash_map.o\n\nsnip\n\n\n\n\n\n\n\n\nAs you can see, a number of files are generated:\n\n\n\n\nArchive File\n\n\n*.cmd: The command use to generate the object or archive file\n\n\n*.lst: The list fil
e where symbols are located\n\n\n*.o The object files that get put into the archive file\n\n\n\n\nDownload/Debug Support\n\n\nOnce a target has been build, there are a number of helper functions \nthat work on the target. These are:\n\n\n\n\ndownload\n Download built target to board\n\n\ndebug\n Open debugger session to target\n\n\nsize Size of target components\n\n\ncreate-image Add image header to target binary\n\n\n\n\nDownload and debug handles driving GDB and the system debugger. These \ncommands call out to scripts that are defined by the BSP.\n\n\n$ more repos/apache-mynewt-core/hw/bsp/nrf52pdk/nrf52pdk_debug.sh\n\nsnip\n\n#\nif [ $# -lt 1 ]; then\n echo \nNeed binary to download\n\n exit 1\nfi\n\nFILE_NAME=$2.elf\nGDB_CMD_FILE=.gdb_cmds\n\necho \nDebugging\n $FILE_NAME\n\n# Monitor mode. Background process gets it\ns own process group.\nset -m\nJLinkGDBServer -device nRF52 -speed 4000 -if SWD -port 3333 -singlerun \n\nset +m\n\necho \ntarget remo
te localhost:3333\n \n $GDB_CMD_FILE\n\narm-none-eabi-gdb -x $GDB_CMD_FILE $FILE_NAME\n\nrm $GDB_CMD_FILE\n\n\n\n\n\nThe idea is that every BSP will add support for the debugger environment \nfor that board. That way common tools can be used across various development boards and kits.\n\n\nNOTE:\n Both for compiler definitions and debugger scripts, the plan is to \ncreate Dockerizable containers of these toolchains. This should make \nthings much easier to support across Mac OS X, Linux and Windows. Newt \nwill know how to call out to Docker to perform these processes.",
+ "text": "Newt Tool - Theory of Operations\n\n\nNewt has a fairly smart package manager that can read a directory tree, build a dependency tree, and emit the right build artifacts.\n\n\nBuilding dependencies\n\n\nNewt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:\n\n\n$ tree -L 3 \n.\n\u251c\u2500\u2500 DISCLAIMER\n\u251c\u2500\u2500 LICENSE\n\u251c\u2500\u2500 NOTICE\n\u251c\u2500\u2500 README.md\n\n\u251c\u2500\u2500 apps\n\n\u2502 \u2514\u2500\u2500 blinky\n\u2502 \u251c\u2500\u2500 pkg.yml\n\u2502 \u2514\u2500\u2500 src\n\u251c\u2500\u2500 project.yml\n\n\u2514\u2500\u2500 targets\n\n \u251c\u2500\u2500 my_blinky_sim\n \u2502 \u251c\u2500\u2500 pkg.yml\n \u2502 \u2514\u2500\u2500 target.yml\n \u2514\u2500\u2500 unittest\n \u251c\u2500\u2500 pkg.yml\n \u2514\u2500\u2500 target.yml\n\n6 directories, 10 files\n\n\
n\n\n\n\n\nWhen Newt sees a directory tree that contains a \"project.yml\" file it knows that it is in the base directory of a project, and automatically builds a package tree. You can see that there are two essential package directories, \"apps\" and \"targets.\" \n\n\n\n\n\"apps\" Package Directory\n\n\napps\n is where applications are stored, and applications are where the main() function is contained. The base project directory comes with one simple app called \nblinky\n in the \napps\n directory. The core repository \n@apache-mynewt-core\n comes with many additional sample apps in its \napps\n directory. At the time of this writing, there are several example BLE apps, the boot app, slinky app for using newt manager protocol, and more in that directory.\n\n\n@~/dev/myproj$ ls repos/apache-mynewt-core/apps/\nblecent bleprph_oic bleuart ffs2native slinky_oic test\nblehci bletest boot ocf_sample spitest timtest\nbleprph bletiny fat2native sl
inky splitty\n\n\n\n\n\nAlong with the \ntargets\n directory, \napps\n represents the top-level of the build tree for the particular project, and define the dependencies and features for the rest of the system. Mynewt users and developers can add their own apps to the project's \napps\n directory. \n\n\nThe app definition is contained in a \npkg.yml\n file. For example, blinky's \npkg.yml\n file is:\n\n\n$ more apps/blinky/pkg.yml\n\nsnip\n\npkg.name: apps/blinky\npkg.type: app\npkg.description: Basic example application which blinks an LED.\npkg.author: \nApache Mynewt \ndev@mynewt.incubator.apache.org\n\npkg.homepage: \nhttp://mynewt.apache.org/\n\npkg.keywords:\n\npkg.deps:\n - \n@apache-mynewt-core/kernel/os\n\n - \n@apache-mynewt-core/hw/hal\n\n - \n@apache-mynewt-core/sys/console/full\n\n\n\n\n\n\n\n\nThis file says that the name of the package is apps/blinky, and it \ndepends on kernel/os, hw/hal and sys/console/full packages.\n\n\nNOTE:\n @apache-mynewt-core
is a repository descriptor, and this will be \ncovered in the \"repository\" section. \n\n\n\n\n\"targets\" Package Directory\n\n\ntargets\n is where targets are stored, and each target is a collection of parameters that must be passed to Newt in order to generate a reproducible build. Along with the \napps\n directory, \ntargets\n represents the top of the build tree. Any packages or parameters specified at the target level cascades down to all dependencies.\n\n\nMost targets consist of:\n\n\n\n\napp: The application to build\n\n\nbsp: The board support package to combine with that application\n\n\nbuild_profile: Either debug or optimized.\n\n\n\n\nThe \nmy_blinky_sim\n target that is included by default has the following settings:\n\n\n$ newt target show\ntargets/my_blinky_sim\n app=apps/blinky\n bsp=@apache-mynewt-core/hw/bsp/native\n build_profile=debug\n$ ls targets/my_blinky_sim/\npkg.yml target.yml\n\n\n\n\n\nThere are helper functions to aid the developer specif
y parameters for a target. \n\n\n\n\nvals\n: Displays all valid values for the specified parameter type (e.g. bsp for a target)\n\n\ntarget show\n: Displays the build artifacts for specified or all targets\n\n\n\n\nIn general, the three basic parameters of a target (\napp\n, \nbsp\n, and \nbuild_profile\n) are stored in the \ntarget.yml\n file in that target's build directory under \ntargets\n. You will also see a \npkg.yml\n file in the same directory. Since targets are packages, a \npkg.yml\n is expected. It contains typical package descriptors, dependencies, and additional parameters such as the following:\n\n\n\n\nCflags: Any additional compiler flags you might want to specify to the build\n\n\nAflags: Any additional assembler flags you might want to specify to the build\n\n\nLflags: Any additional linker flags you might want to specify to the build\n\n\n\n\n\n\nResolving dependencies\n\n\nWhen newt is told to build a project, it will:\n\n\n\n\nfind the top-level project.yml fil
e\n\n\nrecurse the packages in the package tree, and build a list of all \nsource packages\n\n\n\n\nNewt then looks at the target that the user set, for example, blinky_sim:\n\n\n$ more targets/my_blinky_sim/\npkg.yml target.yml\n$ more targets/my_blinky_sim/target.yml\n### Target: targets/my_blinky_sim\ntarget.app: \napps/blinky\n\ntarget.bsp: \n@apache-mynewt-core/hw/bsp/native\n\ntarget.build_profile: \ndebug\n\n\n\n\n\n\n\n\nThe target specifies two major things:\n\n\n\n\nApplication (target.app): The application to build\n\n\nBoard Support Package (target.bsp): The board support package to build \nalong with that application.\n\n\n\n\nNewt goes and builds the dependency tree specified by all the packages. While building this tree, it does a few other things:\n\n\n\n\nAny package that depends on another package, automatically gets the include directories from the package it includes. Include directories in the\nnewt structure must always be prefixed by the package name. For
example, libs/os has the following include tree and its include directory files contains the package name \"os\" before any header files. This is so in order to avoid any header file conflicts.\n\n\n\n\n$ tree\n.\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 include\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 arch\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m0\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m4\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 sim\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500
os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 endian.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_callout.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_cfg.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_eventq.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_heap.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_malloc.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mbuf.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mempool.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mutex.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sanity.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sched.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sem.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_task.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_test.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_time.h\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 queue.h\n\u251c\u
2500\u2500 pkg.yml\n\u2514\u2500\u2500 src\n \u251c\u2500\u2500 arch\n\nsnip\n\n\n\n\n\n\n\n\n\n\nAPI requirements are validated. Packages can export APIs they \nimplement, (i.e. pkg.api: hw-hal-impl), and other packages can require \nthose APIs (i.e. pkg.req_api: hw-hal-impl).\n\n\n\n\nIn order to properly resolve all dependencies in the build system, Newt recursively processes the package dependencies until there are no new dependencies or features (because features can add dependencies.) And it builds a big list of all the packages that need to be build.\n\n\nNewt then goes through this package list, and builds every package into \nan archive file.\n\n\nNOTE:\n The Newt tool generates compiler dependencies for all of these packages, and only rebuilds the packages whose dependencies have changed. Changes in package \n project dependencies are also taken into account. It is smart, after all!\n\n\nProducing artifacts\n\n\nOnce Newt has built all the archive files, it then links
the archive files together. The linkerscript to use is specified by the board support package (BSP.)\n\n\nNOTE: One common use of the \"features\" option above is to overwrite \nwhich linkerscript is used, based upon whether or not the BSP is being \nbuild for a raw image, bootable image or bootloader itself.\n\n\nThe newt tool places all of it's artifacts into the bin/ directory at \nthe top-level of the project, prefixed by the target name being built, \nfor example:\n\n\n$ tree -L 4 bin/\nbin/\n\u2514\u2500\u2500 my_blinky_sim\n \u251c\u2500\u2500 apps\n \u2502 \u2514\u2500\u2500 blinky\n \u2502 \u251c\u2500\u2500 blinky.a\n \u2502 \u251c\u2500\u2500 blinky.a.cmd\n \u2502 \u251c\u2500\u2500 blinky.elf\n \u2502 \u251c\u2500\u2500 blinky.elf.cmd\n \u2502 \u251c\u2500\u2500 blinky.elf.dSYM\n \u2502 \u251c\u2500\u2500 blinky.elf.lst\n \u2502 \u251c\u2500\u2500 main.d\n \u2502 \u251c\u2500\u250
0 main.o\n \u2502 \u2514\u2500\u2500 main.o.cmd\n \u251c\u2500\u2500 hw\n \u2502 \u251c\u2500\u2500 bsp\n \u2502 \u2502 \u2514\u2500\u2500 native\n \u2502 \u251c\u2500\u2500 hal\n \u2502 \u2502 \u251c\u2500\u2500 flash_map.d\n \u2502 \u2502 \u251c\u2500\u2500 flash_map.o\n\nsnip\n\n\n\n\n\n\n\n\nAs you can see, a number of files are generated:\n\n\n\n\nArchive File\n\n\n*.cmd: The command use to generate the object or archive file\n\n\n*.lst: The list file where symbols are located\n\n\n*.o The object files that get put into the archive file\n\n\n\n\nDownload/Debug Support\n\n\nOnce a target has been build, there are a number of helper functions \nthat work on the target. These are:\n\n\n\n\nload\n Download built target to board\n\n\ndebug\n Open debugger session to target\n\n\nsize\n Size of target components\n\n\ncreate-image\n Add image header to target binary\n\n\nrun\n The equivalent of build, create-image,
load, and debug on specified target\n\n\n\n\nload\n and \ndebug\n handles driving GDB and the system debugger. These \ncommands call out to scripts that are defined by the BSP.\n\n\n$ more repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_debug.sh\n\nsnip\n\n. $CORE_PATH/hw/scripts/jlink.sh\n\nFILE_NAME=$BIN_BASENAME.elf\n\nif [ $# -gt 2 ]; then\n SPLIT_ELF_NAME=$3.elf\n # TODO -- this magic number 0x42000 is the location of the second image\n # slot. we should either get this from a flash map file or somehow learn\n # this from the image itself\n EXTRA_GDB_CMDS=\nadd-symbol-file $SPLIT_ELF_NAME 0x8000 -readnow\n\nfi\n\nJLINK_DEV=\nnRF52\n\n\njlink_debug\n\n\n\n\n\nThe idea is that every BSP will add support for the debugger environment \nfor that board. That way common tools can be used across various development boards and kits.",
"title": "Newt Theory of Ops"
},
{
@@ -9942,17 +9997,17 @@
},
{
"location": "/newt/newt_operation/#apps-package-directory",
- "text": "apps is where applications are stored, and applications are where the main() function is contained. Along with the targets directory, apps represents the top-level of the build tree, and define the dependencies and features for the rest of the system. The app definition is contained in a pkg.yml file. An example of blinky's pkg.yml file is: $ more apps/blinky/pkg.yml snip \npkg.name: apps/blinky\npkg.vers: 0.8.0\npkg.description: Basic example application which blinks an LED.\npkg.author: Apache Mynewt dev@mynewt.incubator.apache.org \npkg.homepage: http://mynewt.apache.org/ \npkg.repository:\npkg.keywords:\n\npkg.deps:\n - @apache-mynewt-core/libs/os \n - @apache-mynewt-core/hw/hal \n - @apache-mynewt-core/libs/console/full This file says that the name of the package is apps/blinky, and it \ndepends on libs/os, hw/hal and libs/console/full packages. NOTE: @apache-mynewt-core is a repository descriptor, and this will be \ncover
ed in the \"repository\" section.",
+ "text": "apps is where applications are stored, and applications are where the main() function is contained. The base project directory comes with one simple app called blinky in the apps directory. The core repository @apache-mynewt-core comes with many additional sample apps in its apps directory. At the time of this writing, there are several example BLE apps, the boot app, slinky app for using newt manager protocol, and more in that directory. @~/dev/myproj$ ls repos/apache-mynewt-core/apps/\nblecent bleprph_oic bleuart ffs2native slinky_oic test\nblehci bletest boot ocf_sample spitest timtest\nbleprph bletiny fat2native slinky splitty Along with the targets directory, apps represents the top-level of the build tree for the particular project, and define the dependencies and features for the rest of the system. Mynewt users and developers can add their own apps to the project's apps directory. The app
definition is contained in a pkg.yml file. For example, blinky's pkg.yml file is: $ more apps/blinky/pkg.yml snip \npkg.name: apps/blinky\npkg.type: app\npkg.description: Basic example application which blinks an LED.\npkg.author: Apache Mynewt dev@mynewt.incubator.apache.org \npkg.homepage: http://mynewt.apache.org/ \npkg.keywords:\n\npkg.deps:\n - @apache-mynewt-core/kernel/os \n - @apache-mynewt-core/hw/hal \n - @apache-mynewt-core/sys/console/full This file says that the name of the package is apps/blinky, and it \ndepends on kernel/os, hw/hal and sys/console/full packages. NOTE: @apache-mynewt-core is a repository descriptor, and this will be \ncovered in the \"repository\" section.",
"title": "\"apps\" Package Directory"
},
{
"location": "/newt/newt_operation/#targets-package-directory",
- "text": "targets is where targets are stored, and each target is a collection of parameters that must be passed to Newt in order to generate a reproducible build. Along with the apps directory, targets represents the top of the build tree. Any packages or parameters specified at the target level cascades down to all dependencies. Most targets consist of: app: The application to build bsp: The board support package to combine with that application build_profile: Either debug or optimized. The my_blinky_sim target in the example below has the following settings: $ newt target show\ntargets/my_blinky_sim\n app=apps/blinky\n bsp=@apache-mynewt-core/hw/bsp/native\n build_profile=debug\n$ ls my_blinky_sim/\npkg.yml target.yml In general, the three basic parameters of a target ( app , bsp , and build_profile ) are stored in the target.yml file in that target's build directory under targets . You will also see a pkg.yml file in the same direct
ory. Since targets are packages, a pkg.yml is expected. It contains typical package descriptors, dependencies, and additional parameters such as the following: Cflags: Any additional compiler flags you might want to specify to the build Aflags: Any additional assembler flags you might want to specify to the build Lflags: Any additional linker flags you might want to specify to the build features: Any system level features you want to enable.",
+ "text": "targets is where targets are stored, and each target is a collection of parameters that must be passed to Newt in order to generate a reproducible build. Along with the apps directory, targets represents the top of the build tree. Any packages or parameters specified at the target level cascades down to all dependencies. Most targets consist of: app: The application to build bsp: The board support package to combine with that application build_profile: Either debug or optimized. The my_blinky_sim target that is included by default has the following settings: $ newt target show\ntargets/my_blinky_sim\n app=apps/blinky\n bsp=@apache-mynewt-core/hw/bsp/native\n build_profile=debug\n$ ls targets/my_blinky_sim/\npkg.yml target.yml There are helper functions to aid the developer specify parameters for a target. vals : Displays all valid values for the specified parameter type (e.g. bsp for a target) target show : Displays the build art
ifacts for specified or all targets In general, the three basic parameters of a target ( app , bsp , and build_profile ) are stored in the target.yml file in that target's build directory under targets . You will also see a pkg.yml file in the same directory. Since targets are packages, a pkg.yml is expected. It contains typical package descriptors, dependencies, and additional parameters such as the following: Cflags: Any additional compiler flags you might want to specify to the build Aflags: Any additional assembler flags you might want to specify to the build Lflags: Any additional linker flags you might want to specify to the build",
"title": "\"targets\" Package Directory"
},
{
"location": "/newt/newt_operation/#resolving-dependencies",
- "text": "When newt is told to build a project, it will: find the top-level project.yml file recurse the packages in the package tree, and build a list of all \nsource packages Newt then looks at the target that the user set, for example, blinky_sim: $ more targets/my_blinky_sim/\npkg.yml target.yml\n$ more targets/my_blinky_sim/target.yml\n### Target: targets/my_blinky_sim\ntarget.app: apps/blinky \ntarget.bsp: @apache-mynewt-core/hw/bsp/native \ntarget.build_profile: debug The target specifies two major things: Application (target.app): The application to build Board Support Package (target.bsp): The board support package to build \nalong with that application. Newt goes and builds the dependency tree specified by all the packages. While building this tree, it does a few other things: Any package that depends on another package, automatically gets the include directories from the package it includes. Include directories in the\nnewt structure mus
t always be prefixed by the package name. For example, libs/os has the following include tree and its include directory files contains the package name \"os\" before any header files. This is so in order to avoid any header file conflicts. $ tree\n.\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 include\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 arch\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m0\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m4\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 sim\n\u2502\u00a0\u00a0 \u25
02\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 endian.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_callout.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_cfg.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_eventq.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_heap.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_malloc.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mbuf.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mempool.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mutex.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sanity.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sched.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sem.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_task.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_test.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_time.h\n\u2502\u00a0\u00a0
\u2514\u2500\u2500 queue.h\n\u251c\u2500\u2500 pkg.yml\n\u2514\u2500\u2500 src\n \u251c\u2500\u2500 arch snip API requirements are validated. Packages can export APIs they \nimplement, (i.e. pkg.api: hw-hal-impl), and other packages can require \nthose APIs (i.e. pkg.req_api: hw-hal-impl). \"Features\" options are supported. Packages can change what dependencies \nthey have, or what flags they are using based upon what features are enabled in the system. As an example, many packages will add additional software, based on whether the shell package is present. To do this, they can overwrite cflags or deps based upon the shell \"feature.\" pkg.cflags.SHELL: -DSHELL_PRESENT In order to properly resolve all dependencies in the build system, Newt recursively processes the package dependencies until there are no new dependencies or features (because features can add dependencies.) And it builds a big list of all the packages that need to be build. Newt then goes thr
ough this package list, and builds every package into \nan archive file. NOTE: The Newt tool generates compiler dependencies for all of these packages, and only rebuilds the packages whose dependencies have changed. Changes in package project dependencies are also taken into account. It is smart, after all!",
+ "text": "When newt is told to build a project, it will: find the top-level project.yml file recurse the packages in the package tree, and build a list of all \nsource packages Newt then looks at the target that the user set, for example, blinky_sim: $ more targets/my_blinky_sim/\npkg.yml target.yml\n$ more targets/my_blinky_sim/target.yml\n### Target: targets/my_blinky_sim\ntarget.app: apps/blinky \ntarget.bsp: @apache-mynewt-core/hw/bsp/native \ntarget.build_profile: debug The target specifies two major things: Application (target.app): The application to build Board Support Package (target.bsp): The board support package to build \nalong with that application. Newt goes and builds the dependency tree specified by all the packages. While building this tree, it does a few other things: Any package that depends on another package, automatically gets the include directories from the package it includes. Include directories in the\nnewt structure mus
t always be prefixed by the package name. For example, libs/os has the following include tree and its include directory files contains the package name \"os\" before any header files. This is so in order to avoid any header file conflicts. $ tree\n.\n\u251c\u2500\u2500 README.md\n\u251c\u2500\u2500 include\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 arch\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m0\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u251c\u2500\u2500 cortex_m4\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 sim\n\u2502\u00a0\u00a0 \u25
02\u00a0\u00a0 \u2514\u2500\u2500 os\n\u2502\u00a0\u00a0 \u2502\u00a0\u00a0 \u2514\u2500\u2500 os_arch.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 endian.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_callout.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_cfg.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_eventq.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_heap.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_malloc.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mbuf.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mempool.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_mutex.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sanity.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sched.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_sem.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_task.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_test.h\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 os_time.h\n\u2502\u00a0\u00a0
\u2514\u2500\u2500 queue.h\n\u251c\u2500\u2500 pkg.yml\n\u2514\u2500\u2500 src\n \u251c\u2500\u2500 arch snip API requirements are validated. Packages can export APIs they \nimplement, (i.e. pkg.api: hw-hal-impl), and other packages can require \nthose APIs (i.e. pkg.req_api: hw-hal-impl). In order to properly resolve all dependencies in the build system, Newt recursively processes the package dependencies until there are no new dependencies or features (because features can add dependencies.) And it builds a big list of all the packages that need to be build. Newt then goes through this package list, and builds every package into \nan archive file. NOTE: The Newt tool generates compiler dependencies for all of these packages, and only rebuilds the packages whose dependencies have changed. Changes in package project dependencies are also taken into account. It is smart, after all!",
"title": "Resolving dependencies"
},
{
@@ -9962,7 +10017,7 @@
},
{
"location": "/newt/newt_operation/#downloaddebug-support",
- "text": "Once a target has been build, there are a number of helper functions \nthat work on the target. These are: download Download built target to board debug Open debugger session to target size Size of target components create-image Add image header to target binary Download and debug handles driving GDB and the system debugger. These \ncommands call out to scripts that are defined by the BSP. $ more repos/apache-mynewt-core/hw/bsp/nrf52pdk/nrf52pdk_debug.sh snip \n#\nif [ $# -lt 1 ]; then\n echo Need binary to download \n exit 1\nfi\n\nFILE_NAME=$2.elf\nGDB_CMD_FILE=.gdb_cmds\n\necho Debugging $FILE_NAME\n\n# Monitor mode. Background process gets it s own process group.\nset -m\nJLinkGDBServer -device nRF52 -speed 4000 -if SWD -port 3333 -singlerun \nset +m\n\necho target remote localhost:3333 $GDB_CMD_FILE\n\narm-none-eabi-gdb -x $GDB_CMD_FILE $FILE_NAME\n\nrm $GDB_CMD_FILE The idea is that every BSP will add support
for the debugger environment \nfor that board. That way common tools can be used across various development boards and kits. NOTE: Both for compiler definitions and debugger scripts, the plan is to \ncreate Dockerizable containers of these toolchains. This should make \nthings much easier to support across Mac OS X, Linux and Windows. Newt \nwill know how to call out to Docker to perform these processes.",
+ "text": "Once a target has been build, there are a number of helper functions \nthat work on the target. These are: load Download built target to board debug Open debugger session to target size Size of target components create-image Add image header to target binary run The equivalent of build, create-image, load, and debug on specified target load and debug handles driving GDB and the system debugger. These \ncommands call out to scripts that are defined by the BSP. $ more repos/apache-mynewt-core/hw/bsp/nrf52dk/nrf52dk_debug.sh snip \n. $CORE_PATH/hw/scripts/jlink.sh\n\nFILE_NAME=$BIN_BASENAME.elf\n\nif [ $# -gt 2 ]; then\n SPLIT_ELF_NAME=$3.elf\n # TODO -- this magic number 0x42000 is the location of the second image\n # slot. we should either get this from a flash map file or somehow learn\n # this from the image itself\n EXTRA_GDB_CMDS= add-symbol-file $SPLIT_ELF_NAME 0x8000 -readnow \nfi\n\nJLINK_DEV= nRF52 \n
\njlink_debug The idea is that every BSP will add support for the debugger environment \nfor that board. That way common tools can be used across various development boards and kits.",
"title": "Download/Debug Support"
},
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8da4f0a3/latest/network/ble/ble_hs/ble_att/ble_att/index.html
----------------------------------------------------------------------
diff --git a/latest/network/ble/ble_hs/ble_att/ble_att/index.html b/latest/network/ble/ble_hs/ble_att/ble_att/index.html
index 6c885d0..8b6172f 100644
--- a/latest/network/ble/ble_hs/ble_att/ble_att/index.html
+++ b/latest/network/ble/ble_hs/ble_att/ble_att/index.html
@@ -46,11 +46,17 @@
<div class="container">
<div class="row v2-main-banner">
- <div class="col-xs-12 v2-vcenter">
- <a href="/"><img class="logo" src="/img/logo.png"></a>
-
+ <a class="logo-cell" href="/">
+ <img class="logo" src="/img/logo.png">
+ </a>
+ <div class="tagline-cell">
<h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
</div>
+ <div class="news-cell">
+ <div class="well">
+ <h4>Latest News:</h4> <a href="/download">Apache Mynewt 1.0.0-b1</a> released (Dec 13, 2016)
+ </div>
+ </div>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8da4f0a3/latest/network/ble/ble_hs/ble_att/functions/ble_att_mtu/index.html
----------------------------------------------------------------------
diff --git a/latest/network/ble/ble_hs/ble_att/functions/ble_att_mtu/index.html b/latest/network/ble/ble_hs/ble_att/functions/ble_att_mtu/index.html
index dcbbbf1..ea64569 100644
--- a/latest/network/ble/ble_hs/ble_att/functions/ble_att_mtu/index.html
+++ b/latest/network/ble/ble_hs/ble_att/functions/ble_att_mtu/index.html
@@ -46,11 +46,17 @@
<div class="container">
<div class="row v2-main-banner">
- <div class="col-xs-12 v2-vcenter">
- <a href="/"><img class="logo" src="/img/logo.png"></a>
-
+ <a class="logo-cell" href="/">
+ <img class="logo" src="/img/logo.png">
+ </a>
+ <div class="tagline-cell">
<h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
</div>
+ <div class="news-cell">
+ <div class="well">
+ <h4>Latest News:</h4> <a href="/download">Apache Mynewt 1.0.0-b1</a> released (Dec 13, 2016)
+ </div>
+ </div>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8da4f0a3/latest/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu/index.html
----------------------------------------------------------------------
diff --git a/latest/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu/index.html b/latest/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu/index.html
index d0eab5b..c4e42b5 100644
--- a/latest/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu/index.html
+++ b/latest/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu/index.html
@@ -46,11 +46,17 @@
<div class="container">
<div class="row v2-main-banner">
- <div class="col-xs-12 v2-vcenter">
- <a href="/"><img class="logo" src="/img/logo.png"></a>
-
+ <a class="logo-cell" href="/">
+ <img class="logo" src="/img/logo.png">
+ </a>
+ <div class="tagline-cell">
<h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
</div>
+ <div class="news-cell">
+ <div class="well">
+ <h4>Latest News:</h4> <a href="/download">Apache Mynewt 1.0.0-b1</a> released (Dec 13, 2016)
+ </div>
+ </div>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8da4f0a3/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local/index.html
----------------------------------------------------------------------
diff --git a/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local/index.html b/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local/index.html
index ab70d52..463fc36 100644
--- a/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local/index.html
+++ b/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local/index.html
@@ -46,11 +46,17 @@
<div class="container">
<div class="row v2-main-banner">
- <div class="col-xs-12 v2-vcenter">
- <a href="/"><img class="logo" src="/img/logo.png"></a>
-
+ <a class="logo-cell" href="/">
+ <img class="logo" src="/img/logo.png">
+ </a>
+ <div class="tagline-cell">
<h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
</div>
+ <div class="news-cell">
+ <div class="well">
+ <h4>Latest News:</h4> <a href="/download">Apache Mynewt 1.0.0-b1</a> released (Dec 13, 2016)
+ </div>
+ </div>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8da4f0a3/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local/index.html
----------------------------------------------------------------------
diff --git a/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local/index.html b/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local/index.html
index 1bb5920..3169cfa 100644
--- a/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local/index.html
+++ b/latest/network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local/index.html
@@ -46,11 +46,17 @@
<div class="container">
<div class="row v2-main-banner">
- <div class="col-xs-12 v2-vcenter">
- <a href="/"><img class="logo" src="/img/logo.png"></a>
-
+ <a class="logo-cell" href="/">
+ <img class="logo" src="/img/logo.png">
+ </a>
+ <div class="tagline-cell">
<h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
</div>
+ <div class="news-cell">
+ <div class="well">
+ <h4>Latest News:</h4> <a href="/download">Apache Mynewt 1.0.0-b1</a> released (Dec 13, 2016)
+ </div>
+ </div>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8da4f0a3/latest/network/ble/ble_hs/ble_gap/ble_gap/index.html
----------------------------------------------------------------------
diff --git a/latest/network/ble/ble_hs/ble_gap/ble_gap/index.html b/latest/network/ble/ble_hs/ble_gap/ble_gap/index.html
index 18cd771..366f41b 100644
--- a/latest/network/ble/ble_hs/ble_gap/ble_gap/index.html
+++ b/latest/network/ble/ble_hs/ble_gap/ble_gap/index.html
@@ -46,11 +46,17 @@
<div class="container">
<div class="row v2-main-banner">
- <div class="col-xs-12 v2-vcenter">
- <a href="/"><img class="logo" src="/img/logo.png"></a>
-
+ <a class="logo-cell" href="/">
+ <img class="logo" src="/img/logo.png">
+ </a>
+ <div class="tagline-cell">
<h4 class="tagline">An OS to build, deploy and securely manage billions of devices</h4>
</div>
+ <div class="news-cell">
+ <div class="well">
+ <h4>Latest News:</h4> <a href="/download">Apache Mynewt 1.0.0-b1</a> released (Dec 13, 2016)
+ </div>
+ </div>
</div>
</div>