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 19:34:45 UTC
[37/40] incubator-mynewt-site git commit: This closes #118.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/core_os/time/os_time.md
----------------------------------------------------------------------
diff --git a/docs/os/core_os/time/os_time.md b/docs/os/core_os/time/os_time.md
index 52d0376..eee868f 100644
--- a/docs/os/core_os/time/os_time.md
+++ b/docs/os/core_os/time/os_time.md
@@ -17,20 +17,18 @@ 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 the epoch (00:00:00 Jan 1, 1970 UTC).
-
-```c
+`struct os_timeval` represents the number of seconds elapsed since 00:00:00 Jan 1, 1970 UTC.
+<pre>
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.
-
-```c
+<pre>
struct os_timezone {
int16_t tz_minuteswest;
int16_t tz_dsttime;
@@ -42,7 +40,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/1720300a/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 8b70236..a9199ba 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/1720300a/docs/os/get_started/cross_tools.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/cross_tools.md b/docs/os/get_started/cross_tools.md
index b68c1e9..af7b8a3 100644
--- a/docs/os/get_started/cross_tools.md
+++ b/docs/os/get_started/cross_tools.md
@@ -58,11 +58,11 @@ lrwxr-xr-x 1 <user> admin 36 Sep 17 16:22 /usr/local/bin/openocd -> ../Cellar
On a Debian-based Linux distribution, gcc 4.9.3 for ARM can be installed with
apt-get as documented below. The steps are explained in depth at
-[https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa](https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa).
+[https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded](https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded).
```no-highlight
$ sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi
-$ sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
+$ sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
$ sudo apt-get update
$ sudo apt-get install gcc-arm-none-eabi
$ sudo apt-get install gdb-arm-none-eabi
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/get_started/project_create.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/project_create.md b/docs/os/get_started/project_create.md
index 9eb09ce..65358d6 100644
--- a/docs/os/get_started/project_create.md
+++ b/docs/os/get_started/project_create.md
@@ -77,20 +77,6 @@ targets.
**NOTE:** the actual code and package files are not installed
(except the template for `main.c`). See the next step for installing the packages.
-**NOTE:** By default newt uses the code in the master branch. This is the latest stable
-code for newt. If you need to use a different branch, you can set this in the project.yml
-file.
-
-```no-highlight
-repository.apache-mynewt-core:
- type: github
- vers: 0-latest
- user: apache
- repo: incubator-mynewt-core
-```
-Changing to 0-dev will put you on the develop branch. **The Develop Branch may not be stable and
-you may encounter bugs or other problems.**
-
<br>
### Newt Install
@@ -114,32 +100,8 @@ Once _newt install_ has successfully finished, the contents of _apache-mynewt-co
```no-highlight
$ tree -L 2 repos/apache-mynewt-core/
-repos/apache-mynewt-core/
-\u251c\u2500\u2500 CODING_STANDARDS.md
-\u251c\u2500\u2500 DISCLAIMER
-\u251c\u2500\u2500 LICENSE
-\u251c\u2500\u2500 NOTICE
-\u251c\u2500\u2500 README.md
-\u251c\u2500\u2500 RELEASE_NOTES.md
-\u251c\u2500\u2500 apps
-\u2502�� \u251c\u2500\u2500 blecent
-\u2502�� \u251c\u2500\u2500 blehci
-\u2502�� \u251c\u2500\u2500 bleprph
-\u2502�� \u251c\u2500\u2500 bletest
-\u2502�� \u251c\u2500\u2500 bletiny
-\u2502�� \u251c\u2500\u2500 bleuart
-\u2502�� \u251c\u2500\u2500 blinky
-\u2502�� \u251c\u2500\u2500 boot
-\u2502�� \u251c\u2500\u2500 ffs2native
-\u2502�� \u251c\u2500\u2500 luatest
-\u2502�� \u251c\u2500\u2500 slinky
-\u2502�� \u2514\u2500\u2500 test
-\u251c\u2500\u2500 compiler
-\u2502�� \u251c\u2500\u2500 arm-none-eabi-m0
-\u2502�� \u251c\u2500\u2500 arm-none-eabi-m4
-\u2502�� \u2514\u2500\u2500 sim
-\u251c\u2500\u2500 drivers
-\u2502�� \u2514\u2500\u2500 uart_bitbang
+.
+<snip>
\u251c\u2500\u2500 fs
\u2502�� \u251c\u2500\u2500 fs
\u2502�� \u2514\u2500\u2500 nffs
@@ -149,16 +111,12 @@ repos/apache-mynewt-core/
\u2502�� \u2514\u2500\u2500 mcu
\u251c\u2500\u2500 libs
\u2502�� \u251c\u2500\u2500 baselibc
-\u2502�� \u251c\u2500\u2500 bleuart
-\u2502�� \u251c\u2500\u2500 boot_serial
\u2502�� \u251c\u2500\u2500 bootutil
\u2502�� \u251c\u2500\u2500 cmsis-core
\u2502�� \u251c\u2500\u2500 console
-\u2502�� \u251c\u2500\u2500 crash_test
\u2502�� \u251c\u2500\u2500 elua
\u2502�� \u251c\u2500\u2500 flash_test
\u2502�� \u251c\u2500\u2500 imgmgr
-\u2502�� \u251c\u2500\u2500 inet_def_service
\u2502�� \u251c\u2500\u2500 json
\u2502�� \u251c\u2500\u2500 mbedtls
\u2502�� \u251c\u2500\u2500 newtmgr
@@ -166,26 +124,10 @@ repos/apache-mynewt-core/
\u2502�� \u251c\u2500\u2500 shell
\u2502�� \u251c\u2500\u2500 testreport
\u2502�� \u251c\u2500\u2500 testutil
-\u2502�� \u251c\u2500\u2500 tinycrypt
-\u2502�� \u251c\u2500\u2500 util
-\u2502�� \u2514\u2500\u2500 wifi_mgmt
+\u2502�� \u2514\u2500\u2500 util
\u251c\u2500\u2500 net
\u2502�� \u2514\u2500\u2500 nimble
-\u251c\u2500\u2500 project.yml
-\u251c\u2500\u2500 repository.yml
-\u251c\u2500\u2500 sys
-\u2502�� \u251c\u2500\u2500 config
-\u2502�� \u251c\u2500\u2500 coredump
-\u2502�� \u251c\u2500\u2500 fcb
-\u2502�� \u251c\u2500\u2500 id
-\u2502�� \u251c\u2500\u2500 log
-\u2502�� \u251c\u2500\u2500 mn_socket
-\u2502�� \u251c\u2500\u2500 reboot
-\u2502�� \u2514\u2500\u2500 stats
-\u2514\u2500\u2500 targets
- \u2514\u2500\u2500 unittest
-
-61 directories, 8 files
+<snip>
```
As you can see, the core of the Apache Mynewt operating system has been brought
@@ -208,13 +150,6 @@ Compiling flash_map.c
<snip>
```
-**NOTE:** If you've installed the latest gcc using homebrew on your Mac, you should downgrade to gcc-5 in order to use MyNewt.
-
-```
-$ brew uninstall gcc-6
-$ brew link gcc-5
-```
-
<br>
To test all the packages in a project, specify `all` instead of the package name.
@@ -223,11 +158,10 @@ To test all the packages in a project, specify `all` instead of the package name
$ newt test all
...lots of compiling and testing...
...about 2 minutes later ...
-Compiling mn_sock_test.c
-Archiving mn_socket.a
-Linking test_mn_socket
-Executing test: /Users/dsimmons/myproj/bin/unittest/sys/mn_socket/test_mn_socket
-Passed tests: [libs/json libs/util libs/mbedtls net/nimble/host hw/hal libs/bootutil sys/log sys/config sys/fcb fs/nffs libs/os libs/boot_serial sys/mn_socket]
+Archiving bootutil.a
+Linking test_bootutil
+Executing test: /myproj/bin/unittest/libs/bootutil/test_bootutil
+Passed tests: [net/nimble/host fs/nffs libs/os hw/hal libs/mbedtls libs/util sys/config libs/bootutil]
All tests passed
```
@@ -239,17 +173,21 @@ To build and run your new application, simply issue the following command:
```
$ newt build my_blinky_sim
-Building target targets/my_blinky_sim
+Compiling base64.c
+Compiling cbmem.c
+Compiling datetime.c
+Compiling tpq.c
+Archiving util.a
Compiling main.c
Archiving blinky.a
-Compiling hal_bsp.c
-Compiling os_bsp.c
-Compiling sbrk.c
-Archiving native.a
Compiling flash_map.c
+Compiling hal_flash.c
+Archiving hal.a
+Compiling cons_fmt.c
+Compiling cons_tty.c
<snip>
Linking blinky.elf
-App successfully built: /Users/dsimmons/myproj/bin/my_blinky_sim/apps/blinky/blinky.elf
+App successfully built: /Users/sterling/dev/tmp/my_app/bin/my_blinky_sim/apps/blinky/blinky.elf
```
<br>
@@ -260,10 +198,16 @@ You can run the simulated version of your project and see the simulated LED
blink.
```
-$ ./bin/my_blinky_sim/apps/blinky/blinky.elf
-hal_gpio set pin 1 to 0
+$ newt run my_blinky_sim
+No download script for BSP hw/bsp/native
+Debugging /workspace/bin/my_blinky_sim/apps/blinky/blinky.elf
+<snip>
+Reading symbols from /workspace/bin/my_blinky_sim/apps/blinky/blinky.elf...done.
+(gdb)
```
+Type `r` at the `(gdb)` prompt to run the project. You will see an output indicating that the `hal_gpio` pin is toggling between 1 and 0 in a simulated blink.
+
<br>
### Complete
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/get_started/vocabulary.md
----------------------------------------------------------------------
diff --git a/docs/os/get_started/vocabulary.md b/docs/os/get_started/vocabulary.md
index f35f019..3377f17 100644
--- a/docs/os/get_started/vocabulary.md
+++ b/docs/os/get_started/vocabulary.md
@@ -46,10 +46,6 @@ relies upon.
* ```repository.apache-mynewt-core```: Defines the repository information for
the ```apache-mynewt-core``` repository.
-* ```vers=0-latest```: Defines the repository version. This string will use the
-latest code in the 'Master' github branch. To use the latest version in the
-develop branch, just change it to ```vers=0-dev```
-
Repositories are versioned collections of packages.
Projects can rely on remote repositories for functionality, and the newt tool
@@ -133,59 +129,34 @@ 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:
+
+Usage:
newt target [flags]
newt target [command]
-Available Commands:
- config View target system configuration
- copy Copy target
+Available Commands:
+ show View target configuration variables
+ set Set target configuration variable
create Create a target
delete Delete target
- set Set target configuration variable
- show View target configuration variables
-
-Global Flags:
- -l, --loglevel string Log level (default "WARN")
- -o, --outfile string Filename to tee output to
- -q, --quiet Be quiet; only display error output
- -s, --silent Be silent; don't output anything
- -v, --verbose Enable verbose output when executing commands
+ copy Copy target
+ vars Show variable names
-Use "newt target [command] --help" for more information about a command.
-$
-```
+Flags:
+ -h, --help=false: help for target
-###Configuration
+Global Flags:
+ -l, --loglevel="WARN": Log level, defaults to WARN.
+ -o, --outfile="": Filename to tee log output to
+ -q, --quiet=false: Be quiet; only display error output.
+ -s, --silent=false: Be silent; don't output anything.
+ -v, --verbose=false: Enable verbose output when executing commands.
-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.
+Additional help topics:
-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
-...
-$
+Use "newt help [command]" for more information about a command.
+$
```
-
-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.
-
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/modules/baselibc.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/baselibc.md b/docs/os/modules/baselibc.md
index 377eca8..fe650ac 100644
--- a/docs/os/modules/baselibc.md
+++ b/docs/os/modules/baselibc.md
@@ -1,8 +1,6 @@
# 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.
@@ -10,17 +8,11 @@ Baselibc comes from https://github.com/PetteriAimonen/Baselibc.git
###Description
-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.
+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.
###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
@@ -32,13 +24,12 @@ uses baselibc. Its project description file `boot.yml` looks like the following:
- libs/console/stub
- libs/util
- libs/baselibc
-```
+ ```
###List of Functions
-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).
+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).
-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/1720300a/docs/os/modules/bootloader/bootloader.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/bootloader/bootloader.md b/docs/os/modules/bootloader/bootloader.md
index 3908e73..55b6d44 100644
--- a/docs/os/modules/bootloader/bootloader.md
+++ b/docs/os/modules/bootloader/bootloader.md
@@ -1,197 +1,15 @@
#Bootloader
-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:
+Insert synopsis here
-* 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:
+###Description
-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.
+Describe module here, special features, how pieces fit together etc.
-###Limitations
+###Data structures
-The boot loader currently only supports images with the following
-characteristics:
-
-* Built to run from flash.
-* Build to run from a fixed location (i.e., position-independent).
-
-
-###Image Format
-
-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;
- 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;
- 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;
-};
-```
-
-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.
-
-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
-
-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
-
-
-
-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 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.
-
-
-```c
-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;
-};
-```
-
-
-```c
-struct boot_status {
- uint32_t idx; /* Which area we're operating on */
- uint8_t state; /* Which part of the swapping process are we at */
-};
-```
-
-
-
-###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:
-
-
-###Verifying integrity of image
-
-
-
-###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
-
-
-###Example
-
-
-###Dependencies
-
-The bootloader depends on the following OS kernel functions:
-
-
-The bootloader does not depend on any flash file system.
+Replace this with the list of data structures used, why, any neat features
###List of Functions
@@ -200,3 +18,29 @@ The bootloader does not depend on any flash file system.
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)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/modules/console/console.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/console/console.md b/docs/os/modules/console/console.md
index 9d5b738..53d195b 100644
--- a/docs/os/modules/console/console.md
+++ b/docs/os/modules/console/console.md
@@ -1,10 +1,7 @@
#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.
@@ -16,10 +13,8 @@ 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 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:
-
+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:
```no-highlight
pkg.name: libs/shell
pkg.vers: 0.1
@@ -31,19 +26,11 @@ following pkg.yml file:
pkg.identities:
- SHELL
```
-
The project .yml file decides which version of the console pkg should be included.
-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.
-
+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.
-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
@@ -55,18 +42,10 @@ stub instead, and the pkg.yml file for the project boot pkg looks like the follo
- 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, 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 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.
-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.
+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.
###Data structures
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/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 01568ea..ea1c7d7 100644
--- a/docs/os/modules/console/console_blocking_mode.md
+++ b/docs/os/modules/console/console_blocking_mode.md
@@ -1,12 +1,10 @@
## <font color="#F2853F" style="font-size:24pt"> console_blocking_mode </font>
-```c
-void console_blocking_mode(void)
+```no-highlight
+ 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
@@ -22,7 +20,7 @@ N/A
Here is an example of calling `console_blocking_mode` and printing crash information from an assert to help debug.
-```c
+```no-highlight
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/1720300a/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 086307c..6d58c67 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>
-```c
-void console_echo(int on)
+```no-highlight
+ 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,14 +19,11 @@ None
#### Notes
-None
-
#### Example
-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.
+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.
-```c
+```no-highlight
static int
nmgr_def_console_echo(struct nmgr_jbuf *njb)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/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 9438208..d56b2b6 100644
--- a/docs/os/modules/console/console_init.md
+++ b/docs/os/modules/console/console_init.md
@@ -1,21 +1,19 @@
## <font color="#F2853F" style="font-size:24pt"> console_init </font>
-```c
-int console_init(console_rx_cb rx_cb)
+```no-highlight
+ 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.)
-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.
+ 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.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| `rx_cb` | Function pointer, which gets called when input is received. |
+| rx_cb | Function pointer, which gets called input is received. |
#### Returned values
@@ -24,7 +22,7 @@ Non-zero if HAL UART function calls fail.
#### Example
-```c
+```no-highlight
int
main(int argc, char **argv)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/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 b781b6d..3ec0698 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>
-```c
-int console_is_init(void)
+```no-highlight
+ 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
-```c
+```no-highlight
static int
log_console_append(struct log *log, void *buf, int len)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/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 0cda207..8eb2280 100644
--- a/docs/os/modules/console/console_printf.md
+++ b/docs/os/modules/console/console_printf.md
@@ -1,21 +1,19 @@
## <font color="F2853F" style="font-size:24pt"> console_printf</font>
-```c
-void console_printf(const char *fmt, ...)
+```no-highlight
+ void
+ console_printf(const char *fmt, ...)
```
-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.
+Writes a formatted message instead of raw output to the console. It first composes a C string containing text specified as arguments to the function or containing the elements in the variable argument list passed to it using snprintf or vsnprintf, respectively. It then uses function `console_write` to output the formatted data (messages) on the console.
#### Arguments
| Arguments | Description |
|-----------|-------------|
-| `fmt` | Pointer to C string that contains a format string that follows the same specifications as format in printf. The string is printed to console. |
-| ... | Depending on the format string, the function may expect either a sequence of additional arguments to be used to replace a format specifier in the format string or a variable arguments list. `va_list` is a special type defined in <cstdarg> in `stdarg.h`. |
+| 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
@@ -23,14 +21,12 @@ 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:
-```c
+```no-highlight
char adv_data_buf[32];
void
@@ -44,7 +40,7 @@ task()
Example #2:
-```c
+```no-highlight
struct exception_frame {
uint32_t r0;
uint32_t r1;
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/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 8ddc3d8..1e6600d 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>
-```c
-int console_read(char *str, int cnt)
+```no-highlight
+ 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
-```c
+```no-highlight
void
task1_loop(void *arg)
{
@@ -39,8 +39,4 @@ 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/1720300a/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 51f73aa..3d38529 100644
--- a/docs/os/modules/console/console_write.md
+++ b/docs/os/modules/console/console_write.md
@@ -1,7 +1,8 @@
## <font color="#F2853F" style="font-size:24pt"> console_write </font>
-```c
-void console_write(char *str, int cnt)
+```no-highlight
+ void
+ console_write(char *str, int cnt)
```
Queues characters to console display over serial port.
@@ -9,8 +10,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
@@ -21,7 +22,7 @@ N/A
Here is an example of the function being used in an echo command with a newline at the end.
-```c
+```no-highlight
static int
shell_echo_cmd(int argc, char **argv)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/modules/shell/shell.md
----------------------------------------------------------------------
diff --git a/docs/os/modules/shell/shell.md b/docs/os/modules/shell/shell.md
index 208f9fb..d3b50f5 100644
--- a/docs/os/modules/shell/shell.md
+++ b/docs/os/modules/shell/shell.md
@@ -1,20 +1,16 @@
# Shell
-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.
+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.
###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`, `echo`, `date` and `prompt`.
+ A few commands are currently available in the shell - `tasks`, `log`, and `stat stat`. A $ prompt sign will be coming soon!
-* 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>
@@ -85,12 +81,8 @@ 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)
-
-prompt
-Usage: prompt [set|show] [prompt_char]
-prompt set >
-Prompt set to: >
-229370: >
+stat stat
+229881:s0: 1
```
@@ -99,7 +91,7 @@ Prompt set to: >
This data structure is used in holding information about registered command handlers.
-```c
+```no-highlight
struct shell_cmd {
char *sc_cmd;
shell_cmd_func_t sc_cmd_func;
@@ -109,9 +101,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/1720300a/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 5becffd..aea4c16 100644
--- a/docs/os/modules/shell/shell_cmd_register.md
+++ b/docs/os/modules/shell/shell_cmd_register.md
@@ -1,21 +1,18 @@
## <font color="#F2853F" style="font-size:24pt"> shell_cmd_register </font>
-```c
+```no-highlight
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
@@ -24,7 +21,7 @@ Non-zero on failure.
#### Example
-```c
+```no-highlight
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/1720300a/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 ab2912a..abc64d6 100644
--- a/docs/os/modules/shell/shell_nlip_input_register.md
+++ b/docs/os/modules/shell/shell_nlip_input_register.md
@@ -1,22 +1,19 @@
## <font color="#F2853F" style="font-size:24pt"> shell_nlip_input_register </font>
-```c
+```no-highlight
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
@@ -24,7 +21,7 @@ Returns 0 on success.
#### Example
-```c
+```no-highlight
static int
nmgr_shell_in(struct os_mbuf *m, void *arg)
{
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/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 a905b63..4880de0 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>
-```c
+```no-highlight
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
-```c
+```no-highlight
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/1720300a/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 63b854d..ce2985a 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>
-```c
-int shell_task_init(uint8_t prio, os_stack_t *stack, uint16_t stack_size, int max_input_length);
+```no-highlight
+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 a few commands on its own
-(`echo`, `?`, `prompt` for example). It also allocates memory for buffering console input.
+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.
#### 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.
-```c
+```no-highlight
#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/1720300a/docs/os/tutorials/STM32F303.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/STM32F303.md b/docs/os/tutorials/STM32F303.md
index 695af1c..00ab024 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.9.1-none
+apache-mynewt-core successfully installed version 0.7.9-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.9.0-none
+mynewt_stm32f3 successfully installed version 0.0.0-none
```
<br>
@@ -183,8 +183,6 @@ 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/1720300a/docs/os/tutorials/arduino_zero.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/arduino_zero.md b/docs/os/tutorials/arduino_zero.md
index cbf9484..9926656 100644
--- a/docs/os/tutorials/arduino_zero.md
+++ b/docs/os/tutorials/arduino_zero.md
@@ -95,15 +95,24 @@ generate both a bootloader, and an image target.
To generate the bootloader target, you need to specify the following options. The output of the commands (indicating success) have been suppressed for easier readability.
```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 create arduino_boot
+$ newt target set arduino_boot bsp=@mynewt_arduino_zero/hw/bsp/arduino_zero
+$ newt target set arduino_boot app=@apache-mynewt-core/apps/boot
$ newt target set arduino_boot build_profile=optimized
-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>
+
+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
```
<br>
@@ -123,29 +132,6 @@ 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:
@@ -173,8 +159,7 @@ 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!
@@ -242,55 +227,6 @@ 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.
@@ -360,23 +296,18 @@ Continuing.
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 up and run on
-the Arduino on the next boot!
+If you want the image to run without the debugger connected, simply quit the
+debugger and restart the board. The image you programmed will come and run on the Arduino on next boot!
<br>
### Watch the LED blink
-Congratulations! You have created a Mynewt operating system running on the
-Arduino Zero. The LED right next to the power LED should be blinking. It is toggled
-by one task running on the Mynewt OS.
+Congratulations! You have created a Mynewt operating system running on the
+Arduino Zero. The LED right next to the power LED should be blinking. It is toggled by one task running on the Mynewt OS.
-We have more fun tutorials for you to get your hands dirty. Be bold and try other
-Blinky-like [tutorials](../tutorials/nRF52.md) or try enabling additional functionality
-such as [remote comms](project-target-slinky.md) on the current board.
+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!
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/tutorials/bleprph/bleprph-conn.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bleprph/bleprph-conn.md b/docs/os/tutorials/bleprph/bleprph-conn.md
new file mode 100644
index 0000000..ffbf7a1
--- /dev/null
+++ b/docs/os/tutorials/bleprph/bleprph-conn.md
@@ -0,0 +1,156 @@
+## BLE Peripheral Project
+
+### Connection callbacks
+
+<br>
+
+#### Overview
+
+
+Every BLE connection has a *connection callback* associated with it. A
+connection callback is a bit of application code which NimBLE uses to inform
+you of connection-related events. For example, if a connection is terminated,
+NimBLE lets you know about it with a call to that connection's callback.
+
+In the [advertising section](bleprph-adv/) of this tutorial, we saw how the
+application specifies a connection callback when it begins advertising. NimBLE
+uses this callback to notify the application that a central has connected to
+your peripheral after receiving an advertisement. Let's revisit how *bleprph* specifies its connection callback when advertising:
+
+<br>
+
+```c
+ /* Begin advertising. */
+ rc = ble_gap_adv_start(BLE_GAP_DISC_MODE_GEN, BLE_GAP_CONN_MODE_UND,
+ NULL, 0, NULL, bleprph_on_connect, NULL);
+ if (rc != 0) {
+ BLEPRPH_LOG(ERROR, "error enabling advertisement; rc=%d\n", rc);
+ return;
+ }
+```
+
+<br>
+
+#### bleprph_on_connect()
+
+
+The `bleprph_on_connect()` function is *bleprph*'s connection callback; NimBLE
+calls this function when the advertising operation leads to connection
+establishment. Upon connecting, this callback becomes permanently associated
+with the connection; all subsequent events related to this connection are
+communicated through this callback.
+
+Now let's look at the function that *bleprph* uses for all its connection
+callbacks: `bleprph_on_connect()`.
+
+
+```c
+static int
+bleprph_on_connect(int event, int status, struct ble_gap_conn_ctxt *ctxt,
+ void *arg)
+{
+ switch (event) {
+ case BLE_GAP_EVENT_CONN:
+ BLEPRPH_LOG(INFO, "connection %s; status=%d ",
+ status == 0 ? "up" : "down", status);
+ bleprph_print_conn_desc(ctxt->desc);
+ BLEPRPH_LOG(INFO, "\n");
+
+ if (status != 0) {
+ /* Connection terminated; resume advertising. */
+ bleprph_advertise();
+ }
+ break;
+ }
+
+ return 0;
+}
+```
+
+<br>
+
+Connection callbacks are used to communicate a variety of events related to a
+connection. An application determines the type of event that occurred by
+inspecting the value of the *event* parameter. The full list of event codes
+can be found in [net/nimble/host/include/host/ble_gatt.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/include/host/ble_gatt.h).
+*bleprph* only concerns itself with a single event type: *BLE_GAP_EVENT_CONN*.
+This event indicates that a new connection has been established, or an existing
+connection has been terminated; the *status* parameter clarifies which. As you
+can see, *bleprph* uses the *status* parameter to determine if it should resume
+advertising.
+
+The *ctxt* parameter contains additional information about the connection
+event. *bleprph* does nothing more than log some fields of this struct, but
+some apps will likely want to perform further actions, e.g., perform service
+discovery on the connected device. The *struct ble_gap_conn_ctxt* type is
+defined as follows:
+
+```c
+struct ble_gap_conn_ctxt {
+ struct ble_gap_conn_desc *desc;
+
+ union {
+ struct {
+ struct ble_gap_upd_params *self_params;
+ struct ble_gap_upd_params *peer_params;
+ } update;
+
+ struct ble_gap_sec_params *sec_params;
+ };
+};
+```
+
+<br>
+
+As shown, a connection context object consists of two parts:
+
+* *desc:* The connection descriptor; indicates properties of the connection.
+* *anonymous union:* The contents are event-specific; check the *event* code to determine which member field (if any) is relevant.
+
+For events of type *BLE_GAP_EVENT_CONN*, the anonymous union is not used at all, so the only information carried by the context struct is the connection descriptor. The *struct ble_gap_conn_desc* type is defined as follows:
+
+```c
+struct ble_gap_conn_desc {
+ uint8_t peer_addr[6];
+ uint16_t conn_handle;
+ uint16_t conn_itvl;
+ uint16_t conn_latency;
+ uint16_t supervision_timeout;
+ uint8_t peer_addr_type;
+};
+```
+
+<br>
+
+We will examine these fields in a slightly different order from how they appear
+in the struct definition.
+
+<br>
+
+| *Field* | *Purpose* | *Notes* |
+| ------- | --------- | ------- |
+| peer\_addr | The 48-bit address of the peer device. | |
+| peer\_addr\_type | Whether the peer is using a public or random address. | The address type list is documented in [net/nimble/include/nimble/hci_common.h](https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/include/nimble/hci_common.h). |
+| conn\_handle | The 16-bit handle associated with this connection. | This number is how your app and the NimBLE stack refer to this connection. |
+| conn\_itvl,<br>conn\_latency,<br>supervision\_timeout | Low-level properties of the connection. | |
+
+<br>
+
+#### Guarantees
+
+It is important to know what your application code is allowed to do from within
+a connection callback.
+
+**No restrictions on NimBLE operations**
+
+Your app is free to make calls into the NimBLE stack from within a connection
+callback. *bleprph* takes advantage of this freedom when it resumes
+advertising upon connection termination. All other NimBLE operations are also
+allowed (service discovery, pairing initiation, etc).
+
+**All context data is transient**
+
+Pointers in the context object point to data living on the stack. Your
+callback is free to read (or write, if appropriate) through these pointers, but
+you should not store these pointers for later use. If your application needs
+to retain some data from a context object, it needs to make a copy.
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/tutorials/bletiny_project.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/bletiny_project.md b/docs/os/tutorials/bletiny_project.md
index 4a7033a..495a8b3 100644
--- a/docs/os/tutorials/bletiny_project.md
+++ b/docs/os/tutorials/bletiny_project.md
@@ -59,19 +59,17 @@ targets/nrf52_boot
<br>
-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>
+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).
```
-$ 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 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 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..
@@ -79,7 +77,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/nrf52dk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
build_profile=optimized
```
@@ -93,30 +91,15 @@ targets/my_blinky_sim
build_profile=debug
targets/myble
app=@apache-mynewt-core/apps/bletiny
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
build_profile=optimized
cflags=-DSTATS_NAME_ENABLE
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
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.
@@ -166,10 +149,11 @@ 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, 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.
+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.
+
```
-$ minicom -D /dev/tty.usbserial-AJ03HAQQ -b 115200
+$ minicom -D /dev/tty.usbserial-AJ03HAQQ
```
<br>
@@ -186,40 +170,26 @@ Port /dev/tty.usbserial-AJ03HAQQ, 09:57:17
Press Meta-Z for help on special keys
?
-4754:Commands:
-4754: echo ? prompt tasks mempools date
-4756: b
+4828455:log echo ? tasks mempools date
+4828457:stat b
```
<br>
-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.
-
-**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.
+Try the `stat` command.
```hl_lines="1"
-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: >
+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
```
<br>
@@ -227,19 +197,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"
-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
+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
<snip>
```
@@ -248,18 +218,21 @@ hci_cmds: 11
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"
-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
-...
+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=
<snip>
```
@@ -308,4 +281,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.
+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
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/tutorials/nRF52.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/nRF52.md b/docs/os/tutorials/nRF52.md
index 469bd6e..15e5171 100644
--- a/docs/os/tutorials/nRF52.md
+++ b/docs/os/tutorials/nRF52.md
@@ -15,6 +15,7 @@ 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
@@ -49,7 +50,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.9.0-none
+ apache-mynewt-core successfully installed version 0.7.9-none
```
<br>
@@ -61,6 +62,7 @@ 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)
@@ -68,22 +70,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/nrf52dk
+$ newt target set blink_nordic bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
$ 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/nrf52dk
+$ newt target set nrf52_boot bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
$ newt target set nrf52_boot build_profile=optimized
$ newt target show
targets/blink_nordic
app=apps/blinky
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
build_profile=debug
targets/nrf52_boot
app=@apache-mynewt-core/apps/boot
- bsp=@apache-mynewt-core/hw/bsp/nrf52dk
+ bsp=@apache-mynewt-core/hw/bsp/nrf52pdk
build_profile=optimized
```
@@ -94,8 +96,8 @@ targets/nrf52_boot
```
$ newt build nrf52_boot
...
-Compiling boot.c
-Archiving boot.a
+Compiling log_shell.c
+Archiving log.a
Linking boot.elf
App successfully built: ~/dev/myproj/bin/nrf52_boot/apps/boot/boot.elf
```
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/tutorials/repo/add_repos.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/repo/add_repos.md b/docs/os/tutorials/repo/add_repos.md
index e280c8e..22098fa 100644
--- a/docs/os/tutorials/repo/add_repos.md
+++ b/docs/os/tutorials/repo/add_repos.md
@@ -105,7 +105,7 @@ after `github.com` in the repo path. Consider the repository
* **repo** -- The name of the repo. On github, this is the name after
the username described above. Consider the repository
-`https://github.com/apache/incubator-mynewt-core`. It has path
+`https://github.com/apache/incubator-mynewt-core`. It has username
`incubator-mynewt-core`. This is a path to the source control
and should not be confused with the name of the repo that you used in the
`repository.<name>` declaration above. That name is contained elsewhere
@@ -182,15 +182,9 @@ Here is the `repository.yml` file from the apache-Mynewt-core:
```no-highlight
repo.name: apache-mynewt-core
repo.versions:
- "0.0.0": "develop"
- "0.7.9": "mynewt_0_8_0_b2_tag"
- "0.8.0": "mynewt_0_8_0_tag"
- "0.9.0": "mynewt_0_9_0_tag"
- "0.9.1": "master"
- "0-latest": "0.9.0"
- "0-dev": "0.9.1"
- "0.8-latest": "0.8.0"
- "0.9-latest": "0.9.0"
+ "0.7.9": "Mynewt_0_8_0_b2_tag"
+ "0-latest": "0.7.9"
+ "0.8-latest": "0.7.9"
```
<br>
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/tutorials/repo/create_repo.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/repo/create_repo.md b/docs/os/tutorials/repo/create_repo.md
index 63ade07..1e1927e 100644
--- a/docs/os/tutorials/repo/create_repo.md
+++ b/docs/os/tutorials/repo/create_repo.md
@@ -1,19 +1,10 @@
## Create a Repo out of a Project
-In order to create a repository out of a project, all you need to do is create a
-`repository.yml` file, and check it into the master branch of your project.
+In order to create a repository out of a project, all you need to do is create a `repository.yml` file, and check it into the master branch of your project.
-**NOTE:** Currently only github source control service is supported by our
-package management system, but support for plain git is planned for a future
-version.
+**NOTE:** Currently only github source control service is supported by our package management system, but support for plain git will be added soon.
-The `repository.yml` defines all versions of the repository and the corresponding
-source control tags that these versions correspond to. As an example, if the
-`repository.yml` file has the following content, it means there is one version
-of the apache-mynewt-core operating system available, which is `0.0.0` (implying we
-haven't released yet!). Such a version number corresponds to the "develop" branch
-in this repository. `0-latest` would also resolved to this same `0.0.0` version.
-The next section explains the versioning system a bit more.
+The repository.yml defines all versions of the repository and the corresponding source control tags that these versions correspond to. As an example, if the repository.yml file has the following content, it means there is one version of the apache-mynewt-core operating system available, which is `0.0.0` (implying we haven't released yet!). Such a version number corresponds to the "develop" branch in this repository. `0-latest` would also resolved to this same `0.0.0` version. The next section explains the versioning system a bit more.
```
$ more repository.yml
@@ -48,8 +39,7 @@ repo.versions:
It contains the following:
* **repo.name** The external name that is used to include the library in
-your `project.yml` file. This is the name you in include in the `project.repositories`
-variable when adding this repository to your project.
+your `project.yml` file. This is the name you in include in the `project.repositories` variable when adding this repository to your project.
* **repo.versions** A description of what versions to give the user depending
on the settings in their `project.yml` file. See below for a thorough description
on versioning. Its a flexible mapping between version numbers and git branches.
@@ -80,9 +70,9 @@ or
The stability string can be one of 3 pre-defined stability values.
-1. `stable` -- A stable release version of the repository
-2. `dev` -- A development version from the repository
-3. `latest` -- The latest from the repository
+1. stable -- A stable release version of the repository
+2. dev -- A development version from the repository
+3. latest -- The latest from the repository
In your `project.yml` file you can specify different combinations of
the version number and stability value. For example:
@@ -105,9 +95,7 @@ You **cannot** specify a stability string with a fully numbered version, e.g.
A `repository.yml` file contains information to match this version request
into a git branch to fetch for your project.
-It's up to you as the repository maintainer to map these to actual github branches
-of the repository. For example, let's say in a fictitious repository the
-following are defined.
+It's up to you as the repository maintainer to map these to actual github branches of the repository. For example, let's say in a fictitious repository the following are defined.
```no-highlight
repo.versions:
@@ -127,8 +115,7 @@ repo.versions:
```
When the `project.yml` file asks for `1.2-stable` it will be resolved to version
-`1.2.0` which in turn will resolve to a specific branch `xxx_branch_1_2_0`.
-This is the branch that `newt` will then fetch into the project with that `project.yml` file.
+`1.2.0` which in turn will resolve to a specific branch `xxx_branch_1_2_0`. This is the branch that `newt` will fetch into the project with that `project.yml` file.
<br>
@@ -153,16 +140,13 @@ develop.repositories:
This would tell Newt that for anything that resolves to the develop
branch, this repository requires the sterlys-little-repo repository.
-Dependencies are resolved circularly by the newt tool, and every
-dependent repository is placed as a sibling in the repos directory.
-Currently, if two repositories have the same name, they will conflict
-and bad things will happen.
+Dependencies are resolved circularly by the newt tool, and every dependent repository is placed as a sibling in the repos directory. Currently, if two repositories have the same name, they will conflict and bad things will happen.
When a repository is installed to the repos/ directory, the current
-version of that repository is written to the `project.state` file. The
+version of that repository is written to the "project.state" file. The
project state file contains the currently installed version of any given
repository. This way, the current set of repositories can be recreated
-from the `project.state` file reliably, whereas the `project.yml` file can
+from the project.state file reliably, whereas the project.yml file can
have higher level directives (i.e. include 0.8-stable.)
http://git-wip-us.apache.org/repos/asf/incubator-mynewt-site/blob/1720300a/docs/os/tutorials/repo/upgrade_repo.md
----------------------------------------------------------------------
diff --git a/docs/os/tutorials/repo/upgrade_repo.md b/docs/os/tutorials/repo/upgrade_repo.md
index 475535a..c44fab8 100644
--- a/docs/os/tutorials/repo/upgrade_repo.md
+++ b/docs/os/tutorials/repo/upgrade_repo.md
@@ -12,7 +12,3 @@ Newt upgrade will look at the current desired version in `project.yml`,
and compare it to the version in `project.state`. If these two differ, it
will upgrade the dependency. Upgrade works not just for the dependency
in `project.yml`, but for all the sub-dependencies that they might have.
-
-If you have changed any settings in the `project.yml` file, you should run
-`newt upgrade` to ensure that your repos are all up to date with the versions
-specified in your `project.yml` file.