mynewt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ad...@apache.org
Subject [24/45] incubator-mynewt-site git commit: fixed anchors in project Blinky - still need to update Windows instructions for hardware target
Date Wed, 06 Jan 2016 21:56:27 GMT
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter5/bootloader.md
----------------------------------------------------------------------
diff --git a/docs/chapter5/bootloader.md b/docs/chapter5/bootloader.md
deleted file mode 100644
index 381630a..0000000
--- a/docs/chapter5/bootloader.md
+++ /dev/null
@@ -1,148 +0,0 @@
-# Bootloader
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## 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:
-
-* [boot_slot_addr](#function-boot_slot_addr)
-* [boot_find_image_slot](#function-boot_find_image_slot)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function boot_slot_addr </font>
-
-```
-    static void
-    boot_slot_addr(int slot_num, uint8_t *flash_id, uint32_t *address)
-
-```
-
-<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 boot_find_image_slot </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

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter5/console.md
----------------------------------------------------------------------
diff --git a/docs/chapter5/console.md b/docs/chapter5/console.md
deleted file mode 100644
index 4e0bd73..0000000
--- a/docs/chapter5/console.md
+++ /dev/null
@@ -1,546 +0,0 @@
-# Console
-
-
-The console is an operating system window where users interact with system programs of the operating system or a console application by entering text input (typically from a keyboard) and reading text output (typically on the computer terminal). The text written on the console brings some information and is a sequence of characters sent by the OS or programs running on the OS. 
-
-Support is currently available for console access via the serial port on the hardware board.
-
-
-## Description
-
-In the Mynewt OS, the console library comes in two versions:
-
-* full - containing the full implementation
-* stub - containing stubs for the API
-
-If an egg or project requires the full console capability it lists that dependency in its egg.yml file. For example, the shell egg is defined by the following egg.yml file:
-
-    egg.name: libs/shell 
-    egg.vers: 0.1
-    egg.deps:
-        - libs/console/full
-        - libs/os
-    egg.identities:
-        - SHELL 
-
-On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on an egg that has console capability. In that case you would use a console stub. Another example would be the bootloader project where we want to keep the size of the image small. It includes the `libs/os` egg that can print out messages on a console (e.g. if there is a hard fault) and the `libs/util` egg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead and the egg.yml file for the project boot egg looks like the following:
-
-    project.name: boot
-    project.identities: bootloader
-    project.eggs:
-        - libs/os
-        - libs/bootutil
-        - libs/nffs
-        - libs/console/stub
-        - libs/util 
-
-## Data structures
-
-
-Console interaction is intrinsically composed of two unidirectional systems. The console implementation uses two ring buffers containing input (receive) and output (transmit) characters, respectively. Read and write operations on the console_ring structure are managed by labeling the read location indicator the `cr_tail` and the write location indicator the `cr_head`. The console ring length is variable and is specified as the `cr_size` member of the data structure. `cr_buf` is the pointer to the actual array of data contained.
-
-
-```
-struct console_ring {
-  32     uint8_t cr_head;
-  33     uint8_t cr_tail;
-  34     uint8_t cr_size;
-  35     uint8_t _pad;
-  36     uint8_t *cr_buf;
-  37 }
-```
-
-
-```
-struct console_tty {
-  40     struct console_ring ct_tx;
-  41     uint8_t ct_tx_buf[CONSOLE_TX_BUF_SZ]; /* must be after console_ring */
-  42     struct console_ring ct_rx;
-  43     uint8_t ct_rx_buf[CONSOLE_RX_BUF_SZ]; /* must be after console_ring */
-  44     console_rx_cb ct_rx_cb;     /* callback that input is ready */
-  45     console_write_char ct_write_char;
-  46 } console_tty
-```
-
-## List of Functions
-
-The functions available in console are:
-
-* [console_printf](#function-console_printf)
-* [console_add_char](#function-console_add_char)
-* [console_pull_char](#function-console_pull_char)
-* [console_pull_char_head](#function-console_pull_char_head)
-* [console_queue_char](#function-console_queue_char)
-* [console_blocking_tx](#function-console_blocking_tx)
-* [console_blocking_mode](#function-console_blocking_mode)
-* [console_write](#function-console_write)
-* [console_read](#function-console_read)
-* [console_tx_char](#function-console_tx_char)
-* [console_rx_char](#function-console_rx_char)
-* [console_init](#function-console_init)
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function console_printf</font>
-
-```
-    void 
-    console_printf(const char *fmt, ...)
-```
-
-Writes a formatted message instead of raw output to the console. It first composes a C string containing text specified as arguments to the function or containing the elements in the variable argument list passed to it using snprintf or vsnprintf, respectively. It then uses function `console_write` to output the formatted data (messages) on the console.
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| fmt |  Pointer to C string that contains a format string that follows the same specifications as format in printf. The string is printed to console.          |
-| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. va_list is a special type defined in <cstdarg> in stdarg.h. |
-
-#### Returned values
-
-None
-
-#### Notes 
-
-While `console_printf`, with its well understood formatting options in C, is more convenient and easy on the eyes than the raw output of `console_write`, the associated code size is considerably larger.
-
-#### Example
-Example #1:
-
-```
-char adv_data_buf[32];
-    
-void
-task()
-{ 
-   char adv_data_buf[32];
-   
-   console_printf("%s", adv_data_buf);
-}
-```   
-
-Example #2:
-
-```
-struct exception_frame {
-    uint32_t r0;
-    uint32_t r1;
-
-struct trap_frame {
-    struct exception_frame *ef;
-    uint32_t r2;
-    uint32_t r3;
-};
-
-void
-task(struct trap_frame *tf)
-{
-     console_printf(" r0:%8.8x  r1:%8.8x", tf->ef->r0, tf->ef->r1);
-     console_printf(" r8:%8.8x  r9:%8.8x", tf->r2, tf->r3);
-}
-```
-  
----------------------
-   
-### <font color="#2980b9"> function console_add_char</font>
-
-```
-   static void
-   console_add_char(struct console_ring *cr, char ch)
-```
-
-Adds a character to the console ring buffer. When you store an item in the buffer you store it at the head location, and the head advances to the next location.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *cr |  Pointer to a console ring data structure whose `cr_head` variable is to be set to the second argument in this function call|
-| ch |  Character to be inserted to the ring |
-
-#### Returned values
-
-None
-
-#### 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 a new line character to the output (transmit) buffer.
-
-```
-void
-task()
-{
-     struct console_ring *tx = &ct->ct_tx;
-     
-     console_add_char(tx, '\n');
-}
-```
-
--------------------
-
-### <font color="#2980b9"> function console_pull_char </font>
-
-```
-   static uint8_t
-   console_pull_char(struct console_ring *cr)
-```
-
-Reads (remove) a byte from the console ring buffer. When you read (pull) an item, you read it at the current tail location, and the tail advances to the next position. 
-
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| *cr | Pointer to the console ring buffer from where a character is to be removed  |
-
-
-#### Returned values
-
-Returns the character pulled from the ring buffer.
-
-#### 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
-
-Read the characters in the ring buffer into a string.
-
-```
-void
-task(struct console_ring *cr, char *str, int cnt)
-{    
-     for (i = 0; i < cnt; i++) {
-          if (cr->cr_head == cr->cr_tail) {
-              i = -1;
-              break;
-          }
-     ch = console_pull_char(cr);
-     *str++ = ch;
-     }
-}
-```
-
----------------
-      
-### <font color="#2980b9"> function console_pull_char_head </font>
-
-```
-   static void
-   console_pull_char_head(struct console_ring *cr)
-```
-
-Removes the last character inserted into the ring buffer by moving back the head location and shrinking the ring size by 1. 
-  
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| cr |  Pointer to the console ring buffer from which the last inserted character must be deleted |
-
-
-#### Returned values
-
-None
-
-#### 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
-
-In order to see a character getting deleted when a user hits backspace while typying a command, the following needs to happen in sequence:
-
-* output a backspace (move cursor back one character)
-* output space (erasing whatever character there was before)
-* output backspace (move cursor back one character)
-* remove the previous character from incoming RX queue
-
-The example below shows console_pull_char_head being used for the last step.
-
-```
-void
-task(uint8_t data)
-{
-      struct console_tty *ct = (struct console_tty *)arg;
-      struct console_ring *tx = &ct->ct_tx;
-      struct console_ring *rx = &ct->ct_rx;
-      
-      switch (data) {
-      case '\b':
-          console_add_char(tx, '\b');
-          console_add_char(tx, ' ');
-          console_add_char(tx, '\b');
-          console_pull_char_head(rx);
-          break;
-      }
-}
-
-```
-
--------------
-
-### <font color="#2980b9"> function console_queue_char </font>
-
-``` 
-   static void
-   console_queue_char(char ch)
-```
-   
-Manage the buffer queue before inserting a character into it. If the head of the output (transmit) console ring is right up to its tail, the queue needs to be drained first before any data can be added. Then it uses console_add_char function to add the character.
-
-#### Arguments
-
-| Arguments | Description |
-|-----------|-------------|
-| ch |  Character to be inserted to the queue  |
-
-
-#### Returned values
-
-List any values returned.
-Error codes?
-
-#### Notes 
-
-This function makes sure no interrupts are allowed while the transmit buffer is draining and the character is being added.
-
-#### Example
-
-```
-Insert example
-``` 
-------------------
- 
-### <font color="#2980b9"> function console_blocking_tx </font>
-
-```
-    static void
-    console_blocking_tx(char ch)
-```
-    
-  Calls the hal function hal_uart_blocking_tx to transmit a byte to the console over UART in a blocking mode until the character has been sent. Hence it must be called with interrupts disabled. It is used when printing diagnostic output from system crash. 
-
-#### 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
-
-Give at least one example of usage.
-
------------
-
-### <font color="#2980b9"> function console_blocking_mode </font>
-
-```
-   void
-   console_blocking_mode(void)
-```
-   Calls the console_blocking_tx function to flush the buffered console output (transmit) queue. The function OS_ENTER_CRITICAL() is called to disable interrupts and OS_EXIT_CRITICAL() is called to enable interrupts back again once the buffer is flushed.
-
-#### 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
-
-Give at least one example of usage.
-
-
-### <font color="#2980b9">function console_write </font>
- 
-```
-   void
-   console_write(char *str, int cnt)
-```
-Transmit characters to console display over serial port. 
-
-#### 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
-
-Give at least one example of usage.
-
-
-### <font color="#2980b9"> function console_read </font>
-
-```   
-  int
-  console_read(char *str, int cnt)
-```
-  Calls hal function hal_uart_start_rx to start receiving input from console terminal over serial port.
-
-#### 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
-
-Give at least one example of usage.
-
-
-### <font color="#2980b9"> function console_tx_char </font>
-
-   ```   
-   static int
-   console_tx_char(void *arg)
-   ```
-
-#### 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
-
-Give at least one example of usage.
-
-  
-### <font color="#2980b9"> function console_rx_char </font>
-
-```
-   static int
-   console_rx_char(void *arg, uint8_t data)
-```
-
-#### 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
-
-Give at least one example of usage.
-
-
-### <font color="#2980b9"> function console_init </font>
-
-```
-   int
-   console_init(console_rx_cb rx_cb)
-```
-   
-  Initializes console receive buffer and calls hal funtions hal_uart_init_cbs and hal_uart_config to initialize serial port connection and configure it (e.g. baud rate, flow control etc.)
-   
-#### 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
-
-Give at least one example of usage.

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter5/filesystem.md
----------------------------------------------------------------------
diff --git a/docs/chapter5/filesystem.md b/docs/chapter5/filesystem.md
deleted file mode 100644
index dc1ad43..0000000
--- a/docs/chapter5/filesystem.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# Filesystem
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## 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:
-
-* [nffs_lock](#function-nffs_lock)
-* [nffs_unlock](#function-nffs_unlock)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function nffs_lock </font>
-
-```
-    static void
-    nffs_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 nffs_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>
-
-```
-
----------------------
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter5/shell.md
----------------------------------------------------------------------
diff --git a/docs/chapter5/shell.md b/docs/chapter5/shell.md
deleted file mode 100644
index 1b2928a..0000000
--- a/docs/chapter5/shell.md
+++ /dev/null
@@ -1,147 +0,0 @@
-# Shell
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## 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:
-
-* [shell_cmd_list_lock](#function-shell_cmd_list_lock)
-* [shell_cmd_list_unlock](#function-shell_cmd_list_unlock)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function shell_cmd_list_lock </font>
-
-```
-    static int 
-    shell_cmd_list_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 shell_cmd_list_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/chapter5/testutil.md
----------------------------------------------------------------------
diff --git a/docs/chapter5/testutil.md b/docs/chapter5/testutil.md
deleted file mode 100644
index 601ed02..0000000
--- a/docs/chapter5/testutil.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# testutil
-
-
-Insert synopsis here
-
-
-## Description
-
-Describe module here, special features, how pieces fit together etc.
-
-## 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:
-
-* [tu_init](#function-tu_init)
-* [tu_restart](#function-tu_restart)
-* add the rest
-
-
-## Function Reference
-
-------------------
-
-### <font color="2980b9">function tu_init </font>
-
-```
-    int
-    tu_init(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 tu_restart </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

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/chapter6/dist.md
----------------------------------------------------------------------
diff --git a/docs/chapter6/dist.md b/docs/chapter6/dist.md
deleted file mode 100644
index e69de29..0000000

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/get_acclimated/pics/STM32f3discovery_connector.png
----------------------------------------------------------------------
diff --git a/docs/get_acclimated/pics/STM32f3discovery_connector.png b/docs/get_acclimated/pics/STM32f3discovery_connector.png
new file mode 100644
index 0000000..1f4437a
Binary files /dev/null and b/docs/get_acclimated/pics/STM32f3discovery_connector.png differ

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/get_acclimated/project2.md
----------------------------------------------------------------------
diff --git a/docs/get_acclimated/project2.md b/docs/get_acclimated/project2.md
new file mode 100644
index 0000000..3a6e5a6
--- /dev/null
+++ b/docs/get_acclimated/project2.md
@@ -0,0 +1,374 @@
+## 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)
+
+* ![STMdiscovery](pics/STM32f3discovery_connector.png)
+
+        
+        [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/get_acclimated/project3.md
----------------------------------------------------------------------
diff --git a/docs/get_acclimated/project3.md b/docs/get_acclimated/project3.md
new file mode 100644
index 0000000..43e6a59
--- /dev/null
+++ b/docs/get_acclimated/project3.md
@@ -0,0 +1 @@
+## How to Test an Egg

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/get_acclimated/vocabulary.md
----------------------------------------------------------------------
diff --git a/docs/get_acclimated/vocabulary.md b/docs/get_acclimated/vocabulary.md
new file mode 100644
index 0000000..5e6b792
--- /dev/null
+++ b/docs/get_acclimated/vocabulary.md
@@ -0,0 +1,170 @@
+## 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/get_started/how_to_edit_docs.md
----------------------------------------------------------------------
diff --git a/docs/get_started/how_to_edit_docs.md b/docs/get_started/how_to_edit_docs.md
new file mode 100644
index 0000000..69c7743
--- /dev/null
+++ b/docs/get_started/how_to_edit_docs.md
@@ -0,0 +1,187 @@
+## How to Edit Docs  
+
+### Objective
+
+We will go through the process of downloading existing doccumentation and adding some content to a test document.
+
+### Markdown, MkDocs, Mou
+
+The Mynewt documentation you see on the Apache incubator website is a bunch of HTML files generated using MkDocs which is a simple static site generation tool geared towards building project documentation. You can read about it at [http://www.mkdocs.org](http://www.mkdocs.org). Documentation source files are written in Markdown, and configured with a single YAML configuration file. Markdown is a lightweight markup language with plain text formatting syntax designed so that it can be converted to HTML and many other formats using a tool (which in our case is MkDocs).
+
+You do not need to install MkDocs unless you want to actually render your documentation in HTML in order to preview it before pushing your content to the remote repository. Typically, using a Markdown editor such as [Mou](http://25.io/mou/) is enough to check how it will look after the document has gone through MkDocs. Go ahead and download [Mou](http://25.io/mou/). If you are on a Windows machine, download the [editor of your choice](http://alternativeto.net/software/mou/?platform=windows).
+
+Currently someone in the project is designated to use MkDocs to generate the HTML pages periodically after changes have been reviewed and accepted into the master branch.
+
+
+### Access to the Apache repo
+
+Get an account on Apache. You do not need a committer account to view the website or clone the repository but you need it to push changes to it.
+
+If you are not a committer, you may follow the proposed non-committer workflow to share your work. The direct link to the proposed workflow is [https://git-wip-us.apache.org/docs/workflow.html](https://git-wip-us.apache.org/docs/workflow.html). You will find the steps described in more detail later in this tutorial.
+
+### Making a local copy
+
+* Copy the document source files into a local directory and look at the contents of the copied directory to get an idea of the directory structure. Use http instead of https if you are a non-committer.
+
+        $ git clone https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git
+        Cloning into 'incubator-mynewt-site'...
+        remote: Counting objects: 330, done.
+        remote: Compressing objects: 100% (263/263), done.
+        remote: Total 330 (delta 120), reused 0 (delta 0)
+        Receiving objects: 100% (330/330), 4.34 MiB | 830.00 KiB/s, done.
+        Resolving deltas: 100% (120/120), done.
+        Checking connectivity... done.
+        $ ls
+        incubator-mynewt-site
+        $ ls incubator-mynewt-site/
+        docs		images		mkdocs.yml
+        
+* Create a new branch to work on your documentation and move to that branch.
+
+        $ git checkout -b <your-branch-name>
+
+
+### File to be edited
+
+The file you will edit is [try_markdown.md](./try_markdown.md).
+
+### Editing an existing page 
+
+* Open the application Mou.
+
+* Open the file incubator-mynewt-site/docs/get_started/try_markdown.md in Mou.
+
+* Edit the last item on the list.
+
+* Save and quit the application.
+
+You may want to review the documentation organization back in [Home](../index.md) to remind you how to locate files easily. The corresponding directory tree structure is shown below.
+
+      .
+      ├── docs
+      │   ├── get_started 
+      │   │   ├── how_to_edit_docs.md
+      │   │   ├── newt_concepts.md
+      │   │   ├── pics
+      │   │   │   ├── bottomview.png
+      │   │   │   └── topview.png
+      │   │   ├── project1.md
+      │   │   └── try_markdown.md
+      │   ├── get_acclimated
+      │   │   ├── project2.md
+      │   │   ├── project3.md
+      │   │   ├── ... (more to be added)
+      │   │   └── vocabulary.md
+      │   ├── newt
+      │   │   ├── newt_ops.md
+      │   │   └── newt_tool_reference.md
+      │   ├── os
+      │   │   ├── context_switch.md
+      │   │   ├── event_queue.md
+      │   │   ├── heap.md
+      │   │   ├── mbufs.md
+      │   │   ├── memory_pool.md
+      │   │   ├── mutex.md
+      │   │   ├── mynewt_os.md
+      │   │   ├── port_os.md
+      │   │   ├── sanity.md
+      │   │   ├── semaphore.md
+      │   │   ├── task.md
+      │   │   ├── time.md
+      │   │   └── ... (more to be added)
+      │   ├── modules
+      │   │   ├── bootloader.md
+      │   │   ├── console.md
+      │   │   ├── filesystem.md
+      │   │   ├── shell.md
+      │   │   ├── testutil.md
+      │   │   └── ... (more to be added)
+      │   ├── packaging
+      │   │   ├── dist.md
+      │   │   └── ... (more to be added)
+      │   ├── extra.css
+      │   ├── images
+      │   │   └── egg-logo.png
+      │   └── index.md
+      ├── images
+      │   ├── asf_logo_wide.gif
+      │   ├── content-bg.png
+      │   └── egg-logo.png
+      ├── mkdocs.yml
+
+
+### Adding a new page
+
+If you create a new file somewhere in the `docs` subdirectory to add a new page, you have to add a line in the `mkdocs.yml` file at the correct level. For example, if you add a new module named "Ethernet" by creating a new file named `ethernet.md` in the `modules` subdirectory, you have to insert the following line under `Modules:` in the `mkdocs.yml` file.
+
+        - 'Ethernet': 'modules/ethernet.md'
+
+### Pushing changes to remote as a committer
+
+If you are not a committer yet, skip this section and proceed to the [next section](#sharing-changes-as-a-non-committer).
+
+* Check whether your remote git repository is set up. If you see the remote location as shown below you can skip the next step.
+
+        $ git remote -v
+        origin	https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git (fetch)
+        origin	https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git (push)
+
+* If, however, you do not see your remote repository, then set it up as follows.
+
+
+        $ git remote add origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git 
+       
+* First check the git status. It will show you that the `try_markdown.md` document has been modified. So you will stage a commit, and then commit the change. Finally, you will push the changes to the remote repository. 
+
+  During staging below using `git add`, we use the `-A` option indicating you want to stage all your modifications. Instead, you can choose to specify only the files that you want to. The commit message (specified after `-m`) should summarize what your changes are about.
+
+        $ git status
+        $ git add -A 
+        $ git commit -m "My first doc change as a trial run"
+        $ git push -u origin <your-branch-name>
+        
+* You can see the changed Markdown file if you traverse the tree on the git repository [ https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git]( https://git-wip-us.apache.org/repos/asf/incubator-mynewt-site.git).
+
+* A commit notification automatically goes out to the commits@mynewt.incubator.apache.org mailing list. The "upstream" manager pulls the notified changes, reviews it, and merges it to the master branch if all is well. Otherwise you get an email for further changes.
+
+### Sharing changes as a non-committer
+
+We suggest you follow the proposed non-committer workflow at Apache to share your work. The direct link to the proposed workflow is [https://git-wip-us.apache.org/docs/workflow.html](https://git-wip-us.apache.org/docs/workflow.html). 
+
+* Assuming you have made changes to the example file, you will first commit your changes.
+
+        $ git add -A 
+        $ git commit -m "My first doc change as a trial run"
+
+* Once you're ready to share your changes with the rest of the project team, you can use the git format-patch command to produce a patch file (or a nice set of patches in the future):
+
+        $ git format-patch origin/trunk
+        
+* Email the patch file to dev@mynewt.incubator.apache.org. Later on you may attach multiple files in your email to the mailing list as part of an existing thread or a new one. Remember to summarize the issue you have tackled and your work if the commit message is not detailed enough. 
+
+   If there is a JIRA ticket associated with your work you should post your patch files to the ticket.
+
+
+### Conversion to HTML
+
+The conversion of the Markdown files to HTML for the website happens manually and statically using MkDocs. You cannot see automatic and immediate rendering in HTML upon making a change in the Markdown file. You can choose to stop here and proceed to changing other Markdown files in your branch.
+
+### Local preview of HTML files
+
+However, you have the option to download MkDocs and do a local conversion yourself to preview the pages using the built-in devserver that comes with MkDocs. But first you will have to install MkDocs for that. In order to install MkDocs you'll need Python installed on your system, as well as the Python package manager, pip. You can check if you have them already (usually you will).
+
+        $ python --version
+        Python 2.7.2
+        $ pip --version
+        pip 1.5.2
+        $ pip install mkdocs
+
+You will then run the built-in webserver from the root of the documentation directory using the command `mkdocs serve`. The root directory for documentation is `incubator-mynewt-site` or the directory with the `mkdocs.yml` file.
+
+        $ ls
+        docs		images		mkdocs.yml
+        $ mkdocs serve
+        
+Then go to [http://127.0.0.1:8000](http://127.0.0.1:8000) to preview your pages and see how they will look on the website! Remember that the Myself website itself will not be updated.
+        
+For more information on MkDocs go to [http://www.mkdocs.org](http://www.mkdocs.org). 

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/get_started/newt_concepts.md
----------------------------------------------------------------------
diff --git a/docs/get_started/newt_concepts.md b/docs/get_started/newt_concepts.md
new file mode 100644
index 0000000..6ac28da
--- /dev/null
+++ b/docs/get_started/newt_concepts.md
@@ -0,0 +1,48 @@
+## Newt Concepts
+
+This page introduces the basic terms you will need to find your way around the Mynewt ecosystem.
+
+### Basic components in the ecosystem
+
+* NewtOS is an open-source RTOS (Real Time Operating System) that works on a variety of hardware. The goal is to develop a pre-emptive, multitasking OS that is highly modular, making it possible to mix and match components to enable desired features and capabilities on multiple hardware architectures. Examples of components being worked on are the Core RTOS, a flash file system, utility functions, a variety of board support packages, packages of microcontrollers etc.
+
+
+* Network protocol stacks such as Bluetooth Low Energy, and more
+
+
+* Newt Tool helps you mix the specific packages for the combination of hardware and low-level embedded architecture features of the user's choice and generate the corresponding run-time image based on the NewtOS. It provides the infrastructure to manage and build for different CPU architectures, memory units, board support packages etc., allowing a user to formulate the contents according to the low-level features needed by his or her project.
+
+
+### Terminology
+
+A Mynewt user starts with a project in mind that defines the application or utility that he or she wants to implement on an embedded device. Making an LED blink on an electronics prototyping board is a common starter project. Enabling a BLE (Bluetooth Low Energy) peripheral mode on a development board is a more complex project. Specifying a project requires naming it, at the very least, and then adding the desired properties or attributes. In order to actualize a project, it needs to be applied to a target which is essentially a combination of some specified hardware and the execution environment. 
+
+In the mynewt lifecycle, a project grows in a nest. A nest may house multiple projects. The nest is, therefore, a repository where various component packages for one or more projects reside. Each package is an egg (naturally!). However, in the world of Mynewt an egg may consist of other eggs! For example, the starter project Blinky is an egg consisting of several constituent eggs that enable core features. The egg form is suitable for elemental units of code as it explicitly exposes characteristics such as dependencies, versions, capabilities, requirements etc., thus making assembling appropriate components for a project and building an image for it easy to follow, modular, and robust.
+
+A nest can be given any name. For example, you will see a nest named "tadpole" in Mynewt ([https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-tadpole.git](https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-tadpole.git)). It contains all the core libraries of the operating system for the native platform which currently supports compilation on Mac OS X. The core libraries are contained in the form of eggs where an egg is a basic unit of implementation of any aspect of the RTOS. The eggs are distributed in the following directory structure inside the nest:
+
+* libs: contains the two eggs `os` and `testutil`
+* hw: contains three eggs - (i) `hal` which has the abstraction layer (HAL) API definitions that all BSP and MCU implementations must support, (ii) `/mcu/native` which in an MCU implementation for the native platform (a simulator, in this case), and (iii) `bsp/native` which is a BSP implementation for the native platform 
+* compiler: contains the `sim` egg which bundles the compiler specifications for the native platform.
+
+Let's explore this sample nest a bit further. The `libs/os` egg contains code for scheduler, process/thread/memory management, semaphores etc. It is the core RTOS which ports to all supported chip platforms.The `libs/testutil` egg contains code for testing packages on hardware or simulated environment. The `hw/hal` egg contains header files that provide abstraction for physical hardware components such as GPIO (general purpose input/output), network adapters, timers, and UARTs. This `hw/hal` egg is an MCU peripheral abstraction designed to make it easy to port to different MCUs (microcontrollers). The `hw/mcu/native` egg contains code for microcontroller operations on the native platform. The `hw/bsp/native` egg contains the board support package for the native platform. And finally, the sixth egg `sim` contains the compiler specifications such as path and flags. Currently the compilation is supported on Mac OS X.
+
+You can see another nest in the mynewt ecosystem called the "larva". It was spawned from the skeletal "tadpole" nest using the newt tool. Spawning is easy - ` $ newt create nest <your_nest_name> `. "larva" is the developer's test repository containing all sorts of eggs being written and incubated, including ones to enhance the core operating system which should eventually make their way into the "tadpole" nest. There is a `hatch_tadpole` script to update the "tadpole" nest when the core OS related eggs in "larva" are ready.
+
+There is a third nest named "newt" that contains all the eggs needed to support the build and release process of mynewt software. In the future, there will also be pre-built nests for certain common hardware devices to enable a user to quickly get started with a project.
+
+
+### A Mynewt contributor
+
+A contributor can choose to work on any area(s) of the Mynewt endeavor that appeals to him or her. Hence, you can work on one or more eggs or an entire nest. You can create your own nest (master) or create a branch in an existing nest. For now, Runtime contributors will review any new areas of support that you may wish to introduce e.g. a new board support package (BSP) or a new network protocol. 
+
+A contributer role necessarily implies he or she is a Mynewt user (see below) of some or all of the products developed.
+
+### A Mynewt user 
+
+An application developer is interested only in using software available in this ecosystem to build a top level build artifact. He or she may either:
+
+* Use a pre-built nest, or
+* Spawn a new nest using the newt tool for a target where a target is a custom combination of supported hardware components
+
+In either case, the user would use the newt tool to create and set the target in the chosen nest. The newt tool would then be used to build out the target profile which would determine which eggs to choose. Finally, the user would use the newt tool to generate a run-time image that can be run on the device.

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/get_started/pics/bottomview.png
----------------------------------------------------------------------
diff --git a/docs/get_started/pics/bottomview.png b/docs/get_started/pics/bottomview.png
new file mode 100644
index 0000000..fb7bf0a
Binary files /dev/null and b/docs/get_started/pics/bottomview.png differ

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/8aced2b5/docs/get_started/pics/topview.png
----------------------------------------------------------------------
diff --git a/docs/get_started/pics/topview.png b/docs/get_started/pics/topview.png
new file mode 100644
index 0000000..e57995e
Binary files /dev/null and b/docs/get_started/pics/topview.png differ


Mime
View raw message