You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by ad...@apache.org on 2016/11/15 01:20:46 UTC
[01/19] incubator-mynewt-site git commit: added a presentation and
modified section titles on landing page
Repository: incubator-mynewt-site
Updated Branches:
refs/heads/master a58d2e130 -> 6a5535405
added a presentation and modified section titles on landing page
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/eedefaf9
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/eedefaf9
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/eedefaf9
Branch: refs/heads/master
Commit: eedefaf99f196a4813a8252f31f70a7f7a060cb9
Parents: a58d2e1
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 4 12:05:50 2016 -0700
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 7 17:57:15 2016 -0800
----------------------------------------------------------------------
custom-theme/landing.html | 4 ++--
custom-theme/talks.html | 20 ++++++++++++++++++++
2 files changed, 22 insertions(+), 2 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/eedefaf9/custom-theme/landing.html
----------------------------------------------------------------------
diff --git a/custom-theme/landing.html b/custom-theme/landing.html
index 746145b..5136271 100644
--- a/custom-theme/landing.html
+++ b/custom-theme/landing.html
@@ -5,7 +5,7 @@
<div class="highlight">
<img src="/img/FWdist.png">
- <h2>Designed to manage</h2>
+ <h2>Operations ready</h2>
<p>Ready your IoT network of billions for remote monitoring, troubleshooting, management, and upgrade.</p>
@@ -64,7 +64,7 @@
<div class="highlight">
<img src="/img/cross-platform.png">
- <h2>Cross platforms</h2>
+ <h2>Cross-platform</h2>
<p> Pick one MCU now. Migrate to another later. </p>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/eedefaf9/custom-theme/talks.html
----------------------------------------------------------------------
diff --git a/custom-theme/talks.html b/custom-theme/talks.html
index 0d215f2..28f7a4f 100644
--- a/custom-theme/talks.html
+++ b/custom-theme/talks.html
@@ -6,6 +6,26 @@
</div>
<div class="row">
+
+ <div class="col-xs-12 col-md-6">
+
+<iframe width="480" height="360" src="https://www.youtube.com/embed/4xRbGMDcMu8?list=PLbzoR-pLrL6pRFP6SOywVJWdEHlmQE51q" frameborder="0" allowfullscreen style="padding: 20px;"></iframe>
+ </div>
+
+ <div class="col-xs-12 col-md-6">
+ <h3>Apache Mynewt Overview</h3>
+ </br>
+ @OpenIoT Summit, Berlin, Germany, October 2016
+ </br>
+ <b>Speaker: Sterling Hughes, CTO, Runtime Inc.</b>
+
+ <p>
+ The case for an open-source OS for connected devices that ensures their commercial and operational readiness in a comprehensive, easy way is presented. The talk details the architecture of the resulting Apache Mynewt OS and the rationale behind some of the key design and implementation decisions.
+ </p>
+ </div>
+</div>
+
+<div class="row">
<div class="col-xs-12 col-md-6">
<h3>MyNewt technical Overview</h3>
<br>
[18/19] incubator-mynewt-site git commit: Updated About page with
feature support and roadmap
Posted by ad...@apache.org.
Updated About page with feature support and roadmap
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/cb39e9b2
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/cb39e9b2
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/cb39e9b2
Branch: refs/heads/master
Commit: cb39e9b2225283ad67f5543e2520ccbc853aa858
Parents: 2c68c2d
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 16:49:03 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 16:49:03 2016 -0800
----------------------------------------------------------------------
custom-theme/about.html | 13 +++++++++++--
docs/about.md | 11 +++++------
2 files changed, 16 insertions(+), 8 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/cb39e9b2/custom-theme/about.html
----------------------------------------------------------------------
diff --git a/custom-theme/about.html b/custom-theme/about.html
index 440fcf3..b5bfd2c 100644
--- a/custom-theme/about.html
+++ b/custom-theme/about.html
@@ -7,10 +7,14 @@
Real-time operating system kernel (Mynewt OS)
</li>
<li>
+ Bluetooth Low Energy stack (BLE 4.2) - choose HOST only or CONTROLLER only or FULL stack.
+ </li>
+ <li>
Command line package management and build system (Newt Tool)
</li>
<li>
- Hardware Abstraction Layer unifying common MCU features
+ Hardware Abstraction Layer unifying common MCU features, see <a href="http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201606.mbox/%3C06CB0682-8F67-4C3F-93E4-6A20444487A1%40apache.org%3E"> discussion thread </a>
+
</li>
<li>
Board Support Infrastructure
@@ -22,7 +26,12 @@
Signed images and remote firmware upgrade
</li>
<li>
- Bluetooth Low Energy stack (BLE 4.2)
+ Serial upgrade of bootloader, see <a href="https://lists.apache.org/list.html?dev@mynewt.apache.org:dfr=June%201|dto=2016-11-14:%22newtmgr%20over%20Serial%22"> discussion thread </a>
+ </li>
+ <li>
+ WiFi support via socket interface, join <a href="https://lists.apache.org/list.html?dev@mynewt.apache.org:dfr=June%201|dto=2016-11-14:%22socket%20interface%22"> discussion here </a>
+ <li>
+ Basic IP support
</li>
<br>
<p> For features in each release, see <a href="https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Project"> Release Notes </a>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/cb39e9b2/docs/about.md
----------------------------------------------------------------------
diff --git a/docs/about.md b/docs/about.md
index a842db4..a0b10f5 100644
--- a/docs/about.md
+++ b/docs/about.md
@@ -2,12 +2,11 @@
Some upcoming features:
-* Host-only BLE stack
-* Serial upgrade of image in bootloader
-* HAL redesign to abstract across a diverse set of chip peripherals ([View discussion thread](http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201606.mbox/%3C06CB0682-8F67-4C3F-93E4-6A20444487A1%40apache.org%3E))
-* HAL for SPI access (master and slave)
-* Ability for drivers to turn on/off low power settings automatically
-
+* Full IP support
+* Low power support with ability for drivers to turn on/off low power settings automatically
+* Sensor API, see <a href="https://lists.apache.org/list.html?dev@mynewt.apache.org:dfr=June%201|dto=2016-11-14:%22Sensor%20Drivers%22"> discussion thread </a>
+* Support for MIPS architecture
+* Support for additional boards
<font color="#F2853F"> The detailed roadmap is tracked on [JIRA for Mynewt](https://issues.apache.org/jira/browse/MYNEWT/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel). </font>
[05/19] incubator-mynewt-site git commit: Added STM32F4DISCOVERY to
the list of supported boards
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/tutorials.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/tutorials.md b/docs/os/tutorials/tutorials.md
index b66222e..59e2dae 100644
--- a/docs/os/tutorials/tutorials.md
+++ b/docs/os/tutorials/tutorials.md
@@ -1,6 +1,6 @@
## Tutorials
-If the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner.
+If the introduction to Mynewt has piqued your interest and you want to familiarize yourself with some of its functionality, this series of tutorials is for you. The lessons are aimed at the beginner.
The full list of tutorials can be seen in the navigation bar on the left. New ones are being constantly added and will show up there automatically.
@@ -10,14 +10,6 @@ The full list of tutorials can be seen in the navigation bar on the left. New on
* You have installed Docker container of Newt tool and toolchains or you have installed them natively on your machine
* You have created a new project space (directory structure) and populated it with the core code repository (apache-mynewt-core) or know how to as explained in [Creating Your First Project](../get_started/project_create).
-* You have at least one of the supported development boards:
- * [STM32F3 discovery kit from ST Micro](STM32F303.md)
- * [Arduino Zero hardware](arduino_zero.md)
- * [Olimex/STM32F407ZGT6 Cortex-M4 hardware](olimex.md)
- * [nRF52 Development Kit from Nordic Semiconductor](nRF52.md)
-
-The Nordic nrf52 developer kit supports Bluetooth Low Energy. We are always looking to add new hardware to the list, so if you want to develop the required Board Support Package (bsp) and/or Hardware Abstraction Layer (HAL) for a new board, you can look [here](../core_os/porting/port_os/) to get started.
-
<br>
@@ -30,14 +22,14 @@ The tutorials fall into a few broad categories. Some examples in each category a
* [Blinky on Olimex/STM32F407ZGT6 Cortex-M4 hardware](olimex.md)
* [Blinky on STM32F3 discovery kit from ST Micro](STM32F303.md)
* [Blinky on nRF52 Development Kit from Nordic Semiconductor](nRF52.md) **Note:** This supports BLE.
-
+
<br>
-
+
* Tweaking available apps to customize behavior e.g. making a more exciting LED blink pattern
* [Pinwheel Blinky on STM32F3 discovery board](pin-wheel-mods.md)
-
+
<br>
-
+
* Navigating the code and adding functionality
* [Adding more repositories to your project](repo/add_repos.md)
* [Adding a unit test for a package](unit_test.md)
@@ -47,18 +39,16 @@ The tutorials fall into a few broad categories. Some examples in each category a
* Bluetooth Low Energy
* [Running the example BLE app included in the repo](bletiny_project.md)
- * [Working with another example BLE app for a peripheral device](bleprph/bleprph-intro.md)
<br>
-* Using NewtMgr
+* Using NewtMgr
* [Enabling remote communication with a device running Mynewt OS](project-slinky.md)
<br>
-* Additional network connectivity
- * [Connect Arduino to a Wi-Fi network](wi-fi_on_arduino.md)
**Send us an email on the dev@ mailing list if you have comments or suggestions!** If you haven't joined the mailing list, you will find the links [here](../../community.md).
<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/quick-start.md
----------------------------------------------------------------------
diff --git a/docs/quick-start.md b/docs/quick-start.md
index 3ad3afb..002c487 100644
--- a/docs/quick-start.md
+++ b/docs/quick-start.md
@@ -18,7 +18,7 @@ Start a new project as explained under [Create Your First Project](/DOCSLINK/os/
* When you [Create Your First Project](/DOCSLINK/os/get_started/project_create/) you define a simulated target and run Project Blinky, the Hello World equivalent in the embedded world.
-* If you have one of the supported [boards](/), you can make real LEDs blink in [Project Blinky](/DOCSLINK/os/tutorials/arduino_zero/). Simply choose the appropriate tutorial for the board and proceed.
+* If you have one of the supported [boards](../), you can make real LEDs blink in [Project Blinky](/DOCSLINK/os/tutorials/arduino_zero/). Simply choose the appropriate tutorial for the board and proceed.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 62fd598..9a31988 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -5,12 +5,8 @@ theme_dir: 'custom-theme'
pages:
- Home: 'index.md'
-- Pages:
- - Bluetooth Low Energy 4.2: 'pages/ble.md'
- - Mynewt OS Security: 'pages/securitybullets.md'
- Quick Start: 'quick-start.md'
- About: 'about.md'
-- Talks: 'talks.md'
- Download: 'download.md'
- Community: 'community.md'
- Events: 'events.md'
@@ -32,7 +28,7 @@ pages:
- 'Blinky on Arduino Zero': 'os/tutorials/arduino_zero.md'
- 'Blinky on Arduino Primo': 'os/tutorials/blinky_primo.md'
- 'Blinky on Olimex': 'os/tutorials/olimex.md'
- - 'Blinky on STM32F303':
+ - 'Blinky on STM32F303':
- toc: 'os/tutorials/STM32F303.md'
- 'Pinwheel Blinky': 'os/tutorials/pin-wheel-mods.md'
- 'Blinky on nRF52': 'os/tutorials/nRF52.md'
@@ -41,23 +37,18 @@ pages:
- toc: 'os/tutorials/repo/add_repos.md'
- 'Upgrade a repo': 'os/tutorials/repo/upgrade_repo.md'
- 'Turn project into a repo': 'os/tutorials/repo/create_repo.md'
- - 'A Sample Lesson':
- - 'Lesson Unit on Tasks and Priority Management': 'os/tutorials/tasks_lesson.md'
- - 'Enable Wi-Fi on Arduino Zero': 'os/tutorials/wi-fi_on_arduino.md'
- 'Write a Test Suite for a Package': 'os/tutorials/unit_test.md'
- 'Air-quality Sensor project': 'os/tutorials/air_quality_sensor.md'
- 'Add task to manage multiple events': 'os/tutorials/event_queue.md'
- - 'Project Slinky for remote comms':
- - 'Slinky on sim device': 'os/tutorials/project-slinky.md'
- - 'Slinky on STM32 board': 'os/tutorials/project-target-slinky.md'
- - 'Enable newtmgr in any app': 'os/tutorials/add_newtmgr.md'
+ - 'Enable remote comms on sim device': 'os/tutorials/project-slinky.md'
+ - 'Enable remote comms on STM32 board': 'os/tutorials/project-target-slinky.md'
- 'BLE app to check stats via console': 'os/tutorials/bletiny_project.md'
- 'BLE peripheral project':
- toc: 'os/tutorials/bleprph/bleprph-intro.md'
- 'Service Registration': 'os/tutorials/bleprph/bleprph-svc-reg.md'
- 'Characteristic Access': 'os/tutorials/bleprph/bleprph-chr-access.md'
- 'Advertising': 'os/tutorials/bleprph/bleprph-adv.md'
- - 'GAP Event Callbacks': 'os/tutorials/bleprph/bleprph-gap-event.md'
+ - 'Connection Callbacks': 'os/tutorials/bleprph/bleprph-conn.md'
- 'BLE iBeacon': 'os/tutorials/ibeacon.md'
- 'BLE HCI interface': 'os/tutorials/blehci_project.md'
- OS User Guide:
@@ -207,8 +198,6 @@ pages:
- 'shell_cmd_register': 'os/modules/shell/shell_cmd_register.md'
- 'shell_nlip_input_register': 'os/modules/shell/shell_nlip_input_register.md'
- 'shell_nlip_output': 'os/modules/shell/shell_nlip_output.md'
- - Split Images:
- - toc: 'os/modules/split/split.md'
- Bootloader:
- toc: 'os/modules/bootloader/bootloader.md'
- 'Functions':
@@ -325,19 +314,6 @@ pages:
- 'json_encode_object_key': 'os/modules/json/json_encode_object_key.md'
- 'json_encode_object_start': 'os/modules/json/json_encode_object_start.md'
- 'json_read_object': 'os/modules/json/json_read_object.md'
- - Flash Circular Buffer:
- - toc: 'os/modules/fcb/fcb.md'
- - 'Functions':
- - 'fcb_init': 'os/modules/fcb/fcb_init.md'
- - 'fcb_append': 'os/modules/fcb/fcb_append.md'
- - 'fcb_append_finish': 'os/modules/fcb/fcb_append_finish.md'
- - 'fcb_walk': 'os/modules/fcb/fcb_walk.md'
- - 'fcb_getnext': 'os/modules/fcb/fcb_getnext.md'
- - 'fcb_rotate': 'os/modules/fcb/fcb_rotate.md'
- - 'fcb_append_to_scratch': 'os/modules/fcb/fcb_append_to_scratch.md'
- - 'fcb_is_empty': 'os/modules/fcb/fcb_is_empty.md'
- - 'fcb_offset_last_n': 'os/modules/fcb/fcb_offset_last_n.md'
- - 'fcb_clear': 'os/modules/fcb/fcb_clear.md'
- Stats:
- toc: 'os/modules/stats/stats.md'
- Logs:
@@ -356,110 +332,8 @@ pages:
- 'Initialize controller': 'network/ble/ini_stack/ble_controller_ini.md'
- 'Initialize parent task': 'network/ble/ini_stack/ble_parent_ini.md'
- 'Initialize host': 'network/ble/ini_stack/ble_host_ini.md'
- - NimBLE Host API:
- - toc: 'network/ble/ble_hs/ble_hs.md'
- - 'Return codes': 'network/ble/ble_hs/ble_hs_return_codes.md'
-
- - 'Init and config':
- - toc: 'network/ble/ble_hs/init/init.md'
- - 'Definitions':
- - 'Init and config definitions': 'network/ble/ble_hs/init/definitions/init_defs.md'
- - 'Functions':
- - 'ble_hs_start': 'network/ble/ble_hs/init/functions/ble_hs_start.md'
- - 'ble_hs_init': 'network/ble/ble_hs/init/functions/ble_hs_init.md'
- - 'ble_hs_synced': 'network/ble/ble_hs/init/functions/ble_hs_synced.md'
-
- - 'GAP':
- - toc: 'network/ble/ble_hs/ble_gap/ble_gap.md'
- - 'Definitions':
- - 'GAP definitions': 'network/ble/ble_hs/ble_gap/definitions/ble_gap_defs.md'
- - 'Functions':
- - 'ble_gap_adv_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_active.md'
- - 'ble_gap_adv_rsp_set_fields': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_fields.md'
- - 'ble_gap_adv_set_fields': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields.md'
- - 'ble_gap_adv_start': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md'
- - 'ble_gap_adv_stop': 'network/ble/ble_hs/ble_gap/functions/ble_gap_adv_stop.md'
- - 'ble_gap_conn_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_active.md'
- - 'ble_gap_conn_cancel': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_cancel.md'
- - 'ble_gap_conn_find': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_find.md'
- - 'ble_gap_conn_rssi': 'network/ble/ble_hs/ble_gap/functions/ble_gap_conn_rssi.md'
- - 'ble_gap_connect': 'network/ble/ble_hs/ble_gap/functions/ble_gap_connect.md'
- - 'ble_gap_disc': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc.md'
- - 'ble_gap_disc_active': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc_active.md'
- - 'ble_gap_disc_cancel': 'network/ble/ble_hs/ble_gap/functions/ble_gap_disc_cancel.md'
- - 'ble_gap_security_initiate': 'network/ble/ble_hs/ble_gap/functions/ble_gap_security_initiate.md'
- - 'ble_gap_terminate': 'network/ble/ble_hs/ble_gap/functions/ble_gap_terminate.md'
- - 'ble_gap_update_params': 'network/ble/ble_hs/ble_gap/functions/ble_gap_update_params.md'
- - 'ble_gap_wl_set': 'network/ble/ble_hs/ble_gap/functions/ble_gap_wl_set.md'
-
- - 'GATT client':
- - toc: 'network/ble/ble_hs/ble_gattc/ble_gattc.md'
- - 'Definitions':
- - 'GATT client definitions': 'network/ble/ble_hs/ble_gattc/definitions/ble_gattc_defs.md'
- - 'Functions':
- - 'ble_gattc_disc_all_chrs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_chrs.md'
- - 'ble_gattc_disc_all_dscs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_dscs.md'
- - 'ble_gattc_disc_all_svcs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_all_svcs.md'
- - 'ble_gattc_disc_chrs_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_chrs_by_uuid.md'
- - 'ble_gattc_disc_svc_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_disc_svc_by_uuid.md'
- - 'ble_gattc_exchange_mtu': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu.md'
- - 'ble_gattc_find_inc_svcs': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_find_inc_svcs.md'
- - 'ble_gattc_indicate': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_indicate.md'
- - 'ble_gattc_notify': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify.md'
- - 'ble_gattc_notify_custom': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_notify_custom.md'
- - 'ble_gattc_read': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read.md'
- - 'ble_gattc_read_by_uuid': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_by_uuid.md'
- - 'ble_gattc_read_long': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_long.md'
- - 'ble_gattc_read_mult': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_read_mult.md'
- - 'ble_gattc_write': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write.md'
- - 'ble_gattc_write_flat': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_flat.md'
- - 'ble_gattc_write_long': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_long.md'
- - 'ble_gattc_write_no_rsp': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp.md'
- - 'ble_gattc_write_no_rsp_flat': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_no_rsp_flat.md'
- - 'ble_gattc_write_reliable': 'network/ble/ble_hs/ble_gattc/functions/ble_gattc_write_reliable.md'
-
- - 'GATT server':
- - toc: 'network/ble/ble_hs/ble_gatts/ble_gatts.md'
- - 'Definitions':
- - 'GATT server definitions': 'network/ble/ble_hs/ble_gatts/definitions/ble_gatts_defs.md'
- - 'Functions':
- - 'ble_gatts_count_cfg': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_count_cfg.md'
- - 'ble_gatts_count_resources': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_count_resources.md'
- - 'ble_gatts_find_chr': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_chr.md'
- - 'ble_gatts_register_svcs': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_register_svcs.md'
- - 'ble_gatts_add_svcs': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_add_svcs.md'
- - 'ble_gatts_find_svc': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_svc.md'
- - 'ble_gatts_find_dsc': 'network/ble/ble_hs/ble_gatts/functions/ble_gatts_find_dsc.md'
-
- - 'Identity':
- - toc: 'network/ble/ble_hs/ble_hs_id/ble_hs_id.md'
- - 'Functions':
- - 'ble_hs_id_copy_addr': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_copy_addr.md'
- - 'ble_hs_id_gen_rnd': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_gen_rnd.md'
- - 'ble_hs_id_set_rnd': 'network/ble/ble_hs/ble_hs_id/functions/ble_hs_id_set_rnd.md'
-
- - 'ATT':
- - toc: 'network/ble/ble_hs/ble_att/ble_att.md'
- - 'Functions':
- - 'ble_att_mtu': 'network/ble/ble_hs/ble_att/functions/ble_att_mtu.md'
- - 'ble_att_set_preferred_mtu': 'network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu.md'
- - 'ble_att_svr_read_local': 'network/ble/ble_hs/ble_att/functions/ble_att_svr_read_local.md'
- - 'ble_att_svr_write_local': 'network/ble/ble_hs/ble_att/functions/ble_att_svr_write_local.md'
-
- - 'Other':
- - toc: 'network/ble/ble_hs/other/other.md'
- - 'Functions':
- - 'ble_eddystone_set_adv_data_uid': 'network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_uid.md'
- - 'ble_eddystone_set_adv_data_url': 'network/ble/ble_hs/other/functions/ble_eddystone_set_adv_data_url.md'
- - 'ble_hs_mbuf_att_pkt': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_att_pkt.md'
- - 'ble_hs_mbuf_from_flat': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_from_flat.md'
- - 'ble_hs_mbuf_to_flat': 'network/ble/ble_hs/other/functions/ble_hs_mbuf_to_flat.md'
- - 'ble_ibeacon_set_adv_data': 'network/ble/ble_hs/other/functions/ble_ibeacon_set_adv_data.md'
- - 'ble_uuid_128_to_16': 'network/ble/ble_hs/other/functions/ble_uuid_128_to_16.md'
- - 'ble_uuid_16_to_128': 'network/ble/ble_hs/other/functions/ble_uuid_16_to_128.md'
-
- - bletiny app Usage API:
- - toc: 'network/ble/bletiny/bletiny_api.md'
+ - API for bletiny app:
+ - toc: 'network/ble/bletiny_api.md'
- 'GAP in bletiny': 'network/ble/bletiny/bletiny_GAP.md'
- 'GATT in bletiny': 'network/ble/bletiny/bletiny_GATT.md'
- 'Advertisement Data Fields': 'network/ble/bletiny/bletiny_advdata.md'
@@ -501,14 +375,14 @@ markdown_extensions:
pygments_style: xcode
extra:
- version: 'develop'
+ version: 'v0_9_0'
versions:
- label: 'develop'
branch: 'develop'
- latest: True
+ latest: False
- label: '0.9.0'
branch: 'v0_9_0'
- latest: False
+ latest: True
doc_path: 'os/introduction'
chapters:
Chapter 1 - Get Started: 'The chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.'
@@ -529,6 +403,6 @@ extra:
location: "Grand Ballroom C, JW Marriott Resort and Spa Hotel, Las Vegas, NV"
date: 'Time: 16:10 - 16:45, Date: 26 September 2016, 2016'
-copyright: 'Copyright © 2015 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 Apache and the Apache feather logo are trademarks of The Apache Software Foundation.'
+copyright: 'Copyright © 2015 The Apache Software Foundation, Licensed under the Apache License, Version 2.0 Apache and the Apache feather logo are trademarks of The Apache Software Foundation.<br>The Apache Software Foundation Apache Incubator'
google_analytics: ['UA-72162311-1', 'auto']
[03/19] incubator-mynewt-site git commit: resized images on landing
page, added security page below langing page
Posted by ad...@apache.org.
resized images on landing page, added security page below langing page
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/5e6aa5b1
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/5e6aa5b1
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/5e6aa5b1
Branch: refs/heads/master
Commit: 5e6aa5b13ad52d667ad7bdb7b38e7753f4f70127
Parents: 38ca46f
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 15:42:28 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 15:42:28 2016 -0800
----------------------------------------------------------------------
custom-theme/img/cross-platform.png | Bin 86709 -> 0 bytes
custom-theme/img/cross-platforms.png | Bin 0 -> 14324 bytes
custom-theme/landing.html | 31 +++++++++++----------
custom-theme/pages/securitybullets.html | 40 +++++++++++++++++++++++++++
docs/pages/securitybullets.md | 8 ++++++
mkdocs.yml | 2 +-
6 files changed, 66 insertions(+), 15 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5e6aa5b1/custom-theme/img/cross-platform.png
----------------------------------------------------------------------
diff --git a/custom-theme/img/cross-platform.png b/custom-theme/img/cross-platform.png
deleted file mode 100644
index c1578b8..0000000
Binary files a/custom-theme/img/cross-platform.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5e6aa5b1/custom-theme/img/cross-platforms.png
----------------------------------------------------------------------
diff --git a/custom-theme/img/cross-platforms.png b/custom-theme/img/cross-platforms.png
new file mode 100644
index 0000000..26adf5e
Binary files /dev/null and b/custom-theme/img/cross-platforms.png differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5e6aa5b1/custom-theme/landing.html
----------------------------------------------------------------------
diff --git a/custom-theme/landing.html b/custom-theme/landing.html
index 7da29f8..d0014e5 100644
--- a/custom-theme/landing.html
+++ b/custom-theme/landing.html
@@ -3,10 +3,8 @@
<div class="col-xs-12 highlights">
<div class="highlight">
- <div class="img" style="background-image: url(/img/concurrent_conn.png); background-size: cover; height: 200px;">
-
- </div>
-
+ <img src="/img/concurrent_conn.png">
+
<h2>Built for wireless</h2>
<p> Meet your application\u2019s demands with open source networking stacks e.g. Bluetooth Low Energy 4.2. </p>
@@ -30,9 +28,7 @@
<br>
<div class="highlight">
- <div class="img" style="background-image: url(/img/secure_img.png); background-size: cover; height: 200px;">
-
- </div>
+ <img src="/img/secure_img.png">
<h2>Security from the start</h2>
@@ -42,15 +38,14 @@
<li>Device identity for secure provisioning </li>
<li>Authenticated, authorized, and encrypted data transfers </li>
<li>Abstracted interface to leverage hardware security </li>
+ <li> <a href="/pages/securitybullets/">More on Mynewt OS security...</a> </li>
</ul>
</div>
<div class="highlight">
- <div class="img" style="background-image: url(/img/FWdist.png); background-size: cover; height: 200px;">
-
- </div>
+ <img src="/img/FWdist.png">
<h2>Operations ready</h2>
@@ -70,9 +65,7 @@
<div class="highlight">
- <div class="img" style="background-image: url(/img/cross-platform.png); background-size: cover; height: 200px;">
-
- </div>
+ <img src="/img/cross-platforms.png" style="margin-top: 0px; margin-bottom: 0px;">
<h2>Cross-platform</h2>
@@ -88,6 +81,7 @@
<div class="highlight">
<img src="/img/newt-img.png">
+
<h2>Easy to use</h2>
<p> Compose, fine-tune, and build your image within hours or even minutes. </p>
@@ -121,7 +115,10 @@
<a href="https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF51822"> nRF51 DK </a> from Nordic Semiconductor (Cortex-M0)
</li>
<li>
- <a href="http://redbearlab.com/blenano/"> BLE Nano </a> from RedBearLabs (Nordic nRF51822 SoC based)
+ <a href="http://redbearlab.com/blenano/"> BLE Nano </a> from RedBear (Nordic nRF51822 SoC based)
+ </li>
+ <li>
+ <a href="https://www.kickstarter.com/projects/1991736672/bluetooth-5-ready-ble-module-nano-2-and-blend-2"> BLE Nano2 and Blend2 </a> from RedBear (Nordic nRF52832 SoC based)
</li>
<li>
<a href="https://www.rigado.com/products/bmd-300-eval-kit/"> BMD-300-EVAL-ES </a> from Rigado (Cortex-M4)
@@ -141,6 +138,12 @@
<li>
<a href="http://www.arduino.org/products/boards/4-arduino-boards/arduino-m0-pro"> Arduino M0 Pro </a> (Cortex-M0)
</li>
+ <li>
+ <a href="http://www.st.com/en/evaluation-tools/nucleo-f401re.html"> NUCLEO-F401RE </a> (Cortex-M4)
+ </li>
+ <li>
+ <a href="http://www.nxp.com/products/software-and-tools/hardware-development-tools/freedom-development-boards/freedom-development-platform-for-kinetis-k64-k63-and-k24-mcus:FRDM-K64F"> FRDM-K64F </a> from NXP (Cortex-M4)
+ </li>
</ul>
</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5e6aa5b1/custom-theme/pages/securitybullets.html
----------------------------------------------------------------------
diff --git a/custom-theme/pages/securitybullets.html b/custom-theme/pages/securitybullets.html
new file mode 100644
index 0000000..b14768a
--- /dev/null
+++ b/custom-theme/pages/securitybullets.html
@@ -0,0 +1,40 @@
+<div class="row">
+ <div class="col-xs-12 v2-sub-page">
+
+ <h2>Security through the life of a device</h2>
+
+ <p>
+ One of the primary goals of the Apache Mynewt project is to facilitate security assurance at every stage of a product's lifecycle. Securing a device essentially requires balancing the cost of the product inclusive of all its security mechanisms and the value of the product, keeping in mind that neither should exceed the cost of attacks on deployments of that product. Apache Mynewt OS takes care of the fundamental security requirements of a connected embedded device in a commercial marketplace. It also acknowledges that security is an ongoing effort with evolving threat scenarios, and therefore enables remote, secure updates over the product\u2019s lifetime.
+ </p>
+
+
+<div class="tg-wrap"><table>
+ <tr>
+ <th>Stage</th>
+ <th>Secure Feature/Service</th>
+ </tr>
+ <tr>
+ <td>Development</td>
+ <td>Dev image signing and verification<br>Separation of duties<br>Enable HW security (e.g. crypto accelerator)<br>Enable security logs and stats</td>
+ </tr>
+ <tr>
+ <td>Manufacturing</td>
+ <td>Unique Device ID<br>Unique Crypto keys<br>Secure bootloader<br>Manufacturing data integrity</td>
+ </tr>
+ <tr>
+ <td>Deployment</td>
+ <td>Prod image signing and verification<br>Authenticated and authorized network join<br>Secure manufacturing data upload<br>Secure time update</td>
+ </tr>
+ <tr>
+ <td>Operations</td>
+ <td>Authorized access to device<br>Mutual authentication<br>Encrypted communication<br>Data integrity<br>Secure over-the-air updates</td>
+ </tr>
+ <tr>
+ <td>Decommission</td>
+ <td>Authorized credential removal</td>
+ </tr>
+</table>
+</div>
+
+ </div>
+</div>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5e6aa5b1/docs/pages/securitybullets.md
----------------------------------------------------------------------
diff --git a/docs/pages/securitybullets.md b/docs/pages/securitybullets.md
new file mode 100644
index 0000000..792b488
--- /dev/null
+++ b/docs/pages/securitybullets.md
@@ -0,0 +1,8 @@
+html: pages/securitybullets.html
+sub_page: True
+
+<!--
+## Markdown
+
+You could make a page with markdown but then you will need to add a {{ content }} to your pages/whatever.html.
+-->
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/5e6aa5b1/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 8586282..62fd598 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -7,7 +7,7 @@ pages:
- Home: 'index.md'
- Pages:
- Bluetooth Low Energy 4.2: 'pages/ble.md'
- - Newt build and configuration Tool: 'pages/configurability.md'
+ - Mynewt OS Security: 'pages/securitybullets.md'
- Quick Start: 'quick-start.md'
- About: 'about.md'
- Talks: 'talks.md'
[10/19] incubator-mynewt-site git commit: Updated events with ESC
conference in Dec 2016
Posted by ad...@apache.org.
Updated events with ESC conference in Dec 2016
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/41c526f9
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/41c526f9
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/41c526f9
Branch: refs/heads/master
Commit: 41c526f9f7cb281f9a429108ebd462f4487d7b70
Parents: d0b69c5
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 17:14:08 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 17:14:08 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/41c526f9/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 9a31988..3a25117 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -379,10 +379,10 @@ extra:
versions:
- label: 'develop'
branch: 'develop'
- latest: False
+ latest: True
- label: '0.9.0'
branch: 'v0_9_0'
- latest: True
+ latest: False
doc_path: 'os/introduction'
chapters:
Chapter 1 - Get Started: 'The chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.'
@@ -393,11 +393,16 @@ extra:
Chapter 6 - Packaging it: 'Packages for distribution delineates the process of creating complete packages to load on your embedded device to get it up, connected, and ready for remote management.'
events:
event 1:
+ title: 'Embedded Systems Conference'
+ description: 'Join discussions of Apache Mynewt OS at the conference.'
+ location: "San Jose Convention Center, San Jose, CA, USA"
+ date: '6-8 December, 2016'
+ event 2:
title: 'ARM TechCon'
description: 'See Apache Mynewt in action in Booth #805. Watch it enable a variety of functionalities on different boards!'
location: "Santa Clara Convention Center, Santa Clara, CA, USA"
date: '25-27 October, 2016'
- event 2:
+ event 3:
title: 'Linaro Connect - Keynote Presentation'
description: 'LAS16-104: Mynewt Technical Overview. Apache Mynewt developers will be available until September 28th to meet and discuss Mynewt OS and associated Newt tool.'
location: "Grand Ballroom C, JW Marriott Resort and Spa Hotel, Las Vegas, NV"
[11/19] incubator-mynewt-site git commit: Updated events with ESC
conference in Dec 2016
Posted by ad...@apache.org.
Updated events with ESC conference in Dec 2016
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/ff0b4d03
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/ff0b4d03
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/ff0b4d03
Branch: refs/heads/master
Commit: ff0b4d0342ff4a75db39bb3f48bf3f799adb97bc
Parents: 41c526f
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 17:16:45 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 17:16:45 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ff0b4d03/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 3a25117..9a31988 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -379,10 +379,10 @@ extra:
versions:
- label: 'develop'
branch: 'develop'
- latest: True
+ latest: False
- label: '0.9.0'
branch: 'v0_9_0'
- latest: False
+ latest: True
doc_path: 'os/introduction'
chapters:
Chapter 1 - Get Started: 'The chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.'
@@ -393,16 +393,11 @@ extra:
Chapter 6 - Packaging it: 'Packages for distribution delineates the process of creating complete packages to load on your embedded device to get it up, connected, and ready for remote management.'
events:
event 1:
- title: 'Embedded Systems Conference'
- description: 'Join discussions of Apache Mynewt OS at the conference.'
- location: "San Jose Convention Center, San Jose, CA, USA"
- date: '6-8 December, 2016'
- event 2:
title: 'ARM TechCon'
description: 'See Apache Mynewt in action in Booth #805. Watch it enable a variety of functionalities on different boards!'
location: "Santa Clara Convention Center, Santa Clara, CA, USA"
date: '25-27 October, 2016'
- event 3:
+ event 2:
title: 'Linaro Connect - Keynote Presentation'
description: 'LAS16-104: Mynewt Technical Overview. Apache Mynewt developers will be available until September 28th to meet and discuss Mynewt OS and associated Newt tool.'
location: "Grand Ballroom C, JW Marriott Resort and Spa Hotel, Las Vegas, NV"
[13/19] incubator-mynewt-site git commit: Fix broken link for NimBLE
page
Posted by ad...@apache.org.
Fix broken link for NimBLE page
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/a0522bda
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/a0522bda
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/a0522bda
Branch: refs/heads/master
Commit: a0522bda2cc766e1f4f19869a7d42953f8d665d6
Parents: 52f0a27
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 15:37:59 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 15:37:59 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/a0522bda/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 60d1201..2c46b94 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -379,7 +379,7 @@ extra:
versions:
- label: 'develop'
branch: 'develop'
- latest: True
+ latest: True
- label: '0.9.0'
branch: 'v0_9_0'
latest: False
[02/19] incubator-mynewt-site git commit: moved wireless feature to
the top
Posted by ad...@apache.org.
moved wireless feature to the top
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/38ca46f0
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/38ca46f0
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/38ca46f0
Branch: refs/heads/master
Commit: 38ca46f095cf0c1870f5b5d7995e09b49ca95a13
Parents: eedefaf
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 4 12:26:08 2016 -0700
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 7 17:57:33 2016 -0800
----------------------------------------------------------------------
custom-theme/landing.html | 69 +++++++++++++++++++++++++-----------------
1 file changed, 41 insertions(+), 28 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/38ca46f0/custom-theme/landing.html
----------------------------------------------------------------------
diff --git a/custom-theme/landing.html b/custom-theme/landing.html
index 5136271..7da29f8 100644
--- a/custom-theme/landing.html
+++ b/custom-theme/landing.html
@@ -2,24 +2,33 @@
<div class="col-xs-12 highlights">
- <div class="highlight">
- <img src="/img/FWdist.png">
+ <div class="highlight">
+ <div class="img" style="background-image: url(/img/concurrent_conn.png); background-size: cover; height: 200px;">
+
+ </div>
- <h2>Operations ready</h2>
+ <h2>Built for wireless</h2>
- <p>Ready your IoT network of billions for remote monitoring, troubleshooting, management, and upgrade.</p>
+ <p> Meet your application\u2019s demands with open source networking stacks e.g. Bluetooth Low Energy 4.2. </p>
<ul>
- <li> Image management module to enable efficient, failure-aware, and reliable remote firmware updates </li>
- <li> Logging modules that can be invoked at various levels of granularity, including specialized reboot logs </li>
- <li> Richly instrumented statistics modules for OS components and network interfaces </li>
- <li> Modularity for selective, optimized composition to extract the best performance from the hardware platform </li>
- <li> <a href="../os/os_user_guide/"> More on managment utilities...</a></li>
+ <li> Flexible, powerful BLE implementation (NimBLE)</li>
+ <ul>
+ <li> Full stack, host only, or controller only - your choice </li>
+ <li> 10x throughput of Nordic Softdevice </li>
+ <li> 2x as many concurrent connections as Nordic Softdevice </li>
+ <li> 4x as many active connections in simulatenous central and peripheral roles as Intel Zephyr and Nordic Softdevice </li>
+ <li> <a href="/pages/ble/">More on NimBLE...</a> </li>
+ </ul>
+ <li> Additional connectivity options include WiFi </li>
+ <li> Native support for TCP/IP, UDP </li>
+ <li> Supports protocols for constrained networks e.g. CoAP and 6LoWPAN </li>
</ul>
- </p>
</div>
+<br>
+
<div class="highlight">
<div class="img" style="background-image: url(/img/secure_img.png); background-size: cover; height: 200px;">
@@ -38,31 +47,32 @@
</div>
- <div class="highlight">
- <img src="/img/concurrent_conn.png">
+ <div class="highlight">
+ <div class="img" style="background-image: url(/img/FWdist.png); background-size: cover; height: 200px;">
+
+ </div>
- <h2>Built for wireless</h2>
+ <h2>Operations ready</h2>
- <p> Meet your application\u2019s demands with open source networking stacks e.g. Bluetooth Low Energy 4.2. </p>
+ <p>Ready your IoT network of billions for remote monitoring, troubleshooting, management, and upgrade.</p>
<ul>
- <li> Flexible, powerful BLE implementation (NimBLE)</li>
- <ul>
- <li> Full stack, host only, or controller only - your choice </li>
- <li> 10x throughput of Nordic Softdevice </li>
- <li> 2x as many concurrent connections as Nordic Softdevice </li>
- <li> 4x as many active connections in simulatenous central and peripheral roles as Intel Zephyr and Nordic Softdevice </li>
- <li> <a href="/pages/ble/">More on NimBLE...</a> </li>
- </ul>
- <li> Additional connectivity options include WiFi </li>
- <li> Native support for TCP/IP, UDP </li>
- <li> Supports protocols for constrained networks e.g. CoAP and 6LoWPAN </li>
+ <li> Image management module to enable efficient, failure-aware, and reliable remote firmware updates </li>
+ <li> Logging modules that can be invoked at various levels of granularity, including specialized reboot logs </li>
+ <li> Richly instrumented statistics modules for OS components and network interfaces </li>
+ <li> Modularity for selective, optimized composition to extract the best performance from the hardware platform </li>
+ <li> <a href="../os/os_user_guide/"> More on managment utilities...</a></li>
</ul>
+ </p>
</div>
+
+
<div class="highlight">
- <img src="/img/cross-platform.png">
+ <div class="img" style="background-image: url(/img/cross-platform.png); background-size: cover; height: 200px;">
+
+ </div>
<h2>Cross-platform</h2>
@@ -92,10 +102,13 @@
<div class="updates">
+<br>
+<br>
+
<div class="row">
<div class="col-xs-12">
-
- <h2>Supported Boards</h2>
+
+ <h2>Supported Boards</h2>
<ul>
<li>
[16/19] incubator-mynewt-site git commit: Fix mkdocs.yml to correctly
show links to sub-pages
Posted by ad...@apache.org.
Fix mkdocs.yml to correctly show links to sub-pages
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/ff60aac0
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/ff60aac0
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/ff60aac0
Branch: refs/heads/master
Commit: ff60aac049e85aedf06b86573f7e2e436d8f68f3
Parents: ad43e92
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 15:55:18 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 15:55:18 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ff60aac0/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index f257fb1..a7fdbee 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -7,7 +7,7 @@ pages:
- Home: 'index.md'
- Pages:
- Bluetooth Low Energy 4.2: 'pages/ble.md'
- - Newt build and configuration Tool: 'pages/securitybullets.md'
+ - Newt build and configuration Tool: 'pages/configurability.md'
- Quick Start: 'quick-start.md'
- About: 'about.md'
- Talks: 'talks.md'
[19/19] incubator-mynewt-site git commit: Added discussion threads in
about page
Posted by ad...@apache.org.
Added discussion threads in about page
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/6a553540
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/6a553540
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/6a553540
Branch: refs/heads/master
Commit: 6a5535405bd4930b514bf37d85b38f594d96679b
Parents: cb39e9b
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 16:55:52 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 16:55:52 2016 -0800
----------------------------------------------------------------------
docs/about.md | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/6a553540/docs/about.md
----------------------------------------------------------------------
diff --git a/docs/about.md b/docs/about.md
index a0b10f5..a842db4 100644
--- a/docs/about.md
+++ b/docs/about.md
@@ -2,11 +2,12 @@
Some upcoming features:
-* Full IP support
-* Low power support with ability for drivers to turn on/off low power settings automatically
-* Sensor API, see <a href="https://lists.apache.org/list.html?dev@mynewt.apache.org:dfr=June%201|dto=2016-11-14:%22Sensor%20Drivers%22"> discussion thread </a>
-* Support for MIPS architecture
-* Support for additional boards
+* Host-only BLE stack
+* Serial upgrade of image in bootloader
+* HAL redesign to abstract across a diverse set of chip peripherals ([View discussion thread](http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201606.mbox/%3C06CB0682-8F67-4C3F-93E4-6A20444487A1%40apache.org%3E))
+* HAL for SPI access (master and slave)
+* Ability for drivers to turn on/off low power settings automatically
+
<font color="#F2853F"> The detailed roadmap is tracked on [JIRA for Mynewt](https://issues.apache.org/jira/browse/MYNEWT/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel). </font>
[06/19] incubator-mynewt-site git commit: Added STM32F4DISCOVERY to
the list of supported boards
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/arduino_zero.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/arduino_zero.md b/docs/os/tutorials/arduino_zero.md
index 6f25374..9926656 100644
--- a/docs/os/tutorials/arduino_zero.md
+++ b/docs/os/tutorials/arduino_zero.md
@@ -6,13 +6,13 @@ This tutorial describes how to run Mynewt OS on Arduino Zero. Follow these simpl
### Prerequisites
-Before tackling this tutorial, it's best to read about Mynewt in the [Introduction](../get_started/get_started) section of this documentation.
+Before tackling this tutorial, it's best to read about Mynewt in the [Introduction](../get_started/introduction) section of this documentation.
### Equipment
You will need the following equipment
-* An Arduino Zero board. NOTE: There are many flavors of Arduino. Ensure that
+* An Arduino Zero board. NOTE: There are many flavors of Arduino. Ensure that
you have an Arduino Zero. See below for the versions of Arduino Zero that are
compatible with this tutorial
* A computer that can connect to the Arduino Zero over USB
@@ -34,20 +34,20 @@ Mynewt has not been tested on Arduino M0 which has no internal debugger support.
<br>
-### Fetch External Packages
+### Fetch External Packages
-Mynewt uses source code provided directly from the chip manufacturer for
+Mynewt uses source code provided directly from the chip manufacturer for
low level operations. Sometimes this code is licensed only for the specific manufacturer of the chipset and cannot live in the Apache Mynewt repository. That happens to be the case for the Arduino Zero board which uses Atmel SAMD21. Runtime's github repository hosts such external third-party packages and the Newt tool can fetch them.
-To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add
+To fetch the package with MCU support for Atmel SAMD21 for Arduino Zero from the Runtime git repository, you need to add
the repository to the `project.yml` file in your base project directory.
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
+added. The sections with ```mynewt_arduino_zero``` that need to be added to
your project file are highlighted.
```hl_lines="6 14 15 16 17 18"
-$ more project.yml
+$ more project.yml
project.name: "my_project"
project.repositories:
@@ -65,17 +65,17 @@ repository.mynewt_arduino_zero:
vers: 0-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.):
+Once you've edited your ```project.yml``` file, the next step is to install the
+project dependencies, this can be done with the ```newt install``` command
+(to see more output, provide the ```-v``` verbose option.):
```no-highlight
-$ newt install
+$ newt install
apache-mynewt-core
mynewt_arduino_zero
$
@@ -89,15 +89,15 @@ $
### Create your bootloader target
-Next, you need to tell Newt what to build. For the Arduino Zero, we are going to
+Next, you need to tell Newt what to build. For the Arduino Zero, we are going to
generate both a bootloader, and an image target.
-To generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability.
+To generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability.
```no-highlight
-$ newt target create arduino_boot
-$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
-$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot
+$ newt target create arduino_boot
+$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
+$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot
$ newt target set arduino_boot build_profile=optimized
```
@@ -106,24 +106,24 @@ $ newt target set arduino_boot build_profile=optimized
If you have an Arduino Zero Pro or M0 Pro, you have to set the following next:
```
-$ newt target set arduino_boot features=arduino_zero_pro
+$ newt target set arduino_boot features=arduino_zero_pro
```
If you have an Arduino Zero, you have to set the following instead:
```
-$ newt target set arduino_boot features=arduino_zero
+$ newt target set arduino_boot features=arduino_zero
```
<br>
-These commands do a few things:
+These commands do a few things:
* Create a target named ```arduino_boot```, in order to build the Arduino Zero Bootloader.
- * Set the application for the ```arduino_boot``` target to the default Apache Mynewt
+ * Set the application for the ```arduino_boot``` target to the default Apache Mynewt
bootloader (```@apache-mynewt-core/apps/boot```)
- * Set the board support package for the target to
- ```@mynewt_arduino_zero/hw/bsp/arduino_zero```. This is a reference to the downloaded
+ * Set the board support package for the target to
+ ```@mynewt_arduino_zero/hw/bsp/arduino_zero```. This is a reference to the downloaded
Arduino Zero support from Github.
* Use the "optimized" build profile for the `arduino_boot` target. This
instructs Newt to generate smaller and more efficient code for this target.
@@ -137,7 +137,7 @@ These commands do a few things:
Once you've configured the bootloader target, the next step is to build the bootloader for your Arduino. You can do this by using the ```newt build``` command:
```no-highlight
-$ newt build arduino_boot
+$ newt build arduino_boot
Compiling asprintf.c
Compiling atoi.c
Compiling atol.c
@@ -151,38 +151,38 @@ Compiling inline.c
App successfully built: myproject/bin/arduino_boot/apps/boot/boot.elf
```
-If this command finishes successfully, you have successfully built the Arduino
-bootloader, and the next step is to build your application for the Arduino
+If this command finishes successfully, you have successfully built the Arduino
+bootloader, and the next step is to build your application for the Arduino
board.
<br>
-### Build your blinky app
+### Build your blinky app
To create and download your application, you create another target, this one pointing to the application you want to download to the Arduino board. In this tutorial, we will use the default application that comes with your project, ```apps/blinky```:
**Note**: Remember to set features to `arduino_zero` if your board is Arduino Zero and not a Pro!
```hl_lines="9"
-$ newt target create arduino_blinky
+$ newt target create arduino_blinky
Target targets/arduino_blinky successfully created
-$ newt target set arduino_blinky app=apps/blinky
+$ newt target set arduino_blinky app=apps/blinky
Target targets/arduino_blinky successfully set target.app to apps/blinky
$ newt target set arduino_blinky bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
Target targets/arduino_blinky successfully set target.bsp to @mynewt_arduino_zero/hw/bsp/arduino_zero
-$ newt target set arduino_blinky build_profile=debug
+$ newt target set arduino_blinky build_profile=debug
Target targets/arduino_blinky successfully set target.build_profile to debug
-$ newt target set arduino_blinky features=arduino_zero_pro
+$ newt target set arduino_blinky features=arduino_zero_pro
Target targets/arduino_blinky successfully set pkg.features to arduino_zero_pro
-$
+$
```
<br>
-You can now build the target, with ```newt build```:
+You can now build the target, with ```newt build```:
```no-highlight
-$ newt build arduino_blinky
+$ newt build arduino_blinky
Compiling main.c
Archiving blinky.a
Compiling cons_fmt.c
@@ -201,9 +201,9 @@ App successfully built: myproject/bin/arduino_blinky/apps/blinky/blinky.elf
### Connect the Target
-Connect your computer to the Arduino Zero (from now on we'll call this the
-target) 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
+Connect your computer to the Arduino Zero (from now on we'll call this the
+target) 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.
No external debugger is required. The Arduino Zero comes with an internal
@@ -218,13 +218,13 @@ A image below shows the Arduino Zero Programming Port.
### Download the Bootloader
-Execute the command to download the bootloader.
+Execute the command to download the bootloader.
```c
$ newt load arduino_boot
```
-If the newt tool finishes without error, that means the bootloader has been
+If the newt tool finishes without error, that means the bootloader has been
successfully loaded onto the target.
<br>
@@ -233,18 +233,18 @@ successfully loaded onto the target.
<br>
-### Run the Image
+### Run the Image
-Now that the bootloader is downloaded to the target, the next step is to load
-your image onto the Arduino Zero. The easiest way to do this, is to use the
+Now that the bootloader is downloaded to the target, the next step is to load
+your image onto the Arduino Zero. The easiest way to do this, is to use the
```newt run``` command. ```newt run``` will automatically rebuild your program
(if necessary), create an image, and load it onto the target device.
-Here, we will load our ```arduino_blinky``` target onto the device, and we
+Here, we will load our ```arduino_blinky``` target onto the device, and we
should see it run:
```no-highlight
-$ newt run arduino_blinky 0.0.0
+$ newt run arduino_blinky 0.0.0
Debugging myproject/bin/arduino_blinky/apps/blinky/blinky.elf
Open On-Chip Debugger 0.9.0 (2015-09-23-21:46)
Licensed under GNU GPL v2
@@ -279,7 +279,7 @@ For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from myproject/bin/arduino_blinky/apps/blinky/blinky.elf...done.
target state: halted
-target halted due to debug-request, current mode: Thread
+target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x0000030e msp: 0x20008000
Info : accepting 'gdb' connection on tcp/3333
Info : SAMD MCU: SAMD21G18A (256KB Flash, 32KB RAM)
@@ -292,18 +292,18 @@ Continuing.
<br>
-**NOTE:** The 0.0.0 specified after the target name to `newt run` is the version
-of the image to load. If you are not providing remote upgrade, and are just
+**NOTE:** The 0.0.0 specified after the target name to `newt run` is the version
+of the image to load. If you are not providing remote upgrade, and are just
developing locally, you can provide 0.0.0 for every image version.
-If you want the image to run without the debugger connected, simply quit the
+If you want the image to run without the debugger connected, simply quit the
debugger and restart the board. The image you programmed will come and run on the Arduino on next boot!
<br>
### Watch the LED blink
-Congratulations! You have created a Mynewt operating system running on the
+Congratulations! You have created a Mynewt operating system running on the
Arduino Zero. The LED right next to the power LED should be blinking. It is toggled by one task running on the Mynewt OS.
We have more fun tutorials for you to get your hands dirty. Be bold and try other Blinky-like [tutorials](../tutorials/nRF52.md) or try enabling additional functionality such as [remote comms](project-target-slinky.md) on the current board.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/bleprph/bleprph-adv.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bleprph/bleprph-adv.md b/docs/os/tutorials/bleprph/bleprph-adv.md
index 44a39ac..ac4f3bd 100644
--- a/docs/os/tutorials/bleprph/bleprph-adv.md
+++ b/docs/os/tutorials/bleprph/bleprph-adv.md
@@ -39,43 +39,14 @@ Let's take a look at *bleprph*'s advertisement code (*main.c*):
static void
bleprph_advertise(void)
{
- struct ble_gap_adv_params adv_params;
struct ble_hs_adv_fields fields;
- const char *name;
int rc;
- /**
- * Set the advertisement data included in our advertisements:
- * o Flags (indicates advertisement type and other general info).
- * o Advertising tx power.
- * o Device name.
- * o 16-bit service UUIDs (alert notifications).
- */
-
+ /* Set the advertisement data included in our advertisements. */
memset(&fields, 0, sizeof fields);
-
- /* Indicate that the flags field should be included; specify a value of 0
- * to instruct the stack to fill the value in for us.
- */
- fields.flags_is_present = 1;
- fields.flags = 0;
-
- /* Indicate that the TX power level field should be included; have the
- * stack fill this one automatically as well. This is done by assiging the
- * special value BLE_HS_ADV_TX_PWR_LVL_AUTO.
- */
- fields.tx_pwr_lvl_is_present = 1;
- fields.tx_pwr_lvl = BLE_HS_ADV_TX_PWR_LVL_AUTO;
-
- name = ble_svc_gap_device_name();
- fields.name = (uint8_t *)name;
- fields.name_len = strlen(name);
+ fields.name = (uint8_t *)bleprph_device_name;
+ fields.name_len = strlen(bleprph_device_name);
fields.name_is_complete = 1;
-
- fields.uuids16 = (uint16_t[]){ GATT_SVR_SVC_ALERT_UUID };
- fields.num_uuids16 = 1;
- fields.uuids16_is_complete = 1;
-
rc = ble_gap_adv_set_fields(&fields);
if (rc != 0) {
BLEPRPH_LOG(ERROR, "error setting advertisement data; rc=%d\n", rc);
@@ -83,11 +54,8 @@ bleprph_advertise(void)
}
/* Begin advertising. */
- memset(&adv_params, 0, sizeof adv_params);
- adv_params.conn_mode = BLE_GAP_CONN_MODE_UND;
- adv_params.disc_mode = BLE_GAP_DISC_MODE_GEN;
- rc = ble_gap_adv_start(BLE_ADDR_TYPE_PUBLIC, 0, NULL, BLE_HS_FOREVER,
- &adv_params, bleprph_gap_event, NULL);
+ rc = ble_gap_adv_start(BLE_GAP_DISC_MODE_GEN, BLE_GAP_CONN_MODE_UND,
+ NULL, 0, NULL, bleprph_on_connect, NULL);
if (rc != 0) {
BLEPRPH_LOG(ERROR, "error enabling advertisement; rc=%d\n", rc);
return;
@@ -102,9 +70,18 @@ Now let's examine this code in detail.
#### Setting advertisement data
-A NimBLE peripheral specifies what information to include in its advertisements with the [ble_gap_adv_set_fields()](../../../network/ble/ble_hs/ble_gap/functions/ble_gap_adv_set_fields.md) function.
+A NimBLE peripheral specifies what information to include in its advertisements with the following function:
+
+<br>
-The *fields* argument specifies the fields and their contents to include in
+```c
+int
+ble_gap_adv_set_fields(struct ble_hs_adv_fields *adv_fields)
+```
+
+<br>
+
+The *adv_fields* argument specifies the fields and their contents to include in
subsequent advertisements. The Bluetooth [Core Specification
Supplement](https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=302735)
defines a set of standard fields that can be included in an advertisement; the
@@ -119,30 +96,44 @@ function makes a copy of all the advertisement data before it returns.
*bleprph* doesn't take full advantange of this; it stores its device name in a
static array.
-The code sets several members of the *struct ble_hs_adv_fields* instance. Most
-of them are quite straight-forward. However, the *name\_is\_complete* field
-requires some explanation. Bluetooth specifies two name-related advertisement
-fields: *Shortened Local Name* and *Complete Local Name*. Setting the
-`name_is_complete` variable to 1 or 0 tells NimBLE which of these two fields to
-include in advertisements. Some other advertisement fields also correspond to
-multiple variables in the field struct, so it is a good idea to review the
-*ble\_hs\_adv\_fields* reference to make sure you get the details right in your
-app.
+The code sets three members of the *struct ble_hs_adv_fields* instance:
+
+* name
+* name\_len
+* name\_is\_complete
+
+The first two fields are used to communicate the device's name and are quite
+straight-forward. The third field requires some explanation. Bluetooth
+specifies two name-related advertisement fields: *Shortened Local Name* and
+*Complete Local Name*. Setting the `name_is_complete` variable to 1 or 0 tells
+NimBLE which of these two fields to include in advertisements. Some other
+advertisement fields also correspond to multiple variables in the field struct,
+so it is a good idea to review the *ble\_hs\_adv\_fields* reference to
+make sure you get the details right in your app.
<br>
#### Begin advertising
-An app starts advertising with
-[ble_gap_adv_start()](../../../network/ble/ble_hs/ble_gap/functions/ble_gap_adv_start.md)
-function. This function allows a lot of flexibility, and it might seem
-daunting at first glance. *bleprph* specifies a simple set of arguments that
-is appropriate for most peripherals. When getting started on a typical
-peripheral, we recommend you use the same arguments as *bleprph*, with the
-exception of the last two (*cb* and *cb_arg*; *bleprph_gap_event* and *NULL* in
-this case). These last two arguments will be specific to your app, so let's
-talk about them.
+An app starts advertising with the following function:
+
+<br>
+
+```c
+int
+ble_gap_adv_start(uint8_t discoverable_mode, uint8_t connectable_mode,
+ uint8_t *peer_addr, uint8_t peer_addr_type,
+ struct hci_adv_params *adv_params,
+ ble_gap_conn_fn *cb, void *cb_arg)
+```
+
+This function allows a lot of flexibility, and it might seem daunting at first
+glance. *bleprph* specifies a simple set of arguments that is appropriate for
+most peripherals. When getting started on a typical peripheral, we recommend
+you use the same arguments as *bleprph*, with the exception of the last two
+(*cb* and *cb_arg*). These last two arguments will be specific to your app, so
+let's talk about them.
*cb* is a callback function. It gets executed when a central connects to your
peripheral after receiving an advertisement. The *cb_arg* argument gets passed
@@ -150,15 +141,10 @@ to the *cb* callback. If your callback doesn't need the *cb_arg* parameter,
you can do what *bleprph* does and pass *NULL*. Once a connection is
established, the *cb* callback becomes permanently associated with the
connection. All subsequent events related to the connection are communicated
-to your app via calls to this callback function. GAP event callbacks are an
+to your app via calls to this callback function. Connection callbacks are an
important part of building a BLE app, and we examine *bleprph*'s connection
callback in detail in the next section of this tutorial.
<br>
-**One final note:** Your peripheral automatically stops advertising when a
-central connects to it. You can immediately resume advertising if you want to
-allow another central to connect, but you will need to do so explicitly by
-calling `ble_gap_adv_start()` again. Also, be aware NimBLE's default
-configuration only allows a single connection at a time. NimBLE supports
-multiple concurrent connections, but you must configure it to do so first.
+**One final note:** Your peripheral automatically stops advertising when a central connects to it. You can immediately resume advertising if you want to allow another central to connect, but you will need to do so explicitly by calling `ble_gap_adv_start()` again. Also, be aware NimBLE's default configuration only allows a single connection at a time. NimBLE supports multiple concurrent connections, but you must configure it to do so first.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/bleprph/bleprph-app.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bleprph/bleprph-app.md b/docs/os/tutorials/bleprph/bleprph-app.md
new file mode 100644
index 0000000..4a8cff3
--- /dev/null
+++ b/docs/os/tutorials/bleprph/bleprph-app.md
@@ -0,0 +1,108 @@
+## BLE Peripheral Project
+
+###Overview
+
+<br>
+
+Now that we've gone through how BLE Apps are contructed, how they function, and how all the parts fit together
+let's try out a BLE Peripheral App to see how it all works.
+
+<br>
+
+###Prerequisites
+
+<br>
+
+* You should already have completed the previous [BLE Tiny Project](../bletiny_project.md), though it's not required.
+* You should have a BLE Central App of some sort to connect with. On Mac OS or iOS, you can use [LightBlue](https://itunes.apple.com/us/app/lightblue-explorer-bluetooth/id557428110?mt=8)
+which is a free app to browse and connect to BLE Peripheral devices.
+
+<br>
+
+###Create a New Target
+
+You can create a new project instead, but this tutorial will simply use the previously created bletiny project and add a new target for the BLE Peripheral
+
+```
+$ newt target create myperiph
+Target targets/myperiph successfully created
+$ newt target set myperiph bsp=@apache-mynewt-core/hw/bsp/nrf52dk
+Target targets/myperiph successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52dk
+$ newt target set myperiph app=@apache-mynewt-core/apps/bleprph
+Target targets/myperiph successfully set target.app to @apache-mynewt-core/apps/bleprph
+$ newt target set myperiph build_profile=optimized
+Target targets/myperiph successfully set target.build_profile to optimized
+$ newt build blerph
+Building target targets/myperiph
+...
+Linking ~/dev/nrf52dk/bin/targets/myperiph/app/apps/bleprph/bleprph.elf
+Target successfully built: targets/myperiph
+$ newt create-image myperiph 1.0.0
+App image succesfully generated: ~/dev/nrf52dk/bin/targets/myperiph/app/apps/bleprph/bleprph.img
+$ newt load myperiph
+Loading app image into slot 1
+```
+
+Now if you reset the board, and fire up your BLE Central App, you should see a new peripheral device called 'nimble-bleprph'.
+
+<br>
+
+
+
+<br>
+
+Now that you can see the device, you can begin to interact with the advertised service.
+
+Click on the device and you'll establish a connection.
+
+<br>
+
+
+
+<br>
+
+Now that you're connected, you can see the Services that are being advertised.
+
+Scroll to the bottom and you will see a Read Characteristic, and a Read/Write Characteristic.
+
+
+
+<br>
+
+Just click on the Read Write Characteristic and you will see the existing value.
+
+
+
+<br>
+
+Type in a new value.
+
+
+
+<br>
+
+And you will see the new value reflected.
+
+
+
+<br>
+
+If you still have your console connected, you will be able to see the connection requests, and pairing,
+happen on the device as well.
+
+<br>
+
+```hl_lines="1"
+258894:[ts=2022609336ssb, mod=64 level=1] connection established; status=0 handle=1 our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0 our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=1 peer_ota_addr=7f:be:d4:44:c0:d4 peer_id_addr_type=1 peer_id_addr=7f:be:d4:44:c0:d4 conn_itvl=24 conn_latency=0 supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
+258904:[ts=2022687456ssb, mod=64 level=1]
+258917:[ts=2022789012ssb, mod=64 level=1] mtu update event; conn_handle=1 cid=4 mtu=185
+258925:[ts=2022851508ssb, mod=64 level=1] subscribe event; conn_handle=1 attr_handle=14 reason=1 prevn=0 curn=0 previ=0 curi=1
+261486:[ts=2042859320ssb, mod=64 level=1] encryption change event; status=0 handle=1 our_ota_addr_type=0 our_ota_addr=0a:0a:0a:0a:0a:0a our_id_addr_type=0 our_id_addr=0a:0a:0a:0a:0a:0a peer_ota_addr_type=1 peer_ota_addr=7f:be:d4:44:c0:d4 peer_id_addr_type=1 peer_id_addr=7f:be:d4:44:c0:d4 conn_itvl=24 conn_latency=0 supervision_timeout=72 encrypted=1 authenticated=0 bonded=1
+261496:[ts=2042937440ssb, mod=64 level=1]
+```
+
+<br>
+
+Congratulations! You've just built and connected your first BLE Peripheral device!
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/bleprph/bleprph-chr-access.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bleprph/bleprph-chr-access.md b/docs/os/tutorials/bleprph/bleprph-chr-access.md
index 3e6c3a5..3865e12 100644
--- a/docs/os/tutorials/bleprph/bleprph-chr-access.md
+++ b/docs/os/tutorials/bleprph/bleprph-chr-access.md
@@ -12,7 +12,7 @@ Each characteristic definition in an attribute table contains an *access_cb*
field. The *access_cb* field is an application callback that gets executed
whenever a peer device attempts to read or write the characteristic.
-Earlier in this tutorial, we looked at how *bleprph* implements the ANS
+Earlier in this tutorial, we looked at how *bleprph* implements the GAP
service. Let's take another look at how *bleprph* specifies the first few
characteristics in this service.
@@ -21,68 +21,80 @@ characteristics in this service.
```c
static const struct ble_gatt_svc_def gatt_svr_svcs[] = {
{
- /*** Alert Notification Service. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid128 = BLE_UUID16(GATT_SVR_SVC_ALERT_UUID),
- .characteristics = (struct ble_gatt_chr_def[]) { {
- .uuid128 = BLE_UUID16(GATT_SVR_CHR_SUP_NEW_ALERT_CAT_UUID),
- .access_cb = gatt_svr_chr_access_alert,
- .flags = BLE_GATT_CHR_F_READ,
+ /*** Service: GAP. */
+ .type = BLE_GATT_SVC_TYPE_PRIMARY,
+ .uuid128 = BLE_UUID16(BLE_GAP_SVC_UUID16),
+ .characteristics = (struct ble_gatt_chr_def[]) { {
+ /*** Characteristic: Device Name. */
+ .uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_DEVICE_NAME),
+ .access_cb = gatt_svr_chr_access_gap,
+ .flags = BLE_GATT_CHR_F_READ,
}, {
- .uuid128 = BLE_UUID16(GATT_SVR_CHR_NEW_ALERT),
- .access_cb = gatt_svr_chr_access_alert,
- .flags = BLE_GATT_CHR_F_NOTIFY,
+ /*** Characteristic: Appearance. */
+ .uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_APPEARANCE),
+ .access_cb = gatt_svr_chr_access_gap,
+ .flags = BLE_GATT_CHR_F_READ,
}, {
// [...]
```
-As you can see, *bleprph* uses the same *access_cb* function for all the ANS
+As you can see, *bleprph* uses the same *access_cb* function for all the GAP
service characteristics, but the developer could have implemented separate
-functions for each characteristic if they preferred. Here is part of the
-*access_cb* function that the ANS service characteristics use:
+functions for each characteristic if they preferred. Here is the *access_cb*
+function that the GAP service characteristics use:
<br>
```c
-
static int
-gatt_svr_chr_access_alert(uint16_t conn_handle, uint16_t attr_handle,
- struct ble_gatt_access_ctxt *ctxt,
- void *arg)
+gatt_svr_chr_access_gap(uint16_t conn_handle, uint16_t attr_handle, uint8_t op,
+ union ble_gatt_access_ctxt *ctxt, void *arg)
{
uint16_t uuid16;
- int rc;
- uuid16 = ble_uuid_128_to_16(ctxt->chr->uuid128);
+ uuid16 = ble_uuid_128_to_16(ctxt->chr_access.chr->uuid128);
assert(uuid16 != 0);
switch (uuid16) {
- case GATT_SVR_CHR_SUP_NEW_ALERT_CAT_UUID:
- assert(ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR);
- rc = os_mbuf_append(ctxt->om, &gatt_svr_new_alert_cat,
- sizeof gatt_svr_new_alert_cat);
- return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
-
- case GATT_SVR_CHR_UNR_ALERT_STAT_UUID:
- if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
- if (OS_MBUF_PKTLEN(ctxt->om) != sizeof gatt_svr_unr_alert_stat) {
- return BLE_ATT_ERR_INVALID_ATTR_VALUE_LEN;
- }
-
- rc = ble_hs_mbuf_to_flat(ctxt->om, &gatt_svr_unr_alert_stat,
- sizeof gatt_svr_unr_alert_stat, NULL);
- if (rc != 0) {
- return BLE_ATT_ERR_UNLIKELY;
- }
-
- return 0;
-
- /* [...] */
+ case BLE_GAP_CHR_UUID16_DEVICE_NAME:
+ assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
+ ctxt->chr_access.data = (void *)bleprph_device_name;
+ ctxt->chr_access.len = strlen(bleprph_device_name);
+ break;
+
+ case BLE_GAP_CHR_UUID16_APPEARANCE:
+ assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
+ ctxt->chr_access.data = (void *)&bleprph_appearance;
+ ctxt->chr_access.len = sizeof bleprph_appearance;
+ break;
+
+ case BLE_GAP_CHR_UUID16_PERIPH_PRIV_FLAG:
+ assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
+ ctxt->chr_access.data = (void *)&bleprph_privacy_flag;
+ ctxt->chr_access.len = sizeof bleprph_privacy_flag;
+ break;
+
+ case BLE_GAP_CHR_UUID16_RECONNECT_ADDR:
+ assert(op == BLE_GATT_ACCESS_OP_WRITE_CHR);
+ if (ctxt->chr_access.len != sizeof bleprph_reconnect_addr) {
+ return BLE_ATT_ERR_INVALID_ATTR_VALUE_LEN;
+ }
+ memcpy(bleprph_reconnect_addr, ctxt->chr_access.data,
+ sizeof bleprph_reconnect_addr);
+ break;
+
+ case BLE_GAP_CHR_UUID16_PERIPH_PREF_CONN_PARAMS:
+ assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
+ ctxt->chr_access.data = (void *)&bleprph_pref_conn_params;
+ ctxt->chr_access.len = sizeof bleprph_pref_conn_params;
+ break;
default:
assert(0);
- return BLE_ATT_ERR_UNLIKELY;
+ break;
}
+
+ return 0;
}
```
@@ -92,38 +104,44 @@ After you've taken a moment to examine the structure of this function, let's exp
#### Function signature
+<br>
+
```c
static int
-gatt_svr_chr_access_alert(uint16_t conn_handle, uint16_t attr_handle,
- struct ble_gatt_access_ctxt *ctxt,
- void *arg)
+gatt_svr_chr_access_gap(uint16_t conn_handle, uint16_t attr_handle, uint8_t op,
+ union ble_gatt_access_ctxt *ctxt, void *arg)
```
A characteristic access function always takes this same set of parameters and
always returns an int. The parameters to this function type are documented
below.
+<br>
+
| **Parameter** | **Purpose** | **Notes** |
| ------------- | ----------- | --------- |
| conn_handle | Indicates which connection the characteristic access was sent over. | Use this value to determine which peer is accessing the characteristic. |
| attr_handle | The low-level ATT handle of the characteristic value attribute. | Can be used to determine which characteristic is being accessed if you don't want to perform a UUID lookup. |
| op | Indicates whether this is a read or write operation | Valid values are:<br>*BLE_GATT_ACCESS_OP_READ_CHR*<br>*BLE_GATT_ACCESS_OP_WRITE_CHR* |
-| ctxt | Contains the characteristic value mbuf that the application needs to access. | For characteristic accesses, use the *ctxt->chr* member; for descriptor accesses, use the *ctxt->dsc* member. |
+| ctxt | Contains the characteristic value pointer that the application needs to access. | For characteristic accesses, use the *ctxt->chr_access* member; for descriptor accesses, use the *ctxt->dsc_access* member. |
The return value of the access function tells the NimBLE stack how to respond
to the peer performing the operation. A value of 0 indicates success. For
-failures, the function returns the specific [ATT error code](../../../network/ble/ble_hs/ble_hs_return_codes/#return-codes-att) that the NimBLE
-stack should respond with. *Note:* The return code is a formal code, **not** a NimBLE value!
+failures, the function returns the specific ATT error code that the NimBLE
+stack should respond with. The ATT error codes are defined in
+[net/nimble/host/include/host/ble_att.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/include/host/ble_att.h).
<br>
#### Determine characteristic being accessed
+<br>
+
```c
{
uint16_t uuid16;
- uuid16 = ble_uuid_128_to_16(ctxt->chr->uuid128);
+ uuid16 = ble_uuid_128_to_16(ctxt->chr_access.chr->uuid128);
assert(uuid16 != 0);
switch (uuid16) {
@@ -137,76 +155,94 @@ accomplish this task:
* Map characteristics to ATT handles during service registration; use the *attr_handle* parameter as a key into this table during characteristic access.
* Implement a dedicated function for each characteristic; each function inherently knows which characteristic it corresponds to.
-All the ANS service characteristics have 16-bit UUIDs, so this function uses
+All the GAP service characteristics have 16-bit UUIDs, so this function uses
the *ble_uuid_128_to_16()* function to convert the 128-bit UUID to its
corresponding 16-bit UUID. This conversion function returns the corresponding
16-bit UUID on success, or 0 on failure. Success is asserted here to ensure
the NimBLE stack is doing its job properly; the stack should only call this
function for accesses to characteristics that it is registered with, and all
-ANS service characteristics have valid 16-bit UUIDs.
+GAP service characteristics have valid 16-bit UUIDs.
<br>
#### Read access
+<br>
+
```c
- case GATT_SVR_CHR_SUP_NEW_ALERT_CAT_UUID:
- assert(ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR);
- rc = os_mbuf_append(ctxt->om, &gatt_svr_new_alert_cat,
- sizeof gatt_svr_new_alert_cat);
- return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
+ case BLE_GAP_CHR_UUID16_DEVICE_NAME:
+ assert(op == BLE_GATT_ACCESS_OP_READ_CHR);
+ ctxt->chr_access.data = (void *)bleprph_device_name;
+ ctxt->chr_access.len = strlen(bleprph_device_name);
+ break;
```
-This code excerpt handles read accesses to the Supported New Alert Category
-characteristic. The *assert()* here is another case of making sure the NimBLE
-stack is doing its job; this characteristic was registered as read-only, so the
-stack should have prevented write accesses.
+This code excerpt handles read accesses to the device name characteristic. The
+*assert()* here is another case of making sure the NimBLE stack is doing its
+job; this characteristic was registered as read-only, so the stack should have
+prevented write accesses.
-To fulfill a characteristic read request, the application needs fill a buffer (*om*) with the characteristic value. The NimBLE host will then include the contents of this buffer in its read response. NimBLE uses [mbufs](../../../os/core_os/mbuf/mbuf) to exchange data between itself and the application. To fill an mbuf with data that is available in a contiguous chunk of memory, the *os_mbuf_append()* function suffices. The source of the data, *gatt_svr_new_alert_cat*, is is stored in read-only memory as follows:
+To fulfill a characteristic read request, the application needs to assign the
+*ctxt->chr_access.data* field to point to the attribute data to respond with,
+and fill the *ctxt->chr_access.len* field with the length of the attribute data.
+*bleprph* stores the device name in read-only memory as follows:
<br>
```c
-static const uint8_t gatt_svr_new_alert_cat = 0x01; /* Simple alert. */
+const char *bleprph_device_name = "nimble-bleprph";
```
+The cast to pointer-to-void is a necessary annoyance to remove the *const*
+qualifier from the device name variable. You will need to "cast away const"
+whenever you respond to read requests with read-only data.
+
It is not shown in the above snippet, but this function ultimately returns 0.
By returning 0, *bleprph* indicates that the characteristic data in
-*ctxt->om* is valid and that NimBLE should include it in its response
+*ctxt->chr_access* is valid and that NimBLE should include it in its response
to the peer.
<br>
+**A word of warning:** The attribute data that *ctxt->chr_access.data* points to
+must remain valid after the access function returns, as the NimBLE stack needs
+to use it to form a GATT read response. In other words, you must not
+allocate the characteristic value data on the stack of the access function.
+Two characteristic accesses never occur at the same time, so it is OK to use
+the same memory for repeated accesses.
+
+<br>
+
#### Write access
-```c
-static uint16_t gatt_svr_unr_alert_stat;
-```
+<br>
```c
- case GATT_SVR_CHR_UNR_ALERT_STAT_UUID:
- if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
- if (OS_MBUF_PKTLEN(ctxt->om) != sizeof gatt_svr_unr_alert_stat) {
- return BLE_ATT_ERR_INVALID_ATTR_VALUE_LEN;
- }
-
- rc = ble_hs_mbuf_to_flat(ctxt->om, &gatt_svr_unr_alert_stat,
- sizeof gatt_svr_unr_alert_stat, NULL);
- if (rc != 0) {
- return BLE_ATT_ERR_UNLIKELY;
- }
-
- return 0;
- } else /* [...] */
+ case BLE_GAP_CHR_UUID16_RECONNECT_ADDR:
+ assert(op == BLE_GATT_ACCESS_OP_WRITE_CHR);
+ if (ctxt->chr_access.len != sizeof bleprph_reconnect_addr) {
+ return BLE_ATT_ERR_INVALID_ATTR_VALUE_LEN;
+ }
+ memcpy(bleprph_reconnect_addr, ctxt->chr_access.data,
+ sizeof bleprph_reconnect_addr);
+ break;
```
-This code excerpt handles writes to the New Alert characteristic. For writes,
-the role of the *ctxt->om* field is the reverse of the read case. The NimBLE
-stack uses these fields to indicate the data written by the peer.
+This code excerpt handles writes to the reconnect address characteristic. This
+characteristic was registered as write-only, so the *assert()* here is just a
+safety precaution to ensure the NimBLE stack is doing its job.
-Many characteristics have strict length requirements for write operations.
-This characteristic has such a restriction; if the written data is not a 2-byte
-value, the application tells NimBLE to respond with an invalid attribute value
-length error.
+For writes, the roles of the *ctxt->chr_access.data* and *ctxt->chr_access.len*
+fields are the reverse of the read case. The NimBLE stack uses these fields to
+indicate the data written by the peer.
-*bleprph* copies the data out of the supplied mbuf and writes it to a contiguous chunk of storage (the *gatt_svr_unr_alert_stat* variable). This is accomplished with the [ble_hs_mbuf_to_flat()](../../../network/ble/ble_hs/other/functions/ble_hs_mbuf_to_flat) function. If the application did not have a suitable destination for the data handy, it could have inherited the mbuf from the context object. This is done by saving a copy of the mbuf pointer, and assigning *NULL* to *ctxt->om*. By assigning *NULL* to the mbuf pointer, your application prevents the stack from freeing the mbuf while it is still being used. Be aware, however, that it is the application's responsibility to free inherited mbufs.
+Many characteristics have strict length requirements for write operations.
+This characteristic has such a restriction; if the written data is not a 48-bit
+BR address, the application tells NimBLE to respond with an invalid attribute
+value length error.
+
+For writes, the *ctxt->chr_access.data* pointer is only valid for the duration
+of the access function. If the application needs to save the written data, it
+should store it elsewhere before the function returns. In this case, *bleprph*
+stores the specified address in a global variable called
+*bleprph_reconnect_addr*.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/bleprph/bleprph-conn.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bleprph/bleprph-conn.md b/docs/os/tutorials/bleprph/bleprph-conn.md
new file mode 100644
index 0000000..ffbf7a1
--- /dev/null
+++ b/docs/os/tutorials/bleprph/bleprph-conn.md
@@ -0,0 +1,156 @@
+## BLE Peripheral Project
+
+### Connection callbacks
+
+<br>
+
+#### Overview
+
+
+Every BLE connection has a *connection callback* associated with it. A
+connection callback is a bit of application code which NimBLE uses to inform
+you of connection-related events. For example, if a connection is terminated,
+NimBLE lets you know about it with a call to that connection's callback.
+
+In the [advertising section](bleprph-adv/) of this tutorial, we saw how the
+application specifies a connection callback when it begins advertising. NimBLE
+uses this callback to notify the application that a central has connected to
+your peripheral after receiving an advertisement. Let's revisit how *bleprph* specifies its connection callback when advertising:
+
+<br>
+
+```c
+ /* Begin advertising. */
+ rc = ble_gap_adv_start(BLE_GAP_DISC_MODE_GEN, BLE_GAP_CONN_MODE_UND,
+ NULL, 0, NULL, bleprph_on_connect, NULL);
+ if (rc != 0) {
+ BLEPRPH_LOG(ERROR, "error enabling advertisement; rc=%d\n", rc);
+ return;
+ }
+```
+
+<br>
+
+#### bleprph_on_connect()
+
+
+The `bleprph_on_connect()` function is *bleprph*'s connection callback; NimBLE
+calls this function when the advertising operation leads to connection
+establishment. Upon connecting, this callback becomes permanently associated
+with the connection; all subsequent events related to this connection are
+communicated through this callback.
+
+Now let's look at the function that *bleprph* uses for all its connection
+callbacks: `bleprph_on_connect()`.
+
+
+```c
+static int
+bleprph_on_connect(int event, int status, struct ble_gap_conn_ctxt *ctxt,
+ void *arg)
+{
+ switch (event) {
+ case BLE_GAP_EVENT_CONN:
+ BLEPRPH_LOG(INFO, "connection %s; status=%d ",
+ status == 0 ? "up" : "down", status);
+ bleprph_print_conn_desc(ctxt->desc);
+ BLEPRPH_LOG(INFO, "\n");
+
+ if (status != 0) {
+ /* Connection terminated; resume advertising. */
+ bleprph_advertise();
+ }
+ break;
+ }
+
+ return 0;
+}
+```
+
+<br>
+
+Connection callbacks are used to communicate a variety of events related to a
+connection. An application determines the type of event that occurred by
+inspecting the value of the *event* parameter. The full list of event codes
+can be found in [net/nimble/host/include/host/ble_gatt.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/include/host/ble_gatt.h).
+*bleprph* only concerns itself with a single event type: *BLE_GAP_EVENT_CONN*.
+This event indicates that a new connection has been established, or an existing
+connection has been terminated; the *status* parameter clarifies which. As you
+can see, *bleprph* uses the *status* parameter to determine if it should resume
+advertising.
+
+The *ctxt* parameter contains additional information about the connection
+event. *bleprph* does nothing more than log some fields of this struct, but
+some apps will likely want to perform further actions, e.g., perform service
+discovery on the connected device. The *struct ble_gap_conn_ctxt* type is
+defined as follows:
+
+```c
+struct ble_gap_conn_ctxt {
+ struct ble_gap_conn_desc *desc;
+
+ union {
+ struct {
+ struct ble_gap_upd_params *self_params;
+ struct ble_gap_upd_params *peer_params;
+ } update;
+
+ struct ble_gap_sec_params *sec_params;
+ };
+};
+```
+
+<br>
+
+As shown, a connection context object consists of two parts:
+
+* *desc:* The connection descriptor; indicates properties of the connection.
+* *anonymous union:* The contents are event-specific; check the *event* code to determine which member field (if any) is relevant.
+
+For events of type *BLE_GAP_EVENT_CONN*, the anonymous union is not used at all, so the only information carried by the context struct is the connection descriptor. The *struct ble_gap_conn_desc* type is defined as follows:
+
+```c
+struct ble_gap_conn_desc {
+ uint8_t peer_addr[6];
+ uint16_t conn_handle;
+ uint16_t conn_itvl;
+ uint16_t conn_latency;
+ uint16_t supervision_timeout;
+ uint8_t peer_addr_type;
+};
+```
+
+<br>
+
+We will examine these fields in a slightly different order from how they appear
+in the struct definition.
+
+<br>
+
+| *Field* | *Purpose* | *Notes* |
+| ------- | --------- | ------- |
+| peer\_addr | The 48-bit address of the peer device. | |
+| peer\_addr\_type | Whether the peer is using a public or random address. | The address type list is documented in [net/nimble/include/nimble/hci_common.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/include/nimble/hci_common.h). |
+| conn\_handle | The 16-bit handle associated with this connection. | This number is how your app and the NimBLE stack refer to this connection. |
+| conn\_itvl,<br>conn\_latency,<br>supervision\_timeout | Low-level properties of the connection. | |
+
+<br>
+
+#### Guarantees
+
+It is important to know what your application code is allowed to do from within
+a connection callback.
+
+**No restrictions on NimBLE operations**
+
+Your app is free to make calls into the NimBLE stack from within a connection
+callback. *bleprph* takes advantage of this freedom when it resumes
+advertising upon connection termination. All other NimBLE operations are also
+allowed (service discovery, pairing initiation, etc).
+
+**All context data is transient**
+
+Pointers in the context object point to data living on the stack. Your
+callback is free to read (or write, if appropriate) through these pointers, but
+you should not store these pointers for later use. If your application needs
+to retain some data from a context object, it needs to make a copy.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/bleprph/bleprph-intro.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bleprph/bleprph-intro.md b/docs/os/tutorials/bleprph/bleprph-intro.md
index f03f1d7..77a72b9 100644
--- a/docs/os/tutorials/bleprph/bleprph-intro.md
+++ b/docs/os/tutorials/bleprph/bleprph-intro.md
@@ -8,10 +8,9 @@
*bleprph* is an example app included in the apache-mynewt-core repository. This app implements a simple BLE peripheral with the following properties:
+* Supports three services: GAP, GATT, and alert notification service (ANS).
* Supports a single concurrent connection.
* Automatically advertises connectability when not connected to a central device.
-* Supports pairing and bonding.
-* Supports five services.
This tutorial aims to provide a guided tour through the *bleprph* app source
code. This document builds on some concepts described elsewhere in the Apache
@@ -33,3 +32,5 @@ these concepts, you will probably want to check out this
from the Bluetooth Developer's site before proceeding.
Now let's dig in to some C code.
+<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/bleprph/bleprph-svc-reg.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bleprph/bleprph-svc-reg.md b/docs/os/tutorials/bleprph/bleprph-svc-reg.md
index a40e772..dc8747d 100644
--- a/docs/os/tutorials/bleprph/bleprph-svc-reg.md
+++ b/docs/os/tutorials/bleprph/bleprph-svc-reg.md
@@ -8,38 +8,33 @@
The NimBLE host uses a table-based design for GATT server configuration. The
set of supported attributes are expressed as a series of tables that resides in
-your C code.
+your C code. When possible, we recommend using a single monolithic table, as
+it results in code that is simpler and less error prone. Multiple tables
+can be used if it is impractical for the entire attribute set to live in one
+place in your code.
-*bleprph* supports the following services:
-
-* GAP
-* GATT
-* newtmgr
-* Alert Notification
-* Security Test
-
-The first two services (GAP and GATT) are mandatory services that all BLE peripherals must support. These are implemented in a separate package which the *bleprph* app depends on. Later, we will see how the *main()* function initializes and registers this package. Your app will follow the same procedure when using GATT service libraries.
-
-The third service, newtmgr, is vendor-specific service supported by most Mynewt devices. This service is used for remote configuration, status queries, and firmware updates. As with GAP and GATT, this service is implemented in a package separate from the *bleprph* app.
-
-The final two services, *Alert Notification* and *Security Test*, are not implemented in separate libraries. Rather, these services are specific to the app, so they are implemented the *bleprph* app itself. The attribute table used to express these services is located in the *gatt_svr.c* file, so let's take a look at that now. The attribute table is called `gatt_svr_svcs`; here are the first several lines from this table:
+*bleprph* uses a single attribute table located in the *gatt_svr.c* file,
+so let's take a look at that now. The attribute table is called
+`gatt_svr_svcs`; here are the first several lines from this table:
<br>
```c
static const struct ble_gatt_svc_def gatt_svr_svcs[] = {
{
- /*** Alert Notification Service. */
- .type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid128 = BLE_UUID16(GATT_SVR_SVC_ALERT_UUID),
- .characteristics = (struct ble_gatt_chr_def[]) { {
- .uuid128 = BLE_UUID16(GATT_SVR_CHR_SUP_NEW_ALERT_CAT_UUID),
- .access_cb = gatt_svr_chr_access_alert,
- .flags = BLE_GATT_CHR_F_READ,
+ /*** Service: GAP. */
+ .type = BLE_GATT_SVC_TYPE_PRIMARY,
+ .uuid128 = BLE_UUID16(BLE_GAP_SVC_UUID16),
+ .characteristics = (struct ble_gatt_chr_def[]) { {
+ /*** Characteristic: Device Name. */
+ .uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_DEVICE_NAME),
+ .access_cb = gatt_svr_chr_access_gap,
+ .flags = BLE_GATT_CHR_F_READ,
}, {
- .uuid128 = BLE_UUID16(GATT_SVR_CHR_NEW_ALERT),
- .access_cb = gatt_svr_chr_access_alert,
- .flags = BLE_GATT_CHR_F_NOTIFY,
+ /*** Characteristic: Appearance. */
+ .uuid128 = BLE_UUID16(BLE_GAP_CHR_UUID16_APPEARANCE),
+ .access_cb = gatt_svr_chr_access_gap,
+ .flags = BLE_GATT_CHR_F_READ,
}, {
// [...]
```
@@ -48,14 +43,16 @@ static const struct ble_gatt_svc_def gatt_svr_svcs[] = {
As you can see, the table is an array of service definitions (
`struct ble_gatt_svc_def`). This code excerpt contains a small part of the
-Alert Notification service. Let's now consider the contents of this table in
-more detail.
+*GAP service*. The GAP service exposes generic information about a device,
+such as its name and appearance. Support for the GAP service is mandatory for
+all BLE peripherals. Let's now consider the contents of this table in more
+detail.
A service definition consists of the following fields:
-| *Field* | *Meaning* | *Notes* |
-| --------------- | --------- | ------- |
-| type | Specifies whether this is a primary or secondary service. | Secondary services are not very common. When in doubt, specify *BLE_GATT_SVC_TYPE_PRIMARY* for new services. |
+| *Field* | *Meaning* | *Notes* |
+| ------- | --------- | ------- |
+| type | Specifies whether this is a primary or secondary service. | Secondary services are not very common. When in doubt, specify *BLE_GATT_SVC_TYPE_PRIMARY* for new services. |
| uuid128 | The 128-bit UUID of this service. | If the service has a 16-bit UUID, you can convert it to its corresponding 128-bit UUID with the `BLE_UUID16()` macro. |
| characteristics | The array of characteristics that belong to this service. | |
@@ -68,10 +65,10 @@ definition consists of the following fields:
| *Field* | *Meaning* | *Notes* |
| ------- | --------- | ------- |
| uuid128 | The 128-bit UUID of this characteristic. | If the characteristic has a 16-bit UUID, you can convert it to its corresponding 128-bit UUID with the `BLE_UUID16()` macro. |
-| access\_cb | A callback function that gets executed whenever a peer device accesses this characteristic. | *For reads:* this function generates the value that gets sent back to the peer.<br>*For writes:* this function receives the written value as an argument. |
+| access_cb | A callback function that gets executed whenever a peer device accesses this characteristic. | *For reads:* this function generates the value that gets sent back to the peer.<br>*For writes:* this function provides the written value as an argument. |
| flags | Indicates which operations are permitted for this characteristic. The NimBLE stack responds negatively when a peer attempts an unsupported operation. | The full list of flags can be found under `ble_gatt_chr_flags` in [net/nimble/host/include/host/ble_gatt.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/include/host/ble_gatt.h).|
-A characteristic's access callback implements its behavior. Access
+The access callback is what implements the characteristic's behavior. Access
callbacks are described in detail in the next section:
[BLE Peripheral - Characteristic Access](bleprph-chr-access/).
@@ -84,20 +81,29 @@ characteristic array and service array.
```c hl_lines="26 31"
{
- /*** Service: Security test. */
+ /*** Alert Notification Service. */
.type = BLE_GATT_SVC_TYPE_PRIMARY,
- .uuid128 = gatt_svr_svc_sec_test_uuid,
+ .uuid128 = BLE_UUID16(GATT_SVR_SVC_ALERT_UUID),
.characteristics = (struct ble_gatt_chr_def[]) { {
- /*** Characteristic: Random number generator. */
- .uuid128 = gatt_svr_chr_sec_test_rand_uuid,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ | BLE_GATT_CHR_F_READ_ENC,
+ .uuid128 = BLE_UUID16(GATT_SVR_CHR_SUP_NEW_ALERT_CAT_UUID),
+ .access_cb = gatt_svr_chr_access_alert,
+ .flags = BLE_GATT_CHR_F_READ,
+ }, {
+ .uuid128 = BLE_UUID16(GATT_SVR_CHR_NEW_ALERT),
+ .access_cb = gatt_svr_chr_access_alert,
+ .flags = BLE_GATT_CHR_F_NOTIFY,
}, {
- /*** Characteristic: Static value. */
- .uuid128 = gatt_svr_chr_sec_test_static_uuid,
- .access_cb = gatt_svr_chr_access_sec_test,
- .flags = BLE_GATT_CHR_F_READ |
- BLE_GATT_CHR_F_WRITE | BLE_GATT_CHR_F_WRITE_ENC,
+ .uuid128 = BLE_UUID16(GATT_SVR_CHR_SUP_UNR_ALERT_CAT_UUID),
+ .access_cb = gatt_svr_chr_access_alert,
+ .flags = BLE_GATT_CHR_F_READ,
+ }, {
+ .uuid128 = BLE_UUID16(GATT_SVR_CHR_UNR_ALERT_STAT_UUID),
+ .access_cb = gatt_svr_chr_access_alert,
+ .flags = BLE_GATT_CHR_F_NOTIFY,
+ }, {
+ .uuid128 = BLE_UUID16(GATT_SVR_CHR_ALERT_NOT_CTRL_PT),
+ .access_cb = gatt_svr_chr_access_alert,
+ .flags = BLE_GATT_CHR_F_WRITE,
}, {
0, /* No more characteristics in this service. */
} },
@@ -112,32 +118,34 @@ characteristic array and service array.
#### Registration function
-After you have created your service table, your app needs to register it with the NimBLE stack. This is done by calling the [ble_gatts_add_svcs()](../../../network/ble/ble_hs/ble_gatts/functions/ble_gatts_add_svcs.md) function. There is a small complication, though. The NimBLE host needs to allocate sufficient resources upfront to accommodate all of your peripheral's services. You can ensure your GATT services are accounted for in the host configuration object by calling the [ble_gatts_count_cfg()](../../../network/ble/ble_hs/ble_gatts/functions/ble_gatts_count_cfg.md) function.
-
-The *bleprph* app registers its services in *gatt_svr.c* as follows:
+After you have created your service table, your app needs to register it with the NimBLE stack. This is done by calling the following function:
```c
int
-gatt_svr_init(struct ble_hs_cfg *cfg)
-{
- int rc;
+ble_gatts_register_svcs(const struct ble_gatt_svc_def *svcs,
+ ble_gatt_register_fn *cb, void *cb_arg)
+```
- rc = ble_gatts_count_cfg(gatt_svr_svcs, cfg);
- if (rc != 0) {
- return rc;
- }
+The function parameters are documented below.
- rc = ble_gatts_add_svcs(gatt_svr_svcs);
- if (rc != 0) {
- return rc;
- }
+| *Parameter* | *Meaning* | *Notes* |
+| ----------- | --------- | ------- |
+| svcs | The table of services to register. | |
+| cb | A callback that gets executed each time a service, characteristic, or descriptor is registered. | Optional; pass NULL if you don't want to be notified. |
+| cb\_arg | An argument that gets passed to the callback function on each invocation. | Optional; pass NULL if there is no callback or if you don't need a special argument. |
- return 0;
-}
+The `ble_gatts_register_svcs()` function returns 0 on success, or a
+*BLE_HS_E[...]* error code on failure.
-```
+More detailed information about the registration callback function can be found
+in the [BLE User Guide](../../../network/ble/ble_intro/) (TBD).
+
+The *bleprph* app registers its services as follows:
-You application will perform the above two-step process for each service definition array that you wish to register. Libraries that implement GATT services will generally expose an initialization function which does this for you.
+```c
+ rc = ble_gatts_register_svcs(gatt_svr_svcs, gatt_svr_register_cb, NULL);
+ assert(rc == 0);
+```
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/blinky_sram_olimex.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/blinky_sram_olimex.md b/docs/os/tutorials/blinky_sram_olimex.md
index 3bd5750..dd2439d 100644
--- a/docs/os/tutorials/blinky_sram_olimex.md
+++ b/docs/os/tutorials/blinky_sram_olimex.md
@@ -6,12 +6,12 @@ To download an application image directly into the embedded SRAM in the microcon
### What you need
-1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeySTM32-E407), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
+1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
3. USB A-B type cable to connect the debugger to your personal computer
4. Personal Computer with Mac OS (Mac: OS X Yosemite Version 10.10.5) or Linux box (Ubuntu 14.10: Utopic Unicorn)
5. An account on Github repository and *git* installed on your computer.
-6. It is assumed you have already installed newt tool.
+6. It is assumed you have already installed newt tool.
7. It is assumed you already installed native tools as described [here](../get_started/native_tools.md)
Also, we assume that you're familiar with UNIX shells. Let's gets started!
@@ -21,13 +21,13 @@ Also, we assume that you're familiar with UNIX shells. Let's gets started!
### Prepare the Software
-* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory.
-
+* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory.
+
<br>
### Create a project
-Create a new project to hold your work. For a deeper understanding, you can read about project creation in
+Create a new project to hold your work. For a deeper understanding, you can read about project creation in
[Get Started -- Creating Your First Project](../get_started/project_create.md)
or just follow the commands below.
@@ -41,15 +41,15 @@ or just follow the commands below.
$cd myproj
- $ newt install -v
+ $ newt install -v
apache-mynewt-core
Downloading repository description for apache-mynewt-core... success!
...
apache-mynewt-core successfully installed version 0.7.9-none
-```
+```
<br>
-
+
### Create a target
Change directory to ~/dev/myproj directory and define the *blinky* target inside myproj, using the *newt* tool. Starting with the target name, assign specific aspects of the project, as shown below, to pull the appropriate packages and build the right bundle or list for the board. For example, we set the build_profile, board support package (bsp), and app.
@@ -71,11 +71,11 @@ Change directory to ~/dev/myproj directory and define the *blinky* target inside
### Build the image
-Next, let's build the image for the above target. By default, the linker script within the `hw/bsp/olimex_stm32-e407_devboard` package builds an image for flash memory, which we don't want; instead, we want an image for the SRAM, so you need to switch that script with `run_from_sram.ld`.
-
-Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.*
-
+Next, let's build the image for the above target. By default, the linker script within the `hw/bsp/olimex_stm32-e407_devboard` package builds an image for flash memory, which we don't want; instead, we want an image for the SRAM, so you need to switch that script with `run_from_sram.ld`.
+Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.*
+
+
```no-highlight
$ cd ~/dev/myproj/repos/apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard/
$ diff olimex_stm32-e407_devboard.ld run_from_sram.ld
@@ -106,12 +106,12 @@ Afer you build the target, you can find the executable *blinky.elf* in the proje
<br>
-* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present.
+* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present.
To locate the bootloader, the board searches in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we will configure it to boot from SRAM by jumpering **B0_1** and **B1_1**.
-* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
+* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
-* The red PWR LED should be lit.
+* The red PWR LED should be lit.
* Connect the JTAG connector to the SWD/JTAG interface on the board. The other end of the cable should be connected to the USB port or hub of your computer.
@@ -133,7 +133,7 @@ To locate the bootloader, the board searches in three places: User Flash Memory,
(info)
...
target state: halted
- target halted due to debug-request, current mode: Thread
+ target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080003c0 msp: 0x10010000
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10036413
@@ -141,15 +141,15 @@ To locate the bootloader, the board searches in three places: User Flash Memory,
```
<br>
-Check the value of the msp (main service pointer) register. If it is not 0x10010000 as indicated above, you will have to manually set it after you open the gdb tool and load the image on it. For example,
-
+Check the value of the msp (main service pointer) register. If it is not 0x10010000 as indicated above, you will have to manually set it after you open the gdb tool and load the image on it. For example,
+
```no-highlight
(gdb) set $msp=0x10010000
```
<br>
- Now load the image and type "c" or "continue" from the GNU debugger.
+ Now load the image and type "c" or "continue" from the GNU debugger.
```no-highlight
(gdb) load ~/dev/myproj/bin/blinky/apps/blinky/blinky.elf
@@ -161,7 +161,8 @@ Check the value of the msp (main service pointer) register. If it is not 0x10010
(gdb) c
Continuing.
```
-
+
* Voil�! The board's LED should be blinking at 1 Hz. Success!
<br>
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/ibeacon.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/ibeacon.md b/docs/os/tutorials/ibeacon.md
index 3b4fa4e..1ff7a39 100644
--- a/docs/os/tutorials/ibeacon.md
+++ b/docs/os/tutorials/ibeacon.md
@@ -37,7 +37,7 @@ This function's parameters are documented below.
To demonstrate how the above function is used, we will now modify the *bleprph*
example application to send iBeacons. For some background behind the *bleprph*
app, we recommend you take a look at the [bleprph project
-tutorial](bleprph/bleprph-intro/). If you plan on making these modifications
+tutorial](bleprph/bleprph_intro/). If you plan on making these modifications
yourself, it might be a good idea to copy *bleprph* to your local repository
and work with the copy. In general, you should avoid changing a package that
newt downloads, as you will lose your changes the next time you upgrade the
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/olimex.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/olimex.md b/docs/os/tutorials/olimex.md
index 398bfe1..740c293 100644
--- a/docs/os/tutorials/olimex.md
+++ b/docs/os/tutorials/olimex.md
@@ -10,12 +10,12 @@ This tutorial shows you how to create a runtime image for an Olimex board to mak
### What you need
-1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeySTM32-E407), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
+1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
3. USB A-B type cable to connect the debugger to your personal computer
4. Personal Computer with Mac OS (Mac: OS X Yosemite Version 10.10.5) or Linux box (Ubuntu 14.10: Utopic Unicorn)
5. An account on Github repository and *git* installed on your computer.
-6. It is assumed you have already installed newt tool.
+6. It is assumed you have already installed newt tool.
7. It is assumed you already installed native tools as described [here](../get_started/native_tools.md)
Also, we assume that you're familiar with UNIX shells. Let's gets started!
@@ -25,13 +25,13 @@ Also, we assume that you're familiar with UNIX shells. Let's gets started!
### Prepare the Software
-* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory.
-
+* Make sure the PATH environment variable includes the $HOME/dev/go/bin directory.
+
<br>
### Create a project.
-Create a new project to hold your work. For a deeper understanding, you can read about project creation in
+Create a new project to hold your work. For a deeper understanding, you can read about project creation in
[Get Started -- Creating Your First Project](../get_started/project_create.md)
or just follow the commands below.
@@ -45,15 +45,15 @@ or just follow the commands below.
$cd myproj
- $ newt install -v
+ $ newt install -v
apache-mynewt-core
Downloading repository description for apache-mynewt-core... success!
...
apache-mynewt-core successfully installed version 0.7.9-none
-```
+```
<br>
-
+
### Create targets
Change directory to ~/dev/myproj directory and define the *blinky* target inside myproj, using the *newt* tool. Starting with the target name, assign specific aspects of the project, as shown below, to pull the appropriate packages and build the right bundle or list for the board. For example, we set the build_profile, board support package (bsp), and app.
@@ -64,13 +64,13 @@ Change directory to ~/dev/myproj directory and define the *blinky* target inside
$ newt target set blinky build_profile=debug
$ newt target set blinky bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
$ newt target set blinky app=apps/blinky
-
+
$ newt target create boot_olimex
$ newt target set boot_olimex app=@apache-mynewt-core/apps/boot
$ newt target set boot_olimex bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
$ newt target set boot_olimex build_profile=optimized
-
- $ newt target show
+
+ $ newt target show
targets/blinky
app=apps/blinky
bsp=@apache-mynewt-core/hw/bsp/olimex_stm32-e407_devboard
@@ -85,9 +85,9 @@ Change directory to ~/dev/myproj directory and define the *blinky* target inside
### Build the images
-Next, let's build the images for the above targets. Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.*
-
-
+Next, let's build the images for the above targets. Afer you build the target, you can find the executable *blinky.elf* in the project directory *~/dev/myproj/bin/blinky/apps/blinky/.*
+
+
```no-highlight
$ newt build blinky
Compiling case.c
@@ -98,7 +98,7 @@ Next, let's build the images for the above targets. Afer you build the target, y
$ ls ~/dev/myproj/bin/blinky/apps/blinky/
blinky.elf blinky.elf.bin blinky.elf.cmd
blinky.elf.lst blinky.elf.map
-
+
$ newt build boot_olimex
Building target targets/boot_olimex
App successfully built: ~/dev/myproj/bin/boot_olimex/apps/boot/boot.elf
@@ -106,7 +106,7 @@ Next, let's build the images for the above targets. Afer you build the target, y
<br>
-### Sign and create the blinky application image
+### Sign and create the blinky application image
You must sign and version your application image to download it using newt to the board. Use the newt create-image command to perform this action. You may assign an arbitrary version (e.g. 1.0.0) to the image.
@@ -129,12 +129,12 @@ Build manifest: ~/dev/myproj/bin/blinky/apps/blinky/manifest.json
<br>
-* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present.
+* B1_1/B1_0 and B0_1/B0_0 are PTH jumpers. Note that because the markings on the board may not always be accurate, when in doubt, you should always refer to the manual for the correct positioning. Since the jumpers are a pair, they should move together, and as such, the pair is responsible for the boot mode when bootloader is present.
To locate the bootloader, the board searches in three places: User Flash Memory, System Memory or the Embedded SRAM. For this Blinky project, we will configure it to boot from flash by jumpering **B0_0** and **B1_0**.
-* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
+* Connect USB-OTG#2 in the picture above to a USB port on your computer (or a powered USB hub to make sure there is enough power available to the board).
-* The red PWR LED should be lit.
+* The red PWR LED should be lit.
* Connect the JTAG connector to the SWD/JTAG interface on the board. The other end of the cable should be connected to the USB port or hub of your computer.
@@ -158,12 +158,12 @@ Successfully loaded image.
<br>
-**But wait...not so fast.** Let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor, severing the debug connection to the JTAG port. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board.
+**But wait...not so fast.** Let's double check that it is indeed booting from flash and making the LED blink from the image in flash. Pull the USB cable off the Olimex JTAG adaptor, severing the debug connection to the JTAG port. Next power off the Olimex board by pulling out the USB cable from the board. Wait for a couple of seconds and plug the USB cable back to the board.
The LED light will start blinking again. Success!
-
+
**Note #1:** If you want to download the image to flash and a gdb session opened up, use `newt debug blinky`. Type `c` to continue inside the gdb session.
-
+
```no-highlight
$ newt debug blinky
Debugging with ~/dev/myproj/hw/bsp/olimex_stm32-e407_...
@@ -175,7 +175,7 @@ Successfully loaded image.
(info)
...
target state: halted
- target halted due to debug-request, current mode: Thread
+ target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000250 msp: 0x10010000
Info : accepting 'gdb' connection from 3333
Info : device id = 0x10036413
@@ -186,22 +186,22 @@ Successfully loaded image.
```
<br>
-
+
**Note #2:** If you want to erase the flash and load the image again you may use the following commands from within gdb. `flash erase_sector 0 0 x` tells it to erase sectors 0 through x. When you ask it to display (in hex notation) the contents of the sector starting at location 'lma,' you should see all f's. The memory location 0x8000000 is the start or origin of the flash memory contents and is specified in the olimex_stm32-e407_devboard.ld linker script. The flash memory locations is specific to the processor.
```no-highlight
(gdb) monitor flash erase_sector 0 0 4
erased sectors 0 through 4 on flash bank 0 in 2.296712s
(gdb) monitor mdw 0x08000000 16
- 0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
- (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+ 0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+ (0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
+ (0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
(0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
(gdb) monitor flash info 0
```
### Conclusion
-Congratulations! You have now tried out a project on actual hardware. If this is your first time to embedded systems, this must feel like the best hands-on and low-level "Hello World" program ever.
+Congratulations! You have now tried out a project on actual hardware. If this is your first time to embedded systems, this must feel like the best hands-on and low-level "Hello World" program ever.
Good, we have more fun tutorials for you to get your hands dirty. Be bold and try other Blinky-like [tutorials](../tutorials/nRF52.md) or try enabling additional functionality such as [remote comms](project-target-slinky.md) on the current board.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/pics/LightBlue-1.jpg
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/LightBlue-1.jpg b/docs/os/tutorials/pics/LightBlue-1.jpg
new file mode 100644
index 0000000..87a305e
Binary files /dev/null and b/docs/os/tutorials/pics/LightBlue-1.jpg differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/pics/LightBlue-2.jpg
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/LightBlue-2.jpg b/docs/os/tutorials/pics/LightBlue-2.jpg
new file mode 100644
index 0000000..715deff
Binary files /dev/null and b/docs/os/tutorials/pics/LightBlue-2.jpg differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/pics/LightBlue-3.jpg
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/LightBlue-3.jpg b/docs/os/tutorials/pics/LightBlue-3.jpg
new file mode 100644
index 0000000..5ceb627
Binary files /dev/null and b/docs/os/tutorials/pics/LightBlue-3.jpg differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/pics/LightBlue-4.jpg
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/LightBlue-4.jpg b/docs/os/tutorials/pics/LightBlue-4.jpg
new file mode 100644
index 0000000..a8e35c3
Binary files /dev/null and b/docs/os/tutorials/pics/LightBlue-4.jpg differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/pics/LightBlue-5.jpg
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/LightBlue-5.jpg b/docs/os/tutorials/pics/LightBlue-5.jpg
new file mode 100644
index 0000000..4a3cbbd
Binary files /dev/null and b/docs/os/tutorials/pics/LightBlue-5.jpg differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/pics/LightBlue-6.jpg
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/pics/LightBlue-6.jpg b/docs/os/tutorials/pics/LightBlue-6.jpg
new file mode 100644
index 0000000..eb4ca4d
Binary files /dev/null and b/docs/os/tutorials/pics/LightBlue-6.jpg differ
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/tutorials/project-slinky.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/project-slinky.md b/docs/os/tutorials/project-slinky.md
index 5537001..2949437 100644
--- a/docs/os/tutorials/project-slinky.md
+++ b/docs/os/tutorials/project-slinky.md
@@ -1,13 +1,9 @@
## Project Sim Slinky
-<br>
-
-The goal of the project is to use a sample app called "Slinky" included in the Mynewt repository to enable remote communications with a device running the Mynewt OS. The protocol for remote communications is called newt manager (newtmgr). In this tutorial we will create a target for a simulated device and define it with the sample app "Slinky".
+### Objective
-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>
+The goal of the project is to enable and demonstrate remote communications with the Mynewt OS via newt manager (newtmgr). We will do this through building a project with Mynewt called Slinky that runs via the native platform.
### What you need
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/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 bea8049..8f71650 100644
--- a/docs/os/tutorials/project-target-slinky.md
+++ b/docs/os/tutorials/project-target-slinky.md
@@ -1,17 +1,13 @@
-## Project Slinky using STM32 board
+## Project Slinky
-<br>
-
-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.
+### Objective
-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>
+The goal of the project is to enable and demonstrate remote communications with the Mynewt OS via newt manager (newtmgr). We will do this through a project with Mynewt called Slinky that runs on the STM32-E407 board.
### What you need
-1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeySTM32-E407), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
+1. STM32-E407 development board from Olimex. You can order it from [http://www.mouser.com](http://www.mouser.com/ProductDetail/Olimex-Ltd/STM32-E407/?qs=UN6GZl1KCcit6Ye0xmPO4A%3D%3D), [http://www.digikey.com](http://www.digikey.com/product-detail/en/STM32-E407/1188-1093-ND/3726951), and other places.
2. ARM-USB-TINY-H connector with JTAG interface for debugging ARM microcontrollers (comes with the ribbon cable to hook up to the board)
3. USB A-B type cable to connect the debugger to your personal computer
4. A USB to TTL Serial Cable with female wiring harness. An example is [http://www.amazon.com/JBtek�-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88/ref=lp_464404_1_9?s=pc&ie=UTF8&qid=1454631303&sr=1-9](http://www.amazon.com/JBtek�-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88/ref=lp_464404_1_9?s=pc&ie=UTF8&qid=1454631303&sr=1-9)
@@ -26,18 +22,18 @@ The instructions assume the user is using a Bourne-compatible shell (e.g. bash o
* Install dependencies
* Define a target using the newt tool
* Build executables for the targets using the newt tool
-* Set up serial connection with the targets
+* Set up serial connection with the targets
* Create a connection profile using the newtmgr tool
* Use the newtmgr tool to communicate with the targets
### Install newt
-If you have not already installed `newt`, see the
+If you have not already installed `newt`, see the
[newt installation instructions](../get_started/get_started/) and ensure newt is installed an in your path.
### Install newtmgr
-If you have not already installed `newtmgr`, see the
+If you have not already installed `newtmgr`, see the
[newtmgr installation instructions](../../newtmgr/installing/) and ensure newtmgr is installed an in your path.
### Create a new project
@@ -116,11 +112,11 @@ Build manifest: /Users/paulfdietrich/dev/slinky/bin/stm32_slinky/apps/slinky/man
<br>
-### Using newtmgr with a remote target
+### Using newtmgr with a remote target
-* First make sure the USB A-B type cable is connected to the ARM-USB-TINY-H debugger connector on the Olimex board.
+* First make sure the USB A-B type cable is connected to the ARM-USB-TINY-H debugger connector on the Olimex board.
- Next go the to project directory and download the slinky project image to the flash of the Olimex board.
+ Next go the to project directory and download the slinky project image to the flash of the Olimex board.
```no-highlight
$ newt load stm32_bootloader
@@ -136,8 +132,8 @@ You can now disconnect the debugging cable from the board. You should see the gr
- * Connect the female RX pin of the USB-TTL serial cable to the TX of the UEXT connector on the board.
- * Connect the female TX pin of the USB-TTL serial cable to the RX of the UEXT connector on the board.
+ * Connect the female RX pin of the USB-TTL serial cable to the TX of the UEXT connector on the board.
+ * Connect the female TX pin of the USB-TTL serial cable to the RX of the UEXT connector on the board.
* Connect the GND pin of the USB-TTL serial cable to the GND of the UEXT connector on the board.
<br>
@@ -145,7 +141,7 @@ You can now disconnect the debugging cable from the board. You should see the gr
* Locate the serial connection established in the /dev directory of your computer. It should be of the type `tty.usbserial-<some identifier>`.
```no-highlight
- $ ls /dev/tty.usbserial-AJ03HAQQ
+ $ ls /dev/tty.usbserial-AJ03HAQQ
/dev/tty.usbserial-AJ03HAQQ
```
@@ -156,17 +152,17 @@ You can now disconnect the debugging cable from the board. You should see the gr
```no-highlight
$ pwd
/Users/<user>/dev/larva/project/slinky
- $ newtmgr conn add olimex01 type=serial connstring=/dev/tty.usbserial-AJ03HAQQ
+ $ newtmgr conn add olimex01 type=serial connstring=/dev/tty.usbserial-AJ03HAQQ
Connection profile olimex01 successfully added
$ newtmgr conn show
- Connection profiles:
+ Connection profiles:
sim1: type=serial, connstring='/dev/ttys007'
olimex01: type=serial, connstring='/dev/tty.usbserial-AJ03HAQQ'
```
<br>
-* Now go ahead and query the Olimex board to get responses back. The simplest command is the `echo` command to ask it to respond with the text you send it.
+* Now go ahead and query the Olimex board to get responses back. The simplest command is the `echo` command to ask it to respond with the text you send it.
```no-highlight
$ newtmgr echo -c olimex01 hello
@@ -182,3 +178,13 @@ You can now disconnect the debugging cable from the board. You should see the gr
idle (prio=255 tid=0 runtime=299916 cswcnt=313 stksize=32 stkusage=18 last_checkin=0 next_checkin=0)
shell (prio=3 tid=1 runtime=1 cswcnt=20 stksize=384 stkusage=60 last_checkin=0 next_checkin=0)
```
+
+
+
+
+
+
+
+
+
+
[07/19] incubator-mynewt-site git commit: Added STM32F4DISCOVERY to
the list of supported boards
Posted by ad...@apache.org.
Added STM32F4DISCOVERY to the list of supported boards
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/32902442
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/32902442
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/32902442
Branch: refs/heads/master
Commit: 32902442dadad4f49cdad50c50bcb4227757b682
Parents: 2f682cd
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 17:00:42 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 17:00:42 2016 -0800
----------------------------------------------------------------------
custom-theme/landing.html | 3 +
docs/about.md | 3 +-
docs/index.md | 2 +-
docs/network/ble/bletiny/bletiny_GAP.md | 128 +++--------
docs/network/ble/bletiny/bletiny_GATT.md | 56 ++---
docs/network/ble/bletiny/bletiny_advdata.md | 28 +--
docs/network/ble/bletiny_api.md | 144 +++++++++++++
docs/network/ble/ini_stack/ble_parent_ini.md | 2 +-
docs/newt/install/newt_linux.md | 23 --
docs/newt/install/newt_mac.md | 25 ---
docs/newt/newt_intro.md | 11 -
docs/os/core_os/porting/port_bsp.md | 20 +-
docs/os/core_os/porting/port_os.md | 41 ++--
docs/os/core_os/time/os_time_tick.md | 8 +-
docs/os/introduction.md | 32 +--
.../os/modules/hal/hal_cputime/hal_cpu_timer.md | 14 +-
docs/os/modules/hal/hal_gpio/hal_gpio.md | 19 +-
docs/os/modules/split/split.md | 173 ++++++++++-----
docs/os/tutorials/arduino_zero.md | 98 ++++-----
docs/os/tutorials/bleprph/bleprph-adv.md | 114 +++++-----
docs/os/tutorials/bleprph/bleprph-app.md | 108 ++++++++++
docs/os/tutorials/bleprph/bleprph-chr-access.md | 212 +++++++++++--------
docs/os/tutorials/bleprph/bleprph-conn.md | 156 ++++++++++++++
docs/os/tutorials/bleprph/bleprph-intro.md | 5 +-
docs/os/tutorials/bleprph/bleprph-svc-reg.md | 128 +++++------
docs/os/tutorials/blinky_sram_olimex.md | 41 ++--
docs/os/tutorials/ibeacon.md | 2 +-
docs/os/tutorials/olimex.md | 56 ++---
docs/os/tutorials/pics/LightBlue-1.jpg | Bin 0 -> 90014 bytes
docs/os/tutorials/pics/LightBlue-2.jpg | Bin 0 -> 121238 bytes
docs/os/tutorials/pics/LightBlue-3.jpg | Bin 0 -> 122447 bytes
docs/os/tutorials/pics/LightBlue-4.jpg | Bin 0 -> 94431 bytes
docs/os/tutorials/pics/LightBlue-5.jpg | Bin 0 -> 53663 bytes
docs/os/tutorials/pics/LightBlue-6.jpg | Bin 0 -> 97461 bytes
docs/os/tutorials/project-slinky.md | 8 +-
docs/os/tutorials/project-target-slinky.md | 46 ++--
docs/os/tutorials/tutorials.md | 24 +--
docs/quick-start.md | 2 +-
mkdocs.yml | 146 +------------
39 files changed, 1054 insertions(+), 824 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/custom-theme/landing.html
----------------------------------------------------------------------
diff --git a/custom-theme/landing.html b/custom-theme/landing.html
index d0014e5..2473b84 100644
--- a/custom-theme/landing.html
+++ b/custom-theme/landing.html
@@ -127,6 +127,9 @@
<a href="http://www.st.com/en/evaluation-tools/stm32f3discovery.html"> STM32F3DISCOVERY </a> from ST Micro (Cortex-M4)
</li>
<li>
+ <a href="http://www.st.com/en/evaluation-tools/stm32f4discovery.html"> STM32F4DISCOVERY </a> from ST Micro (Cortex-M4)
+ </li>
+ <li>
<a href=" https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware"> STM32-E407 </a> from Olimex (Cortex-M4)
</li>
<li>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/about.md
----------------------------------------------------------------------
diff --git a/docs/about.md b/docs/about.md
index 5ba9e00..a842db4 100644
--- a/docs/about.md
+++ b/docs/about.md
@@ -7,7 +7,6 @@ Some upcoming features:
* HAL redesign to abstract across a diverse set of chip peripherals ([View discussion thread](http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/201606.mbox/%3C06CB0682-8F67-4C3F-93E4-6A20444487A1%40apache.org%3E))
* HAL for SPI access (master and slave)
* Ability for drivers to turn on/off low power settings automatically
-* Support for Wi-Fi controllers via a socket interface
<font color="#F2853F"> The detailed roadmap is tracked on [JIRA for Mynewt](https://issues.apache.org/jira/browse/MYNEWT/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel). </font>
@@ -18,7 +17,7 @@ Some upcoming features:
The WISHLIST at the top of the roadmap on [JIRA for Mynewt](https://issues.apache.org/jira/browse/MYNEWT/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel) features all the new ideas awaiting discussion and review. Once the community decides to go ahead with a request, it is scheduled into a release. Generally, effort is made to schedule a requested feature into a particular version no later than 6 weeks prior to the planned release date.
-If you have suggestions for a new feature, use case, or implementation improvements, file a JIRA ticket with Issue Type set to "Wish". Introduce it in the [dev@](http://mail-archives.apache.org/mod_mbox/incubator-mynewt-dev/) mailing list with a link to the JIRA ticket. This assumes you have signed up for an account on JIRA and submitted a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project.
+If you have suggestions for a new feature, use case, or implementation improvements, file a JIRA ticket with Issue Type set to "Wish". Introduce it in the [dev@](dev@mynewt.incubator.apache.org) mailing list with a link to the JIRA ticket. This assumes you have signed up for an account on JIRA and submitted a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/index.md
----------------------------------------------------------------------
diff --git a/docs/index.md b/docs/index.md
index 8daa8aa..bc1906c 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1 +1 @@
-[//]: # (This is not used - see landing.html for content)
+Apache Mynewt is a real-time, modular operating system for connected IoT devices that need to operate for long periods of time under power, memory, and storage constraints. The first connectivity stack offered is BLE 4.2.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/network/ble/bletiny/bletiny_GAP.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/bletiny/bletiny_GAP.md b/docs/network/ble/bletiny/bletiny_GAP.md
index a6ff368..f89664c 100644
--- a/docs/network/ble/bletiny/bletiny_GAP.md
+++ b/docs/network/ble/bletiny/bletiny_GAP.md
@@ -5,107 +5,47 @@
Generic Access Profile (GAP) defines the generic procedures related to discovery of Bluetooth devices (idle mode procedures) and link management aspects of connecting to Bluetooth devices (connecting mode procedures). It also defines procedures related to use of different security levels.
-Several different modes and procedures may be performed simultaneously over an LE physical transport. The following modes and procedures are defined for use over an LE physical transport:
-
-1. **Broadcast mode and observation procedure**
- - These allow two devices to communicate in a unidirectional connectionless manner using the advertising events.
-2. **Discovery modes and procedures**
+Several different modes and procedures may be performed simultaneously over an LE physical transport. The following modes and procedures are defined for use over an LE physical transport:1. **Broadcast mode and observation procedure**
+ - These allow two devices to communicate in a unidirectional connectionless manner using the advertising events.2. **Discovery modes and procedures**
- All devices shall be in either non-discoverable mode or one of the discoverable modes.
- A device in the discoverable mode shall be in either the general discoverable mode or the limited discoverable mode.
- - A device in non-discoverable mode will not be discovered by any device that is performing either the general discovery procedure or the limited discovery procedure.
-3. **Connection modes and procedures**
+ - A device in non-discoverable mode will not be discovered by any device that is performing either the general discovery procedure or the limited discovery procedure.3. **Connection modes and procedures**
- allow a device to establish a connection to another device.
- allow updating of parameters of the connection
- - allow termination of the connection
-4. **Bonding modes and procedures**
+ - allow termination of the connection 4. **Bonding modes and procedures**
- Bonding allows two connected devices to exchange and store security and identity information to create a trusted relationship.
- - Bonding can occur only between two devices in bondable mode.
-
-
-<br>
-
-
-###Usage API
-
-
-|**Item No.** | **Modes and Procedures** | **nimBLE command** |
-|----|---------|---------------|
-| 1 | Broadcast Mode | `b adv conn=non disc=x` |
-| | Observation Procedure | `b scan dur=x disc=x type=x filt=x` |
-| 2 | Non-Discoverable mode | `b adv conn=x disc=non` |
-| | Limited Discoverable mode | `b adv conn=x disc=ltd` |
-| | General Discoverable mode | `b adv conn=x disc=gen` |
-| | Limited Discovery procedure | `b scan dur=x disc=ltd type=active filt=no_wl` |
-| | General Discovery procedure | `b scan dur=x disc=gen type=active filt=no_wl` |
-| | Name Discovery procedure | `b scan dur=x` <br> `b scan cancel` <br> `b conn peer_addr_type=x peer_addr=x` <br> `b read uuid=0x2a00` |
+ - Bonding can occur only between two devices in bondable mode.<br>
+###Usage API
+|**Item No.** | **Modes and Procedures** | **nimBLE command** ||----|---------|---------------|
+| 1 | Broadcast Mode | `b adv conn=non disc=x` || | Observation Procedure | `b scan dur=x disc=x type=x filt=x` |
+| 2 | Non-Discoverable mode | `b adv conn=x disc=non` || | Limited Discoverable mode | `b adv conn=x disc=ltd` |
+| | General Discoverable mode | `b adv conn=x disc=gen` || | Limited Discovery procedure | `b scan dur=x disc=ltd type=active filt=no_wl` |
+| | General Discovery procedure | `b scan dur=x disc=gen type=active filt=no_wl` |
+| | Name Discovery procedure | UNSUPPORTED |
| 3 | Non-connectable mode | `b adv conn=non disc=x` |
-| | Directed connectable mode | `b adv conn=dir [own_addr_type=x] [disc=x] [dur=x]` |
-| | Undirected connectable mode | `b adv conn=und [own_addr_type=x] [disc=x] [dur=x]` |
-| | Auto connection establishment procedure | `b wl addr_type=x addr=x [addr_type=y addr=y] [...]` <br> `b conn addr_type=wl` |
-| | General connection establishment procedure | `b scan dur=x` <br> `b scan cancel` <br> `b conn peer_addr_type=x peer_addr=x` |
-| | Selective connection establishment procedure | `b wl addr_type=x addr=x [addr_type=y addr=y] [...]` <br> `b scan filt=use_wl dur=x` <br> `b scan cancel` <br> `b conn peer_addr_type=x peer_addr=x [own_addr_type=x]` |
-| | Direct connection establishment procedure | `b conn addr_type=x addr=x [params]` |
-| | Connection parameter update procedure | `b update conn=x <params>` |
-| | Terminate connection procedure | `b term conn=x` |
-| 4 | Non-Bondable mode | `b set sm_data bonding=0` [\*] |
-| | Bondable mode | `b set sm_data bonding=1` [\*] |
-| | Bonding procedure | `b sec start conn=x` [\*] |
-
-**[\*]** Security is disabled by default in bletiny. To use the bonding modes and procedures, add the `-DNIMBLE_OPT_SM=1` cflag to your target.
-
-<br>
-
-### Address Types
-
-| *bletiny string* | *Description* | *Notes* |
-|------------------|---------------|
-| public | Public address. | |
-| random | Random static address. | |
-| rpa_pub | Resolvable private address, public identity. | Not available for all commands. |
-| rpa_rnd | Resolvable private address, random static identity. | Not available for all commands. |
-| wl | Use white list; ignore peer_addr parameter. | Only availble for "conn" command. |
-
-### Connection Parameters
-
-The Connection parameter definitions can be found in Section 7.8.12 of the BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E].
-
-| *Name* | *Description* | *bletiny string* |
-|----|---------|---------------|
-| LE_Scan_Interval | Recommendation from the Host on how long the Controller should scan | scan_itvl |
-| LE_Scan_Window | Recommendation from the Host on how frequently the Controller should scan | scan_window |
-| Peer_Address_Type | Whether the peer is using a public or random address (see Address types table). | peer_addr_type |
-| Peer_Address | The 6-byte device address of the peer; ignored if white list is used | peer_addr |
-| Own_Address_Type | The type of address to use when initiating the connection (see Address types table) | own_addr_type |
-| Conn_Interval_Min | Defines minimum allowed connection interval | itvl_min |
-| Conn_Interval_Max | Defines maximum allowed connection interval | itvl_max |
+| | Directed connectable mode | `b adv conn=dir disc=x addr_type=x addr=x` |
+| | Undirected connectable mode | `b adv conn=und disc=x` |
+| | Auto connection establishment procedure | `b wl addr_type=x addr=x` |
+| | Auto connection establishment procedure | `b conn addr_type=wl` |
+| | General connection establishment procedure | AVAILABLE SOON |
+| | Selective connection establishment procedure | AVAILABLE SOON |
+| | Direct connection establishment procedure | `b conn addr_type=x addr=x [params]` |
+| | Connection parameter update procedure | `b update conn=x <params>` |
+| | Terminate connection procedure | `b term conn=x` |
+| 4 | Non-Bondable mode | AVAILABLE SOON |
+| | Bondable mode | AVAILABLE SOON |
+| | Bonding procedure | AVAILABLE SOON |<br>
+### Connection Parameters
+
+The Connection parameter definitions can be found in Section 7.8.12 of the BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E].|**Name** | **Description** | **nimBLE parameter** ||----|---------|---------------|
+| Minimum connection interval | Defines minimum allowed connection interval| itvl_min |
+| Maximum connection interval | Defines maximum allowed connection interval | itvl_max |
| Conn_Latency | Defines the maximum allowed connection latency | latency |
| Supervision_Timeout | Link supervision timeout for the connection. | timeout |
-| Minimum_CE_Length | Informative parameter providing the Controller with the expected minimum length of the connection event| min_ce_len |
-| Maximum_CE_Length | Informative parameter providing the Controller with the expected maximum length of the connection event | max_ce_len |
-| Duration | Number of milliseconds before aborting the connect attempt | dur |
-
-### Advertisment Parameters
-
-| *bletiny string* | *Description* | *Notes* | *Default* |
-|------------------|---------------|---------|-----------|
-| conn | Connectable mode | See Connectable Modes table. | und |
-| disc | Discoverable mode | See Discoverable Modes table. | gen |
-| own_addr_type | The type of address to advertise with | See Address Types table. | public |
-| peer_addr_type | The peer's address type | Only used for directed advertising; see Address Types table. | public |
-| peer_addr | The peer's address | Only used for directed advertising | N/A |
-| chan_map | | | 0 |
-| filt | The filter policy | See Advertisement Filter Policies table. | none |
-| itvl_min | | units=0.625ms | non: 100ms; und/dir: 30ms |
-| itvl_max | | units=0.625ms | non: 150ms; und/dir: 60ms |
-| hd | Whether to use high-duty-cycle | 0/1 | 0 |
-| dur | | Milliseconds | Forever |
-
-### Advertisement Filter Policies
+|LE_Scan_Interval | Recommendation from the Host on how long the Controller should scan | scan_itvl |
+|LE_Scan_Window |Recommendation from the Host on how frequently the Controller should scan | scan_window |
+|Minimum_CE_Length | Informative parameter providing the Controller with the expected minimum length of the connection event| min_ce_len |
+|Maximum_CE_Length |Informative parameter providing the Controller with the expected maximum length of the connection event | max_ce_len |
-| *bletiny string* | *Description* | *Notes* |
-| -----------------|---------------|---------|
-| none | No filtering. No whitelist used. | Default |
-| scan | Process all connection requests but only scans from white list. | |
-| conn | Process all scan request but only connection requests from white list. | |
-| both | Ignore all scan and connection requests unless in white list. | |
+### Advertisement data fields
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/network/ble/bletiny/bletiny_GATT.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/bletiny/bletiny_GATT.md b/docs/network/ble/bletiny/bletiny_GATT.md
index 7469eb6..84ab2ac 100644
--- a/docs/network/ble/bletiny/bletiny_GATT.md
+++ b/docs/network/ble/bletiny/bletiny_GATT.md
@@ -3,52 +3,30 @@
<br>
GATT(GENERIC ATTRIBUTE PROFILE) describes a service framework using the Attribute Protocol for discovering services, and for reading and writing characteristic values on a peer device. There are 11 features defined in the GATT Profile, and each of the features is mapped to procedures and sub-procedures:
-
-
-|**Item No.** | **Feature** | **Sub-Procedure** | **nimBLE command** |
-|----|---------|---------------|------|
-| 1 | Server Configuration | Exchange MTU | `b mtu` |
-| 2 | Primary Service Discovery | Discover All Primary Services | `b disc svc conn=x` |
+|**Item No.** | **Feature** | **Sub-Procedure** | **nimBLE command** ||----|---------|---------------|------|| 1 | Server Configuration | Exchange MTU | `b mtu` | | 2 | Primary Service Discovery | Discover All Primary Services | `b disc svc conn=x` |
| | | Discover Primary Services By Service UUID | `b disc svc conn=x uuid=x` |
-| 3 | Relationship Discovery | Find Included Services | `b find inc_svcs conn=x start=x end=x` |
-| 4 | Characteristic Discovery | Discover All Characteristic of a Service | `b disc chr conn=x start=x end=x` |
-| | | Discover Characteristic by UUID | `b disc chr conn=x start=x end=x uuid=x` |
-| 5 | Characteristic Descriptor Discovery | Discover All Characteristic Descriptors | `b disc dsc conn=x start=x end=x` |
-| 6 | Reading a Characteristic Value | Read Characteristic Value | `b read conn=x attr=x` |
-| | | Read Using Characteristic UUID | `b read conn=x start=x end=x uuid=x` |
-| | | Read Long Characteristic Values | `b read conn=x attr=x long=1` |
-| | | Read Multiple Characteristic Values | `b read conn=x attr=x attr=y attr=z` |
-| 7 | Writing a Characteristic Value | Write Without Response | `b write conn=x value=0xXX:0xXX no_rsp=1` |
-| | | Signed Write Without Response | NOT SUPPORTED |
-| | | Write Characteristic Value | `b write conn=x attr=x value=0xXX:0xXX` |
-| | | Write Long Characteristic Values | `b write conn=x attr=x value=0xXX:0xXX long=1` |
-| | | Characteristic Value Reliable Writes | `b write conn=x attr=x value=0xXX:0xXX attr=y value=0xYY:0xYY` |
-| 8 | Notification of a Characteristic Value | Notifications | Write _0x01:0x00_ to CLIENT CONFIGURATION characteristic |
-| 9 | Indication of a Characteristic Value | Indications | Write _0x02:0x00_ to CLIENT CONFIGURATION characteristic |
-| 10| Reading a Characteristic Descriptor | Read Characteristic Descriptors | `b read conn=x attr=x` |
-| | | Read Long Characteristic Descriptors | `b read conn=x attr=x long=1` |
-| 11| Writing a Characteristic Descriptor | Write Characteristic Descriptors | `b write conn=x value=0xXX:0xXX` |
-| | | Write Long Characteristic Descriptors | `b write conn=x value=0xXX:0xXX long=1` |
-
-
-<br>
-
-### Using NimBLE commands
-
-
-Assuming you have discovered and established a BLE connection with at least one peer device (as explained earlier in [API for bletiny app](bletiny_api.md), you can find out what characteristics and services are available over these connections. Here is a recap.
-
-To show established connections:
-```
+| 3 | Relationship Discovery | Find Included Services | `b find inc_svcs conn=x start=x end=x` || 4 | Characteristic Discovery | Discover All Characteristic of a Service | `b disc chr conn=x start=x end=x` |
+| | | Discover Characteristic by UUID | `b disc chr conn=x start=x end=x uuid=x` || 5 | Characteristic Descriptor Discovery | Discover All Characteristic Descriptors | `b disc dsc conn=x start=x end=x` || 6 | Reading a Characteristic Value | Read Characteristic Value | `b read conn=x attr=x` |
+| | | Read Using Characteristic UUID | `b read conn=x start=x end=x uuid=x` || | | Read Long Characteristic Values | `b read conn=x attr=x long=1` || | | Read Multiple Characteristic Values | `b read conn=x attr=x attr=y attr=z` |
+| 7 | Writing a Characteristic Value | Write Without Response | `b write conn=x value=0xXX:0xXX no_rsp=1` || | | Signed Write Without Response | NOT SUPPORTED || | | Write Characteristic Value | `b write conn=x attr=x value=0xXX:0xXX` || | | Write Long Characteristic Values | `b write conn=x attr=x value=0xXX:0xXX long=1` || | | Characteristic Value Reliable Writes | `b write conn=x attr=x value=0xXX:0xXX attr=y value=0xYY:0xYY` || 8 | Notification of a Characteristic Value | Notifications | Write CLIENT CONFIGURATION characteristic || 9 | Indication of a Characteristic Value | Indications | Write CLIENT CONFIGURATION characteristic || 10| Reading a Characteristic Descriptor | Read Characteristic Descriptors | `b read conn=x attr=x` |
+| | | Read Long Characteristic Descriptors | `b read conn=x attr=x long=1` || 11 | Writing a Characteristic Descriptor | Write Characteristic Descriptors | `b write conn=x value=0xXX:0xXX` |
+| | | Write Long Characteristic Descriptors | `b write conn=x value=0xXX:0xXX long=1` |<br>
+### Using nimBLE commands
+Assuming you have discovered and established a BLE connection with at least one peer device (as explained earlier in [API for bletiny app](../bletiny_api.md), you can find out what characteristics and services are available over these connections. Here is a recap.
+```
b show conn
```
+To show discovered services
+```
+b show svc
+```
-To show discovered services, characteristics, and descriptors:
+To show discovered characteristics
```
b show chr
```
-To show connection RSSI:
+To show connection RSSI
```
b show rssi conn=x
-```
+```
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/network/ble/bletiny/bletiny_advdata.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/bletiny/bletiny_advdata.md b/docs/network/ble/bletiny/bletiny_advdata.md
index d2480bc..215232e 100644
--- a/docs/network/ble/bletiny/bletiny_advdata.md
+++ b/docs/network/ble/bletiny/bletiny_advdata.md
@@ -5,21 +5,12 @@
This part defines the advertisement data fields used in the `bletiny` app. For a complete list of all data types and formats used for Extended Inquiry Response (EIR), Advertising Data (AD), and OOB data blocks, refer to the Supplement to the Bluetooth Core Specification, CSSv6, available for download [here](https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=302735&_ga=1.133090766.1368218946.1444779486).
-
-<br>
-
-
-
-|**Name** | **Definition** | **Details** | **bletiny Notes** |
-|----|---------|---------------|--|
-| flags | Indicates basic information about the advertiser. | Flags used over the LE physical channel are: <br> * Limited Discoverable Mode <br> * General Discoverable Mode <br> * BR/EDR Not Supported <br> * Simultaneous LE and BR/EDR to Same Device Capable (Controller) <br> * Simultaneous LE and BR/EDR to Same Device Capable (Host) | NimBLE will auto-calculate if set to 0. |
-| uuids16 |16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 16-bit Service UUIDs available. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. | Set repeatedly for multiple service UUIDs. |
-| uuids16_is_complete | 16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
-| uuids32 | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 32-bit Service UUIDs available. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. | Set repeatedly for multiple service UUIDs. |
-| uuids32_is_complete | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
-| uuids128 | Global 128-bit Service UUIDs | More 128-bit Service UUIDs available. | Set repeatedly for multiple service UUIDs. |
-| uuids128_is_complete | Global 128-bit Service UUIDs | Complete list of 128-bit Service UUIDs |
-| tx_pwr_lvl | TX Power Level | Indicates the transmitted power level of the packet containing the data type. The TX Power Level data type may be used to calculate path loss on a received packet using the following equation: <br> <br> pathloss = Tx Power Level \u2013 RSSI <br> <br> where \u201cRSSI\u201d is the received signal strength, in dBm, of the packet received. | NimBLE will auto-calculate if set to -128. |
+<br>
+|**Name** | **Definition** | **Details** ||----|---------|---------------|
+| uuids16 |16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 16-bit Service UUIDs available. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. || uuids16_is_complete | 16-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 16 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
+| uuids32 | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is incomplete i.e. more 32-bit Service UUIDs available. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. || uuids32_is_complete | 32-bit Bluetooth Service UUIDs | Indicates the Service UUID list is complete. 32 bit UUIDs shall only be used if they are assigned by the Bluetooth SIG. |
+| uuids128 | Global 128-bit Service UUIDs | More 128-bit Service UUIDs available. || uuids128_is_complete | Global 128-bit Service UUIDs | Complete list of 128-bit Service UUIDs |
+| tx_pwr_lvl | TX Power Level | Indicates the transmitted power level of the packet containing the data type. The TX Power Level data type may be used to calculate path loss on a received packet using the following equation: <br> <br> pathloss = Tx Power Level \u2013 RSSI <br> <br> where \u201cRSSI\u201d is the received signal strength, in dBm, of the packet received. |
| device_class | Class of device | Size: 3 octets |
| slave_itvl_range | Slave Connection Interval Range | Contains the Peripheral\u2019s preferred connection interval range, for all logical connections. Size: 4 Octets . The first 2 octets defines the minimum value for the connection interval in the following manner: <br> <br> connIntervalmin = Conn_Interval_Min * 1.25 ms <br> <br> Conn_Interval_Min range: 0x0006 to 0x0C80 <br> Value of 0xFFFF indicates no specific minimum. <br> <br> The other 2 octets defines the maximum value for the connection interval in the following manner: <br> <br> connIntervalmax = Conn_Interval_Max * 1.25 ms <br> Conn_Interval_Max range: 0x0006 to 0x0C80 <br> Conn_Interval_Max shall be equal to or greater than the Conn_Interval_Min. <br> Value of 0xFFFF indicates no specific maximum.|
| svc_data_uuid16 | Service Data - 16 bit UUID | Size: 2 or more octets <br> The first 2 octets contain the 16 bit Service UUID followed by additional service data |
@@ -31,8 +22,5 @@ This part defines the advertisement data fields used in the `bletiny` app. For a
| svc_data_uuid32 | Service Data - 32 bit UUID | Size: 4 or more octets <br> The first 4 octets contain the 32 bit Service UUID followed by additional service data |
| svc_data_uuid128 | Service Data - 128 bit UUID | Size: 16 or more octets <br> The first 16 octets contain the 128 bit Service UUID followed by additional service data |
| uri | Uniform Resource Identifier (URI) | Scheme name string and URI as a UTF-8 string |
-| mfg_data | Manufacturer Specific data | Size: 2 or more octets <br> The first 2 octets contain the Company Identifier Code followed by additional manufacturer specific data |
-| eddystone_url | | |
-
-<br>
-
+| mfg_data | Manufacturer Specific data | Size: 2 or more octets <br> The first 2 octets contain the Company Identifier Code followed by additional manufacturer specific data |<br>
+
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/network/ble/bletiny_api.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/bletiny_api.md b/docs/network/ble/bletiny_api.md
new file mode 100644
index 0000000..a20b96a
--- /dev/null
+++ b/docs/network/ble/bletiny_api.md
@@ -0,0 +1,144 @@
+## API for bletiny app
+
+"bletiny" is one of the sample applications that come with Mynewt. It is a simple shell application which provides a basic interface to the host-side of the BLE stack. "bletiny" includes all the possible roles (Central/Peripheral) and they may be run simultaneously. You can run bletiny on a board and issue commands that make it behave as a central or a peripheral with different peers.
+
+Highlighted below are some of the ways you can use the API to establish connections and discover services and characteristics from peer devices. For descriptions of the full API, go to the next sections on [GAP in bletiny](bletiny/bletiny_GAP.md) and [GATT in bletiny](bletiny/bletiny_GATT.md).
+
+<br>
+
+### Set device public address.
+
+Currently the device public address is hardcoded to `0a:0b:0c:0d:0e:0f` in `bletiny` app but you can change it by going into its source code and initializing it to the desired value as described in the section on how to [initialize device addr](ini_stack/ble_devadd.md).
+
+<br>
+
+### Initiate a direct connection to a device
+
+In this case, your board is acting as a central and initiating a connection with another BLE device. The example assumes you know the address of the peer, either by scanning for available peers or because you have set up the peer yourself.
+
+```hl_lines="1"
+b conn addr_type=public addr=d4:f5:13:53:d2:43
+[ts=118609ssb, mod=64 level=2] connection complete; status=0 handle=1 peer_addr_type=0 peer_addr=0x43:0xd2:0x53:0x13:0xf5:0xd4 conn_itvl=40 conn_latency=0 supervision_timeout=256
+```
+
+The `handle=1` in the output indicates that it is connection-1.
+
+<br>
+
+### Configure advertisements to include device name
+
+In this case, your board is acting as a peripheral.
+
+```
+b set adv_data name=<your-device-name>
+```
+
+<br>
+
+### Begin sending undirected general advertisements
+
+In this case, your board is acting as a peripheral.
+
+```
+b adv conn=und disc=gen
+```
+
+<br>
+
+### Show established connections.
+
+```
+b show conn
+```
+
+<br>
+
+### Discover and display peer's services.
+
+This is how you discover and then display the services of the peer you established earlier across connection-1.
+
+```hl_lines="1 2"
+b disc svc conn=1
+b show chr
+[ts=132425ssb, mod=64 level=2] CONNECTION: handle=1 addr=d4:f5:13:53:d2:43
+[ts=132428ssb, mod=64 level=2] start=1 end=5 uuid=0x1800
+[ts=132433ssb, mod=64 level=2] start=6 end=16 uuid=0x1808
+[ts=132437ssb, mod=64 level=2] start=17 end=31 uuid=0x180a
+[ts=132441ssb, mod=64 level=2] start=32 end=65535 uuid=00000000-0000-1000-1000000000000000
+```
+
+<br>
+
+### Discover characteristics for each service on peer
+
+The following examples show how to find the characteristics for each service available on the peer device across connection-1. The start and end values depend on the specific services discovered using the previous command `b show chr`. Continuing with the example above, you can discover the characteristics of the first service and display it using the following commands.
+
+```hl_lines="1 2"
+b disc chr conn=1 start=1 end=5
+b show chr
+[ts=163063ssb, mod=64 level=2] CONNECTION: handle=1 addr=d4:f5:13:53:d2:43
+[ts=163067ssb, mod=64 level=2] start=1 end=5 uuid=0x1800
+[ts=163071ssb, mod=64 level=2] def_handle=2 val_handle=3 properties=0x02 uuid=0x2a00
+[ts=163078ssb, mod=64 level=2] def_handle=4 val_handle=5 properties=0x02 uuid=0x2a01
+[ts=163085ssb, mod=64 level=2] start=6 end=16 uuid=0x1808
+[ts=163089ssb, mod=64 level=2] start=17 end=31 uuid=0x180a
+[ts=163094ssb, mod=64 level=2] start=32 end=65535 uuid=00000000-0000-1000-1000000000000000
+```
+
+You can next discover characteristics for the second service and display.
+
+```hl_lines="1 2"
+b disc chr conn=1 start=6 end=16
+b show chr
+[ts=180631ssb, mod=64 level=2] CONNECTION: handle=1 addr=d4:f5:13:53:d2:43
+[ts=180634ssb, mod=64 level=2] start=1 end=5 uuid=0x1800
+[ts=180639ssb, mod=64 level=2] def_handle=2 val_handle=3 properties=0x02 uuid=0x2a00
+[ts=180646ssb, mod=64 level=2] def_handle=4 val_handle=5 properties=0x02 uuid=0x2a01
+[ts=180653ssb, mod=64 level=2] start=6 end=16 uuid=0x1808
+[ts=180657ssb, mod=64 level=2] def_handle=7 val_handle=8 properties=0x10 uuid=0x2a18
+[ts=180664ssb, mod=64 level=2] def_handle=10 val_handle=11 properties=0x02 uuid=0x2a51
+[ts=180672ssb, mod=64 level=2] def_handle=12 val_handle=13 properties=0x28 uuid=0x2a52
+[ts=180679ssb, mod=64 level=2] def_handle=15 val_handle=16 properties=0x02 uuid=0x2a08
+[ts=180686ssb, mod=64 level=2] start=17 end=31 uuid=0x180a
+[ts=180691ssb, mod=64 level=2] start=32 end=65535 uuid=00000000-0000-1000-1000000000000000
+```
+
+<br>
+
+### Discover descriptors for each characteristic on peer
+
+Just as before, the start and end values depend on the specific characteristics discovered.
+
+```
+b disc dsc conn=1 start=1 end=5
+b disc dsc conn=1 start=6 end=16
+b disc dsc conn=1 start=17 end=31
+```
+
+<br>
+
+### Read an attribute belonging to the peer
+
+```
+b read conn=1 attr=18 attr=21
+```
+
+<br>
+
+### Write to an attribute belonging to the peer
+
+```
+b write conn=1 attr=3 value=0x01:0x02:0x03
+```
+
+<br>
+
+### Perform a passive scan
+
+This is how you tell your board to listen to all advertisements around it. The duration is specified in ms.
+
+```
+b scan dur=1000 disc=gen type=passive filt=no_wl
+```
+
+<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/network/ble/ini_stack/ble_parent_ini.md
----------------------------------------------------------------------
diff --git a/docs/network/ble/ini_stack/ble_parent_ini.md b/docs/network/ble/ini_stack/ble_parent_ini.md
index 6928ef5..37054c5 100644
--- a/docs/network/ble/ini_stack/ble_parent_ini.md
+++ b/docs/network/ble/ini_stack/ble_parent_ini.md
@@ -6,7 +6,7 @@ application-specific work, the host parent task does work for NimBLE by
processing events generated by the host.
The process of creating an OS task is described in the [Add Task
-tutorial](../../../os/tutorials/event_queue/).
+tutorial](#../../../../os/tutorials/event_queue/).
**Priority:**
It is up to you which priority to use for the host parent task. Unlike the
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/newt/install/newt_linux.md
----------------------------------------------------------------------
diff --git a/docs/newt/install/newt_linux.md b/docs/newt/install/newt_linux.md
index 8029662..6f2509b 100644
--- a/docs/newt/install/newt_linux.md
+++ b/docs/newt/install/newt_linux.md
@@ -134,27 +134,4 @@ If you want to build the *newt* tool from its source code, follow the following
<br>
-#### 5. Updating the Newt tool
-
-* You will update the newt tool in the same place as you initially installed the newt tool.
-* Start by updating the git repository of the newt tool (you can change to a different branch using git checkout [branch] if you need to)
-* Then update each of the tools newt, newtmgr and newtvm as needed
-
-```no-highlight
- $ cd $GOPATH/src/mynewt.apache.org/newt
- $ git pull
- $ cd newt
- $ go install
- $ cd ../newtmgr
- $ go install
- $ cd ../newtvm
- $ go install
- $ ls "$GOPATH"/bin/
- newt newtmgr newtvm
-```
-
-That should have updated your newt, newtmgr and newtvm to the latest versions based on the git repository you used.
-
-<br>
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/newt/install/newt_mac.md
----------------------------------------------------------------------
diff --git a/docs/newt/install/newt_mac.md b/docs/newt/install/newt_mac.md
index f1eb586..0da1503 100644
--- a/docs/newt/install/newt_mac.md
+++ b/docs/newt/install/newt_mac.md
@@ -139,28 +139,3 @@ If you want to build the *newt* tool from its source code, follow the following
Use "newt help [command]" for more information about a command.
```
-<br>
-
-#### 5. Updating the Newt tool
-
-* You will update the newt tool in the same place as you initially installed the newt tool.
-* Start by updating the git repository of the newt tool (you can change to a different branch using git checkout [branch] if you need to)
-* Then update each of the tools newt, newtmgr and newtvm as needed
-
-```no-highlight
- $ cd $GOPATH/src/mynewt.apache.org/newt
- $ git pull
- $ cd newt
- $ go install
- $ cd ../newtmgr
- $ go install
- $ cd ../newtvm
- $ go install
- $ ls "$GOPATH"/bin/
- newt newtmgr newtvm
-```
-
-That should have updated your newt, newtmgr and newtvm to the latest versions based on the git repository you used.
-
-<br>
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/newt/newt_intro.md
----------------------------------------------------------------------
diff --git a/docs/newt/newt_intro.md b/docs/newt/newt_intro.md
index f736b09..89a7922 100644
--- a/docs/newt/newt_intro.md
+++ b/docs/newt/newt_intro.md
@@ -187,18 +187,7 @@ pkg.deps:
<br>
-### Autocompletion in Bash
-Newt has the ability to autocomplete within `bash`. The following instructions allow MAC users to enable autocomplete within `bash`.
-
-1. Install the autocomplete tools for bash via `brew install bash-completion`
-2. Tell your shell to use newt for autocompletion of newt via `complete -C "newt complete" newt`. You can add this to your .bashrc or other init file to have it automatically set for all bash shells.
-
-Notes:
-
-1. Autocomplete will give you flag hints, but only if you type a '-'.
-2. Autocomplete will not give you completion hints for the flag arguments (those optional things after the flag like `-l DEBUG`)
-3. Autocomplete uses newt to parse the project to find targets and libs.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/core_os/porting/port_bsp.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/porting/port_bsp.md b/docs/os/core_os/porting/port_bsp.md
index 1a34a9d..4747589 100644
--- a/docs/os/core_os/porting/port_bsp.md
+++ b/docs/os/core_os/porting/port_bsp.md
@@ -1,5 +1,5 @@
-#Create a BSP for your Target
+#Create a BSP for your Target
###Introduction
@@ -24,8 +24,8 @@ Select a name for your BSP. For the remainder of this document, we'll assume th
Create a directory `hw/bsp/myboard` using the name chosen above. Within this BSP directory, create the following subdirectories:
-Select a name for your BSP. For the remainder of this document,
-well assume the bsp is named `myboard`. In general its best to select a
+Select a name for your BSP. For the remainder of this document,
+well assume the bsp is named `myboard`. In general its best to select a
name that describes the board/system you are creating.
* `include`
@@ -34,7 +34,7 @@ name that describes the board/system you are creating.
###Create a Target using Mynewt
-Create a newt target for your test project for the BSP. To learn how to create a target, see this **howto** [Tutorial](../../get_started/project_create). Once you are familiar with creating targets, move on below to create a target to use to test your BSP.
+Create a newt target for your test project for the BSP. To learn how to create a target, see this **howto** [Tutorial](../../get_started/project1). Once you are familiar with creating targets, move on below to create a target to use to test your BSP.
It is recommended that you use a simple `project` like `blinky` to minimize time to get a working Mynewt system. For this document, we will assume the `target` is called `myboard_blinky` and uses project `blinky`.
@@ -43,7 +43,7 @@ Set the `bsp` of the project to `/hw/bsp/myboard`. While creating your target, y
When you are complete, your `target` may look similar to this.
```c
- $newt target show
+ $newt target show
myboard_blinky
arch=cortex_m0
bsp=hw/bsp/myboard
@@ -80,7 +80,7 @@ Optionally, create these files as necessary to provide all functionality from My
###Fill Out your Package File
-Edit the package file to describe your BSP.
+Edit the package file to describe your BSP.
The package file must contain:
@@ -102,7 +102,7 @@ The package file typically contains:
pkg.linkerscript.bootloader.OVERWRITE: "myboard_boot.ld"
pkg.downloadscript: "myboard_download.sh"
pkg.debugscript: "myboard_debug.sh"
- pkg.deps:
+ pkg.deps:
- hw/mcu/mymcu/variant
```
where `mymcu/variant` should be replaced with the specific MCU and variant used in your design.
@@ -160,7 +160,7 @@ Create an alternate linker script for the bootloader since it is typically linke
###Add Functions and Defines
-At this point, it will be possible to run the `newt` tool to build your target.
+At this point, it will be possible to run the `newt` tool to build your target.
You may run into complaints from the linker script that a few Mynewt specific functions are missing. We will describe these below.
@@ -173,7 +173,7 @@ There are also several libc definitions that can be stubbed in your first BSP. E
| **Function** | **Description** |
|-----------|-------------|
-| _sbrk | Returns memory from heap (used by malloc) |
+| _sbrk | Returns memory from heap (used by malloc) |
* Implement `_sbrk()`
@@ -232,5 +232,5 @@ The `LICENSE` file is an ASCII text file that describes the source license for t
package.
The `README.md` is a [markdown](https://en.wikipedia.org/wiki/Markdown)
- file that contains any documentation you
+ file that contains any documentation you
want to provide for the BSP.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/core_os/porting/port_os.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/porting/port_os.md b/docs/os/core_os/porting/port_os.md
index 0784fc4..1a3b779 100644
--- a/docs/os/core_os/porting/port_os.md
+++ b/docs/os/core_os/porting/port_os.md
@@ -1,35 +1,35 @@
# Porting Mynewt OS
-This chapter describes how to adapt the Mynewt OS to different platforms.
+This chapter describes how to adapt the Mynewt OS to different platforms.
###Description
-The Mynewt OS is a complete multi-tasking environment with scheduler, time
-control, buffer management, and synchronization objects. it also includes
-libraries and services like console, command shell, image manager,
+The Mynewt OS is a complete multi-tasking environment with scheduler, time
+control, buffer management, and synchronization objects. it also includes
+libraries and services like console, command shell, image manager,
bootloader, and file systems etc.
Thee majority of this software is platform independent and requires no
-intervention to run on your platform, but some of the components require
-support from the underlying platform.
+intervention to run on your platform, but some of the components require
+support from the underlying platform.
The platform dependency of these components can fall into several categories:
-* **CPU Core Dependencies** -- Specific code or
+* **CPU Core Dependencies** -- Specific code or
configuration to operate the CPU core within your target platform
-* **MCU Dependencies** -- Specific code or configuration to operate the MCU or
+* **MCU Dependencies** -- Specific code or configuration to operate the MCU or
SoC within your target platform
-* **BSP Dependencies** -- Specific code or configuration to accommodate the
-specific layout and functionality of your target platform
+* **BSP Dependencies** -- Specific code or configuration to accommodate the
+specific layout and functionality of your target platform
###BSP Dependency
-With all of the functionality provided by the core, MCU, and MCU HAL (Hardware Abstraction Layer), there are still some things that must be specified for your particular system. This
+With all of the functionality provided by the core, MCU, and MCU HAL (Hardware Abstraction Layer), there are still some things that must be specified for your particular system. This
is provided in Mynewt to allow you the flexibility to design for the exact
functionality, peripherals and features that you require in your product.
-In Mynewt, these settings/components are included in a Board Support Package
-(BSP). The BSP contains the information specific to running Mynewt on a target
+In Mynewt, these settings/components are included in a Board Support Package
+(BSP). The BSP contains the information specific to running Mynewt on a target
platform or hardware board. Mynewt supports some common open source hardware as well
as the development boards for some common MCUs. These development systems
might be enough for you to get your prototype up and running, but when building
@@ -37,13 +37,13 @@ a product you are likely going to have your own board which is slightly differen
from those already supported by Mynewt.
For example, you might decide on your system that 16 Kilobytes of flash space
-in one flash device is reserved for a flash file system. Or on your system
+in one flash device is reserved for a flash file system. Or on your system
you may decide that GPIO pin 5 of the MCU is connected to the system LED. Or
you may decide that the OS Tick (the underlying time source for the OS) should
-run slower than the defaults to conserve battery power. These types of
+run slower than the defaults to conserve battery power. These types of
behaviors are specified in the BSP.
-The information provided in the BSP (what you need to specify to get a
+The information provided in the BSP (what you need to specify to get a
complete executable) can vary depending on the MCU and its underlying core
architecture. For example, some MCUs have dedicated pins for UART, SPI etc,
so there is no configuration required in the BSP when using these peripherals.
@@ -51,14 +51,14 @@ However some MCUs have a pin multiplexor that allows the UART to be mapped to
several different pins. For these MCUs, the BSP must specify if and where
the UART pins should appear to match the hardware layout of your system.
-* If your BSP is already supported my Mynewt, there is no additional BSP work involved in porting to your platform. You need only to set the `bsp` attribute in your Mynewt target using the [newt command tool](../../../newt/newt_intro).
+* If your BSP is already supported my Mynewt, there is no additional BSP work involved in porting to your platform. You need only to set the `bsp` attribute in your Mynewt target using the [newt command tool](../../../../newt/newt_intro).
* If your BSP is not yet supported by Mynewt, you can add support following the instructions on [how to add BSP support to Mynewt](port_bsp.md)
###MCU Dependency
Some OS code depends on the MCU or SoC that the system contains. For example, the MCU may specify the potential memory map of the system - where code and data can reside.
-* If your MCU is already supported my Mynewt, there is no additional MCU work involved in porting to your platform. You need only to set the `arch` attribute in your Mynewt target using the [newt command tool](../../../newt/newt_intro).
+* If your MCU is already supported my Mynewt, there is no additional MCU work involved in porting to your platform. You need only to set the `arch` attribute in your Mynewt target using the [newt command tool](../../../../newt/newt_intro).
* If your MCU is not yet supported by Mynewt, you can add support following the instructions on[how to add MCU support to Mynewt](port_mcu.md)
@@ -67,9 +67,10 @@ Some OS code depends on the MCU or SoC that the system contains. For example, th
Mynewt's architecture supports a hardware abstraction layer (HAL) for common on or off-chip MCU peripherals such as GPIO, UARTs, flash memory etc. Even if your MCU is supported for the core OS, you may find that you need to implement the HAL functionality for a new peripheral. For a description of the HAL abstraction and implementation information,
see the [HAL API](../../modules/hal/hal.md)
-###CPU Core Dependency
+###CPU Core Dependency
Some OS code depends on the CPU core that your system is using. For example, a given CPU core has a specific assembly language instruction set, and may require special cross compiler or compiler settings to use the appropriate instruction set.
-* If your CPU architecture is already supported my Mynewt, there is no CPU core work involved in porting to your platform. You need only to set the `arch` and `compiler` attributes in your Mynewt target using the [newt command tool](../../../newt/newt_intro).
+* If your CPU architecture is already supported my Mynewt, there is no CPU core work involved in porting to your platform. You need only to set the `arch` and `compiler` attributes in your Mynewt target using the [newt command tool](../../../../newt/newt_intro).
* If your CPU architecture is not supported by Mynewt, you can add support following the instructions on [how to add CPU architecture support to Mynewt](port_cpu.md)
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/core_os/time/os_time_tick.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time_tick.md b/docs/os/core_os/time/os_time_tick.md
index 1c217e1..420aa23 100644
--- a/docs/os/core_os/time/os_time_tick.md
+++ b/docs/os/core_os/time/os_time_tick.md
@@ -1,10 +1,10 @@
## <font color="F2853F" style="font-size:24pt">os_time_tick</font>
```c
-void os_time_tick(void)
+void os_time_tick(void)
```
-Increments the OS time tick for the system. Typically, this is called in one place by the architecture specific OS code (`libs/os/arch`) `timer_handler` which is in turn called by the BSP specific code assigned to drive the OS timer tick. See [Porting Mynewt OS](../porting/port_os) for details.
+Increments the OS time tick for the system. Typically, this is called in one place by the architecture specific OS code (`libs/os/arch`) `timer_handler` which is in turn called by the BSP specific code assigned to drive the OS timer tick. See [Porting Mynewt OS](../port_os) for details.
#### Arguments
@@ -14,7 +14,7 @@ N/A
N/A
-#### Notes
+#### Notes
Called for every single tick by the architecture specific functions.
@@ -25,3 +25,5 @@ Called for every single tick by the architecture specific functions.
```c
os_time_tick();
```
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/introduction.md
----------------------------------------------------------------------
diff --git a/docs/os/introduction.md b/docs/os/introduction.md
index 4d83372..22df5c9 100644
--- a/docs/os/introduction.md
+++ b/docs/os/introduction.md
@@ -3,14 +3,14 @@
### Welcome to Apache Mynewt
Apache Mynewt is an operating system that makes it easy to develop
-applications for microcontroller environments where power and cost
-are driving factors. Examples of these devices are connected locks,
+applications for microcontroller environments where power and cost
+are driving factors. Examples of these devices are connected locks,
lights, and wearables.
-Microcontroller environments have a number of characteristics that
-makes the operating system requirements for them unique:
+Microcontroller environments have a number of characteristics that
+makes the operating system requirements for them unique:
-* Low memory footprint: memory on these systems range from
+* Low memory footprint: memory on these systems range from
8-16KB (on the low end) to 16MB (on the high end).
* Reduced code size: code often runs out of flash, and total available code size ranges from 64-128KB to 16-32MB.
@@ -22,7 +22,7 @@ battery power and maximize power usage.
As more and more devices get connected, these interconnected devices perform complex tasks. To
perform these tasks, you need low-level operational functionality built into the operating system.
-Typically, connected devices built with these microcontrollers perform a myriad of functions:
+Typically, connected devices built with these microcontrollers perform a myriad of functions:
* Networking Stacks: Bluetooth Low Energy and Thread
@@ -34,23 +34,23 @@ to keep time.
Apache Mynewt accomplishes all the above easily, by providing a complete
operating system for constrained devices, including:
-* A fully open-source Bluetooth Low Energy stack with both Host and
-Controller implementations.
+* A fully open-source Bluetooth Low Energy stack with both Host and
+Controller implementations.
* A pre-emptive, multi-tasking Real Time operating system kernel
-* A Hardware Abstraction Layer (HAL) that abstracts the MCU's
+* A Hardware Abstraction Layer (HAL) that abstracts the MCU's
peripheral functions, allowing developers to easily write cross-platform
code.
<br>
### Newt ###
-In order to provide all this functionality, and operate in an
-extremely low resource environment, Mynewt provides a very fine-grained source
-package management and build system tool, called *newt*.
+In order to provide all this functionality, and operate in an
+extremely low resource environment, Mynewt provides a very fine-grained source
+package management and build system tool, called *newt*.
-You can install and build *newt* for [Linux](../newt/install/newt_linux/) or [Mac](../newt/install/newt_mac/).
+You can install and build *newt* for [Linux](..//newt/install/newt_linux/) or [Mac](../newt/install/newt_mac/).
<br>
@@ -59,13 +59,13 @@ You can install and build *newt* for [Linux](../newt/install/newt_linux/) or [Ma
In order to enable a user to communicate with remote instances of Mynewt OS and query, configure, and operate them, Mynewt provides an application tool called Newt Manager or `newtmgr`.
-You can install and build *newtmgr* from source code on [Linux or Mac](../newtmgr/installing/).
+You can install and build *newtmgr* from source code on [Linux or Mac](../newtmgr/installing/).
<br>
### Build your first Mynewt App with Newt ###
-With the introductions out of the way, now is a good time to [get set up and
-started](get_started/get_started/) with your first Mynewt application.
+With the introductions out of the way, now is a good time to [get set up and
+started](../get_started/get_started/) with your first Mynewt application.
Happy Hacking!
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md b/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md
index d430dfc..99fa830 100644
--- a/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md
+++ b/docs/os/modules/hal/hal_cputime/hal_cpu_timer.md
@@ -7,7 +7,7 @@ The hardware independent interface to system time.
Contains several different interface.
-* An interface to get the current CPU time
+* An interface to get the current CPU time
* Interfaces to convert between CPU time and clock time (microseconds etc.)
* An Interface to set up a software timer based on CPU time.
@@ -17,13 +17,15 @@ Contains several different interface.
###CPU Time
-The CPU time is not the same as the [os_time](). Typically,
+The CPU time is not the same as the [os_time](TBD). Typically,
the os_time is set to a much slower tick rate than the CPU time. The CPU
time should be used for timing real-time events at exact times. The os_time
-should be used for system level timeout etc that are not in fine time
+should be used for system level timeout etc that are not in fine time
resolutions. In fact, cputime is not part of the os at all, but a hardware
-layer abstraction to high resolution timers.
+layer abstraction to high resolution timers.
-There are methods to get the cputime as 32-bit and 64-bit values. Both
+There are methods to get the cputime as 32-bit and 64-bit values. Both
values may eventually wrap, but for timing short events a 32-bit value
-may be sufficient and would
+may be sufficient and would
+
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/modules/hal/hal_gpio/hal_gpio.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/hal/hal_gpio/hal_gpio.md b/docs/os/modules/hal/hal_gpio/hal_gpio.md
index a8d6af6..5518bc8 100644
--- a/docs/os/modules/hal/hal_gpio/hal_gpio.md
+++ b/docs/os/modules/hal/hal_gpio/hal_gpio.md
@@ -8,20 +8,20 @@ This is the hardware independent GPIO (General Purpose Input Output) Interface f
Contains the basic operations to set and read General Purpose Digital I/O Pins
within a Mynewt system.
-Individual GPIOs are referenced in the APIs as `pins`. However, in this interface the `pins` are virtual GPIO pins. The MCU hal driver maps these virtual `pins` to the physical GPIO ports and pins.
+Individual GPIOs are referenced in the APIs as `pins`. However, in this interface the `pins` are virtual GPIO pins. The MCU hal driver maps these virtual `pins` to the physical GPIO ports and pins.
Typically, the BSP code may define named I/O pins in terms of these virtual `pins` to describe the devices attached to the physical pins.
Here's a brief example so you can get the gist of the translation.
-Suppose my product uses the stm32F4xx processor. There already exists support for this processor within Mynewt. The processor has N ports (A,B,C..) of 16 GPIO pins per port. The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 and so on. The exact number of physical port (and virtual
+Suppose my product uses the stm32F4xx processor. There already exists support for this processor within Mynewt. The processor has N ports (A,B,C..) of 16 GPIO pins per port. The MCU hal_gpio driver maps these to a set of virtual pins 0-N where port A maps to 0-15, Port B maps to 16-31, Port C maps to 32-47 and so on. The exact number of physical port (and virtual
port pins) depends on the specific variant of the stm32F4xx.
-So if I want to turn on port B pin 3, that would be virtual pin 1*16 + 3 = 19.
-This translation is defined in the MCU implementation of
-[hal_gpio.c](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/mcu/stm/stm32f4xx/src/hal_gpio.c)
-for the stmf32F4xx. Each MCU will typically have a different translation method
-depending on its GPIO architecture.
+So if I want to turn on port B pin 3, that would be virtual pin 1*16 + 3 = 19.
+This translation is defined in the MCU implementation of
+[hal_gpio.c](https://github.com/apache/incubator-mynewt-larva/blob/master/hw/mcu/stm/stm32f4xx/src/hal_gpio.c)
+for the stmf32F4xx. Each MCU will typically have a different translation method
+depending on its GPIO architecture.
Now, when writing a BSP, it's common to give names to the relevant port pins that you are using. Thus, the BSP may define a mapping between a function and a virtual port pin. For example
@@ -46,10 +46,11 @@ SYSTEM_LED --> hal_gpio virtual pin 37 --> port C pin 5 on the stm34F4xx
#### Blinky
-Blinky uses the hal_gpio to blink the system LED. The blinky source code is available
-[here](https://github.com/apache/incubator-mynewt-core/blob/master/apps/blinky/src/main.c).
+Blinky uses the hal_gpio to blink the system LED. The blinky source code is available
+[here](https://github.com/apache/incubator-mynewt-larva/blob/master/project/blinky/src/main.c).
Examine how `task1_handler` initializes and toggles the GPIO to control the LED.
<br>
---------------------
+
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/32902442/docs/os/modules/split/split.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/split/split.md b/docs/os/modules/split/split.md
index 0733e6f..bd54dde 100644
--- a/docs/os/modules/split/split.md
+++ b/docs/os/modules/split/split.md
@@ -4,18 +4,25 @@
## Description
-Split images allow the user to build the application content separate from the library content by splitting an application into two pieces:
+Split images allow the user to build the application content separate from the library content by
+splitting an application into two pieces:
-* A "loader" which contains a separate application that can perform upgrades and manage split images. The "loader" resides in slot 1.
-* A "split app" which contains the main application content and references the libraries in the loader by static linkage. The "split app" resides in slot 2.
+* A "loader" which contains a separate application that can perform upgrades and manage split images.
+The "loader" resides in slot 1.
+* A "split app" which contains the main application content and references the libraries in the loader
+by static linkage. The "split app" resides in slot 2.
## Goals
-The goal of split images is to allow a larger application to run along with large components of mynewt such as [nimble BLE stack](../../../network/ble/ble_intro/) and [neutron flash file system(nffs)](../fs/nffs/nffs.md).
+The goal of split images is to allow a larger application to run along with large components of
+mynewt such as [nimble BLE stack](../../../network/ble/ble_intro/) and [neutron flash file system(nffs)](../fs/nffs/nffs.md).
## Concept
-In a typical mynewt application, an application is contained wholly within an image slot. Typically there are at least two image slots since the image runs from one slot while uploading new code into the second slot. Each image is capable of erasing and uploading another image. Each image is completely stand-alone; that is, each image contains all of the libraries and components that it needs.
+In a typical mynewt application, an application is contained wholly within an image slot. Typically
+there are at least two image slots since the image runs from one slot while uploading new code into
+the second slot. Each image is capable of erasing and uploading another image. Each image is completely
+stand-alone; that is, each image contains all of the libraries and components that it needs.
On a typical 256 kbyte flash, a flash layout might look like this:
@@ -40,18 +47,25 @@ Now, suppose the desired image contains:
| newtmgr | 7 k |
-which total 106k. With an image slot size of 108k this leaves only a small amount of code space remaining for the application.
+which total 106k. With an image slot size of 108k this leaves only a small amount of code space
+remaining for the application.
-However, we can see that these packages contain everything you need to upgrade and configure, so if we build a stand-alone loader with these components, we can build the app as a split image and get the entire second image slot to store application code and constant data.
+However, we can see that these packages contain everything you need to upgrade and configure, so
+if we build a stand-alone loader with these components, we can build the app as a split image and
+get the entire second image slot to store application code and constant data.
## When do I use split images
-If your application fits into the available image slots, there is no advantage to using split images. In general, split images are harder to debug and more complicated to upload. However for a larger application, there may not be enough flash space to have two copies of the entire application. This is when split image becomes necessary.
+If your application fits into the available image slots, there is no advantage to using split
+images. In general, split images are harder to debug and more complicated to upload. However
+for a larger application, there may not be enough flash space to have two copies of the entire
+application. This is when split image becomes necessary.
## How do I tell Newt I am building a split image?
-Newt looks for the variable `loader` in your target file. If it finds `loader` variable, it will build a split image. For example,
+Newt looks for the variable `loader` in your target file. If it finds `loader` variable, it
+will build a split image. For example,
```
targets/app
@@ -75,14 +89,16 @@ Split image requires BSP support. The following BSPs support split images:
## Loaders
-The following applications have been enabled as loaders. You may choose to build your own loader application, and these can serve as samples.
+The following applications have been enabled as loaders. You may choose to build your own loader
+application, and these can serve as samples.
* @apache-mynewt-core/apps/slinky
* @apache-mynewt-core/apps/bleprph
## Split Apps
-The following applications have been enabled as split applications. If you choose to build your own split application these can serve as samples. Note that slinky can be either a loader image or a split app image.
+The following applications have been enabled as split applications. If you choose to build your own
+split application these can serve as samples. Note that slinky can be either a loader image or a split app image.
* @apache-mynewt-core/apps/slinky
* @apache-mynewt-core/apps/splitty
@@ -91,58 +107,81 @@ The following applications have been enabled as split applications. If you choos
A split image is built as follows:
-First newt builds the `app` and `loader` images separately to ensure they are consistent (no errors) and to generate elf files which can inform newt of the symbols used by each part.
+First newt builds the `app` and `loader` images separately to ensure they are consistent (no errors) and
+to generate elf files which can inform newt of the symbols used by each part.
-Then newt collects the symbols used by both `app` and `loader` in two ways. It collects the set of symbols from the `.elf` files. It also collects all the possible symbols from the `.a` files for each application.
+Then newt collects the symbols used by both `app` and `loader` in two ways. It collects the set of
+symbols from the `.elf` files. It also collects all the possible symbols from the `.a` files for
+each application.
-Newt builds the set of packages that the two applications share. It ensures that all the symbols used in those packages are matching. NOTE: because of features and #ifdefs, its possible for the two package to have symbols that are not the same. In this case newt generates an error and will not build a split image.
+Newt builds the set of packages that the two applications share. It ensures that all the symbols
+used in those packages are matching. NOTE: because of features and #ifdefs, its possible for the
+two package to have symbols that are not the same. In this case newt generates an error and will
+not build a split image.
Then newt creates the list of symbols that the two applications share from those packages (using the .elf files).
-Newt re-links the loader to ensure all of these symbols are present in the loader application (by forcing the linker to include them in the `.elf`).
+Newt re-links the loader to ensure all of these symbols are present in the loader application (by
+forcing the linker to include them in the `.elf`).
-Newt builds a special copy of the loader.elf with only these symbols (and the handful of symbols discussed in the linking section above).
+Newt builds a special copy of the loader.elf with only these symbols (and the handful of symbols
+discussed in the linking section above).
-Finally, newt links the application, replacing the common .a libraries with the special loader.elf image during the link.
+Finally, newt links the application, replacing the common .a libraries with the special loader.elf
+image during the link.
## Design
### Bootloader
-The bootloader has been modified to support "non bootable" images like split app images. A flag in the image header denotes the image as "non-bootable". When this flag is set, the bootloader will not boot the split app image, nor will it copy it to the slot 1 location. Loader images are bootable, split app images are not.
+The [bootloader](../bootloader/bootloader.md) has been modified to support "non bootable" images like split app images. A flag in
+the image header denotes the image as "non-bootable". When this flag is set, the bootloader will
+not boot the split app image, nor will it copy it to the slot 1 location. Loader images are bootable,
+split app images are not.
### Newt
Newt builds a split image when the token `loader=@apache-mynewt-core/apps/slinky` is present in the target file.
-Newt has a `Builder` object that is responsible for building an image. This features a `targetBuilder` object that contains two builders (one for the app and one for the loader).
+Newt has a `Builder` object that is responsible for building an image. This features a `targetBuilder`
+object that contains two builders (one for the app and one for the loader).
The `Builder` object has been expanded to include options for building as part of a split image.
* Ability to specify the linker file during the link
* Ability to specify a set of keep_symbols during the link
-Newt commands like download, size, create-image have been expanded to perform operations twice (once for loader and once for app) if the loader target is present.
+Newt commands like download, size, create-image have been expanded to perform operations twice
+(once for loader and once for app) if the loader target is present.
-During normal single-image builds, the `targetBuilder` initializes and builds the application `builder`. During the split image build, the `targetBuilder` performs the steps outlined in the section above using the two `builder`s for the loader and app.
+During normal single-image builds, the `targetBuilder` initializes and builds the application
+`builder`. During the split image build, the `targetBuilder` performs the steps outlined in the
+section above using the two `builder`s for the loader and app.
Special symbol and link features are designed as follows:
* Newt uses objdump to parse the symbol maps in the `.a` and `.elf` files.
-* Newt uses the `--undefined=` option of the linker to force the loader to keep symbols used by the app (but not used by the linker)
+* Newt uses the `--undefined=` option of the linker to force the loader to keep symbols used by
+the app (but not used by the linker)
* Newt uses objcopy with the `-K` (keep) option when building the special linker `.elf`.
* Newt uses the `--just-symbols` option of the linker to link against the loader `.elf` file.
#### newt create-image
-`create-image` uses two different methods to compute the image hash for standard and split images. For split images, the hash is computed starting with the 32-byte hash of the loader, then continuing with the hashing algorithm used by the standard application. This ensures that the split app can be "validated" against a loader image specifically.
+`create-image` uses two different methods to compute the image hash for standard and split images.
+For split images, the hash is computed starting with the 32-byte hash of the loader, then continuing
+with the hashing algorithm used by the standard application. This ensures that the split app can be "validated" against a loader image specifically.
#### newt errors
Newt has several new build errors when building split images.
-* Linker script undefined. If the BSP for your application does not define a split image linker script the build will fail.
+* Linker script undefined. If the BSP for your application does not define a split image linker script
+the build will fail.
-If newt finds that the same library (for example libs/os) has a different implementaiton in the loader and app, it will generate an error and fail to build. These differences can arise when `#ifdef` or features are included in one app and not the other. For example, it the loader includes `libs/console/stubs` and the app includes `libs/console/full` this may change implementations of certain functions within other packages.
+If newt finds that the same library (for example libs/os) has a different implementaiton in the loader
+and app, it will generate an error and fail to build. These differences can arise when `#ifdef` or features
+are included in one app and not the other. For example, it the loader includes `libs/console/stubs` and the
+app includes `libs/console/full` this may change implementations of certain functions within other packages.
### Image manifest
@@ -156,15 +195,18 @@ newt builds a single manifest for split images, adding extra tags to the manifes
]
```
-The manifest lists packages in both the loader and app. The app package list only contains those packages that reside in the app image itself.
+The manifest lists packages in both the loader and app. The app package list only contains those
+packages that reside in the app image itself.
### libs/bootutil
-Bootutil has been expanded to include a function that looks for a split app image in slot 2, verifies that it matches the loader image in slot 1 and then fetches the entry information for the split app.
+Bootutil has been expanded to include a function that looks for a split app image in slot 2, verifies
+that it matches the loader image in slot 1 and then fetches the entry information for the split app.
### libs/split
-A small split image library was created to provide newtmgr commands for split image and to hold the configuration for split image. See newtmgr below for details.
+A small split image library was created to provide newtmgr commands for split image and to hold the
+configuration for split image. See newtmgr below for details.
It also contains the function used by a loader to validate and boot a split image.
@@ -180,17 +222,23 @@ A sample app that can be built as a split image with slinky.
A BSP needs additional components to be "split image ready".
-The split image requires a special linker script. The split image needs to run from the second image partition (since it's using the loader library that is linked to be placed in the first partition). It needs to reserve space for RAM used by the loader. It also does not need to include the vector table (just a bit of it).
+The split image requires a special linker script. The split image needs to run from the second image
+partition (since it's using the loader library that is linked to be placed in the first partition).
+It needs to reserve space for RAM used by the loader. It also does not need to include the vector table (just a bit of it).
-The startup of the split image is different than a typical image. It needs to copy `.data` from the loader image, and zero the loader image bss. For this, it must reference symbols defined in the linker script of the loader. It has a special entry symbol that differentiates it from the entry symbol in the loader application.
+The startup of the split image is different than a typical image. It needs to copy `.data` from the
+loader image, and zero the loader image bss. For this, it must reference symbols defined in the linker
+script of the loader. It has a special entry symbol that differentiates it from the entry symbol in the
+loader application.
-Several of the bsp scripts need to handle additional agruments to deal with the two images produced by newt when building split images - mainly download and debug.
+Several of the bsp scripts need to handle additional agruments to deal with the two images produced
+by newt when building split images - mainly download and debug.
Add the following components to enable your BSP for split images:
1. A split image linker file
2. A startup file for the split image
-3. A property in the pkg.yml file to tell newt what linker script to use for partition 2 images. The property is defined as `pkg.part2linkerscript: "split-nrf52dk.ld` for example.
+3. A property in the pkg.yml file to tell newt what linker script to use for partition 2 images. The property is defined as `pkg.part2linkerscript: "split-nrf52dk.ld` for example.
4. Modified download script
5. Modified sbrk functionality
@@ -202,7 +250,7 @@ The split image linker script must have the following.
The split linker must be linked to run from the second flash image slot. For example:
-```
+```c
MEMORY
{
FLASH (rx) : ORIGIN = 0x00042000, LENGTH = 0x3a000
@@ -212,11 +260,13 @@ MEMORY
The split linker must define the entry symbol as Reset_Handler_split. For example:
-```
+```c
ENTRY(Reset_Handler_split)
```
-The split linker must define the first two words in the vector table (initial SP and Reset Vector). The additional vector entries are part of the loader and are not needed in the split image. The bootloader accesses these entries at the beginning of the image slot (first 2 words). For example:
+The split linker must define the first two words in the vector table (initial SP and Reset Vector). The additional
+vector entries are part of the loader and are not needed in the split image. The bootloader accesses these
+entries at the beginning of the image slot (first 2 words). For example:
```
.text :
@@ -224,10 +274,15 @@ The split linker must define the first two words in the vector table (initial SP
__split_isr_vector_start = .;
KEEP(*(.isr_vector_split))
__split_isr_vector_end = .;
- ...
+ ...
+ }
```
-The split linker must ensure that it doesn't overwrite the BSS and DATA sections of the loader (they are both using RAM). Note, the two apps don't run at the same time, but the loader has global data that its libraries use. This cannot be overwritten by the application. An example linker section that accomplishes this can be found in `/hw/bsp/nrf52dk/split-nrf52dk.ld`. When linking against the loader, the loader exports the following symbosl which can be used by the split app code:
+The split linker must ensure that it doesn't overwrite the BSS and DATA sections of the loader (they are
+both using RAM). Note, the two apps don't run at the same time, but the loader has global data that its
+libraries use. This cannot be overwritten by the application. An example linker section that accomplishes
+this can be found in `/hw/bsp/nrf52dk/split-nrf52dk.ld`. When linking against the loader, the loader exports
+the following symbosl which can be used by the split app code:
* `__HeapBase_loader`
* `__bss_start___loader`
@@ -238,7 +293,7 @@ The split linker must ensure that it doesn't overwrite the BSS and DATA sections
The split app linker can use `__HeapBase_loader` to skip RAM used by the loader as follows.
-```
+```c
/* save RAM used by the split image. This assumes that
* the loader uses all the RAM up to its HeapBase */
.loader_ram_contents :
@@ -253,36 +308,44 @@ The split app linker can use `__HeapBase_loader` to skip RAM used by the loader
### split image startup code
-The split application needs separate startup code to intialize the split image before running main. THe split image is specially linked so that _start and main are included individually for the loader and split app.
+The split application needs separate startup code to intialize the split image before running main. The
+split image is specially linked so that `_start` and `main` are included individually for the loader and split app.
The split app startup code must have the following.
1. A definition of the split image vector table (first two words).
2. The entry point function to start the code `Reset_Handler_split`
-3. Code that copies the .data section for the loader from Flash to RAM
-4. Code that zeros the .bss section for the loader.
-5. Code that calls _sbrkInit to set the heap pointers for the application (see below)
+3. Code that copies the `.data` section for the loader from Flash to RAM
+4. Code that zeros the `.bss` section for the loader.
+5. Code that calls `_sbrkInit` to set the heap pointers for the application (see below)
6. Code that calls the `bsp_slot_init_split_application` function (see below)
An example can be found in the `/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52_split.s`
### Download script
-The download script needs to be modified to include support for passing the image slot number in the build. Image slots are referenced as 0 and 1. Loading bootloaders ignore the image slot numbers.
+The download script needs to be modified to include support for passing the image slot number in the build.
+Image slots are referenced as 0 and 1. Loading bootloaders ignore the image slot numbers.
See and example in `/hw/bsp/bmd300eval/bmd300eval_download.sh`.
### Sbrk functionality
-Split image (either a loader or app) references a single set of heap managment functions. But the heap location and size is different depending which image is running. Special functionality is needed to handle the dynamic setting of the heap base and limit.
+Split image (either a loader or app) references a single set of heap managment functions. But the heap location and
+size is different depending which image is running. Special functionality is needed to handle the dynamic
+setting of the heap base and limit.
-Instead of hard-coding the heap base and limit at link time (depending on the size of data and bss), sbrk needs to be dynamically initialized with these values from the startup code.
+Instead of hard-coding the heap base and limit at link time (depending on the size of data and bss), sbrk
+needs to be dynamically initialized with these values from the startup code.
-See an example in `/hw/bsp/bmd300eval/src/sbrk.c` in the core repository. The function `_sbrkInit` must be called from the startup code of the split image and normal image startup code with the appropriate values of heap base and limit.
+See an example in `/hw/bsp/bmd300eval/src/sbrk.c` in the core repository. The function `_sbrkInit` must be
+called from the startup code of the split image and normal image startup code with the appropriate
+values of heap base and limit.
### Slot Init
-A global variable tells mynewt whether the split image is runnning as just a stand-alone loader, or as the combined loader/app image. Its the responsibility of the startup code to set this global variable.
+A global variable tells Mynewt whether the split image is runnning as just a stand-alone loader, or as
+the combined loader/app image. Its the responsibility of the startup code to set this global variable.
See `hw/bsp/bmd300eval/src/os_bsp.c` for and implementation of the functionality.
@@ -304,15 +367,19 @@ Images:
hash=1697bd1658f7e902e0191094c5f729446c9dd790c00a58e2bb37f56d6fcb72fe
```
-The bootloader is unable to boot split app images (of course it can boot the loader images), so do not use the `boot2` command to instruct mynewt to boot slot 2.
+The bootloader is unable to boot split app images (of course it can boot the loader images), so do not use the `boot2`
+command to instruct mynewt to boot slot 2.
-Instead, use the new `split status` command to see the status of split images and to set their boot status. The split status command with no arguments returns status of the split image. The Split Value tells the loader how to boot the split app. Options are:
+Instead, use the new `split status` command to see the status of split images and to set their boot status.
+The split status command with no arguments returns status of the split image. The Split Value tells the loader
+how to boot the split app. Options are:
* `none` Don't boot the split application. Just remain running in the loader.
* `test` Boot the split application, but revert back to the loader on the next reset.
* `run` Boot the split application.
-The split status command also verified the hash of the split application (using the hash of the loader as shown above) and returns the status of the check (matching or non-matching).
+The split status command also verified the hash of the split application (using the hash of the loader
+as shown above) and returns the status of the check (matching or non-matching).
```
newtmgr -c connection split status
@@ -320,7 +387,8 @@ newtmgr -c connection split status
Split status is matching
```
-When the split image application is running, the active hash in the boot2 command will match the hash of the split application (in slot 2). For example:
+When the split image application is running, the active hash in the `boot2` command will match the
+hash of the split application (in slot 2). For example:
```
prompt$ newtmgr -c foo1 image boot
@@ -333,7 +401,8 @@ prompt$ newtmgr -c foo1 image boot
When running via newt, the `newt load` command will load both parts of a split image, the loader and application.
-When running via newtmgr a sequence of commands is required to upgrade. Assuming you are running the split app in `run` mode the following sequence will upgrade
+When running via newtmgr a sequence of commands is required to upgrade. Assuming you are running the
+split app in `run` mode the following sequence will upgrade
1. newtmgr split status none
2. newtmgr reboot
[14/19] incubator-mynewt-site git commit: Fix broken link for NimBLE
page
Posted by ad...@apache.org.
Fix broken link for NimBLE page
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/f6064b94
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/f6064b94
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/f6064b94
Branch: refs/heads/master
Commit: f6064b94bc3433cacc059d8095042265f50203f8
Parents: a0522bd
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 15:38:43 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 15:38:43 2016 -0800
----------------------------------------------------------------------
custom-theme/landing.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/f6064b94/custom-theme/landing.html
----------------------------------------------------------------------
diff --git a/custom-theme/landing.html b/custom-theme/landing.html
index 2473b84..af58d5b 100644
--- a/custom-theme/landing.html
+++ b/custom-theme/landing.html
@@ -16,7 +16,7 @@
<li> 10x throughput of Nordic Softdevice </li>
<li> 2x as many concurrent connections as Nordic Softdevice </li>
<li> 4x as many active connections in simulatenous central and peripheral roles as Intel Zephyr and Nordic Softdevice </li>
- <li> <a href="/pages/ble/">More on NimBLE...</a> </li>
+ <li> <a href="pages/ble/">More on NimBLE...</a> </li>
</ul>
<li> Additional connectivity options include WiFi </li>
<li> Native support for TCP/IP, UDP </li>
[17/19] incubator-mynewt-site git commit: Fixed security sub-page
link in mkdocs.yml
Posted by ad...@apache.org.
Fixed security sub-page link in mkdocs.yml
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/2c68c2d3
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/2c68c2d3
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/2c68c2d3
Branch: refs/heads/master
Commit: 2c68c2d334d5d54fb42ef2e374392b2538edfa2a
Parents: ff60aac
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 16:03:10 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 16:03:10 2016 -0800
----------------------------------------------------------------------
custom-theme/landing.html | 2 +-
mkdocs.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/2c68c2d3/custom-theme/landing.html
----------------------------------------------------------------------
diff --git a/custom-theme/landing.html b/custom-theme/landing.html
index af58d5b..bd6e862 100644
--- a/custom-theme/landing.html
+++ b/custom-theme/landing.html
@@ -38,7 +38,7 @@
<li>Device identity for secure provisioning </li>
<li>Authenticated, authorized, and encrypted data transfers </li>
<li>Abstracted interface to leverage hardware security </li>
- <li> <a href="/pages/securitybullets/">More on Mynewt OS security...</a> </li>
+ <li> <a href="pages/securitybullets/">More on Mynewt OS security...</a> </li>
</ul>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/2c68c2d3/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index a7fdbee..8370943 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -7,7 +7,7 @@ pages:
- Home: 'index.md'
- Pages:
- Bluetooth Low Energy 4.2: 'pages/ble.md'
- - Newt build and configuration Tool: 'pages/configurability.md'
+ - Security Lifecycle: 'pages/securitybullets.md'
- Quick Start: 'quick-start.md'
- About: 'about.md'
- Talks: 'talks.md'
[04/19] incubator-mynewt-site git commit: moved section on
contributing code to cwiki. A link to the cwiki page is now included. Also
added a link to the wishlist for the project on JIRA
Posted by ad...@apache.org.
moved section on contributing code to cwiki. A link to the cwiki page is now included. Also added a link to the wishlist for the project on JIRA
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/2f682cd9
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/2f682cd9
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/2f682cd9
Branch: refs/heads/master
Commit: 2f682cd9e644ff85bdcc4e069cb356e09b3eddb9
Parents: 5e6aa5b
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 16:30:50 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 16:52:29 2016 -0800
----------------------------------------------------------------------
custom-theme/community.html | 41 +++++++---------------------------------
1 file changed, 7 insertions(+), 34 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/2f682cd9/custom-theme/community.html
----------------------------------------------------------------------
diff --git a/custom-theme/community.html b/custom-theme/community.html
index ac3e094..9fa2da7 100644
--- a/custom-theme/community.html
+++ b/custom-theme/community.html
@@ -48,46 +48,19 @@
<div class="row">
<div class="col-md-12">
- <h3>Contributing</h3>
- <p>
- <font color="#F2853F"> Getting involved is easy! Simply send an email to the dev@ mailing list introducing yourself, and the people in the community can help you get familiar with Apache Mynewt OS. </font> </p>
- <p>
- If you are already settled in and wish to contribute code, read on ahead. This project strives to adhere to Apache's proposed workflow as explained <a href="https://git-wip-us.apache.org/docs/workflow.html">here</a>. Basically, you submit your initial edits for your peers to review and merge. After a few successful patches under your belt, you will get access to commit code directly to the module you are working on in the repository. And over time, you will get full access to all the repositories, where you can commit code to any module on the apache git repository (and not the github mirror). </p>
- <p>The diagram below explains the recommended process for submitting code to the core repository of Apache Mynewt. The "develop" branch on Mynewt's repository contains the most recent changes made by the community of developers. Contributions from you need to go into this branch. The essential steps are the following: </p>
- <ol>
- <li> Fork the Mynewt repository to create your very own repo on github. </li>
- <li> Clone the Mynewt repository on your machine using the Newt tool. Set up the remotes correctly as shown in the diagram. This is key to making sure you correctly pull the latest code from Mynewt's "develop" and push to your working branch on github. </li>
- <li> Make your code changes and commit them locally. </li>
- <li> Always sync up with the latest code in the "develop" branch and resolve any merge conflicts. </li>
- <li> Push your commits to your working branch on github.
- <li> Submit a pull request to the `develop` branch of the appropriate Apache Mynewt repository by clicking the green "New pull request" button on your github fork page. </li>
- </ol>
+ <h3>Getting involved</h3>
- <br>
+ <p> It is easy! Simply send an email to the dev@ mailing list introducing yourself and the Apache Mynewt community will welcome you. If you have questions, sending an email to this list is the fastest way of getting an answer. </p>
- <object data="/img/mynewt_dev_cycle.pdf" type="application/pdf" width=900 height=750>
- <p><b>Example fallback content</b>: This browser does not support PDFs. Please download the PDF to view it: <a href="/img/mynewt_dev_cycle.pdf"> Download PDF </a>.</p>
- </object>
+ <p> If you want to browse the code, <a href="https://github.com/apache/incubator-mynewt-core/tree/develop">Mynewt Core Repo</a> is the best place to start.
- <br>
-
- <p> Remember there are three repositories to work with in the Apache Mynewt project. All of them have a "develop" branch which contains the latest code. The code from "develop" is merged periodically into "master" on all these repositories and releases are then tagged off the "master" branch.
- <ul>
- <li><a href="https://github.com/apache/incubator-mynewt-core">Apache Mynewt core repo mirrored on github</a></li>
- <li><a href="https://github.com/apache/incubator-mynewt-newt">Apache Mynewt newt tool repo mirrored on github</a></li>
- <li><a href="https://github.com/apache/incubator-mynewt-site">Apache Mynewt documentation repo mirrored on github</a></li>
- </ul>
- <br>
- <p> <mark>The bottomline is to work with the "develop" branch. </mark> It has the latest code and you want your changes tested, working, and merged with that codebase. In the comment for the pull request, include a description of the changes you have made and why. Github will automatically notify everyone on the commits@mynewt.incubator.apache.org mailing list about the newly opened pull requests. You can open a pull request even if you don't think the code is ready for merging but want some discussion on the matter. </p>
- <p> <mark>There is no need to open a new pull request if you have already submitted a pull request against the "develop" branch on the mirror but have modified your code futher </mark>(e.g. after some feedback from the community or another clever idea popping into your head). The old pull request will get updated with your changes.</p>
- <p> Upon receiving notification, one or more committers will review your work, ask for edits or clarifications, and merge when your proposed changes are ready.</p>
-
- </p>
- <p> To know more check out the FAQ in Appendix under <a href="https://mynewt.apache.org/faq/answers/">Documentation.</a></p>
- <br>
+ <p> If you wish to contribute code, a quick look at the <a href="https://cwiki.apache.org/confluence/display/MYNEWT/Contributing+to+Apache+Mynewt"> recommended steps </a> should help.
<h3>Bug Submission and Issue Tracking</h3>
<p>Issues, features, improvements, and wish-lists are tracked using <a href="https://issues.apache.org/jira/browse/Mynewt/">ASF JIRA</a>, the Atlassian JIRA software on Apache Software Foundation </p>
+ <li>
+ <p><a href="https://issues.apache.org/jira/issues/?jql=project%20%3D%20MYNEWT%20AND%20fixVersion%20%3D%20WISHLIST%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC">Click here to see WISHLIST for Mynewt</a></p>
+ </li>
<li>
Sign up for an account on JIRA and submit a request to the dev@ mailing list for your JIRA username to be added to the Apache Mynewt (MYNEWT) project. Editing a ticket requires an account.
</li>
[12/19] incubator-mynewt-site git commit: configured develop version
to show up as latest documentation
Posted by ad...@apache.org.
configured develop version to show up as latest 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/52f0a27a
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/52f0a27a
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/52f0a27a
Branch: refs/heads/master
Commit: 52f0a27ad1568dc4c3654635ad82e0a904a3dfda
Parents: ff0b4d0
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 17:19:02 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 17:19:02 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/52f0a27a/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 9a31988..60d1201 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -379,10 +379,10 @@ extra:
versions:
- label: 'develop'
branch: 'develop'
- latest: False
+ latest: True
- label: '0.9.0'
branch: 'v0_9_0'
- latest: True
+ latest: False
doc_path: 'os/introduction'
chapters:
Chapter 1 - Get Started: 'The chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.'
[09/19] incubator-mynewt-site git commit: configured develop version
to show up as latest documentation
Posted by ad...@apache.org.
configured develop version to show up as latest 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/d0b69c55
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/d0b69c55
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/d0b69c55
Branch: refs/heads/master
Commit: d0b69c5565e11a3dd00ccf5e6f5f46f83fd51580
Parents: 9f22ee5
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 17:04:26 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 17:04:26 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/d0b69c55/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 1626812..9a31988 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -375,14 +375,14 @@ markdown_extensions:
pygments_style: xcode
extra:
- version: 'develop'
+ version: 'v0_9_0'
versions:
- label: 'develop'
branch: 'develop'
- latest: True
+ latest: False
- label: '0.9.0'
branch: 'v0_9_0'
- latest: False
+ latest: True
doc_path: 'os/introduction'
chapters:
Chapter 1 - Get Started: 'The chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.'
[08/19] incubator-mynewt-site git commit: configured develop version
to show up as latest documentation
Posted by ad...@apache.org.
configured develop version to show up as latest 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/9f22ee57
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/9f22ee57
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/9f22ee57
Branch: refs/heads/master
Commit: 9f22ee5773d697c6d375dd7f3e586d95eab129ee
Parents: 3290244
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 17:02:35 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 17:02:35 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9f22ee57/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 9a31988..1626812 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -375,14 +375,14 @@ markdown_extensions:
pygments_style: xcode
extra:
- version: 'v0_9_0'
+ version: 'develop'
versions:
- label: 'develop'
branch: 'develop'
- latest: False
+ latest: True
- label: '0.9.0'
branch: 'v0_9_0'
- latest: True
+ latest: False
doc_path: 'os/introduction'
chapters:
Chapter 1 - Get Started: 'The chapter organization is outlined below. Each chapter will include one or more tutorials for hands-on experience with the material in each chapter.'
[15/19] incubator-mynewt-site git commit: Fixed mkdocs.yml to add
back the subpages and talks
Posted by ad...@apache.org.
Fixed mkdocs.yml to add back the subpages and talks
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/ad43e928
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/ad43e928
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/ad43e928
Branch: refs/heads/master
Commit: ad43e928af3c1d66d430d0c60d208dfce4801d77
Parents: f6064b9
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 15:47:37 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 15:47:37 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 4 ++++
1 file changed, 4 insertions(+)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ad43e928/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 2c46b94..f257fb1 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -5,8 +5,12 @@ theme_dir: 'custom-theme'
pages:
- Home: 'index.md'
+- Pages:
+ - Bluetooth Low Energy 4.2: 'pages/ble.md'
+ - Newt build and configuration Tool: 'pages/securitybullets.md'
- Quick Start: 'quick-start.md'
- About: 'about.md'
+- Talks: 'talks.md'
- Download: 'download.md'
- Community: 'community.md'
- Events: 'events.md'