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/01/06 22:56:28 UTC
[25/45] incubator-mynewt-site git commit: fixed anchors in project
Blinky - still need to update Windows instructions for hardware target
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter2/project2.md
----------------------------------------------------------------------
diff --git a/docs/chapter2/project2.md b/docs/chapter2/project2.md
deleted file mode 100644
index 3a6e5a6..0000000
--- a/docs/chapter2/project2.md
+++ /dev/null
@@ -1,374 +0,0 @@
-## Project 2 - Blinky on additional boards
-
-### Objective
-
-The goal of this tutorial is to download a generic firmware skeleton ("bootstrap image") that applies to any hardware and then throw in additional applicable eggs to generate a build for a specific board. In the process you will be exposed to more Mynewt terms and Newt tool commands.
-
-The following target hardware chips are covered:
-
-* [STM32F303VC MCU](#stm32f303vc-mcu) from STMicroelectronics
-* [nRF52 Series](#nrf52-series) from Nordic Semiconductors
-
-
-### STM32F303VC MCU
-
-#### Hardware needed
-
-* Discovery kit with STM32F303VC MCU
-* Laptop running Mac OS
-
-
-#### Step by Step Instructions to build image
-
-* The first step is to download the generic skeleton of the project. The eggs constituting the skeleton are not hardware architecture specific. The skeleton is maintained as a nest in a separate repository on Apache. You know it is a nest because there is a nest.yml file.
-
- [user:~/dev]$ newt nest create test_project
- Downloading nest skeleton from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-tadpole.git... ok!
- Nest test_project successfully created in ~/dev/go/test_project
-
- [user:~/dev]$ cd test_project/
- [user:~/dev/test_project]$ ls
- README.md compiler hw libs nest.yml
-
-
-* Next, the clutch of eggs named larva is added from the nest (also named larva) from another repository on Apache. This step simply downloads the clutch description file and does not actually install the eggs that constitute the clutch. The clutch description file (`clutch.yml`) will be used to check dependencies during the egg install to ensure completeness. It serves as a reference for all the eggs in the clutch that one can choose from and install.
-
- [user:~/dev/test_project]$ newt nest add-clutch larva https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git
- Downloading clutch.yml from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva.git/master... ok!
- Verifying clutch.yml format...
- ok!
- Clutch larva successfully installed to Nest.
-
-* The next step is to install relevant eggs from the larva nest on github. The instructions assume that you know what application or project you are interested in (the blinky application, in this case), what hardware you are using (STM32F3DISCOVERY board, in this case) and hence, what board support package you need.
-
- [user:~/dev/test_project]$ newt egg install project/blinky
- Downloading larva from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/master... ok!
- Installing project/blinky
- Installing libs/console/full
- Installing libs/shell
- Installation was a success!
-
- [user:~/dev/test_project]$ newt egg install hw/bsp/stm32f3discovery
- Downloading larva from https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva/master... ok!
- Installing hw/bsp/stm32f3discovery
- Installing hw/mcu/stm/stm32f3xx
- Installing libs/cmsis-core
- Installing compiler/arm-none-eabi-m4
- Installation was a success!
-
-* It's time to create a target for the project and define the target attributes.
-
- [user:~/dev/test_project]$ newt target create blink_f3disc
- Creating target blink_f3disc
- Target blink_f3disc successfully created!
-
- [user:~/dev/test_project]$ newt target set blink_f3disc project=blinky
- Target blink_f3disc successfully set project to blinky
-
- [user:~/dev/test_project]$ newt target set blink_f3disc bsp=hw/bsp/stm32f3discovery
- Target blink_f3disc successfully set bsp to hw/bsp/stm32f3discovery
-
- [user:~/dev/test_project]$ newt target set blink_f3disc compiler_def=debug
- Target blink_f3disc successfully set compiler_def to debug
-
- [user:~/dev/test_project]$ newt target set blink_f3disc compiler=arm-none-eabi-m4
- Target blink_f3disc successfully set compiler to arm-none-eabi-m4
-
- [user:~/dev/test_project]$ newt target set blink_f3disc arch=cortex_m4
- Target blink_f3disc successfully set arch to cortex_m4
-
- [user:~/dev/test_project]$ newt target show blink_f3disc
- blink_f3disc
- arch: cortex_m4
- project: blinky
- bsp: hw/bsp/stm32f3discovery
- compiler_def: debug
- compiler: arm-none-eabi-m4
- name: blink_f3disc
-
-* Next, you get to build the target and generate an executable that can then be uploaded to the board. The STM32F3DISCOVERY board includes an ST-LINK/V2 embedded debug tool interface that will be used to program/debug the board. To program the MCU on the board, simply plug in the two jumpers on CN4, as shown in the picture in red. If you want to learn more about the board you will find the User Manual at [http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf](http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf)
-
-* 
-
-
- [user:~/dev/test_project]$ newt target build blink_f3disc
- Building target blink_f3disc (project = blinky)
- Compiling case.c
- Compiling suite.c
- Compiling testutil.c
- Compiling testutil_arch_arm.c
- Archiving libtestutil.a
- Compiling os.c
- Compiling os_callout.c
- Compiling os_eventq.c
- Compiling os_heap.c
- Compiling os_mbuf.c
- Compiling os_mempool.c
- Compiling os_mutex.c
- Compiling os_sanity.c
- Compiling os_sched.c
- Compiling os_sem.c
- Compiling os_task.c
- Compiling os_time.c
- Compiling os_arch_arm.c
- Assembling HAL_CM4.s
- Assembling SVC_Table.s
- Archiving libos.a
- Compiling hal_gpio.c
- Compiling stm32f3xx_hal_gpio.c
- Archiving libstm32f3xx.a
- Compiling cmsis_nvic.c
- Compiling libc_stubs.c
- Compiling os_bsp.c
- Compiling sbrk.c
- Compiling system_stm32f3xx.c
- Assembling startup_stm32f303xc.s
- Archiving libstm32f3discovery.a
- Compiling main.c
- Building project blinky
- Linking blinky.elf
- Successfully run!
-
-* Finally, you have to download the image on to the board. You will see a blue light start to blink.
-
- [user:~/dev/test_project]$ newt target download blink_f3disc
- Downloading with /Users/user/dev/test_project/hw/bsp/stm32f3discovery/stm32f3discovery_download.sh
-
-
-
-### nRF52 Series
-
-
-#### Hardware needed
-
-* nRF52 Development Kit
-* Laptop running Mac OS
-
-
-#### Step by Step Instructions to build image
-
-* The first step is to download the generic skeleton of the project. The eggs installed are not hardware architecture specific.
-
- []user@~/dev]$ newt nest create nordic_blinky
- Downloading nest skeleton from https://www.github.com/mynewt/tadpole... ok!
- Nest nordic_blinky successfully created in ~dev/nordic_blinky
-
- user@~/dev$ cd nordic_blinky/
-
-
-* Then, the clutch of eggs named larva is added from the nest (also named larva) on the github. This step simply downloads the clutch description file and does not actually install the eggs that constitute the clutch. The clutch description file (`clutch.yml`) will be used to check dependencies during the egg install to ensure completeness. It serves as a reference for all the eggs in the clutch that one can choose from and install.
-
- []user@~/dev/nordic_blinky]$ newt nest add-clutch larva https://github.com/mynewt/larva
- Downloading clutch.yml from https://github.com/mynewt/larva/master... ok!
- Verifying clutch.yml format...ok!
- Clutch larva successfully installed to Nest.
-
-* The next step is to install relevant eggs from the larva nest on github. The instructions assume that you know what application or project you are interested in (the blinky application, in this case), what hardware you are using (STM32F3DISCOVERY board, in this case) and hence, what board support package you need.
-
- [user@~/dev/nordic_blinky]$ newt egg install project/blinky
- Downloading larva from https://github.com/mynewt/larva//master... ok!
- Installing project/blinky
- Installation was a success!
-
-
- [user@~/dev/nordic_blinky]$ newt egg install hw/bsp/nrf52pdk
- Downloading larva from https://github.com/mynewt/larva//master... ok!
- Installing hw/bsp/nrf52pdk
- Installing hw/mcu/nordic/nrf52xxx
- Installing libs/cmsis-core
- Installing compiler/arm-none-eabi-m4
- Installation was a success!
-
-
-* It's time to create a target for the project and define the target attributes.
-
- [user@~/dev/nordic_blinky]$ newt target create blink_nordic
- Creating target blink_nordic
- Target blink_nordic successfully created!
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic project=blinky
- Target blink_nordic successfully set project to blinky
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic bsp=hw/bsp/nrf52pdk
- Target blink_nordic successfully set bsp to hw/bsp/nrf52pdk
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic compiler_def=debug
- Target blink_nordic successfully set compiler_def to debug
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic compiler=arm-none-eabi-m4
- Target blink_nordic successfully set compiler to arm-none-eabi-m4
- [user@~/dev/nordic_blinky]$ newt target set blink_nordic arch=cortex_m4
- Target blink_nordic successfully set arch to cortex_m4
- [user@~/dev/nordic_blinky]$ newt target show
- blink_nordic
- compiler: arm-none-eabi-m4
- name: blink_nordic
- arch: cortex_m4
- project: blinky
- bsp: hw/bsp/nrf52pdk
- compiler_def: debug
-
-
-* Finally, you get to build the target and generate an executable that can now be uploaded to the board via the on-board SEGGER J-Link debugger.
-
- [user@~/dev/nordic_blinky]$ newt target build blink_nordic
- Building target blink_nordic (project = blinky)
- Compiling case.c
- Compiling suite.c
- Compiling testutil.c
- Compiling testutil_arch_arm.c
- Archiving libtestutil.a
- Compiling os.c
- Compiling os_callout.c
- Compiling os_eventq.c
- Compiling os_heap.c
- Compiling os_mbuf.c
- Compiling os_mempool.c
- Compiling os_mutex.c
- Compiling os_sanity.c
- Compiling os_sched.c
- Compiling os_sem.c
- Compiling os_task.c
- Compiling os_time.c
- Compiling os_arch_arm.c
- Assembling HAL_CM4.s
- Assembling SVC_Table.s
- Archiving libos.a
- Compiling hal_cputime.c
- Compiling hal_gpio.c
- Compiling hal_uart.c
- Archiving libnrf52xxx.a
- Compiling cmsis_nvic.c
- Compiling hal_bsp.c
- Compiling libc_stubs.c
- Compiling os_bsp.c
- Compiling sbrk.c
- Compiling system_nrf52.c
- Assembling gcc_startup_nrf52.s
- Archiving libnrf52pdk.a
- Compiling main.c
- Building project blinky
- Linking blinky.elf
- Successfully run!
-
-* In order to be able to communicate with the SEGGER J-Link debugger on the dev board, you have to download and install the J-Link GDB Server software on to your laptop. You may download the "Software and documentation pack for Mac OS X" from [https://www.segger.com/jlink-software.html](https://www.segger.com/jlink-software.html). The command line version of the server is used in the steps below.
-
-* Open a new terminal and start a J-Link session.
-
- [user@~/dev/nordic_blinky/project/blinky/bin]$ which JLinkGDBServer
- /usr/local/bin/JLinkGDBServer
- [user@~/dev/nordic_blinky/project/blinky/bin]$ JLinkGDBServer -if SWD
- SEGGER J-Link GDB Server V5.02f Command Line Version
-
- JLinkARM.dll V5.02f (DLL compiled Oct 2 2015 20:55:03)
-
- -----GDB Server start settings-----
- GDBInit file: none
- GDB Server Listening port: 2331
- SWO raw output listening port: 2332
- Terminal I/O port: 2333
- Accept remote connection: yes
- Generate logfile: off
- Verify download: off
- Init regs on start: off
- Silent mode: off
- Single run mode: off
- Target connection timeout: 0 ms
- ------J-Link related settings------
- J-Link Host interface: USB
- J-Link script: none
- J-Link settings file: none
- ------Target related settings------
- Target device: unspecified
- Target interface: SWD
- Target interface speed: 1000kHz
- Target endian: little
-
- Connecting to J-Link...
- J-Link is connected.
- Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Aug 28 2015 19:26:24
- Hardware: V1.00
- S/N: 682371959
- Checking target voltage...
- Target voltage: 3.30 V
- Listening on TCP/IP port 2331
- Connecting to target...Connected to target
- Waiting for GDB connection...Connected to 127.0.0.1
-
-
-* You need a configuration file for the GDB session to be opened correctly and the image ("blinky.elf") you built for this target downloaded to flash. A sample config script is given below. Alternatively, you could choose to type each command at the gdb prompt.
-
- [user@~/dev/nordic_blinky/project/blinky/bin/blink_nordic]$ cat jlink-gdb.cfg
- echo ***Setting up the environment for debugging gdb.***\n
- set complaints 1
- set prompt (gdb)
- set endian little
- echo \n*** Set target charset ASCII\n
- set target-charset ASCII
- echo \n*** Connecting over port #2331 ***\n
- target remote localhost:2331
- echo \n*** Enable flash write and set device to nrf52 ***\n
- monitor flash download=1
- monitor flash device=nRF52
- echo \n*** loading blinky.elf ***\n
- load ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf
- symbol-file ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf
- echo \n*** Resetting target ***\n
- monitor reset
- echo \n*** Halting target ***\n
- monitor halt
-
-* Start the gdb session and monitor that it loads the image, resets the target, and halts for a command to continue.
-
- [user@~/dev/nordic_blinky/project/blinky/bin/blink_nordic]$ arm-none-eabi-gdb -x ~/dev/nordic_blinky/project/blinky/bin/blink_nordic/jlink-gdb.cfg
-
- GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs
- Copyright (C) 2014 Free Software Foundation, Inc.
- License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
- This is free software: you are free to change and redistribute it.
- There is NO WARRANTY, to the extent permitted by law. Type "show copying"
- and "show warranty" for details.
- This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
- Type "show configuration" for configuration details.
- For bug reporting instructions, please see:
- <http://www.gnu.org/software/gdb/bugs/>.
- Find the GDB manual and other documentation resources online at:
- <http://www.gnu.org/software/gdb/documentation/>.
- For help, type "help".
- Type "apropos word" to search for commands related to "word".
-
- ***Setting up the environment for debugging gdb.***
- The target is assumed to be little endian
-
- *** Set target charset ASCII
-
- *** Connecting over port #2331 ***
- 0x00003c34 in ?? ()
-
- *** Enable flash write and set device to nrf52 ***
- Flash download enabled
- Selecting device: nRF52
-
- *** loading blinky.elf ***
- Loading section .text, size 0x5c84 lma 0x0
- Loading section .ARM.extab, size 0x24 lma 0x5c84
- Loading section .ARM.exidx, size 0xd8 lma 0x5ca8
- Loading section .data, size 0x8f8 lma 0x5d80
- Start address 0x48c, load size 26232
- Transfer rate: 12808 KB/sec, 2914 bytes/write.
- During symbol reading, unexpected overlap between:
- (A) section `.text' from `~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf' [0x0, 0x5c84)
- (B) section `*COM*' from `~/dev/nordic_blinky/project/blinky/bin/blink_nordic/blinky.elf' [0x0, 0x0).
- Will ignore section B.
-
- *** Resetting target ***
- Resetting target
-
- *** Halting target ***
-
-* Type 'c' to continue. The LED on the board will start to blink. You will also see some activity in the terminal showing the open J-Link GDB server connection. The LED will continue to blink after you quit out of that connection.
-
- (gdb) c
- Continuing.
-
-
-
-
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter2/project3.md
----------------------------------------------------------------------
diff --git a/docs/chapter2/project3.md b/docs/chapter2/project3.md
deleted file mode 100644
index 43e6a59..0000000
--- a/docs/chapter2/project3.md
+++ /dev/null
@@ -1 +0,0 @@
-## How to Test an Egg
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter2/vocabulary.md
----------------------------------------------------------------------
diff --git a/docs/chapter2/vocabulary.md b/docs/chapter2/vocabulary.md
deleted file mode 100644
index 5e6b792..0000000
--- a/docs/chapter2/vocabulary.md
+++ /dev/null
@@ -1,170 +0,0 @@
-## Understanding Newt Terms
-
-### Nest
-
-The nest is the base directory of your embedded software. It is meant to be the workspace containing a logical collection of the source code for one or more of your projects. A nest can contain multiple projects, and reflect multiple end products.
-
-As the base repository of your source code, the nest has a master branch and several other branches off it. You may choose any branch to nest on. Each project in your nest will typically consist of several [eggs](#egg). A project could be an egg itself as well. In addition to eggs, a local nest will contain additional items such as [target](#target) or build definitions, clutch description files, scripts etc.
-
-For example, a walk through the "larva" nest at [https://github.com/mynewt/larva.git](https://github.com/mynewt/larva.git) shows the following structure. The nest.yml file in the larva directory indicates that it is a nest. An egg will have the egg.yml file in it as shown below. By this nomenclature, each board support package for a particular chip is an egg, the API for the hardware abstraction layer is an egg, and so on.
-
-```
-larva
- |- nest.yml
- |- compiler
- |- arm-none-eabi-m4
- |- sim
- |- hw (hardware)
- |- bsp (board support package)
- |- nrf52pdk (Nordic nRF52 series chip)
- |- egg.yml
- |- ...
- |- olimex_stm32-e407_devboard (used in chapter1 project)
- |- egg.yml
- |- ...
- |- stm32f3discovery (another board with stm32f3 mcu)
- |- egg.yml
- |- ...
- |- yet another board
- |- egg.yml
- |- ...
- |- hal (hardware abstraction layer APIs)
- |- egg.yml
- |- include
- |- hal_cputime.h
- |- hal_flash.h
- |- hal_gpio.h
- |- ... (header files for other peripherals)
- |- mcu (microcontroller)
- |- stm (STMicro family)
- |- stm32f3xx (STM32f3 series, 32-bit ARM Cortex-M4 core)
- |- egg.yml
- |- src
- |- hal_gpio.c (specific to the STM32f3 mcu)
- |- hal_cputime.c
- |- ... (code for other peripherals)
- |- nordic (Nordic Semiconductor family)
- |- nrf52xxx (nRF52 Series SoC, Cortex-M4F core)
- |- egg.yml
- |- src
- |- hal_gpio.c (specific to the nRF52 mcu )
- |- hal_cputime.c
- |- ... (code for other peripherals)
- |- yet another family of mcu
- |- ...
- |- libs
- |- bootutil (hw architecture independent boot loader library)
- |- egg.yml
- |- src
- |- loader.c
- |- ... (related source code files)
- |- nffs (hw architecture independent Newtron Flash File System)
- |- egg.yml
- |- src
- |- nffs.c
- |- ... (related source code files)
- |- another library
- |- egg.yml
- |- src
- |- ... (related source code files)
- |- project
- |- scripts
-
-
-```
-
-The newt tool offers the `nest` command to create and manage nests. In general, commands represent actions and flags are modifiers for those actions. A command can have children commands and optionally run an action. A full description of the `nest` command can be found in the newt tool reference in Chapter 3.
-
- newt nest [flags]
- newt nest [child-commands]
-
-A complete list of all the nest commands can be found in the newt tool reference in [Chapter 3](../chapter3/newt_tool_reference.md).
-
-### Project
-
-Projects represent the individual build configurations of your embedded system and essentially defines your application. The project files are what dictate the resulting binary that is generated.
-
-Layout-wise, a project is a directory inside a nest and contains eggs required for a certain application. For example, the `blinky` egg sits in `project/blinky` directory of the `larva` nest. This egg is used in the blinky project (application) outlined in [Chapter 1](../chapter1/project1.md). <*Note: This Will Change*>
-
-A project has the following concepts or properties associated with it. You can find them in the `<project-name>.yml` file in the project directory. For example, the `project/blinky` directory has the `blinky.yml` file indicating some or all of the properties below. Only the name of a project is required for the project to exist, however additional properties may need to be specified for the eggs in it to compile properly and produce an executable.
-
-* Project name
-* Base path of the project (nest/project/project-name by default)
-* Eggs belonging to the project
-* [Capabilities](#capabilities) that are required for the project or target
-* [Identity](#identity) to classify the type of project or target
-* Compiler flags to call out any specific compiler requirement
-
-A project could itself be an egg if it is a distributable package for a specific application.
-
-The newt tool offers various commands that you can use with a project. For example, if your project is an egg, you can use the following command to install a project from a nest.
-
- newt egg install [flags] <project egg name>
-
-### Egg
-
-An egg is a distributable package of libraries. Just as an egg in nature has various parts each of which serves a certain purpose, the Mynewt egg consists of software parcels or modules that have different functions. However, unlike the egg in nature these software modules can exist by itself and may be distributed; therefore, they too are essentially eggs. Once this concept is grasped it is easy to see how an egg may consist of other eggs.
-
-The two main directories in an egg are `/include` and `/src`.
-
-The newt tool offers several egg commands to list, inspect, install, and do other operations on eggs. For example, the following command
-
- newt egg list
-
-outputs all the eggs in the current nest where each egg has details on its version, path, and dependencies. A sample output for an egg is given below.
-
- Egg libs/os, version 0.1.0
- path: /Users/aditihilbert/dev/test_project/libs/os
- deps: libs/testutil@none#stable
-
-A complete list of all the egg commands can be found in the newt tool reference in [Chapter 3](../chapter3/newt_tool_reference.md).
-
-### Clutch
-
-A clutch is a snapshot of all eggs in a remote nest at any point in time. On any given github branch, a nest with a clutch of eggs will contain a `clutch.yml` file that specifies the version number, dependencies, and hash value for each constituent egg as well as the name of the entire clutch and the github url for it. [Note: Currently ]
-
-You may download multiple clutches into your local nest as long as the names of the clutches are different. This allows you to mix and match various features and functionality coming from different clutches of eggs. You can see all the clutches in the `.nest/clutches` directory in your nest.
-
-The newt tool offers clutch management commands within the `newt nest` command. For example, the following command creates a new clutch using all the eggs in the current directory. It requires that a clutch name be specified and the url for the location of that clutch in the online repository. These two inputs go into the `clutch.yml` file in the nest.
-
- newt nest generate-clutch <name> <url>
-
-Note that a clutch merely defines the eggs belonging together and requires the eggs to be installed (hatched) for the source code to be populated in the project.
-
-### Eggshell
-
-The term eggshell is used to refer to the eggs of a clutch in a remote repository. They are not useful on your local machine until you actually install them. So they are mere shells of themselves while sitting on the online repository. When you enter the following command outputs the total number of shells in each remote clutch.
-
- newt nest list-clutches
-
-So, if you had two clutches installed, the output could be:
-
- Remote clutch larva (eggshells: 19)
- Remote clutch ble_test (eggshells: 15)
-
-### Target
-
-A target is the hardware build or its software equivalent (e.g. test, simulator) set for a project. It tells the newt tool how to build the source code within a given nest. Once a new target is created, its architecture and other details needs to be defined. An example of a defined target named "blink_f3disc" is given below.
-
- blink_f3disc
- compiler_def: debug
- compiler: arm-none-eabi-m4
- name: blink_f3disc
- arch: cortex_m4
- project: blinky
- bsp: hw/bsp/stm32f3discovery
-
-The newt tool offers commands to create, set up and manipulate targets. For example, the create command below creates an empty target named `my_target1` and the set command sets one detail of its definition, namely the architecture.
-
- newt target create my_target1
- newt target set my_target1 arch=cortex_m4
-
-### Capability
-
-Capability is functionality that is exposed by an egg. A capability is tracked by its name and version. An egg may require capabilities exposed by another egg, thus establishing a dependency tracked through the egg.yml files.
-
-The newt tool can ascertain a map of all the egg capabilities and use it to check dependencies and make sure all the necessary eggs are in a project for a particular target.
-
-### Identity
-
-Identity is a property of a target or project in the newt world. A target may inherit it from a project or vice versa. It may be used to determine what eggs to include or how an egg code should behave in a build or which linkerscripts to use. For example, the identity of a lock is different from the identity of a wearable monitor. Even if they were to be built on the same hardware target, different features and behavior are required. Their different identities result in differing sets of eggs in the projects and/or the same egg behaving differently depending on the identity.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter3/newt_ops.md
----------------------------------------------------------------------
diff --git a/docs/chapter3/newt_ops.md b/docs/chapter3/newt_ops.md
deleted file mode 100644
index 39171d0..0000000
--- a/docs/chapter3/newt_ops.md
+++ /dev/null
@@ -1,40 +0,0 @@
-## Command Structure
-
-In the newt tool, commands represent actions and flags are modifiers for those actions. A command can have children commands which are also simply referred to as commands. One or more arguments may need to be provided to a command to execute it correctly.
-
-In the example below, the `newt` command has the child command `target set`. The first argument 'my_target1' is the name of the target whose attributes are being set. The second argument 'arch=cortex_m4' specifies the value to set the attribute (variable) 'arch' to, which in this case is 'cortex_m4'.
-
- newt target set my_target1 arch=cortex_m4
-
-Global flags work on all newt commands in the same way. An example is the flag `-v, --verbose` to ask for a verbose output while executing a command. The help flag `-h` or `--help` is available on all commands but provides command specific output, of course. These flags may be specified in either a long or a short form.
-
-A command may additionally take flags specific to it. For example, the `-b ` flag may be used with `newt egg install` to tell it which branch to install the egg from.
-
- newt egg install -b <branchname> <eggname>
-
-In addition to the newt tool [reference](../chapter3/newt_tool_reference.md) in this documentation set, command-line help is available for each command (and child command). Simply use the flag `-h` or `--help` as shown below:
-
- $ newt target export --help
- Export build targets from the current nest, and print them to
- standard output. If the -a (or -export-all) option is specified,
- then all targets will be exported. Otherwise, <target-name>
- must be specified, and only that target will be exported.
-
- Usage:
- newt target export [flags]
-
- Examples:
- newt target export [-a -export-all] [<target-name>]
- newt target export -a > my_exports.txt
- newt target export my_target > my_target_export.txt
-
- Flags:
- -a, --export-all=false: If present, export all targets
- -h, --help=false: help for export
-
- Global Flags:
- -l, --loglevel="WARN": Log level, defaults to WARN.
- -q, --quiet=false: Be quiet; only display error output.
- -s, --silent=false: Be silent; don't output anything.
- -v, --verbose=false: Enable verbose output when executing commands.
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter3/newt_tool_reference.md
----------------------------------------------------------------------
diff --git a/docs/chapter3/newt_tool_reference.md b/docs/chapter3/newt_tool_reference.md
deleted file mode 100644
index 27cf442..0000000
--- a/docs/chapter3/newt_tool_reference.md
+++ /dev/null
@@ -1,269 +0,0 @@
-
-## Command List
-
-### Available high-level commands
-
-```
-version Display the Newt version number
-help Help about any command
-nest Commands to manage nests & clutches (remote egg repositories)
-egg Commands to list and inspect eggs on a nest
-target Set and view target information
-```
-
-### *version*
-
-#### Usage:
-
- newt version [flags]
-
-Flags:
-
- -h, --help=false: help for version
-
-Global Flags:
-
- -h, --help=false: help for newt
-
-
-Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-version | newt version | Displays the version of newt tool installed
-
-
-### *help*
-
-#### Usage:
-
- newt help [input1]
-
-Flags:
-
-```
-
--h, --help=false: help for newt
--l, --loglevel="WARN": Log level, defaults to WARN.
--q, --quiet=false: Be quiet; only display error output.
--s, --silent=false: Be silent; don't output anything.
--v, --verbose=false: Enable verbose output when executing commands.
-```
-
-Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-help | newt help target | Displays the help text for the newt command 'target'
-help | newt help | Displays the help text for newt tool
-
-
-
-### *nest*
-
-#### Usage:
-
- newt nest [command][flags] input1 input2...
-
-Available commands:
-
- create Create a new nest
- generate-clutch Generate a clutch file from the eggs in the current directory
- add-clutch Add a remote clutch, and put it in the current nest
- list-clutches List the clutches installed in the current nest
- show-clutch Show an individual clutch in the current nest
-
-
-Flags:
-
- -h, --help=false: help for nest
-
-Global Flags:
-
- -h, --help=false: help for newt
- -l, --loglevel="WARN": Log level, defaults to WARN.
- -q, --quiet=false: Be quiet; only display error output.
- -s, --silent=false: Be silent; don't output anything.
- -v, --verbose=false: Enable verbose output when executing commands.
-
-Description
-
-Sub-command | Explanation
--------------| ------------------------
-create | Downloads the skeleton of a nest on your local machine from the optional `input2` nest url, if specified, and creates a new nest directory by the name of `input1`. If `input2` is not specified, then a default skeleton from the `tadpole` nest on Mynewt is downloaded. The command lays out a generic directory structure for the nest you are going to build under it and includes some default eggs in it.
-generate-clutch | Takes a snapshot of the eggs in the current local directory and combines them into a clutch by the name of `input1` and with the url of `input2` and generates a standard output of the clutch details that can be redirected to a `.yml` clutch file. Typically the clutch file name is chosen to match the clutch name which means the standard output should be directed to a clutch file named `input1.yml`
-add-clutch | Downloads the clutch of the name `input1` from the master branch of the github repository `input2` into the current nest. A file named `input1.yml` file is added in the `.nest/clutches` subdirectory inside the current local nest. The `.nest/` directory structure is created automatically if it does not exist.
-list-clutches | Lists all the clutches present in the current nest, including clutches that may have been added from other nests on github. The output shows all the remote clutch names and the total eggshells in each of the clutches.
-show-clutch | Shows information about the clutch that has the name given in the `input1` argument. Output includes the clutch name, url, and all the constituent eggs with their version numbers.
-
-Command-specific flags
-
-Sub-command | Available flags | Explanation
--------------| ----------------|------------
-add-clutch | -b, --branch="<branch-name>" | Fetches the clutch file with name `input1` from the specified branch at `input1` url of the github repository. All subsequent egg installations will be done from that branch.
-
-Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-create | newt nest create test_project | Creates a new nest named "test_project " using the default skeleton0
-create | newt nest create mynest <nest-url> | Creates a new nest named "mynest" using the skeleton at the <nest-url> specified
-generate-clutch | newt nest generate-clutch myclutch https://www.github.com/mynewt/larva > myclutch.yml| Takes a snapshot of the eggs in the current nest to form a clutch named myclutch with the url https://www.github.com/mynewt/larva. The output is written to a file named `myclutch.yml` and describes the properties and contents of the clutch (name, url, eggs).
-add-clutch | newt nest add-clutch larva https://www.github.com/mynewt/larva | Adds the remote clutch named larva at www.github.com/mynewt/larva to the local nest.
-list-clutches | newt nest list-clutches | Shows all the remote clutch description files that been downloaded into the current nest
-show-clutch | newt nest show-clutch larva | Outputs the details of the clutch named larva such as the github url where the remote sits, the constituent eggs and their versions
-
-
-### *egg*
-
-#### Usage:
-
- newt egg [command][flag] input1 input2
-
-
-Available Commands:
-
- list List eggs in the current nest
- checkdeps Check egg dependencies
- hunt Search for egg from clutches
- show Show the contents of an egg.
- install Install an egg
- remove Remove an egg
-
-Flags:
-
- -h, --help=false: help for egg
-
-Global Flags:
-
- -l, --loglevel="WARN": Log level, defaults to WARN.
- -q, --quiet=false: Be quiet; only display error output.
- -s, --silent=false: Be silent; don't output anything.
- -v, --verbose=false: Enable verbose output when executing commands.
-
-Description
-
-Sub-command | Explanation
--------------| ------------------------
-list | List all the eggs in the current nest. The output shows the name, version, path, and any additional attributes of each egg in the nest such as dependencies, capabilities, and linker scripts. The newt command gets the attributes of each egg from the corresponsing egg.yml description file.
-checkdeps | Resolve all dependencies in the local nest. This command goes through all eggs currently installed, checks their dependencies, and prints any unresolved dependencies between eggs.
-hunt | Hunts for an egg, specified by `input1`. The local nest, along with all remote nests (clutches) are searched. All matched eggs are shown along with the clutch informaton. Installed eggs are called out as such. The command can be invoked from anywhere in the nest.
-show | Show the contents of the egg named `input2` found in the clutch named `input1`. The clutch name is optional; if only the egg name is given as the argument it is resolved using all the clutches installed in the current nest. If the egg is present in multiple clutches it will list all of them along with the clutch information for each.
-install | Install the egg specified by `input2` from the clutch named `input1`. The command downloads the egg from the github repository using the URL in the clutch description file (typically donwloaded as 'input1@<branch-name>.yml' in .nest/clutches). It also downloads all the dependencies (constituent eggs) as decribed in the egg's description file ('egg.yml') and installs all of them. The clutch name is optional. If only the egg name is given as the argument, the command looks for the egg name in all the clutches in the local nest and installs accordingly. An egg is installed by this command only if it has not already been installed.
-remove | Remove an egg named `input2` from clutch `input1`, if clutch is specified. Otherwise only one input required - that of the name of the egg to be removed from the local nest.
-
-
-
-
-Command-specific flags
-
-Sub-command | Available flags | Explanation
--------------| ----------------|------------
-install | -b, --branch="<branch-name>" | Installs the eggs from the branch name or tag of the clutch specified
-
-Examples
-
-Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-list | newt egg list | CList all of the eggs in the current nest and the details of the eggs.
-checkdeps | newt egg checkdeps | Checks all the dependencies between eggs in the nest. Lists any unresolved dependencies.
-hunt | newt egg hunt blinky| Hunts for the egg named 'blinky'. The command can be invoked from anywhere in the nest. Results show if the egg is installed and which clutch, if any, has the egg.
-show | newt egg show larva libs/os | Show the contents of the egg named 'libs/os' in the clutch named larva. The contents are essentially derived from the egg's 'egg.yml' file.
-install | newt egg install hw/bsp/stm32f3discovery | Downloads and installs the egg named "stm32f3discovery" (specified with its full path name inside the remote nest) along with all its dependencies from the remote nest on github. Since no clutch is specified, the URL for the remote nest in the clutch description file found in the local nest (in .nest/clutches for the project) is used.
-remove | newt egg remove larva blinky| Removes the egg named blinky only from the clutch named larva
-remove | newt egg remove blinky| Removes the egg named blinky from the local nest
-
-
-### *target*
-
-#### Usage:
-
-Usage:
-
- newt target [command] input1 [flag1] [flag2]
-
-Available Commands:
-
- set Set target configuration variable
- unset Unset target configuration variable
- delete Delete target
- create Create a target
- show View target configuration variables
- build Build target
- test Test target
- export Export target
- import Import target
- download Download image to target
- debug Download image to target and start an openocd/gdb session
-
-Flags:
-
- -h, --help=false: help for target
-
-Global Flags:
-
- -l, --loglevel="WARN": Log level, defaults to WARN.
- -q, --quiet=false: Be quiet; only display error output.
- -s, --silent=false: Be silent; don't output anything.
- -v, --verbose=false: Enable verbose output when executing commands.
-
-Description
-
-Sub-command | Explanation
--------------| ------------------------
-set | Set attributes of the target. Currently the list of possible attributes are:``` arch, compiler, compiler_def, project, bsp, egg, identities, capabilities, dependencies, cflags, lflags```. Typically only the first 5 need to be set for a hardware target. For a simulated target, e.g. for software testing purposes, `arch=sim`, `compiler=sim`, and `egg=<egg name to be tested>`. You cannot set both the project and egg for a target.
-unset | Unset attributes of the target in its configuration.
-delete | Deletes only the description for the target. Does not delete the target directory with associated binaries. If you want to clean out the binaries, list files, and executables use`newt target build <target-name> clean` **before** deleting the target!
-create | Creates a target description or build definition by the name `input1`. By default it assigns the sim (simulator) architecture to it which allows you to build new projects and software on your native OS and try it out.
-show | Display the configuration defined for the target named `input1`. If no `input1` is specified then show the details for all the targets in the nest.
-build | Build the source code into an image that can be loaded on the hardware associated with the target named `input1` to do the application enabled by the 'project' associated with that target (via the target definition). It creates 'bin/' and 'bin/<input1>/' subdirectories inside the base directory for the project, compiles and generates binaries and executables, and places them in 'bin/<input1>/.
-test | Test an egg on the target named `input1`. The egg is either supplied as an argument to the command line invocation of `newt target test` or added as part of the target definition. If only the target is specified as `input1`, then the egg in the target's definition is automatically chosen to be tested. You currently cannot test an entire project on a hardware target. The test command is envisioned for use if one or two eggs gets updated and each needs to be tested against a target. Alternatively, a script may be written for a series of tests on several eggs.
-export | Exports the configurations of the specified target `input1`. If -a or -export-all flag is used, then all targets are exported and printed out to standard out. You may redirect the output to a file.
-import | Import one or more target configuration from standard input or a file. Each target starts with `@target=<target-name>` followed by the attributes. The list of targets should end with `@endtargets`.
-size | Outputs the RAM and flash consumption by the components of the specified target `input1`.
-download | Downloads the binary executable `<target-name>.elf.bin` to the board.
-debug | Downloads the binary executable `<target-name>.elf.bin` to the board and starts up the openocd/gdb combination session. gdb takes over the terminal.
-
-
-Command-specific flags
-
-Sub-command | Available flags | Explanation
--------------| ----------------|------------
-build | clean | All the binaries and object files for the specified target will be removed. The subdirectory named after the specified target within that project is removed.
-build clean | all | All the binaries and object files for all targets are removed, and subdirectories of all targets for the project are removed. However, the entire repository is not emptied since any eggs or projects that the specified target doesn't reference are not touched.
-export | -a, -export-all | Export all targets. `input1` is not necessary when this flag is used.
-import | -a, -import-all | Import all targets typed into standard input or redirected from a file.
-
-Examples
-
- Sub-command | Usage | Explanation
--------------| -----------------------|-----------------
-set | newt target set myblinky compiler=arm-none-eabi-m4 | Set the compiler for the 'myblinky' target to the gcc compiler for embedded ARM chips.
-unset | newt target unset myblinky compiler | Remove the setting for the compiler for the 'myblinky' target.
-delete | newt target delete myblinky | Delete the target description for the target named 'myblinky'. Note that it does not remove any binaries or clean out the directory for this target.
-create | newt target create blink_f3disc | Create a new target description by the name 'blink_f3disc'. The architecture is 'sim' by default and can be changed using subcommand 'set' above.
-show | newt target show myblinky | Show the target attributes set for 'myblinky'
-build | newt target build blink_f3disc | Compile the source code for the target named blink_f3disc and generate binaries that can be loaded into the target hardware.
-test | newt target test test_target egg=libs/os | Tests the egg named 'libs/os' against the target named 'test_target'
-export | newt target export -a > my_exports.txt | Export all build targets from the current nest, and redirect output to a file named 'my_exports.txt'.
-export | newt target export -export-all | Export all build targets from the current nest, and print them to standard output on the screen.
-export | newt target export my_target | Export only target named 'my_target' and print it to standard output on the screen.
-import | newt target import ex_tgt_1 < exported_targets.txt | Imports the target configuration for 'ex_tgt_1' in 'exported_targets.txt'.
-import | newt target import -a < in_targets.txt | Imports all the targets specified in the file named `in_targets.txt`. A sample file is shown after this table.
-size | newt target size blink_nordic | Inspects and lists the RAM and Flash memory use by each component (object files and libraries) of the target.
-download | newt target -v -lVERBOSE download blinky | Downloads `blinky.elf.bin` to the hardware in verbose mode with logging turned on at VERBOSE level.
-debug | newt target debug blinky | Downloads `blinky.elf.bin` to the hardware, opens up a gdb session with `blinky.elf` in the terminal, and halts for further input in gdb.
-
-Example content for `in_targets.txt` file used for importing targets `test3` and `test4`.
-
-> @target=test3
-project=blinked
-arch=sim
-compiler_def=debug
-compiler=arm-none-eabi-m4
-@target=test4
-project=super_blinky
-arch=sim
-compiler_def=debug
-compiler=arm-none-eabi-m4
-@endtargets
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/context_switch.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/context_switch.md b/docs/chapter4/context_switch.md
deleted file mode 100644
index d2e8b80..0000000
--- a/docs/chapter4/context_switch.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Scheduler/Context Switching
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe scheduler here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in the scheduler are:
-
-* [os_sched_insert](#function-os_sched_insert)
-* [os_sched_walk](#function-os_sched_walk)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_sched_insert</font>
-
-```
- os_error_t
- os_sched_insert(struct os_task *t)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_sched_walk</font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/event_queue.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/event_queue.md b/docs/chapter4/event_queue.md
deleted file mode 100644
index 6de4adb..0000000
--- a/docs/chapter4/event_queue.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Event Queues
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe scheduler here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_eventq_init](#function-os_eventq_init)
-* [os_eventq_put2](#function-os_eventq_put2)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_eventq_init</font>
-
-```
- void
- os_eventq_init(struct os_eventq *evq)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_eventq_put2</font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/heap.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/heap.md b/docs/chapter4/heap.md
deleted file mode 100644
index b960c26..0000000
--- a/docs/chapter4/heap.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Heap
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_malloc_lock](#function-os_malloc_lock)
-* [os_malloc_unlock](#function-os_malloc_unlock)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_malloc_lock</font>
-
-```
- static void
- os_malloc_lock(void)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_malloc_unlock</font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/mbufs.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/mbufs.md b/docs/chapter4/mbufs.md
deleted file mode 100644
index c2938fc..0000000
--- a/docs/chapter4/mbufs.md
+++ /dev/null
@@ -1,150 +0,0 @@
-# Mbufs
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_mbuf_pool_init](#function-os_mbuf_pool_init)
-* [os_mbuf_get](#function-os_mbuf_get)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_mbuf_pool_init</font>
-
-```
- int
- os_mbuf_pool_init(struct os_mbuf_pool *omp, struct os_mempool *mp,
- uint16_t hdr_len, uint16_t buf_len, uint16_t nbufs)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_mbuf_get</font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/memory_pool.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/memory_pool.md b/docs/chapter4/memory_pool.md
deleted file mode 100644
index 4048648..0000000
--- a/docs/chapter4/memory_pool.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# Memory Pools
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_mempool_init](#function-os_mempool_init)
-* [os_memblock_get](#function-os_memblock_get)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_mempool_init</font>
-
-```
- os_error_t
- os_mempool_init(struct os_mempool *mp, int blocks,
- int block_size, void *membuf, char *name)
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_memblock_get</font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/mutex.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/mutex.md b/docs/chapter4/mutex.md
deleted file mode 100644
index 0e0c329..0000000
--- a/docs/chapter4/mutex.md
+++ /dev/null
@@ -1,150 +0,0 @@
-# Mutex
-
-
-Mutex is short for "mutual exclusion"; a mutex provides mutually exclusive access to a shared resource. A mutex provides *priority inheritance* in order to prevent *priority inversion*. Priority inversion occurs when a higher priority task is waiting on a resource owned by a lower priority task. Using a mutex, the lower priority task will inherit the highest priority of any task waiting on the mutex.
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_mutex_init](#function-os_mutex_init)
-* [os_mutex_release](#function-os_mutex_release)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_mutex_init</font>
-
-```
- os_error_t
- os_mutex_init(struct os_mutex *mu)
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_mutex_release</font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/mynewt_os.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/mynewt_os.md b/docs/chapter4/mynewt_os.md
deleted file mode 100644
index f1865c4..0000000
--- a/docs/chapter4/mynewt_os.md
+++ /dev/null
@@ -1,167 +0,0 @@
-# Mynewt OS
-
-Insert introduction here
-
-## Real-Time Kernel <Modify as you Wish>
-
- Description
-
-## Real-Time OS <Modify as you Wish>
-
- Description
-
-
-## Insert topic of your choice
-
- Description
-
-## Features
-
-<Insert basic feature descriptions, how the various pieces fit together etc., what's special in Mynewt OS>
-
-* [Scheduler/context switching](context_switch.md)
-* [Time](time.md)
-* [Tasks](task.md)
-* [Event queues/callouts](event_queue.md)
-* [Semaphores](semaphore.md)
-* [Mutexes](mutex.md)
-* [Memory pools](memory_pool.md)
-* [Heap](heap.md)
-* [Mbufs](mbufs.md)
-* [Sanity](sanity.md)
-* [Porting OS to other platforms](port_os.md)
-
-## OS Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_idle_task](#function-os_idle_task)
-* [os_started](#function-os_started)
-* add the rest
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_idle_task</font>
-
-```
- void
- os_idle_task(void *arg)
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_started</font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/port_os.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/port_os.md b/docs/chapter4/port_os.md
deleted file mode 100644
index 1331dde..0000000
--- a/docs/chapter4/port_os.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Porting Mynewt OS
-
-
-This chapter describes how to adapt Newt OS to different processors. Adapting μC/OS-III to a microprocessor or a microcontroller is called porting.
-
-
-## Description
-
-
-## Insert sections as you wish
-
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/sanity.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/sanity.md b/docs/chapter4/sanity.md
deleted file mode 100644
index 8b021f4..0000000
--- a/docs/chapter4/sanity.md
+++ /dev/null
@@ -1,150 +0,0 @@
-# Sanity
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_sanity_check_init](#function-os_sanity_check_init)
-* [os_sanity_check_list_lock](#function-os_sanity_check_list_lock)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_sanity_check_init</font>
-
-```
- int
- os_sanity_check_init(struct os_sanity_check *sc)
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_sanity_check_list_lock </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/semaphore.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/semaphore.md b/docs/chapter4/semaphore.md
deleted file mode 100644
index c05a1a8..0000000
--- a/docs/chapter4/semaphore.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Semaphore
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_sem_init](#function-os_sem_init)
-* [os_sem_release](#function-os_sem_release)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_sem_init</font>
-
-```
- os_error_t
- os_sem_init(struct os_sem *sem, uint16_t tokens)
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_sem_release </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/task.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/task.md b/docs/chapter4/task.md
deleted file mode 100644
index 52d6481..0000000
--- a/docs/chapter4/task.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Tasks
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [_clear_stack](#function-_clear_stack)
-* [os_task_next_id](#function-os_task_next_id)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function _clear_stack </font>
-
-```
- static void
- _clear_stack(os_stack_t *stack_bottom, int size)
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_task_next_id </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter4/time.md
----------------------------------------------------------------------
diff --git a/docs/chapter4/time.md b/docs/chapter4/time.md
deleted file mode 100644
index 5daf9e9..0000000
--- a/docs/chapter4/time.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Time
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe OS feature here
-
-## Data structures
-
-Replace this with the list of data structures used, why, any neat features
-
-## List of Functions
-
-<List all the functions here. Note how the anchors work. You put the text you want to show up as a link within [] and the relevant #heading within (). Note that the words of the heading need to be connected with a dash for the anchor to work. Hence the word "function" and the function name is connected with a dash, not underscore! And the header has to have at least 2 words for the anchor to work - that's how it is.>
-
-The functions available in this OS feature are:
-
-* [os_time_get](#function-os_time_get)
-* [os_time_tick](#function-os_time_tick)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function os_time_get </font>
-
-```
- os_time_t
- os_time_get(void)
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function os_time_tick </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
-
-### <font color="#2980b9"> function next_one </font>
-
-```
- <Insert function callout here >
-
-```
-
-<Insert short description>
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| xx | explain argument xx |
-| yy | explain argument yy |
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes
-
-Any special feature/special benefit that we want to tout.
-Does it need to be used with some other specific functions?
-Any caveats to be careful about (e.g. high memory requirements).
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```
-
-<Insert the code snippet here>
-
-```
-
----------------------
\ No newline at end of file