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/11/05 04:47:36 UTC

[15/50] incubator-mynewt-site git commit: fix more links

fix more links


Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/commit/5c00cfff
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/5c00cfff
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/5c00cfff

Branch: refs/heads/master
Commit: 5c00cfff4e6643ce6510b81c789f19c0b24eb5d6
Parents: bbbda53
Author: Gavin Jefferies <ga...@runtime.io>
Authored: Fri Oct 7 16:27:10 2016 -0700
Committer: Gavin Jefferies <ga...@runtime.io>
Committed: Fri Oct 7 16:30:32 2016 -0700

----------------------------------------------------------------------
 README.md                                       |  6 +-
 build.py                                        | 21 +++++-
 custom-theme/base.html                          |  3 +-
 docs/network/ble/ini_stack/ble_parent_ini.md    |  2 +-
 docs/os/core_os/time/os_time_tick.md            |  8 +--
 .../os/modules/hal/hal_cputime/hal_cpu_timer.md | 14 ++--
 docs/os/modules/hal/hal_gpio/hal_gpio.md        | 19 +++---
 docs/os/tutorials/blinky_sram_olimex.md         | 41 ++++++------
 docs/os/tutorials/olimex.md                     | 56 ++++++++--------
 docs/os/tutorials/project-target-slinky.md      | 38 ++++-------
 docs/os/tutorials/tutorials.md                  | 21 +++---
 docs/os/tutorials/wi-fi_on_arduino.md           | 70 ++++++++++----------
 12 files changed, 151 insertions(+), 148 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/README.md
