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:12:02 UTC
[01/21] incubator-mynewt-site git commit: Updated tutorials.
Repository: incubator-mynewt-site
Updated Branches:
refs/heads/develop 5de32ba19 -> 38b20a681
Updated tutorials.
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/cc3415ea
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/cc3415ea
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/cc3415ea
Branch: refs/heads/develop
Commit: cc3415ea8f8e5ed0725745b10865f36ae43ed9ec
Parents: bc45bd4
Author: David G. Simmons <sa...@mac.com>
Authored: Thu Oct 20 16:07:35 2016 -0400
Committer: David G. Simmons <sa...@mac.com>
Committed: Thu Oct 20 16:07:35 2016 -0400
----------------------------------------------------------------------
docs/os/tutorials/STM32F303.md | 6 ++++--
docs/os/tutorials/nRF52.md | 16 +++++++---------
2 files changed, 11 insertions(+), 11 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/cc3415ea/docs/os/tutorials/STM32F303.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/STM32F303.md b/docs/os/tutorials/STM32F303.md
index 00ab024..695af1c 100644
--- a/docs/os/tutorials/STM32F303.md
+++ b/docs/os/tutorials/STM32F303.md
@@ -96,14 +96,14 @@ Now you can install this into the project using:
$ newt install -v
Downloading repository description for apache-mynewt-core... success!
...
-apache-mynewt-core successfully installed version 0.7.9-none
+apache-mynewt-core successfully installed version 0.9.1-none
...
Downloading repository description for mynewt_stm32f3... success!
Downloading repository mynewt_stm32f3
...
Resolving deltas: 100% (65/65), done.
Checking connectivity... done.
-mynewt_stm32f3 successfully installed version 0.0.0-none
+mynewt_stm32f3 successfully installed version 0.9.0-none
```
<br>
@@ -183,6 +183,8 @@ Build manifest:~/dev/myproj/bin/stmf3_blinky/apps/blinky/manifest.json
The STM32F3DISCOVERY board includes an ST-LINK/V2 embedded debug tool interface that will be used to program/debug the board. To program the MCU on the board, simply plug in the two jumpers on CN4, as shown in the picture in red. If you want to learn more about the board you will find the User Manual at [http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf](http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00063382.pdf)
+
+ Just plug the USB cable into the ```USB ST-LINK``` port and it should power on and be ready to dowload to.
* 
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/cc3415ea/docs/os/tutorials/nRF52.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/nRF52.md b/docs/os/tutorials/nRF52.md
index 15e5171..469bd6e 100644
--- a/docs/os/tutorials/nRF52.md
+++ b/docs/os/tutorials/nRF52.md
@@ -15,7 +15,6 @@ Note that there are several versions of the nRF52 in the market. The boards test
### Hardware needed
* nRF52 Development Kit (one of the following)
- * Preview Kit from Nordic - PCA 10036
* Dev Kit from Nordic - PCA 10040
* Eval Kit from Rigado - BMD-300-EVAL-ES
* Laptop running Mac OS
@@ -50,7 +49,7 @@ or just follow the commands below.
apache-mynewt-core
Downloading repository description for apache-mynewt-core... success!
...
- apache-mynewt-core successfully installed version 0.7.9-none
+ apache-mynewt-core successfully installed version 0.9.0-none
```
<br>
@@ -62,7 +61,6 @@ Create two targets - one for the bootloader and one for the nrf52 board.
<font color="#F2853F">
Note: The correct bsp must be chosen for the board you are using. </font>
-* For the Nordic Preview Dev Kit choose @apache-mynewt-core/hw/bsp/nrf52pdk (as shown below)
* For the Nordic Dev Kit choose @apache-mynewt-core/hw/bsp/nrf52dk instead (in the highlighted lines)
* For the Rigado Eval Kit choose @apache-mynewt-core/hw/bsp/bmd300eval instead (in the highlighted lines)
@@ -70,22 +68,22 @@ Note: The correct bsp must be chosen for the board you are using. </font>
```hl_lines="3 8"
$ newt target create blink_nordic
$ newt target set blink_nordic app=apps/blinky
-$ newt target set blink_nordic bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
+$ newt target set blink_nordic bsp=@apache-mynewt-core/hw/bsp/nrf52dk
$ newt target set blink_nordic build_profile=debug
$ newt target create nrf52_boot
$ newt target set nrf52_boot app=@apache-mynewt-core/apps/boot
-$ newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
+$ newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52dk
$ newt target set nrf52_boot build_profile=optimized
$ newt target show
targets/blink_nordic
app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52dk
build_profile=debug
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52dk
build_profile=optimized
```
@@ -96,8 +94,8 @@ targets/nrf52_boot
```
$ newt build nrf52_boot
...
-Compiling log_shell.c
-Archiving log.a
+Compiling boot.c
+Archiving boot.a
Linking boot.elf
App successfully built: ~/dev/myproj/bin/nrf52_boot/apps/boot/boot.elf
```
[19/21] 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/b665dc74
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/b665dc74
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/b665dc74
Branch: refs/heads/develop
Commit: b665dc741fc3e323801f580380288cb643680229
Parents: c4f4b18
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 17:20:07 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 17:20:07 2016 -0800
----------------------------------------------------------------------
mkdocs.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/b665dc74/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index ab7dbab..8b22dc4 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -506,10 +506,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/21] incubator-mynewt-site git commit: New Bootloader Doc
Posted by ad...@apache.org.
New Bootloader Doc
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/9aff0aef
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/9aff0aef
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/9aff0aef
Branch: refs/heads/develop
Commit: 9aff0aef9a3a70221e09c57a76ef8f857773957e
Parents: 7970734
Author: David G. Simmons <sa...@mac.com>
Authored: Fri Nov 4 11:11:49 2016 -0400
Committer: David G. Simmons <sa...@mac.com>
Committed: Fri Nov 4 11:11:49 2016 -0400
----------------------------------------------------------------------
docs/os/modules/bootloader/bootloader.md | 373 +++++++++++++++++++++++++-
1 file changed, 368 insertions(+), 5 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9aff0aef/docs/os/modules/bootloader/bootloader.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/bootloader.md b/docs/os/modules/bootloader/bootloader.md
index 55b6d44..6841875 100644
--- a/docs/os/modules/bootloader/bootloader.md
+++ b/docs/os/modules/bootloader/bootloader.md
@@ -1,15 +1,378 @@
#Bootloader
-Insert synopsis here
+The bootutil library performs most of the functions of a boot loader. In
+particular, the piece that is missing is the final step of actually jumping to
+the main image. This last step should instead be implemented in an
+architecture-specific project. Boot loader functionality is separated in this
+manner for the following two reasons:
+1. By keeping architecture-dependent code separate, the bootutil library can be
+ reused among several boot loaders.
+2. By excluding the last boot step from the library, the rest of the code can
+ be tested in a sim environment.
-###Description
+There is a boot loader project specific to the olimex_stm32-e407 devboard
+called *boot*. This project provides an example of how the bootutil library
+should be used.
-Describe module here, special features, how pieces fit together etc.
+###Limitations
-###Data structures
+The boot loader currently only supports images with the following
+characteristics:
-Replace this with the list of data structures used, why, any neat features
+* Built to run from flash.
+* Build to run from a fixed location (i.e., position-independent).
+
+These limitations will likely be addressed soon.
+
+
+###Image Format
+
+The following definitions describe the image header format.
+
+```c
+#define IMAGE_MAGIC 0x96f3b83c
+
+struct image_version {
+ uint8_t iv_major;
+ uint8_t iv_minor;
+ uint16_t iv_revision;
+ uint32_t iv_build_num;
+};
+
+/** Image header. All fields are in little endian byte order. */
+struct image_header {
+ uint32_t ih_magic;
+ uint32_t ih_crc32; /* Covers remainder of header and all of image body. */
+ uint32_t ih_hdr_size;
+ uint32_t ih_img_size; /* Does not include header. */
+ uint32_t ih_flags;
+ struct image_version ih_ver;
+};
+```
+
+At this time, no flags have been defined.
+
+The `ih_hdr_size` field indicates the length of the header, and therefore the
+offset of the image itself. This field provides for backwards compatibility in
+case of changes to the format of the image header.
+
+When security is added, security data will likely go in a footer at the end of
+the image.
+
+
+###Flash Areas
+
+Bootutil uses the same concept of "flash areas" as the nffs file system.
+Briefly, an area is a region of disk with the following properties:
+1. An area can be fully erased without affecting any other areas.
+2. A write to one area does not restrict writes to other areas.
+
+The areas used for image data must not be used for anything else. In
+particular, these areas must be kept separate from the nffs file system.
+
+
+###Image Slots
+
+A portion of the flash memory is partitioned into two image slots: a primary
+slot and a secondary slot. The boot loader will only run an image from the
+primary slot, so images must be built such that they can run from that fixed
+location in flash. If the boot loader needs to run the image resident in the
+secondary slot, it must swap the two images in flash prior to booting.
+
+In addition to the two image slots, the boot loader requires a scratch area to
+allow for reliable image swapping.
+
+All areas used by image data (including the scratch area) must be the same
+size.
+
+
+###Boot Vector
+
+Bootutil determines which image it should boot into by reading the contents of
+the boot vector. The boot vector comprises the following files in the flash
+file system:
+
+```c
+#define BOOT_PATH_MAIN "/boot/main"
+#define BOOT_PATH_TEST "/boot/test"
+```
+
+Each file, if present, must contain a 64-bit image version. This version is
+simply a "binary dump" of an `image_version` struct. The test file is used to
+indicate that an image is being "tested out," and should only be booted once.
+The main file indicates the "last known good" image which should be booted
+repeatedly.
+
+The boot loader uses the following procedure to determine which image to boot:
+
+1. If the test file is present and contains a valid image version:
+ * Delete the test file.
+ * Boot into the specified image.
+2. Else if the main file is present and contains a valid image version:
+ * Boot into the specified image.
+3. Else:
+ * Just boot into whichever image is in the primary slot. If there is no
+image in the primary slot, boot into the image in the secondary slot.
+
+If a vector file contains a version which doesn't correspond to an image
+actually present in flash, the boot loader deletes the file and procedes as
+though the file was not present.
+
+
+###Boot Status
+
+The boot status file allows the boot loader to recover in case it was reset
+while in the middle of an image swap operation. Image swapping is discussed
+later in this document; the structure of the boot status file is presented
+here. To ensure recovery is always possible, bootutil updates the status file
+at each step throughout the image swap process. The boot status is contained
+in the following file:
+
+```c
+#define BOOT_PATH_STATUS "/boot/status"
+```
+
+The contents of the boot status file are defined below.
+
+```c
+struct boot_status {
+ uint32_t bs_img1_length;
+ uint32_t bs_img2_length;
+ /* Followed by sequence of boot status entries; file size indicates number
+ * of entries.
+ */
+};
+
+struct boot_status_entry {
+ uint8_t bse_image_num;
+ uint8_t bse_part_num;
+};
+
+#define BOOT_IMAGE_NUM_NONE 0xff
+```
+
+There is a separate boot status entry for each flash area used by the boot
+loader (i.e., each area in the two slots, plus one for the scratch area). The
+entries are placed in the file in the same order as their corresponding areas
+in flash. Each entry indicates which image part is resident in the
+corresponding flash area. If a flash area does not contain any image data, its
+corresponding entry will have a `bse_image_num` value of `BOOT_IMAGE_NUM_NONE`.
+
+Consider the following example:
+
+Five flash areas are dedicated to image data, as follows:
+
+| Area | Slot | Value |
+|------|------|-------|
+| Area 0 | slot 0 | 0/1 |
+| Area 1 | slot 0 | 1/1 |
+| Area 2 | slot 1 | 0/1 |
+| Area 3 | slot 1 | 1/1 |
+| Area 4 | scratch ||
+
+The following array of boot status entries is read from the status file:
+
+```c
+ [0] = {
+ .bse_image_num = 0,
+ .bse_part_num = 0,
+ },
+ [1] = {
+ .bse_image_num = 0,
+ .bse_part_num = 1,
+ },
+ [2] = {
+ .bse_image_num = 1,
+ .bse_part_num = 0,
+ },
+ [3] = {
+ .bse_image_num = 1,
+ .bse_part_num = 1,
+ },
+ [4] = {
+ .bse_image_num = 0xff,
+ .bse_part_num = 0xff,
+ },
+```
+
+This status file indicates the following image placement:
+
+| Area | Image | Part |
+|------|------|-------|
+| Area 0 | image 0 | part 0 |
+| Area 1 | image 0 | part 1 |
+| Area 2 | image 1 | part 0 |
+| Area 3 | image 1 | part 1 |
+| Scratch area | empty ||
+
+Images don't have an instrinsic image number. When a swap operation is
+started, the image initially in the primary slot is labelled `image 0`, and the
+image in the secondary slot is labelled `image 1`. All swap operations end with
+`image 1` in the primary slot, and `image 0` in the secondary slot.
+
+The boot status header containing the image sizes is necessary so that `bootutil`
+can determine how many flash areas each image occupies. Without this
+information, `bootutil` would need to swap the full contents of the image slots,
+including useless data after the end of each image.
+
+The status file is always deleted upon successful boot.
+
+
+###Image Swapping
+
+If the boot vector indicates that the image in the secondary slot should be
+run, the boot loader needs to copy it to the primary slot. The image currently
+in the primary slot also needs to be retained in flash so that it can be used
+later. Furthermore, both images need to be recoverable if the boot loader
+resets in the middle of the process. The two images are swapped according to
+the following procedure:
+
+1. Determine how many flash areas are required to hold the desired image.
+2. For each required area in the primary slot ("destination area"):
+ a. Identify the flash area in the secondary slot which contains the
+ required image data ("source area").
+ b. Erase scratch area.
+ c. Copy destination area to scratch area.
+ d. Write updated boot status to the file system.
+ e. Erase destination area.
+ f. Copy source area to destination area.
+ g. Write updated boot status to the file system.
+ h. Erase source area.
+ i. Copy scratch area to source area.
+ j. Write updated boot status to the file system.
+3. Determine how many flash areas are required to hold image 1.
+4. For each required area in the secondary slot ("destination area"):
+ a. If the destination area already contains the required image data,
+ advance to the next image part.
+ b. Else, identify the flash area in the primary slot which contains the
+ required image data ("source area").
+ c. Repeat steps b through j from step 2.
+
+This procedure ensures that the contents of the boot status file are always
+accurate, so the boot loader can recover after an unexpected reset.
+
+Step 4 is necessary in case the two images do not occupy the same number of
+flash areas.
+
+
+###Reset Recovery
+
+If the boot loader resets in the middle of a swap operation, the two images may
+be discontiguous in flash. Bootutil recovers from this condition by using the
+boot status file to determine how the image parts are placed in flash.
+
+If the boot status file indicates that the images are not contiguous, bootutil
+completes the swap operation that was in progress when the system was reset.
+In other words, it applies the procedure defined in the previous section,
+moving image 1 into slot 0 and image 0 into slot 1. If the boot status file
+indicates that an image part is present in the scratch area, this part is
+copied into the correct location by starting at step e or step h in the
+area-swap procedure, depending on whether the part belongs to image 0 or image
+1.
+
+After the swap operation has been completed, the boot loader proceeds as though
+it had just been started.
+
+
+###API
+
+The API consists of a single function:
+
+```c
+int boot_go(const struct boot_req *req, struct boot_rsp *rsp)
+```
+
+The request and response structures are defined as follows:
+
+```c
+struct boot_req {
+
+ struct nffs_area_desc *br_area_descs;
+
+ uint8_t *br_image_areas;
+
+ uint8_t *br_slot_areas;
+
+ uint8_t br_num_image_areas;
+
+
+ uint8_t br_scratch_area_idx;
+};
+```
+
+```c
+struct boot_rsp {
+ const struct image_header *br_hdr;
+
+ uint32_t br_image_addr;
+};
+```
+
+###Example
+
+In this example, each image slot consists of three flash areas.
+
+```c
+/** Internal flash layout. */
+static struct nffs_area_desc boot_area_descs[] = {
+ [0] = { 0x08000000, 16 * 1024 },
+ [1] = { 0x08004000, 16 * 1024 },
+ [2] = { 0x08008000, 16 * 1024 },
+ [3] = { 0x0800c000, 16 * 1024 },
+ [4] = { 0x08010000, 64 * 1024 },
+ [5] = { 0x08020000, 128 * 1024 }, /* Image data; 0,0. */
+ [6] = { 0x08040000, 128 * 1024 }, /* Image data; 0,1. */
+ [7] = { 0x08060000, 128 * 1024 }, /* Image data; 0,2. */
+ [8] = { 0x08080000, 128 * 1024 }, /* Image data; 1,0. */
+ [9] = { 0x080a0000, 128 * 1024 }, /* Image data; 1,1. */
+ [10] = { 0x080c0000, 128 * 1024 }, /* Image data; 1,2. */
+ [11] = { 0x080e0000, 128 * 1024 }, /* Image scratch area. */
+ { 0, 0 },
+};
+
+/** Contains indices of the areas which can contain image data. */
+static uint8_t boot_img_areas[] = {
+ 5, 6, 7, 8, 9, 10, 11,
+};
+
+/** Areas representing the beginning of image slots. */
+static uint8_t boot_slot_areas[] = {
+ 5, 8,
+};
+
+#define BOOT_NUM_IMG_AREAS \
+ ((int)(sizeof boot_img_areas / sizeof boot_img_areas[0]))
+
+/** The scratch area to use during an image swap operation. */
+#define BOOT_AREA_IDX_SCRATCH 11
+
+int
+main(void)
+{
+ struct boot_rsp rsp;
+ int rc;
+
+ const struct boot_req req = {
+ .br_area_descs = boot_area_descs,
+ .br_image_areas = boot_img_areas,
+ .br_slot_areas = boot_slot_areas,
+ .br_num_image_areas = BOOT_NUM_IMG_AREAS,
+ .br_scratch_area_idx = BOOT_AREA_IDX_SCRATCH,
+ };
+
+ rc = boot_go(&req, &rsp);
+ assert(rc == 0);
+
+ /* Perform jump to address indicated by the response object. */
+
+ return 0;
+}
+```
+
+###Dependencies
+* `nffs` (for the boot vector and boot status files).
+* `os` (for `os_malloc()` and `os_free()`).
###List of Functions
[03/21] incubator-mynewt-site git commit: Tidy up list of steps in
editing FAQ
Posted by ad...@apache.org.
Tidy up list of steps in editing FAQ
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/05083e74
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/05083e74
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/05083e74
Branch: refs/heads/develop
Commit: 05083e74a7e2a478a3af27c6694c7dc360a7c4aa
Parents: 4cab025
Author: Sam Bristow <sa...@gmail.com>
Authored: Thu Oct 27 13:30:02 2016 +1300
Committer: GitHub <no...@github.com>
Committed: Thu Oct 27 13:30:02 2016 +1300
----------------------------------------------------------------------
docs/faq/how_to_edit_docs.md | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/05083e74/docs/faq/how_to_edit_docs.md
----------------------------------------------------------------------
diff --git a/docs/faq/how_to_edit_docs.md b/docs/faq/how_to_edit_docs.md
index b3229c6..9005330 100644
--- a/docs/faq/how_to_edit_docs.md
+++ b/docs/faq/how_to_edit_docs.md
@@ -19,9 +19,8 @@ If you are not a committer, you may follow the proposed non-committer workflow t
### Editing an existing page
-* Create a fork on the [github mirror](https://github.com/apache/incubator-mynewt-site).
-*
-* Then create a new branch to work on your documentation and move to that branch.
+* Create a fork on the [github mirror](https://github.com/apache/incubator-mynewt-site).
+* Create a new branch to work on your documentation and move to that branch.
```
$ git checkout -b <your-branch-name>
```
[04/21] incubator-mynewt-site git commit: Updated for beta,
new tutorial doc
Posted by ad...@apache.org.
Updated for beta, new tutorial doc
Added a tutorial doc for BLE Peripheral, complete with pictures.
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/31d56312
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/31d56312
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/31d56312
Branch: refs/heads/develop
Commit: 31d56312a83944fb50c7195f9aedb69dd64938b0
Parents: cc3415e
Author: David G. Simmons <sa...@mac.com>
Authored: Thu Oct 27 12:48:05 2016 -0400
Committer: David G. Simmons <sa...@mac.com>
Committed: Thu Oct 27 12:48:05 2016 -0400
----------------------------------------------------------------------
docs/os/tutorials/bleprph/bleprph-app.md | 110 ++++++++++++++++++++++++++
docs/os/tutorials/bletiny_project.md | 83 +++++++++++--------
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
mkdocs.yml | 3 +-
9 files changed, 160 insertions(+), 36 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/31d56312/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..a0a51c1
--- /dev/null
+++ b/docs/os/tutorials/bleprph/bleprph-app.md
@@ -0,0 +1,110 @@
+## 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 target set myperiph cflags=-DSTATS_NAME_ENABLE
+Target targets/myperiph successfully set pkg.cflags to -DSTATS_NAME_ENABLE
+$ newt build blerph
+Building target targets/myperiph
+...
+Linking /Users/dsimmons/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: /Users/dsimmons/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/31d56312/docs/os/tutorials/bletiny_project.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bletiny_project.md b/docs/os/tutorials/bletiny_project.md
index 495a8b3..51f4594 100644
--- a/docs/os/tutorials/bletiny_project.md
+++ b/docs/os/tutorials/bletiny_project.md
@@ -59,11 +59,15 @@ targets/nrf52_boot
<br>
-Define the targets further. Note that you are using the example app `bletiny` for the application target. Set the bsp correctly (nrf52pdk or nrf52dk depending on whether the board is the preview kit or the dev kit, respectively. Look on the top of your board, if you see PCA100040, use the nrf52dk version, otherwide use the nrf52pdk version).
+Define the targets further. Note that you are using the example app `bletiny` for the application target. Set the bsp
+
+**NOTE:** The preview version, nrf52pdk, is no longer supported. If you do not see PCA100040 on the top of your board, you have a preview version of the board and will need to upgrade your developer board before continuing.
+
+<br>
```
-$ newt target set myble bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
-Target targets/myble successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52pdk
+$ newt target set myble bsp=@apache-mynewt-core/hw/bsp/nrf52dk
+Target targets/myble successfully set target.bsp to @apache-mynewt-core/hw/bsp/nrf52dk
$ newt target set myble app=@apache-mynewt-core/apps/bletiny
Target targets/myble successfully set target.app to @apache-mynewt-core/apps/bletiny
$ newt target set myble build_profile=optimized
@@ -77,7 +81,7 @@ Use the same `newt target set` command to set the following definition for the b
```
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52dk
build_profile=optimized
```
@@ -91,12 +95,12 @@ targets/my_blinky_sim
build_profile=debug
targets/myble
app=@apache-mynewt-core/apps/bletiny
- bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52dk
build_profile=optimized
cflags=-DSTATS_NAME_ENABLE
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52dk
build_profile=optimized
```
@@ -170,26 +174,38 @@ Port /dev/tty.usbserial-AJ03HAQQ, 09:57:17
Press Meta-Z for help on special keys
?
-4828455:log echo ? tasks mempools date
-4828457:stat b
+4754:Commands:
+4754: echo ? prompt tasks mempools date
+4756: b
```
<br>
-Try the `stat` command.
+If you'd like a shell prompt, try the `prompt` command.
+```hl_lines="1"
+prompt
+14025:Usage: prompt [set|show] [prompt_char]
+prompt set >
+15086:Prompt set to: >
+15086:Usage: prompt [set|show] [prompt_char]
+15087: >
+```
+
+You'll notice that there is an ever-increasing counter before the prompt (and before any output to the terminal).
+This is just a counter kept by the MCU.
+
+<br>
+
+Try the `tasks` command.
```hl_lines="1"
-stat
-4973017:Must specify a statistic name to dump, possible names are:
-4973021: stat
-4973022: ble_l2cap
-4973024: ble_att
-4973026: ble_gap
-4973027: ble_gattc
-4973029: ble_gatts
-4973031: ble_hs
-4973032: ble_ll_conn
-4973034: ble_ll
+27365: > tasks
+Tasks:
+28330: idle (prio: 255, tid: 0, lcheck: 0, ncheck: 0, flags: 0x0, ssize: 64, susage: 34, cswcnt: 233, tot_run_time: 28330ms)
+28333: ble_ll (prio: 0, tid: 1, lcheck: 0, ncheck: 0, flags: 0x0, ssize: 80, susage: 60, cswcnt: 11, tot_run_time: 0ms)
+28336: shell (prio: 1, tid: 2, lcheck: 0, ncheck: 0, flags: 0x0, ssize: 512, susage: 115, cswcnt: 18, tot_run_time: 0ms)
+28339: bletiny (prio: 1, tid: 3, lcheck: 0, ncheck: 0, flags: 0x0, ssize: 512, susage: 138, cswcnt: 456, tot_run_time: 0ms)
+28342: >
```
<br>
@@ -218,21 +234,18 @@ stat ble_ll
For a more exciting output, try scanning your surroundings for BLE adverstisements. The HCI command shown below specifies a scan duration in ms, sets discovery mode to general (as opposed to limited), the filter to no-whitelist, and type of scan to passive. You should see some scan data flying by!
```hl_lines="1"
-b scan dur=10000 disc=gen filt=no_wl type=passive
-
-5301227:[ts=5301227ssb, mod=4 level=1] host_hci_cmd_send: ogf=0x08 ocf=0x0b len=7
-5301233:[ts=5301233ssb, mod=4 level=1] Command Complete: cmd_pkts=1 ogf=0x8 ocf=0xb status=0
-5301241:[ts=5301241ssb, mod=4 level=1] host_hci_cmd_send: ogf=0x08 ocf=0x0c len=2
-5301248:[ts=5301248ssb, mod=4 level=1] Command Complete: cmd_pkts=1 ogf=0x8 ocf=0xc status=0
-GAP procedure initiated: discovery; disc_mode=2 filter_policyLE advertising report. len=38 num=1 evtype=3 addr9
-5301270:[ts=5301270ssb, mod=4 level=1] 02 01 06 03 03 aa fe 12
-5301276:[ts=5301276ssb, mod=4 level=1] 16 aa fe 10 f6 02 67 2e
-5301281:[ts=5301281ssb, mod=4 level=1] 63 6f 2f 62 65 61 63 6f
-5301287:[ts=5301287ssb, mod=4 level=1] 6e 73
-5301291:[ts=5301291ssb, mod=64 level=2] received advertisement; event_type=3 addr_type=1 addr=0xa0:0x0d:0xec:0:
-5301316:[ts=5301316ssb, mod=64 level=2] flags=0x06
-5301321:[ts=5301321ssb, mod=64 level=2] uuids16(complete)=0xfeaa
-5301327:[ts=5301327ssb, mod=64 level=2] svc_data_uuid16=
+139088: > b scan dur=10000 disc=gen filt=no_wl type=passive
+...
+146055:received advertisement; event_type=0 addr_type=1 addr=6b:aa:49:b7:46:e6 length_data=24 rssi=-42 data=0x02:0x01:0x1a:0x14:0xff:0x4c:0x00:0x01:0x00:0x00:0x00:0x00:0x04:0x00:0x00:0x00:0x00:0x00:0x00:0x00:0x00:0x00:0x00:0x00 fields:
+146061: flags=0x1a
+146062: mfg_data=0x4c:0x00:0x01:0x00:0x00:0x00:0x00:0x04:0x00:0x00:0x00:0x00:0x00:0x00:0x00:0x00:0x00:0x00:0x00
+146065:
+146065:received advertisement; event_type=0 addr_type=0 addr=ac:bc:32:ac:4f:e4 length_data=11 rssi=-36 data=0x02:0x01:0x06:0x07:0xff:0x4c:0x00:0x10:0x02:0x0b:0x00 fields:
+146069: flags=0x06
+146070: mfg_data=0x4c:0x00:0x10:0x02:0x0b:0x00
+146071:
+146072:scanning finished
+...
<snip>
```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/31d56312/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/31d56312/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/31d56312/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/31d56312/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/31d56312/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/31d56312/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/31d56312/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index a7dd702..f39ac4c 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -54,6 +54,7 @@ pages:
- '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'
+ - 'BLE Peripheral App' : 'os/tutorials/bleprph/bleprph-app.md'
- 'BLE iBeacon': 'os/tutorials/ibeacon.md'
- 'BLE HCI interface': 'os/tutorials/blehci_project.md'
- OS User Guide:
@@ -497,7 +498,7 @@ markdown_extensions:
pygments_style: xcode
extra:
- version: 'none'
+ version: 'v0_9_0'
versions:
- label: 'develop'
branch: 'develop'
[02/21] incubator-mynewt-site git commit: Add link to the MyNewt
website in editing FAQ
Posted by ad...@apache.org.
Add link to the MyNewt website in editing FAQ
It looks like 'MyNewt' was incorrectly auto-corrected to 'Myself' at some point.
I've fixed the spelling and taken the opportunity to add a link to the website.
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/0712743b
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/0712743b
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/0712743b
Branch: refs/heads/develop
Commit: 0712743b399c5d84dabd9c5be0412eec5f3244d3
Parents: 4cab025
Author: Sam Bristow <sa...@gmail.com>
Authored: Thu Oct 27 13:25:41 2016 +1300
Committer: GitHub <no...@github.com>
Committed: Thu Oct 27 13:25:41 2016 +1300
----------------------------------------------------------------------
docs/faq/how_to_edit_docs.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/0712743b/docs/faq/how_to_edit_docs.md
----------------------------------------------------------------------
diff --git a/docs/faq/how_to_edit_docs.md b/docs/faq/how_to_edit_docs.md
index b3229c6..2c1e209 100644
--- a/docs/faq/how_to_edit_docs.md
+++ b/docs/faq/how_to_edit_docs.md
@@ -51,6 +51,6 @@ You will then run the built-in webserver from the root of the documentation dire
docs images mkdocs.yml
$ mkdocs serve
```
-Then go to [http://127.0.0.1:8000](http://127.0.0.1:8000) to preview your pages and see how they will look on the website. **Remember that the Myself website itself will not be updated.**
+Then go to [http://127.0.0.1:8000](http://127.0.0.1:8000) to preview your pages and see how they will look on the website. **Remember that the [MyNewt website](https://mynewt.apache.org) itself will not be updated.**
For more information on MkDocs go to [http://www.mkdocs.org](http://www.mkdocs.org).
[06/21] incubator-mynewt-site git commit: Normalize OS Core Docs
Posted by ad...@apache.org.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/memory_pool/os_memblock_put.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/os_memblock_put.md b/docs/os/core_os/memory_pool/os_memblock_put.md
index 4aba497..2c834c8 100644
--- a/docs/os/core_os/memory_pool/os_memblock_put.md
+++ b/docs/os/core_os/memory_pool/os_memblock_put.md
@@ -11,14 +11,14 @@ Releases previously allocated element back to the pool.
| Arguments | Description |
|-----------|-------------|
-| mp | Pointer to memory pool from which block was allocated |
-| block_addr | Pointer to element getting freed |
+| `mp` | Pointer to memory pool from which block was allocated |
+| `block_addr` | Pointer to element getting freed |
<br>
#### Returned values
-OS_OK: operation was a success:
-OS_INVALID_PARAM: If either mp or block_addr were NULL, or the block being freed was outside the range of the memory buffer or not on a true block size boundary.
+`OS_OK`: operation was a success:
+`OS_INVALID_PARAM`: If either `mp` or `block_addr` were **NULL**, or the block being freed was outside the range of the memory buffer or not on a true block size boundary.
<br>
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/memory_pool/os_mempool_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/os_mempool_init.md b/docs/os/core_os/memory_pool/os_mempool_init.md
index 809a067..b476b52 100644
--- a/docs/os/core_os/memory_pool/os_mempool_init.md
+++ b/docs/os/core_os/memory_pool/os_mempool_init.md
@@ -4,33 +4,33 @@
os_error_t os_mempool_init(struct os_mempool *mp, int blocks, int block_size, void *membuf, char *name)
```
-Initializes the memory pool. Memory pointed to by *membuf* is divided into *blocks* number of elements of size OS_ALIGN(*block_size*). The *name* is optional, and names the memory pool.
+Initializes the memory pool. Memory pointed to by `membuf` is divided into `blocks` number of elements of size `OS_ALIGN(*block_size*)`. The `name` is optional, and names the memory pool.
-It is assumed that the amount of memory pointed by *membuf* has at least *OS_MEMPOOL_BYTES(blocks, block_size)* number of bytes.
+It is assumed that the amount of memory pointed by `membuf` has at least `OS_MEMPOOL_BYTES(blocks, block_size)` number of bytes.
-*name* is not copied, so caller should make sure that the memory does not get reused.
+`name` is not copied, so caller should make sure that the memory does not get reused.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| mp | Memory pool being initialized |
-| blocks | Number of elements in the pool |
-| block_size | Minimum size of an individual element in pool |
-| membuf | Backing store for the memory pool elements |
-| name | Name of the memory pool |
+| `mp` | Memory pool being initialized |
+| `blocks` | Number of elements in the pool |
+| `block_size` | Minimum size of an individual element in pool |
+| `membuf` | Backing store for the memory pool elements |
+| `name` | Name of the memory pool |
#### Returned values
-OS_OK: operation was successful.
-OS_INVALID_PARAM: invalid parameters. Block count or block size was negative, or membuf or mp was NULL.
-OS_MEM_NOT_ALIGNED: membuf was not aligned on correct byte boundary.
+`OS_OK`: operation was successful.
+`OS_INVALID_PARAM`: invalid parameters. Block count or block size was negative, or `membuf` or `mp` was **NULL**.
+`OS_MEM_NOT_ALIGNED`: `membuf` was not aligned on correct byte boundary.
#### Notes
-Note that os_mempool_init() does not allocate backing storage; *membuf* has to be allocated by the caller.
+Note that `os_mempool_init()` does not allocate backing storage; `membuf` has to be allocated by the caller.
-It's recommended that you use *OS_MEMPOOL_BYTES()* or *OS_MEMPOOL_SIZE()* to figure out how much memory to allocate for the pool.
+It's recommended that you use `OS_MEMPOOL_BYTES()` or `OS_MEMPOOL_SIZE()` to figure out how much memory to allocate for the pool.
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mqueue/mqueue.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mqueue/mqueue.md b/docs/os/core_os/mqueue/mqueue.md
index ac0de39..08a8e5f 100644
--- a/docs/os/core_os/mqueue/mqueue.md
+++ b/docs/os/core_os/mqueue/mqueue.md
@@ -1,14 +1,14 @@
# Mqueue
-Mqueue (Mbuf event queue) is a set of API built on top of the mbuf and event queue code. A typical networking stack operation is to put a packet on a queue and post an event to the task handling that queue. Mqueue was designed to provide a common API so that individual packages would not each have to create similar code.
+Mqueue (Mbuf event queue) is a set of APIs built on top of the mbuf and event queue code. A typical networking stack operation is to put a packet on a queue and post an event to the task handling that queue. Mqueue was designed to provide a common API so that individual packages would not each have to create similar code.
-The mqueue data structure consists of a queue head pointer (a "stailq" queue; a singly linked list with head structure having a pointer to the start and end of the list) and an os event structure. Packets (packet header mbufs) are added to the queue using the *omp_next* pointer in the `os_mbuf_pkthdr` structure of the mbuf. The event is used to post to the task an event of type OS_EVENT_T_MQUEUE_DATA.
+The mqueue data structure consists of a queue head pointer (a "stailq" queue; a singly linked list with head structure having a pointer to the start and end of the list) and an os event structure. Packets (packet header mbufs) are added to the queue using the `omp_next` pointer in the `os_mbuf_pkthdr` structure of the mbuf. The event is used to post to the task an event of type `OS_EVENT_T_MQUEUE_DATA`.
<br>
### Using Mqueue
-The following code sample will demonstrate how to use an mqueue. This is a simple example where packets are put on a "receive queue" and a task processes that "receive queue" by incrementing the total number of packet received and then freeing the packet. Not shown in the code example is a call my_task_rx_data_func. Presumably, some other code will call this API.
+The following code sample will demonstrate how to use an mqueue. This is a simple example where packets are put on a "receive queue" and a task processes that "receive queue" by incrementing the total number of packet received and then freeing the packet. Not shown in the code example is a call `my_task_rx_data_func`. Presumably, some other code will call this API.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mqueue/os_mqueue_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mqueue/os_mqueue_get.md b/docs/os/core_os/mqueue/os_mqueue_get.md
index 14bf963..e54ef8e 100644
--- a/docs/os/core_os/mqueue/os_mqueue_get.md
+++ b/docs/os/core_os/mqueue/os_mqueue_get.md
@@ -4,7 +4,7 @@
struct os_mbuf *os_mqueue_get(struct os_mqueue *mq)
```
-Retrieves a packet off an Mqueue. Returns a pointer to the mbuf at the head of the mbuf chain. NULL if no packets are on the queue.
+Retrieves a packet off an Mqueue. Returns a pointer to the mbuf at the head of the mbuf chain. **NULL** if no packets are on the queue.
<br>
@@ -12,13 +12,13 @@ Retrieves a packet off an Mqueue. Returns a pointer to the mbuf at the head of t
| Arguments | Description |
|-----------|-------------|
-| mq | Pointer to Mqueue structure |
+| `mq` | Pointer to Mqueue structure |
<br>
#### Returned values
-The packet at the head of the queue or NULL if no packets are on the queue.
+The packet at the head of the queue or **NULL** if no packets are on the queue.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mqueue/os_mqueue_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mqueue/os_mqueue_init.md b/docs/os/core_os/mqueue/os_mqueue_init.md
index 725c041..ff0b04f 100644
--- a/docs/os/core_os/mqueue/os_mqueue_init.md
+++ b/docs/os/core_os/mqueue/os_mqueue_init.md
@@ -3,7 +3,7 @@
```c
int os_mqueue_init(struct os_mqueue *mq, void *arg)
```
-Initializes an queue. Sets the event argument in the os event of the mqueue to *arg*. Sets type of event to OS_EVENT_T_MQUEUE_DATA.
+Initializes an queue. Sets the event argument in the os event of the mqueue to `arg`. Sets type of event to `OS_EVENT_T_MQUEUE_DATA`.
<br>
@@ -11,8 +11,8 @@ Initializes an queue. Sets the event argument in the os event of the mqueue to *
| Arguments | Description |
|-----------|-------------|
-| mq | Pointer to a mqueue structure |
-| arg | Event argument |
+| `mq` | Pointer to a mqueue structure |
+| `arg` | Event argument |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mqueue/os_mqueue_put.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mqueue/os_mqueue_put.md b/docs/os/core_os/mqueue/os_mqueue_put.md
index e2e9d54..d5f4b13 100644
--- a/docs/os/core_os/mqueue/os_mqueue_put.md
+++ b/docs/os/core_os/mqueue/os_mqueue_put.md
@@ -4,7 +4,7 @@
int os_mqueue_put(struct os_mqueue *mq, struct os_eventq *evq, struct os_mbuf *m)
```
-Adds a packet (i.e. packet header mbuf) to an mqueue. Post event to *evq*.
+Adds a packet (i.e. packet header mbuf) to an mqueue. Post event to `evq`.
<br>
@@ -12,9 +12,9 @@ Adds a packet (i.e. packet header mbuf) to an mqueue. Post event to *evq*.
| Arguments | Description |
|-----------|-------------|
-| mq | Pointer to mqueue |
-| evq | Pointer to event queue where mqueue event should get posted |
-| m | Pointer to packet header mbuf |
+| `mq` | Pointer to mqueue |
+| `evq` | Pointer to event queue where mqueue event should get posted |
+| `m` | Pointer to packet header mbuf |
<br>
@@ -22,7 +22,7 @@ Adds a packet (i.e. packet header mbuf) to an mqueue. Post event to *evq*.
0: success
-OS_EINVAL: the mbuf is not a packet header mbuf.
+`OS_EINVAL`: the mbuf is not a packet header mbuf.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/msys/msys.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/msys/msys.md b/docs/os/core_os/msys/msys.md
index 6c3b2ca..483fa2b 100644
--- a/docs/os/core_os/msys/msys.md
+++ b/docs/os/core_os/msys/msys.md
@@ -1,10 +1,10 @@
# Msys
-Msys stands for "system mbufs" and is a set of API built on top of the mbuf code. The basic idea behind msys is the following. The developer can create different size mbuf pools and register them with msys. The application then allocates mbufs using the msys API (as opposed to the mbuf API). The msys code will choose the mbuf pool with the smallest mbufs that can accommodate the requested size.
+Msys stands for "system mbufs" and is a set of APIs built on top of the mbuf code. The basic idea behind msys is the following. The developer can create different size mbuf pools and register them with msys. The application then allocates mbufs using the msys API (as opposed to the mbuf API). The msys code will choose the mbuf pool with the smallest mbufs that can accommodate the requested size.
Let us walk through an example where the user registers three mbuf pools with msys: one with 32 byte mbufs, one with 256 and one with 2048. If the user requests an mbuf with 10 bytes, the 32-byte mbuf pool is used. If the request is for 33 bytes the 256 byte mbuf pool is used. If an mbuf data size is requested that is larger than any of the pools (say, 4000 bytes) the largest pool is used. While this behaviour may not be optimal in all cases that is the currently implemented behaviour. All this means is that the user is not guaranteed that a single mbuf can hold the requested data.
-The msys code will not allocate an mbuf from a larger pool if the chosen mbuf pool is empty. Similarly, the msys code will not chain together a number of smaller mbufs to accommodate the requested size. While this behaviour may change in future implementations the current code will simply return NULL. Using the above example, say the user requests 250 bytes. The msys code chooses the appropriate pool (i.e. the 256 byte mbuf pool) and attempts to allocate an mbuf from that pool. If that pool is empty, NULL is returned even though the 32 and 2048 byte pools are not empty.
+The msys code will not allocate an mbuf from a larger pool if the chosen mbuf pool is empty. Similarly, the msys code will not chain together a number of smaller mbufs to accommodate the requested size. While this behaviour may change in future implementations the current code will simply return **NULL**. Using the above example, say the user requests 250 bytes. The msys code chooses the appropriate pool (i.e. the 256 byte mbuf pool) and attempts to allocate an mbuf from that pool. If that pool is empty, **NULL** is returned even though the 32 and 2048 byte pools are not empty.
Note that no added descriptions on how to use the msys API are presented here (other than in the API descriptions themselves) as the msys API is used in exactly the same manner as the mbuf API. The only difference is that mbuf pools are added to msys by calling `os_msys_register().`
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/msys/os_msys_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/msys/os_msys_get.md b/docs/os/core_os/msys/os_msys_get.md
index b69c9a0..188071f 100644
--- a/docs/os/core_os/msys/os_msys_get.md
+++ b/docs/os/core_os/msys/os_msys_get.md
@@ -4,7 +4,7 @@
struct os_mbuf *os_msys_get(uint16_t dsize, uint16_t leadingspace)
```
-Retrieve an mbuf from the system mbuf pools with *leadingspace* bytes available in the mbuf.
+Retrieve an mbuf from the system mbuf pools with `leadingspace` bytes available in the mbuf.
<br>
@@ -12,18 +12,18 @@ Retrieve an mbuf from the system mbuf pools with *leadingspace* bytes available
| Arguments | Description |
|-----------|-------------|
-| dsize | Minimum requested size of mbuf. Actual mbuf allocated may not accommodate *dsize* |
-| leadingspace | Number of bytes for leading space in mbuf (space at start of mbuf) |
+| `dsize` | Minimum requested size of mbuf. Actual mbuf allocated may not accommodate *dsize* |
+| `leadingspace` | Number of bytes for leading space in mbuf (space at start of mbuf) |
<br>
#### Returned values
-Pointer to mbuf or NULL if no mbufs were available.
+Pointer to mbuf or **NULL** if no mbufs were available.
<br>
#### Notes
-As described in the overview section, `os_msys_get()` may return an mbuf that is smaller than dsize, meaning that the mbuf user data buffer does not have enough contiguous space to hold *dsize* bytes.
+As described in the overview section, `os_msys_get()` may return an mbuf that is smaller than `dsize`, meaning that the mbuf user data buffer does not have enough contiguous space to hold `dsize` bytes.
This API will not return an mbuf from a larger mbuf pool if the appropriate msys mbuf pool is empty. See the overview for more information.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/msys/os_msys_get_pkthdr.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/msys/os_msys_get_pkthdr.md b/docs/os/core_os/msys/os_msys_get_pkthdr.md
index 38a5302..cda7b8d 100644
--- a/docs/os/core_os/msys/os_msys_get_pkthdr.md
+++ b/docs/os/core_os/msys/os_msys_get_pkthdr.md
@@ -4,7 +4,7 @@
struct os_mbuf *os_msys_get_pkthdr(uint16_t dsize, uint16_t user_hdr_len)
```
-Retrieve a packet header mbuf from the system mbuf pools with *user_hdr_len* bytes available for the user header in the mbuf.
+Retrieve a packet header mbuf from the system mbuf pools with `user_hdr_len` bytes available for the user header in the mbuf.
<br>
@@ -12,13 +12,13 @@ Retrieve a packet header mbuf from the system mbuf pools with *user_hdr_len* byt
| Arguments | Description |
|-----------|-------------|
-| dsize | Minimum requested size of mbuf. Actual mbuf allocated may not accommodate *dsize* |
-| user_hdr_len | Size, in of bytes, of user header in the mbuf |
+| `dsize` | Minimum requested size of mbuf. Actual mbuf allocated may not accommodate *dsize* |
+| `user_hdr_len` | Size, in of bytes, of user header in the mbuf |
<br>
#### Returned values
-Pointer to mbuf or NULL if no mbufs were available.
+Pointer to mbuf or **NULL** if no mbufs were available.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/msys/os_msys_register.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/msys/os_msys_register.md b/docs/os/core_os/msys/os_msys_register.md
index 4125f22..7335772 100644
--- a/docs/os/core_os/msys/os_msys_register.md
+++ b/docs/os/core_os/msys/os_msys_register.md
@@ -12,7 +12,7 @@ Register an mbuf pool for use as a system mbuf pool. The pool should be initiali
| Arguments | Description |
|-----------|-------------|
-| new_pool | Pointer to mbuf pool to add to system mbuf pools |
+| `new_pool` | Pointer to mbuf pool to add to system mbuf pools |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mutex/mutex.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/mutex.md b/docs/os/core_os/mutex/mutex.md
index 961ebc5..b75f4e2 100644
--- a/docs/os/core_os/mutex/mutex.md
+++ b/docs/os/core_os/mutex/mutex.md
@@ -8,7 +8,7 @@ Mutex is short for "mutual exclusion"; a mutex provides mutually exclusive acces
The first order of business when using a mutex is to declare the mutex globally. The mutex needs to be initialized before it is used (see the examples). It is generally a good idea to initialize the mutex before tasks start running in order to avoid a task possibly using the mutex before it is initialized.
-When a task wants exclusive access to a shared resource it needs to obtain the mutex by calling *os_mutex_pend*. If the mutex is currently owned by a different task (a lower priority task), the requesting task will be put to sleep and the owners priority will be elevated to the priority of the requesting task. Note that multiple tasks can request ownership and the current owner is elevated to the highest priority of any task waitin on the mutex. When the task is done using the shared resource, it needs to release the mutex by called *os_mutex_release*. There needs to be one release per call to pend. Note that nested calls to *os_mutex_pend* are allowed but there needs to be one release per pend.
+When a task wants exclusive access to a shared resource it needs to obtain the mutex by calling `os_mutex_pend`. If the mutex is currently owned by a different task (a lower priority task), the requesting task will be put to sleep and the owners priority will be elevated to the priority of the requesting task. Note that multiple tasks can request ownership and the current owner is elevated to the highest priority of any task waitin on the mutex. When the task is done using the shared resource, it needs to release the mutex by called `os_mutex_release`. There needs to be one release per call to pend. Note that nested calls to `os_mutex_pend` are allowed but there needs to be one release per pend.
The following example will illustrate how priority inheritance works. In this example, the task number is the same as its priority. Remember that the lower the number, the higher the priority (i.e. priority 0 is higher priority than priority 1). Suppose that task 5 gets ownership of a mutex but is preempted by task 4. Task 4 attempts to gain ownership of the mutex but cannot as it is owned by task 5. Task 4 is put to sleep and task 5 is temporarily raised to priority 4. Before task 5 can release the mutex, task 3 runs and attempts to acquire the mutex. At this point, both task 3 and task 4 are waiting on the mutex (sleeping). Task 5 now runs at priority 3 (the highest priority of all the tasks waiting on the mutex). When task 5 finally releases the mutex it will be preempted as two higher priority tasks are waiting for it.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mutex/os_mutex_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/os_mutex_init.md b/docs/os/core_os/mutex/os_mutex_init.md
index 284e225..37d9872 100644
--- a/docs/os/core_os/mutex/os_mutex_init.md
+++ b/docs/os/core_os/mutex/os_mutex_init.md
@@ -10,13 +10,13 @@ Initialize the mutex. Must be called before the mutex can be used.
| Arguments | Description |
|-----------|-------------|
-| *mu| Pointer to mutex |
+| `*mu`| Pointer to mutex |
#### Returned values
-OS_INVALID_PARM: returned when *mu is NULL on entry.
+`OS_INVALID_PARM`: returned when `*mu` is **NULL** on entry.
-OS_OK: mutex initialized successfully.
+`OS_OK`: mutex initialized successfully.
#### Notes
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mutex/os_mutex_pend.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/os_mutex_pend.md b/docs/os/core_os/mutex/os_mutex_pend.md
index 2b3af83..4e1b0f3 100644
--- a/docs/os/core_os/mutex/os_mutex_pend.md
+++ b/docs/os/core_os/mutex/os_mutex_pend.md
@@ -11,23 +11,23 @@ Acquire ownership of a mutex.
| Arguments | Description |
|-----------|-------------|
-| *mu | Pointer to mutex |
-| timeout | Timeout, in os ticks. A value of 0 means no timeout. A value of 0xFFFFFFFF means to wait forever. |
+| `*mu` | Pointer to mutex |
+| `timeout` | Timeout, in os ticks. A value of 0 means no timeout. A value of 0xFFFFFFFF means to wait forever. |
#### Returned values
-OS_INVALID_PARM: returned when *mu is NULL on entry.
+`OS_INVALID_PARM`: returned when `*mu` is **NULL** on entry.
-OS_OK: mutex was successfully acquired.
+`OS_OK`: mutex was successfully acquired.
-OS_TIMEOUT: the mutex was not available within the timeout specified.
+`OS_TIMEOUT`: the mutex was not available within the timeout specified.
-OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
+`OS_NOT_STARTED`: Attempt to release a mutex before the os has been started.
#### Notes
-If the mutex is owned by another task and the timeout is 0 the function returns immediately with the error code OS_TIMEOUT. The calling task *does not* own the mutex when this occurs.
+If the mutex is owned by another task and the timeout is 0 the function returns immediately with the error code `OS_TIMEOUT`. The calling task *does not* own the mutex when this occurs.
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mutex/os_mutex_release.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mutex/os_mutex_release.md b/docs/os/core_os/mutex/os_mutex_release.md
index 356ae49..ba5f294 100644
--- a/docs/os/core_os/mutex/os_mutex_release.md
+++ b/docs/os/core_os/mutex/os_mutex_release.md
@@ -11,16 +11,16 @@ Release ownership of a mutex
| Arguments | Description |
|-----------|-------------|
-| *mu| Pointer to mutex |
+| `*mu`| Pointer to mutex |
#### Returned values
-OS_INVALID_PARM: returned when *mu is NULL on entry.
+`OS_INVALID_PARM`: returned when `*mu` is **NULL** on entry.
-OS_OK: mutex initialized successfully.
+`OS_OK`: mutex initialized successfully.
-OS_BAD_MUTEX: The mutex was not owned by the task attempting to release it.
+`OS_BAD_MUTEX`: The mutex was not owned by the task attempting to release it.
-OS_NOT_STARTED: Attempt to release a mutex before the os has been started.
+`OS_NOT_STARTED`: Attempt to release a mutex before the os has been started.
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mynewt_os.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mynewt_os.md b/docs/os/core_os/mynewt_os.md
index 2f22abb..ecc695b 100644
--- a/docs/os/core_os/mynewt_os.md
+++ b/docs/os/core_os/mynewt_os.md
@@ -1,6 +1,6 @@
# Mynewt Core OS
-The Mynewt Core OS is a multitasking, preemptive real-time operating system combining a scheduler with typical RTOS features such as mutexes, semaphores, memory pools, etc. The Mynewt Core OS also provides a number of useful utilities such as a task watchdog, networking stack memory buffers and time management API. Each of these features is described in detail in its own section of the manual.
+The Mynewt Core OS is a multitasking, preemptive real-time operating system combining a scheduler with typical RTOS features such as mutexes, semaphores, memory pools, etc. The Mynewt Core OS also provides a number of useful utilities such as a task watchdog, networking stack, memory buffers and time management API. Each of these features is described in detail in its own section of the manual.
A multitasking, preemptive operating system is one in which a number of different tasks can be instantiated and assigned a priority, with higher priority tasks running before lower priority tasks. Furthermore, if a lower priority task is running and a higher priority task wants to run, the lower priority task is halted and the higher priority task is allowed to run. In other words, the lower priority task is preempted by the higher priority task.
@@ -41,9 +41,9 @@ Consider the sequence of events when the OS is started. The scheduler starts run
One way to avoid initialization issues like the one described above is to perform task initializations prior to starting the OS. The code example shown below illustrates this concept. The application initializes the OS, calls an application specific "task initialization" function, and then starts the OS. The application task initialization function is responsible for initializing all the data objects that each task exposes to the other tasks. The tasks themselves are also initialized at this time (by calling `os_task_init()`).
-In the example, each task works in a ping-pong like fashion: task 1 wakes up, adds a token to semaphore 1 and then waits for a token from semaphore 2. Task 2 waits for a token on semaphore 1 and once it gets it, adds a token to semaphore 2. Notice that the semaphores are initialized by the application specific task initialization functions and not inside the task handler functions. If task 2 (being lower in priority than task 1) had called os_sem_init() for task2_sem inside task2_handler(), task 1 would have called os_sem_pend() using task2_sem before task2_sem was initialized.
-
+In the example, each task works in a ping-pong like fashion: task 1 wakes up, adds a token to semaphore 1 and then waits for a token from semaphore 2. Task 2 waits for a token on semaphore 1 and once it gets it, adds a token to semaphore 2. Notice that the semaphores are initialized by the application specific task initialization functions and not inside the task handler functions. If task 2 (being lower in priority than task 1) had called `os_sem_init()` for task2_sem inside `task2_handler()`, task 1 would have called `os_sem_pend()` using task2_sem before task2_sem was initialized.
+```c
/* Task 1 handler function */
void
task1_handler(void *arg)
@@ -145,7 +145,7 @@ In the example, each task works in a ping-pong like fashion: task 1 wakes up, ad
return rc;
}
-
+```
###OS Functions
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/os_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/os_init.md b/docs/os/core_os/os_init.md
index eaad890..36a9430 100644
--- a/docs/os/core_os/os_init.md
+++ b/docs/os/core_os/os_init.md
@@ -1,10 +1,10 @@
## <font color="#F2853F" style="font-size:24pt">os_init</font>
-```no-highlight
+```c
void os_init(void)
```
-Initializes the OS. Must be called before the OS is started (i.e. os_start() is called).
+Initializes the OS. Must be called before the OS is started (i.e. `os_start()` is called).
<br>
@@ -21,6 +21,6 @@ None
#### Notes
-The call to os_init performs architecture and bsp initializations and initializes the idle task.
+The call to `os_init()` performs architecture and bsp initializations and initializes the idle task.
This function does not start the OS, the OS time tick interrupt, or the scheduler.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/os_start.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/os_start.md b/docs/os/core_os/os_start.md
index cc6db5e..e1480b4 100644
--- a/docs/os/core_os/os_start.md
+++ b/docs/os/core_os/os_start.md
@@ -1,6 +1,6 @@
## <font color="#F2853F" style="font-size:24pt">os_start</font>
-```no-highlight
+```c
void os_start(void)
```
@@ -23,5 +23,5 @@ None (does not return).
#### Notes
-Once os_start has been called, context is switched to the highest priority task that was initialized prior to calling os_start.
+Once `os_start()` has been called, context is switched to the highest priority task that was initialized prior to calling `os_start()`.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/os_started.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/os_started.md b/docs/os/core_os/os_started.md
index 5584782..d8d24ca 100644
--- a/docs/os/core_os/os_started.md
+++ b/docs/os/core_os/os_started.md
@@ -1,6 +1,6 @@
-## <font color="#F2853F" style="font-size:24pt">os_started</font>
+##<font color="#F2853F" style="font-size:24pt">os_started</font>
-```no-highlight
+```c
int os_started(void)
```
@@ -15,5 +15,5 @@ None
<br>
#### Returned values
-Integer value with 0 meaning the OS has not been started and 1 indicating the OS has been started (i.e. os_start() has been called).
+Integer value with 0 meaning the OS has not been started and 1 indicating the OS has been started (i.e. `os_start()` has been called).
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/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..638ecb9 100644
--- a/docs/os/core_os/porting/port_bsp.md
+++ b/docs/os/core_os/porting/port_bsp.md
@@ -3,7 +3,10 @@
###Introduction
-If you are using a board or system not currently supported by Mynewt, you will need to create a BSP for the new target. If another similar BSP exists it is recommended to copy that BSP as a starting point. For example, if another BSP exists using the same MCU, start with a copy of that BSP.
+If you are using a board or system not currently supported by Mynewt, you will need to
+create a BSP for the new target. If another similar BSP exists it is recommended to
+copy that BSP as a starting point. For example, if another BSP exists using the same MCU,
+start with a copy of that BSP.
Either way, this document describes the steps necessary to create a new BSP from scratch.
@@ -18,32 +21,35 @@ To build a proper BSP, you will typically need the following:
###Name your BSP
-Select a name for your BSP. For the remainder of this document, we'll assume the bsp is named `myboard`. In general its best to select a name that describes the board/system you are creating.
+Select a name for your BSP. For the remainder of this document, we'll assume the bsp is named `myboard`.
+In general its best to select a name that describes the board/system you are creating.
###Create a BSP directory
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
-name that describes the board/system you are creating.
-
* `include`
* `include/bsp`
* `src`
###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/project_create). 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`.
+It is recommended that you use a simple project like [blinky](../tutorials/blinky_primo.md) to minimize the time
+to get a working Mynewt system. For this document, we will assume the *target* is called *myboard_blinky*
+and uses project *blinky*.
-Set the `bsp` of the project to `/hw/bsp/myboard`. While creating your target, you will need to specify your `arch`and `compiler`. If your platform requires an architecture or compiler that are not defined in Mynewt, you will need to add them first. To add a CPU architecture see [CPU Porting](port_cpu.md).
+Set the `bsp` of the project to `/hw/bsp/myboard`. While creating your target, you will need to
+specify your `arch`and `compiler`. If your platform requires an architecture or compiler
+that are not defined in Mynewt, you will need to add them first. To add a CPU architecture see [CPU Porting](port_cpu.md).
-When you are complete, your `target` may look similar to this.
+When this is complete, your *target* may look similar to this.
```c
- $newt target show
+ $ newt target show
myboard_blinky
arch=cortex_m0
bsp=hw/bsp/myboard
@@ -84,21 +90,23 @@ Edit the package file to describe your BSP.
The package file must contain:
-```c
+```no-highlight
pkg.name: "hw/bsp/myboard"
pkg.linkerscript: "myboard.ld"
```
| **Attribute** | **Description** |
|-----------|-------------|
-| pkg.name | The name of your bsp package |
-| pkg.linkerscript | The linker script that controls the memory placement of the compiled code sections from the Mynewt OS and your applications. |
+| `pkg.name` | The name of your bsp package |
+| `pkg.linkerscript` | The linker script that controls the memory placement of the compiled code sections from the Mynewt OS and your applications. |
-The linker script is a key component of the BSP and specifies where each section of code and data are stored within your CPU which can vary with the BSP depending on your chosen memory layout. For a tutorial on writing linker scripts, see [Create or Copy Linker Script(s)](#create-or-copy-linker-script).
+The linker script is a key component of the BSP and specifies where each section of code and data are
+stored within your CPU which can vary with the BSP depending on your chosen memory layout.
+For a tutorial on writing linker scripts, see [Create or Copy Linker Script(s)](#create-or-copy-linker-script).
The package file typically contains:
-```c
+```no-highlight
pkg.linkerscript.bootloader.OVERWRITE: "myboard_boot.ld"
pkg.downloadscript: "myboard_download.sh"
pkg.debugscript: "myboard_debug.sh"
@@ -111,29 +119,33 @@ The following table describes additional attributes relevant to the BSP `pkg.yml
| **Attribute** | **Description** |
|-----------|-------------|
-| pkg.linkerscript.bootloader.OVERWRITE | A special linker for creating a bootloader for Mynewt |
-| pkg.downloadscript | A script that can download a flash image into your target platform |
-| pkg.debugscript | A script that can run the GDB debugger on your board |
-| pkg.deps | Any dependencies on your BSP |
+| `pkg.linkerscript.bootloader.OVERWRITE` | A special linker for creating a bootloader for Mynewt |
+| `pkg.downloadscript` | A script that can download a flash image into your target platform |
+| `pkg.debugscript` | A script that can run the GDB debugger on your board |
+| `pkg.deps` | Any dependencies on your BSP |
-The BSP will invariably depend upon an MCU ( in this sample it's `hw/mcu/mymcu/variant`) since the Mynewt OS runs on an MCU within your target. If your MCU is not supported by Mynewt, see [MCU Porting](port_mcu.md) for details on how to create an MCU in Mynewt.
+The BSP will invariably depend upon an MCU (in this sample it's `hw/mcu/mymcu/variant`) since the
+Mynewt OS runs on an MCU within your target. If your MCU is not supported by Mynewt,
+see [MCU Porting](port_mcu.md) for details on how to create a new MCU in Mynewt.
The package file may also contain:
-```c
+```no-highlight
pkg.cflags: -D__MY_SPECIAL_BSP_OPTIONS_
pkg.deps:
- libs/cmsis-core
```
+
| **Attribute** | **Description** |
|-----------|-------------|
-| pkg.cflags | Any specific compiler flags for your bsp |
-| pkg.deps | Any other libraries that may be required. Some architectures (like ARM) have special libraries to make BSP creation easier. |
+| `pkg.cflags` | Any specific compiler flags for your bsp |
+| `pkg.deps` | Any other libraries that may be required. Some architectures (like ARM) have special libraries to make BSP creation easier. |
###Create or Copy Linker Script
-It's probably best to start with a linker script from another BSP using the same MCU. If this is not available, consult your MCU documentation and library samples to find a linker script to start with.
+It's probably best to start with a linker script from another BSP using the same MCU. If this is not available,
+consult your MCU documentation and library samples to find a linker script to start with.
Typically, a linker script has to specify the following sections for code:
@@ -142,19 +154,22 @@ Typically, a linker script has to specify the following sections for code:
* .bss -- the location and alignment of the memory section to store uninitialized data
* .heap -- the location and alignment of the memory section to provide system memory
-The linker script should specify the location and size of the different memory regions in your BSP and map the code sections described above into these regions.
+The linker script should specify the location and size of the different memory regions
+in your BSP and map the code sections described above into these regions.
-The linker script should also include an ENTRY point. This is used by the debugger to know where to start the program counter when the target is debugged.
+The linker script should also include an ENTRY point. This is used by the debugger
+to know where to start the program counter when the target is debugged.
-There may be additional requirements from the MCU or OS that you may find easiest to place in the linker script. Some specific variables that the OS and MCU depends on are :
+There may be additional requirements from the MCU or OS that you may find easiest to
+place in the linker script. Some specific variables that the OS and MCU depends on are :
| **Variable** | **Description** |
|-----------|-------------|
-|\__bss_start__ | a variable located at the start of the BSS section |
-|\__bss_end__ | a variable located at the end of the BSS section |
-|\__isr_vector | Some CPUs map their interrupt vectors. They may need to be specified in the linker |
-|\_user_heap_start | the start of the heap for unallocated memory |
-|\_user_heap_end | the end of the heap for unallocated memory |
+|`__bss_start__` | a variable located at the start of the BSS section |
+|`__bss_end__` | a variable located at the end of the BSS section |
+|`__isr_vector` | Some CPUs map their interrupt vectors. They may need to be specified in the linker |
+|`_user_heap_start` | the start of the heap for unallocated memory |
+|`_user_heap_end` | the end of the heap for unallocated memory |
Create an alternate linker script for the bootloader since it is typically linked to use different addresses to boot the main image.
@@ -166,24 +181,27 @@ You may run into complaints from the linker script that a few Mynewt specific fu
| **Function** | **Description** |
|-----------|-------------|
-| os_bsp_init() | code to initialize the bsp |
-| os_bsp_systick_init() | code to setup the system tick for the OS |
+| `os_bsp_init()` | code to initialize the bsp |
+| `os_bsp_systick_init()` | code to setup the system tick for the OS |
-There are also several libc definitions that can be stubbed in your first BSP. Examples are `_write`, `_read`, etc. that can be found in `libc_stubs.c`. But you _must_ implement the following function to provide memory to the OS and system.
+There are also several libc definitions that can be stubbed in your first BSP. Examples are `_write`, `_read`,
+etc. that can be found in `libc_stubs.c`. But you _must_ implement the following function to provide memory to the OS and system.
| **Function** | **Description** |
|-----------|-------------|
-| _sbrk | Returns memory from heap (used by malloc) |
+| `_sbrk` | Returns memory from heap (used by malloc) |
* Implement `_sbrk()`
-`sbrk()` is required by libc to get memory from the heap for things like malloc. Although not strongly BSP dependent, this is currently in the BSP to allow flexibility in providing system memory. See other BSPs for providing `sbrk` functionality.
+`sbrk()` is required by libc to get memory from the heap for things like malloc. Although not strongly BSP dependent,
+this is currently in the BSP to allow flexibility in providing system memory. See other BSPs for providing `sbrk` functionality.
* Implement `os_bsp_init()`
-`os_bsp_init` should initialize anything required by the OS by the BSP. Typically this is a very small set.
+`os_bsp_init` should initialize anything required in the OS by the BSP. Typically this is a very small set.
-NOTE: Currently we are making calls to `_sbrk()` and `close(0)` from `os_bsp_init` to get around a linker issue where some of libc is not getting included. Please include this in your `os_bsp_init`.
+**NOTE**: Currently we are making calls to `_sbrk()` and `close(0)` from `os_bsp_init` to get around a
+linker issue where some of libc is not getting included. Please include this in your `os_bsp_init`.
```c
/*
@@ -200,20 +218,27 @@ There may be other unresolved defines or functions that are required by the spec
| **Undefined Variable** | **Description** |
|-----------|-------------|
-| CONSOLE_UART_PORT | Which communications port on your target runs the console |
-| LED_BLINK_PIN | which pin on your target runs the blinky LED |
+| `CONSOLE_UART_PORT` | Which communications port on your target runs the console |
+| `LED_BLINK_PIN` | which pin on your target runs the blinky LED |
-The set of missing functionality depends upon the libraries and dependencies you have included in the project. That's why its best to keep your first project pretty simple then add incrementally. For example, if you include Newtron file system, you will need to define a file system map for your BSP.
+The set of missing functionality depends upon the libraries and dependencies you have included in the project.
+That's why its best to keep your first project pretty simple then add incrementally.
+For example, if you include the Newtron file system, you will need to define a file system map for your BSP.
Missing functionality may take the form of `#define` items required to compile, or they may take the form of missing functions.
* `cmsis_nvic.h`
-If you are using an ARM cortex architecture, you need to define the number of interrupts supported by your system. If you are not using ARM Cortex architecture this may not be required (but something else might be).
+If you are using an ARM cortex architecture, you need to define the number of interrupts supported by your system.
+If you are not using ARM Cortex architecture this may not be required (but something else might be).
###Add Debug Script
-The debug script in the bsp directory allows the newt tool to automatically connect to the debugger, and create a debug session with the target. This requires knowledge of your target debug interface. Most of the Mynewt BSP targets use [openocd](http://openocd.org) to perform debugging. This script typically creates an openocd connection to the target and then connects a gdb instance to this openocd connection. There are several examples in existing BSPs to follow.
+The debug script in the bsp directory allows the newt tool to automatically connect to the debugger
+and create a debug session with the target. This requires knowledge of your target debug interface.
+Most of the Mynewt BSP targets use [openocd](http://openocd.org) to perform debugging.
+This script typically creates an openocd connection to the target and then connects a gdb instance
+to this openocd connection. There are several examples in existing BSPs to follow.
The script must take a single argument which is the name of the image file minus the '.elf' suffix.
@@ -221,10 +246,13 @@ The BSP is complete without this file, but newt will be unable to establish a de
###Add Download Script
-Similar to the debug script, the download script is a hook for newt to download the image to the target system. The download script also typically uses openocd interface to erase flash, and progam the code into the device.
+Similar to the debug script, the download script is a hook for newt to download the image to the target system.
+The download script also typically uses the openocd interface to erase flash and progam the code into the device.
-NOTE: The download script needs to command openocd to program the image into the appropriate location, which is typically called `FLASH_OFFSET` in these scripts. This location has to match the linker script location of the image link address. For example, if your linker links the code to be run at `0xC000` your download script should download the image to the same
-address in the correct flash.
+**NOTE:** The download script needs to command openocd to program the image into the appropriate location
+which is typically called `FLASH_OFFSET` in these scripts. This location has to match the linker script
+location of the image link address. For example, if your linker links the code to be run at `0xC000` your
+download script should download the image to the same address in the correct flash.
###Add License and Documentation
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/porting/port_cpu.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/porting/port_cpu.md b/docs/os/core_os/porting/port_cpu.md
index fae2e82..873b42a 100644
--- a/docs/os/core_os/porting/port_cpu.md
+++ b/docs/os/core_os/porting/port_cpu.md
@@ -10,22 +10,26 @@ These are discussed below:
###Create A New Compiler
-NOTE: Newt does not automatically install the compilers require to build all platforms. Its up to the user using their local machines package manager to install the compilers. The step described here just registers the compiler with newt.
+NOTE: Newt does not automatically install the compilers require to build all platforms.
+It's up to the user using their local machines package manager to install the compilers.
+The steps described here just registers the compiler with newt.
Create a new directory (named after the compiler you are adding). Copy the `pkg.yml` file from another compiler.
-Edit the `pkg.yml` file and change the configuration attributes to match your compiler. Most are self-explanatory paths to different compiler and linker tools. There are a few configuration attributes worth noting.
+Edit the `pkg.yml` file and change the configuration attributes to match your compiler.
+Most are self-explanatory paths to different compiler and linker tools. There are a few configuration attributes worth noting.
| **Configuration Attributes** | **Description** |
|-----------|-------------|
-| pkg.keywords | Specific keywords to help others search for this using newt |
-| compiler.flags.default | default compiler flags for this architecture |
-| compiler.flags.optimized | additional flags when the newt tool builds an optimized image |
-| compiler.flags.debug | additional flags when the newt tool builds a debug image|
+| `pkg.keywords` | Specific keywords to help others search for this using newt |
+| `compiler.flags.default` | default compiler flags for this architecture |
+| `compiler.flags.optimized` | additional flags when the newt tool builds an optimized image |
+| `compiler.flags.debug` | additional flags when the newt tool builds a debug image|
-###Implement architecture-specific OS code
+###Implement Architecture-specific OS code
-There are several architecture-specific code functions that are required when implementing a new architecture. You can find examples in the `sim` architecture within Mynewt.
+There are several architecture-specific code functions that are required when implementing a
+new architecture. You can find examples in the `sim` architecture within Mynewt.
When porting to a new CPU architecture, use the existing architectures as samples when writing your implementation.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/porting/port_mcu.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/porting/port_mcu.md b/docs/os/core_os/porting/port_mcu.md
index 8fe5fbf..504baa3 100644
--- a/docs/os/core_os/porting/port_mcu.md
+++ b/docs/os/core_os/porting/port_mcu.md
@@ -6,9 +6,12 @@ The depth of work depends on the amount of HAL (Hardware Abstraction Layer) supp
To get started:
-* Create a `hw/mcu/mymcu` directory where `mymcu` is the MCU you are porting to. Replace the name `mymcu` with a description of the MCU you are using.
-* Create a `hw/mcu/mymcu/variant` directory where the variant is the specific variant of the part you are usuing. Many MCU parts have variants with different capabilities (RAM, FLASH etc) or different pinouts. Replace `variant` with a description of the variant of the part you are using.
-* Create a `hw/mcu/mymcu/variant/pkg.yml` file. Copy from another mcu and fill out the relevant information
+* Create a `hw/mcu/mymcu` directory where `mymcu` is the MCU you are porting to.
+Replace the name `mymcu` with a description of the MCU you are using.
+* Create a `hw/mcu/mymcu/variant` directory where the variant is the specific
+variant of the part you are usuing. Many MCU parts have variants with different capabilities
+(RAM, FLASH etc) or different pinouts. Replace `variant` with a description of the variant of the part you are using.
+* Create a `hw/mcu/mymcu/variant/pkg.yml` file. Copy from another mcu and fill out the relevant information
* Create `hw/mcu/mymcu/variant/include`,`hw/mcu/mymcu/variant/include/mcu`, and
`hw/mcu/mymcu/variant/src` directories to contain the code for your mcu.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/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..2d3895a 100644
--- a/docs/os/core_os/porting/port_os.md
+++ b/docs/os/core_os/porting/port_os.md
@@ -22,9 +22,10 @@ SoC within your target platform
* **BSP Dependencies** -- Specific code or configuration to accommodate the
specific layout and functionality of your target platform
-###BSP Dependency
+###Board Support Package (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.
@@ -51,25 +52,38 @@ 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 not yet supported by Mynewt, you can add support following the instructions on [how to add BSP support to Mynewt](port_bsp.md)
+* If your BSP is already supported my Mynewt, there is no additional BSP work involved in porting to your platform.
+You need only 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 by 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.
+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 not yet supported by Mynewt, you can add support following the instructions on[how to add MCU support to Mynewt](port_mcu.md)
+* If your MCU is already supported by Mynewt, there is no additional MCU work involved in
+porting to your platform. You need only 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 by following the
+instructions on [how to add MCU support to Mynewt](port_mcu.md)
-### MCU HAL
+### MCU Hardware Abstraction Layer (HAL)
-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,
+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
-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.
+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 not supported by Mynewt, you can add support following the instructions on [how to add CPU architecture support to Mynewt](port_cpu.md)
+* If your CPU architecture is already supported by Mynewt, there is no CPU core work involved
+in porting to your platform. You need only 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 by 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/aac53ed0/docs/os/core_os/sanity/sanity.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/sanity/sanity.md b/docs/os/core_os/sanity/sanity.md
index 7091a33..ff9c5c9 100644
--- a/docs/os/core_os/sanity/sanity.md
+++ b/docs/os/core_os/sanity/sanity.md
@@ -148,7 +148,7 @@ err:
In the above example, every time the custom sanity check
`mymodule_perform_sanity_check` returns successfully (0),
the sanity check is reset. In the `OS_SANITY_CHECK_SETFUNC` macro,
-the sanity checkin interval is specified as 50 * SANITY_TASK_INTERVAL
+the sanity checkin interval is specified as 50 * `SANITY_TASK_INTERVAL`
(which is the interval at which the sanity task runs.) This means
that the `mymodule_perform_sanity_check()` function needs to fail
50 times consecutively before the sanity task will crash the system.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/semaphore/os_sem_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/os_sem_init.md b/docs/os/core_os/semaphore/os_sem_init.md
index 894caab..c588a19 100644
--- a/docs/os/core_os/semaphore/os_sem_init.md
+++ b/docs/os/core_os/semaphore/os_sem_init.md
@@ -11,14 +11,14 @@ Initialize a semaphore with a given number of tokens. Should be called before th
| Arguments | Description |
|-----------|-------------|
-| *sem | Pointer to semaphore |
-| tokens | Initial number of tokens allocated to semaphore |
+| `*sem` | Pointer to semaphore |
+| `tokens` | Initial number of tokens allocated to semaphore |
#### Returned values
-OS_INVALID_PARM: returned when *sem is NULL on entry.
+`OS_INVALID_PARM`: returned when `*sem` is **NULL** on entry.
-OS_OK: semaphore initialized successfully.
+`OS_OK`: semaphore initialized successfully.
#### Notes
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/semaphore/os_sem_pend.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/os_sem_pend.md b/docs/os/core_os/semaphore/os_sem_pend.md
index 9ccf8bd..c068595 100644
--- a/docs/os/core_os/semaphore/os_sem_pend.md
+++ b/docs/os/core_os/semaphore/os_sem_pend.md
@@ -10,22 +10,22 @@ Wait for a semaphore for a given amount of time.
| Arguments | Description |
|-----------|-------------|
-| *sem | Pointer to semaphore |
-| timeout | Amount of time, in os ticks, to wait for semaphore. A value of 0 means no wait. A value of 0xFFFFFFFF means wait forever. |
+| `*sem` | Pointer to semaphore |
+| `timeout` | Amount of time, in os ticks, to wait for semaphore. A value of 0 means no wait. A value of 0xFFFFFFFF means wait forever. |
#### Returned values
-OS_INVALID_PARM: returned when *sem is NULL on entry.
+`OS_INVALID_PARM`: returned when `*sem` is **NULL** on entry.
-OS_OK: semaphore acquired successfully.
+`OS_OK`: semaphore acquired successfully.
-OS_TIMEOUT: the semaphore was not available within the timeout specified.
+`OS_TIMEOUT`: the semaphore was not available within the timeout specified.
-OS_NOT_STARTED: Attempt to release a semaphore before os started.
+`OS_NOT_STARTED:` Attempt to release a semaphore before os started.
#### Notes
-If a timeout of 0 is used and the function returns OS_TIMEOUT, the semaphore was not available and was not acquired. No release of the semaphore should occur and the calling task does not own the semaphore.
+If a timeout of 0 is used and the function returns `OS_TIMEOUT`, the semaphore was not available and was not acquired. No release of the semaphore should occur and the calling task does not own the semaphore.
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/semaphore/os_sem_release.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/os_sem_release.md b/docs/os/core_os/semaphore/os_sem_release.md
index 3cb31f9..d55b992 100644
--- a/docs/os/core_os/semaphore/os_sem_release.md
+++ b/docs/os/core_os/semaphore/os_sem_release.md
@@ -11,15 +11,15 @@ Release a semaphore that you are holding. This adds a token to the semaphore.
| Arguments | Description |
|-----------|-------------|
-| *sem | Pointer to semaphore |
+| `*sem` | Pointer to semaphore |
#### Returned values
-OS_NOT_STARTED: Called before os has been started.
+`OS_NOT_STARTED`: Called before os has been started.
-OS_INVALID_PARM: returned when *sem is NULL on entry.
+`OS_INVALID_PARM`: returned when `*sem` is **NULL** on entry.
-OS_OK: semaphore released successfully.
+`OS_OK`: semaphore released successfully.
#### Notes
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/semaphore/semaphore.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/semaphore/semaphore.md b/docs/os/core_os/semaphore/semaphore.md
index 9bcff62..a97643d 100644
--- a/docs/os/core_os/semaphore/semaphore.md
+++ b/docs/os/core_os/semaphore/semaphore.md
@@ -1,17 +1,17 @@
# Semaphore
-A semaphore is a structure used for gaining exclusive access (much like a mutex), synchronizing task operations and/or use in a "producer/consumer" roles. Semaphores like the ones used by the myNewt OS are called "counting" semaphores as they are allowed to have more than one token (explained below).
+A semaphore is a structure used for gaining exclusive access (much like a mutex), synchronizing task operations and/or use in a "producer/consumer" roles. Semaphores like the ones used by the Mynewt OS are called "counting" semaphores as they are allowed to have more than one token (explained below).
### Description
A semaphore is a fairly simple construct consisting of a queue for waiting tasks and the number of tokens currently owned by the semaphore. A semaphore can be obtained as long as there are tokens in the semaphore. Any task can add tokens to the semaphore and any task can request the semaphore, thereby removing tokens. When creating the semaphore, the initial number of tokens can be set as well.
-When used for exclusive access to a shared resource the semaphore only needs a single token. In this case, a single task "creates" the semaphore by calling *os_sem_init* with a value of one (1) for the token. When a task desires exclusive access to the shared resource it requests the semaphore by calling *os_sem_pend*. If there is a token the requesting task will acquire the semaphore and continue operation. If no tokens are available the task will be put to sleep until there is a token. A common "problem" with using a semaphore for exclusive access is called *priority inversion*. Consider the following scenario: a high and low priority task both share a resource which is locked using a semaphore. If the low priority task obtains the semaphore and then the high priority task requests the semaphore, the high priority task is now blocked until the low priority task releases the semaphore. Now suppose that there are tasks between the low priority task and the high priority task that wa
nt to run. These tasks will preempt the low priority task which owns the semaphore. Thus, the high priority task is blocked waiting for the low priority task to finish using the semaphore but the low priority task cannot run since other tasks are running. Thus, the high priority tasks is "inverted" in priority; in effect running at a much lower priority as normally it would preempt the other (lower priority) tasks. If this is an issue a mutex should be used instead of a semaphore.
+When used for exclusive access to a shared resource the semaphore only needs a single token. In this case, a single task "creates" the semaphore by calling `os_sem_init` with a value of one (1) for the token. When a task desires exclusive access to the shared resource it requests the semaphore by calling `os_sem_pend`. If there is a token the requesting task will acquire the semaphore and continue operation. If no tokens are available the task will be put to sleep until there is a token. A common problem with using a semaphore for exclusive access is called *priority inversion*. Consider the following scenario: a high and low priority task both share a resource which is locked using a semaphore. If the low priority task obtains the semaphore and then the high priority task requests the semaphore, the high priority task is now blocked until the low priority task releases the semaphore. Now suppose that there are tasks between the low priority task and the high priority task that want
to run. These tasks will preempt the low priority task which owns the semaphore. Thus, the high priority task is blocked waiting for the low priority task to finish using the semaphore but the low priority task cannot run since other tasks are running. Thus, the high priority tasks is "inverted" in priority; in effect running at a much lower priority as normally it would preempt the other (lower priority) tasks. If this is an issue a mutex should be used instead of a semaphore.
-Semaphores can also be used for task synchronization. A simple example of this would be the following. A task creates a semaphore and initializes it with no tokens. The task then waits on the semaphore, and since there are no tokens, the task is put to sleep. When other tasks want to wake up the sleeping task they simply add a token by calling *os_sem_release*. This will cause the sleeping task to wake up (instantly if no other higher priority tasks want to run).
+Semaphores can also be used for task synchronization. A simple example of this would be the following. A task creates a semaphore and initializes it with no tokens. The task then waits on the semaphore, and since there are no tokens, the task is put to sleep. When other tasks want to wake up the sleeping task they simply add a token by calling `os_sem_release`. This will cause the sleeping task to wake up (instantly if no other higher priority tasks want to run).
-The other common use of a counting semaphore is in what is commonly called a "producer/consumer" relationship. The producer adds tokens (by calling *os_sem_release*) and the consumer consumes them by calling *os_sem_pend*. In this relationship, the producer has work for the consumer to do. Each token added to the semaphore will cause the consumer to do whatever work is required. A simple example could be the following: every time a button is pressed there is some work to do (ring a bell). Each button press causes the producer to add a token. Each token consumed rings the bell. There will exactly the same number of bell rings as there are button presses. In other words, each call to *os_sem_pend* subtracts exactly one token and each call to *os_sem_release* adds exactly one token.
+The other common use of a counting semaphore is in what is commonly called a "producer/consumer" relationship. The producer adds tokens (by calling `os_sem_release`) and the consumer consumes them by calling `os_sem_pend`. In this relationship, the producer has work for the consumer to do. Each token added to the semaphore will cause the consumer to do whatever work is required. A simple example could be the following: every time a button is pressed there is some work to do (ring a bell). Each button press causes the producer to add a token. Each token consumed rings the bell. There will be exactly the same number of bell rings as there are button presses. In other words, each call to `os_sem_pend` subtracts exactly one token and each call to `os_sem_release` adds exactly one token.
### Data structures
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/task/os_task_info_get_next.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/os_task_info_get_next.md b/docs/os/core_os/task/os_task_info_get_next.md
index d1e5759..ef39372 100644
--- a/docs/os/core_os/task/os_task_info_get_next.md
+++ b/docs/os/core_os/task/os_task_info_get_next.md
@@ -3,27 +3,27 @@
```c
struct os_task *os_task_info_get_next(const struct os_task *prev, struct os_task_info *oti);
```
-Populates the os task info structure pointed to by *oti* with task information.
-The task populating the *oti* structure is either the first task on the task
-list if *prev* is NULL, or the next task in the task list (the next pointer of
-*prev*).
+Populates the os task info structure pointed to by `oti` with task information.
+The task populating the `oti` structure is either the first task on the task
+list if `prev` is **NULL**, or the next task in the task list (the next pointer of
+`prev`).
-If there are no tasks initialized, NULL is returned. Otherwise, the task
-structure used to populate *oti* is returned.
+If there are no tasks initialized, **NULL** is returned. Otherwise, the task
+structure used to populate `oti` is returned.
<br>
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| prev | Pointer to previous task in task list. If NULL, use first task on list |
-| oti | Pointer to `os_task_info` structure where task information will be stored |
+| `prev` | Pointer to previous task in task list. If NULL, use first task on list |
+| `oti` | Pointer to `os_task_info` structure where task information will be stored |
<br>
#### Returned values
Returns a pointer to the os task structure that was used to populate the task
-information structure. NULL means that no tasks were created.
+information structure. **NULL** means that no tasks were created.
<br>
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/task/os_task_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/os_task_init.md b/docs/os/core_os/task/os_task_init.md
index a8329be..788ebbc 100644
--- a/docs/os/core_os/task/os_task_init.md
+++ b/docs/os/core_os/task/os_task_init.md
@@ -6,7 +6,7 @@ int os_task_init(struct os_task *t, char *name, os_task_func_t func, void *arg,
uint16_t stack_size)
```
-Called to create a task. This adds the task object to the list of ready to run
+Called to create a task. This adds the task object to the list of *ready to run*
tasks.
<br>
@@ -14,19 +14,19 @@ tasks.
| Arguments | Description |
|-----------|-------------|
-| t | Pointer to task |
-| name | Task name |
-| func | Task function |
-| arg | Generic argument to pass to task |
-| prio | Priority of task |
-| sanity_itvl | The interval at which the sanity task will check to see if this task is sill alive |
-| stack_bottom | Pointer to bottom of stack. |
-| stack_size | The size of the stack. NOTE: this is not in bytes! It is the number of `os_stack_t` elements allocated (generally 32-bits each) |
+| `t` | Pointer to task |
+| `name` | Task name |
+| `func` | Task function |
+| `arg` | Generic argument to pass to task |
+| `prio` | Priority of task |
+| `sanity_itvl` | The interval at which the sanity task will check to see if this task is sill alive |
+| `stack_bottom` | Pointer to bottom of stack. |
+| `stack_size` | The size of the stack. NOTE: this is not in bytes! It is the number of `os_stack_t` elements allocated (generally 32-bits each) |
<br>
#### Returned values
-OS_OK: task initialization successful.
+`OS_OK`: task initialization successful.
All other error codes indicate an internal error.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/task/task.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/task/task.md b/docs/os/core_os/task/task.md
index dac58d0..6ec0685 100644
--- a/docs/os/core_os/task/task.md
+++ b/docs/os/core_os/task/task.md
@@ -3,9 +3,8 @@
A task, along with the scheduler, forms the basis of the Mynewt OS. A task
consists of two basic elements: a task stack and a task function. The task
function is basically a forever loop, waiting for some "event" to wake it up.
-There are two methods used to signal a task that it has work to do: event queues
-and semaphores (see the appropriate manual sections for descriptions of these
-features).
+There are two methods used to signal a task that it has work to do: [event queues](../event_queue/event_queue.md)
+and [semaphores](../semaphore/semaphore.md) .
The Mynewt OS is a multi-tasking, preemptive OS. Every task is assigned a task
priority (from 0 to 255), with 0 being the highest priority task. If a higher
@@ -16,11 +15,11 @@ stack of the higher priority task and the task resumes execution where it left
off.
Tasks run to completion unless they are preempted by a higher priority task. The
-developer must insure that tasks eventually "sleep"; otherwise lower priority
+developer must ensure that tasks eventually "sleep"; otherwise lower priority
tasks will never get a chance to run (actually, any task lower in priority than
the task that never sleeps). A task will be put to sleep in the following cases:
-it puts itself to sleep using `os_time_delay()`, it waits on an event queue
-which is empty or attempts to obtain a mutex or a semaphore that is currently
+it puts itself to sleep using `os_time_delay()`, it waits on an [event queue](../event_queue/event_queue.md)
+which is empty or attempts to obtain a mutex or a [semaphore](../semaphore/semaphore.md) that is currently
owned by another task.
Note that other sections of the manual describe these OS features in more
@@ -29,7 +28,7 @@ detail.
## Description
In order to create a task two data structures need to be defined: the task
-object (struct os_task) and its associated stack. Determining the stack size can
+object (`struct os_task`) and its associated stack. Determining the stack size can
be a bit tricky; generally developers should not declare large local variables
on the stack so that task stacks can be of limited size. However, all
applications are different and the developer must choose the stack size
@@ -47,7 +46,7 @@ scheduler, the `os_task_init()` function is called. Once `os_task_init()` is
called, the task is made ready to run and is added to the active task list. Note
that a task can be initialized (started) before or after the os has started
(i.e. before `os_start()` is called) but must be initialized after the os has
-been initialized (i.e. 'os_init' has been called). In most of the examples and
+been initialized (i.e. 'os_init()' has been called). In most of the examples and
current Mynewt projects, the os is initialized, tasks are initialized, and the
the os is started. Once the os has started, the highest priority task will be
the first task set to run.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/time/os_gettimeofday.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_gettimeofday.md b/docs/os/core_os/time/os_gettimeofday.md
index 22d10a3..98875fb 100644
--- a/docs/os/core_os/time/os_gettimeofday.md
+++ b/docs/os/core_os/time/os_gettimeofday.md
@@ -8,8 +8,8 @@ int os_gettimeofday(struct os_timeval *utctime, struct os_timezone *timezone);
| Arguments | Description |
|-----------|-------------|
-| utctime | UTC time corresponding to wallclock time |
-| timezone | Timezone to convert UTC time to wallclock time |
+| `utctime` | UTC time corresponding to wallclock time |
+| `timezone` | Timezone to convert UTC time to wallclock time |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/time/os_settimeofday.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_settimeofday.md b/docs/os/core_os/time/os_settimeofday.md
index c5fc186..91615ce 100644
--- a/docs/os/core_os/time/os_settimeofday.md
+++ b/docs/os/core_os/time/os_settimeofday.md
@@ -8,8 +8,8 @@ int os_settimeofday(struct os_timeval *utctime, struct os_timezone *timezone);
| Arguments | Description |
|-----------|-------------|
-| utctime | UTC time corresponding to the wallclock time |
-| timezone | Timezone associated with the wallclock time |
+| `utctime` | UTC time corresponding to the wallclock time |
+| `timezone` | Timezone associated with the wallclock time |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/time/os_time.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time.md b/docs/os/core_os/time/os_time.md
index eee868f..52d0376 100644
--- a/docs/os/core_os/time/os_time.md
+++ b/docs/os/core_os/time/os_time.md
@@ -17,18 +17,20 @@ Time is stored in Mynewt as an `os_time_t` value.
Wallclock time is represented using the `struct os_timeval` and `struct os_timezone` tuple.
-`struct os_timeval` represents the number of seconds elapsed since 00:00:00 Jan 1, 1970 UTC.
-<pre>
+`struct os_timeval` represents the number of seconds elapsed since the epoch (00:00:00 Jan 1, 1970 UTC).
+
+```c
struct os_timeval {
int64_t tv_sec; /* seconds since Jan 1 1970 UTC */
int32_t tv_usec; /* fractional seconds */
};
struct os_timeval tv = { 1457400000, 0 }; /* 01:20:00 Mar 8 2016 UTC */
-</pre>
+```
`struct os_timezone` is used to specify the offset of local time from UTC and whether daylight savings is in effect. Note that `tz_minuteswest` is a positive number if the local time is *behind* UTC and a negative number if the local time is *ahead* of UTC.
-<pre>
+
+```c
struct os_timezone {
int16_t tz_minuteswest;
int16_t tz_dsttime;
@@ -40,7 +42,7 @@ struct os_timezone PDT = { 480, 1 };
/* Indian Standard Time is 05:30 hours east of UTC */
struct os_timezone IST = { -330, 0 };
-</pre>
+```
## List of Functions
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/time/os_time_delay.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time_delay.md b/docs/os/core_os/time/os_time_delay.md
index a9199ba..8b70236 100644
--- a/docs/os/core_os/time/os_time_delay.md
+++ b/docs/os/core_os/time/os_time_delay.md
@@ -8,7 +8,7 @@ void os_time_delay(int32_t ticks)
| Arguments | Description |
|-----------|-------------|
-| ticks | Number of ticks to delay. Less than or equal to zero means no delay |
+| `ticks` | Number of ticks to delay. Less than or equal to zero means no delay |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/get_started/vocabulary.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/vocabulary.md b/docs/os/get_started/vocabulary.md
index 729bf2e..f35f019 100644
--- a/docs/os/get_started/vocabulary.md
+++ b/docs/os/get_started/vocabulary.md
@@ -133,8 +133,8 @@ Targets can also have additional items specified, including:
In order to create and manipulate targets, the *newt* tool offers a set of helper commands,
you can find more information about these by issuing:
-```no-highlight
$ newt target
+```no-highligh
Usage:
newt target [flags]
newt target [command]
@@ -183,3 +183,9 @@ $ newt target config <target-name>
...
$
```
+
+Keep in mind that this will only show the configuration options for any packages that are included in your applicaiton.
+
+If you really want to see **all** the available configuration options, you can go rough each package and look at the
+`syscfg.yml` file in each.
+
[21/21] 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/38b20a68
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/38b20a68
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/38b20a68
Branch: refs/heads/develop
Commit: 38b20a6810c9566743fa9dc57f5717dc06cb6fab
Parents: f18c78f
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 16:03:10 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 16:05:45 2016 -0800
----------------------------------------------------------------------
custom-theme/landing.html | 1 +
mkdocs.yml | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/38b20a68/custom-theme/landing.html
----------------------------------------------------------------------
diff --git a/custom-theme/landing.html b/custom-theme/landing.html
index 746145b..c304f16 100644
--- a/custom-theme/landing.html
+++ b/custom-theme/landing.html
@@ -33,6 +33,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>
</ul>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/38b20a68/mkdocs.yml
----------------------------------------------------------------------
diff --git a/mkdocs.yml b/mkdocs.yml
index 8b22dc4..5f3e328 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'
[15/21] incubator-mynewt-site git commit: This closes #121
Posted by ad...@apache.org.
This closes #121
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/ff2476a1
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/ff2476a1
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/ff2476a1
Branch: refs/heads/develop
Commit: ff2476a1caf564266a6beb766d2026dbbd0c2ad4
Parents: 6077ca7
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 15:54:28 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 15:54:28 2016 -0800
----------------------------------------------------------------------
docs/newt/install/newt_linux.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ff2476a1/docs/newt/install/newt_linux.md
----------------------------------------------------------------------
diff --git a/docs/newt/install/newt_linux.md b/docs/newt/install/newt_linux.md
index 43f3170..f8147c4 100644
--- a/docs/newt/install/newt_linux.md
+++ b/docs/newt/install/newt_linux.md
@@ -19,7 +19,7 @@ If you want to build the *newt* tool from its source code, follow the following
#### 2. Install Go, the programming language
-* Go language environment dictates a directory structure. Known in Go parlanace as workspace, it must contain three sibling directories with the directory names src, pkg and bin, as explained below.
+* Go language environment dictates a directory structure. Known in Go parlance as a workspace, it must contain three sibling directories with the directory names src, pkg and bin, as explained below.
* src contains Go source files organized into packages (one package per directory),
[18/21] incubator-mynewt-site git commit: Fixed relative path to
primo blinky tutorial in port_bsp.md file
Posted by ad...@apache.org.
Fixed relative path to primo blinky tutorial in port_bsp.md file
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/c4f4b182
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/c4f4b182
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/c4f4b182
Branch: refs/heads/develop
Commit: c4f4b182c8be5e58e5a0d16e3498470446804df8
Parents: da24183
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 16:50:02 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 16:50:02 2016 -0800
----------------------------------------------------------------------
docs/os/core_os/porting/port_bsp.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/c4f4b182/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 638ecb9..4265c58 100644
--- a/docs/os/core_os/porting/port_bsp.md
+++ b/docs/os/core_os/porting/port_bsp.md
@@ -38,7 +38,7 @@ Create a newt target for your test project for the BSP. To learn how to create a
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.
-It is recommended that you use a simple project like [blinky](../tutorials/blinky_primo.md) to minimize the time
+It is recommended that you use a simple project like [blinky](../../tutorials/blinky_primo.md) to minimize the time
to get a working Mynewt system. For this document, we will assume the *target* is called *myboard_blinky*
and uses project *blinky*.
[20/21] incubator-mynewt-site git commit: Added skeleton for updated
bootloader
Posted by ad...@apache.org.
Added skeleton for updated bootloader
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/f18c78f1
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/f18c78f1
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/f18c78f1
Branch: refs/heads/develop
Commit: f18c78f19a2203078ae271f1dcd9d98c9bfab90e
Parents: b665dc7
Author: aditihilbert <ad...@runtime.io>
Authored: Mon Nov 14 15:28:29 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Mon Nov 14 15:28:29 2016 -0800
----------------------------------------------------------------------
docs/os/modules/bootloader/bootloader.md | 319 +++++---------------------
1 file changed, 56 insertions(+), 263 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/f18c78f1/docs/os/modules/bootloader/bootloader.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/bootloader.md b/docs/os/modules/bootloader/bootloader.md
index 6841875..3908e73 100644
--- a/docs/os/modules/bootloader/bootloader.md
+++ b/docs/os/modules/bootloader/bootloader.md
@@ -1,8 +1,14 @@
#Bootloader
-The bootutil library performs most of the functions of a boot loader. In
-particular, the piece that is missing is the final step of actually jumping to
-the main image. This last step should instead be implemented in an
+The "bootloader" is the code that loads the Mynewt OS image into memory and conducts some checks before allowing the OS to be run. The bootloader in the Apache Mynewt project verifies the cryptographic signature of the firmware image before running it. It maintains a detailed status log for each stage of the boot process. For verification of the authenticity of the OS image, it:
+
+* Calculates hash of the image.
+* Uses public key to uncover hash value from included signature.
+* Compares the calculated and uncovered hashes for a match.
+
+The "secure bootloader" should be placed in protected memory on a given microcontroller.
+
+The Mynewt code is structured so that the generic bootutil library performs most of the functions of a boot loader. The final step of actually jumping to the main image is kept out of the bootutil library. This last step should instead be implemented in an
architecture-specific project. Boot loader functionality is separated in this
manner for the following two reasons:
@@ -11,10 +17,6 @@ manner for the following two reasons:
2. By excluding the last boot step from the library, the rest of the code can
be tested in a sim environment.
-There is a boot loader project specific to the olimex_stm32-e407 devboard
-called *boot*. This project provides an example of how the bootutil library
-should be used.
-
###Limitations
The boot loader currently only supports images with the following
@@ -23,8 +25,6 @@ characteristics:
* Built to run from flash.
* Build to run from a fixed location (i.e., position-independent).
-These limitations will likely be addressed soon.
-
###Image Format
@@ -32,6 +32,7 @@ The following definitions describe the image header format.
```c
#define IMAGE_MAGIC 0x96f3b83c
+#define IMAGE_MAGIC_NONE 0xffffffff
struct image_version {
uint8_t iv_major;
@@ -43,22 +44,43 @@ struct image_version {
/** Image header. All fields are in little endian byte order. */
struct image_header {
uint32_t ih_magic;
- uint32_t ih_crc32; /* Covers remainder of header and all of image body. */
- uint32_t ih_hdr_size;
+ uint16_t ih_tlv_size; /* Trailing TLVs */
+ uint8_t ih_key_id;
+ uint8_t _pad1;
+ uint16_t ih_hdr_size;
+ uint16_t _pad2;
uint32_t ih_img_size; /* Does not include header. */
uint32_t ih_flags;
struct image_version ih_ver;
+ uint32_t _pad3;
};
```
-At this time, no flags have been defined.
-
The `ih_hdr_size` field indicates the length of the header, and therefore the
offset of the image itself. This field provides for backwards compatibility in
case of changes to the format of the image header.
-When security is added, security data will likely go in a footer at the end of
-the image.
+The following are the image header flags available.
+
+```c
+#define IMAGE_F_PIC 0x00000001
+#define IMAGE_F_SHA256 0x00000002 /* Image contains hash TLV */
+#define IMAGE_F_PKCS15_RSA2048_SHA256 0x00000004 /* PKCS15 w/RSA and SHA */
+#define IMAGE_F_ECDSA224_SHA256 0x00000008 /* ECDSA256 over SHA256 */
+#define IMAGE_F_NON_BOOTABLE 0x00000010
+#define IMAGE_HEADER_SIZE 32
+```
+
+Security data gets added as a footer at the end of the image.
+
+```c
+/*
+ * Image trailer TLV types.
+ */
+#define IMAGE_TLV_SHA256 1 /* SHA256 of image hdr and body */
+#define IMAGE_TLV_RSA2048 2 /* RSA2048 of hash output */
+#define IMAGE_TLV_ECDSA224 3 /* ECDSA of hash output */
+```
###Flash Areas
@@ -89,31 +111,7 @@ size.
###Boot Vector
-Bootutil determines which image it should boot into by reading the contents of
-the boot vector. The boot vector comprises the following files in the flash
-file system:
-
-```c
-#define BOOT_PATH_MAIN "/boot/main"
-#define BOOT_PATH_TEST "/boot/test"
-```
-
-Each file, if present, must contain a 64-bit image version. This version is
-simply a "binary dump" of an `image_version` struct. The test file is used to
-indicate that an image is being "tested out," and should only be booted once.
-The main file indicates the "last known good" image which should be booted
-repeatedly.
-
-The boot loader uses the following procedure to determine which image to boot:
-1. If the test file is present and contains a valid image version:
- * Delete the test file.
- * Boot into the specified image.
-2. Else if the main file is present and contains a valid image version:
- * Boot into the specified image.
-3. Else:
- * Just boot into whichever image is in the primary slot. If there is no
-image in the primary slot, boot into the image in the secondary slot.
If a vector file contains a version which doesn't correspond to an image
actually present in flash, the boot loader deletes the file and procedes as
@@ -122,101 +120,31 @@ though the file was not present.
###Boot Status
-The boot status file allows the boot loader to recover in case it was reset
+The boot status record allows the boot loader to recover in case it was reset
while in the middle of an image swap operation. Image swapping is discussed
-later in this document; the structure of the boot status file is presented
-here. To ensure recovery is always possible, bootutil updates the status file
-at each step throughout the image swap process. The boot status is contained
-in the following file:
+later in this document.
-```c
-#define BOOT_PATH_STATUS "/boot/status"
-```
-
-The contents of the boot status file are defined below.
```c
-struct boot_status {
- uint32_t bs_img1_length;
- uint32_t bs_img2_length;
- /* Followed by sequence of boot status entries; file size indicates number
- * of entries.
+struct boot_status_table {
+ /**
+ * For each field, a value of 0 means "any".
*/
+ uint8_t bst_magic_slot0;
+ uint8_t bst_magic_scratch;
+ uint8_t bst_copy_done_slot0;
+ uint8_t bst_status_source;
};
-
-struct boot_status_entry {
- uint8_t bse_image_num;
- uint8_t bse_part_num;
-};
-
-#define BOOT_IMAGE_NUM_NONE 0xff
```
-There is a separate boot status entry for each flash area used by the boot
-loader (i.e., each area in the two slots, plus one for the scratch area). The
-entries are placed in the file in the same order as their corresponding areas
-in flash. Each entry indicates which image part is resident in the
-corresponding flash area. If a flash area does not contain any image data, its
-corresponding entry will have a `bse_image_num` value of `BOOT_IMAGE_NUM_NONE`.
-
-Consider the following example:
-
-Five flash areas are dedicated to image data, as follows:
-
-| Area | Slot | Value |
-|------|------|-------|
-| Area 0 | slot 0 | 0/1 |
-| Area 1 | slot 0 | 1/1 |
-| Area 2 | slot 1 | 0/1 |
-| Area 3 | slot 1 | 1/1 |
-| Area 4 | scratch ||
-
-The following array of boot status entries is read from the status file:
```c
- [0] = {
- .bse_image_num = 0,
- .bse_part_num = 0,
- },
- [1] = {
- .bse_image_num = 0,
- .bse_part_num = 1,
- },
- [2] = {
- .bse_image_num = 1,
- .bse_part_num = 0,
- },
- [3] = {
- .bse_image_num = 1,
- .bse_part_num = 1,
- },
- [4] = {
- .bse_image_num = 0xff,
- .bse_part_num = 0xff,
- },
+struct boot_status {
+ uint32_t idx; /* Which area we're operating on */
+ uint8_t state; /* Which part of the swapping process are we at */
+};
```
-
-This status file indicates the following image placement:
-
-| Area | Image | Part |
-|------|------|-------|
-| Area 0 | image 0 | part 0 |
-| Area 1 | image 0 | part 1 |
-| Area 2 | image 1 | part 0 |
-| Area 3 | image 1 | part 1 |
-| Scratch area | empty ||
-
-Images don't have an instrinsic image number. When a swap operation is
-started, the image initially in the primary slot is labelled `image 0`, and the
-image in the secondary slot is labelled `image 1`. All swap operations end with
-`image 1` in the primary slot, and `image 0` in the secondary slot.
-
-The boot status header containing the image sizes is necessary so that `bootutil`
-can determine how many flash areas each image occupies. Without this
-information, `bootutil` would need to swap the full contents of the image slots,
-including useless data after the end of each image.
-The status file is always deleted upon successful boot.
###Image Swapping
@@ -228,33 +156,10 @@ later. Furthermore, both images need to be recoverable if the boot loader
resets in the middle of the process. The two images are swapped according to
the following procedure:
-1. Determine how many flash areas are required to hold the desired image.
-2. For each required area in the primary slot ("destination area"):
- a. Identify the flash area in the secondary slot which contains the
- required image data ("source area").
- b. Erase scratch area.
- c. Copy destination area to scratch area.
- d. Write updated boot status to the file system.
- e. Erase destination area.
- f. Copy source area to destination area.
- g. Write updated boot status to the file system.
- h. Erase source area.
- i. Copy scratch area to source area.
- j. Write updated boot status to the file system.
-3. Determine how many flash areas are required to hold image 1.
-4. For each required area in the secondary slot ("destination area"):
- a. If the destination area already contains the required image data,
- advance to the next image part.
- b. Else, identify the flash area in the primary slot which contains the
- required image data ("source area").
- c. Repeat steps b through j from step 2.
-
-This procedure ensures that the contents of the boot status file are always
-accurate, so the boot loader can recover after an unexpected reset.
-
-Step 4 is necessary in case the two images do not occupy the same number of
-flash areas.
+###Verifying integrity of image
+
+
###Reset Recovery
@@ -277,102 +182,16 @@ it had just been started.
###API
-The API consists of a single function:
-
-```c
-int boot_go(const struct boot_req *req, struct boot_rsp *rsp)
-```
-
-The request and response structures are defined as follows:
-
-```c
-struct boot_req {
-
- struct nffs_area_desc *br_area_descs;
-
- uint8_t *br_image_areas;
-
- uint8_t *br_slot_areas;
-
- uint8_t br_num_image_areas;
-
-
- uint8_t br_scratch_area_idx;
-};
-```
-
-```c
-struct boot_rsp {
- const struct image_header *br_hdr;
-
- uint32_t br_image_addr;
-};
-```
###Example
-In this example, each image slot consists of three flash areas.
-
-```c
-/** Internal flash layout. */
-static struct nffs_area_desc boot_area_descs[] = {
- [0] = { 0x08000000, 16 * 1024 },
- [1] = { 0x08004000, 16 * 1024 },
- [2] = { 0x08008000, 16 * 1024 },
- [3] = { 0x0800c000, 16 * 1024 },
- [4] = { 0x08010000, 64 * 1024 },
- [5] = { 0x08020000, 128 * 1024 }, /* Image data; 0,0. */
- [6] = { 0x08040000, 128 * 1024 }, /* Image data; 0,1. */
- [7] = { 0x08060000, 128 * 1024 }, /* Image data; 0,2. */
- [8] = { 0x08080000, 128 * 1024 }, /* Image data; 1,0. */
- [9] = { 0x080a0000, 128 * 1024 }, /* Image data; 1,1. */
- [10] = { 0x080c0000, 128 * 1024 }, /* Image data; 1,2. */
- [11] = { 0x080e0000, 128 * 1024 }, /* Image scratch area. */
- { 0, 0 },
-};
-
-/** Contains indices of the areas which can contain image data. */
-static uint8_t boot_img_areas[] = {
- 5, 6, 7, 8, 9, 10, 11,
-};
-
-/** Areas representing the beginning of image slots. */
-static uint8_t boot_slot_areas[] = {
- 5, 8,
-};
-
-#define BOOT_NUM_IMG_AREAS \
- ((int)(sizeof boot_img_areas / sizeof boot_img_areas[0]))
-
-/** The scratch area to use during an image swap operation. */
-#define BOOT_AREA_IDX_SCRATCH 11
-
-int
-main(void)
-{
- struct boot_rsp rsp;
- int rc;
- const struct boot_req req = {
- .br_area_descs = boot_area_descs,
- .br_image_areas = boot_img_areas,
- .br_slot_areas = boot_slot_areas,
- .br_num_image_areas = BOOT_NUM_IMG_AREAS,
- .br_scratch_area_idx = BOOT_AREA_IDX_SCRATCH,
- };
-
- rc = boot_go(&req, &rsp);
- assert(rc == 0);
+###Dependencies
- /* Perform jump to address indicated by the response object. */
+The bootloader depends on the following OS kernel functions:
- return 0;
-}
-```
-###Dependencies
-* `nffs` (for the boot vector and boot status files).
-* `os` (for `os_malloc()` and `os_free()`).
+The bootloader does not depend on any flash file system.
###List of Functions
@@ -381,29 +200,3 @@ main(void)
The functions available in bootloader are:
-* [boot_build_status](boot_build_status.md)
-* [boot_build_status_one](boot_build_status_one.md)
-* [boot_clear_status](boot_clear_status.md)
-* [boot_copy_area](boot_copy_area.md)
-* [boot_copy_image](boot_copy_image.md)
-* [boot_erase_area](boot_erase_area.md)
-* [boot_fill_slot](boot_fill_slot.md)
-* [boot_find_image_area_idx](boot_find_image_area_idx.md)
-* [boot_find_image_part](boot_find_image_part.md)
-* [boot_find_image_slot](boot_find_image_slot.md)
-* [boot_go](boot_go.md)
-* [boot_init_flash](boot_init_flash.md)
-* [boot_move_area](boot_move_area.md)
-* [boot_read_image_header](boot_read_image_header.md)
-* [boot_read_image_headers](boot_read_image_headers.md)
-* [boot_read_status](boot_read_status.md)
-* [boot_select_image_slot](boot_select_image_slot.md)
-* [boot_slot_addr](boot_slot_addr.md)
-* [boot_slot_to_area_idx](boot_slot_to_area_idx.md)
-* [boot_swap_areas](boot_swap_areas.md)
-* [boot_vect_delete_main](boot_vect_delete_main.md)
-* [boot_vect_delete_test](boot_vect_delete_test.md)
-* [boot_vect_read_main](boot_vect_read_main.md)
-* [boot_vect_read_one](boot_vect_read_one.md)
-* [boot_vect_read_test](boot_vect_read_test.md)
-* [boot_write_status](boot_write_status.md)
[13/21] incubator-mynewt-site git commit: Merge branch 'patch-3' of
https://github.com/sam-bristow/incubator-mynewt-site into develop
Posted by ad...@apache.org.
Merge branch 'patch-3' of https://github.com/sam-bristow/incubator-mynewt-site into develop
This closes #123
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/9aae5133
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/9aae5133
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/9aae5133
Branch: refs/heads/develop
Commit: 9aae513392122cfa5e322397e97361a2c9c7c18f
Parents: 1aec628 05083e7
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 15:50:21 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 15:50:21 2016 -0800
----------------------------------------------------------------------
docs/faq/how_to_edit_docs.md | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/9aae5133/docs/faq/how_to_edit_docs.md
----------------------------------------------------------------------
[11/21] incubator-mynewt-site git commit: Updated Arduino Tutorial
Posted by ad...@apache.org.
Updated Arduino Tutorial
Lots of changes for this tutorial.
Project: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/commit/ed14270c
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/ed14270c
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/ed14270c
Branch: refs/heads/develop
Commit: ed14270c188d47edd17667929da707cb3aa64fec
Parents: 9aff0ae
Author: David G. Simmons <sa...@mac.com>
Authored: Fri Nov 11 14:08:47 2016 -0500
Committer: David G. Simmons <sa...@mac.com>
Committed: Fri Nov 11 14:08:47 2016 -0500
----------------------------------------------------------------------
docs/os/tutorials/arduino_zero.md | 107 +++++++++++++++++++++++++++------
1 file changed, 88 insertions(+), 19 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/ed14270c/docs/os/tutorials/arduino_zero.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/arduino_zero.md b/docs/os/tutorials/arduino_zero.md
index 6f25374..d37b280 100644
--- a/docs/os/tutorials/arduino_zero.md
+++ b/docs/os/tutorials/arduino_zero.md
@@ -97,22 +97,13 @@ To generate the bootloader target, you need to specify the following options. Th
```no-highlight
$ newt target create arduino_boot
$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
+Target targets/arduino_boot successfully created
$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot
+Target targets/arduino_boot successfully set target.app to @apache-mynewt-core/apps/boot
$ newt target set arduino_boot build_profile=optimized
-```
-
-<br>
-
-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
-```
-
-If you have an Arduino Zero, you have to set the following instead:
-
-```
-$ newt target set arduino_boot features=arduino_zero
+Target targets/arduino_boot successfully set target.build_profile to optimized
+$ newt target set arduino_boot syscfg=BSP_ARDUINO_ZERO_PRO=1
+Target targets/arduino_boot successfully set target.syscfg to BSP_ARDUINO_ZERO_PRO=1
```
<br>
@@ -132,6 +123,29 @@ These commands do a few things:
<br>
+If you'd rather, you can also take care of that last part by editing the `syscfg.yml` file
+for the target to set options -- at least one that is *required*.
+Look in the directory for the target, as defined by the target (in this case `targets/arduino_boot`)
+and edit the syscfg.yml file. It should look like this when you're done:
+
+```no-highlight
+### Package: targets/arduino_boot
+
+syscfg.vals:
+ BSP_ARDUINO_ZERO_PRO: 1
+
+
+```
+
+If you have an Arduino Zero Pro or M0 Pro, you'll want `BSP_ARDUINO_ZEZRO_PRO: 1`. If you have the Arduino Zero,
+you'll want `BSP_ARDUINO_ZERO: 1` instead.
+
+For more information on setting options, see the section on [Concepts](../get_started/vocabulary.md).
+
+For now, we're not going to set any more options or enable any more features of Mynewt OS.
+
+<br>
+
### Build your bootloader
Once you've configured the bootloader target, the next step is to build the bootloader for your Arduino. You can do this by using the ```newt build``` command:
@@ -159,7 +173,8 @@ board.
### 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```:
+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!
@@ -227,6 +242,55 @@ Execute the command to download the bootloader.
If the newt tool finishes without error, that means the bootloader has been
successfully loaded onto the target.
+If, on the other hand, you get errors like the following:
+
+```
+$ newt load arduino_boot -v
+Loading bootloader
+Error: Downloading ~/dev/arduino_zero/bin/targets/arduino_boot/app/apps/boot/boot.elf.bin to 0x0
+Open On-Chip Debugger 0.9.0 (2015-11-15-05:39)
+Licensed under GNU GPL v2
+For bug reports, read
+ http://openocd.org/doc/doxygen/bugs.html
+Info : only one transport option; autoselect 'swd'
+adapter speed: 500 kHz
+adapter_nsrst_delay: 100
+cortex_m reset_config sysresetreq
+Info : CMSIS-DAP: SWD Supported
+Info : CMSIS-DAP: JTAG Supported
+Info : CMSIS-DAP: Interface Initialised (SWD)
+Info : CMSIS-DAP: FW Version = 01.1F.0118
+Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
+Info : CMSIS-DAP: Interface ready
+Info : clock speed 500 kHz
+Info : SWD IDCODE 0x0bc11477
+Info : at91samd21g18.cpu: hardware has 4 breakpoints, 2 watchpoints
+Error: Target not halted
+```
+
+Then you'll need to erase your board first before downloading the `arduino_boot` application. Here's how you do that using gdb,
+the GNU Debugger.
+
+```gdb
+$ newt debug arduino_blinky
+
+(gdb) mon at91samd chip-erase
+chip erased
+chip erased
+(gdb) x/32wx 0
+0x0: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
+0x10: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
+0x20: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
+0x30: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
+0x40: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
+0x50: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
+0x60: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
+0x70: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
+(gdb) q
+```
+
+Once the chip is erased, go back and download the `arduino_boot` image to the board as above.
+
<br>
<font color="#FF0000"> Reminder if you are using Docker: </font> When working with actual hardware, remember that each board has an ID. If you swap boards and do not refresh the USB Device Filter on the VirtualBox UI, the ID might be stale and the Docker instance may not be able to see the board correctly. For example, you may see an error message like `Error: unable to find CMSIS-DAP device` when you try to load or run an image on the board. In that case, you need to click on the USB link in VirtualBox UI, remove the existing USB Device Filter (e.g. "Atmel Corp. EDBG CMSIS-DAP[0101]") by clicking on the "Removes selected USB filter" button, and add a new filter by clicking on the "Adds new USB filter" button.
@@ -297,17 +361,22 @@ 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
-debugger and restart the board. The image you programmed will come and run on the Arduino on next boot!
+debugger and restart the board. The image you programmed will come up and run on
+the Arduino on the next boot!
<br>
### Watch the LED blink
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.
+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.
+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.
-If you see anything missing or want to send us feedback, please do so by signing up for appropriate mailing lists on our [Community Page](../../community.md).
+If you see anything missing or want to send us feedback, please do so by signing up for
+appropriate mailing lists on our [Community Page](../../community.md).
Keep on hacking and blinking!
[08/21] incubator-mynewt-site git commit: Normalizing the modules
Posted by ad...@apache.org.
Normalizing the modules
More editing, formatting and normalizing of documents.
Some just splitting lines so they fit in an editor.
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/79707346
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/79707346
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/79707346
Branch: refs/heads/develop
Commit: 7970734600fc3cd522ee6431bb49f630ffaf239f
Parents: aac53ed
Author: David G. Simmons <sa...@mac.com>
Authored: Thu Nov 3 15:20:07 2016 -0400
Committer: David G. Simmons <sa...@mac.com>
Committed: Thu Nov 3 15:20:07 2016 -0400
----------------------------------------------------------------------
docs/os/modules/baselibc.md | 21 ++-
docs/os/modules/console/console.md | 37 +++-
.../os/modules/console/console_blocking_mode.md | 12 +-
docs/os/modules/console/console_echo.md | 13 +-
docs/os/modules/console/console_init.md | 18 +-
docs/os/modules/console/console_is_init.md | 8 +-
docs/os/modules/console/console_printf.md | 22 ++-
docs/os/modules/console/console_read.md | 18 +-
docs/os/modules/console/console_write.md | 11 +-
docs/os/modules/shell/shell.md | 30 ++--
docs/os/modules/shell/shell_cmd_register.md | 13 +-
.../modules/shell/shell_nlip_input_register.md | 15 +-
docs/os/modules/shell/shell_nlip_output.md | 6 +-
docs/os/modules/shell/shell_task_init.md | 18 +-
docs/os/modules/split/split.md | 173 +++++++++++++------
15 files changed, 271 insertions(+), 144 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/baselibc.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/baselibc.md b/docs/os/modules/baselibc.md
index fe650ac..377eca8 100644
--- a/docs/os/modules/baselibc.md
+++ b/docs/os/modules/baselibc.md
@@ -1,6 +1,8 @@
# Baselibc
-Baselibc is a very simple libc for embedded systems geared primarily for 32-bit microcontrollers in the 10-100kB memory range. The library of basic system calls and facilities compiles to less than 5kB total on Cortex-M3, and much less if some functions aren't used.
+Baselibc is a very simple libc for embedded systems geared primarily for 32-bit microcontrollers in the
+10-100kB memory range. The library of basic system calls and facilities compiles to less than 5kB total
+on Cortex-M3, and much less if some functions aren't used.
The code is based on klibc and tinyprintf modules, and licensed under the BSD license.
@@ -8,11 +10,17 @@ Baselibc comes from https://github.com/PetteriAimonen/Baselibc.git
###Description
-Mynewt OS can utilize libc which comes with compiler (e.g. newlib bundled with some binary distributions of arm-none-eabi-gcc). However, you may choose to replace the libc with baselibc for a reduced image size. Baselibc optimizes for size rather than performance, which is usually a more important goal in embedded environments.
+Mynewt OS can utilize libc which comes with the compiler (e.g. newlib bundled with some binary
+distributions of arm-none-eabi-gcc). However, you may choose to replace the libc with baselibc
+for a reduced image size. Baselibc optimizes for size rather than performance, which is usually
+a more important goal in embedded environments.
###How to switch to baselibc
-In order to switch from using libc to using baselibc you have to add the baselibc pkg as a dependency in the project pkg. Specifying this dependency ensures that the linker first looks for the functions in baselibc before falling back to libc while creating the executable. For example, project `boot` uses baselibc. Its project description file `boot.yml` looks like the following:
+In order to switch from using libc to using baselibc you have to add the baselibc pkg as a dependency
+in the project pkg. Specifying this dependency ensures that the linker first looks for the functions
+in baselibc before falling back to libc while creating the executable. For example, project `boot`
+uses baselibc. Its project description file `boot.yml` looks like the following:
```no-highlight
project.name: boot
@@ -24,12 +32,13 @@ In order to switch from using libc to using baselibc you have to add the baselib
- libs/console/stub
- libs/util
- libs/baselibc
- ```
+```
###List of Functions
-Documentation for libc functions is available from multiple places. One example are the on-line manual pages at [https://www.freebsd.org/cgi/man.cgi](#https://www.freebsd.org/cgi/man.cgi).
+Documentation for libc functions is available from multiple places. One example is the on-line manual
+pages at [https://www.freebsd.org/cgi/man.cgi](#https://www.freebsd.org/cgi/man.cgi).
-baselibc supports most libc functionality; malloc(), printf-family, string handling, and conversion routines.
+baselibc supports most libc functionality; `malloc()`, printf-family, string handling, and conversion routines.
There is some functionality which is not available, e.g. support for floating point numbers, and limited support for 'long long'.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/console/console.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console.md b/docs/os/modules/console/console.md
index 53d195b..9d5b738 100644
--- a/docs/os/modules/console/console.md
+++ b/docs/os/modules/console/console.md
@@ -1,7 +1,10 @@
#Console
-The console is an operating system window where users interact with system programs of the operating system or a console application by entering text input (typically from a keyboard) and reading text output (typically on the computer terminal or monitor). The text written on the console brings some information and is a sequence of characters sent by the OS or programs running on the OS.
+The console is an operating system window where users interact with system programs of the operating system
+or a console application by entering text input (typically from a keyboard) and reading text output
+(typically on the computer terminal or monitor). The text written on the console brings some information
+and is a sequence of characters sent by the OS or programs running on the OS.
Support is currently available for console access via the serial port on the hardware board.
@@ -13,8 +16,10 @@ In the Mynewt OS, the console library comes in two versions:
* full - containing the full implementation
* stub - containing stubs for the API
-Both of these have `pkg.yml` file which states that they provide the `console` API. If a pkg uses this API, it should list `console` as a requirement.
-For example, the shell pkg is defined by the following pkg.yml file:
+Both of these have a `pkg.yml` file which states that they provide the `console` API. If a pkg uses
+this API, it should list `console` as a requirement. For example, the shell pkg is defined by the
+following pkg.yml file:
+
```no-highlight
pkg.name: libs/shell
pkg.vers: 0.1
@@ -26,11 +31,19 @@ For example, the shell pkg is defined by the following pkg.yml file:
pkg.identities:
- SHELL
```
+
The project .yml file decides which version of the console pkg should be included.
-If project requires the full console capability it lists dependency `libs/console/full` in its pkg.yml file. On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to) but may have a dependency on a pkg that has console capability. In that case you would use a console stub.
+If a project requires the full console capability it lists dependency `libs/console/full` in its pkg.yml
+file. On the other hand, a project may not have a physical console (e.g. a UART port to connect a terminal to)
+but may have a dependency on a pkg that has console capability. In that case you would use a console stub.
+
+Another example would be the bootloader project where we want to keep the size of the image small. It includes
+the `libs/os` pkg that can print out messages on a console (e.g. if there is a hard fault) and the `libs/util`
+pkg that uses the full console (but only if SHELL is present to provide a CLI). However, we do not want to use
+any console I/O capability in this particular bootloader project to keep the size small. We simply use the console
+stub instead, and the pkg.yml file for the project boot pkg looks like the following:
-Another example would be the bootloader project where we want to keep the size of the image small. It includes the `libs/os` pkg that can print out messages on a console (e.g. if there is a hard fault) and the `libs/util` pkg that uses full console (but only if SHELL is present to provide a CLI). However, we do not want to use any console I/O capability in this particular bootloader project to keep the size small. We simply use the console stub instead, and the pkg.yml file for the project boot pkg looks like the following:
```no-highlight
project.name: boot
project.identities: bootloader
@@ -42,10 +55,18 @@ Another example would be the bootloader project where we want to keep the size o
- libs/util
```
-Console has 2 modes for transmit; *blocking mode* and *non-blocking mode*. Usually the *non-blocking mode* is the active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added based on these interrupts.
-*Blocking mode* is used when we don't want TX completion interrupts. It is used when system crashes, and we still want to output info related to that crash.
+Console has 2 modes for transmit; *blocking mode* and *non-blocking mode*. Usually the *non-blocking mode* is the
+active one; the output buffer is drained by getting TX completion interrupts from hardware, and more data is added
+based on these interrupts.
+
+*Blocking mode* is used when we don't want TX completion interrupts. It is used when system crashes, and we still
+want to output info related to that crash.
+
+Console, by default, echoes everything it receives back. Terminal programs expect this, and is a way for the user to
+know that the console is connected and responsive. Whether echoing happens or not can be controlled programmatically.
-Console, by default, echoes everything it receives back. Terminal programs expect this, and is a way for the user to know that the console is connected and responsive. Whether echoing happens or not can be controlled programmatically.
+The Console also has a prompt that is configurable. It is off by default but can be turned on programatically. The
+prompt cahracter can also be changed by the user.
###Data structures
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/console/console_blocking_mode.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_blocking_mode.md b/docs/os/modules/console/console_blocking_mode.md
index ea1c7d7..01568ea 100644
--- a/docs/os/modules/console/console_blocking_mode.md
+++ b/docs/os/modules/console/console_blocking_mode.md
@@ -1,10 +1,12 @@
## <font color="#F2853F" style="font-size:24pt"> console_blocking_mode </font>
-```no-highlight
- void
- console_blocking_mode(void)
+```c
+void console_blocking_mode(void)
```
- Calls the `console_blocking_tx` function to flush the buffered console output (transmit) queue. The function `OS_ENTER_CRITICAL()` is called to disable interrupts and `OS_EXIT_CRITICAL()` is called to enable interrupts back again once the buffer is flushed.
+
+Calls the `console_blocking_tx` function to flush the buffered console output (transmit) queue.
+The function `OS_ENTER_CRITICAL()` is called to disable interrupts and `OS_EXIT_CRITICAL()`
+is called to enable interrupts back again once the buffer is flushed.
#### Arguments
@@ -20,7 +22,7 @@ N/A
Here is an example of calling `console_blocking_mode` and printing crash information from an assert to help debug.
-```no-highlight
+```c
void
_assert_func(const char *file, int line, const char *func, const char *e)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/console/console_echo.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_echo.md b/docs/os/modules/console/console_echo.md
index 6d58c67..086307c 100644
--- a/docs/os/modules/console/console_echo.md
+++ b/docs/os/modules/console/console_echo.md
@@ -1,7 +1,7 @@
## <font color="#F2853F" style="font-size:24pt"> console_echo </font>
-```no-highlight
- void console_echo(int on)
+```c
+void console_echo(int on)
```
Controls whether echoing is on or off for the console. When echoing is on, all characters received are transmitted back.
@@ -10,7 +10,7 @@ Controls whether echoing is on or off for the console. When echoing is on, all c
| Arguments | Description |
|-----------|-------------|
-| on | 1 turns on echoing, 0 turns it off |
+| `on` | 1 turns on echoing, 0 turns it off |
#### Returned values
@@ -19,11 +19,14 @@ None
#### Notes
+None
+
#### Example
-Here is an example where newtmgr protocol handler is controlling whether echoing is on or off. Newtmgr, the tool, turns echoing off when it's transmitting large chunks of data to target board.
+Here is an example where newtmgr protocol handler is controlling whether echoing is on or off. [Newtmgr](../../../newtmgr/overview.md)
+turns echoing off when it is transmitting large chunks of data to a target board.
-```no-highlight
+```c
static int
nmgr_def_console_echo(struct nmgr_jbuf *njb)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/console/console_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_init.md b/docs/os/modules/console/console_init.md
index d56b2b6..9438208 100644
--- a/docs/os/modules/console/console_init.md
+++ b/docs/os/modules/console/console_init.md
@@ -1,19 +1,21 @@
## <font color="#F2853F" style="font-size:24pt"> console_init </font>
-```no-highlight
- int
- console_init(console_rx_cb rx_cb)
+```c
+int console_init(console_rx_cb rx_cb)
```
+
+Initializes the console receive buffer and calls hal funtions `hal_uart_init_cbs` and `hal_uart_config` to
+initialize the serial port connection and configure it (e.g. baud rate, flow control etc.)
- Initializes console receive buffer and calls hal funtions `hal_uart_init_cbs` and `hal_uart_config` to initialize serial port connection and configure it (e.g. baud rate, flow control etc.)
-
-Caller registers a function pointer of `type void (*console_rx_cb)(int full_line)`. This function will be called when console receives either a) full line of data or b) when RX buffer in console is full. Note that this function is most likely getting called from interrupt context.
+Caller registers a function pointer of `type void (*console_rx_cb)(int full_line)`. This function will be
+called when the console receives either a) full line of data or b) when RX buffer in console is full.
+Note that this function is most likely getting called from an interrupt context.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| rx_cb | Function pointer, which gets called input is received. |
+| `rx_cb` | Function pointer, which gets called when input is received. |
#### Returned values
@@ -22,7 +24,7 @@ Non-zero if HAL UART function calls fail.
#### Example
-```no-highlight
+```c
int
main(int argc, char **argv)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/console/console_is_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_is_init.md b/docs/os/modules/console/console_is_init.md
index 3ec0698..b781b6d 100644
--- a/docs/os/modules/console/console_is_init.md
+++ b/docs/os/modules/console/console_is_init.md
@@ -1,10 +1,10 @@
## <font color="#F2853F" style="font-size:24pt"> console_is_init </font>
-```no-highlight
- int console_is_init(void)
+```c
+int console_is_init(void)
```
- Returns whether console has been initialized or not. I.e. whether `console_init()` has been called yet.
+Returns whether console has been initialized or not. I.e. whether `console_init()` has been called yet.
#### Arguments
@@ -17,7 +17,7 @@ Returns 1 if console has been initialized. 0 if not.
#### Example
-```no-highlight
+```c
static int
log_console_append(struct log *log, void *buf, int len)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/console/console_printf.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_printf.md b/docs/os/modules/console/console_printf.md
index 8eb2280..0cda207 100644
--- a/docs/os/modules/console/console_printf.md
+++ b/docs/os/modules/console/console_printf.md
@@ -1,19 +1,21 @@
## <font color="F2853F" style="font-size:24pt"> console_printf</font>
-```no-highlight
- void
- console_printf(const char *fmt, ...)
+```c
+void console_printf(const char *fmt, ...)
```
-Writes a formatted message instead of raw output to the console. It first composes a C string containing text specified as arguments to the function or containing the elements in the variable argument list passed to it using snprintf or vsnprintf, respectively. It then uses function `console_write` to output the formatted data (messages) on the console.
+Writes a formatted message instead of raw output to the console. It first composes a C string containing
+the text specified as arguments to the function or containing the elements in the variable argument list
+passed to it using `snprintf` or `vsnprintf`, respectively. It then uses the function `console_write` to
+output the formatted data (messages) on the console.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| fmt | Pointer to C string that contains a format string that follows the same specifications as format in printf. The string is printed to console. |
-| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. va_list is a special type defined in <cstdarg> in stdarg.h. |
+| `fmt` | Pointer to C string that contains a format string that follows the same specifications as format in printf. The string is printed to console. |
+| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. `va_list` is a special type defined in <cstdarg> in `stdarg.h`. |
#### Returned values
@@ -21,12 +23,14 @@ None
#### Notes
-While `console_printf`, with its well understood formatting options in C, is more convenient and easy on the eyes than the raw output of `console_write`, the associated code size is considerably larger.
+While `console_printf`, with its well understood formatting options in C, is more convenient and easy on the
+eyes than the raw output of `console_write`, the associated code size is considerably larger.
#### Example
+
Example #1:
-```no-highlight
+```c
char adv_data_buf[32];
void
@@ -40,7 +44,7 @@ task()
Example #2:
-```no-highlight
+```c
struct exception_frame {
uint32_t r0;
uint32_t r1;
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/console/console_read.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_read.md b/docs/os/modules/console/console_read.md
index 1e6600d..8ddc3d8 100644
--- a/docs/os/modules/console/console_read.md
+++ b/docs/os/modules/console/console_read.md
@@ -1,18 +1,18 @@
## <font color="#F2853F" style="font-size:24pt"> console_read </font>
-```no-highlight
- int
- console_read(char *str, int cnt)
+```c
+int console_read(char *str, int cnt)
```
-Copies up to *cnt* bytes of received data to buffer pointed by *str*. Function tries to break the input into separate lines; once it encounters a newline character, it replaces that with end-of-string and returns.
+Copies up to `cnt` bytes of received data to buffer pointed by `str`. Function tries to break the input into
+separate lines; once it encounters a newline character, it replaces that with end-of-string and returns.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| str | Buffer where data is copied to. |
-| cnt | Maximum number of characters to copy. |
+| `str` | Buffer where data is copied to. |
+| `cnt` | Maximum number of characters to copy. |
#### Returned values
@@ -22,7 +22,7 @@ available, or if the first received character was '\n'.
#### Example
-```no-highlight
+```c
void
task1_loop(void *arg)
{
@@ -39,4 +39,8 @@ task1_loop(void *arg)
if (!strncmp(rx_msg, "reset", rx_len)) {
assert(0);
}
+ }
+ }
+ }
+}
```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/console/console_write.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console_write.md b/docs/os/modules/console/console_write.md
index 3d38529..51f73aa 100644
--- a/docs/os/modules/console/console_write.md
+++ b/docs/os/modules/console/console_write.md
@@ -1,8 +1,7 @@
## <font color="#F2853F" style="font-size:24pt"> console_write </font>
-```no-highlight
- void
- console_write(char *str, int cnt)
+```c
+void console_write(char *str, int cnt)
```
Queues characters to console display over serial port.
@@ -10,8 +9,8 @@ Queues characters to console display over serial port.
| Arguments | Description |
|-----------|-------------|
-| *str | pointer to the character or packet to be transmitted |
-| cnt | number of characters in *str* |
+| `*str` | pointer to the character or packet to be transmitted |
+| `cnt` | number of characters in `str` |
#### Returned values
@@ -22,7 +21,7 @@ N/A
Here is an example of the function being used in an echo command with a newline at the end.
-```no-highlight
+```c
static int
shell_echo_cmd(int argc, char **argv)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/shell/shell.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell.md b/docs/os/modules/shell/shell.md
index d3b50f5..208f9fb 100644
--- a/docs/os/modules/shell/shell.md
+++ b/docs/os/modules/shell/shell.md
@@ -1,16 +1,20 @@
# Shell
-The shell is package sitting on top of console, handling 2 jobs: processing console input and implementing newtmgr line protocol over serial line. Shell runs on its own task.
+The shell is package sitting on top of console, handling 2 jobs: processing console input and implementing
+[newtmgr](../../../newtmgr/overview.md) line protocol over serial line. Shell runs in its own task.
###Description
-* Shell's first job is directing incoming commands to other subsystems. It parses the incoming character string, and splits it into tokens. Then it looks for the subsystem to handle this command based on the first token of input.
+* Shell's first job is directing incoming commands to other subsystems. It parses the incoming character string
+and splits it into tokens. Then it looks for the subsystem to handle this command based on the first token of input.
- Subsystems register their command handlers using `shell_cmd_register()`. When shell calls the command handler, it passes the other tokens as arguments.
+ * Subsystems register their command handlers using `shell_cmd_register()`. When shell calls the command handler, it passes the other tokens as arguments.
- A few commands are currently available in the shell - `tasks`, `log`, and `stat stat`. A $ prompt sign will be coming soon!
+ * A few commands are currently available in the shell - `tasks`, `log`, `echo`, `date` and `prompt`.
-* Shell's second job is doing framing, encoding and decoding newtmgr protocol when it's carried over the console. Protocol handler (libs/newtmgr) registers itself using `shell_nlip_input_register()`, and shell calls the registered handler for every frame. Outgoing frames for the protocol are sent using `shell_nlip_output()`.
+* Shell's second job is doing framing, encoding and decoding newtmgr protocol when it's carried over the console.
+Protocol handler (libs/newtmgr) registers itself using `shell_nlip_input_register()`, and shell calls the registered
+handler for every frame. Outgoing frames for the protocol are sent using `shell_nlip_output()`.
<br>
@@ -81,8 +85,12 @@ tasks
217953: os_sanity (prio: 254, nw: 218710, flags: 0x0, ssize: 0, cswcnt: 218, tot_run_time: 0ms)
218010: task2 (prio: 2, nw: 217709, flags: 0x3, ssize: 0, cswcnt: 218, tot_run_time: 0ms)
-stat stat
-229881:s0: 1
+
+prompt
+Usage: prompt [set|show] [prompt_char]
+prompt set >
+Prompt set to: >
+229370: >
```
@@ -91,7 +99,7 @@ stat stat
This data structure is used in holding information about registered command handlers.
-```no-highlight
+```c
struct shell_cmd {
char *sc_cmd;
shell_cmd_func_t sc_cmd_func;
@@ -101,9 +109,9 @@ struct shell_cmd {
| Element | Description |
|---------|-------------|
-| sc_cmd | Character string of the command |
-| sc_cmd_func | Pointer to the command handler |
-| sc_next | Bookkeeping linkage internal for shell |
+| `sc_cmd` | Character string of the command |
+| `sc_cmd_func` | Pointer to the command handler |
+| `sc_next` | Bookkeeping linkage internal for shell |
###List of Functions
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/shell/shell_cmd_register.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_cmd_register.md b/docs/os/modules/shell/shell_cmd_register.md
index aea4c16..5becffd 100644
--- a/docs/os/modules/shell/shell_cmd_register.md
+++ b/docs/os/modules/shell/shell_cmd_register.md
@@ -1,18 +1,21 @@
## <font color="#F2853F" style="font-size:24pt"> shell_cmd_register </font>
-```no-highlight
+```c
int shell_cmd_register(struct shell_cmd *sc)
```
-Registers a handler for incoming console commands. Within the structure there is the command string and the handler for those commands. Caller must allocate the memory for this structure and keep it around as shell links this to its own internal data structures.
+Registers a handler for incoming console commands. Within the structure there is the command string
+and the handler for those commands. Caller must allocate the memory for this structure and keep it around
+as shell links this to its own internal data structures.
-Command handler is of type `int(*shell_cmd_func_t)(int argc, char **argv)`. Command line arguments are passed to it as an array of character pointers.
+Command handler is of type `int(*shell_cmd_func_t)(int argc, char **argv)`. Command line arguments
+are passed to it as an array of character pointers.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| sc | Structure containing info about the command. |
+| `sc` | Structure containing info about the command. |
#### Returned values
@@ -21,7 +24,7 @@ Non-zero on failure.
#### Example
-```no-highlight
+```c
static int fs_ls_cmd(int argc, char **argv);
static struct shell_cmd fs_ls_struct = {
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/shell/shell_nlip_input_register.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_nlip_input_register.md b/docs/os/modules/shell/shell_nlip_input_register.md
index abc64d6..ab2912a 100644
--- a/docs/os/modules/shell/shell_nlip_input_register.md
+++ b/docs/os/modules/shell/shell_nlip_input_register.md
@@ -1,19 +1,22 @@
## <font color="#F2853F" style="font-size:24pt"> shell_nlip_input_register </font>
-```no-highlight
+```c
int shell_nlip_input_register(shell_nlip_input_func_t nf, void *arg)
```
-Registers a handler for incoming newtmgr messages. Shell receives incoming data stream from UART and when it detects NLIP frame, it decodes it and passes it on by calling the function `nf`.
+Registers a handler for incoming newtmgr messages. Shell receives incoming data stream from
+UART and when it detects NLIP frame, it decodes it and passes it on by calling the function `nf`.
-Handler function is of type `int (*shell_nlip_input_func_t)(struct os_mbuf *m, void *arg)`. Shell passes the incoming newtmgr message inside os_mbuf *m*, and *arg* is the argument that was passed in during handler registration.
+Handler function is of type `int (*shell_nlip_input_func_t)(struct os_mbuf *m, void *arg)`.
+Shell passes the incoming newtmgr message inside `os_mbuf` `m`, and `arg` is the argument that
+was passed in during handler registration.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| nf | Handler for incoming newtmgr datagrams. |
-| arg | Argument that gets passed to this handler, along with the datagram |
+| `nf` | Handler for incoming newtmgr datagrams. |
+| `arg` | Argument that gets passed to this handler, along with the datagram |
#### Returned values
@@ -21,7 +24,7 @@ Returns 0 on success.
#### Example
-```no-highlight
+```c
static int
nmgr_shell_in(struct os_mbuf *m, void *arg)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/shell/shell_nlip_output.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_nlip_output.md b/docs/os/modules/shell/shell_nlip_output.md
index 4880de0..a905b63 100644
--- a/docs/os/modules/shell/shell_nlip_output.md
+++ b/docs/os/modules/shell/shell_nlip_output.md
@@ -1,6 +1,6 @@
## <font color="#F2853F" style="font-size:24pt"> shell_nlip_output </font>
-```no-highlight
+```c
int shell_nlip_output(struct os_mbuf *m)
```
@@ -10,7 +10,7 @@ Queue outgoing newtmgr message for transmission. Shell package will encode this
| Arguments | Description |
|-----------|-------------|
-| m | os_mbuf containing the message |
+| `m` | os_mbuf containing the message |
#### Returned values
@@ -18,7 +18,7 @@ Returns 0 on success.
#### Example
-```no-highlight
+```c
static int
nmgr_shell_out(struct nmgr_transport *nt, struct os_mbuf *m)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/docs/os/modules/shell/shell_task_init.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell_task_init.md b/docs/os/modules/shell/shell_task_init.md
index ce2985a..63b854d 100644
--- a/docs/os/modules/shell/shell_task_init.md
+++ b/docs/os/modules/shell/shell_task_init.md
@@ -1,20 +1,20 @@
## <font color="F2853F" style="font-size:24pt"> shell_task_init</font>
-```no-highlight
-int shell_task_init(uint8_t prio, os_stack_t *stack, uint16_t stack_size,
- int max_input_length);
+```c
+int shell_task_init(uint8_t prio, os_stack_t *stack, uint16_t stack_size, int max_input_length);
```
-Initializes the shell package. This creates a task for shell, and registers few commands on its own (*echo*, *?*, for example). It also allocates memory for buffering console input.
+Initializes the shell package. This creates a task for shell, and registers a few commands on its own
+(`echo`, `?`, `prompt` for example). It also allocates memory for buffering console input.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| prio | Priority of the shell task |
-| stack | Pointer to shell tasks's stack |
-| stack_size | Size of the aforementioned stack (in units of os_stack_t) |
-| max_input_length | the maximum expected length of line for input |
+| `prio` | Priority of the shell task |
+| `stack` | Pointer to shell tasks's stack |
+| `stack_size` | Size of the aforementioned stack (in units of os_stack_t) |
+| `max_input_length` | the maximum expected length of line for input |
#### Returned values
@@ -28,7 +28,7 @@ You can register commands before calling this, but only if OS has not been start
Here's an example of stand-alone code which allows the user to execute regression tests for sys/config package only.
-```no-highlight
+```c
#define SHELL_TASK_PRIO (3)
#define SHELL_MAX_INPUT_LEN (256)
#define SHELL_TASK_STACK_SIZE (OS_STACK_ALIGN(384))
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/79707346/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
[12/21] incubator-mynewt-site git commit: Merge branch 'patch-1' of
https://github.com/sam-bristow/incubator-mynewt-site into develop
Posted by ad...@apache.org.
Merge branch 'patch-1' of https://github.com/sam-bristow/incubator-mynewt-site into develop
This closes #122
This closes #124
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/1aec6284
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/1aec6284
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/1aec6284
Branch: refs/heads/develop
Commit: 1aec6284be3d6dfc3b365a66967c4d04f7423255
Parents: 5de32ba 0712743
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 15:49:22 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 15:49:22 2016 -0800
----------------------------------------------------------------------
docs/faq/how_to_edit_docs.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------
[17/21] 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/da241837
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/da241837
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/da241837
Branch: refs/heads/develop
Commit: da241837b843eb8da74d1a08c00bc0da67b426fd
Parents: 4ff42bd
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 16:30:50 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 16:30:50 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/da241837/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>
[16/21] incubator-mynewt-site git commit: Merge branch 'develop' of
https://github.com/davidgs/incubator-mynewt-site into develop
Posted by ad...@apache.org.
Merge branch 'develop' of https://github.com/davidgs/incubator-mynewt-site into develop
This closes #118
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/4ff42bda
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/4ff42bda
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/4ff42bda
Branch: refs/heads/develop
Commit: 4ff42bda40f7cc7907464ea72a1583e02e16a1a8
Parents: ff2476a ed14270
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 15:56:11 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 15:56:11 2016 -0800
----------------------------------------------------------------------
docs/os/core_os/callout/callout.md | 20 +-
docs/os/core_os/callout/os_callout_func_init.md | 20 +-
docs/os/core_os/callout/os_callout_init.md | 16 +-
docs/os/core_os/callout/os_callout_queued.md | 7 +-
docs/os/core_os/callout/os_callout_reset.md | 12 +-
docs/os/core_os/callout/os_callout_stop.md | 10 +-
.../os/core_os/context_switch/context_switch.md | 20 +-
.../os/core_os/context_switch/os_arch_ctx_sw.md | 10 +-
docs/os/core_os/context_switch/os_sched.md | 6 +-
.../context_switch/os_sched_ctx_sw_hook.md | 2 +-
.../core_os/context_switch/os_sched_insert.md | 7 +-
.../context_switch/os_sched_os_timer_exp.md | 4 +-
.../core_os/context_switch/os_sched_resort.md | 6 +-
.../context_switch/os_sched_set_current_task.md | 6 +-
.../os/core_os/context_switch/os_sched_sleep.md | 10 +-
.../core_os/context_switch/os_sched_wakeup.md | 2 +-
docs/os/core_os/event_queue/event_queue.md | 16 +-
docs/os/core_os/event_queue/os_eventq_get.md | 4 +-
docs/os/core_os/event_queue/os_eventq_init.md | 4 +-
docs/os/core_os/event_queue/os_eventq_put.md | 6 +-
docs/os/core_os/event_queue/os_eventq_remove.md | 6 +-
docs/os/core_os/heap/heap.md | 2 +-
docs/os/core_os/heap/os_free.md | 4 +-
docs/os/core_os/heap/os_malloc.md | 12 +-
docs/os/core_os/heap/os_realloc.md | 10 +-
docs/os/core_os/mbuf/OS_MBUF_DATA.md | 4 +-
docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md | 4 +-
docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md | 2 +-
docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md | 2 +-
docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md | 2 +-
docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md | 4 +-
docs/os/core_os/mbuf/OS_MBUF_USRHDR.md | 2 +-
docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md | 2 +-
docs/os/core_os/mbuf/mbuf.md | 26 +-
docs/os/core_os/mbuf/os_mbuf_adj.md | 6 +-
docs/os/core_os/mbuf/os_mbuf_append.md | 14 +-
docs/os/core_os/mbuf/os_mbuf_concat.md | 4 +-
docs/os/core_os/mbuf/os_mbuf_copydata.md | 10 +-
docs/os/core_os/mbuf/os_mbuf_copyinto.md | 8 +-
docs/os/core_os/mbuf/os_mbuf_dup.md | 4 +-
docs/os/core_os/mbuf/os_mbuf_extend.md | 8 +-
docs/os/core_os/mbuf/os_mbuf_free_chain.md | 2 +-
docs/os/core_os/mbuf/os_mbuf_get.md | 8 +-
docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md | 10 +-
docs/os/core_os/mbuf/os_mbuf_memcmp.md | 10 +-
docs/os/core_os/mbuf/os_mbuf_off.md | 12 +-
docs/os/core_os/mbuf/os_mbuf_pool_init.md | 10 +-
docs/os/core_os/mbuf/os_mbuf_prepend.md | 8 +-
docs/os/core_os/mbuf/os_mbuf_pullup.md | 8 +-
docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md | 8 +-
docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md | 16 +-
docs/os/core_os/memory_pool/memory_pool.md | 2 +-
docs/os/core_os/memory_pool/os_memblock_get.md | 6 +-
docs/os/core_os/memory_pool/os_memblock_put.md | 8 +-
docs/os/core_os/memory_pool/os_mempool_init.md | 26 +-
docs/os/core_os/mqueue/mqueue.md | 6 +-
docs/os/core_os/mqueue/os_mqueue_get.md | 6 +-
docs/os/core_os/mqueue/os_mqueue_init.md | 6 +-
docs/os/core_os/mqueue/os_mqueue_put.md | 10 +-
docs/os/core_os/msys/msys.md | 4 +-
docs/os/core_os/msys/os_msys_get.md | 10 +-
docs/os/core_os/msys/os_msys_get_pkthdr.md | 8 +-
docs/os/core_os/msys/os_msys_register.md | 2 +-
docs/os/core_os/mutex/mutex.md | 2 +-
docs/os/core_os/mutex/os_mutex_init.md | 6 +-
docs/os/core_os/mutex/os_mutex_pend.md | 14 +-
docs/os/core_os/mutex/os_mutex_release.md | 10 +-
docs/os/core_os/mynewt_os.md | 8 +-
docs/os/core_os/os_init.md | 6 +-
docs/os/core_os/os_start.md | 4 +-
docs/os/core_os/os_started.md | 6 +-
docs/os/core_os/porting/port_bsp.md | 124 +++---
docs/os/core_os/porting/port_cpu.md | 20 +-
docs/os/core_os/porting/port_mcu.md | 9 +-
docs/os/core_os/porting/port_os.md | 38 +-
docs/os/core_os/sanity/sanity.md | 2 +-
docs/os/core_os/semaphore/os_sem_init.md | 8 +-
docs/os/core_os/semaphore/os_sem_pend.md | 14 +-
docs/os/core_os/semaphore/os_sem_release.md | 8 +-
docs/os/core_os/semaphore/semaphore.md | 8 +-
docs/os/core_os/task/os_task_info_get_next.md | 18 +-
docs/os/core_os/task/os_task_init.md | 20 +-
docs/os/core_os/task/task.md | 15 +-
docs/os/core_os/time/os_gettimeofday.md | 4 +-
docs/os/core_os/time/os_settimeofday.md | 4 +-
docs/os/core_os/time/os_time.md | 12 +-
docs/os/core_os/time/os_time_delay.md | 2 +-
docs/os/get_started/vocabulary.md | 39 +-
docs/os/modules/baselibc.md | 21 +-
docs/os/modules/bootloader/bootloader.md | 373 ++++++++++++++++++-
docs/os/modules/console/console.md | 37 +-
.../os/modules/console/console_blocking_mode.md | 12 +-
docs/os/modules/console/console_echo.md | 13 +-
docs/os/modules/console/console_init.md | 18 +-
docs/os/modules/console/console_is_init.md | 8 +-
docs/os/modules/console/console_printf.md | 22 +-
docs/os/modules/console/console_read.md | 18 +-
docs/os/modules/console/console_write.md | 11 +-
docs/os/modules/shell/shell.md | 30 +-
docs/os/modules/shell/shell_cmd_register.md | 13 +-
.../modules/shell/shell_nlip_input_register.md | 15 +-
docs/os/modules/shell/shell_nlip_output.md | 6 +-
docs/os/modules/shell/shell_task_init.md | 18 +-
docs/os/modules/split/split.md | 173 ++++++---
docs/os/tutorials/arduino_zero.md | 107 +++++-
docs/os/tutorials/bleprph/bleprph-app.md | 108 ++++++
docs/os/tutorials/bletiny_project.md | 128 ++++---
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
mkdocs.yml | 1 +
114 files changed, 1410 insertions(+), 633 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/4ff42bda/docs/os/tutorials/bletiny_project.md
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/4ff42bda/mkdocs.yml
----------------------------------------------------------------------
[10/21] incubator-mynewt-site git commit: Elaborated on serial
connection parameters
Posted by ad...@apache.org.
Elaborated on serial connection parameters
As a newcomer, it wasn't immediately obvious what what serial connection parameters I should use to connect
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/2493b0f4
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/2493b0f4
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/2493b0f4
Branch: refs/heads/develop
Commit: 2493b0f487f75dd3822662994bbd60321836f131
Parents: 5de32ba
Author: Sam Lewis <sa...@users.noreply.github.com>
Authored: Thu Nov 10 20:49:20 2016 +1000
Committer: GitHub <no...@github.com>
Committed: Thu Nov 10 20:49:20 2016 +1000
----------------------------------------------------------------------
docs/os/tutorials/bletiny_project.md | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/2493b0f4/docs/os/tutorials/bletiny_project.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bletiny_project.md b/docs/os/tutorials/bletiny_project.md
index 495a8b3..23581e2 100644
--- a/docs/os/tutorials/bletiny_project.md
+++ b/docs/os/tutorials/bletiny_project.md
@@ -149,11 +149,10 @@ You will now look for some BLE related stats over a serial connection and see th
<br>
-You may use any terminal emulation program to communicate with the board. This tutorial shows a Minicom set up. You will have to find out what the usbserial port number is on your laptop, of course.
-
+You may use any terminal emulation program to communicate with the board, but you should connect to the nRF52's serial port using a baudrate of 115200, 8N1, and hardware/software flow control both off. This tutorial shows a Minicom set up. You will have to find out what the usbserial port number is on your laptop, of course.
```
-$ minicom -D /dev/tty.usbserial-AJ03HAQQ
+$ minicom -D /dev/tty.usbserial-AJ03HAQQ -b 115200
```
<br>
@@ -281,4 +280,4 @@ Continuing.
<br>
-You should see the g_os_time advancing as above, as each os time tick is 1ms. If the system ticks aren't advancing, then nothing's actually running.
\ No newline at end of file
+You should see the g_os_time advancing as above, as each os time tick is 1ms. If the system ticks aren't advancing, then nothing's actually running.
[07/21] incubator-mynewt-site git commit: Normalize OS Core Docs
Posted by ad...@apache.org.
Normalize OS Core Docs
Trying to get consistency in docs formatting.
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/aac53ed0
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/aac53ed0
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/aac53ed0
Branch: refs/heads/develop
Commit: aac53ed0482b786670727964e8026ab07e62cfed
Parents: 05b828c
Author: David G. Simmons <sa...@mac.com>
Authored: Tue Nov 1 10:24:08 2016 -0400
Committer: David G. Simmons <sa...@mac.com>
Committed: Tue Nov 1 10:24:08 2016 -0400
----------------------------------------------------------------------
docs/os/core_os/callout/callout.md | 20 +--
docs/os/core_os/callout/os_callout_func_init.md | 20 +--
docs/os/core_os/callout/os_callout_init.md | 16 +--
docs/os/core_os/callout/os_callout_queued.md | 7 +-
docs/os/core_os/callout/os_callout_reset.md | 12 +-
docs/os/core_os/callout/os_callout_stop.md | 10 +-
.../os/core_os/context_switch/context_switch.md | 20 +--
.../os/core_os/context_switch/os_arch_ctx_sw.md | 10 +-
docs/os/core_os/context_switch/os_sched.md | 6 +-
.../context_switch/os_sched_ctx_sw_hook.md | 2 +-
.../core_os/context_switch/os_sched_insert.md | 7 +-
.../context_switch/os_sched_os_timer_exp.md | 4 +-
.../core_os/context_switch/os_sched_resort.md | 6 +-
.../context_switch/os_sched_set_current_task.md | 6 +-
.../os/core_os/context_switch/os_sched_sleep.md | 10 +-
.../core_os/context_switch/os_sched_wakeup.md | 2 +-
docs/os/core_os/event_queue/event_queue.md | 16 +--
docs/os/core_os/event_queue/os_eventq_get.md | 4 +-
docs/os/core_os/event_queue/os_eventq_init.md | 4 +-
docs/os/core_os/event_queue/os_eventq_put.md | 6 +-
docs/os/core_os/event_queue/os_eventq_remove.md | 6 +-
docs/os/core_os/heap/heap.md | 2 +-
docs/os/core_os/heap/os_free.md | 4 +-
docs/os/core_os/heap/os_malloc.md | 12 +-
docs/os/core_os/heap/os_realloc.md | 10 +-
docs/os/core_os/mbuf/OS_MBUF_DATA.md | 4 +-
docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md | 4 +-
docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md | 2 +-
docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md | 2 +-
docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md | 2 +-
docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md | 4 +-
docs/os/core_os/mbuf/OS_MBUF_USRHDR.md | 2 +-
docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md | 2 +-
docs/os/core_os/mbuf/mbuf.md | 26 ++--
docs/os/core_os/mbuf/os_mbuf_adj.md | 6 +-
docs/os/core_os/mbuf/os_mbuf_append.md | 14 +--
docs/os/core_os/mbuf/os_mbuf_concat.md | 4 +-
docs/os/core_os/mbuf/os_mbuf_copydata.md | 10 +-
docs/os/core_os/mbuf/os_mbuf_copyinto.md | 8 +-
docs/os/core_os/mbuf/os_mbuf_dup.md | 4 +-
docs/os/core_os/mbuf/os_mbuf_extend.md | 8 +-
docs/os/core_os/mbuf/os_mbuf_free_chain.md | 2 +-
docs/os/core_os/mbuf/os_mbuf_get.md | 8 +-
docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md | 10 +-
docs/os/core_os/mbuf/os_mbuf_memcmp.md | 10 +-
docs/os/core_os/mbuf/os_mbuf_off.md | 12 +-
docs/os/core_os/mbuf/os_mbuf_pool_init.md | 10 +-
docs/os/core_os/mbuf/os_mbuf_prepend.md | 8 +-
docs/os/core_os/mbuf/os_mbuf_pullup.md | 8 +-
docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md | 8 +-
docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md | 16 +--
docs/os/core_os/memory_pool/memory_pool.md | 2 +-
docs/os/core_os/memory_pool/os_memblock_get.md | 6 +-
docs/os/core_os/memory_pool/os_memblock_put.md | 8 +-
docs/os/core_os/memory_pool/os_mempool_init.md | 26 ++--
docs/os/core_os/mqueue/mqueue.md | 6 +-
docs/os/core_os/mqueue/os_mqueue_get.md | 6 +-
docs/os/core_os/mqueue/os_mqueue_init.md | 6 +-
docs/os/core_os/mqueue/os_mqueue_put.md | 10 +-
docs/os/core_os/msys/msys.md | 4 +-
docs/os/core_os/msys/os_msys_get.md | 10 +-
docs/os/core_os/msys/os_msys_get_pkthdr.md | 8 +-
docs/os/core_os/msys/os_msys_register.md | 2 +-
docs/os/core_os/mutex/mutex.md | 2 +-
docs/os/core_os/mutex/os_mutex_init.md | 6 +-
docs/os/core_os/mutex/os_mutex_pend.md | 14 +--
docs/os/core_os/mutex/os_mutex_release.md | 10 +-
docs/os/core_os/mynewt_os.md | 8 +-
docs/os/core_os/os_init.md | 6 +-
docs/os/core_os/os_start.md | 4 +-
docs/os/core_os/os_started.md | 6 +-
docs/os/core_os/porting/port_bsp.md | 124 ++++++++++++-------
docs/os/core_os/porting/port_cpu.md | 20 +--
docs/os/core_os/porting/port_mcu.md | 9 +-
docs/os/core_os/porting/port_os.md | 38 ++++--
docs/os/core_os/sanity/sanity.md | 2 +-
docs/os/core_os/semaphore/os_sem_init.md | 8 +-
docs/os/core_os/semaphore/os_sem_pend.md | 14 +--
docs/os/core_os/semaphore/os_sem_release.md | 8 +-
docs/os/core_os/semaphore/semaphore.md | 8 +-
docs/os/core_os/task/os_task_info_get_next.md | 18 +--
docs/os/core_os/task/os_task_init.md | 20 +--
docs/os/core_os/task/task.md | 15 ++-
docs/os/core_os/time/os_gettimeofday.md | 4 +-
docs/os/core_os/time/os_settimeofday.md | 4 +-
docs/os/core_os/time/os_time.md | 12 +-
docs/os/core_os/time/os_time_delay.md | 2 +-
docs/os/get_started/vocabulary.md | 8 +-
88 files changed, 469 insertions(+), 411 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/callout/callout.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/callout.md b/docs/os/core_os/callout/callout.md
index 042dd7b..ced9eb8 100644
--- a/docs/os/core_os/callout/callout.md
+++ b/docs/os/core_os/callout/callout.md
@@ -20,34 +20,36 @@ Callout timer fires out just once. For periodic timer type of operation you need
### Data structures
+```c
struct os_callout {
struct os_event c_ev;
struct os_eventq *c_evq;
uint32_t c_ticks;
TAILQ_ENTRY(os_callout) c_next;
};
-
+```
| Element | Description |
|---------|-------------|
-| c_ev | Event structure of this callout |
-| c_evq | Event queue where this callout is placed on timer expiry |
-| c_ticks | OS tick amount when timer fires |
-| c_next | Linkage to other unexpired callouts |
-
+| `c_ev` | Event structure of this callout |
+| `c_evq` | Event queue where this callout is placed on timer expiry |
+| `c_ticks` | OS tick amount when timer fires |
+| `c_next` | Linkage to other unexpired callouts |
+```c
struct os_callout_func {
struct os_callout cf_c;
os_callout_func_t cf_func;
void *cf_arg;
};
+```
| Element | Description |
|---------|-------------|
-| cf_c | struct os_callout. See above |
-| cf_func | Function pointer which should be called by event queue processing |
-| cf_arg | Generic void * argument to that function |
+| `cf_c` | struct os_callout. See above |
+| `cf_func` | Function pointer which should be called by event queue processing |
+| `cf_arg` | Generic void * argument to that function |
### List of Functions
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/callout/os_callout_func_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_func_init.md b/docs/os/core_os/callout/os_callout_func_init.md
index 2c45817..de62bef 100644
--- a/docs/os/core_os/callout/os_callout_func_init.md
+++ b/docs/os/core_os/callout/os_callout_func_init.md
@@ -1,20 +1,20 @@
## <font color="#F2853F" style="font-size:24pt"> os_callout_func_init </font>
-
+```c
void os_callout_func_init(struct os_callout_func *cf, struct os_eventq *evq, os_callout_func_t timo_func, void *ev_arg)
+```
-
-Initializes the given *struct os_callout_func*. Data structure is filled in with elements given as argument.
+Initializes the given `struct os_callout_func`. Data structure is filled in with elements given as argument.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| cf | Pointer to os_callout_func being initialized |
-| evq | Event queue where this gets delivered to |
-| timo_func | Timeout function. Event processing should call this |
-| ev_arg | Generic argument for the event |
+| `cf` | Pointer to os_callout_func being initialized |
+| `evq` | Event queue where this gets delivered to |
+| `timo_func` | Timeout function. Event processing should call this |
+| `ev_arg` | Generic argument for the event |
#### Returned values
@@ -22,13 +22,13 @@ N/A
#### Notes
-The same notes as with *os_callout_init()*.
+The same notes as with [`os_callout_init()`](os_callout_init.md).
#### Example
<Add text to set up the context for the example here>
-
+```c
struct os_callout_func g_native_cputimer;
struct os_eventq g_native_cputime_evq;
void native_cputimer_cb(void *arg);
@@ -38,7 +38,7 @@ The same notes as with *os_callout_init()*.
&g_native_cputime_evq,
native_cputimer_cb,
NULL);
-
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/callout/os_callout_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_init.md b/docs/os/core_os/callout/os_callout_init.md
index 7d30fdc..e4896f6 100644
--- a/docs/os/core_os/callout/os_callout_init.md
+++ b/docs/os/core_os/callout/os_callout_init.md
@@ -1,19 +1,19 @@
## <font color="#F2853F" style="font-size:24pt">os_callout_init </font>
-
+```c
void os_callout_init(struct os_callout *c, struct os_eventq *evq, void *ev_arg)
+```
-
-Initializes *struct os_callout*. Event type will be set to *OS_EVENT_T_TIMER*.
+Initializes `struct os_callout`. Event type will be set to `OS_EVENT_T_TIMER`.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| c | Pointer to os_callout to initialize |
-| evq | Event queue where this gets delivered to |
-| ev_arg | Generic argument which is filled in for the event |
+| `c` | Pointer to os_callout to initialize |
+| `evq` | Event queue where this gets delivered to |
+| `ev_arg` | Generic argument which is filled in for the event |
#### Returned values
@@ -28,11 +28,11 @@ Or if the timer has already fired, it will mess up the event queue where the cal
<Add text to set up the context for the example here>
-
+```c
struct os_eventq my_evq;
struct os_callout my_callouts[8];
for (i = 0; i < 8; i++) {
os_callout_init(&my_callouts[i], &my_evq, (void *)i);
}
-
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/callout/os_callout_queued.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_queued.md b/docs/os/core_os/callout/os_callout_queued.md
index 9e69f96..0917d13 100644
--- a/docs/os/core_os/callout/os_callout_queued.md
+++ b/docs/os/core_os/callout/os_callout_queued.md
@@ -1,8 +1,8 @@
## <font color="#F2853F" style="font-size:24pt">os_callout_queued</font>
-
+```c
int os_callout_queued(struct os_callout *c)
-
+```
Tells whether the callout has been armed or not.
@@ -11,11 +11,12 @@ Tells whether the callout has been armed or not.
| Arguments | Description |
|-----------|-------------|
-| c | Pointer to callout being checked |
+| `c` | Pointer to callout being checked |
#### Returned values
0: timer is not armed
+
non-zero: timer is armed
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/callout/os_callout_reset.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_reset.md b/docs/os/core_os/callout/os_callout_reset.md
index 5c6875b..d9ff1d8 100644
--- a/docs/os/core_os/callout/os_callout_reset.md
+++ b/docs/os/core_os/callout/os_callout_reset.md
@@ -1,8 +1,8 @@
## <font color="#F2853F" style="font-size:24pt"> os_callout_reset </font>
-
+```c
void os_callout_reset(struct os_callout *c, int32_t timo)
-
+```
Resets the callout to happen *timo* in OS ticks.
@@ -11,8 +11,8 @@ Resets the callout to happen *timo* in OS ticks.
| Arguments | Description |
|-----------|-------------|
-| c | Pointer to os_callout being reset |
-| timo | OS ticks the timer is being set to |
+| `c` | Pointer to os_callout being reset |
+| `timo` | OS ticks the timer is being set to |
#### Returned values
@@ -27,7 +27,7 @@ N/A
<Add text to set up the context for the example here>
-
+```c
/* Re-start the timer (run every 50 msecs) */
os_callout_reset(&g_bletest_timer.cf_c, OS_TICKS_PER_SEC / 20);
-
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/callout/os_callout_stop.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/callout/os_callout_stop.md b/docs/os/core_os/callout/os_callout_stop.md
index 76aa87d..45359b4 100644
--- a/docs/os/core_os/callout/os_callout_stop.md
+++ b/docs/os/core_os/callout/os_callout_stop.md
@@ -1,8 +1,8 @@
## <font color="#F2853F" style="font-size:24pt"> os_callout_stop </font>
-
+```c
void os_callout_stop(struct os_callout *c)
-
+```
Disarms a timer.
@@ -11,7 +11,7 @@ Disarms a timer.
| Arguments | Description |
|-----------|-------------|
-| c | Pointer to os_callout being stopped |
+| `c` | Pointer to os_callout being stopped |
#### Returned values
@@ -22,10 +22,10 @@ N/A
#### Example
-
+```c
struct os_callout_func g_native_cputimer;
os_callout_stop(&g_native_cputimer.cf_c);
-
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/context_switch.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/context_switch.md b/docs/os/core_os/context_switch/context_switch.md
index b507149..e3c582a 100644
--- a/docs/os/core_os/context_switch/context_switch.md
+++ b/docs/os/core_os/context_switch/context_switch.md
@@ -7,19 +7,19 @@ Scheduler's job is to maintain the list of tasks and decide which one should be
Task states can be *running*, *ready to run* or *sleeping*.
-When task is *running*, CPU is executing in that task's context. The program counter (PC) is pointing to instructions task wants to execute and stack pointer (SP) is pointing to task's stack.
+When a task is *running*, the CPU is executing in that task's context. The program counter (PC) is pointing to instructions that task wants to execute and the stack pointer (SP) is pointing to that task's stack.
-Task which is *ready to run* wants to get on the CPU to do its work.
+A task which is *ready to run* wants to get on the CPU to do its work.
-Task which is *sleeping* has no more work to do. It's waiting for someone else to wake it up.
+A task which is *sleeping* has no more work to do. It's waiting for someone or something else to wake it up.
-Scheduler algorithm is simple: from among the tasks which are ready to run, pick the the one with highest priority (lowest numeric value in task's t_prio field), and make its state *running*.
+The Scheduler algorithm is simple: from among the tasks which are ready to run, pick the the one with highest priority (lowest numeric value in task's `t_prio` field), and make its state *running*.
-Tasks which are either *running* or *ready to run* are kept in linked list `g_os_run_list`. This list is ordered by priority.
+Tasks which are either *running* or *ready to run* are kept in a linked list `g_os_run_list`. This list is ordered by priority.
-Tasks which are *sleeping* are kept in linked list `g_os_sleep_list`.
+Tasks which are *sleeping* are kept in a linked list `g_os_sleep_list`.
-Scheduler has a CPU architecture specific component; this code is responsible for swapping in the task which should be *running*. This process is called context switch. During context switching the state of the CPU (e.g. registers) for the currently *running* task is stored and the new task is swapped in.
+The scheduler has a CPU architecture specific component; this code is responsible for swapping in the task which should be *running*. This process is called context switch. During context switching the state of the CPU (e.g. registers) for the currently *running* task is stored and the new task is swapped in.
## List of Functions
@@ -30,10 +30,10 @@ The functions available in context_switch are:
| **Function** | **Description** |
|-----------|-------------|
| [os_sched](os_sched.md) | Performs context switch if needed. |
-| [os_arch_ctx_sw](os_arch_ctx_sw.md) | Change the state of task given task to *running*. |
+| [os_arch_ctx_sw](os_arch_ctx_sw.md) | Change the state of a given task to *running*. |
| [os_sched_ctx_sw_hook](os_sched_ctx_sw_hook.md) | Performs task accounting when context switching. |
-| [os_sched_get_current_task](os_sched_get_current_task.md) | Returns the pointer to task which is currently *running*. |
-| [os_sched_insert](os_sched_insert.md) | Insert task into scheduler's ready to run list. |
+| [os_sched_get_current_task](os_sched_get_current_task.md) | Returns the pointer to the task which is currently *running*. |
+| [os_sched_insert](os_sched_insert.md) | Insert a task into scheduler's *ready to run* list. |
| [os_sched_next_task](os_sched_next_task.md) | Returns the pointer to highest priority task from the list which are *ready to run*. |
| [os_sched_os_timer_exp](os_sched_os_timer_exp.md) | Inform scheduler that OS time has moved forward. |
| [os_sched_resort](os_sched_resort.md) | Inform scheduler that the priority of the given task has changed and the *ready to run* list should be re-sorted. |
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_arch_ctx_sw.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_arch_ctx_sw.md b/docs/os/core_os/context_switch/os_arch_ctx_sw.md
index 2a1c7f7..9c59b28 100644
--- a/docs/os/core_os/context_switch/os_arch_ctx_sw.md
+++ b/docs/os/core_os/context_switch/os_arch_ctx_sw.md
@@ -1,16 +1,16 @@
-## <font color="#F2853F" style="font-size:24pt"> os_arch_ctx_sw </font>
-
+##<font color="#F2853F" style="font-size:24pt"> os_arch_ctx_sw </font>
+```c
void os_arch_ctx_sw(struct os_task *next_t)
+```
-
-Change the state of task pointed by *next_t* to be *running*.
+Change the state of task pointed by `next_t` to be *running*.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| next_t | Pointer to task which must run next |
+| `next_t` | Pointer to task which must run next |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_sched.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched.md b/docs/os/core_os/context_switch/os_sched.md
index 2eb34cf..4cbeefc 100644
--- a/docs/os/core_os/context_switch/os_sched.md
+++ b/docs/os/core_os/context_switch/os_sched.md
@@ -1,10 +1,10 @@
-## <font color="#F2853F" style="font-size:24pt"> os_sched </font>
+##<font color="#F2853F" style="font-size:24pt"> os_sched </font>
```c
void os_sched(struct os_task *next_t)
```
-Performs context switch if needed. If *next_t* is set, that task will be made *running*. If *next_t* is NULL, highest priority *ready to run* is swapped in. This function can be called when new tasks were made *ready to run* or if the current task is moved to *sleeping* state.
+Performs context switch if needed. If `next_t` is set, that task will be made *running*. If `next_t` is **NULL**, highest priority *ready to run* is swapped in. This function can be called when new tasks were made *ready to run* or if the current task is moved to *sleeping* state.
This function will call the architecture specific routine to swap in the new task.
@@ -12,7 +12,7 @@ This function will call the architecture specific routine to swap in the new tas
| Arguments | Description |
|-----------|-------------|
-| next_t | Pointer to task which must run next (optional) |
+| `next_t` | Pointer to task which must run next (optional) |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md b/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md
index 3042478..dd586fd 100644
--- a/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md
+++ b/docs/os/core_os/context_switch/os_sched_ctx_sw_hook.md
@@ -6,7 +6,7 @@ void os_sched_ctx_sw_hook(struct os_task *next_t)
Performs task accounting when context switching.
-This function must be called from the architecture specific context switching routine *os_arch_ctx_sw()* before resuming execution of the *running* task.
+This function must be called from the architecture specific context switching routine `os_arch_ctx_sw()` before resuming execution of the *running* task.
#### Arguments
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_sched_insert.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_insert.md b/docs/os/core_os/context_switch/os_sched_insert.md
index dce6755..46fcb52 100644
--- a/docs/os/core_os/context_switch/os_sched_insert.md
+++ b/docs/os/core_os/context_switch/os_sched_insert.md
@@ -1,8 +1,7 @@
## <font color="#F2853F" style="font-size:24pt"> os_sched_insert </font>
```c
-os_error_t
-os_sched_insert(struct os_task *t)
+os_error_t os_sched_insert(struct os_task *t)
```
Insert task into scheduler's *ready to run* list.
@@ -12,11 +11,11 @@ Insert task into scheduler's *ready to run* list.
| Arguments | Description |
|-----------|-------------|
-| t | Pointer to task |
+| `t`| Pointer to task |
#### Returned values
-Returns OS_EINVAL if task state is not *READY*.
+Returns `OS_EINVAL` if task state is not **READY**.
Returns 0 on success.
#### Notes
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_sched_os_timer_exp.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_os_timer_exp.md b/docs/os/core_os/context_switch/os_sched_os_timer_exp.md
index f5a03fc..3d2c5ca 100644
--- a/docs/os/core_os/context_switch/os_sched_os_timer_exp.md
+++ b/docs/os/core_os/context_switch/os_sched_os_timer_exp.md
@@ -4,9 +4,9 @@
void os_sched_os_timer_exp(void)
```
-Inform scheduler that OS time has moved forward, and it should inspect tasks which are *sleeping* to check whether they should be moved to *g_run_list* or not.
+Inform scheduler that OS time has moved forward, and it should inspect tasks which are *sleeping* to check whether they should be moved to `g_run_list` or not.
-This function should be called from code which handles moving OS time forward. After calling it, the highest priority task which is *ready to run* might've changed, so call to *os_sched()* should be done.
+This function should be called from code which handles moving OS time forward. After calling it, the highest priority task which is *ready to run* might've changed, so call to `os_sched()` should be done.
#### Arguments
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_sched_resort.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_resort.md b/docs/os/core_os/context_switch/os_sched_resort.md
index c755fb3..5109a88 100644
--- a/docs/os/core_os/context_switch/os_sched_resort.md
+++ b/docs/os/core_os/context_switch/os_sched_resort.md
@@ -4,13 +4,13 @@
void os_sched_resort(struct os_task *t)
```
-Inform scheduler that the priority of the task *t* has changed (e.g. in order to avoid priority inversion), and the *ready to run* list should be re-sorted.
+Inform scheduler that the priority of the task `t` has changed (e.g. in order to avoid priority inversion), and the *ready to run* list should be re-sorted.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| t | Pointer to a task whose priority has changed |
+| `t` | Pointer to a task whose priority has changed |
#### Returned values
@@ -18,7 +18,7 @@ N/A
#### Notes
-*t* must be *ready to run* before calling this.
+`t` must be *ready to run* before calling this.
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_sched_set_current_task.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_set_current_task.md b/docs/os/core_os/context_switch/os_sched_set_current_task.md
index 8839980..8604e1a 100644
--- a/docs/os/core_os/context_switch/os_sched_set_current_task.md
+++ b/docs/os/core_os/context_switch/os_sched_set_current_task.md
@@ -5,15 +5,15 @@ void
os_sched_set_current_task(struct os_task *t)
```
-Sets the currently running task to 't'.
+Sets the currently running task to `t`.
-This is called from architecture specific context switching code to update scheduler state. Call is made when state of the task 't' is made *running*.
+This is called from architecture specific context switching code to update scheduler state. Call is made when state of the task `t` is made *running*.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| t | Pointer to a task |
+| `t` | Pointer to a task |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_sched_sleep.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_sleep.md b/docs/os/core_os/context_switch/os_sched_sleep.md
index 3c46887..1ea45aa 100644
--- a/docs/os/core_os/context_switch/os_sched_sleep.md
+++ b/docs/os/core_os/context_switch/os_sched_sleep.md
@@ -5,18 +5,18 @@ int
os_sched_sleep(struct os_task *t, os_time_t nticks)
```
-Task 't' state is changed from *ready to run* to *sleeping*. Sleep time will be specified in *nticks*.
+Task `t` state is changed from *ready to run* to *sleeping*. Sleep time will be specified in `nticks`.
-Task will be woken up after sleep timer expires, unless there are other signals causing it to wake up.
+Task will be woken up after sleep timer expires, unless there are other signals causing it to wake up.
-If *nticks* is set to *OS_TIMEOUT_NEVER*, task never wakes up with a sleep timer.
+If `nticks` is set to `OS_TIMEOUT_NEVER`, task never wakes up with a sleep timer.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| t | Pointer to task |
-| nticks | Number of ticks to sleep in OS ticks |
+| `t` | Pointer to task |
+| `nticks` | Number of ticks to sleep in OS ticks |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/context_switch/os_sched_wakeup.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/context_switch/os_sched_wakeup.md b/docs/os/core_os/context_switch/os_sched_wakeup.md
index 4407c96..cb884be 100644
--- a/docs/os/core_os/context_switch/os_sched_wakeup.md
+++ b/docs/os/core_os/context_switch/os_sched_wakeup.md
@@ -12,7 +12,7 @@ Called to make task *ready to run*. If task is *sleeping*, it is woken up.
| Arguments | Description |
|-----------|-------------|
-| t | Pointer to task |
+| `t` | Pointer to task |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/event_queue/event_queue.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/event_queue.md b/docs/os/core_os/event_queue/event_queue.md
index 7f3d36d..748673e 100644
--- a/docs/os/core_os/event_queue/event_queue.md
+++ b/docs/os/core_os/event_queue/event_queue.md
@@ -3,23 +3,23 @@
Event queue is a way of serializing events arring to a task. This makes it easy to queue processing to happen inside task's context. This would be done either from an interrupt handler, or from another task.
-Events arrive in a form of a data structure *struct os_event*.
+Events arrive in a form of a data structure `struct os_event`.
### Description
-Events are in form of a data structure *struct os_event*, and they are queued to data structure *struct os_eventq*.
+Events are in form of a data structure `struct os_event`, and they are queued to data structure `struct os_eventq`.
-Queue must be initialized before trying to add events to it. This is done using *os_eventq_init()*.
+Queue must be initialized before trying to add events to it. This is done using `os_eventq_init()`.
-Common way of using event queues is to have a task loop while calling *os_eventq_get()*, waiting for work to do.
-Other tasks (or interrupts) then call *os_eventq_put()* to wake it up. Once event has been queued task waiting on that queue is woken up, and will get a pointer to queued event structure.
+Common way of using event queues is to have a task loop while calling `os_eventq_get()`, waiting for work to do.
+Other tasks (or interrupts) then call `os_eventq_put()` to wake it up. Once event has been queued task waiting on that queue is woken up, and will get a pointer to queued event structure.
Processing task would then act according to event type.
-When *os_event* is queued, it should not be freed until processing task is done with it.
+When `os_event` is queued, it should not be freed until processing task is done with it.
-It is assumed that there is only one task consuming events from an event queue. Only one task should be sleeping on a particular *os_eventq* at a time.
+It is assumed that there is only one task consuming events from an event queue. Only one task should be sleeping on a particular `os_eventq` at a time.
-Note that os_callout subsystem assumes that event queue is used as the wakeup mechanism.
+Note that [os_callout](../callout/callout.md) subsystem assumes that event queue is used as the wakeup mechanism.
### Data structures
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/event_queue/os_eventq_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_get.md b/docs/os/core_os/event_queue/os_eventq_get.md
index 6cfe242..9bff17c 100644
--- a/docs/os/core_os/event_queue/os_eventq_get.md
+++ b/docs/os/core_os/event_queue/os_eventq_get.md
@@ -12,12 +12,12 @@ Fetches the first event from a queue. Task will sleep until something gets queue
| Arguments | Description |
|-----------|-------------|
-| evq | Queue to wait on |
+| `evq` | Queue to wait on |
#### Returned values
-Will return with a pointer to first *struct event* which is in the queue.
+Will return with a pointer to first `struct event` which is in the queue.
#### Notes
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/event_queue/os_eventq_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_init.md b/docs/os/core_os/event_queue/os_eventq_init.md
index 5251a89..0c712bd 100644
--- a/docs/os/core_os/event_queue/os_eventq_init.md
+++ b/docs/os/core_os/event_queue/os_eventq_init.md
@@ -5,13 +5,13 @@
os_eventq_init(struct os_eventq *evq)
```
-Initializes *struct os_eventq*, making it ready for use.
+Initializes `struct os_eventq`, making it ready for use.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| evq | Pointer to event queue getting initialized |
+| `evq` | Pointer to event queue getting initialized |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/event_queue/os_eventq_put.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_put.md b/docs/os/core_os/event_queue/os_eventq_put.md
index 9bf3543..d46197c 100644
--- a/docs/os/core_os/event_queue/os_eventq_put.md
+++ b/docs/os/core_os/event_queue/os_eventq_put.md
@@ -5,15 +5,15 @@ void
os_eventq_put(struct os_eventq *evq, struct os_event *ev)
```
-Queues an event to tail of the event queue.
+Queues an event to the tail of the event queue.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| evq | Queue where event is being placed |
-| ev | Event which is being queued |
+| `evq` | Queue where event is being placed |
+| `ev` | Event which is being queued |
#### Returned values
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/event_queue/os_eventq_remove.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/event_queue/os_eventq_remove.md b/docs/os/core_os/event_queue/os_eventq_remove.md
index 88cd7c5..7adcd36 100644
--- a/docs/os/core_os/event_queue/os_eventq_remove.md
+++ b/docs/os/core_os/event_queue/os_eventq_remove.md
@@ -12,8 +12,8 @@ Removes an event which has been placed in a queue.
| Arguments | Description |
|-----------|-------------|
-| evq | Queue where event is being removed from |
-| ev | Event which is being removed |
+| `evq` | Queue where event is being removed from |
+| `ev` | Event which is being removed |
#### Returned values
@@ -26,7 +26,7 @@ N/A
#### Example
<Add text to set up the context for the example here>
-This is from os_callout_stop(). User wants to stop a callout from getting passed to a task. If the event has already been queued, then remove it before it is seen.
+This is from `os_callout_stop()`. User wants to stop a callout from getting passed to a task. If the event has already been queued, then remove it before it is seen.
```c
if (c->c_evq) {
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/heap/heap.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/heap/heap.md b/docs/os/core_os/heap/heap.md
index 1981a4f..efdd5f6 100644
--- a/docs/os/core_os/heap/heap.md
+++ b/docs/os/core_os/heap/heap.md
@@ -6,7 +6,7 @@ API for doing dynamic memory allocation.
### Description
-This provides malloc()/free() functionality with locking. The shared resource heap needs to be protected from concurrent access when OS has been started. *os_malloc()* function grabs a mutex before calling *malloc()*.
+This provides `malloc()` & `free()` functionality with locking. The shared resource heap needs to be protected from concurrent access when OS has been started. `os_malloc()` function grabs a mutex before calling `malloc()`.
### Data structures
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/heap/os_free.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/heap/os_free.md b/docs/os/core_os/heap/os_free.md
index feb4946..9a22ec2 100644
--- a/docs/os/core_os/heap/os_free.md
+++ b/docs/os/core_os/heap/os_free.md
@@ -11,7 +11,7 @@ Frees previously allocated memory back to the heap.
| Arguments | Description |
|-----------|-------------|
-| mem | Pointer to memory being released |
+| `mem` | Pointer to memory being released |
#### Returned values
@@ -19,7 +19,7 @@ N/A
#### Notes
-Calls C-library *free()* behind the covers.
+Calls C-library `free()` under the covers.
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/heap/os_malloc.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/heap/os_malloc.md b/docs/os/core_os/heap/os_malloc.md
index ab6544b..65220a3 100644
--- a/docs/os/core_os/heap/os_malloc.md
+++ b/docs/os/core_os/heap/os_malloc.md
@@ -4,24 +4,24 @@
void *os_malloc(size_t size)
```
-Allocates *size* number of bytes from heap and returns a pointer to it.
+Allocates `size` number of bytes from heap and returns a pointer to it.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| size | Number of bytes to allocate |
+| `size` | Number of bytes to allocate |
#### Returned values
-<ptr>: pointer to memory allocated from heap.
-NULL: not enough memory available.
+`<ptr>`: pointer to memory allocated from heap.
+**NULL**: not enough memory available.
#### Notes
-*os_malloc()* calls *malloc()*, which is provided by C-library. The heap must be set up during platform initialization.
-Depending on which C-library you use, you might have to do the heap setup differently. Most often *malloc()* implementation will maintain a list of allocated and then freed memory blocks. If user asks for memory which cannot be satisfied from free list, they'll call platform's *sbrk()*, which then tries to grow the heap.
+`os_malloc()` calls `malloc()`, which is provided by the C-library. The heap must be set up during platform initialization.
+Depending on which C-library you use, you might have to do the heap setup differently. Most often `malloc()` implementation will maintain a list of allocated and then freed memory blocks. If user asks for memory which cannot be satisfied from free list, they'll call platform's `sbrk()`, which then tries to grow the heap.
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/heap/os_realloc.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/heap/os_realloc.md b/docs/os/core_os/heap/os_realloc.md
index e675155..7e2e08e 100644
--- a/docs/os/core_os/heap/os_realloc.md
+++ b/docs/os/core_os/heap/os_realloc.md
@@ -5,19 +5,19 @@ void *os_realloc(void *ptr, size_t size)
```
Tries to resize previously allocated memory block, and returns pointer to resized memory.
-ptr can be NULL, in which case the call is similar to calling *os_malloc()*.
+`ptr` can be **NULL**, in which case the call is similar to calling `os_malloc()`.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| ptr | Pointer to previously allocated memory |
-| size | New size to adjust the memory block to |
+| `ptr` | Pointer to previously allocated memory |
+| `size` | New size to adjust the memory block to |
#### Returned values
-NULL: size adjustment was not successful. <br>
-ptr: pointer to new start of memory block
+**NULL**: size adjustment was not successful. <br>
+`ptr`: pointer to new start of memory block
#### Notes
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/OS_MBUF_DATA.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/OS_MBUF_DATA.md b/docs/os/core_os/mbuf/OS_MBUF_DATA.md
index 27effcb..bce48af 100644
--- a/docs/os/core_os/mbuf/OS_MBUF_DATA.md
+++ b/docs/os/core_os/mbuf/OS_MBUF_DATA.md
@@ -14,8 +14,8 @@ Macro used to cast the data pointer of an mbuf to a given type.
| Arguments | Description |
|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
-| __type | Type to cast |
+| `__om` | Pointer to mbuf (struct os_mbuf *) |
+| `__type` | Type to cast |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md b/docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md
index a132362..ecbbb1f 100644
--- a/docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md
+++ b/docs/os/core_os/mbuf/OS_MBUF_LEADINGSPACE.md
@@ -14,13 +14,13 @@ Macro used to get the amount of leading space in an mbuf (in bytes).
| Arguments | Description |
|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
+| `__om` | Pointer to mbuf (struct os_mbuf *) |
<br>
#### Notes
-This macro works on both normal mbufs and packet header mbufs. The amount of leading space is the number of bytes between the current om_data pointer of the mbuf and the start of the mbuf user data buffer.
+This macro works on both normal mbufs and packet header mbufs. The amount of leading space is the number of bytes between the current `om_data` pointer of the mbuf and the start of the mbuf user data buffer.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md b/docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md
index 98faaec..c867b16 100644
--- a/docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md
+++ b/docs/os/core_os/mbuf/OS_MBUF_PKTHDR.md
@@ -14,7 +14,7 @@ Macro used to get a pointer to the os mbuf packet header of an mbuf.
| Arguments | Description |
|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
+| `__om` | Pointer to mbuf (struct os_mbuf *) |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md b/docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md
index 942dcd2..0a9dbf8 100644
--- a/docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md
+++ b/docs/os/core_os/mbuf/OS_MBUF_PKTHDR_TO_MBUF.md
@@ -12,7 +12,7 @@ Macro used to get a pointer to the mbuf given a pointer to the os mbuf packet he
| Arguments | Description |
|-----------|-------------|
-| __hdr | Pointer to os mbuf packet header (struct os_mbuf_pkthdr *) |
+| `__hdr` | Pointer to os mbuf packet header (struct os_mbuf_pkthdr *) |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md b/docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md
index 104cca3..fdab0b5 100644
--- a/docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md
+++ b/docs/os/core_os/mbuf/OS_MBUF_PKTLEN.md
@@ -14,7 +14,7 @@ Macro used to get the length of an entire mbuf chain.
| Arguments | Description |
|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
+| `__om` | Pointer to mbuf (struct os_mbuf *) |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md b/docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md
index d93d948..40a1825 100644
--- a/docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md
+++ b/docs/os/core_os/mbuf/OS_MBUF_TRAILINGSPACE.md
@@ -14,13 +14,13 @@ Macro used to get the amount of trailing space in an mbuf (in bytes).
| Arguments | Description |
|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *) |
+| `__om` | Pointer to mbuf (struct os_mbuf *) |
<br>
#### Notes
-This macro works on both normal mbufs and packet header mbufs. The amount of trailing space is the number of bytes between the current om_data pointer of the mbuf and the end of the mbuf.
+This macro works on both normal mbufs and packet header mbufs. The amount of trailing space is the number of bytes between the current `om_data` pointer of the mbuf and the end of the mbuf.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/OS_MBUF_USRHDR.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/OS_MBUF_USRHDR.md b/docs/os/core_os/mbuf/OS_MBUF_USRHDR.md
index e54cbb7..024f86e 100644
--- a/docs/os/core_os/mbuf/OS_MBUF_USRHDR.md
+++ b/docs/os/core_os/mbuf/OS_MBUF_USRHDR.md
@@ -13,7 +13,7 @@ Macro used to get a pointer to the user packet header of an mbuf.
| Arguments | Description |
|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *). Must be head of chain (i.e. a packet header mbuf) |
+| `__om` | Pointer to mbuf (struct os_mbuf *). Must be head of chain (i.e. a packet header mbuf) |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md b/docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md
index ebc8611..529d163 100644
--- a/docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md
+++ b/docs/os/core_os/mbuf/OS_MBUF_USRHDR_LEN.md
@@ -13,7 +13,7 @@ Macro used to retrieve the length of the user packet header in an mbuf.
| Arguments | Description |
|-----------|-------------|
-| __om | Pointer to mbuf (struct os_mbuf *). Must be head of chain (i.e. a packet header mbuf) |
+| `__om` | Pointer to mbuf (struct os_mbuf *). Must be head of chain (i.e. a packet header mbuf) |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/mbuf.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/mbuf.md b/docs/os/core_os/mbuf/mbuf.md
index 4f14818..01b6a8c 100644
--- a/docs/os/core_os/mbuf/mbuf.md
+++ b/docs/os/core_os/mbuf/mbuf.md
@@ -10,7 +10,7 @@ The main reason is to conserve memory. Consider a networking protocol that gener
### Packet Header mbuf
-Not all mbufs are created equal. The first mbuf in a chain of mbufs is a special mbuf called a "packet header mbuf". The reason that this mbuf is special is that it contains the length of all the data contained by the chain of mbufs (the packet length, in other words). The packet header mbuf may also contain a user defined structure (called a "user header") so that networking protocol specific information can be conveyed to various layers of the networking stack. Any mbufs that are part of the packet (i.e. in the mbuf chain but not the first one) are "normal" (i.e. non-packet header) mbufs. A normal mbuf does not have any packet header or user packet header structures in them; they only contain the basic mbuf header (`struct os_mbuf`). Figure 1 illustrates these two types of mbufs. Note that the numbers/text in parentheses denote the size of the structures/elements (in bytes) and that MBLEN is the memory block length of the memory pool used by the mbuf pool.
+Not all mbufs are created equal. The first mbuf in a chain of mbufs is a special mbuf called a "packet header mbuf". The reason that this mbuf is special is that it contains the length of all the data contained by the chain of mbufs (the packet length, in other words). The packet header mbuf may also contain a user defined structure (called a "user header") so that networking protocol specific information can be conveyed to various layers of the networking stack. Any mbufs that are part of the packet (i.e. in the mbuf chain but not the first one) are "normal" (i.e. non-packet header) mbufs. A normal mbuf does not have any packet header or user packet header structures in them; they only contain the basic mbuf header (`struct os_mbuf`). Figure 1 illustrates these two types of mbufs. Note that the numbers/text in parentheses denote the size of the structures/elements (in bytes) and that `MBLEN` is the memory block length of the memory pool used by the mbuf pool.
@@ -18,28 +18,28 @@ Not all mbufs are created equal. The first mbuf in a chain of mbufs is a special
Now let's take a deeper dive into the mbuf structure. Figure 2 illustrates a normal mbuf and breaks out the various fields in the `os_mbuf` structure.
-* The *om_data* field is a pointer to where the data starts inside the data buffer. Typically, mbufs that are allocated from the mbuf pool (discussed later) have their om_data pointer set to the start of the data buffer but there are cases where this may not be desirable (added a protocol header to a packet, for example).
-* The *om_flags* field is a set of flags used internally by the mbuf library. Currently, no flags have been defined.
-* The *om_pkthdr_len* field is the total length of all packet headers in the mbuf. For normal mbufs this is set to 0 as there is no packet or user packet headers. For packet header mbufs, this would be set to the length of the packet header structure (16) plus the size of the user packet header (if any). Note that it is this field which differentiates packet header mbufs from normal mbufs (i.e. if *om_pkthdr_len* is zero, this is a normal mbuf; otherwise it is a packet header mbuf).
-* The *om_len* field contains the amount of user data in the data buffer. When initially allocated, this field is 0 as there is no user data in the mbuf.
-* The *omp_pool* field is a pointer to the pool from which this mbuf has been allocated. This is used internally by the mbuf library.
-* The *omp_next* field is a linked list element which is used to chain mbufs.
+* The `om_data` field is a pointer to where the data starts inside the data buffer. Typically, mbufs that are allocated from the mbuf pool (discussed later) have their `om_data` pointer set to the start of the data buffer but there are cases where this may not be desirable (added a protocol header to a packet, for example).
+* The `om_flags` field is a set of flags used internally by the mbuf library. Currently, no flags have been defined.
+* The `om_pkthdr_len` field is the total length of all packet headers in the mbuf. For normal mbufs this is set to 0 as there is no packet or user packet headers. For packet header mbufs, this would be set to the length of the packet header structure (16) plus the size of the user packet header (if any). Note that it is this field which differentiates packet header mbufs from normal mbufs (i.e. if `om_pkthdr_len` is zero, this is a normal mbuf; otherwise it is a packet header mbuf).
+* The `om_len` field contains the amount of user data in the data buffer. When initially allocated, this field is 0 as there is no user data in the mbuf.
+* The `omp_pool` field is a pointer to the pool from which this mbuf has been allocated. This is used internally by the mbuf library.
+* The `omp_next` field is a linked list element which is used to chain mbufs.
-Figure 2 also shows a normal mbuf with actual values in the `os_mbuf` structure. This mbuf starts at address 0x1000 and is 256 bytes in total length. In this example, the user has copied 33 bytes into the data buffer starting at address 0x1010 (this is where om_data points). Note that the packet header length in this mbuf is 0 as it is not a packet header mbuf.
+Figure 2 also shows a normal mbuf with actual values in the `os_mbuf` structure. This mbuf starts at address 0x1000 and is 256 bytes in total length. In this example, the user has copied 33 bytes into the data buffer starting at address 0x1010 (this is where `om_data` points). Note that the packet header length in this mbuf is 0 as it is not a packet header mbuf.
-Figure 3 illustrates the packet header mbuf along with some chained mbufs (i.e a "packet"). In this example, the user header structure is defined to be 8 bytes. Note that in figure 3 we show a number of different mbufs with varying *om_data* pointers and lengths since we want to show various examples of valid mbufs. For all the mbufs (both packet header and normal ones) the total length of the memory block is 128 bytes.
+Figure 3 illustrates the packet header mbuf along with some chained mbufs (i.e a "packet"). In this example, the user header structure is defined to be 8 bytes. Note that in figure 3 we show a number of different mbufs with varying `om_data` pointers and lengths since we want to show various examples of valid mbufs. For all the mbufs (both packet header and normal ones) the total length of the memory block is 128 bytes.
### Mbuf pools
-Mbufs are collected into "mbuf pools" much like memory blocks. The mbuf pool itself contains a pointer to a memory pool. The memory blocks in this memory pool are the actual mbufs; both normal and packet header mbufs. Thus, the memory block (and corresponding memory pool) must be sized correctly. In other words, the memory blocks which make up the memory pool used by the mbuf pool must be at least: sizeof(struct os_mbuf) + sizeof(struct os_mbuf_pkthdr) + sizeof(struct user_defined_header) + desired minimum data buffer length. For example, if the developer wants mbufs to contain at least 64 bytes of user data and they have a user header of 12 bytes, the size of the memory block would be (at least): 64 + 12 + 16 + 8, or 100 bytes. Yes, this is a fair amount of overhead. However, the flexibility provided by the mbuf library usually outweighs overhead concerns.
+Mbufs are collected into "mbuf pools" much like memory blocks. The mbuf pool itself contains a pointer to a memory pool. The memory blocks in this memory pool are the actual mbufs; both normal and packet header mbufs. Thus, the memory block (and corresponding memory pool) must be sized correctly. In other words, the memory blocks which make up the memory pool used by the mbuf pool must be at least: `sizeof(struct os_mbuf)` + `sizeof(struct os_mbuf_pkthdr)` + `sizeof(struct user_defined_header)` + *desired minimum data buffer length*. For example, if the developer wants mbufs to contain at least 64 bytes of user data and they have a user header of 12 bytes, the size of the memory block would be (at least): 64 + 12 + 16 + 8, or 100 bytes. Yes, this is a fair amount of overhead. However, the flexibility provided by the mbuf library usually outweighs overhead concerns.
### Create mbuf pool
-Creating an mbuf pool is fairly simple: create a memory pool and then create the mbuf pool using that memory pool. Once the developer has determined the size of the user data needed per mbuf (this is based on the application/networking stack and is outside the scope of this discussion) and the size of the user header (if any), the memory blocks can be sized. In the example shown below, the application requires 64 bytes of user data per mbuf and also allocates a user header (called struct user_hdr). Note that we do not show the user header data structure as there really is no need; all we need to do is to account for it when creating the memory pool. In the example, we use the macro *MBUF_PKTHDR_OVERHEAD* to denote the amount of packet header overhead per mbuf and *MBUF_MEMBLOCK_OVERHEAD* to denote the total amount of overhead required per memory block. The macro *MBUF_BUF_SIZE* is used to denote the amount of payload that the application requires (aligned on a 32-bit boundary in thi
s case). All this leads to the total memory block size required, denoted by the macro *MBUF_MEMBLOCK_OVERHEAD*.
+Creating an mbuf pool is fairly simple: create a memory pool and then create the mbuf pool using that memory pool. Once the developer has determined the size of the user data needed per mbuf (this is based on the application/networking stack and is outside the scope of this discussion) and the size of the user header (if any), the memory blocks can be sized. In the example shown below, the application requires 64 bytes of user data per mbuf and also allocates a user header (called `struct user_hdr`). Note that we do not show the user header data structure as there really is no need; all we need to do is to account for it when creating the memory pool. In the example, we use the macro `MBUF_PKTHDR_OVERHEAD` to denote the amount of packet header overhead per mbuf and `MBUF_MEMBLOCK_OVERHEAD` to denote the total amount of overhead required per memory block. The macro `MBUF_BUF_SIZE` is used to denote the amount of payload that the application requires (aligned on a 32-bit boundary in t
his case). All this leads to the total memory block size required, denoted by the macro `MBUF_MEMBLOCK_OVERHEAD`.
```c
@@ -106,9 +106,9 @@ mbuf_usage_example1(uint8_t *mydata, int mydata_length)
}
```
-In `example2` we show use of the pullup api as this illustrates some of the typical pitfalls developers encounter when using mbufs. The first pitfall is one of alignment/padding. Depending on the processor and/or compiler, the sizeof() a structure may vary. Thus, the size of *my_protocol_header* may be different inside the packet data of the mbuf than the size of the structure on the stack or as a global variable, for instance. While some networking protcols may align protocol information on convenient processor boundaries many others try to conserve bytes "on the air" (i.e inside the packet data). Typical methods used to deal with this are "packing" the structure (i.e. force compiler to not pad) or creating protocol headers that do not require padding. `example2` assumes that one of these methods was used when defining the *my_protocol_header* structure.
+In `example2` we show use of the pullup api as this illustrates some of the typical pitfalls developers encounter when using mbufs. The first pitfall is one of alignment/padding. Depending on the processor and/or compiler, the `sizeof()` a structure may vary. Thus, the size of `my_protocol_header` may be different inside the packet data of the mbuf than the size of the structure on the stack or as a global variable, for instance. While some networking protcols may align protocol information on convenient processor boundaries many others try to conserve bytes "on the air" (i.e inside the packet data). Typical methods used to deal with this are "packing" the structure (i.e. force compiler to not pad) or creating protocol headers that do not require padding. `example2` assumes that one of these methods was used when defining the `my_protocol_header` structure.
-Another common pitfall occurs around endianness. A network protocol may be little endian or big endian; it all depends on the protocol specification. Processors also have an endianness; this means that the developer has to be careful that the processor endianness and the protocol endianness are handled correctly. In `example2`, some common networking functions are used: `ntohs()` and `ntohl()`. These are shorthand for "network order to host order, short" and "network order to host order, long". Basically, these functions convert data of a certain size (i.e. 16 bits, 32 bits, etc) to the endianness of the host. Network byte order is big-endian (most significant byte first), so these functions convert big-endian byte order to host order (thus, the implementation of these functions is host dependent). Note that the BLE networking stack "on the air" format is least signigicant byte first (i.e. little endian), so a "bletoh" function would have to take little endian format and convert to
host format.
+Another common pitfall occurs around endianness. A network protocol may be little endian or big endian; it all depends on the protocol specification. Processors also have an endianness; this means that the developer has to be careful that the processor endianness and the protocol endianness are handled correctly. In `example2`, some common networking functions are used: `ntohs()` and `ntohl()`. These are shorthand for "network order to host order, short" and "network order to host order, long". Basically, these functions convert data of a certain size (i.e. 16 bits, 32 bits, etc) to the endianness of the host. Network byte order is big-endian (most significant byte first), so these functions convert big-endian byte order to host order (thus, the implementation of these functions is host dependent). Note that the BLE networking stack "on the air" format is least signigicant byte first (i.e. little-endian), so a `bletoh` function would have to take little-endian format and convert to
host format.
A long story short: the developer must take care when copying structure data to/from mbufs and flat buffers!
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_adj.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_adj.md b/docs/os/core_os/mbuf/os_mbuf_adj.md
index a3881b4..c89a4a8 100644
--- a/docs/os/core_os/mbuf/os_mbuf_adj.md
+++ b/docs/os/core_os/mbuf/os_mbuf_adj.md
@@ -4,7 +4,7 @@
void os_mbuf_adj(struct os_mbuf *mp, int req_len);
```
-Trims *req_len* bytes from either the head (if positive) or tail (if negative) of an mbuf chain. Adjusts the packet length of the mbuf chain if *mp* points to a packet header mbuf. When trimming from the head, no mbufs are freed. When trimming from the tail, any mbufs of zero length left at the end of the chain are freed.
+Trims `req_len` bytes from either the head (if positive) or tail (if negative) of an mbuf chain. Adjusts the packet length of the mbuf chain if `mp` points to a packet header mbuf. When trimming from the head, no mbufs are freed. When trimming from the tail, any mbufs of zero length left at the end of the chain are freed.
<br>
@@ -12,8 +12,8 @@ Trims *req_len* bytes from either the head (if positive) or tail (if negative) o
| Arguments | Description |
|-----------|-------------|
-| mp | Pointer to mbuf. Can be head of a chain of mbufs, a single mbuf or a packet header mbuf |
-| req_len | Number of bytes to trim from head or tail of mbuf
+| `mp` | Pointer to mbuf. Can be head of a chain of mbufs, a single mbuf or a packet header mbuf |
+| `req_len` | Number of bytes to trim from head or tail of mbuf
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_append.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_append.md b/docs/os/core_os/mbuf/os_mbuf_append.md
index 423409f..8d66e18 100644
--- a/docs/os/core_os/mbuf/os_mbuf_append.md
+++ b/docs/os/core_os/mbuf/os_mbuf_append.md
@@ -4,7 +4,7 @@
int os_mbuf_append(struct os_mbuf *om, const void *data, uint16_t len)
```
-Appends a data buffer of length *len* to the end of an mbuf chain, adjusting packet length if *om* is a packet header mbuf. If not enough trailing space exists at the end of the mbuf chain, mbufs are allocated to hold the data.
+Appends a data buffer of length `len` to the end of an mbuf chain, adjusting packet length if `om` is a packet header mbuf. If not enough trailing space exists at the end of the mbuf chain, mbufs are allocated to hold the data.
<br>
@@ -12,9 +12,9 @@ Appends a data buffer of length *len* to the end of an mbuf chain, adjusting pac
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf. Can be head of a chain of mbufs, a single mbuf or a packet header mbuf |
-| data | Pointer to data buffer to copy from |
-| len | Number of bytes to copy from data buffer to the end of the mbuf |
+| `om` | Pointer to mbuf. Can be head of a chain of mbufs, a single mbuf or a packet header mbuf |
+| `data` | Pointer to data buffer to copy from |
+| `len` | Number of bytes to copy from data buffer to the end of the mbuf |
<br>
@@ -22,8 +22,8 @@ Appends a data buffer of length *len* to the end of an mbuf chain, adjusting pac
#### Returned values
0: success
-OS_ENOMEM: Could not allocate enough mbufs to hold data.
-OS_EINVAL: *om* was NULL on entry.
+`OS_ENOMEM`: Could not allocate enough mbufs to hold data.
+`OS_EINVAL`: `om` was **NULL** on entry.
<br>
@@ -32,7 +32,7 @@ If not enough mbufs were available the packet header length of the mbuf may get
<br>
-If any mbufs are allocated, they are allocated from the same pool as *om*
+If any mbufs are allocated, they are allocated from the same pool as `om`
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_concat.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_concat.md b/docs/os/core_os/mbuf/os_mbuf_concat.md
index 69df9f6..5ef32fd 100644
--- a/docs/os/core_os/mbuf/os_mbuf_concat.md
+++ b/docs/os/core_os/mbuf/os_mbuf_concat.md
@@ -12,8 +12,8 @@ Attaches a second mbuf chain onto the end of the first. If the first chain conta
| Arguments | Description |
|-----------|-------------|
-| first | Pointer to first mbuf chain |
-| second | Pointer to second mbuf chain |
+| `first` | Pointer to first mbuf chain |
+| `second` | Pointer to second mbuf chain |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_copydata.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_copydata.md b/docs/os/core_os/mbuf/os_mbuf_copydata.md
index ff2dcd0..25e24fe 100644
--- a/docs/os/core_os/mbuf/os_mbuf_copydata.md
+++ b/docs/os/core_os/mbuf/os_mbuf_copydata.md
@@ -4,7 +4,7 @@
int os_mbuf_copydata(const struct os_mbuf *m, int off, int len, void *dst)
```
-Copy data from an mbuf chain starting *off* bytes from the beginning, continuing for *len* bytes, into the indicated buffer.
+Copy data from an mbuf chain starting `off` bytes from the beginning, continuing for `len` bytes, into the indicated buffer.
<br>
@@ -12,10 +12,10 @@ Copy data from an mbuf chain starting *off* bytes from the beginning, continuing
| Arguments | Description |
|-----------|-------------|
-| m | Pointer to mbuf chain |
-| off | Start copy offset, in bytes, from beginning of mbuf chain |
-| len | Number of bytes to copy |
-| dst | Data buffer to copy into |
+| `m` | Pointer to mbuf chain |
+| `off` | Start copy offset, in bytes, from beginning of mbuf chain |
+| `len` | Number of bytes to copy |
+| `dst` | Data buffer to copy into |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_copyinto.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_copyinto.md b/docs/os/core_os/mbuf/os_mbuf_copyinto.md
index 6c18f57..ed6dd68 100644
--- a/docs/os/core_os/mbuf/os_mbuf_copyinto.md
+++ b/docs/os/core_os/mbuf/os_mbuf_copyinto.md
@@ -12,10 +12,10 @@ Copies the contents of a flat buffer into an mbuf chain, starting at the specifi
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf chain |
-| off | Start copy offset, in bytes, from beginning of mbuf chain |
-| src | Address from which bytes are copied |
-| len | Number of bytes to copy from src |
+| `om` | Pointer to mbuf chain |
+| `off` | Start copy offset, in bytes, from beginning of mbuf chain |
+| `src` | Address from which bytes are copied |
+| `len` | Number of bytes to copy from src |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_dup.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_dup.md b/docs/os/core_os/mbuf/os_mbuf_dup.md
index 13f9d9e..df32960 100644
--- a/docs/os/core_os/mbuf/os_mbuf_dup.md
+++ b/docs/os/core_os/mbuf/os_mbuf_dup.md
@@ -12,13 +12,13 @@ Duplicate a chain of mbufs. Return the start of the duplicated chain.
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf chain to duplicate |
+| `om` | Pointer to mbuf chain to duplicate |
<br>
#### Returned values
-Pointer to the duplicated chain or NULL if not enough mbufs were available to duplicate the chain.
+Pointer to the duplicated chain or **NULL** if not enough mbufs were available to duplicate the chain.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_extend.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_extend.md b/docs/os/core_os/mbuf/os_mbuf_extend.md
index 3986e37..3db1001 100644
--- a/docs/os/core_os/mbuf/os_mbuf_extend.md
+++ b/docs/os/core_os/mbuf/os_mbuf_extend.md
@@ -12,16 +12,16 @@ Increases the length of an mbuf chain by the specified amount. If there is not
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf chain |
-| len | Number of bytes to increase packet header |
+| `om` | Pointer to mbuf chain |
+| `len` | Number of bytes to increase packet header |
<br>
#### Returned values
-Pointer to start of extended data. Caller is guaranteed that there are at least *len* bytes from this pointer to the end of the mbuf.
+Pointer to start of extended data. Caller is guaranteed that there are at least `len` bytes from this pointer to the end of the mbuf.
-Returns NULL if extension fails due to insufficient mbufs or *len* too large.
+Returns **NULL** if extension fails due to insufficient mbufs or `len` too large.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_free_chain.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_free_chain.md b/docs/os/core_os/mbuf/os_mbuf_free_chain.md
index 660fa5a..17ec186 100644
--- a/docs/os/core_os/mbuf/os_mbuf_free_chain.md
+++ b/docs/os/core_os/mbuf/os_mbuf_free_chain.md
@@ -12,7 +12,7 @@ Frees a chain of mbufs
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf chain |
+| `om` | Pointer to mbuf chain |
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_get.md b/docs/os/core_os/mbuf/os_mbuf_get.md
index 96aa273..fe04dd6 100644
--- a/docs/os/core_os/mbuf/os_mbuf_get.md
+++ b/docs/os/core_os/mbuf/os_mbuf_get.md
@@ -4,7 +4,7 @@
struct os_mbuf *os_mbuf_get(struct os_mbuf_pool *omp, uint16_t leadingspace)
```
-Get an mbuf from the mbuf pool. The mbuf is allocated, and initialized prior to being returned. The *leadingspace* parameter allows the user to specify the amount of leading space in the allocated mbuf.
+Get an mbuf from the mbuf pool. The mbuf is allocated, and initialized prior to being returned. The `eadingspace` parameter allows the user to specify the amount of leading space in the allocated mbuf.
<br>
@@ -13,14 +13,14 @@ Get an mbuf from the mbuf pool. The mbuf is allocated, and initialized prior to
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf pool from which to allocate mbuf |
-| leadingspace | Amount of leading space in allocated mbuf. Request cannot exceed the mbuf data buffer size. |
+| `om` | Pointer to mbuf pool from which to allocate mbuf |
+| `leadingspace` | Amount of leading space in allocated mbuf. Request cannot exceed the mbuf data buffer size. |
<br>
#### Returned values
-Returns a pointer to the allocated mbuf or NULL if there are no mbufs available or *leadingspace* was too large.
+Returns a pointer to the allocated mbuf or **NULL** if there are no mbufs available or `leadingspace` was too large.
<br>
#### Notes
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md b/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md
index d975b4b..304aef8 100644
--- a/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md
+++ b/docs/os/core_os/mbuf/os_mbuf_get_pkthdr.md
@@ -4,7 +4,7 @@
struct os_mbuf *os_mbuf_get_pkthdr(struct os_mbuf_pool *omp, uint8_t pkthdr_len);
```
-Allocates a packet header mbuf from the mbuf pool pointed to by *omp*. Adds a user header of length *pkthdr_len* to packet header mbuf.
+Allocates a packet header mbuf from the mbuf pool pointed to by `omp`. Adds a user header of length `pkthdr_len` to packet header mbuf.
<br>
@@ -12,19 +12,19 @@ Allocates a packet header mbuf from the mbuf pool pointed to by *omp*. Adds a us
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf pool from which to allocate mbuf |
-| pkthdr_len | The user header packet length to allocate for the packet header mbuf |
+| `om` | Pointer to mbuf pool from which to allocate mbuf |
+| `pkthdr_len` | The user header packet length to allocate for the packet header mbuf |
<br>
#### Returned values
-Returns a pointer to the allocated mbuf or NULL if there are no mbufs available or the user packet header was too large.
+Returns a pointer to the allocated mbuf or **NULL** if there are no mbufs available or the user packet header was too large.
<br>
#### Notes
-The packet header mbuf returned will have its data pointer incremented by the sizeof(struct os_mbuf_pkthdr) as well as the amount of user header data (i.e. *pkthdr_len*). In other words, the data pointer is offset from the start of the mbuf by: sizeof(struct os_mbuf) + sizeof(struct os_mbuf_pkthdr) + pkthdr_len. The `om_pkthdr_len` element in the allocated mbuf is set to: sizeof(struct os_mbuf_pkthdr) + pkthdr_len.
+The packet header mbuf returned will have its data pointer incremented by the `sizeof(struct os_mbuf_pkthdr)` as well as the amount of user header data (i.e. `pkthdr_len`). In other words, the data pointer is offset from the start of the mbuf by: `sizeof(struct os_mbuf)` + `sizeof(struct os_mbuf_pkthdr)` + `pkthdr_len`. The `om_pkthdr_len` element in the allocated mbuf is set to: `sizeof(struct os_mbuf_pkthdr)` + `pkthdr_len`.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_memcmp.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_memcmp.md b/docs/os/core_os/mbuf/os_mbuf_memcmp.md
index 20ca328..b2315c9 100644
--- a/docs/os/core_os/mbuf/os_mbuf_memcmp.md
+++ b/docs/os/core_os/mbuf/os_mbuf_memcmp.md
@@ -12,10 +12,10 @@ Performs a memory compare of the specified region of an mbuf chain against a fla
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf |
-| off | Offset, in bytes, from start of mbuf to start of comparison |
-| data | Pointer to flat data buffer to compare |
-| len | Number of bytes to compare |
+| `om` | Pointer to mbuf |
+| `off` | Offset, in bytes, from start of mbuf to start of comparison |
+| `data` | Pointer to flat data buffer to compare |
+| `len` | Number of bytes to compare |
<br>
@@ -25,7 +25,7 @@ A value of zero means the memory regions are identical; all other values represe
<br>
#### Notes
-This function will compare bytes starting from *off* bytes from the start of the mbuf chain with a data buffer.
+This function will compare bytes starting from `off` bytes from the start of the mbuf chain with a data buffer.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_off.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_off.md b/docs/os/core_os/mbuf/os_mbuf_off.md
index 9c9f790..b6fa810 100644
--- a/docs/os/core_os/mbuf/os_mbuf_off.md
+++ b/docs/os/core_os/mbuf/os_mbuf_off.md
@@ -4,7 +4,7 @@
struct os_mbuf *os_mbuf_off(struct os_mbuf *om, int off, int *out_off)
```
-Given an offset in the packet (i.e. user data byte offset in the mbuf chain), return the mbuf and the offset in that mbuf where byte 'off' is located. Note that the offset is 'returned' in *out_off*.
+Given an offset in the packet (i.e. user data byte offset in the mbuf chain), return the mbuf and the offset in that mbuf where byte 'off' is located. Note that the offset is *returned* in `out_off`.
<br>
@@ -12,21 +12,21 @@ Given an offset in the packet (i.e. user data byte offset in the mbuf chain), re
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf |
-| off | Location in mbuf chain of desired byte offset |
-| out_off | Pointer to storage for the relative offset of the absolute location in the returned mbuf |
+| `om` | Pointer to mbuf |
+| `off` | Location in mbuf chain of desired byte offset |
+| `out_off` | Pointer to storage for the relative offset of the absolute location in the returned mbuf |
<br>
#### Returned values
-NULL if the offset is not within the mbuf chain or *om* points to NULL.
+**NULL** if the offset is not within the mbuf chain or `om` points to **NULL**.
<br>
#### Notes
The user is allowed to call this function with the length of the mbuf chain but no greater. This allows the user to get the mbuf and offset (in that mbuf) where the next user data byte should be written.
-While this api is provided to the user, other API are expected to be used by the applciation developer (i.e. `os_mbuf_append()` or `os_mbuf_copyinto()`).
+While this api is provided to the user, other APIs are expected to be used by the applciation developer (i.e. `os_mbuf_append()` or `os_mbuf_copyinto()`).
<br>
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_pool_init.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_pool_init.md b/docs/os/core_os/mbuf/os_mbuf_pool_init.md
index b3ae463..aa3b11b 100644
--- a/docs/os/core_os/mbuf/os_mbuf_pool_init.md
+++ b/docs/os/core_os/mbuf/os_mbuf_pool_init.md
@@ -13,10 +13,10 @@ Initialize an mbuf pool
| Arguments | Description |
|-----------|-------------|
-| omp | Pointer to mbuf pool to initialize |
-| mp | Pointer to memory pool used by mbuf pool |
-| buf_len | The size of the memory blocks in the memory pool used by the mbuf pool |
-| nbufs | The number of mbufs in the pool |
+| `omp` | Pointer to mbuf pool to initialize |
+| `mp` | Pointer to memory pool used by mbuf pool |
+| `buf_len` | The size of the memory blocks in the memory pool used by the mbuf pool |
+| `nbufs` | The number of mbufs in the pool |
<br>
@@ -26,7 +26,7 @@ Initialize an mbuf pool
<br>
#### Notes
-The parameter *buf_len* is the total size of the memory block. This must accommodate the os_mbuf structure, the os_mbuf_pkthdr structure, any user headers plus the desired amount of user data.
+The parameter `buf_len` is the total size of the memory block. This must accommodate the `os_mbuf` structure, the `os_mbuf_pkthdr` structure, any user headers plus the desired amount of user data.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_prepend.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_prepend.md b/docs/os/core_os/mbuf/os_mbuf_prepend.md
index ab146df..91629ec 100644
--- a/docs/os/core_os/mbuf/os_mbuf_prepend.md
+++ b/docs/os/core_os/mbuf/os_mbuf_prepend.md
@@ -12,18 +12,18 @@ Increases the length of an mbuf chain by adding data to the front. If there is
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf |
-| len | Length, in bytes, to prepend |
+| `om` | Pointer to mbuf |
+| `len` | Length, in bytes, to prepend |
<br>
#### Returned values
-Pointer to mbuf at head of chain; NULL if not enough mbufs were available to accommodate *len*.
+Pointer to mbuf at head of chain; **NULL** if not enough mbufs were available to accommodate `len`.
<br>
#### Notes
-If *om* is a packet header mbuf, the total length of the packet is adjusted by *len*. Note that the returned mbuf may not point to *om* if insufficient leading space was available in *om*.
+If `om` is a packet header mbuf, the total length of the packet is adjusted by `len`. Note that the returned mbuf may not point to `om` if insufficient leading space was available in `om`.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/mbuf/os_mbuf_pullup.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/mbuf/os_mbuf_pullup.md b/docs/os/core_os/mbuf/os_mbuf_pullup.md
index 3a9fdc4..8bce3ad 100644
--- a/docs/os/core_os/mbuf/os_mbuf_pullup.md
+++ b/docs/os/core_os/mbuf/os_mbuf_pullup.md
@@ -4,7 +4,7 @@
struct os_mbuf *os_mbuf_pullup(struct os_mbuf *om, uint16_t len)
```
-Rearrange an mbuf chain so that len bytes are contiguous, and in the data area of an mbuf (so that OS_MBUF_DATA() will work on a structure of size len.) Returns the resulting mbuf chain on success, free's it and returns NULL on failure.
+Rearrange an mbuf chain so that len bytes are contiguous, and in the data area of an mbuf (so that `OS_MBUF_DATA()` will work on a structure of size `len`.) Returns the resulting mbuf chain on success, free's it and returns **NULL** on failure.
<br>
@@ -12,13 +12,13 @@ Rearrange an mbuf chain so that len bytes are contiguous, and in the data area o
| Arguments | Description |
|-----------|-------------|
-| om | Pointer to mbuf |
-| len | Length, in bytes, to pullup (make contiguous in mbuf) |
+| `om` | Pointer to mbuf |
+| `len` | Length, in bytes, to pullup (make contiguous in mbuf) |
<br>
#### Returned values
-Pointer to mbuf at head of chain; NULL if not enough mbufs were available to accommodate *len* or if the requested pullup size was too large.
+Pointer to mbuf at head of chain; **NULL** if not enough mbufs were available to accommodate `len` or if the requested pullup size was too large.
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md b/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
index dc7fc33..65aaaae 100644
--- a/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
+++ b/docs/os/core_os/memory_pool/OS_MEMPOOL_BYTES.md
@@ -4,22 +4,22 @@
OS_MEMPOOL_BYTES(n,blksize)
```
-Calculates how many bytes of memory is used by *n* number of elements, when individual element size is *blksize* bytes.
+Calculates how many bytes of memory is used by `n` number of elements, when individual element size is `blksize` bytes.
<br>
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| n | Number of elements |
-| blksize | Size of an element is number of bytes |
+| `n` | Number of elements |
+| `blksize` | Size of an element is number of bytes |
#### Returned values
The number of bytes used by the memory pool.
<br>
#### Notes
-OS_MEMPOOL_BYTES is a macro and not a function.
+`OS_MEMPOOL_BYTES` is a macro and not a function.
<br>
#### Example
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md b/docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md
index 577547e..e0f3247 100644
--- a/docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md
+++ b/docs/os/core_os/memory_pool/OS_MEMPOOL_SIZE.md
@@ -4,31 +4,31 @@
OS_MEMPOOL_SIZE(n,blksize)
```
-Calculates the number of os_membuf_t elements used by *n* blocks of size *blksize* bytes.
+Calculates the number of `os_membuf_t` elements used by `n` blocks of size `blksize` bytes.
-Note that os_membuf_t is used so that memory blocks are aligned on OS_ALIGNMENT boundaries.
+Note that `os_membuf_t` is used so that memory blocks are aligned on `OS_ALIGNMENT` boundaries.
-The *blksize* variable is the minimum number of bytes required for each block; the actual block size is padded so that each block is aligned on OS_ALIGNMENT boundaries.
+The `blksize` variable is the minimum number of bytes required for each block; the actual block size is padded so that each block is aligned on `OS_ALIGNMENT` boundaries.
<br>
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| n | Number of elements |
-| blksize | Size of an element is number of bytes |
+| `n` | Number of elements |
+| `blksize` | Size of an element is number of bytes |
#### Returned values
-The number of os_membuf_t elements used by the memory pool. Note that os_membuf_t is defined to be a unsigned, 32-bit integer when OS_ALIGNMENT is 4 and an unsigned, 64-bit integer when OS_ALIGNMENT is 8.
+The number of `os_membuf_t` elements used by the memory pool. Note that `os_membuf_t` is defined to be a unsigned, 32-bit integer when `OS_ALIGNMENT` is 4 and an unsigned, 64-bit integer when `OS_ALIGNMENT` is 8.
<br>
#### Notes
-OS_MEMPOOL_SIZE is a macro and not a function.
+`OS_MEMPOOL_SIZE` is a macro and not a function.
<br>
#### Example
-Here we define a memory buffer to be used by a memory pool using OS_MEMPOOL_SIZE
+Here we define a memory buffer to be used by a memory pool using `OS_MEMPOOL_SIZE`
```c
#define NUM_BLOCKS (16)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/memory_pool/memory_pool.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/memory_pool.md b/docs/os/core_os/memory_pool/memory_pool.md
index 7009920..0a9cc77 100644
--- a/docs/os/core_os/memory_pool/memory_pool.md
+++ b/docs/os/core_os/memory_pool/memory_pool.md
@@ -16,7 +16,7 @@ The next order of business is to allocate the memory used by the memory pool. Th
In order to simplify this for the user two macros have been provided: `OS_MEMPOOL_BYTES(n, blksize)` and `OS_MEMPOOL_SIZE(n, blksize)`. The first macro returns the number of bytes needed for the memory pool while the second returns the number of `os_membuf_t` elements required by the memory pool. The `os_membuf_t` type is used to guarantee that the memory buffer used by the memory pool is aligned on the correct boundary.
-Here are some examples. Note that if a custom malloc implementation is used it must guarantee that the memory buffer used by the pool is allocated on the correct boundary (i.e. OS_ALIGNMENT).
+Here are some examples. Note that if a custom malloc implementation is used it must guarantee that the memory buffer used by the pool is allocated on the correct boundary (i.e. `OS_ALIGNMENT`).
```c
void *my_memory_buffer;
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/aac53ed0/docs/os/core_os/memory_pool/os_memblock_get.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/memory_pool/os_memblock_get.md b/docs/os/core_os/memory_pool/os_memblock_get.md
index e341d4f..bdb8435 100644
--- a/docs/os/core_os/memory_pool/os_memblock_get.md
+++ b/docs/os/core_os/memory_pool/os_memblock_get.md
@@ -4,18 +4,18 @@
void *os_memblock_get(struct os_mempool *mp)
```
-Allocate an element from the memory pool. If successful, you'll get a pointer to allocated element. If there are no elements available, you'll get NULL as response.
+Allocate an element from the memory pool. If successful, you'll get a pointer to allocated element. If there are no elements available, you'll get **NULL** as response.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| mp | Pool where element is getting allocated from |
+| `mp` | Pool where element is getting allocated from |
#### Returned values
-NULL: no elements available.
+**NULL**: no elements available.
<pointer>: pointer to allocated element.
#### Notes
[05/21] incubator-mynewt-site git commit: Updated system configuration
Posted by ad...@apache.org.
Updated system configuration
Updated for new system configuration interface
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/05b828ca
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/05b828ca
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/05b828ca
Branch: refs/heads/develop
Commit: 05b828cac110eae39c492e2d89b3a6dc90f1308b
Parents: 31d5631
Author: David G. Simmons <sa...@mac.com>
Authored: Fri Oct 28 12:22:29 2016 -0400
Committer: David G. Simmons <sa...@mac.com>
Committed: Fri Oct 28 12:22:29 2016 -0400
----------------------------------------------------------------------
docs/os/get_started/vocabulary.md | 31 +++++++++++++++---
docs/os/tutorials/bleprph/bleprph-app.md | 6 ++--
docs/os/tutorials/bletiny_project.md | 45 ++++++++++++++++++---------
3 files changed, 59 insertions(+), 23 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/05b828ca/docs/os/get_started/vocabulary.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/vocabulary.md b/docs/os/get_started/vocabulary.md
index f176d6a..729bf2e 100644
--- a/docs/os/get_started/vocabulary.md
+++ b/docs/os/get_started/vocabulary.md
@@ -140,15 +140,12 @@ Usage:
newt target [command]
Available Commands:
+ config View target system configuration
copy Copy target
create Create a target
delete Delete target
set Set target configuration variable
show View target configuration variables
- vars Show variable names
-
-Flags:
- -h, --help help for target
Global Flags:
-l, --loglevel string Log level (default "WARN")
@@ -160,3 +157,29 @@ Global Flags:
Use "newt target [command] --help" for more information about a command.
$
```
+
+###Configuration
+
+There are a lot of configuration options available when building your application in MyNewt. System Configuration options are set in
+a file called `syscfg.yml` and you will find these configuration files throughout the MyNewt packages. While you can edit these
+files directly to change some default settings, it is best to override the default settings in a `syscfg.yml` file in your project
+directory rather than editing the package configurations directly.
+
+To see all **all** the system configuration settings, simply type
+
+```no-highlight
+$ newt target config <target-name>
+...
+* PACKAGE: sys/stats
+ * Setting: STATS_CLI
+ * Description: Expose the "stat" shell command.
+ * Value: 0
+ * Setting: STATS_NAMES
+ * Description: Include and report the textual name of each statistic.
+ * Value: 0
+ * Setting: STATS_NEWTMGR
+ * Description: Expose the "stat" newtmgr command.
+ * Value: 0
+...
+$
+```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/05b828ca/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
index a0a51c1..4a8cff3 100644
--- a/docs/os/tutorials/bleprph/bleprph-app.md
+++ b/docs/os/tutorials/bleprph/bleprph-app.md
@@ -32,15 +32,13 @@ $ 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 target set myperiph cflags=-DSTATS_NAME_ENABLE
-Target targets/myperiph successfully set pkg.cflags to -DSTATS_NAME_ENABLE
$ newt build blerph
Building target targets/myperiph
...
-Linking /Users/dsimmons/dev/nrf52dk/bin/targets/myperiph/app/apps/bleprph/bleprph.elf
+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: /Users/dsimmons/dev/nrf52dk/bin/targets/myperiph/app/apps/bleprph/bleprph.img
+App image succesfully generated: ~/dev/nrf52dk/bin/targets/myperiph/app/apps/bleprph/bleprph.img
$ newt load myperiph
Loading app image into slot 1
```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/05b828ca/docs/os/tutorials/bletiny_project.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bletiny_project.md b/docs/os/tutorials/bletiny_project.md
index 51f4594..083393c 100644
--- a/docs/os/tutorials/bletiny_project.md
+++ b/docs/os/tutorials/bletiny_project.md
@@ -72,8 +72,6 @@ $ newt target set myble app=@apache-mynewt-core/apps/bletiny
Target targets/myble successfully set target.app to @apache-mynewt-core/apps/bletiny
$ newt target set myble build_profile=optimized
Target targets/myble successfully set target.build_profile to optimized
-$ newt target set myble cflags=-DSTATS_NAME_ENABLE
-Target targets/myble successfully set pkg.cflags to DSTATS_NAME_ENABLE
```
Use the same `newt target set` command to set the following definition for the bootloader target -- again, make sure you use the correct value for the bsp based on which version of the board you have..
@@ -104,6 +102,21 @@ targets/nrf52_boot
build_profile=optimized
```
+Since we're interested in seeing the stats, we'll need to enable the stats module for the target. By default, the stats module is not enabled, so we will have to override the default behavior.
+To do this, you'll need to create a configuration file `syscfg.yml` in the app directory. from the target definition above, you can see that the app is in `apache-mynewt-core/apps/bletiny`
+so that is where you'll put your configuration file.
+
+```
+# Package: apps/bletiny
+
+syscfg.vals:
+ SHELL_TASK: 1
+ STATS_NAMES: 1
+ STATS_CLI: 1
+```
+
+The first configuration value turns on the Shell Task, and we'll need this to get to the shell. The next 2 enable the names for the various stats, and then turns on the stats CLI option.
+
### Build targets
Then build the two targets.
@@ -194,6 +207,8 @@ prompt set >
You'll notice that there is an ever-increasing counter before the prompt (and before any output to the terminal).
This is just a counter kept by the MCU.
+**Note**: If you want to have a shell prompt by default, simply add the line: `CONSOLE_PROMPT: 1` to your `syscfg.yml` file and it will be turned on by default.
+
<br>
Try the `tasks` command.
@@ -213,19 +228,19 @@ Tasks:
Try specifying a BLE related stat, for example `ble_ll`. You should see some HCI (Host Controller Interface) command counts.
```hl_lines="1"
-stat ble_ll
-4986297:hci_cmds: 5
-4986297:hci_cmd_errs: 0
-4986299:hci_events_sent: 5
-4986301:bad_ll_state: 0
-4986303:bad_acl_hdr: 0
-4986306:rx_adv_pdu_crc_ok: 0
-4986308:rx_adv_pdu_crc_err: 0
-4986311:rx_adv_bytes_crc_ok: 0
-4986314:rx_adv_bytes_crc_err: 0
-4986317:rx_data_pdu_crc_ok: 0
-4986319:rx_data_pdu_crc_err: 0
-4986322:rx_data_bytes_crc_ok: 0
+241133: > stat ble_ll
+hci_cmds: 11
+241888:hci_cmd_errs: 0
+241888:hci_events_sent: 11
+241890:bad_ll_state: 0
+241890:bad_acl_hdr: 0
+241891:no_bufs: 0
+241891:rx_adv_pdu_crc_ok: 0
+241892:rx_adv_pdu_crc_err: 0
+241893:rx_adv_bytes_crc_ok: 0
+241894:rx_adv_bytes_crc_err: 0
+241895:rx_data_pdu_crc_ok: 0
+241895:rx_data_pdu_crc_err: 0
<snip>
```
[14/21] incubator-mynewt-site git commit: Merge branch 'patch-1' of
https://github.com/samvrlewis/incubator-mynewt-site into develop
Posted by ad...@apache.org.
Merge branch 'patch-1' of https://github.com/samvrlewis/incubator-mynewt-site into develop
This closes #125
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/6077ca7a
Tree: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/tree/6077ca7a
Diff: http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/diff/6077ca7a
Branch: refs/heads/develop
Commit: 6077ca7a3b0f15b075523f4dae6b45cc7655de7d
Parents: 9aae513 2493b0f
Author: aditihilbert <ad...@runtime.io>
Authored: Fri Nov 11 15:51:18 2016 -0800
Committer: aditihilbert <ad...@runtime.io>
Committed: Fri Nov 11 15:51:18 2016 -0800
----------------------------------------------------------------------
docs/os/tutorials/bletiny_project.md | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
----------------------------------------------------------------------