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 2017/03/31 17:13:38 UTC
[1/7] incubator-mynewt-site git commit: 1) Added Blinky RedBear Nano
2 tutorial 2) Updated Blinky for Olimex: - Add instruction to use USB-OTG2
port for power source instead of JTG/SWD. - Add note that the diagram has
USB-OTG2 and USB-OTG1 labels r
Repository: incubator-mynewt-site
Updated Branches:
refs/heads/develop b8cab1b93 -> 51ea3d02f
1) Added Blinky RedBear Nano 2 tutorial
2) Updated Blinky for Olimex:
- Add instruction to use USB-OTG2 port for power source instead of JTG/SWD.
- Add note that the diagram has USB-OTG2 and USB-OTG1 labels reversed.
3) Added back and updated Project Slinky for Olimex board
4) Clarify description for newtmgr_uart in enabling newtmgr app tutorial.
5) Updated Blinky for Primo:
- Move Install JlinkExe to Debugger option 1 (using jlink probe)
- Specify Blinky blinks the orange LED (L13) to distiguish the wifi green led on board the blinks too.
- Added command to erase flash when using OpenOCD
6) Updated Add Shell and Console to Blinky tutorial to use default OS eventq and default task instead
of defining a dedicated task for shell events.
7) Add install JLink to Blinky NRF52 since it uses the JlinkEXE in the tutorial.
8) Cleaned Project Slinky Sim tutorial
9) Fix typo in os_task_remove
10) Removed Blinky Boot from Olimex SRAM tutorial.
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/3a6e4ff0
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/3a6e4ff0
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/3a6e4ff0
Branch: refs/heads/develop
Commit: 3a6e4ff0ef247378aec02ee856fa146b17aab305
Parents: b8cab1b
Author: cwanda <wa...@happycity.com>
Authored: Tue Mar 28 10:43:54 2017 -0700
Committer: cwanda <wa...@happycity.com>
Committed: Tue Mar 28 23:53:22 2017 -0700
----------------------------------------------------------------------
docs/os/core_os/task/os_task_remove.md | 2 +-
docs/os/tutorials/add_newtmgr.md | 6 +-
docs/os/tutorials/blinky_console.md | 163 +++++++++--------
docs/os/tutorials/blinky_primo.md | 44 +++--
docs/os/tutorials/nRF52.md | 5 +-
docs/os/tutorials/olimex.md | 14 +-
docs/os/tutorials/project-slinky.md | 26 +--
docs/os/tutorials/project-stm32-slinky.md | 243 +++++++++++++++++++++++++
docs/os/tutorials/rbnano2.md | 206 +++++++++++++++++++++
mkdocs.yml | 3 +-
10 files changed, 583 insertions(+), 129 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/core_os/task/os_task_remove.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/os_task_remove.md b/docs/os/core_os/task/os_task_remove.md
index 79f18c3..02af47c 100644
--- a/docs/os/core_os/task/os_task_remove.md
+++ b/docs/os/core_os/task/os_task_remove.md
@@ -22,7 +22,7 @@ Removes a task, `t`, from the task list. A task cannot be removed when it is in
`OS_OK`: Task `t` is removed sucessfully.
<br>`OS_INVALID_PARM`: Task `t` is the calling task. A task cannot remove itself.
<br>`OS_NOT_STARTED`: Task `t` is not initialized.
-<br>`OS_EBUSY`: Task `t` is either holding a lock or suspended waiting on lock on event.
+<br>`OS_EBUSY`: Task `t` is either holding a lock or suspended waiting for a lock or an event.
<br>
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/tutorials/add_newtmgr.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/add_newtmgr.md b/docs/os/tutorials/add_newtmgr.md
index 5d975cc..658560f 100644
--- a/docs/os/tutorials/add_newtmgr.md
+++ b/docs/os/tutorials/add_newtmgr.md
@@ -220,10 +220,10 @@ The newtmgr framework currently supports BLE and serial transport protocols.
To configure the transport protocols that are supported, modify the `pkg.yml`
and `syscfg.yml` files as follows:
-* Add the `mgmt/newtmgr/transport/ble` package to `pkg.deps` parameter to enable BLE transport.
+* Add the `mgmt/newtmgr/transport/ble` package to the `pkg.deps` parameter to enable BLE transport.
* Add the `mgmt/newtmgr/transport/nmgr_shell` package to
-the `pkg.deps` parameter, and add `SHELL_TASK: 1` to the `syscfg.vals` parameter to enable serial transport.
-* Add the `mgmt/newtmgr/transport/nmgr_uart` package, and add `SHELL_TASK: 1` to enable serial communication over a UARTport.
+the `pkg.deps` parameter, and add `SHELL_TASK: 1` to the `syscfg.vals` parameter to enable serial transport when your application also uses the [Shell](/os/modules/shell/shell.md).
+* Add the `mgmt/newtmgr/transport/nmgr_uart` package to the `pkg.deps` parameter to enable serial transport over a UART port. You can use this package instead of the `nmgr_shell` package when your application does not use the [Shell](/os/modules/shell/shell.md) or you want to use a dedicated UART port to communicate with newtmgr. You can change the `NMGR_UART` and `NMGR_URART_SPEED` sysconfig values to specify a different port.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/tutorials/blinky_console.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/blinky_console.md b/docs/os/tutorials/blinky_console.md
index f3fd9ff..81c9afe 100644
--- a/docs/os/tutorials/blinky_console.md
+++ b/docs/os/tutorials/blinky_console.md
@@ -2,37 +2,28 @@
<br>
-This tutorial explains how to add the Console and Shell task to the blinky app so that you
-can interact with it over a serial line connection.
+This tutorial explains how to add the Console and Shell task to the blinky application so that you can interact with it over a serial line connection.
<br>
-### Pre-Requisites
+### Prerequisites
-* Ensure you have installed [newt](../../newt/install/newt_mac.md) and that the
-newt command is in your system path.
-* You must have Internet connectivity to fetch remote Mynewt components.
-* You must [install the compiler tools](../get_started/native_tools.md) to
-support native compiling to build the project this tutorial creates.
-* You must install the [Segger JLINK package]( https://www.segger.com/jlink-software.html) to
-load your project on the board.
-* Cable to establish a serial USB connection between the board and the laptop
+* Work through one of the Blinky Tutorials to create and build a Blinky application for one of the boards.
<br>
-### Use an existing project
+### Use an Existing Project
Since all we're doing is adding the shell and console capability to blinky, we assume
that you have worked through at least some of the other tutorials, and have an existing project.
For this example, we'll be modifying the [blinky on nrf52](./nRF52.md) project to enable
-the shell and console connectivity. Feel free to use whatever version of blinky you'd like though.
+the shell and console connectivity. You can use blinky on a different board.
<br>
###Modify the Dependencies and Configuration
-The first thing you'll need to add is a few new dependencies for your app. To add shell support to
-your app make sure the following `pkg.deps` are defined in your target's pkg.yml file:
+Add the following dependencies to your application target's `pkg.yml` file:
```
pkg.deps:
@@ -43,12 +34,9 @@ pkg.deps:
This lets the newt system know that it needs to pull in the code for the console and the shell.
-Now we'll need to modify the settings for the app to turn on the shell, etc. by modifying the
-`syscfg.yml` file for your target. (Remember, these files are in the targets/<app-name> directory.)
-If there isn't a `syscfg.yml` file in your target's directory, you will need to create one.
+Modify the system configuration settings to enable Shell and Console ticks and prompt. Add the following to your application target's `syscfg.yml` file:
```no-highlight
-# Package: apps/bletiny
syscfg.vals:
# Enable the shell task.
@@ -59,104 +47,130 @@ syscfg.vals:
CONSOLE_PROMPT: 1
```
-### Add an Event Queue
+<br>
+### Use the OS Default Event Queue to Process Blinky Timer and Shell Events
+Mynewt creates a default task that executes the application `main()` function. It also creates an OS default event queue that packages can use to queue their events. Shell uses the OS default event queue for Shell events, and `main()` can process the events in the context of the default task.
-Blinky is a small app that doesn't make use of tasks or an event queue as many other apps do, so
-we'll have to modify the source for the app in order to add one.
+Blinky's main.c is very simple. It only has a `main()` function that executes an infinite loop to toggle the LED and sleep for one second. We will modify blinky:
-```c
-/* System event queue task handler */
-#define SYSEVQ_PRIO (1)
-#define SYSEVQ_STACK_SIZE OS_STACK_ALIGN(512)
-static struct os_task task_sysevq;
-os_stack_t sysevq_stack[SYSEVQ_STACK_SIZE];
+* To use os_callout to generate a timer event every one second instead of sleeping. The timer events are added to the OS default event queue.
+* To process events from the OS default event queue inside the infinite loop in `main()`.
-/* Event queue for events handled by the system (shell, etc.) */
-static struct os_eventq sys_evq;
-```
+This allows the default task to process both Shell events and the timer events to toggle the LED from the OS default event queue.
-We define a new `os_task` a task stack (`sysevq_stack`) and new system event queue
-(`sys_evq`) so that the shell and console will have an event queue to run in.
+<br>
+### Modify main.c
-Next we go down to our `init_tasks()` function and initialize it
+Initialize a os_callout timer and move the toggle code from the while loop in `main()` to the event callback function. Add the following code above the `main()` function:
```c
-os_task_init(&task_sysevq, "sysevq", sysevq_handler, NULL,
- SYSEVQ_PRIO, OS_WAIT_FOREVER, sysevq_stack, SYSEVQ_STACK_SIZE);
-os_eventq_init(&sys_evq);
-os_eventq_dflt_set(&sys_evq);
-```
+/* The timer callout */
+static struct os_callout blinky_callout;
+
+/*
+ * Event callback function for timer events. It toggles the led pin.
+ */
+static void timer_ev_cb(struct os_event *ev)
+{
+ assert(ev != NULL);
+
+ ++g_task1_loops;
+ hal_gpio_toggle(g_led_pin);
-This will initialize the task, initialize the event queue, and then set the new event queue as
-the default event queue.
+ os_callout_reset(&blinky_callout, OS_TICKS_PER_SEC);
+}
+
+static void init_timer(void)
+{
+ /*
+ * Initialize the callout for a timer event.
+ */
+ os_callout_init(&blinky_callout, os_eventq_dflt_get(),
+ timer_ev_cb, NULL);
+
+ os_callout_reset(&blinky_callout, OS_TICKS_PER_SEC);
+
+}
+```
-Finally, we need to add the task handler for the event queue:
+In `main()`, add the call to the `init_timer()` function before the while loop and modify the while loop to process events from the OS default event queue:
```c
-/**
- * This task serves as a container for the shell and newtmgr packages. These
- * packages enqueue timer events when they need this task to do work.
- */
-static void
-sysevq_handler(void *arg)
+main(int argc, char **argv)
{
+
+ int rc;
+
+#ifdef ARCH_sim
+ mcu_sim_parse_args(argc, argv);
+#endif
+
+ sysinit();
+
+ g_led_pin = LED_BLINK_PIN;
+ hal_gpio_init_out(g_led_pin, 1);
+ init_timer();
while (1) {
- os_eventq_run(&sys_evq);
+ os_eventq_run(os_eventq_dflt_get());
}
+ assert(0)
+ return rc;
}
-```
-### Build targets
+```
+<br>
+### Build the Blinky Application Target
We're not going to build the bootloader here since we are assuming that you have already
built and loaded it during previous tutorials.
+Run the `newt build nrf52_blinky` command to build the Blinky application:
+
```no-highlight
-$ newt build blinky
-Archiving cbmem.a
-Compiling crc16.c
-Compiling crc8.c
-Archiving crc.a
-Compiling mem.c
-Archiving mem.a
-Linking ~/dev/myproj/bin/targets/blinky/app/apps/blinky/blinky.elf
-Target successfully built: targets/blinky
+$ newt build nrf52_blinky
+
+ ...
+
+Archiving util_mem.a
+Linking ~/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky/blinky.elf
+Target successfully built: targets/nrf52_blinky
```
<br>
-### Create the app image
+### Sign and Create the Blinky Application Image
-Generate a signed application image for the `blinky` target. The version number is arbitrary.
+Run the `newt create-image nrf52_blinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
-```
-$ newt create-image blinky 1.0.0
-App image succesfully generated: ~/dev/myproj/bin/targets/blinky/app/apps/blinky/blinky.img
+```no-highlight
+$ newt create-image nrf52_blinky 1.0.0
+App image succesfully generated: ~/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky/blinky.img
```
<br>
-### Load the image
+### Load the Image
Make sure the USB connector is in place and the power LED on the board is lit. Use the Power ON/OFF switch to reset the board after loading the image.
-```
-$ newt load blinky
+Run the `newt load nrf52_blinky` command to load the Blinky application image onto the board.
+```no-highlight
+$ newt load nrf52_blinky
+Loading app image into slot 1
```
<br>
-### Set up Serial connection
+### Set Up a Serial Connection
You'll need a Serial connection to see the output of your program. You can reference the [Serial Port Setup](../get_started/serial_access.md)
-Tutorial for more information on setting up your serial communications.
+Tutorial for more information on setting up your serial communication.
<br>
-###Connecting with your app
+###Communicate with the Application
-Once you have a connection set up, you can connect to your device with ```minicom -D /dev/tty.usbmodem<port> -b 115200``` to run connect
-to the console of your app.
+Once you have a connection set up, run ```minicom -D /dev/tty.usbmodem<port> -b 115200``` to connect to the application console.
To test and make sure that the Shell is running, first just hit <return>:
@@ -164,7 +178,7 @@ To test and make sure that the Shell is running, first just hit <return>:
3534: >
```
-Remember, we turned the CONSOLE_PROMPT and the CONSOLE_TICKS on earlier. You can try some commands now:
+You can try some commands:
```no-highlight
3609: > ?
@@ -184,4 +198,3 @@ prompt on
39108: >
```
-And there you have the Console and Shell working in an app that previously had no event queue!
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/tutorials/blinky_primo.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/blinky_primo.md b/docs/os/tutorials/blinky_primo.md
index 7bade06..cf769b9 100644
--- a/docs/os/tutorials/blinky_primo.md
+++ b/docs/os/tutorials/blinky_primo.md
@@ -22,7 +22,7 @@ Ensure that you have met the following prerequisites before continuing with this
* Install the Newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
* Create a 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](/os/get_started/project_create).
* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
-* Install a debugger - choose one of the two options below. Option 1 requires additional hardware but very easy to set up. Option 2 is free software install but not as simple as Option 1.
+* Install a debugger - choose one of the two options below. Option 1 requires additional hardware but very easy to set up. Option 2 is free software but not as simple as Option 1.
<br>
@@ -30,6 +30,8 @@ Ensure that you have met the following prerequisites before continuing with this
* [Segger J-Link Debug Probe](https://www.segger.com/jlink-debug-probes.html) - any model (this tutorial has been tested with J-Link EDU and J-Link Pro)
* [J-Link 9 pin Cortex-M Adapter](https://www.segger.com/jlink-adapters.html#CM_9pin) that allows JTAG, SWD and SWO connections between J-Link and Cortex M based target hardware systems
+* Install the [Segger JLINK Software and documentation pack](https://www.segger.com/jlink-software.html).
+
##### Option 2
@@ -48,29 +50,9 @@ Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
```
-Next, make sure that you have checked out the newt develop branch and rebuilt newt.
-```
-$ cd $GOPATH/src/mynewt.apache.org/newt
-$ git checkout develop
-$ git pull
-$ cd newt
-$ go install
-```
-**Note:** This step can be removed once the changes have been pushed to master.
-
You can now use openocd to upload to Arduino Primo board via the USB port itself.
-
-
<br>
-
-
-### Install jlinkEXE
-
-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).
-
-<br>
-
### Create a Project
Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already created a project.
@@ -219,14 +201,14 @@ Loading app image into slot 1
$
```
-You should see the LED on the board blink!
+You should see the orange LED (L13), below the ON LED, on the board blink!
Note: If the LED does not blink, try resetting the board.
<br>
-**Note:** If you want to erase the flash and load the image again, you can use JLinkExe to issue an `erase` command.
+**Note:** If you want to erase the flash and load the image again, use JLinkExe and issue the `erase` command when you are using the Jlink debug probe:
```
$ JLinkExe -device nRF52 -speed 4000 -if SWD
@@ -252,7 +234,23 @@ Erasing done.
J-Link>exit
$
```
+<br>
+If you are using the OpenOCD debugger, run the `newt debug primoblinky` command and issue the highlighted command at the (gdb) prompt:
+
+```hl_lines="11"
+$newt debug primoblinky
+[~/dev/myproj/repos/apache-mynewt-core/hw/bsp/arduino_primo_nrf52/primo_debug.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/arduino_primo_nrf52 ~/dev/myproj/bin/targets/primoblinky/app/apps/blinky/blinky]
+Open On-Chip Debugger 0.10.0-dev-snapshot (2017-03-28-11:24)
+
+ ...
+
+os_tick_idle (ticks=128)
+ at repos/apache-mynewt-core/hw/mcu/nordic/nrf52xxx/src/hal_os_tick.c:200
+warning: Source file is more recent than executable.
+200 if (ticks > 0) {
+(gdb) mon nrf52 mass_erase
+```
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/tutorials/nRF52.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/nRF52.md b/docs/os/tutorials/nRF52.md
index 2a14967..2b199bb 100644
--- a/docs/os/tutorials/nRF52.md
+++ b/docs/os/tutorials/nRF52.md
@@ -6,7 +6,7 @@
Learn how to use packages from a default application repository of Mynewt to build your first *Hello World* application (Blinky) on a target board. Once built using the *newt* tool, this application will blink the LED lights on the target board.
-Create a project with a simple app that blinks an LED on the nRF52 board from Nordic Semiconductors. Download the application to the target and watch it blink!
+Create a project with a simple application that blinks an LED on the nRF52 board from Nordic Semiconductors. Download the application to the target and watch it blink!
Note that there are several versions of the nRF52 in the market. The boards tested with this tutorial are listed under "Prerequisites".
@@ -23,11 +23,11 @@ Ensure that you have met the following prerequisites before continuing with this
* Have a computer to build a Mynewt application and connect to the board over USB.
* Have a Micro-USB cable to connect the board and the computer.
* Install the Newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
+* Install the [Segger JLINK package]( https://www.segger.com/jlink-software.html) to load your project on the board.
* Create a 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](/os/get_started/project_create).
* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
This tutorial uses the Nordic nRF52-DK board.
-<br>
### Create a Project
Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already have a project created.
@@ -147,7 +147,6 @@ Run the `newt create-image nrf52_blinky 1.0.0` command to create and sign the ap
```no-highlight
$ newt create-image nrf52_blinky 1.0.0
-newt create-image nrf52_blinky 1.0.0
App image succesfully generated: ~/dev/myproj/bin/targets/nrf52_blinky/app/apps/blinky/blinky.img
```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/tutorials/olimex.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/olimex.md b/docs/os/tutorials/olimex.md
index c42a957..de1b0c2 100644
--- a/docs/os/tutorials/olimex.md
+++ b/docs/os/tutorials/olimex.md
@@ -15,7 +15,8 @@ Ensure that you have met the following prerequisites before continuing with this
* Have a ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
* Have Internet connectivity to fetch remote Mynewt components.
* Have a computer to build a Mynewt application and connect to the board over USB.
-* Have USB A-B type cable to connect the debugger to your computer.
+* Have a USB A-B type cable to connect the debugger to your computer.
+* Have a USB Micro-A cable to connect your computer to the board.
* Install the Newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
* Create a 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](/os/get_started/project_create).
* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
@@ -135,7 +136,9 @@ App image succesfully generated: ~/dev/myproj/bin/targets/olimex_blinky/app/apps
### Connect to the Board
-Configure the board to bootload from flash memory and to use the JTAG/SWD for the power source. Refer to the following diagrams to locate the boot jumpers and power input select jumpers on the board.
+Configure the board to bootload from flash memory and to use USB-OTG2 for the power source. Refer to the following diagrams to locate the boot jumpers and power input select jumpers on the board.
+
+**Note:** The labels for the **USB-OTG1** and **USB-OTG2** ports on the diagram are reversed. The port labeled USB-OTG1 on the diagram is the USB-OTG2 port and the port labeled USB-OTG2 on the diagram is the USB-OTG1 port.
<br>
<p align="center">
@@ -149,8 +152,9 @@ Configure the board to bootload from flash memory and to use the JTAG/SWD for th
* Locate the boot jumpers on the lower right corner of the board. **B1_1/B1_0** and **B0_1/B0_0** are PTH jumpers to control the boot mode when a bootloader is present. These two jumpers must be moved together. The board searches for the bootloader in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we configure the board to boot from flash by jumpering **B0_0** and **B1_0**.
**Note:** The markings on the board may not always be accurate, and you should always refer to the manual for the correct positioning.
-* Locate the **Power Input Select** jumpers on the lower left corner of the board. Set the Power Select jumpers to position 3 and 4 to use the JTAG/SWD for the power source. If you would like to use a different power source, refer to the [OLIMEX STM32-E407 user manual](https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407.pdf) for pin specifications.
-
+* Locate the **Power Input Select** jumpers on the lower left corner of the board. Set the Power Select jumpers to position 5 and 6 to use the USB-OTG2 port for the power source. If you would like to use a different power source, refer to the [OLIMEX STM32-E407 user manual](https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407.pdf) for pin specifications.
+
+* Connect the USB Micro-A cable to the USB-OTG2 port on the board.
* Connect the JTAG connector to the JTAG/SWD interface on the board.
@@ -180,7 +184,7 @@ Successfully loaded image.
The LED should be blinking!
<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.
+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!
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/tutorials/project-slinky.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/project-slinky.md b/docs/os/tutorials/project-slinky.md
index 40f93e3..2b39f61 100644
--- a/docs/os/tutorials/project-slinky.md
+++ b/docs/os/tutorials/project-slinky.md
@@ -8,14 +8,15 @@ The goal of the project is to use a sample app called "Slinky" included in the M
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>
+### Prerequisites
-### What you need
+Ensure that you have met the following prerequisites before continuing with this tutorial:
-1.Personal Computer
-
-The instructions assume the user is using a Bourne-compatible shell (e.g. bash or zsh) on your computer. The given instructions have been tested with the following releases of operating systems:
-
-* Mac: OS X Yosemite Version 10.10.5
+* Have Internet connectivity to fetch remote Mynewt components.
+* Have a computer to build a Mynewt application.
+* Install the newt tool and the toolchains (See [Basic Setup](/os/get_started/get_started.md)).
+* Install the [newtmgr tool](../../newtmgr/installing/).
+* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
### Overview of steps
@@ -26,16 +27,6 @@ The instructions assume the user is using a Bourne-compatible shell (e.g. bash o
* Create a connection profile using the newtmgr tool
* Use the newtmgr tool to communicate with the targets
-### Installing newt
-
-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.
-
-### Installing newtmgr
-
-If you have not already installed `newtmgr` see the
-[newtmgr installation instructions](../../newtmgr/installing/) and ensure newtmgr is installed an in your path.
-
### Creating a new project
Instructions for creating a project are located in the [Basic Setup](../get_started/project_create/) section of the [Mynewt Documentation](../introduction/)
@@ -98,8 +89,7 @@ is created.
### Run the target
-Run the executable you have build for the simulated environment. The serial port name on which the simulated target is connected is shown in the output
-when mynewt slinky starts.
+Run the executable you have build for the simulated environment. The serial port name on which the simulated target is connected is shown in the output when mynewt slinky starts.
```no-highlight
$ ~/dev/slinky/bin/targets/sim_slinky/app/apps/slinky/slinky.elf
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/tutorials/project-stm32-slinky.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/project-stm32-slinky.md b/docs/os/tutorials/project-stm32-slinky.md
new file mode 100644
index 0000000..926a459
--- /dev/null
+++ b/docs/os/tutorials/project-stm32-slinky.md
@@ -0,0 +1,243 @@
+## Project Slinky Using STM32 Board
+
+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 that has a different application and you wish to add newtmgr functionality to it, check out the [Enable newtmgr in any app](add_newtmgr.md) tutorial.
+
+<br>
+
+
+###Prerequisites
+Ensure that you have met the following prerequisites before continuing with this tutorial:
+
+* Have a STM32-E407 development board from Olimex.
+* Have a ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
+* Have a USB to TTL Serial Cable with female wiring harness.
+* Have a USB Micro-A cable to connect your computer to the board.
+* Have Internet connectivity to fetch remote Mynewt components.
+* Have a computer to build a Mynewt application and connect to the board over USB.
+* Install the newt tool and the toolchains (See Basic Setup).
+* Install the newtmgr tool.
+* Create a 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.
+* Read the Mynewt OS Concepts section.
+
+### Overview of Steps
+
+* 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
+* Create a connection profile using the newtmgr tool
+* Use the newtmgr tool to communicate with the targets
+
+### Create a New Project
+Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already have a project created or completed the [Sim Slinky](project-slinky.md) tutorial.
+
+```no-highlight
+$ newt new slinky
+Downloading project skeleton from apache/incubator-mynewt-blinky...
+...
+Installing skeleton in slink...
+Project slink successfully created
+$ cd slinky
+$newt install
+apache-mynewt-core
+```
+
+<br>
+
+###<a name="create_targets"></a> Create the Targets
+Create two targets for the STM32-E407 board - one for the bootloader and one for the Slinky application.
+
+Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `
+stm32_boot`.
+
+```no-highlight
+$ newt target create stm32_boot
+$ newt target set stm32_bootr bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
+$ newt target set stm32_boot build_profile=optimized
+$ newt target set stm32_boot target.app=@apache-mynewt-core/apps/boot
+```
+<br>
+Run the following `newt target` commands to create a target for the Slinky application. We name the target `stm32_slinky`.
+
+```no-highlight
+$ newt target create stm32_slinky
+$ newt target set stm32_slinky bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
+$ newt target set stm32_slinky build_profile=debug
+$ newt target set stm32_slinky app=@apache-mynewt-core/apps/slinky
+```
+<br>
+
+### Build the Targets
+Run the `newt build stm32_boot` command to build the bootloader:
+
+```no-highlight
+$ newt build stm32_boot
+Building target targets/stm32_boot
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
+Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
+Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
+
+ ...
+
+Archiving sys_mfg.a
+Archiving sys_sysinit.a
+Archiving util_mem.a
+Linking ~/dev/slinky/bin/targets/stm32_boot/app/apps/boot/boot.elf
+Target successfully built: targets/stm32_boot
+$
+```
+<br>
+Run the `newt build stm32_slinky` command to build the Slinky application:
+
+```no-highlight
+$newt build stm32_slinky
+Building target targets/stm32_slinky
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
+Compiling repos/apache-mynewt-core/boot/split/src/split.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
+Compiling repos/apache-mynewt-core/apps/slinky/src/main.c
+
+ ...
+
+Archiving util_crc.a
+Archiving util_mem.a
+Linking ~/dev/slinky/bin/targets/stm32_slinky/app/apps/slinky/slinky.elf
+Target successfully built: targets/stm32_slinky
+$
+```
+<br>
+### Sign and Create the Slinky Application Image
+
+Run the `newt create-image stm32_slinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
+
+```no-highlight
+create-image stm32_slinky 1.0.0
+App image succesfully generated: ~/dev/slinky/bin/targets/stm32_slinky/app/apps/slinky/slinky.img
+$
+```
+<br>
+
+
+###Connect to the Board
+
+* Connect the USB A-B type cable to the ARM-USB-TINY-H debugger connector.
+* Connect the ARM-USB-Tiny-H debugger connector to your computer and the board.
+* Connect the USB Micro-A cable to the USB-OTG2 port on the board.
+* Set the Power Sel jumper on the board to pins 5 and 6 to select USB-OTG2 as the power source. If you would like to use a different power source, refer to the [OLIMEX STM32-E407 user manual](https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407.pdf) for pin specifications.
+
+You should see a red LED light up on the board.
+
+<br>
+### Load the Bootloader and the Slinky Application Image
+
+Run the `newt load stm32_boot` command to load the bootloader onto the board:
+
+```no-highlight
+$ newt load stm32_boot
+Loading bootloader
+$
+```
+<br>
+Run the `newt load stm32_slinky` command to load the Slinky application image onto the board:
+```no-highlight
+$ newt load stm32_slinky
+Loading app image into slot 1
+$
+```
+<br>
+
+### Connect Newtmgr with the Board using a Serial Connection
+
+Locate the PC6/USART6_TX (pin 3), PC7/USART6_RX (pin 4), and GND (pin 2) of the UEXT connector on the Olimex board. More information on the UEXT connector can be found at [https://www.olimex.com/Products/Modules/UEXT/](https://www.olimex.com/Products/Modules/UEXT/). The schematic of the board can be found at [https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407_sch.pdf](https://www.olimex.com/Products/ARM/ST/STM32-E407/resources/STM32-E407_sch.pdf) for reference.
+
+
+
+
+* Connect the female RX pin of the USB-TTL serial cable to the TX (Pin 3) of the UEXT connector on the board.
+* Connect the female TX pin of the USB-TTL serial cable to the RX (Pin 4) of the UEXT connector on the board.
+* Connect the GND pin of the USB-TTL serial cable to the GND (Pin 2) of the UEXT connector on the board.
+
+<br>
+Locate the port, in the /dev directory on your computer, that the serial connection uses. It should be of the type `tty.usbserial-<some identifier>`.
+
+```no-highlight
+$ ls /dev/tty*usbserial*
+/dev/tty.usbserial-1d13
+$
+```
+
+<br>
+Setup a newtmgr connection profile for the serial port. For our example, the port is `/dev/tty.usbserial-1d13`.
+
+Run the `newtmgr conn add` command to define a newtmgr connection profile for the serial port. We name the connection profile `stm32serial`. You will need to replace the `connstring` with the specific port for your serial connection.
+
+```no-highlight
+$ newtmgr conn add stm32serial type=serial connstring=/dev/tty.usbserial-1d13
+Connection profile stm32serial successfully added
+$
+```
+<br>
+You can run the `newt conn show` command to see all the newtmgr connection profiles:
+
+```no-highlight
+$ newtmgr conn show
+Connection profiles:
+ stm32serial: type=serial, connstring='/dev/tty.usbserial-1d13'
+ sim1: type=serial, connstring='/dev/ttys012'
+$
+```
+
+<br>
+### Use Newtmgr to Query the Board
+Run some newtmgr commands to query and receive responses back from the board (See the [Newt Manager Guide](newtmgr/overview) for more information on the newtmgr commands).
+
+Run the `newtmgr echo hello -c stm32serial` command. This is the simplest command that requests the board to echo back the
+ text.
+
+```no-highlight
+$ newtmgr echo hello -c stm32serial
+hello
+$
+```
+<br>
+Run the `newtmgr image list -c stm32serial` command to list the images on the board:
+
+```no-highlight
+$ newtmgr image list -c stm32serial
+Images:
+ slot=0
+ version: 1.0.0
+ bootable: true
+ flags: active confirmed
+ hash: 9cf8af22b1b573909a8290a90c066d4e190407e97680b7a32243960ec2bf3a7f
+Split status: N/A
+$
+```
+
+
+<br>
+Run the `newtmgr taskstats -c stm32serial` command to display the task statistics on the board:
+
+```no-highlight
+$ newtmgr taskstats -c stm32serial
+Return Code = 0
+ task pri tid runtime csw stksz stkuse last_checkin next_checkin
+ task1 8 2 0 90 192 110 0 0
+ task2 9 3 0 90 64 31 0 0
+ idle 255 0 89460 89463 64 26 0 0
+ main 127 1 4 26 1024 368 0 0
+$
+```
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/docs/os/tutorials/rbnano2.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/rbnano2.md b/docs/os/tutorials/rbnano2.md
new file mode 100644
index 0000000..52883fa
--- /dev/null
+++ b/docs/os/tutorials/rbnano2.md
@@ -0,0 +1,206 @@
+## Blinky, your "Hello World!", on RedBear Nano 2
+
+<br>
+
+### Objective
+
+Learn how to use packages from a default application repository of Mynewt to build your first *Hello World* application (Blinky) on a target board. Once built using the *newt* tool, this application will blink the LED lights on the target board.
+
+Create a project with a simple application that blinks an LED on a RedBear Nano 2 board. Download the application to the target and watch it blink!
+
+<br>
+
+### Prerequisites
+
+Ensure that you have met the following prerequisites before continuing with this tutorial:
+
+* Have a RedBear Nano 2 board.
+* Have Internet connectivity to fetch remote Mynewt components.
+* Have a computer to build a Mynewt application and connect to the board over USB.
+* Install the Newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
+* Create a 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](/os/get_started/project_create).
+* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
+
+**Note:** You must install a patched version of OpenOCD .10.0 (See [Debugger Option 2 in the Arduino Primo Blinky Tutorial](/os/tutorials/blinky_primo)).
+
+### Create a Project
+Create a new project if you do not have an existing one. You can skip this step and proceed to [create the targets](#create_targets) if you already have a project created.
+
+Run the following commands to create a new project:
+
+```no-highlight
+ $ mkdir ~/dev
+ $ cd ~/dev
+ $ newt new myproj
+ Downloading project skeleton from apache/incubator-mynewt-blinky...
+ Installing skeleton in myproj...
+ Project myproj successfully created.
+ $ cd myproj
+ $ newt install
+ apache-mynewt-core
+ $
+```
+
+<br>
+
+### <a name="create_targets"></a>Create the Targets
+
+Create two targets for the RedBear Nano 2 board - one for the bootloader and one for the Blinky application.
+
+Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `rbnano2_boot`:
+
+```no-highlight
+$ newt target create rbnano2_boot
+$ newt target set rbnano2_boot app=@apache-mynewt-core/apps/boot
+$ newt target set rbnano2_boot bsp=@apache-mynewt-core/hw/bsp/rb-nano2
+$ newt target set rbnano2_boot build_profile=optimized
+```
+
+<br>
+Run the following `newt target` commands to create a target for the Blinky application. We name the target `nrf52_blinky`.
+
+```no-highlight
+$ newt target create rbnano2_blinky
+$ newt target set rbnano2_blinky app=apps/blinky
+$ newt target set rbnano2_blinky bsp=@apache-mynewt-core/hw/bsp/rb-nano2
+$ newt target set rbnano2_blinky build_profile=debug
+```
+<br>
+You can run the `newt target show` command to verify the target settings:
+
+```no-highlight
+$ newt target show
+targets/rbnano2_blinky
+ app=apps/blinky
+ bsp=@apache-mynewt-core/hw/bsp/rb-nano2
+ build_profile=debug
+targets/rbnano2_boot
+ app=@apache-mynewt-core/apps/boot
+ bsp=@apache-mynewt-core/hw/bsp/rb-nano2
+ build_profile=optimized
+```
+<br>
+
+### Build the Target Executables
+
+Run the `newt build rbnano2_boot` command to build the bootloader:
+
+```no-highlight
+$newt build rbnano2_boot
+Building target targets/rbnano2_boot
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
+Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c
+Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
+
+ ...
+
+Archiving sys_sysinit.a
+Archiving util_mem.a
+Linking ~/dev/myproj/bin/targets/rbnano2_boot/app/apps/boot/boot.elf
+Target successfully built: targets/rbnano2_boot
+```
+
+<br>
+Run the `newt build rbnano2_blinky` command to build the Blinky application:
+
+```no-highlight
+$newt build rbnano2_blinky
+Building target targets/rbnano2_blinky
+Assembling repos/apache-mynewt-core/hw/bsp/rb-nano2/src/arch/cortex_m4/gcc_startup_nrf52_split.s
+Compiling repos/apache-mynewt-core/hw/drivers/uart/src/uart.c
+Compiling repos/apache-mynewt-core/hw/cmsis-core/src/cmsis_nvic.c
+Compiling repos/apache-mynewt-core/hw/bsp/rb-nano2/src/sbrk.c
+Compiling apps/blinky/src/main.c
+
+ ...
+
+Archiving sys_sysinit.a
+Archiving util_mem.a
+Linking ~/dev/myproj/bin/targets/rbnano2_blinky/app/apps/blinky/blinky.elf
+Target successfully built: targets/rbnano2_blinky
+
+```
+
+<br>
+
+### Sign and Create the Blinky Application Image
+
+Run the `newt create-image rbnano2_blinky 1.0.0` command to create and sign the application image. You may assign an arbitrary version (e.g. 1.0.0) to the image.
+
+```no-highlight
+$newt create-image rbnano2_blinky 1.0.0
+App image succesfully generated: ~/dev/myproj/bin/targets/rbnano2_blinky/app/apps/blinky/blinky.img
+```
+
+<br>
+
+### Connect to the Board
+
+Connect the RedBear Nano 2 USB to a USB port on your computer. You should see an orange LED light up on the board.
+
+
+### Load the Bootloader and the Blinky Application Image
+
+Run the `newt load rbnano2_boot` command to load the bootloader onto the board:
+
+```no-highlight
+$ newt load rbnano2_boot
+Loading bootloader
+$
+```
+<br>
+Note: The flash memory on the RedBear Nano 2 comes write protected from the factory. If you get an error loading the bootloader and you are using a brand new chip, you need to clear the write protection from the debugger and then load the bootloader again. Run the `newt debug rbnano2_blinky` command and issue the following commands at the highlighted (gdb) prompts.
+
+```hl_lines="8 9 11 14"
+$newt debug rbnano2_blinky
+[~/dev/myproj/repos/apache-mynewt-core/hw/bsp/rb-nano2/rb-nano2_debug.sh ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/rb-nano2 ~/dev/myproj/bin/targets/rbnano2_blinky/app/apps/blinky/blinky]
+Open On-Chip Debugger 0.10.0-dev-snapshot (2017-03-28-11:24)
+Licensed under GNU GPL v2
+
+ ...
+
+(gdb) set {unsigned long}0x4001e504=2
+(gdb) x/1wx 0x4001e504
+0x4001e504:0x00000002
+(gdb) set {unsigned long}0x4001e50c=1
+Info : SWD DPIDR 0x2ba01477
+Error: Failed to read memory at 0x00009ef4
+(gdb) x/32wx 0x00
+0x0:0xffffffff0xffffffff0xffffffff0xffffffff
+0x10:0xffffffff0xffffffff0xffffffff0xffffffff
+0x20:0xffffffff0xffffffff0xffffffff0xffffffff
+0x30:0xffffffff0xffffffff0xffffffff0xffffffff
+0x40:0xffffffff0xffffffff0xffffffff0xffffffff
+0x50:0xffffffff0xffffffff0xffffffff0xffffffff
+0x60:0xffffffff0xffffffff0xffffffff0xffffffff
+0x70:0xffffffff0xffffffff0xffffffff0xffffffff
+(gdb)
+```
+
+<br>
+Run the `newt load rbnano2_blinky` command to load the Blinky application image onto the board.
+```no-highlight
+$ newt load rbnano2_blinky
+Loading app image into slot 1
+```
+
+You should see a blue LED on the board blink!
+
+Note: If the LED does not blink, try resetting your board.
+
+
+### Conclusion
+
+You have created, setup, compiled, loaded, and ran your first mynewt application for a RedBear Nano 2 board.
+
+We have more fun tutorials for you to get your hands dirty. Be bold and work on the OS with tutorials on [writing a test suite](unit_test.md) or try enabling additional functionality such as [remote comms](project-target-slinky.md) or [Bluetooth Low Energy](bletiny_project.md) on your current board.
+
+If you see anything missing or want to send us feedback, please do so by signing up for appropriate mailing lists on our [Community Page](../../community.md).
+
+Keep on hacking and blinking!
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/3a6e4ff0/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index ba52bb6..0080930 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -36,7 +36,7 @@ pages:
- toc: 'os/tutorials/STM32F303.md'
- 'Pinwheel Blinky': 'os/tutorials/pin-wheel-mods.md'
- 'Blinky on nRF52': 'os/tutorials/nRF52.md'
- - 'Run Blinky from SRAM, no bootloader': 'os/tutorials/blinky_sram_olimex.md'
+ - 'Blinky on RedBear Nano 2': 'os/tutorials/rbnano2.md'
- 'Add Console and Shell to Blinky': 'os/tutorials/blinky_console.md'
- 'Work with repositories':
- toc: 'os/tutorials/repo/add_repos.md'
@@ -50,6 +50,7 @@ pages:
- 'Project Slinky for remote comms':
- 'Slinky on sim device': 'os/tutorials/project-slinky.md'
- 'Slinky on Nordic nRF52 board': 'os/tutorials/project-target-slinky.md'
+ - 'Slinky on STM32 board': 'os/tutorials/project-stm32-slinky.md'
- 'Enable Newt Manager in any app': 'os/tutorials/add_newtmgr.md'
- 'Enable the OS Shell and Console': 'os/tutorials/add_shell.md'
- 'BLE app to check stats via console': 'os/tutorials/bletiny_project.md'
[3/7] incubator-mynewt-site git commit: 1)Added cputime module
documentation 2)Updated OS time module: - Use os_time_advance instead of
os_time_tick - Added os_get_uptime_usec - Added os_time_ms_to_ticks
Posted by ad...@apache.org.
1)Added cputime module documentation
2)Updated OS time module:
- Use os_time_advance instead of os_time_tick
- Added os_get_uptime_usec
- Added os_time_ms_to_ticks
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/be606a2e
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/be606a2e
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/be606a2e
Branch: refs/heads/develop
Commit: be606a2e0d73b6acc8eec70000763f62968fa01a
Parents: 19e0f48
Author: cwanda <wa...@happycity.com>
Authored: Thu Mar 30 14:35:38 2017 -0700
Committer: cwanda <wa...@happycity.com>
Committed: Thu Mar 30 15:33:46 2017 -0700
----------------------------------------------------------------------
docs/os/core_os/cputime/os_cputime.md | 43 +++++++++++++
.../core_os/cputime/os_cputime_delay_nsecs.md | 25 ++++++++
.../core_os/cputime/os_cputime_delay_ticks.md | 25 ++++++++
.../core_os/cputime/os_cputime_delay_usecs.md | 25 ++++++++
docs/os/core_os/cputime/os_cputime_get32.md | 23 +++++++
docs/os/core_os/cputime/os_cputime_init.md | 29 +++++++++
.../cputime/os_cputime_nsecs_to_ticks.md | 24 ++++++++
.../cputime/os_cputime_ticks_to_nsecs.md | 24 ++++++++
.../cputime/os_cputime_ticks_to_usecs.md | 24 ++++++++
.../os/core_os/cputime/os_cputime_timer_init.md | 65 ++++++++++++++++++++
.../cputime/os_cputime_timer_relative.md | 33 ++++++++++
.../core_os/cputime/os_cputime_timer_start.md | 34 ++++++++++
.../os/core_os/cputime/os_cputime_timer_stop.md | 30 +++++++++
.../cputime/os_cputime_usecs_to_ticks.md | 24 ++++++++
docs/os/core_os/time/os_get_uptime_usec.md | 24 ++++++++
docs/os/core_os/time/os_time.md | 6 +-
docs/os/core_os/time/os_time_advance.md | 22 +++++++
docs/os/core_os/time/os_time_ms_to_ticks.md | 29 +++++++++
docs/os/core_os/time/os_time_tick.md | 27 --------
mkdocs.yml | 22 ++++++-
20 files changed, 527 insertions(+), 31 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime.md b/docs/os/core_os/cputime/os_cputime.md
new file mode 100644
index 0000000..1a6ce06
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime.md
@@ -0,0 +1,43 @@
+# CPU Time
+
+The MyNewt `cputime` module provides high resolution time and timer support. This module is intended for use by BSPs, drivers, and network controllers.
+
+## Description
+
+The `cputime` API provides high resolution time and timer support. The module must be initialized, using the `os_cputime_init()` function, with the clock frequency to use. The module uses the `hal_timer` API, defined in hal/hal_timer.h, to access the hardware timers. It uses the hardware timer number specified by the `OS_CPUTIME_TIMER_NUM` system configuration setting.
+
+## Data Structures
+
+The module uses the following data structures:
+
+* `uint32_t` to represent `cputime`. Only the lower 32 bits of a 64 timer are used.
+* `struct hal_timer` to represent a cputime timer.
+
+## List of Functions
+
+The functions available in cputime are:
+
+| **Function** | **Description** |
+|-----------|-----------|
+| [os_cputime_delay_nsecs](os_cputime_delay_nsecs.md) | Delays for a specified number of nanoseconds. |
+| [os_cputime_delay_ticks](os_cputime_delay_ticks.md) | Delays for a specified number of ticks. |
+| [os_cputime_delay_usecs](os_cputime_delay_usecs.md) | Delays for a specified number of microseconds. |
+| [os_cputime_get32](os_cputime_get32.md) | Gets the current value of the cpu time.|
+| [os_cputime_init](os_cputime_init.md) | Initializes the cputime module. |
+| [os_cputime_nsecs_to_ticks](os_cputime_nsecs_to_ticks.md) | Converts the specified number of nanoseconds to number of ticks. |
+| [os_cputime_ticks_to_nsecs](os_cputime_ticks_to_nsecs.md) | Converts the specified number of ticks to number of nanoseconds. |
+| [os_cputime_ticks_to_usecs](os_cputime_ticks_to_usecs.md) | Converts the specified number of ticks to number of microseconds. |
+| [os_cputime_timer_init](os_cputime_timer_init.md) | Initializes a timer. |
+| [os_cputime_timer_relative](os_cputime_timer_relative.md) | Sets a timer to expire in the specified number of microseconds from the current time. |
+| [os_cputime_timer_start](os_cputime_timer_start.md) | Sets a timer to expire at the specified cputime. |
+| [os_cputime_timer_stop](os_cputime_timer_stop.md) | Stops a timer from running. |
+| [os_cputime_usecs_to_ticks](os_cputime_usecs_to_ticks.md) | Converts the specified number of microseconds to number of ticks. |
+
+## List of Macros
+
+These macros should be used to evaluate the time with respect to each other.
+
+* `CPUIME_LT(t1,t2)` -- evaluates to true if t1 is before t2 in time.
+* `CPUTIME_GT(t1,t2)` -- evaluates to true if t1 is after t2 in time
+* `CPUTIME_LEQ(t1,t2)` -- evaluates to true if t1 is on or before t2 in time.
+* `CPUTIME_GEQ(t1,t2)` -- evaluates to true if t1 is on or after t2 in time.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_delay_nsecs.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_delay_nsecs.md b/docs/os/core_os/cputime/os_cputime_delay_nsecs.md
new file mode 100644
index 0000000..c4e0e71
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_delay_nsecs.md
@@ -0,0 +1,25 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_delay_nsecs</font>
+
+```c
+void os_cputime_delay_nsecs(uint32_t nsecs)
+```
+Waits for a specified number of nanoseconds to elapse before returning.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `nsecs` | Number of nanoseconds to delay for.
+
+
+#### Returned values
+N/A
+
+#### Notes
+
+#### Example
+Delays for 250000 nsecs:
+```c
+os_cputime_delay_nsecs(250000)
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_delay_ticks.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_delay_ticks.md b/docs/os/core_os/cputime/os_cputime_delay_ticks.md
new file mode 100644
index 0000000..a744141
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_delay_ticks.md
@@ -0,0 +1,25 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_delay_ticks</font>
+
+```c
+void os_cputime_delay_ticks(uint32_t ticks)
+```
+Waits for a specified number of ticks to elapse before returning.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `ticks` | Number of ticks to delay for.
+
+
+#### Returned values
+N/A
+
+#### Notes
+
+#### Example
+Delays for 100000 ticks:
+```c
+os_cputime_delay_ticks(100000)
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_delay_usecs.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_delay_usecs.md b/docs/os/core_os/cputime/os_cputime_delay_usecs.md
new file mode 100644
index 0000000..86c1b43
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_delay_usecs.md
@@ -0,0 +1,25 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_delay_usecs</font>
+
+```c
+void os_cputime_delay_usecs(uint32_t usecs)
+```
+Waits for a specified number of microseconds to elapse before returning.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `usecs` | Number of microseconds to delay for.
+
+
+#### Returned values
+N/A
+
+#### Notes
+
+#### Example
+Delays for 250000 usecs:
+```c
+os_cputime_delay_usecs(250000)
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_get32.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_get32.md b/docs/os/core_os/cputime/os_cputime_get32.md
new file mode 100644
index 0000000..b2ee2c8
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_get32.md
@@ -0,0 +1,23 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_get32</font>
+
+```c
+uint32_t os_cputime_get32(void)
+```
+Gets the current cputime. If a timer is 64 bits, only the lower 32 bit is returned.
+
+#### Arguments
+N/A
+
+#### Returned values
+
+The current cputime.
+
+#### Notes
+
+#### Example
+
+```c
+uint32 cur_cputime;
+cur_cputime = os_cputime_get32();
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_init.md b/docs/os/core_os/cputime/os_cputime_init.md
new file mode 100644
index 0000000..2e119c8
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_init.md
@@ -0,0 +1,29 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_init</font>
+
+```c
+int os_cputime_init(uint32_t clock_freq)
+```
+Initializes the cputime module with the clock frequency (in HZ) to use for the timer resolution. It configures the hardware timer specified by the `OS_CPUTIME_TIMER_NUM` sysconfig value to run at the specified clock frequency.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `clock_freq` | Clock frequency, in HZ, for the timer resolution.
+
+
+#### Returned values
+
+0 on success and -1 on error.
+
+#### Notes
+This function must be called after os_init is called. It should only be called once and before any other timer API and hardware timers are used.
+
+#### Example
+A BSP package usually calls this function and uses the `OS_CPUTIME_FREQUENCY` sysconfig value for the clock frequency argument:
+```c
+int rc
+rc = os_cputime_init(MYNEWT_VAL(OS_CPUTIME_FREQUENCY));
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_nsecs_to_ticks.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_nsecs_to_ticks.md b/docs/os/core_os/cputime/os_cputime_nsecs_to_ticks.md
new file mode 100644
index 0000000..1666d58
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_nsecs_to_ticks.md
@@ -0,0 +1,24 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_nsecs_to_ticks</font>
+
+```c
+uint32_t os_cputime_nsecs_to_ticks(uint32_t nsecs)
+```
+Converts a specified number of nanoseconds to cputime ticks.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `nsecs` | Number of nanoseconds to convert to ticks.
+
+
+#### Returned values
+The number of ticks in `nsecs` nanoseconds.
+
+#### Notes
+
+#### Example
+```c
+uint32_t num_ticks;
+num_ticks = os_cputime_nsecs_to_ticks(1000000);
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_ticks_to_nsecs.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_ticks_to_nsecs.md b/docs/os/core_os/cputime/os_cputime_ticks_to_nsecs.md
new file mode 100644
index 0000000..dc6afa0
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_ticks_to_nsecs.md
@@ -0,0 +1,24 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_ticks_to_nsecs</font>
+
+```c
+uint32_t os_cputime_ticks_to_nsecs(uint32_t ticks)
+```
+Converts cputime ticks to nanoseconds.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `ticks` | Number of cputime ticks to convert to nanoseconds.
+
+
+#### Returned values
+The number of nanoseconds in `ticks` number of ticks.
+
+#### Notes
+
+#### Example
+```c
+uint32_t num_nsecs;
+num_nsecs = os_cputime_ticks_to_nsecs(1000000);
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_ticks_to_usecs.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_ticks_to_usecs.md b/docs/os/core_os/cputime/os_cputime_ticks_to_usecs.md
new file mode 100644
index 0000000..6fcc496
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_ticks_to_usecs.md
@@ -0,0 +1,24 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_ticks_to_usecs</font>
+
+```c
+uint32_t os_cputime_ticks_to_usecs(uint32_t ticks)
+```
+Converts a specified number of cputime ticks to microseconds.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `ticks` | Number of cputime ticks to convert to microseconds.
+
+
+#### Returned values
+The number of microseconds in `ticks` number of ticks.
+
+#### Notes
+
+#### Example
+```c
+uint32_t num_usecs;
+num_usecs = os_cputime_ticks_to_usecs(1000000);
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_timer_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_timer_init.md b/docs/os/core_os/cputime/os_cputime_timer_init.md
new file mode 100644
index 0000000..7fba485
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_timer_init.md
@@ -0,0 +1,65 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_timer_init</font>
+
+```c
+void os_cputime_timer_init(struct hal_timer *timer, hal_timer_cb fp, void *arg)
+```
+Initializes a cputime timer, indicated by `timer`, with a pointer to a callback function to call when the timer expires. When an optional opaque argument is specified, it is passed to the timer callback function.
+
+The callback function has the following prototype:
+```c
+void hal_timer_cb(void *arg)
+```
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `timer` | Pointer to the hal_timer to initialize. This value cannot be NULL.
+| `fp` | Pointer to the callback function to call when the timer expires. This value cannot be NULL.
+| `arg` | Optional opaque argument to pass to the hal timer callback function.
+
+
+#### Returned values
+N/A
+
+#### Notes
+
+#### Example
+
+Example of ble_ll setting up a response timer:
+
+```c
+ble_ll_wfr_timer_exp(void *arg)
+{
+ int rx_start;
+ uint8_t lls;
+
+ ...
+
+ /* If we have started a reception, there is nothing to do here */
+ if (!rx_start) {
+ switch (lls) {
+ case BLE_LL_STATE_ADV:
+ ble_ll_adv_wfr_timer_exp();
+ break;
+
+ ...
+
+ /* Do nothing here. Fall through intentional */
+ case BLE_LL_STATE_INITIATING:
+ default:
+ break;
+ }
+ }
+}
+
+void ble_ll_init(void)
+{
+ ...
+
+ os_cputime_timer_init(&g_ble_ll_data.ll_wfr_timer, ble_ll_wfr_timer_exp, NULL);
+
+ ...
+}
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_timer_relative.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_timer_relative.md b/docs/os/core_os/cputime/os_cputime_timer_relative.md
new file mode 100644
index 0000000..2d420a8
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_timer_relative.md
@@ -0,0 +1,33 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_timer_relative</font>
+
+```c
+void os_cputime_timer_relative(struct hal_timer *timer, uint32_t usecs)
+```
+Sets a timer to expire in the specified number of microseconds from the current time. The callback function for the timer is called when the timer expires.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `timer` | Pointer to an initialized hal_timer.
+| `usecs` | The number of microseconds to set the timer to expire from now.
+
+
+#### Returned values
+N/A
+
+#### Notes
+
+`timer` must be initialized using the `os_cputime_timer_init()` function before setting up a timer.
+
+#### Example
+`
+```c
+struct hal_timer mytimer;
+ ...
+
+os_cputime_timer_relative(&mytimer, 100);
+
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_timer_start.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_timer_start.md b/docs/os/core_os/cputime/os_cputime_timer_start.md
new file mode 100644
index 0000000..4cdba9c
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_timer_start.md
@@ -0,0 +1,34 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_timer_start</font>
+
+```c
+void os_cputime_timer_start(struct hal_timer *timer, uint32_t cputime)
+```
+Sets a timer to expire at the specified cputime. The callback function for the timer is called when the timer expires.
+
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `timer` | Pointer to an initialized hal_timer.
+| `cputime` | The cputime when the timer expires.
+
+
+#### Returned values
+N/A
+
+#### Notes
+
+`timer` must be initialized using the `os_cputime_timer_init()` function before setting up a timer.
+
+#### Example
+
+```c
+void
+ble_ll_wfr_enable(uint32_t cputime)
+{
+ os_cputime_timer_start(&g_ble_ll_data.ll_wfr_timer, cputime);
+}
+
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_timer_stop.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_timer_stop.md b/docs/os/core_os/cputime/os_cputime_timer_stop.md
new file mode 100644
index 0000000..5c38f06
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_timer_stop.md
@@ -0,0 +1,30 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_timer_stop</font>
+
+```c
+void os_cputime_timer_stop(struct hal_timer *timer)
+```
+Stops a timer from running. The timer is removed from the timer queue and interrupts are disabled if there are no more timers on the timer queue.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `timer` | Pointer to the timer to stop.
+
+
+#### Returned values
+N/A
+
+#### Notes
+
+#### Example
+
+```c
+void
+ble_ll_wfr_disable(void)
+{
+ os_cputime_timer_stop(&g_ble_ll_data.ll_wfr_timer);
+}
+
+```
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/cputime/os_cputime_usecs_to_ticks.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/cputime/os_cputime_usecs_to_ticks.md b/docs/os/core_os/cputime/os_cputime_usecs_to_ticks.md
new file mode 100644
index 0000000..dd6618d
--- /dev/null
+++ b/docs/os/core_os/cputime/os_cputime_usecs_to_ticks.md
@@ -0,0 +1,24 @@
+## <font color="F2853F" style="font-size:24pt">os_cputime_usecs_to_ticks</font>
+
+```c
+uint32_t os_cputime_usecs_to_ticks(uint32_t usecs)
+```
+Converts a specified number of microseconds to cputime ticks.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `usecs` | Number of microseconds to convert to ticks.
+
+
+#### Returned values
+The number of ticks in `usecs` nanoseconds.
+
+#### Notes
+
+#### Example
+```c
+uint32_t num_ticks;
+num_ticks = os_cputime_usecs_to_ticks(100);
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/time/os_get_uptime_usec.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_get_uptime_usec.md b/docs/os/core_os/time/os_get_uptime_usec.md
new file mode 100644
index 0000000..4859196
--- /dev/null
+++ b/docs/os/core_os/time/os_get_uptime_usec.md
@@ -0,0 +1,24 @@
+## <font color="F2853F" style="font-size:24pt">os_get_uptime_usec</font>
+
+```c
+int64_t os_get_uptime_usec(void)
+```
+Gets the time duration, in microseconds, since boot.
+
+#### Arguments
+
+N/A
+
+#### Returned values
+Time since boot in microseconds.
+
+#### Notes
+
+#### Example
+
+<Add text to set up the context for the example here>
+
+```c
+ int64_t time_since_boot;
+ time_since_boot = os_get_uptime_usec();
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/time/os_time.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time.md b/docs/os/core_os/time/os_time.md
index 52d0376..44b33f7 100644
--- a/docs/os/core_os/time/os_time.md
+++ b/docs/os/core_os/time/os_time.md
@@ -50,11 +50,13 @@ The functions available in time are:
| **Function** | **Description** |
|-----------|-------------|
+| [os_time_advance](os_time_advance.md) | Increments the OS time tick for the system. |
| [os_time_delay](os_time_delay.md) | Put the current task to sleep for the given number of ticks. |
| [os_time_get](os_time_get.md) | Get the current value of OS time. |
-| [os_time_tick](os_time_tick.md) | Increments the OS time tick for the system. |
-| [os_settimeofday](os_settimeofday.md) | Set the current time of day to the given time structs. |
+| [os_time_ms_to_ticks](os_time_ms_to_ticks.md) | Converts milliseconds to os ticks. |
+| [os_get_uptime_usec](os_get_uptime_usec.md) | Gets the time duration since boot. |
| [os_gettimeofday](os_gettimeofday.md) | Populate the given timeval and timezone structs with current time data. |
+| [os_settimeofday](os_settimeofday.md) | Set the current time of day to the given time structs. |
## List of Macros
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/time/os_time_advance.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time_advance.md b/docs/os/core_os/time/os_time_advance.md
new file mode 100644
index 0000000..fff1245
--- /dev/null
+++ b/docs/os/core_os/time/os_time_advance.md
@@ -0,0 +1,22 @@
+## <font color="F2853F" style="font-size:24pt">os_time_advance</font>
+
+```c
+void os_time_advance(int ticks)
+```
+Moves the OS time forward by the value specified in `ticks`. Typically, this is called in one place by the architecture specific OS code (kernel/os/src/arch) timer_handler which is in turn called by the BSP specific code assigned to drive the OS timer tick. See Porting Mynewt OS for details.
+
+#### Arguments
+
+| Arguments | Description |
+|-----------|-------------|
+| `ticks` | Number of ticks to move the OS time forward. |
+
+
+#### Returned values
+
+N/A
+
+#### Notes
+
+
+#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/docs/os/core_os/time/os_time_ms_to_ticks.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time_ms_to_ticks.md b/docs/os/core_os/time/os_time_ms_to_ticks.md
new file mode 100644
index 0000000..4508012
--- /dev/null
+++ b/docs/os/core_os/time/os_time_ms_to_ticks.md
@@ -0,0 +1,29 @@
+## <font color="F2853F" style="font-size:24pt">os_time_ms_to_ticks</font>
+
+```c
+int os_time_ms_to_ticks(uint32_t ms, uint32_t *out_ticks)
+```
+Converts milliseconds to OS ticks.
+
+#### Arguments
+| Arguments | Description |
+|-----------|-------------|
+| `ms` | Number of milliseconds to convert to OS ticks. |
+| `out_ticks` | Pointer to an uint32_t to return the number of OS ticks for `ms` milliseconds.|
+
+N/A
+
+#### Returned values
+`0`: Success
+<br>`OS_EINVAL`: Number of ticks is too large to fit in an uint32_t.
+
+N/A
+
+#### Notes
+
+
+#### Example
+```c
+unint32_t num_ticks;
+os_time_ms_to_ticks(50, &num_ticks);
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/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
deleted file mode 100644
index 1c217e1..0000000
--- a/docs/os/core_os/time/os_time_tick.md
+++ /dev/null
@@ -1,27 +0,0 @@
-## <font color="F2853F" style="font-size:24pt">os_time_tick</font>
-
-```c
-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](../porting/port_os) for details.
-
-#### Arguments
-
-N/A
-
-#### Returned values
-
-N/A
-
-#### Notes
-
-Called for every single tick by the architecture specific functions.
-
-#### Example
-
-<Add text to set up the context for the example here>
-
-```c
- os_time_tick();
-```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/be606a2e/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 0080930..915a1e7 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -89,12 +89,30 @@ pages:
- 'os_sched_set_current_task': 'os/core_os/context_switch/os_sched_set_current_task.md'
- 'os_sched_sleep': 'os/core_os/context_switch/os_sched_sleep.md'
- 'os_sched_wakeup': 'os/core_os/context_switch/os_sched_wakeup.md'
- - Time:
+ - CPU Time:
+ - toc: 'os/core_os/cputime/os_cputime.md'
+ - 'Functions':
+ - 'os_cputime_delay_nsecs': 'os/core_os/cputime/os_cputime_delay_nsecs.md'
+ - 'os_cputime_delay_ticks': 'os/core_os/cputime/os_cputime_delay_ticks.md'
+ - 'os_cputime_delay_usecs': 'os/core_os/cputime/os_cputime_delay_usecs.md'
+ - 'os_cputime_get32': 'os/core_os/cputime/os_cputime_get32.md'
+ - 'os_cputime_init': 'os/core_os/cputime/os_cputime_init.md'
+ - 'os_cputime_nsecs_to_ticks': 'os/core_os/cputime/os_cputime_nsecs_to_ticks.md'
+ - 'os_cputime_ticks_to_nsecs': 'os/core_os/cputime/os_cputime_ticks_to_nsecs.md'
+ - 'os_cputime_ticks_to_usecs': 'os/core_os/cputime/os_cputime_ticks_to_usecs.md'
+ - 'os_cputime_timer_init': 'os/core_os/cputime/os_cputime_timer_init.md'
+ - 'os_cputime_timer_relative': 'os/core_os/cputime/os_cputime_timer_relative.md'
+ - 'os_cputime_timer_start': 'os/core_os/cputime/os_cputime_timer_start.md'
+ - 'os_cputime_timer_stop': 'os/core_os/cputime/os_cputime_timer_stop.md'
+ - 'os_cputime_usecs_to_ticks': 'os/core_os/cputime/os_cputime_usecs_to_ticks.md'
+ - OS Time:
- toc: 'os/core_os/time/os_time.md'
- 'Functions':
+ - 'os_time_advance': 'os/core_os/time/os_time_advance.md'
- 'os_time_delay': 'os/core_os/time/os_time_delay.md'
- 'os_time_get': 'os/core_os/time/os_time_get.md'
- - 'os_time_tick': 'os/core_os/time/os_time_tick.md'
+ - 'os_time_ms_to_ticks': 'os/core_os/time/os_time_ms_to_ticks.md'
+ - 'os_get_uptime_usec': 'os/core_os/time/os_get_uptime_usec.md'
- 'os_gettimeofday': 'os/core_os/time/os_gettimeofday.md'
- 'os_settimeofday': 'os/core_os/time/os_settimeofday.md'
- Tasks:
[7/7] incubator-mynewt-site git commit: Merge branch
'newtmgr_vanity_domain' of
https://github.com/spoonofpower/incubator-mynewt-site into develop
Posted by ad...@apache.org.
Merge branch 'newtmgr_vanity_domain' of https://github.com/spoonofpower/incubator-mynewt-site into develop
This closes #166. This closes #165.
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/51ea3d02
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/51ea3d02
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/51ea3d02
Branch: refs/heads/develop
Commit: 51ea3d02f3bac30a2c387ef6459a5d2447243d35
Parents: 2b2cdfc b6c6411
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Mar 31 09:52:47 2017 -0700
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Mar 31 09:52:47 2017 -0700
----------------------------------------------------------------------
extras/newtmgr/index.html | 6 ++++++
extras/newtmgr/newtmgr/index.html | 6 ++++++
extras/newtmgr/nmxact/index.html | 6 ++++++
3 files changed, 18 insertions(+)
----------------------------------------------------------------------
[2/7] incubator-mynewt-site git commit: 1) Updated Task and Priority
Management tutorial: Uses defauilt main task instead of the blinky task for
the examples. Updated the picture use main task. Removed Comparing Task
Priority section. 2) Updated
Posted by ad...@apache.org.
1) Updated Task and Priority Management tutorial:
Uses defauilt main task instead of the blinky task for the examples.
Updated the picture use main task.
Removed Comparing Task Priority section.
2) Updated Log module documentation
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/19e0f48f
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/19e0f48f
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/19e0f48f
Branch: refs/heads/develop
Commit: 19e0f48ff80de0c727bb0c281707b0d1ecbc3f21
Parents: 3a6e4ff
Author: cwanda <wa...@happycity.com>
Authored: Wed Mar 29 19:16:48 2017 -0700
Committer: cwanda <wa...@happycity.com>
Committed: Wed Mar 29 19:16:48 2017 -0700
----------------------------------------------------------------------
docs/os/modules/logs/logs.md | 151 +++++++--------
docs/os/tutorials/pics/task_lesson.png | Bin 12931 -> 23822 bytes
docs/os/tutorials/tasks_lesson.md | 273 ++++++----------------------
3 files changed, 135 insertions(+), 289 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/19e0f48f/docs/os/modules/logs/logs.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/logs/logs.md b/docs/os/modules/logs/logs.md
index 7da1a77..63ce68c 100644
--- a/docs/os/modules/logs/logs.md
+++ b/docs/os/modules/logs/logs.md
@@ -1,17 +1,31 @@
-## Mynewt Logging
-
-Apache Mynewt has a logging package (`apache-mynewt-core/sys/log`) to support
-logging of information within a Mynewt application.
+##Logging
+Mynewt log package supports logging of information within a Mynewt application. It allows packages to define their own log streams with separate names. It also allows an application to control the output destination of logs.
<br>
-
###Description
-Logging API is provided in `apache-mynewt-core/sys/log/include/log/log.h`.
+In the Mynewt OS, the log package comes in two versions:
+
+* The `sys/log/full` package implements the complete log functionality and API.
+
+* The `sys/log/stub` package implements stubs for the API.
-It allows packages to define their own log streams with separate
-names. It also allows an application to control the output destinations
-of logs.
+Both packages export the `log` API, and any package that uses the log API must list `log` as a requirement in its `pkg.yml` file as follows:
+
+```no-highlight
+pkg.req_apis:
+ - log
+```
+
+<br>
+The application's `pkg.yml` file specifies the version of the log package to use.
+A project that requires the full logging capability must list the `sys/log/full` package as a dependency in its `pkg.yml` file:
+```no-highlight
+pkg.deps:
+ - sys/log/full
+```
+<br>
+You can use the `sys/log/stub` package if you want to build your application without logging to reduce code size.
<br>
@@ -24,19 +38,19 @@ these at compile time to ensure the code size limits are met.
A compiler flag `LOG_LEVEL` can be set in your `target.cflags` or within
your app `pkg.cflags` files to set the compile time log level. The
-log level are defined in `apache-mynewt-core/sys/log/include/log/log.h`
+log level are defined in `/sys/log/full/include/log/log.h`
but must be added by number to your `yml` file.
For example:
```no-highlight
- pkg.cflags -DLOG_LEVEL=8
+ pkg.cflags -DLOG_LEVEL=3
```
or
```no-highlight
- newt target set my_target cflags=-DLOG_LEVEL=8
+ newt target set my_target cflags=-DLOG_LEVEL=3
```
would both set the compile-time log level to `LOG_LEVEL_ERROR`. All logs
@@ -50,20 +64,18 @@ system.
### Log
-Each log stream requires a log structure to define its logging properties.
-It is typical for modules to extern this structure.
-
+Each log stream requires a `log` structure to define its logging properties.
<br>
### Log Handler
-To use logs, a log-handler is required, which is responsible for handling
-the I/O from the log. The log package comes with two pre-built log handlers.
+To use logs, a log handler that handles the I/O from the log is required. The log package comes with three pre-built log handlers:
* console -- streams log events directly to the console port. Does
not support walking and reading.
* cbmem -- writes/reads log events to a circular buffer. Supports walking
-and reading for access by `newtmgr` and shell commands.
+and reading for access by newtmgr and shell commands.
+* fcb -- writes/reads log events to a [flash circular buffer](/os/modules/fcb/fcb.md). Supports walking and reading for access by newtmgr and shell commands.
In addition, it is possible to create custom log handlers for other methods.
Examples may include
@@ -72,101 +84,96 @@ Examples may include
* Flat flash buffer
* Streamed over some other interface
-To use logging, you will not typically need to create your own log handler.
-You can use one of the two supplied above.
+To use logging, you typically do not need to create your own log handler. You can use one of the pre-built ones.
-In Mynewt today, each module will register its logs with a default log handler.
-Its up to the application to use or override this log handler for its
-specific purposes. See below for an example.
+A package or an application must define a variable of type `struct log` and register a log handler for it with the log package. It must call the `log_register()` function to specify the log handler to use:
-<br>
+```c
+log_register(char *name, struct log *log, const struct log_handler *lh, void *arg, uint8_t level)
-### Typical use of logging when writing an application
+```
-When writing an application that is using other's log modules, you
-may want to override their log handlers and log levels.
+The parameters are:
-Add the logging to your package file.
+* `name`- Name of the log stream.
+* `log` - Log instance to register,
+* `lh` - Pointer to the log handler. You can specify one of the pre-built ones:
+ * `&log_console_handler` for console
+ * `&log_cbm_handler` for circular buffer
+ * `&log_fcb_handler` for flash circular buffer
+* `arg` - Opaque argument that the specified log handler uses. The value of this argument depends on the log handler you specify:
+ * NULL for the `log_console_handler`.
+ * Pointer to an initialized `cbmem` structure (see `util/cbmem` package) for the `log_cbm_handler`.
+ * Pointer to an initialized `fcb_log` structure (see `fs/fcb` package) for the `log_fcb_handler`.
-```no-highlight
- pkg.deps:
- - "@apache-mynewt-core/sys/log"
-```
+Typically, a package that uses logging defines a global variable, such as `my_package_log`, of type `struct log`. The package can call the `log_register()` function with default values, but usually an application will override the logging properties and where to log to. There are two ways a package can allow an application to override the values:
-<br>
+* Define system configuration settings that an application can set and the package can then call the `log_register()` function with the configuration values.
+* Make the `my_package_log` variable external and let the application call the `log_register()` function to specify a log handler for its specific purpose.
-Initialize the logs in your startup code. It may look like this
+
+###Configuring Logging for Packages that an Application Uses
+Here is an example of how an application can set the log handlers for the logs of the packages that the application includes.
+
+In this example, the `package1` package defines the variable `package1_log` of type `struct log` and externs the variable. Similarly, the `package2` package defines the variable `package2_log` and externs the variable. The application sets logs for `package1` to use console and sets logs for `package2` to use a circular buffer.
```c
-#include <module1/module1.h>
-#include <module3/module2.h>
-#include <module3/module3.h>
+#include <package1/package1.h>
+#include <package2/package2.h>
+#include <util/cbmem.h>
+
#include <log/log.h>
-/* log to console */
-static struct log_handler app_log_handler;
+static uint32_t cbmem_buf[MAX_CBMEM_BUF];
+static struct cbmem cbmem;
+
-/* this has to be after all the modules are
- * initialized and have registered
- * their log modules */
void app_log_init(void)
{
- /* create a log handler for all logs . FOr this application
- ** send them directly to the console port */
- log_console_handler_init(&app_log_handler);
- ...
- /* set up logging for the modules appropriately */
- module1_log.log_level = LOG_LEVEL_WARN;
- module2_log.log_level = LOG_LEVEL_INFO;
- module3_log.log_level = LOG_LEVEL_DEBUG;
-
- /* set up a single handler for all modules */
- module1_log.log_handler = &app_log_handler;
- module2_log.log_handler = &app_log_handler;
- module3_log.log_handler = &app_log_handler;
+
+
+ log_register("package1_log", &package1_log, &log_console_handler, NULL, LOG_SYSLEVEL);
+
+ cbmem_init(&cbmem, cbmem_buf, MAX_CBMEM_BUF);
+ log_register("package2_log", &package2_log, &log_cbmem_handler, &cbmem, LOG_SYSLEVEL);
+
}
```
<br>
-### Typical use of Logging when writing a module
-
-When creating a package using its own logging, you can have this type of
-structure.
+### Implementing a Package that Uses Logging
+This example shows how a package logs to console. The package registers default logging properties to use the console, but allows an application to override the values. It defines the `my_package_log` variable and makes it external so an application can override log handler.
+Make the `my_package_log` variable external:
```c
/* my_package.h*/
/* pick a unique name here */
-extern struct log my_log;
+extern struct log my_package_log;
```
<br>
-with an implementation in your module that looks like this:
+Define the `my_package_log` variable and register the console log handler:
```c
-
/* my_package.c */
-struct log_handler log_console_handler;
-struct log my_log;
+struct log my_package_log;
{
...
- /* create a default handler for this log stream */
- log_console_handler_init(&log_console_handler);
/* register my log with a name to the system */
- log_register("log", &my_log, &log_console_handler);
-
- /* set up default log level for my package */
- my_log.log_level = LOG_LEVEL_DEBUG;
+ log_register("log", &my_package_log, &log_console_handler, NULL, LOG_LEVEL_DEBUG);
- LOG_DEBUG(&my_log, LOG_MODULE_DEFAULT, "bla");
- LOG_DEBUG(&my_log, LOG_MODULE_DEFAULT, "bab");
+ LOG_DEBUG(&my_package_log, LOG_MODULE_DEFAULT, "bla");
+ LOG_DEBUG(&my_package_log, LOG_MODULE_DEFAULT, "bab");
}
```
+###Log API and Log Levels
+For more information on the `log` API and log levels, see the `sys/log/full/include/log/log.h` header file.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/19e0f48f/docs/os/tutorials/pics/task_lesson.png
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/task_lesson.png b/docs/os/tutorials/pics/task_lesson.png
index 0ecb5e8..c10603f 100644
Binary files a/docs/os/tutorials/pics/task_lesson.png and b/docs/os/tutorials/pics/task_lesson.png differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/19e0f48f/docs/os/tutorials/tasks_lesson.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/tasks_lesson.md b/docs/os/tutorials/tasks_lesson.md
index 39ff6ab..c107395 100644
--- a/docs/os/tutorials/tasks_lesson.md
+++ b/docs/os/tutorials/tasks_lesson.md
@@ -1,5 +1,5 @@
-#Core OS Lesson: Tasks and Priority Management
+#Tasks and Priority Management
**Target Platform: Arduino M0 Pro** (or legacy Arduino Zero or Zero Pro, but not Arduino M0)
This lesson is designed to teach core OS concepts and strategies encountered when
@@ -21,12 +21,19 @@ You will need the following equipment:
- USB to Micro USB Cable
##Build Your Application
-To save time, we will simply modify the Blinky app. We'll add the Task Management code to
-the Blinky app. Follow the [*Arduino Zero Blinky tutorial*](http://mynewt.apache.org/os/tutorials/arduino_zero/)
+To save time, we will simply modify the Blinky application. We'll add the Task Management code to
+the Blinky application. Follow the [*Arduino Zero Blinky tutorial*](http://mynewt.apache.org/os/tutorials/arduino_zero/)
to create a new project and build your bootloader and application. Finally, build and
load the application to your Arduino to verify that everything is in order. Now let\u2019s get started!
+##Default Main Task
+During Mynewt system startup, Mynewt creates a default main task and executes the application `main()` function in the context of this task. The main task priority defaults to 127 and can be configured with the `OS_MAIN_TASK_PRIO` system configuration setting.
+
+
+The blinky application only has the `main` task. The `main()` function executes an infinite loop that toggles the led and sleeps for one second.
+<br>
##Create a New Task
+
The purpose of this section is to give an introduction to the important aspects of tasks
and how to properly initialize them. First, let\u2019s define a second task called `work_task`
in main.c (located in apps/blinky/src):
@@ -44,7 +51,7 @@ Next, let\u2019s take a look at what is required to initialize our new task.
### Task Stack
The task stack is an array of type `os_stack_t` which holds the program stack frames. Mynewt gives
us the ability to set the stack size for a task giving the application developer room to optimize
-memory usage. Since we\u2019re not short on memory, our `blinky_stack` and `work_stack` are plenty large
+memory usage. Since we\u2019re not short on memory, our `work_stack` is plenty large
for the purpose of this lesson. Notice that the elements in our task stack are of type `os_stack_t`
which are generally 32 bits, making our entire stack 1024 Bytes.
@@ -56,10 +63,8 @@ which are generally 32 bits, making our entire stack 1024 Bytes.
Note: The `OS_STACK_ALIGN` macro is used to align the stack based on the hardware architecture.
### Task Function
-The task function is essentially an infinite loop which waits for some \u201cevent\u201d to wake it up. In our
-Blinky app the task function, named `blinky_task_handler()`, is initially called when we call `os_start()`
-in `main()`. In general, the task function is where the majority of work is done by a task. Let\u2019s write
-a task function for `work_task` called `work_task_handler()`:
+
+A task function is essentially an infinite loop that waits for some \u201cevent\u201d to wake it up. In general, the task function is where the majority of work is done by a task. Let\u2019s write a task function for `work_task` called `work_task_handler()`:
```c
void
@@ -95,8 +100,9 @@ Let\u2019s set the priority of `work_task` to 0, because everyone knows that work i
### Initialization
To initialize a new task we use [*os_task_init()*](http://mynewt.apache.org/os/core_os/task/os_task_init/)
-which takes a number of arguments including our new task function, stack, and priority. Much like `blinky_task`,
-we\u2019re going to initialize `work_task` inside `init_tasks` to keep our main function clean. We'll set the task stack here and pass it to the `os_task_init()` function as well.
+which takes a number of arguments including our new task function, stack, and priority.
+
+Add the `init_tasks()` function to initialize `work_task` to keep our main function clean.
```c
int
@@ -106,23 +112,44 @@ init_tasks(void)
os_stack_t *work_stack;
work_stack = malloc(sizeof(os_stack_t)*WORK_STACK_SIZE);
- assert(pstack);
+ assert(work_stack);
os_task_init(&work_task, "work", work_task_handler, NULL,
WORK_TASK_PRIO, OS_WAIT_FOREVER, work_stack,
WORK_STACK_SIZE);
- tasks_initialized = 1;
return 0;
}
```
+<br>
+
+Add the call to `init_tasks()` in `main()` before the `while` loop:
+
+```c
+
+int
+main(int argc, char **argv)
+{
+
+ ...
+
+ /* Initialize the work task */
+ init_tasks();
+
+ while (1) {
+ ...
+ }
+}
+```
+<br>
And that\u2019s it! Now run your application using the newt run command.
```
$ newt run arduino_blinky 0.0.0
```
+<br>
When GDB appears press C then Enter to continue and \u2026 *wait, why doesn't our LED blink anymore?*
-
+<br>
#### Review
Before we run our new app, let\u2019s review what we need in order to create a task. This is a general case for a new task called mytask:
@@ -146,7 +173,7 @@ mytask_handler(void *arg)
}
}
```
-**3)** Initialize task before calling `os_start()`:
+**3)** Initialize the task:
```c
os_task_init(&mytask, "mytask", mytask_handler, NULL,
MYTASK_PRIO, OS_WAIT_FOREVER, mytask_stack,
@@ -160,11 +187,9 @@ place of) the lower priority task which is *running*. When a lower priority task
priority task, the lower priority task\u2019s context data (stack pointer, registers, etc.) is saved and the new
task is switched in.
-In our example, `work_task` has a higher priority than `blinky_task` and, because it is never put into a
-*sleep* state, holds the processor focus on its context. Let\u2019s give `work_task` a delay and some simulated
-work to keep it busy. Because the delay is measured in os ticks, the actual number of ticks per second is
-dependent on the board. Therefore, we multiply `OS_TICKS_PER_SEC`, which is defined in the MCU, by the
-number of seconds we wish to delay.
+In our example, `work_task` (priority 0) has a higher priority than the `main` task (priority 127). Since `work_task` is never put into a *sleep* state, it holds the processor focus on its context.
+
+Let\u2019s give `work_task` a delay and some simulated work to keep it busy. The delay is measured in os ticks and the actual number of ticks per second is dependent on the board. We multiply `OS_TICKS_PER_SEC`, which is defined in the MCU, by the number of seconds we wish to delay.
```c
void
@@ -182,24 +207,25 @@ work_task_handler(void *arg)
int i;
for(i = 0; i < 1000000; ++i) {
/* Simulate doing a noticeable amount of work */
- hal_gpio_set(g_led_pin);
+ hal_gpio_write(g_led_pin, 1);
}
- os_time_delay(3*OS_TICKS_PER_SECOND);
+ os_time_delay(3 * OS_TICKS_PER_SEC);
}
}
```
+<br>
+In order to notice the LED changing, modify the time delay in `main()` to blink at a higher frequency.
-In order to notice the LED changing, modify the time delay in `blinky_task_handler()` to blink at a higher frequency.
```c
os_time_delay(OS_TICKS_PER_SEC/10);
```
+<br>
Before we run the app, let\u2019s predict the behavior. With the newest additions to `work_task_handler()`,
-our first action will be to sleep for three seconds. This will allow `blinky_task` to take over the CPU
-and blink to its heart\u2019s content. After three seconds, `work_task` will wake up and be made *ready to run*,
-causing it to preempt `blinky_task`. The LED will then remain lit for a short period while `work_task`
+our first action will be to sleep for three seconds. This allows the `main` task, running `main()`, to take over the CPU and blink to its heart\u2019s content. After three seconds, `work_task` will wake up and be made *ready to run*.
+This causes it to preempt the `main` task. The LED will then remain lit for a short period while `work_task`
loops, then blink again for another three seconds while `work_task` sleeps.
-Voila, you should see that our prediction was correct!
+You should see that our prediction was correct!
###Priority Management Considerations
@@ -211,198 +237,11 @@ Some tasks, such as the Shell task, execute quickly and require almost instantan
the Shell task should be given a high priority. On the other hand, tasks which may be communicating over
a network, or processing data, should be given a low priority in order to not hog the CPU.
-The diagram below showcases the different scheduling patterns we. would expect from swapping blinky and
-work tasks priorities.
+The diagram below shows the different scheduling patterns we would expect when we set the `work_task` priority higher and lower than the `main` task priority.
-
+
-In the second case where `blinky_task` has a higher priority, the \u201cwork\u201d done by `work_task` would be
-executed during the millisecond delays in `blinky_task`, saving us idle time compared to the first case.
+In the second case where the `main` task has a higher priority, `work_task` runs and executes \u201cwork\u201d when
+the `main` task sleeps, saving us idle time compared to the first case.
**Note:** Defining the same priority for two tasks leads to somewhat undefined behavior and should be avoided.
-
-##Comparing Priority Strategies
-
-Instead of stepping through a bunch of changes to our blinky app, clone my task lesson application from
-github and copy an existing target.
-
-Change directory into apps and clone the repository to get our new
-files:
-```
-$ cd apps
-$ git clone https://github.com/bgiori/mynewt_tasks_lesson.git
-```
-Change directory back to your project root and copy the arduino_blinky target to a new target called task_tgt.
-```c
-$ newt target copy arduino_blinky task_tgt
-```
-Set a new app location.
-```c
-$ newt target set task_tgt app=apps/mynewt_tasks_lesson
-```
-
-Now let\u2019s take a look at our new code. First, notice that we have abandoned blinking, instead
-choosing to use the [*console*](http://mynewt.apache.org/latest/os/modules/console/console/)
-and [*shell*](http://mynewt.apache.org/latest/os/modules/shell/shell/) to follow our tasks through execution.
-
-Additionally, we have a number of different tasks:
-
-- **Task A** (`a_task`):
- - **Priority**: 3 \u2192 2
- - **Description**: Task A is supposed to represent a task which frequently does a small amount
- of work, such as one which rapidly polls a sensor for data. Much like `blinky_task`, Task A will
- loop 10,000 times then wait 1 millisecond. Priority is changed by `timer_task` after the first simulation.
-
-- **Task B** (`b_task`):
- - **Priority**: 2 \u2192 3
- - **Description**: Task B is supposed to represent a task which does a large amount of work
- relatively infrequently, such as one which sends/receives data from the cloud. Like work\_task,
- Task B will loop 1,000,000 times then wait 3 seconds. Priority is changed by timer\_task after
- the first simulation.
-
-- **Timer Task** (`timer_task`):
- - **Priority**: 1
- - **Description**: With default settings, Timer Task will wait 20 seconds then print the first
- simulations data for Task A and B. Timer task will then swap A and B\u2019s priorities and restart the
- simulation. After the second simulation, timer will again print simulation data then compare the
- two and calculate a final speedup (simulation2 / simulation1).
-
-- **Shell Task**:
- - **Priority**: 0
- - **Description**: Task used by Shell behind the scenes to communicate with the serial port.
-
-### Connecting to the Serial Console
-
-Before running our new app, we must first connect to the serial console. First make sure the
-mynewt_arduino_zero repository is set to the develop branch. (Remove once changes have been
-moved to master).
-```
-$ cd repos/mynewt_arduino_zero
-$ git checkout develop
-```
-
-You should already be familiar with the [Serial Port Setup and Configuration](../get_started/serial_access.md), but if
-you're not, you can go there now and then come back.
-
-### Output Analysis
-
-Run our new target, task_tgt, and you should see an output similar to this:
-
-```
-Starting First Simulation...
-1: Task B: 0%
-78: Task B: 1%
-155: Task B: 2%
-257: Task B: 3%
-359: Task B: 4%
-461: Task B: 5%
-
-<snip>
-
-========== Timer Expired ==========
-
- >>> Task A <<<
- Priority: 3
- Loop count: 162849
- Cycle count: 16.28
- Run time: 1.40 sec
-
- >>> Task B <<<
- Priority: 2
- Loop count: 1345852
- Cycle count: 1.34
- Run time: 17.0 sec
-
- Total loops: 1508709
-
-20023: Switching priorities and restarting...
-20111: Task A looped
-20113: Task B: 0%
-20191: Task B: 1%
-20297: Task A looped
-20356: Task B: 2%
-20483: Task A looped
-20545: Task B: 3%
-20669: Task A looped
-20734: Task B: 4%
-20855: Task A looped
-20923: Task B: 5%
-
-<snip>
-
-========== Timer Expired ==========
-
- >>> Task A <<<
- Priority: 2
- Loop count: 1080000
- Cycle count: 108.0
- Run time: 9.28 sec
-
- >>> Task B <<<
- Priority: 3
- Loop count: 830356
- Cycle count: 0.83
- Run time: 10.72 sec
-
- Total loops: 1910404
-
-40058:
-
- Final Speedup (Sim2 / Sim1): 1.26
-
-```
-
-The console output reaffirms our previous prediction and makes both the scheduling differences
-and subsequent efficiency boost far more apparent. Let\u2019s take a look at scheduling differences
-before we delve into efficiency.
-
-In the first case, where Task B\u2019s priority is higher than that of Task A, we see A get starved
-by Task B\u2019s long execution time. **Starvation** occurs when one task hogs the processor, essentially
-\u201cstarving\u201d other tasks which also need to run. At the end of the first 20 second simulation period,
-Task A has only run for 1.4 seconds compared to task B\u2019s 17 second running time \u2013 ouch. As explained
-before, processes which are expected to run for long periods of time (e.g. network communication,
-data processing) should be given higher priorities in order to combat starvation.
-
-In the second simulation with priorities swapped, we can see Task B only running during the
-millisecond delays when Task A is *sleeping*. Although having Task B only run during these
-delays slows its execution time, we benefit from un-starving Task A and using the processor
-at a higher efficiency.
-
-The bottom line speedup gives us an immediate and clear indication that we have improved our
-ability to process work (i.e throughput). In our second run, we processed an additional 400,000
-loop iterations, equating to a 26% increase in efficiency. On a standard multi-core processor
-found in every modern PC, a 1.26 speedup would be an ok result to adding multithreading capabilities
-to a serial program. However, we accomplished this by simply setting priorities on a single core
-processor \u2013 not bad!
-
-NOTE: Usually the the term \u201cspeedup\u201d is used within a parallel programming context and refers
-to the change in execution time between a serial and parallel program executing over the same
-problem. In this case we\u2019re using the term loosely to illustrate the priority change\u2019s effect
-on scheduling and throughput in our specific context.
-
-### Efficiency Isn\u2019t Everything
-
-Using the processor during every OS tick isn\u2019t always the best course of action. If we modify
-Task A\u2019s delay to a tenth of a millisecond and turn off the console output, we can boost our
-speedup to 1.44. This, however, reduces our ability to process work from Task B who ends up
-only completing 18% of its work cycle after the second simulation. That would mean, at that
-rate, Task B would take over a minute to finish one cycle.
-
-Feel free to play around with the testing parameters to study the different changes yourself!
-
-###Conclusion
-
-Moving forward, tasks are just the tip of the iceberg. The [*scheduler*](http://mynewt.apache.org/latest/os/core_os/context_switch/context_switch/),
-[*event queues*](http://mynewt.apache.org/latest/os/core_os/event_queue/event_queue/),
-[*semaphores*](http://mynewt.apache.org/latest/os/core_os/semaphore/semaphore/), and
-[*mutexes*](http://mynewt.apache.org/latest/os/core_os/mutex/mutex/) also add to tasks functionality,
-increasing our ability as the developer to control greater numbers of tasks more intricately. For
-example, when we switch the tasks priority, we have to tell the scheduler that our tasks priorities
-have changed, allowing us us to use priorities dynamically. When running multiple tasks, logging
-through either the built-in [*Logs*](http://mynewt.apache.org/latest/os/modules/logs/logs/) module
-(not covered in this lesson) or through the serial console/shell can be very useful for debugging
-your application. In the end, the way you manage your tasks depends on the context of your
-application. You should assign priorities based on execution time, urgency, and frequency, among
-other things.
-
-Keep blinking and happy hacking!
[5/7] incubator-mynewt-site git commit: mynewt.apache.org/newtmgr
vanity import domain
Posted by ad...@apache.org.
mynewt.apache.org/newtmgr vanity import domain
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/b6c6411d
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/b6c6411d
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/b6c6411d
Branch: refs/heads/develop
Commit: b6c6411d7e5d5d47248b87c5cd3c742a9e279999
Parents: b8cab1b
Author: spoonofpower <sp...@gmail.com>
Authored: Thu Mar 30 20:19:28 2017 -0700
Committer: spoonofpower <sp...@gmail.com>
Committed: Thu Mar 30 20:19:28 2017 -0700
----------------------------------------------------------------------
extras/newtmgr/index.html | 6 ++++++
extras/newtmgr/newtmgr/index.html | 6 ++++++
extras/newtmgr/nmxact/index.html | 6 ++++++
3 files changed, 18 insertions(+)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b6c6411d/extras/newtmgr/index.html
----------------------------------------------------------------------
diff --git a/extras/newtmgr/index.html b/extras/newtmgr/index.html
new file mode 100644
index 0000000..c58608a
--- /dev/null
+++ b/extras/newtmgr/index.html
@@ -0,0 +1,6 @@
+<html>
+ <head>
+ <meta name="go-import" content="mynewt.apache.org/newtmgr git https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newtmgr.git">
+ <meta http-equiv="refresh" content="0; url=/">
+ </head>
+</html>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b6c6411d/extras/newtmgr/newtmgr/index.html
----------------------------------------------------------------------
diff --git a/extras/newtmgr/newtmgr/index.html b/extras/newtmgr/newtmgr/index.html
new file mode 100644
index 0000000..c58608a
--- /dev/null
+++ b/extras/newtmgr/newtmgr/index.html
@@ -0,0 +1,6 @@
+<html>
+ <head>
+ <meta name="go-import" content="mynewt.apache.org/newtmgr git https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newtmgr.git">
+ <meta http-equiv="refresh" content="0; url=/">
+ </head>
+</html>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b6c6411d/extras/newtmgr/nmxact/index.html
----------------------------------------------------------------------
diff --git a/extras/newtmgr/nmxact/index.html b/extras/newtmgr/nmxact/index.html
new file mode 100644
index 0000000..c58608a
--- /dev/null
+++ b/extras/newtmgr/nmxact/index.html
@@ -0,0 +1,6 @@
+<html>
+ <head>
+ <meta name="go-import" content="mynewt.apache.org/newtmgr git https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newtmgr.git">
+ <meta http-equiv="refresh" content="0; url=/">
+ </head>
+</html>
[6/7] incubator-mynewt-site git commit: Change task_lesson.png to
transparent background
Posted by ad...@apache.org.
Change task_lesson.png to transparent background
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/2b2cdfc7
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/2b2cdfc7
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/2b2cdfc7
Branch: refs/heads/develop
Commit: 2b2cdfc7c833087447e60cb676aa3a4b3680aadf
Parents: 65ca020
Author: cwanda <wa...@happycity.com>
Authored: Thu Mar 30 20:57:11 2017 -0700
Committer: cwanda <wa...@happycity.com>
Committed: Thu Mar 30 20:57:11 2017 -0700
----------------------------------------------------------------------
docs/os/tutorials/pics/task_lesson.png | Bin 23822 -> 25723 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/2b2cdfc7/docs/os/tutorials/pics/task_lesson.png
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/task_lesson.png b/docs/os/tutorials/pics/task_lesson.png
index c10603f..4b09506 100644
Binary files a/docs/os/tutorials/pics/task_lesson.png and b/docs/os/tutorials/pics/task_lesson.png differ
[4/7] incubator-mynewt-site git commit: 1) Updated Enable Wi-Fi on
Arduino Zero tutorial to Use Arduino MKR1000 board. 2) Fixed typo in Project
Slinky for NRF52.
Posted by ad...@apache.org.
1) Updated Enable Wi-Fi on Arduino Zero tutorial to Use Arduino MKR1000 board.
2) Fixed typo in Project Slinky for NRF52.
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/65ca0207
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/65ca0207
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/65ca0207
Branch: refs/heads/develop
Commit: 65ca02079230e2bc4808cbe95d63f58518eafe7b
Parents: be606a2
Author: cwanda <wa...@happycity.com>
Authored: Thu Mar 30 18:30:37 2017 -0700
Committer: cwanda <wa...@happycity.com>
Committed: Thu Mar 30 18:30:37 2017 -0700
----------------------------------------------------------------------
docs/os/tutorials/pics/mkr1000-jlink.jpg | Bin 0 -> 146645 bytes
docs/os/tutorials/pics/mkr1000-serial.jpg | Bin 0 -> 73565 bytes
docs/os/tutorials/project-target-slinky.md | 2 +-
docs/os/tutorials/wi-fi_on_arduino.md | 326 ++++++++++++------------
mkdocs.yml | 2 +-
5 files changed, 171 insertions(+), 159 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/65ca0207/docs/os/tutorials/pics/mkr1000-jlink.jpg
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/mkr1000-jlink.jpg b/docs/os/tutorials/pics/mkr1000-jlink.jpg
new file mode 100755
index 0000000..cfa09ca
Binary files /dev/null and b/docs/os/tutorials/pics/mkr1000-jlink.jpg differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/65ca0207/docs/os/tutorials/pics/mkr1000-serial.jpg
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/mkr1000-serial.jpg b/docs/os/tutorials/pics/mkr1000-serial.jpg
new file mode 100755
index 0000000..f4e3819
Binary files /dev/null and b/docs/os/tutorials/pics/mkr1000-serial.jpg differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/65ca0207/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 61eb4c5..6e567dd 100644
--- a/docs/os/tutorials/project-target-slinky.md
+++ b/docs/os/tutorials/project-target-slinky.md
@@ -161,7 +161,7 @@ $
### Connect Newtmgr with the Board using a Serial Connection
-Set up serial connection from your computer to the nRF52-DK board (See [Serial Port Setup](/os/get_started/serial_access.md)).
+Set up a serial connection from your computer to the nRF52-DK board (See [Serial Port Setup](/os/get_started/serial_access.md)).
Locate the port, in the /dev directory on your computer, that the serial connection uses. It should be of the type `tty.usbserial-<some identifier>`.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/65ca0207/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 5f7085b..132968e 100644
--- a/docs/os/tutorials/wi-fi_on_arduino.md
+++ b/docs/os/tutorials/wi-fi_on_arduino.md
@@ -1,53 +1,57 @@
-## Start Wi-Fi on Arduino Zero
-
-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.
+## Enable Wi-Fi on Arduino MKR1000
+This tutorial shows you how to enable Wi-Fi on an Arduino MKR1000 board and connect to a Wi-Fi network.
### Prerequisites
-Before tackling this tutorial, it's best to read about Mynewt in the [Introduction](../get_started/get_started) section of this documentation.
-
-### Equipment
-
-You will need the following equipment
+Ensure that you have met the following prerequisites before continuing with this tutorial:
-* An Arduino Zero, Zero Pro or M0 Pro.
-**Note:** Mynewt has not been tested on Arduino M0 which has no internal debugger support.
-* An [Arduino Wi-Fi Shield 101](https://www.adafruit.com/product/2891)
-* A computer that can connect to the Arduino board over USB
-* A local Wi-Fi network that the computer is connected to and which the Arduino board can join.
-* A USB cable (Type A to micro B) that can connect the computer to the Arduino (or a USB hub between the computer and the Arduino board)
-* The Mynewt Release
+* Have an Arduino MKR1000 board.
+* Have Internet connectivity to fetch remote Mynewt components.
+* Have a computer to build a Mynewt application and connect to the board over USB.
+* Have a Micro-USB cable to connect the board and the computer.
+* Have local Wi-Fi network that the computer is connected to and that the MKR1000 board can join.
+* Have a [Serial Port Setup](/os/get_started/serial_access.md).
+* Have a [Segger J-Link Debug Probe](https://www.segger.com/jlink-debug-probes.html).
+* Have a [J-Link 9 pin Cortex-M Adapter](https://www.segger.com/jlink-adapters.html#CM_9pin) that allows JTAG, SWD and SWO connections between J-Link and Cortex M based target hardware systems
+* Install the [Segger JLINK Software and documentation pack](https://www.segger.com/jlink-software.html).
+* Install the Newt tool and toolchains (See [Basic Setup](/os/get_started/get_started.md)).
+* Create a 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](/os/get_started/project_create).
+* Read the Mynewt OS [Concepts](/os/get_started/vocabulary.md) section.
-### Install Mynewt and Newt
+### Create a Project
+Create a new project if you do not have an existing one. You can skip this step and proceed to [fetch external packages](#
+fetchexternal) if you already created a project.
-* 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.
+Run the following commands to create a new project:
-```
- user@~/dev$ cd $GOPATH/src/mynewt.apache.org/newt
- user@~/dev/go/src/mynewt.apache.org/newt$ git remote -v
- origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git (fetch)
- origin https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git (push)
- user@~/dev/go/src/mynewt.apache.org/newt$ git pull origin develop
- remote: Counting objects: 59, done.
- <snip>
- user@~/dev/go/src/mynewt.apache.org/newt$ cd newt
- user@~/dev/go/src/mynewt.apache.org/newt/newt$ go install
- user@~/dev$ cd ~/dev
+```no-highlight
+ $ mkdir ~/dev
+ $ cd ~/dev
+ $ newt new arduinowifi
+ Downloading project skeleton from apache/incubator-mynewt-blinky...
+ Installing skeleton in arduinowifi...
+ Project arduinowifi successfully created.
+ $ cd arduinowifi
+ $ newt install
+ apache-mynewt-core
+ $
```
-* If you have not already done so, create a project as shown in the Quick Start guide on how to [Create Your First Project](../get_started/project_create.md). Skip the testing and building the project steps in that tutorial since you will be defining a target for your Arduino board in this tutorial.
+<br>
-Let's say your new project is named `arduinowifi`. You will henceforth be working in that project directory.
+###<a name="fetchexternal"></a> Fetch External Packages
-<br>
+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 git
+hub 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
+the repository to the `project.yml` file in your base project directory.
-### Fetch External Packages, Set correct version to download
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.
@@ -63,9 +67,8 @@ 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.
-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"
+```hl_lines="6 14 15 16 17 18"
$ more project.yml
project.name: "my_project"
@@ -75,24 +78,21 @@ project.repositories:
repository.apache-mynewt-core:
type: github
- vers: 0-dev
+ vers: 1-latest
user: apache
repo: incubator-mynewt-core
repository.mynewt_arduino_zero:
type: github
- vers: 0-dev
+ vers: 1-latest
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.):
-
+<br>
+Install the project dependencies using the `newt install` command (you can specify ```-v``` for verbose output):
```no-highlight
$ newt install
apache-mynewt-core
@@ -100,187 +100,201 @@ mynewt_arduino_zero
$
```
-<br>
-
-### Create your bootloader target
+**NOTE:** If there has been a new release of a repo used in your project since you last installed it, the `1-latest` version for the repo in the `project.yml` file will refer to the new release and will not match the installed files. In that case you will get an error message saying so and you will need to run `newt upgrade` to overwrite the existing files with the latest codebase.
-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.
+<br>
-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.
+### Create a Target for the Bootloader
+You need to create two targets for the MKR1000 board, one for the bootloader and one for the `winc1500_wifi` application.
+<br>
+Run the following `newt target` commands, from your project directory, to create a bootloader target. We name the target `mkr1000_boot`.
```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 set arduino_boot build_profile=optimized
+$ newt target create mkr1000_boot
+$ newt target set mkr1000_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_mkr1000
+$ newt target set mkr1000_boot app=@apache-mynewt-core/apps/boot
+$ newt target set mkr1000_boot build_profile=optimized
+$ newt target set mkr1000_boot syscfg=BSP_ARDUINO_ZERO_PRO=1
```
<br>
-If you have an Arduino Zero Pro or M0 Pro, you have to set the following next:
+### Create a Target for the Wi-Fi Application
+Run the following `newt target` commands to create a target for the `winc1500_wifi` application in the arduino repository. We name the application target `mkr1000_wifi`.
```
-$ newt target set arduino_boot features=arduino_zero_pro
+$ newt target create mkr1000_wifi
+$ newt target set mkr1000_wifi app=@mynewt_arduino_zero/apps/winc1500_wifi
+$ newt target set mkr1000_wifi bsp=@mynewt_arduino_zero/hw/bsp/arduino_mkr1000
+$ newt target set mkr1000_wifi build_profile=debug
+$ newt target set mkr1000_boot syscfg=BSP_ARDUINO_ZERO_PRO=1
```
+<br>
+### Build the Bootloader
-If you have an Arduino Zero, you have to set the following instead:
+Run the `newt build mkr1000_boot` command to build the bootloader:
-```
-$ newt target set arduino_boot features=arduino_zero
+```no-highlight
+$ newt build mkr1000_boot
+Building target targets/mkr1000_boot
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
+Compiling repos/apache-mynewt-core/crypto/mbedtls/src/aes.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
+Compiling repos/apache-mynewt-core/apps/boot/src/boot.c
+
+ ...
+
+Archiving util_mem.a
+Linking ~/dev/arduinowifi/bin/targets/mkr1000_boot/app/apps/boot/boot.elf
+Target successfully built: targets/mkr1000_boot
+$
```
<br>
+### Build the Wi-Fi Application
-### Build your bootloader
-
-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:
+Run the `newt build mkr1000_wifi` command to build the wi-fi application image:
```no-highlight
-$ newt build arduino_boot
-Compiling boot.c
-Archiving boot.a
-Compiling fs_cli.c
-Compiling fs_dirent.c
-Compiling fs_file.c
-Compiling fs_mkdir.c
-<snip>
-App successfully built: ~/dev/arduinowifi/bin/arduino_boot/apps/boot/boot.elf
+$newt build mkr1000_wifi
+Building target targets/mkr1000_wifi
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_ec256.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_rsa.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/image_validate.c
+Compiling repos/apache-mynewt-core/boot/bootutil/src/loader.c
+ ...
+
+Archiving util_mem.a
+Linking ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.elf
+Target successfully built: targets/mkr1000_wifi
+$
```
-
-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>
+### Sign and Create the Wi-Fi Application Image
-### Build your blinky app
+Run the `newt create-image mkr1000_wifi 1.0.0` command to sign and create an image file for the Wi-Fi application. You may assign an arbitrary version (e.g. 1.0.0) number.
-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 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
+```no-highlight
+$newt create-image mkr1000_wifi 1.0.0
+Compiling bin/targets/mkr1000_wifi/generated/src/mkr1000_wifi-sysinit-app.c
+Archiving mkr1000_wifi-sysinit-app.a
+Linking ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.elf
+App image succesfully generated: ~/dev/arduinowifi/bin/targets/mkr1000_wifi/app/apps/winc1500_wifi/winc1500_wifi.img
+$
```
<br>
-You can now build the target, with ```newt build```:
+### Connect to the Board
-```no-highlight
-$ newt build arduino_wifi
-Building target targets/arduino_wifi
-Compiling main.c
-Archiving winc1500_wifi.a
-Compiling fs_cli.c
-Compiling fs_dirent.c
-Compiling fs_file.c
-Compiling fs_mkdir.c
-<snip>
-Linking winc1500_wifi.elf
-App successfully built: ~/dev/arduinowifi/bin/arduino_wifi/apps/winc1500_wifi/winc1500_wifi.elf
-```
-<font color="#FF0000"> Congratulations! </font> You have successfully built your Wi-Fi application. Now it's time to load both the bootloader and application onto the target.
+* Connect your computer to the MKR1000 board with the Micro-USB cable.
+* Connect the debug probe to the JTAG port on the board using the Jlink 9-pin adapter and cable.
<br>
+
+<br>
+<p>
+<br>
+Mynewt will download and debug the target through this port. You should see a green LED come on and indicates the board has power.
-### Connect the Target
-
-Place the Wi-Fi shield on top of the Arduino board and push it in place, making sure the pins and pinholes are properly aligned. Connect your computer to the Arduino board with the Micro-USB cable through the Programming Port as shown below. Mynewt will download and debug the target through this port. You should see a little green LED come on. That means the board has power.
+<br>
-No external debugger is required. The Arduino boards listed in this tutorial come with an internal debugger that can be accessed by Mynewt.
-The picture below shows the setup.
+### Load the Bootloader onto the Board
-
+Run the `newt load mkr1000_boot` command to load the bootloader onto the board:
+```no-highlight
+$ newt load mkr1000_boot
+Loading bootloader
+$
+```
<br>
-### Download the Bootloader
-
-Execute the command to download the bootloader.
+### Load the Wi-Fi Application Image onto the Board
+Run the `newt load arduino_wifi` command to load the wifi application onto the board:
-```c
- $ newt load arduino_boot
+```no-highlight
+$ newt load mkr1000_wifi
+Loading app image into slot 1
+$
```
-If the newt tool finishes without error, that means the bootloader has been
-successfully loaded onto the target.
-
<br>
+### Setup a Serial Connection Between Your Computer and the Board
-<font color="#FF0000"> Reminder if you are using Docker: </font> When working with actual hardware, remember that each board has an ID. If you swap boards and do not refresh the USB Device Filter on the VirtualBox UI, the ID might be stale and the Docker instance may not be able to see the board correctly. For example, you may see an error message like `Error: unable to find CMSIS-DAP device` when you try to load or run an image on the board. In that case, you need to click on the USB link in VirtualBox UI, remove the existing USB Device Filter (e.g. "Atmel Corp. EDBG CMSIS-DAP[0101]") by clicking on the "Removes selected USB filter" button, and add a new filter by clicking on the "Adds new USB filter" button.
-
+Set up a serial connection from your computer to the MKR1000 board (See [Serial Port Setup](/os/get_started/serial_access.md)). On the MKR1000 board, the TX pin is PIN 14 and the RX pin in PIN 13.
<br>
-
-### 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.
-
+<br>
+
+<br>
+<p>
+<br>
+Locate the port, in the /dev directory on your computer, that the serial connection uses. It should be of the type `tty.usbserial-<some identifier>`.
```no-highlight
-$ newt create-image arduino_wifi 1.0.0
-App image succesfully generated: ~/dev/arduinowifi/bin/arduino_wifi/apps/winc1500_wifi/winc1500_wifi.img
-Build manifest: ~/dev/arduinowifi/bin/arduino_wifi/apps/winc1500_wifi/manifest.json
-$ newt load arduino_wifi
-Loading image
+$ ls /dev/tty*usbserial*
+/dev/tty.usbserial-1d13
$
```
-<br>
-
### Start Wi-Fi via console
-Use a terminal emulation program to communicate with the board over the serial port. This tutorial shows a Minicom set up. You will have to find out what the usbserial port number is on your computer/laptop (`ls /dev`) and specify it as the -D flag value. Type `wifi start` to start Wi-Fi.
-
-```hl_lines="12"
-$ minicom -D /dev/tty.usbmodem141122 -b 115200
-
+Use a terminal emulation program to communicate with the board over the serial port. This tutorial shows a Minicom set up. Run the minicom command with the serial port you located on your computer:
+```no-highlight
+$ minicom -D /dev/tty.usbserial-1d13 -b 115200
+```
+<br>
+Type `wifi start` to start Wi-Fi.
+```hl_lines="9"
Welcome to minicom 2.7
-OPTIONS:
-Compiled on Nov 24 2015, 16:14:21.
-Port /dev/tty.usbmodem141122, 10:11:40
+OPTIONS:
+Compiled on Mar 18 2016, 04:59:47.
+Port /dev/tty.usbserial-1d13, 17:06:09
Press Meta-Z for help on special keys
wifi start
-119470:(APP)(INFO)Chip ID 1502b1
+3293703:(APP)(INFO)Chip ID 1503a0
(APP)(INFO)Firmware ver : 19.4.4
(APP)(INFO)Min driver ver : 19.3.0
-(APP)(INFO)Curr driver ver: 19.3.0
-wifi_init : 0
+(APP)(INFO)Curr driver ver: 19.3.0
+wifi_init : 0
```
+<br>
+Connect to the local Wi-Fi network. Note that the MKR1000 board only supports 2.4 GHz Wi-Fi networks.
-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`.
+Run the `wifi connect` command and specify your network <ssid> and <password>. After you are connected to your wi-fi network, run the `net service` command to start network services.
```hl_lines="1 8"
-wifi connect <Wi-Fi network name> <password>
-16906:wifi_request_scan : 0
-17805:scan_results 16: 0
-17816:wifi_connect : 0
-18813:connect_done : 0
-18821:dhcp done 192.168.0.117
-18932:get sys time response 2016.8.2-18.4.43
-net service
+wifi connect <ssid> <password>
+3362937:wifi_request_scan : 0
+3363843:scan_results 9: 0
+3363855:wifi_connect : 0
+3364852:connect_done : 0
+3364861:dhcp done 10.0.0.4
+3365470:get sys time response 2017.3.31-0.9.57
+net service
```
-### Establish TCP connection and talk!
+The board is connected to the network succesfully and has IP address: 10.0.0.4
-From a terminal on your computer/laptop, try telneting to ports 7, 9, or 19 using the IP address your board has been assigned. Type something on this terminal and see the console output (on minicom). Can you see the difference in the behaviors?
+### Establish TCP Connection and Talk!
-```
-$ telnet 192.168.0.117 7
-Trying 192.168.0.117...
-Connected to 192.168.0.117.
+From a terminal on your computer, telnet to ports 7, 9, or 19 using the IP address your board has been assigned. Type something on this terminal and see the console output (on minicom). Can you see the difference in the behaviors?
+
+```no-highlight
+$telnet 10.0.0.4 7
+Trying 10.0.0.4...
+Connected to 10.0.0.4.
Escape character is '^]'.
hello
hello
@@ -290,5 +304,3 @@ $
```
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!
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/65ca0207/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 915a1e7..5249608 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -44,7 +44,7 @@ pages:
- 'Turn project into a Repo': 'os/tutorials/repo/create_repo.md'
- 'Access a private Repo': 'os/tutorials/repo/private_repo.md'
- 'Tasks and Priority Management': 'os/tutorials/tasks_lesson.md'
- - 'Enable Wi-Fi on Arduino Zero': 'os/tutorials/wi-fi_on_arduino.md'
+ - 'Enable Wi-Fi on Arduino MKR1000': 'os/tutorials/wi-fi_on_arduino.md'
- 'Write a Test Suite for a Package': 'os/tutorials/unit_test.md'
- 'Events and Event Queues': 'os/tutorials/event_queue.md'
- 'Project Slinky for remote comms':