----------------------------------------------------------------------
diff --git a/README.md b/README.md
index dc61b4e..6351d8c 100644
--- a/README.md
+++ b/README.md
@@ -44,5 +44,9 @@ When a new release of MyNewt OS and its associated tools occurs, the documentati
 
 For the deployed site a version prefix is added to the URL for each mkdocs page. When developing there is no version prefix. If you want to link from a _site page_ to a _documentation page_ you should prefix the URL with */DOCSLINK/* so that the user is taken to the correct location when browsing in production.
 
+## Link Checking
 
-
+1. Grab a link checking tool like [Integrity](http://peacockmedia.software/mac/integrity/free.html)
+1. Run: `./build.py --test-build`
+1. Run: `./serve.py`
+1. point the link checker at http://localhost:8000/

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/build.py
----------------------------------------------------------------------
diff --git a/build.py b/build.py
index b392523..e1fc469 100755
--- a/build.py
+++ b/build.py
@@ -9,9 +9,14 @@ import fileinput
 
 @click.command()
 @click.option('-s', '--site-branch', default='master', help='Use this branch as source for the top level pages')
+@click.option('-t', '--test-build', is_flag=True, help='Test the build using only the working directory (good for testing for broken links)')
+def build(site_branch, test_build):
+    if test_build:
+        buildForTest()
+    else:
+        buildForReal(site_branch)
 
-def build(site_branch):
-
+def buildForReal(site_branch):
     # make sure there are no local mods outstanding
     repo = Repo(os.getcwd())
     if repo.is_dirty() or repo.untracked_files:
@@ -48,8 +53,18 @@ def build(site_branch):
         mygit.checkout(version['branch'])
         deployVersion(version)
 
+def buildForTest():
+    print "Building site pages..."
+    updateConfigVersion('develop')
+    sh.rm('-rf', 'site')
+    sh.mkdocs('build', '--clean')
+    sh.git('checkout', '--', 'mkdocs.yml')
+
+    cfg = config.load_config()
+    for version in cfg['extra']['versions']:
+        deployVersion(version)
+
 def deployVersion(version):
-    mygit.checkout(version['branch'])
     buildTo(version['branch'])
     if version['latest']:
         buildTo('latest')

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/custom-theme/base.html
----------------------------------------------------------------------
diff --git a/custom-theme/base.html b/custom-theme/base.html
index 04b6513..20831ad 100644
--- a/custom-theme/base.html
+++ b/custom-theme/base.html
@@ -6,7 +6,8 @@
         <meta name="viewport" content="width=device-width, initial-scale=1.0">
         {% if page_description %}<meta name="description" content="{{ page_description }}">{% endif %}
         {% if site_author %}<meta name="author" content="{{ site_author }}">{% endif %}
-        {% if canonical_url %}<link rel="canonical" href="{{ canonical_url }}">{% endif %}
+        <!-- This is broken by doc revisioning.
+        {% if canonical_url %}<link rel="canonical" href="{{ canonical_url }}">{% endif %} -->
         {% if favicon %}<link rel="shortcut icon" href="{{ favicon }}">
         {% else %}<link rel="shortcut icon" href="{{ base_url }}/img/favicon.ico">{% endif %}
 

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/network/ble/ini_stack/ble_parent_ini.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_parent_ini.md b/docs/network/ble/ini_stack/ble_parent_ini.md
index 463a6f0..6928ef5 100644
--- a/docs/network/ble/ini_stack/ble_parent_ini.md
+++ b/docs/network/ble/ini_stack/ble_parent_ini.md
@@ -6,7 +6,7 @@ application-specific work, the host parent task does work for NimBLE by
 processing events generated by the host.
 
 The process of creating an OS task is described in the [Add Task
-tutorial](../../../../os/tutorials/event_queue/).
+tutorial](../../../os/tutorials/event_queue/).
 
 **Priority:**
 It is up to you which priority to use for the host parent task.  Unlike the

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/os/core_os/time/os_time_tick.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time_tick.md b/docs/os/core_os/time/os_time_tick.md
index 420aa23..1c217e1 100644
--- a/docs/os/core_os/time/os_time_tick.md
+++ b/docs/os/core_os/time/os_time_tick.md
@@ -1,10 +1,10 @@
 ## <font color="F2853F" style="font-size:24pt">os_time_tick</font>
 
 ```c
-void os_time_tick(void) 
+void os_time_tick(void)
 ```
 
-Increments the OS time tick for the system.  Typically, this is called in one place by the architecture specific OS code (`libs/os/arch`) `timer_handler` which is in turn called by the BSP specific code assigned to drive the OS timer tick. See [Porting Mynewt OS](../port_os) for details.
+Increments the OS time tick for the system.  Typically, this is called in one place by the architecture specific OS code (`libs/os/arch`) `timer_handler` which is in turn called by the BSP specific code assigned to drive the OS timer tick. See [Porting Mynewt OS](../porting/port_os) for details.
 
 #### Arguments
 
@@ -14,7 +14,7 @@ N/A
 
 N/A
 
-#### Notes 
+#### Notes
 
 Called for every single tick by the architecture specific functions.
 
@@ -25,5 +25,3 @@ Called for every single tick by the architecture specific functions.
 ```c
    os_time_tick();
 ```
-
-

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md b/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md
index 99fa830..d430dfc 100644
--- a/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md
+++ b/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md
@@ -7,7 +7,7 @@ The hardware independent interface to system time.
 
 Contains several different interface.
 
-* An interface to get the current CPU time 
+* An interface to get the current CPU time
 * Interfaces to convert between CPU time and clock time (microseconds etc.)
 * An Interface to set up a software timer based on CPU time.
 
@@ -17,15 +17,13 @@ Contains several different interface.
 
 ###CPU Time
 
-The CPU time is not the same as the [os_time](TBD).  Typically,
+The CPU time is not the same as the [os_time]().  Typically,
 the os_time is set to a much slower tick rate than the CPU time.  The CPU
 time should be used for timing real-time events at exact times.  The os_time
-should be used for system level timeout etc that are not in fine time 
+should be used for system level timeout etc that are not in fine time
 resolutions.  In fact, cputime is not part of the os at all, but a hardware
-layer abstraction to high resolution timers. 
+layer abstraction to high resolution timers.
 
-There are methods to get the cputime as 32-bit and 64-bit values.  Both 
+There are methods to get the cputime as 32-bit and 64-bit values.  Both
 values may eventually wrap, but for timing short events a 32-bit value
-may be sufficient and would 
-
- 
+may be sufficient and would

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/os/modules/hal/hal_gpio/hal_gpio.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_gpio/hal_gpio.md b/docs/os/modules/hal/hal_gpio/hal_gpio.md
index 5518bc8..a8d6af6 100644
--- a/docs/os/modules/hal/hal_gpio/hal_gpio.md
+++ b/docs/os/modules/hal/hal_gpio/hal_gpio.md
@@ -8,20 +8,20 @@ This is the hardware independent GPIO (General Purpose Input Output) Interface f
 Contains the basic operations to set and read General Purpose Digital I/O Pins
 within a Mynewt system.
 
-Individual GPIOs are referenced in the APIs as `pins`. However, in this interface the `pins` are virtual GPIO pins. The MCU hal driver maps these virtual `pins` to the physical GPIO ports and pins. 
+Individual GPIOs are referenced in the APIs as `pins`. However, in this interface the `pins` are virtual GPIO pins. The MCU hal driver maps these virtual `pins` to the physical GPIO ports and pins.
 
 Typically, the BSP code may define named I/O pins in terms of these virtual `pins` to describe the devices attached to the physical pins.
 
 Here's a brief example so you can get the gist of the translation.
 
-Suppose my product uses the stm32F4xx processor.  There already exists support for this processor within Mynewt.  The processor has N ports (A,B,C..) of 16 GPIO pins per port.   The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 and so on.  The exact number of physical port (and virtual 
+Suppose my product uses the stm32F4xx processor.  There already exists support for this processor within Mynewt.  The processor has N ports (A,B,C..) of 16 GPIO pins per port.   The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 and so on.  The exact number of physical port (and virtual
 port pins) depends on the specific variant of the stm32F4xx.  
 
-So if I want to turn on port B pin 3, that would be virtual pin  1*16 + 3 = 19. 
-This translation is defined in the MCU implementation of 
-[hal_gpio.c](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/mcu/stm/stm32f4xx/src/hal_gpio.c) 
-for the stmf32F4xx.  Each MCU will typically have a different translation method 
-depending on its GPIO architecture. 
+So if I want to turn on port B pin 3, that would be virtual pin  1*16 + 3 = 19.
+This translation is defined in the MCU implementation of
+[hal_gpio.c](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/mcu/stm/stm32f4xx/src/hal_gpio.c)
+for the stmf32F4xx.  Each MCU will typically have a different translation method
+depending on its GPIO architecture.
 
 Now, when writing a BSP, it's common to give names to the relevant port pins that you are using.  Thus, the BSP may define a mapping between a function and a virtual port pin.  For example
 
@@ -46,11 +46,10 @@ SYSTEM_LED --> hal_gpio virtual pin 37 --> port C pin 5 on the stm34F4xx
 
 #### Blinky
 
-Blinky uses the hal_gpio to blink the system LED.  The blinky source code is available 
-[here](https://github.com/apache/incubator-mynewt-larva/blob/master/project/blinky/src/main.c).
+Blinky uses the hal_gpio to blink the system LED.  The blinky source code is available
+[here](https://github.com/apache/incubator-mynewt-core/blob/master/apps/blinky/src/main.c).
 Examine how `task1_handler` initializes and toggles the GPIO to control the LED.
 
 <br>
 
 ---------------------
-

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/os/tutorials/blinky_sram_olimex.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/blinky_sram_olimex.md b/docs/os/tutorials/blinky_sram_olimex.md
index dd2439d..3bd5750 100644
--- a/docs/os/tutorials/blinky_sram_olimex.md
+++ b/docs/os/tutorials/blinky_sram_olimex.md
@@ -6,12 +6,12 @@ To download an application image directly into the embedded SRAM in the microcon
 
 ### What you need
 
-1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
+1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeySTM32-E407), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
 2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
 3. USB A-B type cable to connect the debugger to your personal computer
 4. Personal Computer with Mac OS (Mac: OS X Yosemite Version 10.10.5) or Linux box (Ubuntu 14.10: Utopic Unicorn)
 5. An account on Github repository and *git* installed on your computer.
-6. It is assumed you have already installed newt tool. 
+6. It is assumed you have already installed newt tool.
 7. It is assumed you already installed native tools as described [here](../get_started/native_tools.md)
 
 Also, we assume that you're familiar with UNIX shells. Let's gets started!
@@ -21,13 +21,13 @@ Also, we assume that you're familiar with UNIX shells. Let's gets started!
 
 ### Prepare the Software
 
-* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory. 
- 
+* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory.
+
 <br>
 
 ### Create a project  
 
-Create a new project to hold your work.  For a deeper understanding, you can read about project creation in 
+Create a new project to hold your work.  For a deeper understanding, you can read about project creation in
 [Get Started -- Creating Your First Project](../get_started/project_create.md)
 or just follow the commands below.
 
@@ -41,15 +41,15 @@ or just follow the commands below.
 
     $cd myproj
 
-    $ newt install -v 
+    $ newt install -v
     apache-mynewt-core
     Downloading repository description for apache-mynewt-core... success!
     ...
     apache-mynewt-core successfully installed version 0.7.9-none
-``` 
+```
 
 <br>
-   
+
 ### Create a target
 
 Change directory to ~/dev/myproj directory and define the *blinky* target inside myproj, using the *newt* tool. Starting with the target name, assign specific aspects of the project, as shown below, to pull the appropriate packages and build the right bundle or list for the board. For example, we set the build_profile, board support package (bsp), and app.
@@ -71,11 +71,11 @@ Change directory to ~/dev/myproj directory and define the *blinky* target inside
 
 ### Build the image
 
-Next, let's build the image for the above target. By default, the linker script within the `hw/bsp/olimex_stm32-e407_devboard` package builds an image for flash memory, which we don't want; instead, we want an image for the SRAM, so you need to switch that script with `run_from_sram.ld`. 
+Next, let's build the image for the above target. By default, the linker script within the `hw/bsp/olimex_stm32-e407_devboard` package builds an image for flash memory, which we don't want; instead, we want an image for the SRAM, so you need to switch that script with `run_from_sram.ld`.
+
+Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.*
+
 
-Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.* 
-    
-    
 ```no-highlight
     $ cd ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/
     $ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
@@ -106,12 +106,12 @@ Afer you build the target, you can find the executable *blinky.elf* in the proje
 
 <br>
 
-* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present. 
+* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present.
 To locate the bootloader, the board searches in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we will configure it to boot from SRAM by jumpering **B0_1** and **B1_1**.
 
-* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board). 
+* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
 
-* The red PWR LED should be lit. 
+* The red PWR LED should be lit.
 
 * Connect the JTAG connector to the SWD/JTAG interface on the board. The other end of the cable should be connected to the USB port or hub of your computer.
 
@@ -133,7 +133,7 @@ To locate the bootloader, the board searches in three places: User Flash Memory,
     (info)
     ...
     target state: halted
-    target halted due to debug-request, current mode: Thread 
+    target halted due to debug-request, current mode: Thread
     xPSR: 0x01000000 pc: 0x080003c0 msp: 0x10010000
     Info : accepting 'gdb' connection on tcp/3333
     Info : device id = 0x10036413
@@ -141,15 +141,15 @@ To locate the bootloader, the board searches in three places: User Flash Memory,
 ```
 <br>
 
-Check the value of the msp (main service pointer) register. If it is not 0x10010000 as indicated above, you will have to manually set it after you open the gdb tool and load the image on it. For example, 
-   
+Check the value of the msp (main service pointer) register. If it is not 0x10010000 as indicated above, you will have to manually set it after you open the gdb tool and load the image on it. For example,
+
 ```no-highlight
     (gdb) set $msp=0x10010000
 ```
 
 <br>
 
-   Now load the image and type "c" or "continue" from the GNU debugger. 
+   Now load the image and type "c" or "continue" from the GNU debugger.
 
 ```no-highlight           
     (gdb) load ~/dev/myproj/bin/blinky/apps/blinky/blinky.elf   
@@ -161,8 +161,7 @@ Check the value of the msp (main service pointer) register. If it is not 0x10010
     (gdb) c
     Continuing.
 ```   
-      
+
 * Voil�! The board's LED should be blinking at 1 Hz. Success!
 
 <br>
-

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/os/tutorials/olimex.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/olimex.md b/docs/os/tutorials/olimex.md
index 740c293..398bfe1 100644
--- a/docs/os/tutorials/olimex.md
+++ b/docs/os/tutorials/olimex.md
@@ -10,12 +10,12 @@ This tutorial shows you how to create a runtime image for an Olimex board to mak
 
 ### What you need
 
-1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
+1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeySTM32-E407), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
 2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
 3. USB A-B type cable to connect the debugger to your personal computer
 4. Personal Computer with Mac OS (Mac: OS X Yosemite Version 10.10.5) or Linux box (Ubuntu 14.10: Utopic Unicorn)
 5. An account on Github repository and *git* installed on your computer.
-6. It is assumed you have already installed newt tool. 
+6. It is assumed you have already installed newt tool.
 7. It is assumed you already installed native tools as described [here](../get_started/native_tools.md)
 
 Also, we assume that you're familiar with UNIX shells. Let's gets started!
@@ -25,13 +25,13 @@ Also, we assume that you're familiar with UNIX shells. Let's gets started!
 
 ### Prepare the Software
 
-* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory. 
- 
+* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory.
+
 <br>
 
 ### Create a project.  
 
-Create a new project to hold your work.  For a deeper understanding, you can read about project creation in 
+Create a new project to hold your work.  For a deeper understanding, you can read about project creation in
 [Get Started -- Creating Your First Project](../get_started/project_create.md)
 or just follow the commands below.
 
@@ -45,15 +45,15 @@ or just follow the commands below.
 
     $cd myproj
 
-    $ newt install -v 
+    $ newt install -v
     apache-mynewt-core
     Downloading repository description for apache-mynewt-core... success!
     ...
     apache-mynewt-core successfully installed version 0.7.9-none
-``` 
+```
 
 <br>
-   
+
 ### Create targets
 
 Change directory to ~/dev/myproj directory and define the *blinky* target inside myproj, using the *newt* tool. Starting with the target name, assign specific aspects of the project, as shown below, to pull the appropriate packages and build the right bundle or list for the board. For example, we set the build_profile, board support package (bsp), and app.
@@ -64,13 +64,13 @@ Change directory to ~/dev/myproj directory and define the *blinky* target inside
     $ newt target set blinky build_profile=debug
     $ newt target set blinky bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
     $ newt target set blinky app=apps/blinky
-    
+
     $ newt target create boot_olimex
     $ newt target set boot_olimex app=@apache-mynewt-core/apps/boot
     $ newt target set boot_olimex bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
     $ newt target set boot_olimex build_profile=optimized
-    
-    $ newt target show 
+
+    $ newt target show
     targets/blinky
         app=apps/blinky
         bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
@@ -85,9 +85,9 @@ Change directory to ~/dev/myproj directory and define the *blinky* target inside
 
 ### Build the images
 
-Next, let's build the images for the above targets. Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.* 
-    
-    
+Next, let's build the images for the above targets. Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.*
+
+
 ```no-highlight
     $ newt build blinky
     Compiling case.c
@@ -98,7 +98,7 @@ Next, let's build the images for the above targets. Afer you build the target, y
     $ ls ~/dev/myproj/bin/blinky/apps/blinky/
         blinky.elf      blinky.elf.bin     blinky.elf.cmd  
         blinky.elf.lst  blinky.elf.map
-        
+
     $ newt build boot_olimex
     Building target targets/boot_olimex
     App successfully built: ~/dev/myproj/bin/boot_olimex/apps/boot/boot.elf
@@ -106,7 +106,7 @@ Next, let's build the images for the above targets. Afer you build the target, y
 
 <br>
 
-### Sign and create the blinky application image 
+### Sign and create the blinky application image
 
 You must sign and version your application image to download it using newt to the board. Use the newt create-image command to perform this action. You may assign an arbitrary version (e.g. 1.0.0) to the image.
 
@@ -129,12 +129,12 @@ Build manifest: ~/dev/myproj/bin/blinky/apps/blinky/manifest.json
 
 <br>
 
-* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present. 
+* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present.
 To locate the bootloader, the board searches in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we will configure it to boot from flash by jumpering **B0_0** and **B1_0**.
 
-* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board). 
+* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
 
-* The red PWR LED should be lit. 
+* The red PWR LED should be lit.
 
 * Connect the JTAG connector to the SWD/JTAG interface on the board. The other end of the cable should be connected to the USB port or hub of your computer.
 
@@ -158,12 +158,12 @@ Successfully loaded image.
 
 <br>
 
-**But wait...not so fast.** Let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor, severing the debug connection to the JTAG port. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board. 
+**But wait...not so fast.** Let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor, severing the debug connection to the JTAG port. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board.
 
    The LED light will start blinking again. Success!
-  
+
    **Note #1:** If you want to download the image to flash and a gdb session opened up, use `newt debug blinky`. Type `c` to continue inside the gdb session.
-    
+
 ```no-highlight     
     $ newt debug blinky
     Debugging with ~/dev/myproj/hw/bsp/olimex_stm32-e407_...
@@ -175,7 +175,7 @@ Successfully loaded image.
     (info)
     ...
     target state: halted
-    target halted due to debug-request, current mode: Thread 
+    target halted due to debug-request, current mode: Thread
     xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000
     Info : accepting 'gdb' connection from 3333
     Info : device id = 0x10036413
@@ -186,22 +186,22 @@ Successfully loaded image.
 ```
 
 <br>
-    
+
    **Note #2:** If you want to erase the flash and load the image again you may use the following commands from within gdb. `flash erase_sector 0 0 x` tells it to erase sectors 0 through x. When you ask it to display (in hex notation) the contents of the sector starting at location 'lma,' you should see all f's. The memory location 0x8000000 is the start or origin of the flash memory contents and is specified in the olimex_stm32-e407_devboard.ld linker script. The flash memory locations is specific to the processor.
 ```no-highlight         
     (gdb) monitor flash erase_sector 0 0 4
     erased sectors 0 through 4 on flash bank 0 in 2.296712s
     (gdb) monitor mdw 0x08000000 16
-    0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
-    (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
-    (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
+    0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+    (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+    (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
     (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff         
     (gdb) monitor flash info 0
 ```
 
 ### Conclusion
 
-Congratulations! You have now tried out a project on actual hardware. If this is your first time to embedded systems, this must feel like the best hands-on and low-level "Hello World" program ever. 
+Congratulations! You have now tried out a project on actual hardware. If this is your first time to embedded systems, this must feel like the best hands-on and low-level "Hello World" program ever.
 
 Good, we have more fun tutorials for you to get your hands dirty. Be bold and try other Blinky-like [tutorials](../tutorials/nRF52.md) or try enabling additional functionality such as [remote comms](project-target-slinky.md) on the current board.
 

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/os/tutorials/project-target-slinky.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/project-target-slinky.md b/docs/os/tutorials/project-target-slinky.md
index ca2d66a..bea8049 100644
--- a/docs/os/tutorials/project-target-slinky.md
+++ b/docs/os/tutorials/project-target-slinky.md
@@ -5,13 +5,13 @@
 
 The goal of the project is to enable and demonstrate remote communications with the Mynewt OS via newt manager (newtmgr) by leveraging a sample app "Slinky" included under the /apps directory in the repository. In this project we will define a target for the STM32-E407 board and assign the app "Slinky" to it.
 
-If you have an existing project using a target that does not use the Slinky app and you wish to add newtmgt functonality to it, check out the tutorial titled [Enable newtmgr in any app](add_newtmgr.md). 
+If you have an existing project using a target that does not use the Slinky app and you wish to add newtmgt functonality to it, check out the tutorial titled [Enable newtmgr in any app](add_newtmgr.md).
 
 <br>
 
 ### What you need
 
-1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
+1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeySTM32-E407), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
 2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
 3. USB A-B type cable to connect the debugger to your personal computer
 4. A USB to TTL Serial Cable with female wiring harness. An example is [http://www.amazon.com/JBtek�-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88/ref=lp_464404_1_9?s=pc&ie=UTF8&qid=1454631303&sr=1-9](http://www.amazon.com/JBtek�-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88/ref=lp_464404_1_9?s=pc&ie=UTF8&qid=1454631303&sr=1-9)
@@ -26,18 +26,18 @@ The instructions assume the user is using a Bourne-compatible shell (e.g. bash o
 * Install dependencies
 * Define a target using the newt tool
 * Build executables for the targets using the newt tool
-* Set up serial connection with the targets 
+* Set up serial connection with the targets
 * Create a connection profile using the newtmgr tool
 * Use the newtmgr tool to communicate with the targets
 
 ### Install newt
 
-If you have not already installed `newt`, see the 
+If you have not already installed `newt`, see the
 [newt installation instructions](../get_started/get_started/) and ensure newt is installed an in your path.
 
 ### Install newtmgr
 
-If you have not already installed `newtmgr`, see the 
+If you have not already installed `newtmgr`, see the
 [newtmgr installation instructions](../../newtmgr/installing/) and ensure newtmgr is installed an in your path.
 
 ### Create a new project
@@ -116,11 +116,11 @@ Build manifest: /Users/paulfdietrich/dev/slinky/bin/stm32_slinky/apps/slinky/man
 
 <br>
 
-### Using newtmgr with a remote target 
+### Using newtmgr with a remote target
 
-* First make sure the USB A-B type cable is connected to the ARM-USB-TINY-H debugger connector on the Olimex board. 
+* First make sure the USB A-B type cable is connected to the ARM-USB-TINY-H debugger connector on the Olimex board.
 
-     Next go the to project directory and download the slinky project image to the flash of the Olimex board. 
+     Next go the to project directory and download the slinky project image to the flash of the Olimex board.
 
 ```no-highlight
 $ newt load stm32_bootloader
@@ -136,8 +136,8 @@ You can now disconnect the debugging cable from the board. You should see the gr
     ![Alt Layout - Serial Connection](pics/serial_conn.png)
 
 
-	* Connect the female RX pin of the USB-TTL serial cable to the TX of the UEXT connector on the board. 
-	* Connect the female TX pin of the USB-TTL serial cable to the RX of the UEXT connector on the board. 
+	* Connect the female RX pin of the USB-TTL serial cable to the TX of the UEXT connector on the board.
+	* Connect the female TX pin of the USB-TTL serial cable to the RX of the UEXT connector on the board.
 	* Connect the GND pin of the USB-TTL serial cable to the GND of the UEXT connector on the board.
 
 <br>
@@ -145,7 +145,7 @@ You can now disconnect the debugging cable from the board. You should see the gr
 * Locate the serial connection established in the /dev directory of your computer. It should be of the type `tty.usbserial-<some identifier>`.
 
 ```no-highlight
-        $ ls /dev/tty.usbserial-AJ03HAQQ 
+        $ ls /dev/tty.usbserial-AJ03HAQQ
         /dev/tty.usbserial-AJ03HAQQ
 ```
 
@@ -156,17 +156,17 @@ You can now disconnect the debugging cable from the board. You should see the gr
 ```no-highlight
         $ pwd
         /Users/<user>/dev/larva/project/slinky
-        $ newtmgr conn add olimex01 type=serial connstring=/dev/tty.usbserial-AJ03HAQQ 
+        $ newtmgr conn add olimex01 type=serial connstring=/dev/tty.usbserial-AJ03HAQQ
         Connection profile olimex01 successfully added
         $ newtmgr conn show
-        Connection profiles: 
+        Connection profiles:
           sim1: type=serial, connstring='/dev/ttys007'
           olimex01: type=serial, connstring='/dev/tty.usbserial-AJ03HAQQ'
 ```
 
 <br>
 
-* Now go ahead and query the Olimex board to get responses back. The simplest command is the `echo` command to ask it to respond with the text you send it. 
+* Now go ahead and query the Olimex board to get responses back. The simplest command is the `echo` command to ask it to respond with the text you send it.
 
 ```no-highlight
     $ newtmgr echo -c olimex01 hello
@@ -182,13 +182,3 @@ You can now disconnect the debugging cable from the board. You should see the gr
       idle (prio=255 tid=0 runtime=299916 cswcnt=313 stksize=32 stkusage=18 last_checkin=0 next_checkin=0)
       shell (prio=3 tid=1 runtime=1 cswcnt=20 stksize=384 stkusage=60 last_checkin=0 next_checkin=0)
 ```
-
-
-
-
-
-
-
-
-
-

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/os/tutorials/tutorials.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/tutorials.md b/docs/os/tutorials/tutorials.md
index ffc874b..b66222e 100644
--- a/docs/os/tutorials/tutorials.md
+++ b/docs/os/tutorials/tutorials.md
@@ -1,6 +1,6 @@
 ## Tutorials
 
-If the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner. 
+If the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner.
 
 The full list of tutorials can be seen in the navigation bar on the left. New ones are being constantly added and will show up there automatically.
 
@@ -10,14 +10,14 @@ The full list of tutorials can be seen in the navigation bar on the left. New on
 
 * You have installed Docker container of Newt tool and toolchains or you have installed them natively on your machine
 * You have created a new project space (directory structure) and populated it with the core code repository (apache-mynewt-core) or know how to as explained in [Creating Your First Project](../get_started/project_create).
-* You have at least one of the supported development boards: 
+* You have at least one of the supported development boards:
     * [STM32F3 discovery kit from ST Micro](STM32F303.md)
     * [Arduino Zero hardware](arduino_zero.md)
     * [Olimex/STM32F407ZGT6 Cortex-M4 hardware](olimex.md)
     * [nRF52 Development Kit from Nordic Semiconductor](nRF52.md)
-    
-The Nordic nrf52 developer kit supports Bluetooth Low Energy. We are always looking to add new hardware to the list, so if you want to develop the required Board Support Package (bsp) and/or Hardware Abstraction Layer (HAL) for a new board, you can look [here](../../core_os/porting/port_os/) to get started.
-    
+
+The Nordic nrf52 developer kit supports Bluetooth Low Energy. We are always looking to add new hardware to the list, so if you want to develop the required Board Support Package (bsp) and/or Hardware Abstraction Layer (HAL) for a new board, you can look [here](../core_os/porting/port_os/) to get started.
+
 
 <br>
 
@@ -30,14 +30,14 @@ The tutorials fall into a few broad categories. Some examples in each category a
     * [Blinky on Olimex/STM32F407ZGT6 Cortex-M4 hardware](olimex.md)
     * [Blinky on STM32F3 discovery kit from ST Micro](STM32F303.md)
     * [Blinky on nRF52 Development Kit from Nordic Semiconductor](nRF52.md) **Note:** This supports BLE.
-    
+
     <br>
-    
+
 * Tweaking available apps to customize behavior e.g. making a more exciting LED blink pattern
     * [Pinwheel Blinky on STM32F3 discovery board](pin-wheel-mods.md)
-    
+
     <br>
-    
+
 * Navigating the code and adding functionality  
     * [Adding more repositories to your project](repo/add_repos.md)
     * [Adding a unit test for a package](unit_test.md)
@@ -51,7 +51,7 @@ The tutorials fall into a few broad categories. Some examples in each category a
 
 <br>
 
-* Using NewtMgr 
+* Using NewtMgr
     * [Enabling remote communication with a device running Mynewt OS](project-slinky.md)
 
 <br>
@@ -62,4 +62,3 @@ The tutorials fall into a few broad categories. Some examples in each category a
 **Send us an email on the dev@ mailing list if you have comments or suggestions!** If you haven't joined the mailing list, you will find the links [here](../../community.md).
 
 <br>
-

http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5c00cfff/docs/os/tutorials/wi-fi_on_arduino.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/wi-fi_on_arduino.md b/docs/os/tutorials/wi-fi_on_arduino.md
index 6d27114..977f6d8 100644
--- a/docs/os/tutorials/wi-fi_on_arduino.md
+++ b/docs/os/tutorials/wi-fi_on_arduino.md
@@ -1,13 +1,13 @@
 ## Start Wi-Fi on Arduino Zero
 
-This tutorial walks you through the steps to get your Arduino board on a Wi-Fi network. 
+This tutorial walks you through the steps to get your Arduino board on a Wi-Fi network.
 
 **Note:** Wi-Fi support is currently available in the `develop` branch of Mynewt only. It will be merged into `master` branch when version 0.10 is released.
 
 
 ### Prerequisites
 
-Before tackling this tutorial, it's best to read about Mynewt in the [Introduction](../get_started/introduction) section of this documentation.
+Before tackling this tutorial, it's best to read about Mynewt in the [Introduction](../get_started/get_started) section of this documentation.
 
 ### Equipment
 
@@ -24,7 +24,7 @@ You will need the following equipment
 
 ### Install Mynewt and Newt
 
-* If you have not already done so, install Newt as shown in the [Newt install tutorial](../../newt/install/newt_mac.md). 
+* If you have not already done so, install Newt as shown in the [Newt install tutorial](../../newt/install/newt_mac.md).
 * If you installed Newt previously but need to update it, go to the newt git repo directory, pull the latest code from `develop` branch, and install the updated code.
 
 ```
@@ -49,10 +49,10 @@ Let's say your new project is named `arduinowifi`. You will henceforth be workin
 
 ### Fetch External Packages, Set correct version to download
 
-Mynewt uses source code provided directly from the chip manufacturer for 
+Mynewt uses source code provided directly from the chip manufacturer for
 low level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's github repository hosts such external third-party packages and the Newt tool can fetch them.
 
-To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add 
+To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add
 the repository to the `project.yml` file in your base project directory (`arduinowifi`).
 
 ```
@@ -60,13 +60,13 @@ user@~/dev/arduinowifi$ vi project.yml
 ```
 
 Here is an example ```project.yml``` file with the Arduino Zero repository
-added. The sections with ```mynewt_arduino_zero``` that need to be added to 
-your project file are highlighted. 
+added. The sections with ```mynewt_arduino_zero``` that need to be added to
+your project file are highlighted.
 
 Also highlighted is the `0-dev` version for both the repositories to ensure code is downloaded from the `develop` branch.
 
 ```hl_lines="6 10 14 15 16 17 18"
-$ more project.yml 
+$ more project.yml
 project.name: "my_project"
 
 project.repositories:
@@ -84,17 +84,17 @@ repository.mynewt_arduino_zero:
     vers: 0-dev
     user: runtimeinc
     repo: mynewt_arduino_zero
-$ 
+$
 ```
 
 <br>
 
-Once you've edited your ```project.yml``` file, the next step is to install the 
-project dependencies, this can be done with the ```newt install``` command 
-(to see more output, provide the ```-v``` verbose option.): 
+Once you've edited your ```project.yml``` file, the next step is to install the
+project dependencies, this can be done with the ```newt install``` command
+(to see more output, provide the ```-v``` verbose option.):
 
 ```no-highlight
-$ newt install 
+$ newt install
 apache-mynewt-core
 mynewt_arduino_zero
 $
@@ -104,15 +104,15 @@ $
 
 ### Create your bootloader target
 
-Next, you need to tell Newt what to build.  For the Arduino Zero, we are going to 
+Next, you need to tell Newt what to build.  For the Arduino Zero, we are going to
 generate both a bootloader, and an image target.
 
-To generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability. 
+To generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability.
 
 ```no-highlight
-$ newt target create arduino_boot 
-$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero 
-$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot 
+$ newt target create arduino_boot
+$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
+$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot
 $ newt target set arduino_boot build_profile=optimized
 ```
 
@@ -121,13 +121,13 @@ $ newt target set arduino_boot build_profile=optimized
 If you have an Arduino Zero Pro or M0 Pro, you have to set the following next:
 
 ```
-$ newt target set arduino_boot features=arduino_zero_pro 
+$ newt target set arduino_boot features=arduino_zero_pro
 ```
 
 If you have an Arduino Zero, you have to set the following instead:
 
 ```
-$ newt target set arduino_boot features=arduino_zero 
+$ newt target set arduino_boot features=arduino_zero
 ```
 
 <br>
@@ -138,7 +138,7 @@ $ newt target set arduino_boot features=arduino_zero
 Once you've configured the bootloader target, the next step is to build the bootloader for your Arduino. You can do this by using the ```newt build``` command:
 
 ```no-highlight
-$ newt build arduino_boot 
+$ newt build arduino_boot
 Compiling boot.c
 Archiving boot.a
 Compiling fs_cli.c
@@ -149,32 +149,32 @@ Compiling fs_mkdir.c
 App successfully built: ~/dev/arduinowifi/bin/arduino_boot/apps/boot/boot.elf
 ```
 
-If this command finishes successfully, you have successfully built the Arduino 
-bootloader, and the next step is to build your application for the Arduino 
+If this command finishes successfully, you have successfully built the Arduino
+bootloader, and the next step is to build your application for the Arduino
 board.
 
 <br>
 
-### Build your blinky app 
+### Build your blinky app
 
 To create and download your application, you create another target, this one pointing to the application you want to download to the Arduino board.  In this tutorial,  we will use the Wi-Fi application that comes in the arduino repository, `apps/winc1500_wifi`:
 
 **Note**: Remember to set features to `arduino_zero` if your board is Arduino Zero and not a Pro!
 
 ```hl_lines="5"
-$ newt target create arduino_wifi 
+$ newt target create arduino_wifi
 $ newt target set arduino_wifi app=@mynewt_arduino_zero/apps/winc1500_wifi
 $ newt target set arduino_wifi bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
-$ newt target set arduino_wifi build_profile=debug 
-$ newt target set arduino_wifi features=arduino_zero_pro 
+$ newt target set arduino_wifi build_profile=debug
+$ newt target set arduino_wifi features=arduino_zero_pro
 ```
 
 <br>
 
-You can now build the target, with ```newt build```: 
+You can now build the target, with ```newt build```:
 
 ```no-highlight
-$ newt build arduino_wifi 
+$ newt build arduino_wifi
 Building target targets/arduino_wifi
 Compiling main.c
 Archiving winc1500_wifi.a
@@ -204,13 +204,13 @@ The picture below shows the setup.
 
 ### Download the Bootloader
 
-Execute the command to download the bootloader. 
+Execute the command to download the bootloader.
 
 ```c
     $ newt load arduino_boot
 ```
 
-If the newt tool finishes without error, that means the bootloader has been 
+If the newt tool finishes without error, that means the bootloader has been
 successfully loaded onto the target.
 
 <br>
@@ -219,7 +219,7 @@ successfully loaded onto the target.
 
 <br>
 
-### Load the Application Image 
+### Load the Application Image
 
 Now that the bootloader is downloaded to the target, the next steps are to create an image and load it onto the target device.
 
@@ -246,7 +246,7 @@ $ minicom -D /dev/tty.usbmodem141122 -b 115200
 
 Welcome to minicom 2.7
 
-OPTIONS: 
+OPTIONS:
 Compiled on Nov 24 2015, 16:14:21.
 Port /dev/tty.usbmodem141122, 10:11:40
 
@@ -263,7 +263,7 @@ wifi_init : 0
 Connect to the local Wi-Fi network. Then start network services. The commands to be issued are highlighted below. In the example below, the network interface on the Arduino board gets an IP address of `192.168.0.117`.
 
 ```hl_lines="1 8"
-wifi connect <Wi-Fi network name> <password> 
+wifi connect <Wi-Fi network name> <password>
 16906:wifi_request_scan : 0
 17805:scan_results 16: 0
 17816:wifi_connect : 0
@@ -291,4 +291,4 @@ $
 
 One port echoes whatever is typed, one discards everything it gets, and the third spews out bits constantly. Type `wifi stop` to disable WiFi on the Arduino board.
 
-Hope you had fun!
\ No newline at end of file
+Hope you had fun!