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:24:39 UTC
[3/3] 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.
Broke NimBLE tutorial into multiple sections. Added Newt tutorial and theory of ops. Rearranged tutorials for better flow. This is work in progress.
Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/commit/39bcbce3
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/39bcbce3
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/39bcbce3
Branch: refs/heads/master
Commit: 39bcbce3fc096bbae317da1e466dfc8881e9c4a2
Parents: 362391b
Author: aditihilbert <ad...@runtime.io>
Authored: Wed Mar 23 11:24:22 2016 -0700
Committer: aditihilbert <ad...@runtime.io>
Committed: Wed Mar 23 11:24:22 2016 -0700
----------------------------------------------------------------------
custom-theme/landing.html | 4 +-
docs/network/ble/ini_stack/ble_add_cpu.md | 41 ++
docs/network/ble/ini_stack/ble_consolepkg.md | 56 ++
.../network/ble/ini_stack/ble_controller_ini.md | 93 ++++
docs/network/ble/ini_stack/ble_devadd.md | 55 ++
docs/network/ble/ini_stack/ble_host_ini.md | 92 ++++
docs/network/ble/ini_stack/ble_ini_intro.md | 28 +
docs/network/ble/ini_stack/ble_mempool.md | 54 ++
docs/network/ble/ini_stack/ble_statpkg.md | 53 ++
docs/network/ble/nimble_setup.md | 539 ++++++++++++++++++
docs/newt/newt_intro.md | 198 ++++++-
docs/newt/newt_operation.md | 290 ++++++++++
docs/newt/tutorials/define_target.md | 3 -
docs/os/tutorials/add_repos.md | 59 +-
docs/os/tutorials/bletiny_project.md | 5 +
docs/os/tutorials/create_repo.md | 172 ++++++
docs/os/tutorials/define_target.md | 3 +
docs/os/tutorials/nimble_setup.md | 543 -------------------
docs/os/tutorials/nimble_setup_copy.md | 543 +++++++++++++++++++
docs/os/tutorials/upgrade_repo.md | 14 +
mkdocs.yml | 36 +-
21 files changed, 2286 insertions(+), 595 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/custom-theme/landing.html
----------------------------------------------------------------------
diff --git a/custom-theme/landing.html b/custom-theme/landing.html
index af8025c..a774b73 100644
--- a/custom-theme/landing.html
+++ b/custom-theme/landing.html
@@ -37,14 +37,14 @@
<span class="helper"></span>
<img src="/img/folder.png">
</div>
- <p>Produce a foundational RTOS and embedded middleware utilities such as boot loaders, file systems, and time-series data support</p>
+ <p>Produce a foundational RTOS with utilities such as boot loaders, file systems, and time-series data support</p>
</div>
<div class="column col-md-6 goal text-center">
<div class="goal-image">
<span class="helper"></span>
<img src="/img/watch.png">
</div>
- <p>Build solid networking stack support for secure, efficient communications with constrained devices</p>
+ <p>Build networking stacks for secure, efficient communications with constrained devices, starting with Bluetooth Low Energy 4.2</p>
</div>
</div>
<div class="row">
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/ini_stack/ble_add_cpu.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_add_cpu.md b/docs/network/ble/ini_stack/ble_add_cpu.md
new file mode 100644
index 0000000..47b55bb
--- /dev/null
+++ b/docs/network/ble/ini_stack/ble_add_cpu.md
@@ -0,0 +1,41 @@
+## Add cputime
+
+The NimBLE stack requires "cputime". This is provided by the Mynewt HAL of the
+same name. The cputime HAL provides a high resolution timer that is used by the
+nimble stack (as the BLE specification requires a fairly high resolution timer
+and has fairly tight timing requirements). The cputime HAL allows the user to
+specify the timer resolution as different applications may require a different
+resolution. While the Nimble stack does not require a specific timer resolution
+per se, a resolution that is too large may affect performance and power
+efficiency. A suggested clock rate for HAL cputime for the nimble stack is 1
+MHz, or 1 microsecond per cputime tick. This provides enough resolution for
+most needs while providing the Nimble stack enough resolution to implement the
+BLE specification.
+
+Add the initialization of cputime to your application:
+
+```c hl_lines="1 11 12 13"
+#include "hal/hal_cputime.h"
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/ini_stack/ble_consolepkg.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_consolepkg.md b/docs/network/ble/ini_stack/ble_consolepkg.md
new file mode 100644
index 0000000..813678f
--- /dev/null
+++ b/docs/network/ble/ini_stack/ble_consolepkg.md
@@ -0,0 +1,56 @@
+## Initializing the console package
+The console is also required by the Nimble stack. The console is currently used for log output so it needs to be initialized. For this example, we are not going to use a console receive callback. All this means is that input from the console will not be accepted by default; the developer will have to install their own handler or use one provided by another package (the shell, for example). Just like statistics, the console is initialized by calling the console initialization function `console_init()`.
+
+```c hl_lines="1 39 40 41"
+#include "console/console.h"
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Initialize the statistics package */
+ rc = stats_module_init();
+ assert(rc == 0);
+
+ /* Init the console */
+ rc = console_init(NULL);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/ini_stack/ble_controller_ini.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_controller_ini.md b/docs/network/ble/ini_stack/ble_controller_ini.md
new file mode 100644
index 0000000..eddaee1
--- /dev/null
+++ b/docs/network/ble/ini_stack/ble_controller_ini.md
@@ -0,0 +1,93 @@
+
+## Initialize the NimBLE controller
+
+The NimBLE controller is initialized via a call to `ble_ll_init()`. This function is declared as follows:
+
+```c
+int ble_ll_init(uint8_t ll_task_prio, uint8_t num_acl_pkts, uint16_t acl_pkt_size)
+```
+
+This function's parameters are documented below.
+
+| **Parameter** | **Description** |
+| ------------- | --------------- |
+| *prio* | The priority of the NimBLE controller task. A lower number corresponds to higher priority. |
+| *num_acl_pkts* | The maximum number of outstanding data packets that the controller will accept from the host. |
+| *acl_pkt_size* | The maximum data packet size that the controller will accept from the host. |
+
+**prio**:
+
+If you are not familiar with multitasking, preemptive operating systems we
+highly encourage you to read the Core OS section of Mynewt OS manual. It is up
+to the application developer to decide the priority of tasks in the system.
+Note that the lower the priority number the higher the priority in the OS. For
+example, if a task is running at priority 5 and a task at priority 3 wants to
+run, the task at priority 5 gets preempted as the other task is a higher
+proiority.
+
+In the example shown below, the LL task is configured to have the highest
+priority (priority 0). We recommend making the BLE LL task the highest priority
+task in your application as it has fairly rigorous timing requirements and
+allowing other tasks to preempt the LL task could cause undesirable behavior.
+Note that we do not force this to be the case as an application may require a
+task to be even higher priority than the LL task. Just be warned: a task
+higher in priority than the LL task should not perform actions that take too
+long; even a few milliseconds could cause undesirable behavior.
+
+**num_acl_pkts** and **acl_pkt_size**:
+
+These two parameters are used to limit the amount of data the host tries to send through the controller. NimBLE uses the msys facility for allocating data packets, so the product of these arguments must not be larger than the total amount of memory allocated for msys. The below example uses some values that are reasonable for most uses.
+
+```c hl_lines="1 40 41 42"
+#include "controller/ble_ll.h"
+
+int
+main(void)
+{
+ int rc;
+ struct ble_hs_cfg cfg;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for NimBLE packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Initialize the statistics package */
+ rc = stats_module_init();
+ assert(rc == 0);
+
+ /* Initialize the BLE LL */
+ rc = ble_ll_init(0, 7, 260);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/ini_stack/ble_devadd.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_devadd.md b/docs/network/ble/ini_stack/ble_devadd.md
new file mode 100644
index 0000000..0e97595
--- /dev/null
+++ b/docs/network/ble/ini_stack/ble_devadd.md
@@ -0,0 +1,55 @@
+## Initialize the Device Address
+
+The 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.
+
+The two variables that must be defined are named `g_dev_addr` (public device address) and `g_random_addr` (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 company 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.
+
+```c hl_lines="1 2 3 4 5 31 32 33 34 35 36 37"
+/* Our global device address (public) */
+uint8_t g_dev_addr[BLE_DEV_ADDR_LEN];
+
+/* Our random address (static) */
+uint8_t g_random_addr[BLE_DEV_ADDR_LEN];
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/ini_stack/ble_host_ini.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_host_ini.md b/docs/network/ble/ini_stack/ble_host_ini.md
new file mode 100644
index 0000000..cfad56f
--- /dev/null
+++ b/docs/network/ble/ini_stack/ble_host_ini.md
@@ -0,0 +1,92 @@
+## Initialize the NimBLE host
+
+The Nimble host is initialized via a call to `ble_hs_init()`. This function is declared as follows:
+
+```c
+int ble_hs_init(uint8_t prio, struct ble_hs_cfg *cfg)
+```
+
+The parameters are documented below.
+
+| **Parameter** | **Description** |
+| ------------- | --------------- |
+| *prio* | The priority of the Nimble host task. A lower number corresponds to higher priority. |
+| *cfg* | A pointer to the desired host configuration, or *NULL* if you want to use the default settings. |
+
+**prio**:
+
+Unlike the controller, the host does not have any strict timing requirements.
+This number should be greater than the priority of any time-critical tasks in
+your application (remember, bigger number = lower priority!). There are no
+restrictions with regards to the host task's priority relative to its client
+tasks. In the below example, the host is assigned a priority of 1.
+
+
+**cfg**:
+
+As mentioned above, passing a *cfg* value of *NULL* will initialize the Nimble
+host with the default configuration. This is convenient while familiarizing
+yourself with the Nimble stack, but ultimately you will probably want to use a
+custom configuration. For more information on configuring the host, see the
+Nimble Configuration Guide (TBD).
+
+Continuing with our running example, we now add Nimble host initialization to the *main()* function. This application uses the default host configuration, so it specifies *NULL* as the second argument to `ble_hs_init()`.
+
+```c hl_lines="1 44 45 46"
+#include "host/ble_hs.h"
+
+int
+main(void)
+{
+ int rc;
+ struct ble_hs_cfg cfg;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Initialize the statistics package */
+ rc = stats_module_init();
+ assert(rc == 0);
+
+ /* Initialize the BLE LL */
+ rc = ble_ll_init(0, 7, 260);
+ assert(rc == 0);
+
+ /* Initialize the BLE host. */
+ rc = ble_hs_init(BLE_HS_TASK_PRI, NULL);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/ini_stack/ble_ini_intro.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_ini_intro.md b/docs/network/ble/ini_stack/ble_ini_intro.md
new file mode 100644
index 0000000..ee7b4f9
--- /dev/null
+++ b/docs/network/ble/ini_stack/ble_ini_intro.md
@@ -0,0 +1,28 @@
+## Nimble stack initialization
+
+We 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.
+
+A note about the code samples: the main() function in each code 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.
+
+Let'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.
+
+```c
+#include "os/os.h"
+
+int
+main(void)
+{
+ /* Initialize OS */
+ os_init();
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+The 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.
+
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/ini_stack/ble_mempool.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_mempool.md b/docs/network/ble/ini_stack/ble_mempool.md
new file mode 100644
index 0000000..ea96e09
--- /dev/null
+++ b/docs/network/ble/ini_stack/ble_mempool.md
@@ -0,0 +1,54 @@
+## Create the System Memory Buffer Pool
+
+The 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.
+
+Creating 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 should be included in main.c, contains some MBUF macros that you will need to create the memory pool used by msys. The macro `BLE_MBUF_PAYLOAD_SIZE` defines the maximum amount of user payload, plus overhead, that a link layer BLE PDU can contain. The macro `BLE_MBUF_MEMBLOCK_OVERHEAD` is the amount of overhead required by the Nimble stack in each memory block used by the mbuf pool. The macro `MBUF_NUM_MBUFS` 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).
+
+A note about the size of the mbufs and `BLE_MBUF_PAYLOAD_SIZE`. 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 `BLE_MBUF_PAYLOAD_SIZE`. 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.
+
+```c hl_lines="1 2 3 4 5 6 7 8 9 23 24 25 26 27 28 29 30 31 32 33"
+
+/* Create a mbuf pool of BLE mbufs */
+#define MBUF_NUM_MBUFS (8)
+#define MBUF_BUF_SIZE OS_ALIGN(BLE_MBUF_PAYLOAD_SIZE, 4)
+#define MBUF_MEMBLOCK_SIZE (MBUF_BUF_SIZE + BLE_MBUF_MEMBLOCK_OVERHEAD)
+#define MBUF_MEMPOOL_SIZE OS_MEMPOOL_SIZE(MBUF_NUM_MBUFS, MBUF_MEMBLOCK_SIZE)
+
+struct os_mbuf_pool g_mbuf_pool;
+struct os_mempool g_mbuf_mempool;
+os_membuf_t g_mbuf_buffer[MBUF_MEMPOOL_SIZE];
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/ini_stack/ble_statpkg.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_statpkg.md b/docs/network/ble/ini_stack/ble_statpkg.md
new file mode 100644
index 0000000..f60cb13
--- /dev/null
+++ b/docs/network/ble/ini_stack/ble_statpkg.md
@@ -0,0 +1,53 @@
+## Initialize the statistics package
+
+The 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 function `stats_module_init()`.
+
+```c hl_lines="1 35 36 37"
+#include "stats/stats.h"
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Initialize the statistics package */
+ rc = stats_module_init();
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/network/ble/nimble_setup.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/nimble_setup.md b/docs/network/ble/nimble_setup.md
new file mode 100644
index 0000000..7ab8d7b
--- /dev/null
+++ b/docs/network/ble/nimble_setup.md
@@ -0,0 +1,539 @@
+## Set up a NimBLE application
+
+This 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.
+
+This tutorial assumes that you have already installed a source tree and are familiar with the newt tools and concepts.
+
+
+### Create the application directory
+<This needs to be added. This should talk about how you create the pkg.yml file in the apps directory that the user will create. Also, discuss other application dir stuff>
+
+### Create the target
+
+The 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 `newt target create ble_tgt` command. You should get this:
+
+```no-highlight
+$ newt target create ble_tgt
+Target targets/ble_tgt successfully created
+```
+
+What this command just did was to create a directory called `ble_tgt` in the targets directory of your project. Two files are created in that directory: pkg.yml and target.yml.
+
+The 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.
+
+Here is the command you will need to setup your target for the nrf52:
+
+```no-highlight
+$ newt target set ble_tgt app=apps/ble_app \
+ bsp=hw/bsp/nrf52pdk \
+ build_profile=optimized
+Target targets/ble_tgt successfully set target.app to apps/ble_app
+Target targets/ble_tgt successfully set target.bsp to hw/bsp/nrf52pdk
+Target targets/ble_tgt successfully set target.build_profile to optimized
+```
+
+Here is the command you will need to setup your target for the nrf51:
+
+```no-highlight
+$ newt target set ble_tgt app=apps/ble_app \
+ bsp=hw/bsp/nrf51dk \
+ build_profile=optimized
+Target targets/ble_tgt successfully set target.app to apps/ble_app
+Target targets/ble_tgt successfully set target.bsp to hw/bsp/nrf51dk
+Target targets/ble_tgt successfully set target.build_profile to optimized
+```
+
+<br>
+
+
+### Nimble stack initialization
+
+We 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.
+
+A note about the code samples: the main() function in each code 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.
+
+Let'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.
+
+```c
+#include "os/os.h"
+
+int
+main(void)
+{
+ /* Initialize OS */
+ os_init();
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+The 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.
+
+<br>
+
+#### Add cputime
+
+The Nimble stack requires "cputime". This is provided by the Mynewt HAL of the
+same name. The cputime HAL provides a high resolution timer that is used by the
+nimble stack (as the BLE specification requires a fairly high resolution timer
+and has fairly tight timing requirements). The cputime HAL allows the user to
+specify the timer resolution as different applications may require a different
+resolution. While the Nimble stack does not require a specific timer resolution
+per se, a resolution that is too large may affect performance and power
+efficiency. A suggested clock rate for HAL cputime for the nimble stack is 1
+MHz, or 1 microsecond per cputime tick. This provides enough resolution for
+most needs while providing the Nimble stack enough resolution to implement the
+BLE specification.
+
+Add the initialization of cputime to your application:
+
+```c hl_lines="1 11 12 13"
+#include "hal/hal_cputime.h"
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
+#### Create the system memory buffer pool
+The 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.
+
+Creating 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 should be included in main.c, contains some MBUF macros that you will need to create the memory pool used by msys. The macro `BLE_MBUF_PAYLOAD_SIZE` defines the maximum amount of user payload, plus overhead, that a link layer BLE PDU can contain. The macro `BLE_MBUF_MEMBLOCK_OVERHEAD` is the amount of overhead required by the Nimble stack in each memory block used by the mbuf pool. The macro `MBUF_NUM_MBUFS` 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).
+
+A note about the size of the mbufs and `BLE_MBUF_PAYLOAD_SIZE`. 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 `BLE_MBUF_PAYLOAD_SIZE`. 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.
+
+```c hl_lines="1 2 3 4 5 6 7 8 9 23 24 25 26 27 28 29 30 31 32 33"
+/* Create a mbuf pool of BLE mbufs */
+#define MBUF_NUM_MBUFS (8)
+#define MBUF_BUF_SIZE OS_ALIGN(BLE_MBUF_PAYLOAD_SIZE, 4)
+#define MBUF_MEMBLOCK_SIZE (MBUF_BUF_SIZE + BLE_MBUF_MEMBLOCK_OVERHEAD)
+#define MBUF_MEMPOOL_SIZE OS_MEMPOOL_SIZE(MBUF_NUM_MBUFS, MBUF_MEMBLOCK_SIZE)
+
+struct os_mbuf_pool g_mbuf_pool;
+struct os_mempool g_mbuf_mempool;
+os_membuf_t g_mbuf_buffer[MBUF_MEMPOOL_SIZE];
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
+#### Initializing the device address
+The 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.
+
+The two variables that must be defined are named `g_dev_addr` (public device address) and `g_random_addr` (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 company 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.
+
+```c hl_lines="1 2 3 4 5 31 32 33 34 35 36 37"
+/* Our global device address (public) */
+uint8_t g_dev_addr[BLE_DEV_ADDR_LEN];
+
+/* Our random address (static) */
+uint8_t g_random_addr[BLE_DEV_ADDR_LEN];
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
+#### Initializing the statistics package
+The 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 function `stats_module_init()`.
+
+```c hl_lines="1 35 36 37"
+#include "stats/stats.h"
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Initialize the statistics package */
+ rc = stats_module_init();
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
+#### Initializing the console package
+The console is also required by the Nimble stack. The console is currently used for log output so it needs to be initialized. For this example, we are not going to use a console receive callback. All this means is that input from the console will not be accepted by default; the developer will have to install their own handler or use one provided by another package (the shell, for example). Just like statistics, the console is initialized by calling the console initialization function `console_init()`.
+
+```c hl_lines="1 39 40 41"
+#include "console/console.h"
+
+int
+main(void)
+{
+ int rc;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Initialize the statistics package */
+ rc = stats_module_init();
+ assert(rc == 0);
+
+ /* Init the console */
+ rc = console_init(NULL);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
+#### Initializing the Nimble controller
+The Nimble controller is initialized via a call to `ble_ll_init()`. This function is declared as follows:
+
+```c
+int ble_ll_init(uint8_t ll_task_prio, uint8_t num_acl_pkts, uint16_t acl_pkt_size)
+```
+
+This function's parameters are documented below.
+
+| **Parameter** | **Description** |
+| ------------- | --------------- |
+| *prio* | The priority of the Nimble controller task. A lower number corresponds to higher priority. |
+| *num_acl_pkts* | The maximum number of outstanding data packets that the controller will accept from the host. |
+| *acl_pkt_size* | The maximum data packet size that the controller will accept from the host. |
+
+**prio**:
+
+If you are not familiar with multitasking, preemptive operating systems we
+highly encourage you to read the Core OS section of Mynewt OS manual. It is up
+to the application developer to decide the priority of tasks in the system.
+Note that the lower the priority number the higher the priority in the OS. For
+example, if a task is running at priority 5 and a task at priority 3 wants to
+run, the task at priority 5 gets preempted as the other task is a higher
+proiority.
+
+In the example shown below, the LL task is configured to have the highest
+priority (priority 0). We recommend making the BLE LL task the highest priority
+task in your application as it has fairly rigorous timing requirements and
+allowing other tasks to preempt the LL task could cause undesirable behavior.
+Note that we do not force this to be the case as an application may require a
+task to be even higher priority than the LL task. Just be warned: a task
+higher in priority than the LL task should not perform actions that take too
+long; even a few milliseconds could cause undesirable behavior.
+
+**num_acl_pkts** and **acl_pkt_size**:
+
+These two parameters are used to limit the amount of data the host tries to send through the controller. Nimble uses the msys facility for allocating data packets, so the product of these arguments must not be larger than the total amount of memory allocated for msys. The below example uses some values that are reasonable for most uses.
+
+```c hl_lines="1 40 41 42"
+#include "controller/ble_ll.h"
+
+int
+main(void)
+{
+ int rc;
+ struct ble_hs_cfg cfg;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Initialize the statistics package */
+ rc = stats_module_init();
+ assert(rc == 0);
+
+ /* Initialize the BLE LL */
+ rc = ble_ll_init(0, 7, 260);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+<br>
+
+##### Initializing the Nimble host
+
+The Nimble host is initialized via a call to `ble_hs_init()`. This function is declared as follows:
+
+```c
+int ble_hs_init(uint8_t prio, struct ble_hs_cfg *cfg)
+```
+
+The parameters are documented below.
+
+| **Parameter** | **Description** |
+| ------------- | --------------- |
+| *prio* | The priority of the Nimble host task. A lower number corresponds to higher priority. |
+| *cfg* | A pointer to the desired host configuration, or *NULL* if you want to use the default settings. |
+
+**prio**:
+
+Unlike the controller, the host does not have any strict timing requirements.
+This number should be greater than the priority of any time-critical tasks in
+your application (remember, bigger number = lower priority!). There are no
+restrictions with regards to the host task's priority relative to its client
+tasks. In the below example, the host is assigned a priority of 1.
+
+
+**cfg**:
+
+As mentioned above, passing a *cfg* value of *NULL* will initialize the Nimble
+host with the default configuration. This is convenient while familiarizing
+yourself with the Nimble stack, but ultimately you will probably want to use a
+custom configuration. For more information on configuring the host, see the
+Nimble Configuration Guide (TBD).
+
+Continuing with our running example, we now add Nimble host initialization to the *main()* function. This application uses the default host configuration, so it specifies *NULL* as the second argument to `ble_hs_init()`.
+
+```c hl_lines="1 44 45 46"
+#include "host/ble_hs.h"
+
+int
+main(void)
+{
+ int rc;
+ struct ble_hs_cfg cfg;
+
+ /* Initialize OS */
+ os_init();
+
+ /* Set cputime to count at 1 usec increments */
+ rc = cputime_init(1000000);
+ assert(rc == 0);
+
+ /* Create memory pool for Nimble packets and register with Msys */
+ rc = os_mempool_init(&g_mbuf_mempool, MBUF_NUM_MBUFS,
+ MBUF_MEMBLOCK_SIZE, &g_mbuf_buffer[0], "mbuf_pool");
+ assert(rc == 0);
+
+ rc = os_mbuf_pool_init(&g_mbuf_pool, &g_mbuf_mempool, MBUF_MEMBLOCK_SIZE,
+ MBUF_NUM_MBUFS);
+ assert(rc == 0);
+
+ rc = os_msys_register(&g_mbuf_pool);
+ assert(rc == 0);
+
+ /* Initialize our device address */
+ g_dev_addr[0] = 0x33;
+ g_dev_addr[1] = 0x22;
+ g_dev_addr[2] = 0x11;
+ g_dev_addr[3] = 0xcc;
+ g_dev_addr[4] = 0xbb;
+ g_dev_addr[5] = 0x0a;
+
+ /* Initialize the statistics package */
+ rc = stats_module_init();
+ assert(rc == 0);
+
+ /* Initialize the BLE LL */
+ rc = ble_ll_init(0, 7, 260);
+ assert(rc == 0);
+
+ /* Initialize the BLE host. */
+ rc = ble_hs_init(BLE_HS_TASK_PRI, NULL);
+ assert(rc == 0);
+
+ /* Start the OS */
+ os_start();
+
+ /* os start should never return. If it does, this should be an error */
+ assert(0);
+}
+```
+
+<br>
+
+### Building the application
+Now that we have created the application and the target we can build it and test it out. The command you need to run is the newt build command with the target we created (ble\_tgt). The output will show the files being compiled and linked. You should see this when all is done (except for the ... of course):
+
+```no-highlight
+wes@~/dev/larva$ newt build ble_tgt
+...
+Archiving os.a
+Compiling cons_fmt.c
+Compiling cons_tty.c
+Archiving full.a
+Linking ble_app.elf
+App successfully built: /Users/wes/dev/larva/bin/ble_tgt/apps/ble_app/ble_app.elf
+```
+
+### Conclusion
+
+You now have a fully functional BLE app (never mind the fact that it doesn't
+actually do anything yet!). With all the necessary infrastructure in place,
+you can now start turning this into a real applicaiton. Additional tutorials
+with focus on adding application-layer functionality to your Nimble application
+will be coming soon. In the meantime, you might get some inspiration from
+apache-mynewt-core's example Nimble apps. These apps can be found at the below locations, relative to your project's base directory:
+
+* _repos/apache-mynewt-core/apps/bleprph_
+* _repos/apache-mynewt-core/apps/bletiny_
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/newt/newt_intro.md
----------------------------------------------------------------------
diff --git a/docs/newt/newt_intro.md b/docs/newt/newt_intro.md
index 695977b..89a7922 100644
--- a/docs/newt/newt_intro.md
+++ b/docs/newt/newt_intro.md
@@ -1,3 +1,197 @@
-## Introduction
+## Newt Tool
+
+### Introduction
+
+Newt is a smart build and package management system for embedded contexts. It is a single tool that accomplishes both the following goals:
+
+* source package management
+* build, debug and install.
+
+### Rationale
+
+In order for the Mynewt operating system to work well for constrained environments across the many different types of microcontroller applications (from doorbells to medical devices to power grids), a system is needed that lets you select which packages to install and which packages to build.
+
+The build systems for embedded devices are often fairly complicated and not well served for this purpose. For example, autoconf is designed for detecting system compatibility issues but not well suited when it comes to tasks like:
+
+* Building for multiple targets
+* Deciding what to build in and what not to build in
+* Managing dependencies between components
+
+Fortunately, solutions addressing these very issues can be found in source package management systems in higher level languages such as Javascript
+(Node), Go, PHP and Ruby. We decided to fuse their source management
+systems with a make system built for embedded systems and create Newt.
+
+### Build System
+
+A good build system must allow the user to take a few common steps while developing embedded applications:
+
+* Generate full flash images
+* Download debug images to a target board using a debugger
+* Conditionally compile libraries & code based upon build settings
+
+Newt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:
+
+```hl_lines="7 12"
+$ tree -L 3
+.
+├── DISCLAIMER
+├── LICENSE
+├── NOTICE
+├── README.md
+├── apps
+│ └── blinky
+│ ├── pkg.yml
+│ └── src
+├── project.yml
+└── targets
+ ├── my_blinky_sim
+ │ ├── pkg.yml
+ │ └── target.yml
+ └── unittest
+ ├── pkg.yml
+ └── target.yml
+
+6 directories, 10 files
+```
+
+<br>
+
+When Newt sees a directory tree that contains a "project.yml" file, it is smart enough to recognize it as the base directory of a project, and
+automatically builds a package tree. It also recognizes two important package directories in the package tree - "apps" and "targets". More on these directories in [Newt Theory of Ops](newt_operation.md).
+
+
+When Newt 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 - `my_blinky_sim` for example:
+
+```
+$ tree bin
+bin
+└── my_blinky_sim
+ ├── apps
+ │ └── blinky
+ │ ├── blinky.a
+ │ ├── blinky.a.cmd
+ │ ├── blinky.elf
+ │ ├── blinky.elf.cmd
+ │ ├── blinky.elf.dSYM
+ │ │ └── Contents
+ │ │ ├── Info.plist
+ │ │ └── Resources
+ │ │ └── DWARF
+ │ │ └── blinky.elf
+ │ ├── blinky.elf.lst
+ │ ├── main.d
+ │ ├── main.o
+ │ └── main.o.cmd
+ ├── hw
+ │ ├── bsp
+ │ │ └── native
+ │ │ ├── hal_bsp.d
+ │ │ ├── hal_bsp.o
+ │ │ ├── hal_bsp.o.cmd
+<snip>
+```
+
+<br>
+
+### More operations using Newt
+
+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](newt_operation.md).
+
+<br>
+
+### Source Management and Repositories
+
+The other major element of the Newt tool is the ability to create reusable source distributions from a collection of code. **A project can be a reusable container of source code.** In other words, projects can be versioned and redistributed, not packages. A project bundles together packages that are typically needed to work together in a product e.g. RTOS core, filesystem APIs, and networking stack.
+
+A project that has been made redistributable is known as a **repository**.
+Repositories can be added to your local project by adding them into your project.yml file. Here is an example of the blinky project's yml file which relies on apache-mynewt-core:
+
+```
+$ more project.yml
+<snip>
+project.repositories:
+ - apache-mynewt-core
+
+# Use github's distribution mechanism for core ASF libraries.
+# This provides mirroring automatically for us.
+#
+repository.apache-mynewt-core:
+ type: github
+ vers: 0-latest
+ user: apache
+ repo: incubator-mynewt-core
+```
+
+<br>
+
+When you specify this repository in the blinky's project file, you can then use the Newt tool to install dependencies:
+
+```
+$ newt install
+Downloading repository description for apache-mynewt-core... success!
+Downloading repository incubator-mynewt-core (branch: develop) at
+https://github.com/apache/incubator-mynewt-core.git
+Cloning into
+'/var/folders/7l/7b3w9m4n2mg3sqmgw2q1b9p80000gn/T/newt-repo814721459'...
+remote: Counting objects: 17601, done.
+remote: Compressing objects: 100% (300/300), done.
+remote: Total 17601 (delta 142), reused 0 (delta 0), pack-reused 17284
+Receiving objects: 100% (17601/17601), 6.09 MiB | 3.17 MiB/s, done.
+Resolving deltas: 100% (10347/10347), done.
+Checking connectivity... done.
+Repos successfully installed
+```
+
+<br>
+
+Newt will install this repository in the <project>/repos directory. In the case of blinky, the directory structure ends up looking like:
+
+```
+$ tree -L 2
+.
+├── DISCLAIMER
+├── LICENSE
+├── NOTICE
+├── README.md
+├── apps
+│ └── blinky
+├── project.state
+├── project.yml
+├── repos
+│ └── apache-mynewt-core
+└── targets
+ ├── my_blinky_sim
+ └── unittest
+```
+
+<br>
+
+In order to reference the installed repositories in packages, the "@" notation should be specified in the repository specifier. As an example, the apps/blinky application has the following dependencies in its pkg.yml file. This tells the build system to look in the base directory of repos/apache-mynewt-core for the `libs/os`, `hw/hal`, and `libs/console/full` packages.
+
+```
+$ more apps/blinky/pkg.yml
+<snip>
+pkg.deps:
+ - "@apache-mynewt-core/libs/os"
+ - "@apache-mynewt-core/hw/hal"
+ - "@apache-mynewt-core/libs/console/full"
+```
+
+<br>
+
+
+
+
+
+
+
+
+
-What is newt tool?
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/newt/newt_operation.md
----------------------------------------------------------------------
diff --git a/docs/newt/newt_operation.md b/docs/newt/newt_operation.md
new file mode 100644
index 0000000..2f23310
--- /dev/null
+++ b/docs/newt/newt_operation.md
@@ -0,0 +1,290 @@
+## Newt Tool - Theory of Operations
+
+Newt has a fairly smart package manager that can read a directory tree, build a dependency tree, and emit the right build artifacts.
+
+### Building dependencies
+
+Newt can read a directory tree, build a dependency tree, and emit the right build artifacts. An example newt source tree is in incubator-mynewt-blinky/develop:
+
+```hl_lines="7 12"
+$ tree -L 3
+.
+├── DISCLAIMER
+├── LICENSE
+├── NOTICE
+├── README.md
+├── apps
+│ └── blinky
+│ ├── pkg.yml
+│ └── src
+├── project.yml
+└── targets
+ ├── my_blinky_sim
+ │ ├── pkg.yml
+ │ └── target.yml
+ └── unittest
+ ├── pkg.yml
+ └── target.yml
+
+6 directories, 10 files
+```
+
+<br>
+
+When Newt sees a directory tree that contains a "project.yml" file it knows that it is in the base directory of a project, and automatically builds a package tree. You can see that there are two essential package directories, "apps" and "targets."
+
+<br>
+
+#### "apps" Package Directory
+
+`apps` is where applications are stored, and applications are where the main() function is contained. 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>
+pkg.name: apps/blinky
+pkg.vers: 0.8.0
+pkg.description: Basic example application which blinks an LED.
+pkg.author: "Apache Mynewt <de...@mynewt.incubator.apache.org>"
+pkg.homepage: "http://mynewt.apache.org/"
+pkg.repository:
+pkg.keywords:
+
+pkg.deps:
+ - "@apache-mynewt-core/libs/os"
+ - "@apache-mynewt-core/hw/hal"
+ - "@apache-mynewt-core/libs/console/full"
+```
+
+<br>
+
+This file says that the name of the package is apps/blinky, and it
+depends on libs/os, hw/hal and libs/console/full packages.
+
+**NOTE:** @apache-mynewt-core is a repository descriptor, and this will be
+covered in the "repository" section.
+
+<br>
+
+#### "targets" Package Directory
+
+`targets` is where targets are stored, and each target is a collection of parameters that must be passed to Newt in order to generate a reproducible build. Along with the `apps` directory, `targets` represents the top of the build tree. Any packages or parameters specified at the target level cascades down to all dependencies.
+
+Most targets consist of:
+
+* app: The application to build
+* bsp: The board support package to combine with that application
+* build_profile: Either debug or optimized.
+
+The `my_blinky_sim` target in the example below has the following settings:
+
+```
+$ newt target show
+targets/my_blinky_sim
+ app=apps/blinky
+ bsp=@apache-mynewt-core/hw/bsp/native
+ build_profile=debug
+$ ls my_blinky_sim/
+pkg.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 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
+* features: Any system level features you want to enable.
+
+<br>
+
+
+### Resolving dependencies
+
+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
+source packages
+
+Newt then looks at the target that the user set, for example, blinky_sim:
+
+```
+$ more targets/my_blinky_sim/
+pkg.yml target.yml
+$ more targets/my_blinky_sim/target.yml
+### Target: targets/my_blinky_sim
+target.app: "apps/blinky"
+target.bsp: "@apache-mynewt-core/hw/bsp/native"
+target.build_profile: "debug"
+```
+
+<br>
+
+The target specifies two major things:
+
+* Application (target.app): The application to build
+* Board Support Package (target.bsp): The board support package to build
+along with that application.
+
+Newt 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
+newt 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.
+
+
+```
+$ tree
+.
+├── README.md
+├── include
+│ └── os
+│ ├── arch
+│ │ ├── cortex_m0
+│ │ │ └── os
+│ │ │ └── os_arch.h
+│ │ ├── cortex_m4
+│ │ │ └── os
+│ │ │ └── os_arch.h
+│ │ └── sim
+│ │ └── os
+│ │ └── os_arch.h
+│ ├── endian.h
+│ ├── os.h
+│ ├── os_callout.h
+│ ├── os_cfg.h
+│ ├── os_eventq.h
+│ ├── os_heap.h
+│ ├── os_malloc.h
+│ ├── os_mbuf.h
+│ ├── os_mempool.h
+│ ├── os_mutex.h
+│ ├── os_sanity.h
+│ ├── os_sched.h
+│ ├── os_sem.h
+│ ├── os_task.h
+│ ├── os_test.h
+│ ├── os_time.h
+│ └── queue.h
+├── pkg.yml
+└── src
+ ├── arch
+<snip>
+
+```
+
+<br>
+
+- API requirements are validated. Packages can export APIs they
+implement, (i.e. pkg.api: hw-hal-impl), and other packages can require
+those APIs (i.e. pkg.req_api: hw-hal-impl).
+
+- "Features" options are supported. Packages can change what dependencies
+they 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
+```
+
+<br>
+
+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
+an archive file.
+
+**NOTE:** The Newt tool generates compiler dependencies for all of these packages, and only rebuilds the packages whose dependencies have changed. Changes in package & project dependencies are also taken into account. It is smart, after all!
+
+### Producing artifacts
+
+Once Newt has built all the archive files, it then links the archive files together. The linkerscript to use is specified by the board support package (BSP.)
+
+NOTE: One common use of the "features" option above is to overwrite
+which linkerscript is used, based upon whether or not the BSP is being
+build for a raw image, bootable image or bootloader itself.
+
+The newt tool places all of it's artifacts into the bin/ directory at
+the top-level of the project, prefixed by the target name being built,
+for example:
+
+```
+$ tree -L 4 bin/
+bin/
+└── my_blinky_sim
+ ├── apps
+ │ └── blinky
+ │ ├── blinky.a
+ │ ├── blinky.a.cmd
+ │ ├── blinky.elf
+ │ ├── blinky.elf.cmd
+ │ ├── blinky.elf.dSYM
+ │ ├── blinky.elf.lst
+ │ ├── main.d
+ │ ├── main.o
+ │ └── main.o.cmd
+ ├── hw
+ │ ├── bsp
+ │ │ └── native
+ │ ├── hal
+ │ │ ├── flash_map.d
+ │ │ ├── flash_map.o
+<snip>
+```
+
+<br>
+
+As you can see, a number of files are generated:
+
+- Archive File
+- *.cmd: The command use to generate the object or archive file
+- *.lst: The list file where symbols are located
+- *.o The object files that get put into the archive file
+
+### Download/Debug Support
+
+Once a target has been build, there are a number of helper functions
+that 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
+commands call out to scripts that are defined by the BSP.
+
+```
+$ more repos/apache-mynewt-core/hw/bsp/nrf52pdk/nrf52pdk_debug.sh
+<snip>
+#
+if [ $# -lt 1 ]; then
+ echo "Need binary to download"
+ exit 1
+fi
+
+FILE_NAME=$2.elf
+GDB_CMD_FILE=.gdb_cmds
+
+echo "Debugging" $FILE_NAME
+
+# Monitor mode. Background process gets it's own process group.
+set -m
+JLinkGDBServer -device nRF52 -speed 4000 -if SWD -port 3333 -singlerun &
+set +m
+
+echo "target remote localhost:3333" > $GDB_CMD_FILE
+
+arm-none-eabi-gdb -x $GDB_CMD_FILE $FILE_NAME
+
+rm $GDB_CMD_FILE
+```
+
+The idea is that every BSP will add support for the debugger environment
+for that board. That way common tools can be used across various development boards and kits.
+
+**NOTE:** Both for compiler definitions and debugger scripts, the plan is to
+create Dockerizable containers of these toolchains. This should make
+things much easier to support across Mac OS X, Linux and Windows. Newt
+will know how to call out to Docker to perform these processes.
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/newt/tutorials/define_target.md
----------------------------------------------------------------------
diff --git a/docs/newt/tutorials/define_target.md b/docs/newt/tutorials/define_target.md
deleted file mode 100644
index 5492e92..0000000
--- a/docs/newt/tutorials/define_target.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## How to Define a Target
-
-What newt commands to use?
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/os/tutorials/add_repos.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/add_repos.md b/docs/os/tutorials/add_repos.md
index 6213c41..43d1873 100644
--- a/docs/os/tutorials/add_repos.md
+++ b/docs/os/tutorials/add_repos.md
@@ -1,26 +1,22 @@
-## Additional Repositories
+## Adding Repositories to your Project
### What is a Repository
-A repository is a version-ed Mynewt project, which is a
-collection of Mynewt packages organized in a specific
-way.
+A repository is a version-ed Mynewt project, which is a collection of Mynewt packages organized in a specific way for redistribution.
What differentiates a repository from a Mynewt project is the presence of a
`repository.yml` file describing the repository. This will be described
-below. **Note:** For the remainder of this document we'll use the term repo as shorthand for a
-Mynewt repository.
+below. For a basic understanding of repositories you may read the [Newt Tool Manual](../../newt/newt_intro.md) and [How to create repos](../../newt/create_repo.md).
-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.
+**Note:** For the remainder of this document we'll use the term repo as shorthand for a Mynewt repository.
+
+Repos are useful because they are an organized way for the community to share Mynewt packages and projects. In fact, the Mynewt-core is distributed as a repo.
<br>
### Why does Mynewt need additional repos?
-Repos add functionality not included in the Mynewt core. New repos might be created for
-several reasons.
+Repos add functionality not included in the Mynewt core. New repos might be created for several reasons.
* **Expertise**. Individuals or organizations may have expertise that they want
to share in the form of repos. For example a chip vendor may
@@ -63,7 +59,7 @@ By default, this newly created project uses a single repo called
If you wish to add additional repos, you would add
additional lines to the `project.repositories` variable like this.
-```no-highlight
+``` hl_lines="3"
project.repositories:
- apache-Mynewt-core
- another_repo_named_x
@@ -127,7 +123,7 @@ section includes information on the field required in your repo descriptor.
* Edit the `project/yml` file and add a new line to the `project.repositories`
variable with the name of the repo you are adding.
-An example if a `project.yml` file with two repositories is shown below:
+An example of a `project.yml` file with two repositories is shown below:
```no-highlight
project.name: "my_project"
@@ -168,24 +164,18 @@ please use `0-latest` in the `vers` field in your repo descriptor.
vers:0-latest
```
-See below for a description of the version system.
+See [Create a Repo](../../newt/create_repo) for a description of the versioning system and all the possible ways to specify a version to use.
<br>
-### What is in a Repo
-
-A repo is a collection of Mynewt packages organized in a specific
-way and stored in one of the supported code storage methods described above.
+### Identifying a Repo
-A repo is a Mynewt project with an additional file `repository.yml`
-which describes the repo for use by `newt` (and humans browsing them).
+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.
-There is one key consideration for this `repository.yml` file. The
-`repository.yml` file only lives in the master branch of the git
+Note that the `repository.yml` file lives only in the master branch of the git
repository. `Newt` will always fetch this file from the master branch and then
-use that to resolve the actual branch required depending on the version
-specified in the project. Special care should be taken to ensure that this
-file exists only in the master branch.
+use that to determine the actual branch required depending on the version
+specified in your `project.yml` file. Special care should be taken to ensure that this file exists only in the master branch.
Here is the `repository.yml` file from the apache-Mynewt-core:
@@ -204,14 +194,13 @@ It contains the following:
* **repo.name** The external name that is used to include the library in
your `project.yml` file. This is the name you in include in the `project.repositories` variable when adding this repository to your project.
* **repo.versions** A description of what versions to give the user depending
-on the settings in their `project.yml` file. See below for a thorough description
-on versioning. Its a flexible mapping between version numbers and git branches.
+on the settings in their `project.yml` file.
<br>
### Repo Version
-The version field argument in your `project.yml` file has the following format:
+The repo version number resolves to an actual git branch depending on the mapping specified in `repository.yml` for that repo. The version field argument in your `project.yml` file supports multiple formats for flexibility:
```no-highlight
<major_num>.<minor_num>.<revision_num>
@@ -253,10 +242,12 @@ You cannot specify a stability string with a fully numbered version, e.g.
<br>
-A `repository.yml` file contains information to match this version request
+### Repo Versions Available
+
+A `repository.yml` file contains information to match a version request
into a git branch to fetch for your project.
-Its up to the repository maintainer to map these to branches of the
+It's up to the repository maintainer to map these to branches of the
repository. For example, let's say in a fictitious repository the following are
defined.
@@ -277,10 +268,12 @@ repo.versions:
....
```
-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
+When the `project.yml` file asks for `1.2-stable` it is resolved to version
+`1.2.0` (perhaps `1.2.1` is not stable yet), which in turn resolves to a specific
branch `xxx_branch_1_2_0`. This is the branch that `newt` fetches into
-your project.
+your project.
+
+**Note:** Make sure a repo version exists in the `repository.yml` file of a repo you wish to add. Otherwise Newt will not be able to resolve the version and will fail to fetch the repo into your project.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/os/tutorials/bletiny_project.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bletiny_project.md b/docs/os/tutorials/bletiny_project.md
new file mode 100644
index 0000000..084ea17
--- /dev/null
+++ b/docs/os/tutorials/bletiny_project.md
@@ -0,0 +1,5 @@
+## NimBLE project
+
+This tutorial explains how to start BLE 4.2 on a board and start seeing some BLE related statistics.
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/os/tutorials/create_repo.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/create_repo.md b/docs/os/tutorials/create_repo.md
new file mode 100644
index 0000000..1e1927e
--- /dev/null
+++ b/docs/os/tutorials/create_repo.md
@@ -0,0 +1,172 @@
+## Create a Repo out of a Project
+
+In order to create a repository out of a project, all you need to do is create a `repository.yml` file, and check it into the master branch of your project.
+
+**NOTE:** Currently only github source control service is supported by our package management system, but support for plain git will be added soon.
+
+The repository.yml defines all versions of the repository and the corresponding source control tags that these versions correspond to. As an example, if the repository.yml file has the following content, it means there is one version of the apache-mynewt-core operating system available, which is `0.0.0` (implying we haven't released yet!). Such a version number corresponds to the "develop" branch in this repository. `0-latest` would also resolved to this same `0.0.0` version. The next section explains the versioning system a bit more.
+
+```
+$ more repository.yml
+repo.name: apache-mynewt-core
+repo.versions:
+ "0.0.0": "develop"
+ "0-latest": "0.0.0"
+```
+
+<br>
+
+### Where should the repository.yml file be?
+
+The `repository.yml` file lives only in the master branch of the git
+repository. `Newt` will always fetch this file from the master branch and then
+use that to resolve the actual branch required depending on the version
+specified in the project. **Special care should be taken to ensure that this
+file exists only in the master branch.**
+
+Here is the `repository.yml` file from a certain snapshot of apache-Mynewt-core:
+
+```
+repo.name: apache-mynewt-core
+repo.versions:
+ "0.7.9": "Mynewt_0_8_0_b2_tag"
+ "0-latest": "0.7.9"
+ "0.8-latest": "0.7.9"
+```
+
+<br>
+
+It contains the following:
+
+* **repo.name** The external name that is used to include the library in
+your `project.yml` file. This is the name you in include in the `project.repositories` variable when adding this repository to your project.
+* **repo.versions** A description of what versions to give the user depending
+on the settings in their `project.yml` file. See below for a thorough description
+on versioning. Its a flexible mapping between version numbers and git branches.
+
+<br>
+
+### Repo Version Specification
+
+The version field argument for a repo has the following format:
+
+```no-highlight
+<major_num>.<minor_num>.<revision_num>
+```
+
+or
+
+```no-highlight
+<major_num>.<minor_num>-<stability string>
+```
+
+or
+
+```no-highlight
+<major_num>-<stability string>
+```
+
+<br>
+
+The stability string can be one of 3 pre-defined stability values.
+
+1. stable -- A stable release version of the repository
+2. dev -- A development version from the repository
+3. latest -- The latest from the repository
+
+In your `project.yml` file you can specify different combinations of
+the version number and stability value. For example:
+
+* `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.
+
+```no-highlight
+1.2.8-stable
+```
+
+<br>
+
+### Repo Version Resolution
+
+A `repository.yml` file contains information to match this version request
+into a git branch to fetch for your project.
+
+It's up to you as the repository maintainer to map these to actual github branches of the repository. For example, let's say in a fictitious repository the following are defined.
+
+```no-highlight
+repo.versions:
+ "0.8.0": "xxx_branch_0_8_0"
+ "1.0.0": "xxx_branch_1_0_0"
+ "1.0.2": "xxx_branch_1_0_2"
+ "1.1.1": "xxx_branch_1_1_0"
+ "1.1.2": "xxx_branch_1_1_2"
+ "1.2.0": "xxx_branch_1_2_0"
+ "1.2.1": "xxx_branch_1_2_1"
+ "1.2-dev": "1.2.1"
+ "1-dev": "1.2-dev"
+ "1.2-stable": "1.2.0"
+ "0-latest": "0.8.0"
+ "1-latest": "1-dev"
+ ....
+```
+
+When the `project.yml` file asks for `1.2-stable` it will be resolved to version
+`1.2.0` which in turn will resolve to a specific branch `xxx_branch_1_2_0`. This is the branch that `newt` will fetch into the project with that `project.yml` file.
+
+<br>
+
+### Dependencies on other repos
+
+Repositories can also have dependencies on other repositories. These
+dependencies should be listed out on a per-tag basis. So, for example,
+if apache-mynewt-core were to depend on sterlys-little-repo, you might
+have the following directives in the repository.yml:
+
+```
+develop.repositories:
+ sterlys-little-repo:
+ type: github
+ vers: 0.8-latest
+ user: sterlinghughes
+ repo: sterlys-little-repo
+```
+
+<br>
+
+This would tell Newt that for anything that resolves to the develop
+branch, this repository requires the sterlys-little-repo repository.
+
+Dependencies are resolved circularly by the newt tool, and every dependent repository is placed as a sibling in the repos directory. Currently, if two repositories have the same name, they will conflict and bad things will happen.
+
+When a repository is installed to the repos/ directory, the current
+version of that repository is written to the "project.state" file. The
+project state file contains the currently installed version of any given
+repository. This way, the current set of repositories can be recreated
+from the project.state file reliably, whereas the project.yml file can
+have higher level directives (i.e. include 0.8-stable.)
+
+
+### Resolving dependencies
+
+At the moment, all dependencies must match, otherwise newt will provide
+an error. As an example, if you have a set of dependencies such that:
+
+```
+apache-mynewt-core depends on sterlys-little-repo 0.6-stable
+apache-mynewt-core depends on sterlys-big-repo 0.5.1
+sterlys-big-repo-0.5.1 depends on sterlys-little-repo 0.6.2
+```
+
+<br>
+
+where 0.6-stable is 0.6.3, the newt tool will try and resolve the dependency to
+sterlys-little-repo. It will notice that there are two conflicting
+versions of the same repository, and not perform installation.
+
+In the future Newt will be smarter about loading in all dependencies,
+and then looking to satisfy those dependencies to the best match of all
+potential options.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/39bcbce3/docs/os/tutorials/define_target.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/define_target.md b/docs/os/tutorials/define_target.md
new file mode 100644
index 0000000..5492e92
--- /dev/null
+++ b/docs/os/tutorials/define_target.md
@@ -0,0 +1,3 @@
+## How to Define a Target
+
+What newt commands to use?
\ No newline at end of file