zephyr
/
openthread
mirror of https://github.com/zephyrproject-rtos/openthread.git
1
0
Fork 0
Code Issues Releases Wiki Activity

[docs] apply prettier changes (#4881)

This commit is contained in:
Jonathan Hui 2020-04-23 16:29:40 -07:00
parent c48f84d9ea
commit 082f7e9fdc
45 changed files with 1201 additions and 1494 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
.github/ISSUE_TEMPLATE/bug_report.md vendored
View File

@ -1,24 +1,19 @@
---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
A clear and concise description of what the bug is.
**Describe the bug** A clear and concise description of what the bug is.
**To Reproduce** Information to reproduce the behavior, including:
**To Reproduce**
Information to reproduce the behavior, including:
1. Git commit id
2. IEEE 802.15.4 hardware platform
3. Build steps
4. Network topology
**Expected behavior**
A clear and concise description of what you expected to happen.
**Expected behavior** A clear and concise description of what you expected to happen.
**Console/log output**
If applicable, add console/log output to help explain your problem.
**Console/log output** If applicable, add console/log output to help explain your problem.
**Additional context**
Add any other context about the problem here.
**Additional context** Add any other context about the problem here.

13
.github/ISSUE_TEMPLATE/feature_request.md vendored
View File

@ -1,17 +1,12 @@
---
name: Feature request
about: Suggest an idea for this project
---
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is.
**Is your feature request related to a problem? Please describe.** A clear and concise description of what the problem is.
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Describe the solution you'd like** A clear and concise description of what you want to happen.
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
**Describe alternatives you've considered** A clear and concise description of any alternative solutions or features you've considered.
**Additional context**
Add any other context or screenshots about the feature request here.
**Additional context** Add any other context or screenshots about the feature request here.

64
CODE_OF_CONDUCT.md
View File

@ -2,73 +2,45 @@
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
orientation.
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at openthread-conduct@google.com. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at openthread-conduct@google.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [http://contributor-covenant.org/version/1/4][version]
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
[homepage]: http://contributor-covenant.org
[version]: http://contributor-covenant.org/version/1/4/

24
CONTRIBUTING.md
View File

@ -2,21 +2,21 @@
We would love for you to contribute to OpenThread and help make it even better than it is today! As a contributor, here are the guidelines we would like you to follow.
* [1 Code of Conduct](#code-of-conduct)
* [2 Bugs](#bugs)
* [3 New Features](#new-features)
* [4 Contributing Code](#contributing-code)
* [4.1 Initial Setup](#initial-setup)
* [4.2 Contributor License Agreement (CLA)](#contributor-license-agreement--cla-)
* [4.3 Submitting a Pull Request](#submitting-a-pull-request)
- [1 Code of Conduct](#code-of-conduct)
- [2 Bugs](#bugs)
- [3 New Features](#new-features)
- [4 Contributing Code](#contributing-code)
- [4.1 Initial Setup](#initial-setup)
- [4.2 Contributor License Agreement (CLA)](#contributor-license-agreement--cla-)
- [4.3 Submitting a Pull Request](#submitting-a-pull-request)
## Code of Conduct
Help us keep OpenThread open and inclusive. Please read and follow our [Code of Conduct](CODE_OF_CONDUCT.md).
Help us keep OpenThread open and inclusive. Please read and follow our [Code of Conduct](CODE_OF_CONDUCT.md).
## Bugs
If you find a bug in the source code, you can help us by [submitting a GitHub Issue](https://github.com/openthread/openthread/issues/new). The best bug reports provide a detailed description of the issue and step-by-step instructions for predictably reproducing the issue. Even better, you can [submit a Pull Request](#submitting-a-pull-request) with a fix.
If you find a bug in the source code, you can help us by [submitting a GitHub Issue](https://github.com/openthread/openthread/issues/new). The best bug reports provide a detailed description of the issue and step-by-step instructions for predictably reproducing the issue. Even better, you can [submit a Pull Request](#submitting-a-pull-request) with a fix.
## New Features
@ -24,9 +24,9 @@ You can request a new feature by [submitting a GitHub Issue](https://github.com/
If you would like to implement a new feature, please consider the scope of the new feature:
* *Large feature*: first [submit a GitHub Issue](https://github.com/openthread/openthread/issues/new) and communicate your proposal so that the community can review and provide feedback. Getting early feedback will help ensure your implementation work is accepted by the community. This will also allow us to better coordinate our efforts and minimize duplicated effort.
- _Large feature_: first [submit a GitHub Issue](https://github.com/openthread/openthread/issues/new) and communicate your proposal so that the community can review and provide feedback. Getting early feedback will help ensure your implementation work is accepted by the community. This will also allow us to better coordinate our efforts and minimize duplicated effort.
* *Small feature*: can be implemented and directly [submitted as a Pull Request](#submitting-a-pull-request).
- _Small feature_: can be implemented and directly [submitted as a Pull Request](#submitting-a-pull-request).
## Contributing Code
@ -108,7 +108,7 @@ This will open up a text editor where you can specify which commits to squash.
#### Coding Conventions and Style
OpenThread uses and enforces the [OpenThread Coding Conventions and Style](STYLE_GUIDE.md) on all code, except for code located in [third_party](third_party). Use `script/make-pretty` and `script/make-pretty check` to automatically reformat code and check for code-style compliance, respectively. OpenThread currently requires [clang-format v6.0.0](http://releases.llvm.org/download.html#6.0.0) for C/C++ and [yapf v0.29.0](https://github.com/google/yapf) for Python.
OpenThread uses and enforces the [OpenThread Coding Conventions and Style](STYLE_GUIDE.md) on all code, except for code located in [third_party](third_party). Use `script/make-pretty` and `script/make-pretty check` to automatically reformat code and check for code-style compliance, respectively. OpenThread currently requires [clang-format v6.0.0](http://releases.llvm.org/download.html#6.0.0) for C/C++ and [yapf v0.29.0](https://github.com/google/yapf) for Python.
As part of the cleanup process, you should also run `script/make-pretty check` to ensure that your code passes the baseline code style checks.

30
README.md
View File

@ -1,18 +1,10 @@
[![OpenThread][ot-logo]][ot-repo]
[![Build][ot-gh-action-build-svg]][ot-gh-action-build]
[![Simulation][ot-gh-action-simulation-svg]][ot-gh-action-simulation]
[![Language grade: C/C++][ot-lgtm-svg]][ot-lgtm]
[![Coverage Status][ot-codecov-svg]][ot-codecov]
[![Build Status][ot-docker-dev-svg]][ot-docker-dev]
[![OpenThread][ot-logo]][ot-repo] [![Build][ot-gh-action-build-svg]][ot-gh-action-build] [![Simulation][ot-gh-action-simulation-svg]][ot-gh-action-simulation] [![Language grade: C/C++][ot-lgtm-svg]][ot-lgtm] [![Coverage Status][ot-codecov-svg]][ot-codecov] [![Build Status][ot-docker-dev-svg]][ot-docker-dev]
---
# What is OpenThread?
OpenThread released by Google is...
<a href="http://threadgroup.org/technology/ourtechnology#certifiedproducts">
<img src="https://cdn.rawgit.com/openthread/openthread/ab4c4e1e/doc/images/certified.svg" alt="Thread Certified Component" width="150px" align="right">
</a>
OpenThread released by Google is... <a href="http://threadgroup.org/technology/ourtechnology#certifiedproducts"> <img src="https://cdn.rawgit.com/openthread/openthread/ab4c4e1e/doc/images/certified.svg" alt="Thread Certified Component" width="150px" align="right"> </a>
**...an open-source implementation of the [Thread](http://threadgroup.org/technology/ourtechnology) networking protocol.** Google Nest has released OpenThread to make the technology used in Nest products more broadly available to developers to accelerate the development of products for the connected home.
@ -44,12 +36,12 @@ More information about Thread can be found at [threadgroup.org](http://threadgro
All end-user documentation and guides are located at [openthread.io](https://openthread.io). If you're looking to do things like...
* Learn more about OpenThread features and enhancements
* Use OpenThread in your products
* Learn how to build and configure a Thread network
* Port OpenThread to a new platform
* Build an application on top of OpenThread
* Certify a product using OpenThread
- Learn more about OpenThread features and enhancements
- Use OpenThread in your products
- Learn how to build and configure a Thread network
- Port OpenThread to a new platform
- Build an application on top of OpenThread
- Certify a product using OpenThread
...then [openthread.io](https://openthread.io) is the place for you.
@ -77,8 +69,8 @@ Please only use the OpenThread name and marks when accurately referencing this s
There are numerous avenues for OpenThread support:
* Bugs and feature requests — [submit to the Issue Tracker](https://github.com/openthread/openthread/issues)
* Stack Overflow — [post questions using the `openthread` tag](http://stackoverflow.com/questions/tagged/openthread)
* Google Groups — [discussion and announcements at openthread-users](https://groups.google.com/forum/#!forum/openthread-users)
- Bugs and feature requests — [submit to the Issue Tracker](https://github.com/openthread/openthread/issues)
- Stack Overflow — [post questions using the `openthread` tag](http://stackoverflow.com/questions/tagged/openthread)
- Google Groups — [discussion and announcements at openthread-users](https://groups.google.com/forum/#!forum/openthread-users)
The openthread-users Google Group is the recommended place for users to discuss OpenThread and interact directly with the OpenThread team.

51
STYLE_GUIDE.md
View File

@ -1,15 +1,15 @@
# OpenThread Coding Conventions and Style
* [1 C and C++](#c-and-c)
* [1.1 Standards](#standards)
* [1.2 Conventions and Best Practices](#conventions-and-best-practices)
* [1.3 Tightly-constrained Systems and Shared Infrastructure](#tightly-constrained-systems-and-shared-infrastructure)
* [1.4 Format and Style](#format-and-style)
* [1.5 Comments](#comments)
* [2 Python](#python)
* [2.1 Standards](#standards)
* [2.2 Conventions and Best Practices](#conventions-and-best-practices)
* [2.3 Format and Style](#format-and-style)
- [1 C and C++](#c-and-c)
- [1.1 Standards](#standards)
- [1.2 Conventions and Best Practices](#conventions-and-best-practices)
- [1.3 Tightly-constrained Systems and Shared Infrastructure](#tightly-constrained-systems-and-shared-infrastructure)
- [1.4 Format and Style](#format-and-style)
- [1.5 Comments](#comments)
- [2 Python](#python)
- [2.1 Standards](#standards)
- [2.2 Conventions and Best Practices](#conventions-and-best-practices)
- [2.3 Format and Style](#format-and-style)
# C and C++
@ -27,13 +27,13 @@
### Language Independent
- Inline functions should be used judiciously.
- The use of code in headers and, more specifically, the use of the non-local scope inline functions should be avoided. Exception: Simple setters and getters are fine since the compiler can efficiently optimize these and make their overhead as low as a direct data member access.
- The use of code in headers and, more specifically, the use of the non-local scope inline functions should be avoided. Exception: Simple setters and getters are fine since the compiler can efficiently optimize these and make their overhead as low as a direct data member access.
- Return Statements
- There should be one return statement per free function or method at the end of the free function or method.
- Non-local Goto
- There should be no calls to the functions `setjmp` or `longjmp`.
- Local Goto
- There should be no calls to the C/C++ keyword goto. Exception: The use of local gotos for the purposes of common error handling blocks and single points of function return at the bottom of a function.
- There should be no calls to the C/C++ keyword goto. Exception: The use of local gotos for the purposes of common error handling blocks and single points of function return at the bottom of a function.
- C Preprocessor
- Use of the C preprocessor should be limited to file inclusion and simple macros.
- Macros shall not be defined within a function or a block and should be defined at the top of a file.
@ -63,16 +63,16 @@
- Unbounded Recursion
- There shall be no direct or indirect use of unbounded recursive function calls.
- Symmetric APIs
- Wherever possible and appropriate, particularly around the management of resources, APIs should be symmetric. For example, if there is a free function or object method that allocates a resource, then there should be one that deallocates it. If there is a free function or object method that opens a file or network stream, then there should be one that closes it.
- Wherever possible and appropriate, particularly around the management of resources, APIs should be symmetric. For example, if there is a free function or object method that allocates a resource, then there should be one that deallocates it. If there is a free function or object method that opens a file or network stream, then there should be one that closes it.
- Use C stdint.h or C++ cstdint for Plain Old Data Types
- Standard, scalar data types defined in stdint.h (C) or cstdint (C++) should be used for basic signed and unsigned integer types, especially when size and serialization to non-volatile storage or across a network is concerned. Examples of these are: `uint8_t`, `int8_t`, etc.
- Standard, scalar data types defined in stdint.h (C) or cstdint (C++) should be used for basic signed and unsigned integer types, especially when size and serialization to non-volatile storage or across a network is concerned. Examples of these are: `uint8_t`, `int8_t`, etc.
- Constant Qualifiers
- Read-only methods, global variables, stack variables, or data members are read-only should be qualified using the C or C++ `const` qualifier.
- Pointers or references to read-only objects or storage, including but not limited to function parameters, should be qualified using the C or C++ `const` qualifier.
- Header Include Guard
- All C and C++ headers shall use preprocessor header include guards.
- The terminating endif preprocessor directive shall have a comment, C or C++ depending on the header type, containing the preprocessor symbol introduced by the ifndef directive starting the guard.
- The symbol used for the guard should be the file name, converted to all uppercase, with any spaces (“ “) or dots (“.”) converted to underscores (“_”).
- The symbol used for the guard should be the file name, converted to all uppercase, with any spaces (“ “) or dots (“.”) converted to underscores (“\_”).
- Function and Method Prototypes
- All void functions or methods shall explicitly declare and specify the void type keyword.
- Unused parameters
@ -86,16 +86,16 @@
### C++
- Prefer Passing Parameters by Reference to Pointer
- Unlike C, C++ offers an alternate way to alias data over and above a pointer, the reference, indicated by the & symbol. Where appropriate, the reference should be preferred to the pointer.
- Unlike C, C++ offers an alternate way to alias data over and above a pointer, the reference, indicated by the & symbol. Where appropriate, the reference should be preferred to the pointer.
- Passing Base Scalars
- Size- and call frequency-based considerations should be made when passing scalars as to whether they should be passed by value or by constant reference; however, pass-by-value should generally be preferred.
- Eliminate Unnecessary Destructors
- The creation of empty or useless destructors should be avoided. Empty or useless destructors should be removed.
- The creation of empty or useless destructors should be avoided. Empty or useless destructors should be removed.
- Default Parameters
- When you declare C++ free functions and object methods, you should avoid or minimize using default parameters.
- When you declare C++ virtual object methods, you shall avoid using default parameters.
- Global and Scoped Static Construction
- There shall be no use of global, static or otherwise, object construction. The use of scoped static object construction should be avoided.
- There shall be no use of global, static or otherwise, object construction. The use of scoped static object construction should be avoided.
- C++-style Casts
- Wherever possible and practical, C++ style casts should be used and preferred to the C style cast equivalent.
- Avoid `using namespace` Statements in Headers
@ -114,23 +114,25 @@
## Format and Style
- OpenThread uses `script/make-pretty` to reformat code and enforce code format and style. `script/make-pretty check` build target is included in OpenThread's continuous integration and must pass before a pull request is merged.
- OpenThread uses `script/make-pretty` to reformat code and enforce code format and style. `script/make-pretty check` build target is included in OpenThread's continuous integration and must pass before a pull request is merged.
- `script/make-pretty` requires [clang-format v6.0.0](http://releases.llvm.org/download.html#6.0.0) for C/C++ and [yapf v0.29.0](https://github.com/google/yapf) for Python.
### File Names
- File names should match the names and types of what is described in the file. If a file contains many declarations and definitions, the author should choose the one that predominantly describes or that makes the most sense.
- File names should match the names and types of what is described in the file. If a file contains many declarations and definitions, the author should choose the one that predominantly describes or that makes the most sense.
- File contents and names should be limited in the scope of what they contain. It may also be possible that there is too much stuff in one file and you need to break it up into multiple files.
- File names should be all lower case.
- File extensions shall be indicative and appropriate for the type and usage of the source or header file.
### Naming
- Names should be descriptive but not overly so and they should give some idea of scope and should be selected such that *wrong code looks wrong*.
- Names should be descriptive but not overly so and they should give some idea of scope and should be selected such that _wrong code looks wrong_.
- Names shall not give any idea of type, such as is done with System Hungarian notation.
- Case
- C preprocessor symbols should be all uppercase.
- All OpenThread class, namespace, structure, method, function, enumeration, and type names in the C/C++ language shall be in *upper camel case*. Exception: the top level OpenThread namespace 'ot'.
- All OpenThread instantiated names of instances of classes, namespaces, structures, methods, functions, enumerations, and types as well as method and function parameters in the C++ language shall be in *lower camel case*.
- All OpenThread class, namespace, structure, method, function, enumeration, and type names in the C/C++ language shall be in _upper camel case_. Exception: the top level OpenThread namespace 'ot'.
- All OpenThread instantiated names of instances of classes, namespaces, structures, methods, functions, enumerations, and types as well as method and function parameters in the C++ language shall be in _lower camel case_.
- Symbol Qualification
- All OpenThread C public data types and free functions should have `ot` prepended to their name.
- All OpenThread C++ code should be in the ‘ot’ top-level namespace.
@ -142,6 +144,7 @@
- All variables that do not have such prefixes shall be assumed to be function local scope.
### White Space
- Indentation shall be 4 space characters.
- Conditionals shall always appear on a separate line from the code to execute as a result of the condition.
- Scoped Variable declarations
@ -181,7 +184,7 @@
## Conventions and Best Practices
- Run `pylint` over your code. `pylint` is a tool for finding bugs and style problems in Python source code. It finds problems that are typically caught by a compiler for less dynamic languages like C and C++. Because of the dynamic nature of Python, some warnings may be incorrect; however, spurious warnings should be fairly infrequent.
- Run `pylint` over your code. `pylint` is a tool for finding bugs and style problems in Python source code. It finds problems that are typically caught by a compiler for less dynamic languages like C and C++. Because of the dynamic nature of Python, some warnings may be incorrect; however, spurious warnings should be fairly infrequent.
## Format and Style

1
doc/ot_api_doc.h
View File

@ -161,4 +161,3 @@
* @}
*
*/

9
etc/docker/README.md
View File

@ -1,4 +1,3 @@
## Running wpantund from a Docker container:
For a device that has a Thread radio attached to port `/dev/ttyUSB0`, start `wpantund` as follows:
@ -13,22 +12,26 @@ Once `wpantund` is running, one can control the Thread interface with `wpanctl`
docker exec -it wpantund wpanctl
```
## Content
arm32v7_ubuntu_wpantund
- `wpantund` running on ARMv7 (e.g. Raspberry Pi)
x86_ubuntu_wpantund
- `wpantund` running on x86
ot_sim
- OpenThread POSIX simulator
codelab_otsim
- For use with the [Docker Simulation Codelab](https://codelabs.developers.google.com/codelabs/openthread-simulation/), contains the OpenThread POSIX example and `wpantund` pre-built and ready to use.
environment
- Development environment with the GNU toolchain and all required OpenThread dependencies installed. OpenThread is not built in this image.
Images built from these Dockerfiles are available to pull from [Docker Hub](https://hub.docker.com/u/openthread/). See [Docker Support on openthread.io](https://openthread.io/guides#docker_support) for more information.
Images built from these Dockerfiles are available to pull from [Docker Hub](https://hub.docker.com/u/openthread/). See [Docker Support on openthread.io](https://openthread.io/guides#docker_support) for more information.

13
etc/docker/ot_sim/README.md
View File

@ -1,36 +1,47 @@
## Starting simulator
To start the OpenThread simulator, run:
```
docker run --rm -d --name otsim openthread/simulation tail -F /dev/null
```
or
```
./start_sim
```
This runs in background a docker container with environment setup to simulate OpenThread nodes.
## Adding a Thread node
To start simulating an OpenThread node #1, run:
```
docker exec -it otsim node 1
```
or
```
./add_node 1
```
This runs a program called node, which is an OpenThread FTD binary, inside the docker container's simulator environment.
## Stopping simulator
To stop the OpenThread simualtor, run:
```
docker stop otsim
```
or
```
./stop_sim
```
This stop the docker daemon process.

48
examples/platforms/cc1352/README.md
View File

@ -1,34 +1,24 @@
# OpenThread on CC1352 Example
This directory contains example platform drivers for the [Texas Instruments
CC1352R1][cc1352r1].
This directory contains example platform drivers for the [Texas Instruments CC1352R1][cc1352r1].
The example platform drivers are intended to present the minimal code necessary
to support OpenThread. As a result, the example platform drivers do not
necessarily highlight the platform's full capabilities. Consult the [SimpleLink
CC26X2R1 SDK][cc26x2r1-sdk] for more development option. The platform drivers
were built for the [CC1352R1 LAUNCHXL][cc1352r1-launchxl], usage on other
boards with a cc1352r1 may require changes to the peripheral drivers.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. As a result, the example platform drivers do not necessarily highlight the platform's full capabilities. Consult the [SimpleLink CC26X2R1 SDK][cc26x2r1-sdk] for more development option. The platform drivers were built for the [CC1352R1 LAUNCHXL][cc1352r1-launchxl], usage on other boards with a cc1352r1 may require changes to the peripheral drivers.
[cc1352r1-launchxl]: http://www.ti.com/tool/launchxl-cc26x2r1
[cc26x2r1-sdk]: http://www.ti.com/tool/simplelink-cc26x2-sdk
<!---
TODO: Update link when cc1352 product page is live
[cc1352r1]: http://www.ti.com/product/cc1352r1
-->
[cc1352r1]: http://www.ti.com/tool/launchxl-cc26x2r1
## Toolchain
Building the examples for the cc1352 requires [GNU AutoConf][gnu-autoconf],
[GNU AutoMake][gnu-automake], [Python][python], and the [ARM gcc
toolchain][arm-toolchain].
Building the examples for the cc1352 requires [GNU AutoConf][gnu-autoconf], [GNU AutoMake][gnu-automake], [Python][python], and the [ARM gcc toolchain][arm-toolchain].
With the exception of the arm toolchain, most of these tools are installed by
default on modern Posix systems. It is recommended to setup a Linux virtual
machine for building on a Windows host system. For help setting up VirtualBox
with Ubuntu, consult this [community help wiki
article][ubuntu-wiki-virtualbox].
With the exception of the arm toolchain, most of these tools are installed by default on modern Posix systems. It is recommended to setup a Linux virtual machine for building on a Windows host system. For help setting up VirtualBox with Ubuntu, consult this [community help wiki article][ubuntu-wiki-virtualbox].
[gnu-autoconf]: https://www.gnu.org/software/autoconf
[gnu-automake]: https://www.gnu.org/software/automake
@ -38,8 +28,7 @@ article][ubuntu-wiki-virtualbox].
[mingw]: http://www.mingw.org
[ubuntu-wiki-virtualbox]: https://help.ubuntu.com/community/VirtualBox
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -58,11 +47,9 @@ $ make -f examples/Makefile-cc1352
## Flash Binaries
If the build completed successfully, the `elf` files may be found in
`<path-to-openthread>/output/cc1352/bin`.
If the build completed successfully, the `elf` files may be found in `<path-to-openthread>/output/cc1352/bin`.
Flash the images with [Uniflash][uniflash]. Make sure to deselect the binary
check-box, Uniflash assumes a file without an extension is a binary file.
Flash the images with [Uniflash][uniflash]. Make sure to deselect the binary check-box, Uniflash assumes a file without an extension is a binary file.
[uniflash]: http://www.ti.com/tool/uniflash
@ -70,15 +57,13 @@ check-box, Uniflash assumes a file without an extension is a binary file.
### CLI example
1. With a terminal client (PuTTY, minicom, etc.) open the com port associated
with the cc1352 UART. The serial port settings are:
* 115200 baud
* 8 data bits
* no parity bit
* 1 stop bit
1. With a terminal client (PuTTY, minicom, etc.) open the com port associated with the cc1352 UART. The serial port settings are:
- 115200 baud
- 8 data bits
- no parity bit
- 1 stop bit
2. Type `help` for a list of commands.
3. Follow the instructions in the [CLI README][cli-readme] for instructions on
setting up a network.
3. Follow the instructions in the [CLI README][cli-readme] for instructions on setting up a network.
[cli-readme]: ../../../src/cli/README.md
@ -114,7 +99,6 @@ whitelist
### NCP example
Refer to the documentation in the [wpantund][wpantund] project for build
instructions and usage information.
Refer to the documentation in the [wpantund][wpantund] project for build instructions and usage information.
[wpantund]: https://github.com/openthread/wpantund

68
examples/platforms/cc2538/README.md
View File

@ -1,23 +1,18 @@
# OpenThread on CC2538 Example
This directory contains example platform drivers for the [Texas
Instruments CC2538][cc2538].
This directory contains example platform drivers for the [Texas Instruments CC2538][cc2538].
[cc2538]: http://www.ti.com/product/CC2538
The example platform drivers are intended to present the minimal code
necessary to support OpenThread. As a result, the example platform
drivers do not necessarily highlight the platform's full capabilities.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. As a result, the example platform drivers do not necessarily highlight the platform's full capabilities.
## Toolchain
Download and install the [GNU toolchain for ARM
Cortex-M][gnu-toolchain].
Download and install the [GNU toolchain for ARM Cortex-M][gnu-toolchain].
[gnu-toolchain]: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -36,9 +31,7 @@ $ make -f examples/Makefile-cc2538
### CC2592 support
If your board has a CC2592 range extender front-end IC connected to the CC2538
(e.g. the CC2538-CC2592 EM reference design), you need to initialise this part
before reception of radio traffic will work.
If your board has a CC2592 range extender front-end IC connected to the CC2538 (e.g. the CC2538-CC2592 EM reference design), you need to initialise this part before reception of radio traffic will work.
Support is enabled in OpenThread by building with `CC2592=1`:
@ -46,62 +39,39 @@ Support is enabled in OpenThread by building with `CC2592=1`:
$ make -f examples/Makefile-cc2538 CC2592=1
```
The default settings should work for any design following the integration
advice given in TI's application report ["AN130 - Using CC2592 Front End With
CC2538"](http://www.ti.com/lit/pdf/swra447).
The default settings should work for any design following the integration advice given in TI's application report ["AN130 - Using CC2592 Front End With CC2538"](http://www.ti.com/lit/pdf/swra447).
Additional settings can be customised:
* `CC2592_PA_EN`: This specifies which pin (on port C of the CC2538) connects to the
CC2592's `PA_EN` pin. The default is `3` (PC3).
* `CC2592_LNA_EN`: This specifies which pin (on port C of the CC2538) connects to the
CC2592's `LNA_EN` pin. The default is `2` (PC2).
* `CC2592_USE_HGM`: This defines whether the HGM pin of the CC2592 is under GPIO control
or not. If not, it is assumed that the HGM pin is tied to a power rail.
* `CC2592_HGM_PORT`: The HGM pin can be connected to any free GPIO. TI recommend using
PD2, however if you've used a pin on another GPIO port, you may specify that port (`A`,
`B` or `C`) here.
* `CC2592_HGM_PORT`: The HGM pin can be connected to any free GPIO. TI recommend using
PD2, however if you've used a pin on another GPIO port, you may specify that port (`A`,
`B` or `C`) here. Default is `D`.
* `CC2592_HGM_PIN`: The HGM pin can be connected to any free GPIO. TI recommend using
PD2, however if you've used a pin on another GPIO pin, you can specify the pin here.
Default is `2`.
* `CC2592_HGM_DEFAULT_STATE`: By default, HGM is enabled at power-on, but you may want
to have it default to off, specify `CC2592_HGM_DEFAULT_STATE=0` to do so.
* `CC2538_RECEIVE_SENSITIVITY`: If you have tied the HGM pin to a power rail, this allows
you to calibrate the RSSI values according to the new receive sensitivity. This has no
effect if `CC2592_USE_HGM=1` (the default).
* `CC2538_RSSI_OFFSET`: If you have tied the HGM pin to a power rail, this allows
you to calibrate the RSSI values according to the new RSSI offset. This has no
effect if `CC2592_USE_HGM=1` (the default).
- `CC2592_PA_EN`: This specifies which pin (on port C of the CC2538) connects to the CC2592's `PA_EN` pin. The default is `3` (PC3).
- `CC2592_LNA_EN`: This specifies which pin (on port C of the CC2538) connects to the CC2592's `LNA_EN` pin. The default is `2` (PC2).
- `CC2592_USE_HGM`: This defines whether the HGM pin of the CC2592 is under GPIO control or not. If not, it is assumed that the HGM pin is tied to a power rail.
- `CC2592_HGM_PORT`: The HGM pin can be connected to any free GPIO. TI recommend using PD2, however if you've used a pin on another GPIO port, you may specify that port (`A`, `B` or `C`) here.
- `CC2592_HGM_PORT`: The HGM pin can be connected to any free GPIO. TI recommend using PD2, however if you've used a pin on another GPIO port, you may specify that port (`A`, `B` or `C`) here. Default is `D`.
- `CC2592_HGM_PIN`: The HGM pin can be connected to any free GPIO. TI recommend using PD2, however if you've used a pin on another GPIO pin, you can specify the pin here. Default is `2`.
- `CC2592_HGM_DEFAULT_STATE`: By default, HGM is enabled at power-on, but you may want to have it default to off, specify `CC2592_HGM_DEFAULT_STATE=0` to do so.
- `CC2538_RECEIVE_SENSITIVITY`: If you have tied the HGM pin to a power rail, this allows you to calibrate the RSSI values according to the new receive sensitivity. This has no effect if `CC2592_USE_HGM=1` (the default).
- `CC2538_RSSI_OFFSET`: If you have tied the HGM pin to a power rail, this allows you to calibrate the RSSI values according to the new RSSI offset. This has no effect if `CC2592_USE_HGM=1` (the default).
## Flash Binaries
If the build completed successfully, the `elf` files may be found in
`<path-to-openthread>/output/cc2538/bin`.
If the build completed successfully, the `elf` files may be found in `<path-to-openthread>/output/cc2538/bin`.
To flash the images with [Flash Programmer 2][ti-flash-programmer-2],
the files must have the `*.elf` extension.
To flash the images with [Flash Programmer 2][ti-flash-programmer-2], the files must have the `*.elf` extension.
```bash
$ cd <path-to-openthread>/output/cc2538/bin
$ cp ot-cli ot-cli.elf
```
To load the images with the [serial bootloader][ti-cc2538-bootloader],
the images must be converted to `bin`. This is done using
`arm-none-eabi-objcopy`
To load the images with the [serial bootloader][ti-cc2538-bootloader], the images must be converted to `bin`. This is done using `arm-none-eabi-objcopy`
```bash
$ cd <path-to-openthread>/output/cc2538/bin
$ arm-none-eabi-objcopy -O binary ot-cli ot-cli.bin
```
The [cc2538-bsl.py script][cc2538-bsl-tool] provides a convenient
method for flashing a CC2538 via the UART. To enter the bootloader
backdoor for flashing, hold down SELECT for CC2538DK (corresponds to
logic '0') while you press the Reset button.
The [cc2538-bsl.py script][cc2538-bsl-tool] provides a convenient method for flashing a CC2538 via the UART. To enter the bootloader backdoor for flashing, hold down SELECT for CC2538DK (corresponds to logic '0') while you press the Reset button.
[ti-flash-programmer-2]: http://www.ti.com/tool/flash-programmer
[ti-cc2538-bootloader]: http://www.ti.com/lit/an/swra466a/swra466a.pdf

68
examples/platforms/cc2650/README.md
View File

@ -1,25 +1,14 @@
# OpenThread on CC2650 Example
This directory contains example platform drivers for the [Texas
Instruments CC2650][cc2650].
This directory contains example platform drivers for the [Texas Instruments CC2650][cc2650].
The example platform drivers are intended to present the minimal code necessary
to support OpenThread. As a result, the example platform drivers do not
necessarily highlight the platform's full capabilities. The platform
abstraction layer was build for the [CC2650 LAUNCHXL][cc2650-launchxl], usage
on other boards with a CC2650 will require changes to the peripheral drivers.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. As a result, the example platform drivers do not necessarily highlight the platform's full capabilities. The platform abstraction layer was build for the [CC2650 LAUNCHXL][cc2650-launchxl], usage on other boards with a CC2650 will require changes to the peripheral drivers.
Due to flash size limitations, some features of OpenThread are not supported on
the [Texas Instruments CC2650][cc2650]. This platform is intended for
exprimentation and exploration of OpenThread, not a production ready
environment. Texas Instruments recommends future TI SoCs for production.
Due to flash size limitations, some features of OpenThread are not supported on the [Texas Instruments CC2650][cc2650]. This platform is intended for exprimentation and exploration of OpenThread, not a production ready environment. Texas Instruments recommends future TI SoCs for production.
Building with gcc 5.4 is recommended due to generated code size concerns.
All three configurations were tested with `arm-none-eabi-gcc 5.4.1 20160609
(release)` on [this commit][tested-commit]. The automatic integration builds have since
been limited to only the `cli-mtd` configuration to limit the impact on pull
requests.
All three configurations were tested with `arm-none-eabi-gcc 5.4.1 20160609 (release)` on [this commit][tested-commit]. The automatic integration builds have since been limited to only the `cli-mtd` configuration to limit the impact on pull requests.
[cc2650]: http://www.ti.com/product/CC2650
[cc2650-launchxl]: http://www.ti.com/tool/Launchxl-cc2650
@ -27,17 +16,9 @@ requests.
## Build Environment
Building the examples for the cc2650 requires [GNU AutoConf][gnu-autoconf],
[GNU AutoMake][gnu-automake], [Python][python], and the
[ARM gcc toolchain][arm-toolchain].
Building the examples for the cc2650 requires [GNU AutoConf][gnu-autoconf], [GNU AutoMake][gnu-automake], [Python][python], and the [ARM gcc toolchain][arm-toolchain].
With the exception of the arm toolchain, most of these tools are installed by
default on modern Posix systems. Windows does not have these tools installed by
default, and the bootstrap script requires a Posix or MSYS environment to run.
It is possible to setup an MSYS environment inside of Windows using tools such
as [Cygwin][cygwin] or [MinGW][mingw] but it is recommended to setup a Linux VM
for building on a Windows system. For help setting up VirtualBox with Ubuntu,
consult this [community help wiki article][ubuntu-wiki-virtualbox].
With the exception of the arm toolchain, most of these tools are installed by default on modern Posix systems. Windows does not have these tools installed by default, and the bootstrap script requires a Posix or MSYS environment to run. It is possible to setup an MSYS environment inside of Windows using tools such as [Cygwin][cygwin] or [MinGW][mingw] but it is recommended to setup a Linux VM for building on a Windows system. For help setting up VirtualBox with Ubuntu, consult this [community help wiki article][ubuntu-wiki-virtualbox].
[gnu-autoconf]: https://www.gnu.org/software/autoconf
[gnu-automake]: https://www.gnu.org/software/automake
@ -47,8 +28,7 @@ consult this [community help wiki article][ubuntu-wiki-virtualbox].
[mingw]: http://www.mingw.org
[ubuntu-wiki-virtualbox]: https://help.ubuntu.com/community/VirtualBox
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -67,26 +47,23 @@ $ make -f examples/Makefile-cc2650
## Flash Binaries
If the build completed successfully, the `elf` files may be found in
`<path-to-openthread>/output/cc2650/bin`.
If the build completed successfully, the `elf` files may be found in `<path-to-openthread>/output/cc2650/bin`.
To flash the images with [Flash Programmer 2][ti-flash-programmer-2], the files must have the `*.elf` extension.
To flash the images with [Flash Programmer 2][ti-flash-programmer-2], the files
must have the `*.elf` extension.
```bash
$ cd <path-to-openthread>/output/cc2650/bin
$ cp ot-cli ot-cli.elf
```
To load the images with the [serial bootloader][ti-cc2650-bootloader], the
images must be converted to `bin`. This is done using `arm-none-eabi-objcopy`
To load the images with the [serial bootloader][ti-cc2650-bootloader], the images must be converted to `bin`. This is done using `arm-none-eabi-objcopy`
```bash
$ cd <path-to-openthread>/output/cc2650/bin
$ arm-none-eabi-objcopy -O binary ot-cli ot-cli.bin
```
The [cc2538-bsl.py script][cc2538-bsl-tool] provides a convenient method
for flashing a CC2650 via the UART. To enter the bootloader backdoor for flashing,
hold down BTN-1 on CC2650 LauchPad or SELECT for CC2650DK (corresponds to logic '0')
while you press the Reset button.
The [cc2538-bsl.py script][cc2538-bsl-tool] provides a convenient method for flashing a CC2650 via the UART. To enter the bootloader backdoor for flashing, hold down BTN-1 on CC2650 LauchPad or SELECT for CC2650DK (corresponds to logic '0') while you press the Reset button.
[ti-flash-programmer-2]: http://www.ti.com/tool/flash-programmer
[ti-cc2650-bootloader]: http://www.ti.com/lit/an/swra466a/swra466a.pdf
@ -96,15 +73,13 @@ while you press the Reset button.
### CLI example
1. With a terminal client (putty, minicom, etc.) open the com port associated
with the cc2650 UART. The serial port settings are:
* 115200 baud
* 8 data bits
* no parity bit
* 1 stop bit
1. With a terminal client (putty, minicom, etc.) open the com port associated with the cc2650 UART. The serial port settings are:
- 115200 baud
- 8 data bits
- no parity bit
- 1 stop bit
2. Type `help` for a list of commands
3. follow the instructions in the [CLI README][cli-readme] for instructions on
setting up a network
3. follow the instructions in the [CLI README][cli-readme] for instructions on setting up a network
[cli-readme]: ../../../src/cli/README.md
@ -140,7 +115,6 @@ whitelist
### NCP example
Refer to the documentation in the [wpantund][wpantund] project for build
instructions and usage information.
Refer to the documentation in the [wpantund][wpantund] project for build instructions and usage information.
[wpantund]: https://github.com/openthread/wpantund

48
examples/platforms/cc2652/README.md
View File

@ -1,34 +1,24 @@
# OpenThread on CC2652 Example
This directory contains example platform drivers for the [Texas Instruments
CC2652R1][cc2652r1].
This directory contains example platform drivers for the [Texas Instruments CC2652R1][cc2652r1].
The example platform drivers are intended to present the minimal code necessary
to support OpenThread. As a result, the example platform drivers do not
necessarily highlight the platform's full capabilities. Consult the [SimpleLink
CC26X2R1 SDK][cc26x2r1-sdk] for more development option. The platform drivers
were built for the [CC2652R1 LAUNCHXL][cc2652r1-launchxl], usage on other
boards with a cc2652r1 may require changes to the peripheral drivers.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. As a result, the example platform drivers do not necessarily highlight the platform's full capabilities. Consult the [SimpleLink CC26X2R1 SDK][cc26x2r1-sdk] for more development option. The platform drivers were built for the [CC2652R1 LAUNCHXL][cc2652r1-launchxl], usage on other boards with a cc2652r1 may require changes to the peripheral drivers.
[cc2652r1-launchxl]: http://www.ti.com/tool/launchxl-cc26x2r1
[cc26x2r1-sdk]: http://www.ti.com/tool/simplelink-cc26x2-sdk
<!---
TODO: Update link when cc2652 product page is live
[cc2652r1]: http://www.ti.com/product/cc2652r1
-->
[cc2652r1]: http://www.ti.com/tool/launchxl-cc26x2r1
## Toolchain
Building the examples for the cc2652 requires [GNU AutoConf][gnu-autoconf],
[GNU AutoMake][gnu-automake], [Python][python], and the [ARM gcc
toolchain][arm-toolchain].
Building the examples for the cc2652 requires [GNU AutoConf][gnu-autoconf], [GNU AutoMake][gnu-automake], [Python][python], and the [ARM gcc toolchain][arm-toolchain].
With the exception of the arm toolchain, most of these tools are installed by
default on modern Posix systems. It is recommended to setup a Linux virtual
machine for building on a Windows host system. For help setting up VirtualBox
with Ubuntu, consult this [community help wiki
article][ubuntu-wiki-virtualbox].
With the exception of the arm toolchain, most of these tools are installed by default on modern Posix systems. It is recommended to setup a Linux virtual machine for building on a Windows host system. For help setting up VirtualBox with Ubuntu, consult this [community help wiki article][ubuntu-wiki-virtualbox].
[gnu-autoconf]: https://www.gnu.org/software/autoconf
[gnu-automake]: https://www.gnu.org/software/automake
@ -38,8 +28,7 @@ article][ubuntu-wiki-virtualbox].
[mingw]: http://www.mingw.org
[ubuntu-wiki-virtualbox]: https://help.ubuntu.com/community/VirtualBox
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -58,11 +47,9 @@ $ make -f examples/Makefile-cc2652
## Flash Binaries
If the build completed successfully, the `elf` files may be found in
`<path-to-openthread>/output/cc2652/bin`.
If the build completed successfully, the `elf` files may be found in `<path-to-openthread>/output/cc2652/bin`.
Flash the images with [Uniflash][uniflash]. Make sure to deselect the binary
check-box, Uniflash assumes a file without an extension is a binary file.
Flash the images with [Uniflash][uniflash]. Make sure to deselect the binary check-box, Uniflash assumes a file without an extension is a binary file.
[uniflash]: http://www.ti.com/tool/uniflash
@ -70,15 +57,13 @@ check-box, Uniflash assumes a file without an extension is a binary file.
### CLI example
1. With a terminal client (PuTTY, minicom, etc.) open the com port associated
with the cc2652 UART. The serial port settings are:
* 115200 baud
* 8 data bits
* no parity bit
* 1 stop bit
1. With a terminal client (PuTTY, minicom, etc.) open the com port associated with the cc2652 UART. The serial port settings are:
- 115200 baud
- 8 data bits
- no parity bit
- 1 stop bit
2. Type `help` for a list of commands.
3. Follow the instructions in the [CLI README][cli-readme] for instructions on
setting up a network.
3. Follow the instructions in the [CLI README][cli-readme] for instructions on setting up a network.
[cli-readme]: ../../../src/cli/README.md
@ -114,7 +99,6 @@ whitelist
### NCP example
Refer to the documentation in the [wpantund][wpantund] project for build
instructions and usage information.
Refer to the documentation in the [wpantund][wpantund] project for build instructions and usage information.
[wpantund]: https://github.com/openthread/wpantund

67
examples/platforms/efr32mg12/README.md
View File

@ -1,20 +1,14 @@
# OpenThread on EFR32MG12 Example
This directory contains example platform drivers for the [Silicon Labs EFR32MG12][efr32mg12]
based on [EFR32™ Mighty Gecko Wireless Starter Kit][SLWSTK6000B] or [Thunderboard™ Sense 2 Sensor-to-Cloud Advanced IoT Development Kit][SLTB004A].
This directory contains example platform drivers for the [Silicon Labs EFR32MG12][efr32mg12] based on [EFR32™ Mighty Gecko Wireless Starter Kit][slwstk6000b] or [Thunderboard™ Sense 2 Sensor-to-Cloud Advanced IoT Development Kit][sltb004a].
[efr32mg]: http://www.silabs.com/products/wireless/mesh-networking/efr32mg-mighty-gecko-zigbee-thread-soc
[SLWSTK6000B]: http://www.silabs.com/products/development-tools/wireless/mesh-networking/mighty-gecko-starter-kit
[SLTB004A]: https://www.silabs.com/products/development-tools/thunderboard/thunderboard-sense-two-kit
[slwstk6000b]: http://www.silabs.com/products/development-tools/wireless/mesh-networking/mighty-gecko-starter-kit
[sltb004a]: https://www.silabs.com/products/development-tools/thunderboard/thunderboard-sense-two-kit
The example platform drivers are intended to present the minimal code
necessary to support OpenThread. [EFR32MG12P SoC][efr32mg12p]
has rich memory and peripheral resources which can support all OpenThread
capabilities. See the "Run the example with EFR32MG12 boards" section below
for an example using basic OpenThread capabilities.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. [EFR32MG12P SoC][efr32mg12p] has rich memory and peripheral resources which can support all OpenThread capabilities. See the "Run the example with EFR32MG12 boards" section below for an example using basic OpenThread capabilities.
See [sleepy-demo/README.md](sleepy-demo/README.md) for instructions for an example that uses the low-energy
modes of the EFR32MG12 when running as a Sleepy End Device.
See [sleepy-demo/README.md](sleepy-demo/README.md) for instructions for an example that uses the low-energy modes of the EFR32MG12 when running as a Sleepy End Device.
[efr32mg12p]: http://www.silabs.com/products/wireless/mesh-networking/efr32mg-mighty-gecko-zigbee-thread-soc/device.EFR32MG12P432F1024GL125
@ -24,8 +18,7 @@ Download and install the [GNU toolchain for ARM Cortex-M][gnu-toolchain].
[gnu-toolchain]: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -43,15 +36,13 @@ $ ./script/bootstrap
- Find Flex SDK v2.7 in the Software Update page and click Install.
- Flex SDK v2.7 will be installed in the path: `/SimplicityStudio_v4/developer/sdks/gecko_sdk_suite`.
For more information on configuring, building, and installing applications for the Wireless Gecko (EFR32)
portfolio using FLEX, see [Getting Started with the Silicon Labs Flex Software Development Kit for the
Wireless Gecko (EFR32™) Portfolio][QSG138]. For more information
on RAIL, see [Radio Abstraction Interface Layer][rail].
For more information on configuring, building, and installing applications for the Wireless Gecko (EFR32) portfolio using FLEX, see [Getting Started with the Silicon Labs Flex Software Development Kit for the Wireless Gecko (EFR32™) Portfolio][qsg138]. For more information on RAIL, see [Radio Abstraction Interface Layer][rail].
[QSG138]: https://www.silabs.com/documents/public/quick-start-guides/qsg138-flex-efr32.pdf
[qsg138]: https://www.silabs.com/documents/public/quick-start-guides/qsg138-flex-efr32.pdf
[rail]: http://www.silabs.com/products/development-tools/software/radio-abstraction-interface-layer-sdk
3. Configure the path to Flex SDK source code.
```bash
$ cd <path-to-openthread>/third_party
$ mkdir silabs
@ -60,6 +51,7 @@ $ cp -rf gecko_sdk_suite <path-to-openthread>/third_party/silabs/
```
Alternatively create a symbolic link to the Flex SDK source code.
```bash
$ cd <path-to-openthread>/third_party
$ mkdir silabs
@ -67,27 +59,29 @@ $ ln -s <path-to-Simplicity-Studio>/developer/sdks/gecko_sdk_suite silabs/gecko_
```
4. Build OpenThread Firmware (CLI example) on EFR32 platform.
```bash
$ cd <path-to-openthread>
$ ./bootstrap
```
For EFR32MG12™ Mighty Gecko Wireless Starter Kit:
```bash
$ make -f examples/Makefile-efr32mg12 BOARD=BRD4161A
```
or alternatively for the Thunderboard™ Sense 2:
```bash
$ make -f examples/Makefile-efr32mg12 BOARD=BRD4166A
```
After a successful build, the `elf` files are found in
`<path-to-openthread>/output/efr32mg12/bin`.
After a successful build, the `elf` files are found in `<path-to-openthread>/output/efr32mg12/bin`.
## Flash Binaries
Compiled binaries may be flashed onto the EFR32 using [JLinkGDBServer][jlinkgdbserver].
EFR32 Starter kit mainboard integrates an on-board SEGGER J-Link debugger.
Compiled binaries may be flashed onto the EFR32 using [JLinkGDBServer][jlinkgdbserver]. EFR32 Starter kit mainboard integrates an on-board SEGGER J-Link debugger.
[jlinkgdbserver]: https://www.segger.com/jlink-gdb-server.html
@ -104,8 +98,7 @@ $ (gdb) c
Note: Support for the "EFR32MG12PxxxF1024" device was added to JLinkGDBServer V6.14d.
Or
Compiled binaries also may be flashed onto the specified EFR32 dev board using [J-Link Commander][j-link-commander].
Or Compiled binaries also may be flashed onto the specified EFR32 dev board using [J-Link Commander][j-link-commander].
[j-link-commander]: https://www.segger.com/products/debug-probes/j-link/tools/j-link-commander/
@ -132,16 +125,12 @@ $ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.ihex
$ <path-to-simplicity-studio>/developer/adapter_packs/commander/commander
```
In the J-Link Device drop-down list select the serial number of the device to flash. Click the Adapter Connect button.
Esnure the Debug Interface drop-down list is set to SWD and click the Target Connect button.
Click on the Flash icon on the left side of the window to switch to the flash page.
In the Flash MCU pane enter the path of the ot-cli-ftd.s37 file or choose the file with the Browse... button.
Click the Flash button located under the Browse... button.
In the J-Link Device drop-down list select the serial number of the device to flash. Click the Adapter Connect button. Esnure the Debug Interface drop-down list is set to SWD and click the Target Connect button. Click on the Flash icon on the left side of the window to switch to the flash page. In the Flash MCU pane enter the path of the ot-cli-ftd.s37 file or choose the file with the Browse... button. Click the Flash button located under the Browse... button.
## Run the example with EFR32MG12 boards
1. Flash two EFR32 boards with the `CLI example` firmware (as shown above).
2. Open terminal to first device `/dev/ttyACM0` (serial port settings: 115200 8-N-1).
Type `help` for a list of commands.
2. Open terminal to first device `/dev/ttyACM0` (serial port settings: 115200 8-N-1). Type `help` for a list of commands.
```bash
> help
@ -204,8 +193,7 @@ Click the Flash button located under the Browse... button.
Done
```
4. Open terminal to second device `/dev/ttyACM1` (serial port settings: 115200 8-N-1)
and attach it to the Thread network as a Router.
4. Open terminal to second device `/dev/ttyACM1` (serial port settings: 115200 8-N-1) and attach it to the Thread network as a Router.
```bash
> dataset masterkey dfd34f0f05cad978ec4e32b0413038ff
@ -244,8 +232,7 @@ Click the Flash button located under the Browse... button.
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
```
The above example demonstrates basic OpenThread capabilities. Enable more features/roles (e.g. commissioner,
joiner, DHCPv6 Server/Client, etc.) by assigning compile-options before compiling.
The above example demonstrates basic OpenThread capabilities. Enable more features/roles (e.g. commissioner, joiner, DHCPv6 Server/Client, etc.) by assigning compile-options before compiling.
```bash
$ cd <path-to-openthread>
@ -253,14 +240,16 @@ $ ./bootstrap
$ make -f examples/Makefile-efr32mg12 COMMISSIONER=1 JOINER=1 DHCP6_CLIENT=1 DHCP6_SERVER=1
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
[cli]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
## Verification
The following toolchain has been used for testing and verification:
- gcc version 7.3.1
- gcc version 7.3.1
The EFR32 example has been verified with following Flex SDK/RAIL Library version:
- Flex SDK version 2.7.0.0
- Flex SDK version 2.7.0.0

51
examples/platforms/efr32mg12/sleepy-demo/README.md
View File

@ -1,13 +1,9 @@
# EFR32MG12 Sleepy Demo Example
The EFR32 Sleepy applications demonstrates Sleepy End Device behaviour using
the EFR32's low power EM2 mode. The steps below will take you through the
process of building and running the demo
The EFR32 Sleepy applications demonstrates Sleepy End Device behaviour using the EFR32's low power EM2 mode. The steps below will take you through the process of building and running the demo
For setting up the build environment refer to [examples/platforms/efr32mg12/README.md](../README.md).
## 1. Build
```bash
@ -24,18 +20,13 @@ $ arm-none-eabi-objcopy -O srec sleepy-demo-mtd sleepy-demo-mtd.s37
$ arm-none-eabi-objcopy -O srec sleepy-demo-ftd sleepy-demo-ftd.s37
```
In Silicon Labs Simplicity Studio flash one device with the sleepy-demo-mtd.s37
image and the other device with the sleepy-demo-ftd.s37 image.
In Silicon Labs Simplicity Studio flash one device with the sleepy-demo-mtd.s37 image and the other device with the sleepy-demo-ftd.s37 image.
For instructions on flashing firmware see [examples/platforms/efr32mg12/README.md](../README.md#flash-binaries)
## 2. Starting nodes
For demonstration purposes the network settings are hardcoded within the source files.
The devices start Thread and form a network within a few seconds of powering on. In a real-life
application the devices should implement and go through a commissioning process to create
a network and add devices.
For demonstration purposes the network settings are hardcoded within the source files. The devices start Thread and form a network within a few seconds of powering on. In a real-life application the devices should implement and go through a commissioning process to create a network and add devices.
When the sleepy-demo-ftd device is started in the CLI the user shall see:
@ -44,8 +35,7 @@ sleepy-demo-ftd started
sleepy-demo-ftd changed to leader
```
When the sleepy-demo-mtd device starts it joins the preconfigured Thread network
before disabling Rx-On-Idle to become a Sleepy-End-Device.
When the sleepy-demo-mtd device starts it joins the preconfigured Thread network before disabling Rx-On-Idle to become a Sleepy-End-Device.
Use the command "child table" in the FTD console and observe the R flag of the child is 0.
@ -58,43 +48,26 @@ Use the command "child table" in the FTD console and observe the R flag of the c
Done
```
## 3. Buttons on the MTD
Pressing button 0 on the MTD toggles between operating as a Minimal End Device (MED) and
a Sleepy End Device (SED) with the RX off when idle.
Pressing button 0 on the MTD toggles between operating as a Minimal End Device (MED) and a Sleepy End Device (SED) with the RX off when idle.
Pressing button 1 on the MTD sends a multicast UDP message containing the
string "mtd button". The FTD listens on the multicast address and will toggle
LED 0 and display a message in the CLI showing "Message Received: mtd button".
Pressing button 1 on the MTD sends a multicast UDP message containing the string "mtd button". The FTD listens on the multicast address and will toggle LED 0 and display a message in the CLI showing "Message Received: mtd button".
## 4. Buttons on the FTD
Pressing either button 0 or 1 on the FTD will send a UDP message to the FTD containing the string
"ftd button". The MTD must first send a multicast message by pressing the MTD's button 1 so that
the FTD knows the address of the MTD to send messages to.
Pressing either button 0 or 1 on the FTD will send a UDP message to the FTD containing the string "ftd button". The MTD must first send a multicast message by pressing the MTD's button 1 so that the FTD knows the address of the MTD to send messages to.
This will toggle the state of LED0 on the MTD. If the MTD is operating as a sleepy end device then
the MTD polls the parent every 5 seconds for messages and will update the LED state on the
next poll.
This will toggle the state of LED0 on the MTD. If the MTD is operating as a sleepy end device then the MTD polls the parent every 5 seconds for messages and will update the LED state on the next poll.
## 5. Monitoring power consumption of the MTD
Open the Energy Profiler within Silicon Labs Simplicity Studio. Within the Quick Access menu
select Start Energy Capture... and select the MTD device. When operating as a Sleepy End Device
with no LEDs on the current should be under 20 microamps with occassional spikes during waking
and polling the parent. With the LED on the MTD has a current consumption of approximately 1mA.
Open the Energy Profiler within Silicon Labs Simplicity Studio. Within the Quick Access menu select Start Energy Capture... and select the MTD device. When operating as a Sleepy End Device with no LEDs on the current should be under 20 microamps with occassional spikes during waking and polling the parent. With the LED on the MTD has a current consumption of approximately 1mA.
When operating as a Minial End Device with the Rx on Idle observe that the current is in the order
of 10ma.
When operating as a Minial End Device with the Rx on Idle observe that the current is in the order of 10ma.
With further configuration of GPIOs and peripherals it is possible to reduce the sleepy current
consumption further.
With further configuration of GPIOs and peripherals it is possible to reduce the sleepy current consumption further.
## 6. Notes on sleeping, sleepy callback and interrupts
To allow the EFR32 to enter sleepy mode the application must register a callback with efr32SetSleepCallback.
The return value of callback is used to indicate that the application has no further work to do and that
it is safe to go into a low power mode. The callback is called with interrupts disabled so should do
the minimum required to check if it can sleep.
To allow the EFR32 to enter sleepy mode the application must register a callback with efr32SetSleepCallback. The return value of callback is used to indicate that the application has no further work to do and that it is safe to go into a low power mode. The callback is called with interrupts disabled so should do the minimum required to check if it can sleep.

64
examples/platforms/efr32mg13/README.md
View File

@ -1,19 +1,13 @@
# OpenThread on EFR32MG13 Example
This directory contains example platform drivers for the [Silicon Labs EFR32MG13][efr32mg13]
based on [EFR32™ Mighty Gecko Wireless Starter Kit][SLWSTK6000B].
This directory contains example platform drivers for the [Silicon Labs EFR32MG13][efr32mg13] based on [EFR32™ Mighty Gecko Wireless Starter Kit][slwstk6000b].
[efr32mg]: http://www.silabs.com/products/wireless/mesh-networking/efr32mg-mighty-gecko-zigbee-thread-soc
[SLWSTK6000B]: http://www.silabs.com/products/development-tools/wireless/mesh-networking/mighty-gecko-starter-kit
[slwstk6000b]: http://www.silabs.com/products/development-tools/wireless/mesh-networking/mighty-gecko-starter-kit
The example platform drivers are intended to present the minimal code
necessary to support OpenThread. [EFR32MG13P SoC][efr32mg13p]
has rich memory and peripheral resources which can support all OpenThread
capabilities. See the "Run the example with EFR32MG13 boards" section below
for an example using basic OpenThread capabilities.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. [EFR32MG13P SoC][efr32mg13p] has rich memory and peripheral resources which can support all OpenThread capabilities. See the "Run the example with EFR32MG13 boards" section below for an example using basic OpenThread capabilities.
See [sleepy-demo/README.md](sleepy-demo/README.md) for instructions for an example that uses the low-energy
modes of the EFR32MG13 when running as a Sleepy End Device.
See [sleepy-demo/README.md](sleepy-demo/README.md) for instructions for an example that uses the low-energy modes of the EFR32MG13 when running as a Sleepy End Device.
[efr32mg13p]: http://www.silabs.com/products/wireless/mesh-networking/efr32mg-mighty-gecko-zigbee-thread-soc/device.EFR32MG13P432F1024GL125
@ -23,8 +17,7 @@ Download and install the [GNU toolchain for ARM Cortex-M][gnu-toolchain].
[gnu-toolchain]: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -42,15 +35,13 @@ $ ./script/bootstrap
- Find Flex SDK v2.7 in the Software Update page and click Install.
- Flex SDK v2.7 will be installed in the path: `/SimplicityStudio_v4/developer/sdks/gecko_sdk_suite`.
For more information on configuring, building, and installing applications for the Wireless Gecko (EFR32)
portfolio using FLEX, see [Getting Started with the Silicon Labs Flex Software Development Kit for the
Wireless Gecko (EFR32™) Portfolio][QSG138]. For more information
on RAIL, see [Radio Abstraction Interface Layer][rail].
For more information on configuring, building, and installing applications for the Wireless Gecko (EFR32) portfolio using FLEX, see [Getting Started with the Silicon Labs Flex Software Development Kit for the Wireless Gecko (EFR32™) Portfolio][qsg138]. For more information on RAIL, see [Radio Abstraction Interface Layer][rail].
[QSG138]: https://www.silabs.com/documents/public/quick-start-guides/qsg138-flex-efr32.pdf
[qsg138]: https://www.silabs.com/documents/public/quick-start-guides/qsg138-flex-efr32.pdf
[rail]: http://www.silabs.com/products/development-tools/software/radio-abstraction-interface-layer-sdk
3. Configure the path to Flex SDK source code.
```bash
$ cd <path-to-openthread>/third_party
$ mkdir silabs
@ -59,6 +50,7 @@ $ cp -rf gecko_sdk_suite <path-to-openthread>/third_party/silabs/
```
Alternatively create a symbolic link to the Flex SDK source code.
```bash
$ cd <path-to-openthread>/third_party
$ mkdir silabs
@ -66,22 +58,23 @@ $ ln -s <path-to-Simplicity-Studio>/developer/sdks/gecko_sdk_suite silabs/gecko_
```
4. Build OpenThread Firmware (CLI example) on EFR32 platform.
```bash
$ cd <path-to-openthread>
$ ./bootstrap
```
For EFR32MG13™ Mighty Gecko Wireless Starter Kit:
```bash
$ make -f examples/Makefile-efr32mg13 BOARD=BRD4168A
```
After a successful build, the `elf` files are found in
`<path-to-openthread>/output/efr32mg13/bin`.
After a successful build, the `elf` files are found in `<path-to-openthread>/output/efr32mg13/bin`.
## Flash Binaries
Compiled binaries may be flashed onto the EFR32 using [JLinkGDBServer][jlinkgdbserver].
EFR32 Starter kit mainboard integrates an on-board SEGGER J-Link debugger.
Compiled binaries may be flashed onto the EFR32 using [JLinkGDBServer][jlinkgdbserver]. EFR32 Starter kit mainboard integrates an on-board SEGGER J-Link debugger.
[jlinkgdbserver]: https://www.segger.com/jlink-gdb-server.html
@ -98,8 +91,7 @@ $ (gdb) c
Note: Support for the "EFR32MG13PxxxF1024" device was added to JLinkGDBServer V6.14d.
Or
Compiled binaries also may be flashed onto the specified EFR32 dev board using [J-Link Commander][j-link-commander].
Or Compiled binaries also may be flashed onto the specified EFR32 dev board using [J-Link Commander][j-link-commander].
[j-link-commander]: https://www.segger.com/products/debug-probes/j-link/tools/j-link-commander/
@ -126,16 +118,12 @@ $ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.ihex
$ <path-to-simplicity-studio>/developer/adapter_packs/commander/commander
```
In the J-Link Device drop-down list select the serial number of the device to flash. Click the Adapter Connect button.
Esnure the Debug Interface drop-down list is set to SWD and click the Target Connect button.
Click on the Flash icon on the left side of the window to switch to the flash page.
In the Flash MCU pane enter the path of the ot-cli-ftd.s37 file or choose the file with the Browse... button.
Click the Flash button located under the Browse... button.
In the J-Link Device drop-down list select the serial number of the device to flash. Click the Adapter Connect button. Esnure the Debug Interface drop-down list is set to SWD and click the Target Connect button. Click on the Flash icon on the left side of the window to switch to the flash page. In the Flash MCU pane enter the path of the ot-cli-ftd.s37 file or choose the file with the Browse... button. Click the Flash button located under the Browse... button.
## Run the example with EFR32MG13 boards
1. Flash two EFR32 boards with the `CLI example` firmware (as shown above).
2. Open terminal to first device `/dev/ttyACM0` (serial port settings: 115200 8-N-1).
Type `help` for a list of commands.
2. Open terminal to first device `/dev/ttyACM0` (serial port settings: 115200 8-N-1). Type `help` for a list of commands.
```bash
> help
@ -198,8 +186,7 @@ Click the Flash button located under the Browse... button.
Done
```
4. Open terminal to second device `/dev/ttyACM1` (serial port settings: 115200 8-N-1)
and attach it to the Thread network as a Router.
4. Open terminal to second device `/dev/ttyACM1` (serial port settings: 115200 8-N-1) and attach it to the Thread network as a Router.
```bash
> dataset masterkey dfd34f0f05cad978ec4e32b0413038ff
@ -238,8 +225,7 @@ Click the Flash button located under the Browse... button.
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
```
The above example demonstrates basic OpenThread capabilities. Enable more features/roles (e.g. commissioner,
joiner, DHCPv6 Server/Client, etc.) by assigning compile-options before compiling.
The above example demonstrates basic OpenThread capabilities. Enable more features/roles (e.g. commissioner, joiner, DHCPv6 Server/Client, etc.) by assigning compile-options before compiling.
```bash
$ cd <path-to-openthread>
@ -247,14 +233,16 @@ $ ./bootstrap
$ make -f examples/Makefile-efr32mg13 COMMISSIONER=1 JOINER=1 DHCP6_CLIENT=1 DHCP6_SERVER=1
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
[cli]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
## Verification
The following toolchain has been used for testing and verification:
- gcc version 7.3.1
- gcc version 7.3.1
The EFR32 example has been verified with following Flex SDK/RAIL Library version:
- Flex SDK version 2.7.0.0
- Flex SDK version 2.7.0.0

51
examples/platforms/efr32mg13/sleepy-demo/README.md
View File

@ -1,13 +1,9 @@
# EFR32MG13 Sleepy Demo Example
The EFR32 Sleepy applications demonstrates Sleepy End Device behaviour using
the EFR32's low power EM2 mode. The steps below will take you through the
process of building and running the demo
The EFR32 Sleepy applications demonstrates Sleepy End Device behaviour using the EFR32's low power EM2 mode. The steps below will take you through the process of building and running the demo
For setting up the build environment refer to [examples/platforms/efr32mg13/README.md](../README.md).
## 1. Build
```bash
@ -24,18 +20,13 @@ $ arm-none-eabi-objcopy -O srec sleepy-demo-mtd sleepy-demo-mtd.s37
$ arm-none-eabi-objcopy -O srec sleepy-demo-ftd sleepy-demo-ftd.s37
```
In Silicon Labs Simplicity Studio flash one device with the sleepy-demo-mtd.s37
image and the other device with the sleepy-demo-ftd.s37 image.
In Silicon Labs Simplicity Studio flash one device with the sleepy-demo-mtd.s37 image and the other device with the sleepy-demo-ftd.s37 image.
For instructions on flashing firmware see [examples/platforms/efr32mg13/README.md](../README.md#flash-binaries)
## 2. Starting nodes
For demonstration purposes the network settings are hardcoded within the source files.
The devices start Thread and form a network within a few seconds of powering on. In a real-life
application the devices should implement and go through a commissioning process to create
a network and add devices.
For demonstration purposes the network settings are hardcoded within the source files. The devices start Thread and form a network within a few seconds of powering on. In a real-life application the devices should implement and go through a commissioning process to create a network and add devices.
When the sleepy-demo-ftd device is started in the CLI the user shall see:
@ -44,8 +35,7 @@ sleepy-demo-ftd started
sleepy-demo-ftd changed to leader
```
When the sleepy-demo-mtd device starts it joins the preconfigured Thread network
before disabling Rx-On-Idle to become a Sleepy-End-Device.
When the sleepy-demo-mtd device starts it joins the preconfigured Thread network before disabling Rx-On-Idle to become a Sleepy-End-Device.
Use the command "child table" in the FTD console and observe the R flag of the child is 0.
@ -58,43 +48,26 @@ Use the command "child table" in the FTD console and observe the R flag of the c
Done
```
## 3. Buttons on the MTD
Pressing button 0 on the MTD toggles between operating as a Minimal End Device (MED) and
a Sleepy End Device (SED) with the RX off when idle.
Pressing button 0 on the MTD toggles between operating as a Minimal End Device (MED) and a Sleepy End Device (SED) with the RX off when idle.
Pressing button 1 on the MTD sends a multicast UDP message containing the
string "mtd button". The FTD listens on the multicast address and will toggle
LED 0 and display a message in the CLI showing "Message Received: mtd button".
Pressing button 1 on the MTD sends a multicast UDP message containing the string "mtd button". The FTD listens on the multicast address and will toggle LED 0 and display a message in the CLI showing "Message Received: mtd button".
## 4. Buttons on the FTD
Pressing either button 0 or 1 on the FTD will send a UDP message to the FTD containing the string
"ftd button". The MTD must first send a multicast message by pressing the MTD's button 1 so that
the FTD knows the address of the MTD to send messages to.
Pressing either button 0 or 1 on the FTD will send a UDP message to the FTD containing the string "ftd button". The MTD must first send a multicast message by pressing the MTD's button 1 so that the FTD knows the address of the MTD to send messages to.
This will toggle the state of LED0 on the MTD. If the MTD is operating as a sleepy end device then
the MTD polls the parent every 5 seconds for messages and will update the LED state on the
next poll.
This will toggle the state of LED0 on the MTD. If the MTD is operating as a sleepy end device then the MTD polls the parent every 5 seconds for messages and will update the LED state on the next poll.
## 5. Monitoring power consumption of the MTD
Open the Energy Profiler within Silicon Labs Simplicity Studio. Within the Quick Access menu
select Start Energy Capture... and select the MTD device. When operating as a Sleepy End Device
with no LEDs on the current should be under 20 microamps with occassional spikes during waking
and polling the parent. With the LED on the MTD has a current consumption of approximately 1mA.
Open the Energy Profiler within Silicon Labs Simplicity Studio. Within the Quick Access menu select Start Energy Capture... and select the MTD device. When operating as a Sleepy End Device with no LEDs on the current should be under 20 microamps with occassional spikes during waking and polling the parent. With the LED on the MTD has a current consumption of approximately 1mA.
When operating as a Minial End Device with the Rx on Idle observe that the current is in the order
of 10ma.
When operating as a Minial End Device with the Rx on Idle observe that the current is in the order of 10ma.
With further configuration of GPIOs and peripherals it is possible to reduce the sleepy current
consumption further.
With further configuration of GPIOs and peripherals it is possible to reduce the sleepy current consumption further.
## 6. Notes on sleeping, sleepy callback and interrupts
To allow the EFR32 to enter sleepy mode the application must register a callback with efr32SetSleepCallback.
The return value of callback is used to indicate that the application has no further work to do and that
it is safe to go into a low power mode. The callback is called with interrupts disabled so should do
the minimum required to check if it can sleep.
To allow the EFR32 to enter sleepy mode the application must register a callback with efr32SetSleepCallback. The return value of callback is used to indicate that the application has no further work to do and that it is safe to go into a low power mode. The callback is called with interrupts disabled so should do the minimum required to check if it can sleep.

59
examples/platforms/efr32mg21/README.md
View File

@ -1,16 +1,11 @@
# OpenThread on EFR32MG21 Example
This directory contains example platform drivers for the [Silicon Labs EFR32MG21][efr32mg]
based on [EFR32™ Mighty Gecko Wireless Starter Kit][SLWSTK6000B]
This directory contains example platform drivers for the [Silicon Labs EFR32MG21][efr32mg] based on [EFR32™ Mighty Gecko Wireless Starter Kit][slwstk6000b]
[efr32mg]: http://www.silabs.com/products/wireless/mesh-networking/efr32mg-mighty-gecko-zigbee-thread-soc
[SLWSTK6000B]: http://www.silabs.com/products/development-tools/wireless/mesh-networking/mighty-gecko-starter-kit
[slwstk6000b]: http://www.silabs.com/products/development-tools/wireless/mesh-networking/mighty-gecko-starter-kit
The example platform drivers are intended to present the minimal code
necessary to support OpenThread. [EFR32MG21 SoC][efr32mg21]
has rich memory and peripheral resources which can support all OpenThread
capabilities. See the "Run the example with EFR32 boards" section below
for an example using basic OpenThread capabilities.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. [EFR32MG21 SoC][efr32mg21] has rich memory and peripheral resources which can support all OpenThread capabilities. See the "Run the example with EFR32 boards" section below for an example using basic OpenThread capabilities.
[efr32mg21]: https://www.silabs.com/products/wireless/mesh-networking/series-2-efr32-mighty-gecko-zigbee-thread-soc/device.efr32mg21a020f768im32
@ -20,8 +15,7 @@ Download and install the [GNU toolchain for ARM Cortex-M][gnu-toolchain].
[gnu-toolchain]: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -39,29 +33,26 @@ $ ./script/bootstrap
- Find Flex SDK v2.7 in the Software Update page and click Install.
- Flex SDK v2.7 will be installed in the path: `/SimplicityStudio_v4/developer/sdks/gecko_sdk_suite`.
For more information on configuring, building, and installing applications for the Wireless Gecko (EFR32)
portfolio using FLEX, see [Getting Started with the Silicon Labs Flex Software Development Kit for the
Wireless Gecko (EFR32™) Portfolio][QSG138]. For more information
on RAIL, see [Radio Abstraction Interface Layer][rail].
For more information on configuring, building, and installing applications for the Wireless Gecko (EFR32) portfolio using FLEX, see [Getting Started with the Silicon Labs Flex Software Development Kit for the Wireless Gecko (EFR32™) Portfolio][qsg138]. For more information on RAIL, see [Radio Abstraction Interface Layer][rail].
[QSG138]: https://www.silabs.com/documents/public/quick-start-guides/qsg138-flex-efr32.pdf
[qsg138]: https://www.silabs.com/documents/public/quick-start-guides/qsg138-flex-efr32.pdf
[rail]: http://www.silabs.com/products/development-tools/software/radio-abstraction-interface-layer-sdk
3. Configure the path to Flex SDK source code.
```bash
$ cd <path-to-Simplicity-Studio>/developer/sdks
$ cp -rf gecko_sdk_suite <path-to-openthread>/third_party/silabs/
```
Alternatively create a symbolic link to the Flex SDK source code.
```bash
$ cd <path-to-openthread>/third_party
$ ln -s <path-to-Simplicity-Studio>/developer/sdks/gecko_sdk_suite silabs/gecko_sdk_suite
```
Note: Due to an error in the core_cm33.h file provided by ARM, the compiler will throw an error when pedantic
option is used on the builds. To avoid this, please add the following lines of code at the top of the
file core_cm33.h:
Note: Due to an error in the core_cm33.h file provided by ARM, the compiler will throw an error when pedantic option is used on the builds. To avoid this, please add the following lines of code at the top of the file core_cm33.h:
```
#if defined(__GNUC__)
@ -76,17 +67,19 @@ core_cm33.h can be found at:
```
4. Build OpenThread Firmware (CLI example) on EFR32 platform.
```bash
$ cd <path-to-openthread>
$ ./bootstrap
```
For EFR32MG21™ Mighty Gecko Wireless Starter Kit:
```bash
$ make -f examples/Makefile-efr32mg21 BOARD=BRD4180A
```
After a successful build, the `elf` files are found in
`<path-to-openthread>/output/efr32mg21/bin`.
After a successful build, the `elf` files are found in `<path-to-openthread>/output/efr32mg21/bin`.
## Flash Binaries
@ -98,16 +91,12 @@ $ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex
$ <path-to-simplicity-studio>/developer/adapter_packs/commander/commander
```
In the J-Link Device drop-down list select the serial number of the device to flash. Click the Adapter Connect button.
Esnure the Debug Interface drop-down list is set to SWD and click the Target Connect button.
Click on the Flash icon on the left side of the window to switch to the flash page.
In the Flash MCU pane enter the path of the ot-cli-ftd.s37 file or choose the file with the Browse... button.
Click the Flash button located under the Browse... button.
In the J-Link Device drop-down list select the serial number of the device to flash. Click the Adapter Connect button. Esnure the Debug Interface drop-down list is set to SWD and click the Target Connect button. Click on the Flash icon on the left side of the window to switch to the flash page. In the Flash MCU pane enter the path of the ot-cli-ftd.s37 file or choose the file with the Browse... button. Click the Flash button located under the Browse... button.
## Run the example with EFR32MG21 boards
1. Flash two EFR32 boards with the `CLI example` firmware (as shown above).
2. Open terminal to first device `/dev/ttyACM0` (serial port settings: 115200 8-N-1).
Type `help` for a list of commands.
2. Open terminal to first device `/dev/ttyACM0` (serial port settings: 115200 8-N-1). Type `help` for a list of commands.
```bash
> help
@ -156,8 +145,7 @@ leader
Done
```
4. Open terminal to second device `/dev/ttyACM1` (serial port settings: 115200 8-N-1)
and attach it to the Thread network as a Router.
4. Open terminal to second device `/dev/ttyACM1` (serial port settings: 115200 8-N-1) and attach it to the Thread network as a Router.
```bash
> panid 0xface
@ -194,8 +182,7 @@ Done
8 bytes from fdde:ad00:beef:0:5b:3bcd:deff:7786: icmp_seq=1 hlim=64 time=24ms
```
The above example demonstrates basic OpenThread capabilities. Enable more features/roles (e.g. commissioner,
joiner, DHCPv6 Server/Client, etc.) by assigning compile-options before compiling.
The above example demonstrates basic OpenThread capabilities. Enable more features/roles (e.g. commissioner, joiner, DHCPv6 Server/Client, etc.) by assigning compile-options before compiling.
```bash
$ cd <path-to-openthread>
@ -203,14 +190,16 @@ $ ./bootstrap
$ make -f examples/Makefile-efr32mg21 COMMISSIONER=1 JOINER=1 DHCP6_CLIENT=1 DHCP6_SERVER=1
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
[cli]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
## Verification
The following toolchain has been used for testing and verification:
- gcc version 7.3.1
- gcc version 7.3.1
The EFR32 example has been verified with following Flex SDK/RAIL Library version:
- Flex SDK version 2.7.0.0
- Flex SDK version 2.7.0.0

40
examples/platforms/efr32mg21/sleepy-demo/README.md
View File

@ -1,13 +1,9 @@
# EFR32MG21 Sleepy Demo Example
The EFR32 Sleepy applications demonstrates Sleepy End Device behaviour using
the EFR32's low power EM2 mode. The steps below will take you through the
process of building and running the demo
The EFR32 Sleepy applications demonstrates Sleepy End Device behaviour using the EFR32's low power EM2 mode. The steps below will take you through the process of building and running the demo
For setting up the build environment refer to [examples/platforms/efr32mg21/README.md](../README.md).
## 1. Build
```bash
@ -24,18 +20,13 @@ $ arm-none-eabi-objcopy -O srec sleepy-demo-mtd sleepy-demo-mtd.s37
$ arm-none-eabi-objcopy -O srec sleepy-demo-ftd sleepy-demo-ftd.s37
```
In Silicon Labs Simplicity Studio flash one device with the sleepy-demo-mtd.s37
image and the other device with the sleepy-demo-ftd.s37 image.
In Silicon Labs Simplicity Studio flash one device with the sleepy-demo-mtd.s37 image and the other device with the sleepy-demo-ftd.s37 image.
For instructions on flashing firmware see [examples/platforms/efr32mg21/README.md](../README.md#flash-binaries)
## 2. Starting nodes
For demonstration purposes the network settings are hardcoded within the source files.
The devices start Thread and form a network within a few seconds of powering on. In a real-life
application the devices should implement and go through a commissioning process to create
a network and add devices.
For demonstration purposes the network settings are hardcoded within the source files. The devices start Thread and form a network within a few seconds of powering on. In a real-life application the devices should implement and go through a commissioning process to create a network and add devices.
When the sleepy-demo-ftd device is started in the CLI the user shall see:
@ -44,8 +35,7 @@ sleepy-demo-ftd started
sleepy-demo-ftd changed to leader
```
When the sleepy-demo-mtd device starts it joins the preconfigured Thread network
before disabling Rx-On-Idle to become a Sleepy-End-Device.
When the sleepy-demo-mtd device starts it joins the preconfigured Thread network before disabling Rx-On-Idle to become a Sleepy-End-Device.
Use the command "child table" in the FTD console and observe the R flag of the child is 0.
@ -58,30 +48,18 @@ Use the command "child table" in the FTD console and observe the R flag of the c
Done
```
## 3. MTD behaviour on wakeup
MTD wakes up every 5 seconds and sends a multicast UDP message containing the
string "mtd is awake". The FTD listens on the multicast address and will toggle
LED 0 and display a message in the CLI showing "Message Received: mtd is awake".
MTD wakes up every 5 seconds and sends a multicast UDP message containing the string "mtd is awake". The FTD listens on the multicast address and will toggle LED 0 and display a message in the CLI showing "Message Received: mtd is awake".
## 4. Monitoring power consumption of the MTD
Open the Energy Profiler within Silicon Labs Simplicity Studio. Within the Quick Access menu
select Start Energy Capture... and select the MTD device. When operating as a Sleepy End Device
with no LEDs on the current should be under 20-80 microamps with occassional spikes during waking
and polling the parent. With the LED on the MTD has a current consumption of approximately 1mA.
Open the Energy Profiler within Silicon Labs Simplicity Studio. Within the Quick Access menu select Start Energy Capture... and select the MTD device. When operating as a Sleepy End Device with no LEDs on the current should be under 20-80 microamps with occassional spikes during waking and polling the parent. With the LED on the MTD has a current consumption of approximately 1mA.
When operating as a Minial End Device with the Rx on Idle observe that the current is in the order
of 10ma.
When operating as a Minial End Device with the Rx on Idle observe that the current is in the order of 10ma.
With further configuration of GPIOs and peripherals it is possible to reduce the sleepy current
consumption further.
With further configuration of GPIOs and peripherals it is possible to reduce the sleepy current consumption further.
## 5. Notes on sleeping, sleepy callback and interrupts
To allow the EFR32 to enter sleepy mode the application must register a callback with efr32SetSleepCallback.
The return value of callback is used to indicate that the application has no further work to do and that
it is safe to go into a low power mode. The callback is called with interrupts disabled so should do
the minimum required to check if it can sleep.
To allow the EFR32 to enter sleepy mode the application must register a callback with efr32SetSleepCallback. The return value of callback is used to indicate that the application has no further work to do and that it is safe to go into a low power mode. The callback is called with interrupts disabled so should do the minimum required to check if it can sleep.

16
examples/platforms/gp712/README.md
View File

@ -4,15 +4,16 @@ This directory contains example platform drivers for Qorvo gp712 on RPi.
## Toolchain
This example use the GNU GCC toolchain on the Raspberry Pi.
To build on the Pi:
1) Download the repo to the Pi
2) go to the subfolder in the openthread repo: third_party/nlbuild-autotools/repo/tools/packages and enter this command:
This example use the GNU GCC toolchain on the Raspberry Pi. To build on the Pi:
1. Download the repo to the Pi
2. go to the subfolder in the openthread repo: third_party/nlbuild-autotools/repo/tools/packages and enter this command:
```bash
$ sudo /bin/bash build
```
Note that you may need to install additional packages to make this build work, depending on your actual RPi OS version.
The build process will complain if additional packages are required.
Note that you may need to install additional packages to make this build work, depending on your actual RPi OS version. The build process will complain if additional packages are required.
## Build Examples
@ -23,8 +24,7 @@ $ ./bootstrap
$ REFERENCE_DEVICE=1 CLI_LOGGING=1 COMMISSIONER=1 JOINER=1 DHCP6_CLIENT=1 DHCP6_SERVER=1 BORDER_ROUTER=1 make -f examples/Makefile-gp712
```
After a successful build, the `elf` files are found in
`<path-to-openthread>/output/gp712/bin`.
After a successful build, the `elf` files are found in `<path-to-openthread>/output/gp712/bin`.
Building a variant which interfaces via a tcp socket is also possible. Replace the uart-posix.c with uart-socket.c in the Makefile.am from examples/platforms/gp712/Makefile.am and rebuild. Now it should be possible to open a telnet to socket 9190 of the raspberry pi from a remote PC. This also easier testing with the official Thread Test Harness.

121
examples/platforms/jn5189/README.md
View File

@ -1,34 +1,27 @@
# OpenThread on NXP JN5189 Example
This directory contains example platform drivers for the [NXP JN5189][https://www.nxp.com/products/wireless/thread/jn5189-88-t-high-performance-and-ultra-low-power-mcus-for-zigbee-and-thread-with-built-in-nfc-option:JN5189_88_T]
based on [JN5189-DK006][https://www.nxp.com/products/wireless/zigbee/advanced-development-kit-for-jn5189-88:JN5189-DK006] hardware platform.
This directory contains example platform drivers for the [NXP JN5189][https://www.nxp.com/products/wireless/thread/jn5189-88-t-high-performance-and-ultra-low-power-mcus-for-zigbee-and-thread-with-built-in-nfc-option:jn5189_88_t] based on [JN5189-DK006][https://www.nxp.com/products/wireless/zigbee/advanced-development-kit-for-jn5189-88:jn5189-dk006] hardware platform.
The example platform drivers are intended to present the minimal code
necessary to support OpenThread. As a result, the example platform
drivers do not necessarily highlight the platform's full capabilities.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. As a result, the example platform drivers do not necessarily highlight the platform's full capabilities.
## Toolchain
OpenThread environment is suited to be run on a Linux-based OS. Recommended OS is Ubuntu 18.04.2 LTS.
Download and install the [MCUXpresso IDE][mcuxpresso ide].
OpenThread environment is suited to be run on a Linux-based OS. Recommended OS is Ubuntu 18.04.2 LTS. Download and install the [MCUXpresso IDE][mcuxpresso ide].
[mcuxpresso ide]: https://www.nxp.com/support/developer-resources/software-development-tools/mcuxpresso-software-and-tools/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE
In a Bash terminal (found, for example, in Ubuntu OS), follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal (found, for example, in Ubuntu OS), follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
$ ./script/bootstrap
```
If a network connection timeout is encountered, re-run the script.
Python-pip is also required for the build. User can install it by running "sudo apt-get install Python-pip" in bash.
After installing Python-pip, execute "pip install PyCryptodome" in bash. This is needed for signing the built binary in order to load it on the board.
Also, pycrypto "pip install pycrypto" is required for PKCS1.
Python-pip is also required for the build. User can install it by running "sudo apt-get install Python-pip" in bash. After installing Python-pip, execute "pip install PyCryptodome" in bash. This is needed for signing the built binary in order to load it on the board. Also, pycrypto "pip install pycrypto" is required for PKCS1.
Windows 10 offers the possibility of running bash by installing "Ubuntu on Windows" from Microsoft Store. This application allows the user to use Ubuntu Terminal and run Ubuntu command line utilities including bash, ssh, git, apt and many more.
If this option is used, it is recommended to add instructions for the path mapping in MCUXpresso IDE. This can be done after adding the project to the workspace by going to Run->"Debug Configuration"->"C/C++(NXP Semiconductors) MCU Application"->Source->Add. Then the user should create a path mapping such that MCUXpresso IDE will find the mount point for the "Ubuntu in Windows" subsystem.
For example, user can enter compilation path recognized by Ubuntu as /mnt/c/<path-to-openthread>, while equivalent "Local file system path" is C:/<path-to-openthread>. This example assumes that the openthread package is installed on the C drive.
Windows 10 offers the possibility of running bash by installing "Ubuntu on Windows" from Microsoft Store. This application allows the user to use Ubuntu Terminal and run Ubuntu command line utilities including bash, ssh, git, apt and many more. If this option is used, it is recommended to add instructions for the path mapping in MCUXpresso IDE. This can be done after adding the project to the workspace by going to Run->"Debug Configuration"->"C/C++(NXP Semiconductors) MCU Application"->Source->Add. Then the user should create a path mapping such that MCUXpresso IDE will find the mount point for the "Ubuntu in Windows" subsystem. For example, user can enter compilation path recognized by Ubuntu as /mnt/c/<path-to-openthread>, while equivalent "Local file system path" is C:/<path-to-openthread>. This example assumes that the openthread package is installed on the C drive.
## Build Examples
@ -38,15 +31,14 @@ $ ./bootstrap
$ make -f examples/Makefile-jn5189
```
After a successful build, the `elf` files are found in
`<path-to-openthread>/output/jn5189/bin`.
After a successful build, the `elf` files are found in `<path-to-openthread>/output/jn5189/bin`.
## Flash Binaries
Connect to the board by plugging a mini-USB cable to the connector marked with TARGET on the DK6 board. This connector is situated on the same side with the power connector.
OpenThread example application compiled binaries can be found in `<path-to-openthread>/output/jn5189/bin` and include FTD (Full Thread Device) and MTD (Minimal Thread Device) variants of CLI and NCP applications.
The compiled binaries can be flashed onto the JN5189 using MCUXpresso IDE. This requires the following steps:
OpenThread example application compiled binaries can be found in `<path-to-openthread>/output/jn5189/bin` and include FTD (Full Thread Device) and MTD (Minimal Thread Device) variants of CLI and NCP applications. The compiled binaries can be flashed onto the JN5189 using MCUXpresso IDE. This requires the following steps:
1. Import the JN5189 SDK into MCUXpresso IDE. This can be done by dragging and dropping the SDK archive into MCUXpresso IDE's Installed SDKs tab. The archive for SDK_2.6.0_JN5189DK6 can be downloaded from https://mcuxpresso.nxp.com.
2. In MCUXpresso IDE, go to File->Import->C/C++->"Existing Code as Makefile Project" and click Next.
3. Select the OpenThread folder as the "Existing Code Location". In the "Toolchain for Indexer Settings" list, be sure to keep the setting to "none". Click Finish.
@ -67,72 +59,71 @@ The compiled binaries can be flashed onto the JN5189 using MCUXpresso IDE. This
## Running the example
1. Prepare two boards with the flashed `CLI Example` (as shown above). Make sure that the JN4 jumper is set to RX and the JN7 jumper is set to TX, connecting the LPC and JN UART0 pins.
2. The CLI example uses UART connection. To view raw UART output, start a terminal
emulator like PuTTY and connect to the used COM port with the following UART settings:
- Baud rate: 115200
- 8 data bits
- 1 stop bit
- No parity
- No flow control
2. The CLI example uses UART connection. To view raw UART output, start a terminal emulator like PuTTY and connect to the used COM port with the following UART settings:
- Baud rate: 115200
- 8 data bits
- 1 stop bit
- No parity
- No flow control
3. Open a terminal connection on the first board and start a new Thread network.
```bash
> panid 0xabcd
Done
> ifconfig up
Done
> thread start
Done
```
```bash
> panid 0xabcd
Done
> ifconfig up
Done
> thread start
Done
```
4. After a couple of seconds the node will become a Leader of the network.
```bash
> state
Leader
```
```bash
> state
Leader
```
5. Open a terminal connection on the second board and attach a node to the network.
```bash
> panid 0xabcd
Done
> ifconfig up
Done
> thread start
Done
```
```bash
> panid 0xabcd
Done
> ifconfig up
Done
> thread start
Done
```
6. After a couple of seconds the second node will attach and become a Child.
```bash
> state
Child
```
```bash
> state
Child
```
7. List all IPv6 addresses of the first board.
```bash
> ipaddr
fdde:ad00:beef:0:0:ff:fe00:fc00
fdde:ad00:beef:0:0:ff:fe00:9c00
fdde:ad00:beef:0:4bcb:73a5:7c28:318e
fe80:0:0:0:5c91:c61:b67c:271c
```
```bash
> ipaddr
fdde:ad00:beef:0:0:ff:fe00:fc00
fdde:ad00:beef:0:0:ff:fe00:9c00
fdde:ad00:beef:0:4bcb:73a5:7c28:318e
fe80:0:0:0:5c91:c61:b67c:271c
```
8. Choose one of them and send an ICMPv6 ping from the second board.
```bash
> ping fdde:ad00:beef:0:0:ff:fe00:fc00
16 bytes from fdde:ad00:beef:0:0:ff:fe00:fc00: icmp_seq=1 hlim=64 time=8ms
```
```bash
> ping fdde:ad00:beef:0:0:ff:fe00:fc00
16 bytes from fdde:ad00:beef:0:0:ff:fe00:fc00: icmp_seq=1 hlim=64 time=8ms
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
[cli]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
## Known limitations
While running the build process in "Ubuntu on Windows" bash, user can encounter build errors from unknown reasons. The current workaround is to re-run the "make -f examples/Makefile-jn5189" command.
NCP applications have not been tested.
While running the build process in "Ubuntu on Windows" bash, user can encounter build errors from unknown reasons. The current workaround is to re-run the "make -f examples/Makefile-jn5189" command. NCP applications have not been tested.

141
examples/platforms/kw41z/README.md
View File

@ -1,14 +1,11 @@
# OpenThread on NXP(Freescale) Kinetis MKW41Z512 Example
This directory contains example platform drivers for the [NXP(Freescale) Kinetis MKW41Z512][mkw41z512]
based on [FRDM-KW41Z][frdm-kw41z] hardware platform.
This directory contains example platform drivers for the [NXP(Freescale) Kinetis MKW41Z512][mkw41z512] based on [FRDM-KW41Z][frdm-kw41z] hardware platform.
[mkw41z512]: http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/kinetis-cortex-m-mcus/w-series-wireless-m0-plus-m4/kinetis-kw41z-2.4-ghz-dual-mode-ble-and-802.15.4-wireless-radio-microcontroller-mcu-based-on-arm-cortex-m0-plus-core:KW41Z
[frdm-kw41z]: http://www.nxp.com/products/software-and-tools/hardware-development-tools/freedom-development-boards/nxp-freedom-development-kit-for-kinetis-kw41z-31z-21z-mcus:FRDM-KW41Z
The example platform drivers are intended to present the minimal code
necessary to support OpenThread. As a result, the example platform
drivers do not necessarily highlight the platform's full capabilities.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. As a result, the example platform drivers do not necessarily highlight the platform's full capabilities.
## Toolchain
@ -16,8 +13,7 @@ Download and install the [GNU toolchain for ARM Cortex-M][gnu-toolchain].
[gnu-toolchain]: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -32,18 +28,15 @@ $ ./bootstrap
$ make -f examples/Makefile-kw41z
```
After a successful build, the `elf` files are found in
`<path-to-openthread>/output/kw41z/bin`. You can convert them to `bin`
files using `arm-none-eabi-objcopy`:
After a successful build, the `elf` files are found in `<path-to-openthread>/output/kw41z/bin`. You can convert them to `bin` files using `arm-none-eabi-objcopy`:
```bash
$ arm-none-eabi-objcopy -O binary ot-cli-ftd ot-cli-ftd.bin
```
## Flash Binaries
Compiled binaries may be flashed onto the MKW41Z512 using drag-and-drop into the board's MSD Bootloader
or the [NXP(Freescale) Test Tool][test-tool] or [JTAG interface][jtag].
The [NXP(Freescale) Test Tool][test-tool] provides a convenient method for flashing a MKW41Z512 via the [J-Link][jlink].
Compiled binaries may be flashed onto the MKW41Z512 using drag-and-drop into the board's MSD Bootloader or the [NXP(Freescale) Test Tool][test-tool] or [JTAG interface][jtag]. The [NXP(Freescale) Test Tool][test-tool] provides a convenient method for flashing a MKW41Z512 via the [J-Link][jlink].
[test-tool]: http://www.nxp.com/webapp/sps/download/license.jsp?colCode=TESTTOOL_SETUP
[jtag]: https://en.wikipedia.org/wiki/JTAG
@ -52,84 +45,84 @@ The [NXP(Freescale) Test Tool][test-tool] provides a convenient method for flash
## Running the example
1. Prepare two boards with the flashed `CLI Example` (as shown above).
2. The CLI example uses UART connection. To view raw UART output, start a terminal
emulator like PuTTY and connect to the used COM port with the following UART settings:
- Baud rate: 115200
- 8 data bits
- 1 stop bit
- No parity
- No flow control
2. The CLI example uses UART connection. To view raw UART output, start a terminal emulator like PuTTY and connect to the used COM port with the following UART settings:
- Baud rate: 115200
- 8 data bits
- 1 stop bit
- No parity
- No flow control
3. Open a terminal connection on the first board and start a new Thread network.
```bash
> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 13
Channel Mask: 07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d/64
Master Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrcb
Done
> dataset commit active
Done
> ifconfig up
Done
> thread start
Done
```
```bash
> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 13
Channel Mask: 07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d/64
Master Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrcb
Done
> dataset commit active
Done
> ifconfig up
Done
> thread start
Done
```
4. After a couple of seconds the node will become a Leader of the network.
```bash
> state
leader
```
```bash
> state
leader
```
5. Open a terminal connection on the second board and attach a node to the network.
```bash
> dataset masterkey dfd34f0f05cad978ec4e32b0413038ff
Done
> dataset commit active
Done
> ifconfig up
Done
> thread start
Done
```
```bash
> dataset masterkey dfd34f0f05cad978ec4e32b0413038ff
Done
> dataset commit active
Done
> ifconfig up
Done
> thread start
Done
```
6. After a couple of seconds the second node will attach and become a Child.
```bash
> state
child
```
```bash
> state
child
```
7. List all IPv6 addresses of the first board.
```bash
> ipaddr
fd3d:b50b:f96d:722d:0:ff:fe00:fc00
fd3d:b50b:f96d:722d:0:ff:fe00:c00
fd3d:b50b:f96d:722d:7a73:bff6:9093:9117
fe80:0:0:0:6c41:9001:f3d6:4148
Done
```
```bash
> ipaddr
fd3d:b50b:f96d:722d:0:ff:fe00:fc00
fd3d:b50b:f96d:722d:0:ff:fe00:c00
fd3d:b50b:f96d:722d:7a73:bff6:9093:9117
fe80:0:0:0:6c41:9001:f3d6:4148
Done
```
8. Choose one of them and send an ICMPv6 ping from the second board.
```bash
> ping fd3d:b50b:f96d:722d:7a73:bff6:9093:9117
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
```
```bash
> ping fd3d:b50b:f96d:722d:7a73:bff6:9093:9117
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
[cli]: https://github.com/openthread/openthread/blob/master/src/cli/README.md

76
examples/platforms/nrf528xx/DIAG.md
View File

@ -1,34 +1,33 @@
## Diagnostic module
nRF52811 and nRF52840 ports extend [OpenThread Diagnostics Module][DIAG].
nRF52811 and nRF52840 ports extend [OpenThread Diagnostics Module][diag].
New commands allow for more accurate low level radio testing.
### New commands
* [diag ccathreshold](#diag-ccathreshold)
* [diag gpio](#diag-gpio)
* [diag id](#diag-id)
* [diag listen](#diag-listen)
* [diag temp](#diag-temp)
* [diag transmit](#diag-transmit)
- [diag ccathreshold](#diag-ccathreshold)
- [diag gpio](#diag-gpio)
- [diag id](#diag-id)
- [diag listen](#diag-listen)
- [diag temp](#diag-temp)
- [diag transmit](#diag-transmit)
### Diagnostic radio packet
[diag listen](#diag-listen) and [diag transmit](#diag-transmit) use radio frame payload specified below.
```c
struct PlatformDiagMessage
{
const char mMessageDescriptor[11];
uint8_t mChannel;
int16_t mID;
uint32_t mCnt;
};
```
```c
struct PlatformDiagMessage
{
const char mMessageDescriptor[11];
uint8_t mChannel;
int16_t mID;
uint32_t mCnt;
};
```
`mMessageDescriptor` is a constant string `"DiagMessage"`.<br />
`mChannel` contains the channel number on which the packet was transmitted.<br />
`mID` contains the board ID set with the [diag id](#diag-id) command.<br />
`mCnt` is a counter incremented every time the board transmits diagnostic radio packet.
`mMessageDescriptor` is a constant string `"DiagMessage"`.<br /> `mChannel` contains the channel number on which the packet was transmitted.<br /> `mID` contains the board ID set with the [diag id](#diag-id) command.<br /> `mCnt` is a counter incremented every time the board transmits diagnostic radio packet.
If the [listen mode](#diag-listen) is enabled and OpenThread was built with the`DEFAULT_LOGGING` flag, JSON string is printed every time a diagnostic radio packet is received.
@ -44,9 +43,11 @@ If the [listen mode](#diag-listen) is enabled and OpenThread was built with the`
```
### diag ccathreshold
Get the current CCA threshold.
### diag ccathreshold \<threshold\>
Set the CCA threshold.
Value range: 0 to 255.
@ -54,16 +55,19 @@ Value range: 0 to 255.
Default: `45`.
### diag gpio
Manage GPIO pins.
### diag gpio \<pinnum\>
Return the current value of the gpio.
Note: \<pinnum\> is an integer that combines port and pin into a single,
contiguous number space as follows:
Note: \<pinnum\> is an integer that combines port and pin into a single, contiguous number space as follows:
```
pinnum = (port * 32) + pin
```
See also the [`NRF_GPIO_PIN_MAP`](../../../third_party/NordicSemiconductor/hal/nrf_gpio.h) macro.
```bash
@ -72,37 +76,47 @@ gpio 47 = 0
```
### diag gpio out \<pinnum\>
Set the given GPIO to the output mode.
```bash
> diag gpio out 47
gpio 47: out
```
### diag gpio in \<pinnum\>
Sets the given GPIO to the input mode with no pull variant.
```bash
> diag gpio in 47
gpio 47: in no pull
```
### diag gpio set \<pinnum\>
Sets the given output gpio to high.
```bash
> diag gpio set 47
gpio 47 = 1
```
### diag gpio clr \<pinnum\>
Sets the given output gpio to low.
```bash
> diag gpio clr 47
gpio 47 = 0
```
### diag id
Get board ID.
### diag id \<id\>
Set board ID.
Value range: 0 to 32767.
@ -110,23 +124,27 @@ Value range: 0 to 32767.
Default: `-1`.
### diag listen
Get the listen state.
### diag listen \<listen\>
Set the listen state.
`0` disables the listen state.<br />
`1` enables the listen state.
`0` disables the listen state.<br /> `1` enables the listen state.
By default, the listen state is disabled.
### diag temp
Get the temperature from the internal temperature sensor (in degrees Celsius).
### diag transmit
Get the message count and the interval between the messages that will be transmitted after `diag transmit start`.
### diag transmit interval \<interval\>
Set the interval in ms between the transmitted messages.
Value range: 1 to 4294967295.
@ -134,21 +152,23 @@ Value range: 1 to 4294967295.
Default: `1`.
### diag transmit count \<count\>
Set the number of messages to be transmitted.
Value range: 1 to 2147483647<br />
or<br />
For continuous transmission: `-1`
Value range: 1 to 2147483647<br /> or<br /> For continuous transmission: `-1`
Default: `1`
### diag transmit stop
Stop the ongoing transmission regardless of the remaining number of messages to be sent.
### diag transmit start
Start transmiting messages with specified interval.
### diag transmit carrier
Start transmitting continuous carrier wave.
[DIAG]: ./../../../src/core/diags/README.md
[diag]: ./../../../src/core/diags/README.md

17
examples/platforms/nrf528xx/README.md
View File

@ -1,16 +1,17 @@
# OpenThread on nRF528xx Example
This directory contains example platform drivers for [Nordic Semiconductor nRF52840 SoC][nRF52840], [Nordic Semiconductor nRF52833 SoC][nRF52833] and [Nordic Semiconductor nRF52811 SoC][nRF52811].
This directory contains example platform drivers for [Nordic Semiconductor nRF52840 SoC][nrf52840], [Nordic Semiconductor nRF52833 SoC][nrf52833] and [Nordic Semiconductor nRF52811 SoC][nrf52811].
[nRF52840]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52840
[nRF52833]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52833
[nRF52811]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52811
[nrf52840]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52840
[nrf52833]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52833
[nrf52811]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52811
To learn more about building and running the examples please check:
* [OpenThread on nRF52840 examples][nrf52840-page]
* [OpenThread on nRF52833 examples][nrf52833-page]
* [OpenThread on nRF52811 examples][nrf52811-page]
- [OpenThread on nRF52840 examples][nrf52840-page]
- [OpenThread on nRF52833 examples][nrf52833-page]
- [OpenThread on nRF52811 examples][nrf52811-page]
[nrf52840-page]: ./nrf52840/README.md
[nrf52833-page]: ./nrf52833/README.md
[nrf52811-page]: ./nrf52811/README.md
[nrf52811-page]: ./nrf52811/README.md

111
examples/platforms/nrf528xx/nrf52811/README.md
View File

@ -1,19 +1,16 @@
# OpenThread on nRF52811 Example
This directory contains example platform drivers for [Nordic Semiconductor nRF52811 SoC][nRF52811].
This directory contains example platform drivers for [Nordic Semiconductor nRF52811 SoC][nrf52811].
[nRF52811]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52811
[nrf52811]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52811
This SoC is meant to be used in the configuration that involves the Host Processor and the IEEE 802.15.4 radio.
In this configuration, the full OpenThread stack is running on the Host Processor and the nRF52811 SoC acts as an IEEE 802.15.4 radio.
The radio is running a minimal OpenThread implementation that allows for communication between the Host Processor and the nRF52811.
In this architecture the nRF52811 SoC device is called RCP (Radio Co-Processor).
This SoC is meant to be used in the configuration that involves the Host Processor and the IEEE 802.15.4 radio. In this configuration, the full OpenThread stack is running on the Host Processor and the nRF52811 SoC acts as an IEEE 802.15.4 radio. The radio is running a minimal OpenThread implementation that allows for communication between the Host Processor and the nRF52811. In this architecture the nRF52811 SoC device is called RCP (Radio Co-Processor).
The nRF52811 platform is currently under development.
For the SoC capable to a run full OpenThread stack, see the [nRF52840 platform][nRF52840-page].
For the SoC capable to a run full OpenThread stack, see the [nRF52840 platform][nrf52840-page].
[nRF52840-page]: ./../nrf52840/README.md
[nrf52840-page]: ./../nrf52840/README.md
## Emulation on nRF52840
@ -38,28 +35,28 @@ $ ./script/bootstrap
### Flashing and debugging tools
[nRF-Command-Line-Tools]: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Command-Line-Tools
[nrf-command-line-tools]: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Command-Line-Tools
Install the [nRF Command Line Tools][nRF-Command-Line-Tools] to flash, debug, and make use of logging features on the nRF52811 DK with SEGGER J-Link.
Install the [nRF Command Line Tools][nrf-command-line-tools] to flash, debug, and make use of logging features on the nRF52811 DK with SEGGER J-Link.
## Building the examples
With this platform, you can build:
- Limited version of CLI example (e.g. without Thread commissioning functionality)
- RCP example that consists of two parts:
- firmware that is flashed to the nRF52811 SoC
- host executables to be executed on a POSIX platform in case of the RCP usage
- Limited version of CLI example (e.g. without Thread commissioning functionality)
- RCP example that consists of two parts:
- firmware that is flashed to the nRF52811 SoC
- host executables to be executed on a POSIX platform in case of the RCP usage
### Building host executables
```bash
$ cd <path-to-openthread>
$ ./bootstrap
$ make -f src/posix/Makefile-posix
```
After a successful build, executables can be found in
`<path-to-openthread>/openthread/output/posix/<system-architecture>/bin`.
It is recommended to copy them to `/usr/bin` for easier access.
After a successful build, executables can be found in `<path-to-openthread>/openthread/output/posix/<system-architecture>/bin`. It is recommended to copy them to `/usr/bin` for easier access.
### Building the firmware with UART support
@ -71,9 +68,8 @@ $ ./bootstrap
$ make -f examples/Makefile-nrf52811
```
After a successful build, the `elf` files can be found in
`<path-to-openthread>/output/nrf52811/bin`.
You can convert them to hex using `arm-none-eabi-objcopy`:
After a successful build, the `elf` files can be found in `<path-to-openthread>/output/nrf52811/bin`. You can convert them to hex using `arm-none-eabi-objcopy`:
```bash
$ arm-none-eabi-objcopy -O ihex ot-cli-mtd ot-cli-mtd.hex
$ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex
@ -81,15 +77,14 @@ $ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex
### Building the firmware with native SPI support
You can build the libraries with support for the native SPI Slave.
To do so, build the libraries with the following parameter:
You can build the libraries with support for the native SPI Slave. To do so, build the libraries with the following parameter:
```
$ make -f examples/Makefile-nrf52811 NCP_SPI=1
```
With this option enabled, the RCP example can communicate through SPI with wpantund (provided that the wpantund host supports SPI Master). To achieve this communication, choose the right SPI device in the wpantund configuration file, `/etc/wpantund.conf`. See the following example.
```
Config:NCP:SocketPath "system:/usr/bin/ot-ncp /usr/bin/spi-hdlc-adapter -- '--stdio -i /sys/class/gpio/gpio25 /dev/spidev0.1'"
```
@ -105,8 +100,9 @@ The default SPI Slave pin configuration for nRF52811 is defined in `examples/pla
When the Thread device is configured to obtain the Thread Network security credentials with either Thread Commissioning or an out-of-band method, the extended MAC address should be constructed out of the globally unique IEEE EUI-64.
The IEEE EUI-64 address consists of two parts:
- 24 bits of MA-L (MAC Address Block Large), formerly called OUI (Organizationally Unique Identifier)
- 40-bit device unique identifier
- 24 bits of MA-L (MAC Address Block Large), formerly called OUI (Organizationally Unique Identifier)
- 40-bit device unique identifier
By default, the device uses Nordic Semiconductor's MA-L (f4-ce-36). You can modify it by overwriting the `OPENTHREAD_CONFIG_STACK_VENDOR_OUI` define, located in the `openthread-core-nrf52811-config.h` file. This value must be publicly registered by the IEEE Registration Authority.
@ -116,8 +112,7 @@ After the Thread Network security credentials have been successfully obtained, t
## Flashing binaries
Once the examples and libraries are built, flash the compiled binaries onto nRF52811
using `nrfjprog` that is part of the [nRF Command Line Tools][nRF-Command-Line-Tools].
Once the examples and libraries are built, flash the compiled binaries onto nRF52811 using `nrfjprog` that is part of the [nRF Command Line Tools][nrf-command-line-tools].
Run the following command:
@ -137,9 +132,7 @@ To test the example:
4. Connect the RCP to the PC.
5. Start the ot-cli host application and connect with the RCP.
It is assumed that the default UART version of RCP is being used (make executed without the NCP-SPI=1 flag).
On Linux system, call a port name, for example `/dev/ttyACM0` for the first connected development kit, and `/dev/ttyACM1` for the second one.
5. Start the ot-cli host application and connect with the RCP. It is assumed that the default UART version of RCP is being used (make executed without the NCP-SPI=1 flag). On Linux system, call a port name, for example `/dev/ttyACM0` for the first connected development kit, and `/dev/ttyACM1` for the second one.
```bash
$ /usr/bin/ot-cli /dev/ttyACM0 115200
@ -185,20 +178,19 @@ To test the example:
b. Connect to the used COM port with the following direct UART settings:
* Baud rate: 115200
* 8 data bits
* 1 stop bit
* No parity
* HW flow control: RTS/CTS
This allows you to view the raw UART output.
- Baud rate: 115200
- 8 data bits
- 1 stop bit
- No parity
- HW flow control: RTS/CTS This allows you to view the raw UART output.
c. Run the following command to connect to the second board.
```shell
screen /dev/ttyACM1 115200
```
```shell
screen /dev/ttyACM1 115200
```
You are now connected with the CLI on the second board
You are now connected with the CLI on the second board
8. Use the following commands to attach to the network on the second board:
@ -238,9 +230,9 @@ To test the example:
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: ./../../../src/cli/README.md
[cli]: ./../../../src/cli/README.md
## SEGGER J-Link tools
@ -248,12 +240,12 @@ SEGGER J-Link tools allow to debug and flash generated firmware using on-board d
### Working with RTT logging
By default, the OpenThread's logging module provides functions to output logging
information over SEGGER's Real Time Transfer (RTT).
By default, the OpenThread's logging module provides functions to output logging information over SEGGER's Real Time Transfer (RTT).
You can set the desired log level by using the `OPENTHREAD_CONFIG_LOG_LEVEL` define.
To enable the highest verbosity level, append `FULL_LOGS` flag to the `make` command:
```
$ make -f examples/Makefile-nrf52811 FULL_LOGS=1
```
@ -269,10 +261,13 @@ $ make -f examples/Makefile-nrf52811 FULL_LOGS=1
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52810_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID> -RTTTelnetPort 19021
```
3. Run `JLinkRTTTelnet` to obtain the RTT logs from the connected device in a separate console. For example:
```
JLinkRTTClient -RTTTelnetPort 19021
```
@ -288,22 +283,28 @@ Depending on your version, due to a known issue in SEGGER's J-Link firmware, you
3. From the Specify Target Device dropdown menu, select `NRF52810_XXAA`.
4. From the Target Interface & Speed dropdown menu, select `SWD`.
5. Run the following command:
```
MSDDisable
```
6. Power cycle the DK.
#### Disabling the Mass Storage Device on Linux
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52810_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID>
```
3. Run the following command:
```
MSDDisable
```
4. Power cycle the DK.
### Hardware Flow Control detection
@ -321,39 +322,45 @@ To avoid potential race conditions, you can force HWFC and bypass the runtime au
3. From the Specify Target Device dropdown menu, select `NRF52810_XXAA`.
4. From the Target Interface & Speed dropdown menu, select `SWD`.
5. Run the following command:
```
SetHWFC Force
```
6. Power cycle the DK.
#### Disabling the HWFC detection on Linux
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52810_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID>
```
3. Run the following command:
```
SetHWFC Force
```
4. Power cycle the DK.
You can find more details [here][J-Link-OB].
You can find more details [here][j-link-ob].
[J-Link-OB]: https://wiki.segger.com/J-Link_OB_SAM3U_NordicSemi#Hardware_flow_control_support
[j-link-ob]: https://wiki.segger.com/J-Link_OB_SAM3U_NordicSemi#Hardware_flow_control_support
## Diagnostic module
nRF52811 supports [OpenThread Diagnostics Module][DIAG], with some additional features.
nRF52811 supports [OpenThread Diagnostics Module][diag], with some additional features.
For more information, see [nRF Diag command reference][nRFDIAG].
For more information, see [nRF Diag command reference][nrfdiag].
[DIAG]: ./../../../src/core/diags/README.md
[nRFDIAG]: ./../DIAG.md
[diag]: ./../../../src/core/diags/README.md
[nrfdiag]: ./../DIAG.md
## Radio driver documentation
The radio driver documentation includes *.uml state machines sequence diagrams that can be opened with [PlantUML][PlantUML-url].
The radio driver documentation includes \*.uml state machines sequence diagrams that can be opened with [PlantUML][plantuml-url].
[PlantUML-url]: http://plantuml.com/
[plantuml-url]: http://plantuml.com/

143
examples/platforms/nrf528xx/nrf52833/README.md
View File

@ -1,11 +1,11 @@
# OpenThread on nRF52833 Example
This directory contains example platform drivers for [Nordic Semiconductor nRF52833 SoC][nRF52833].
This directory contains example platform drivers for [Nordic Semiconductor nRF52833 SoC][nrf52833].
To facilitate Thread products development with the nRF52833 platform, Nordic Semiconductor provides <i>nRF5 SDK for Thread and Zigbee</i>. See [Nordic Semiconductor's nRF5 SDK for Thread and Zigbee][nRF5-SDK-section] section for more details.
To facilitate Thread products development with the nRF52833 platform, Nordic Semiconductor provides <i>nRF5 SDK for Thread and Zigbee</i>. See [Nordic Semiconductor's nRF5 SDK for Thread and Zigbee][nrf5-sdk-section] section for more details.
[nRF52833]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52833
[nRF5-SDK-section]: #nordic-semiconductors-nrf5-sdk-for-thread-and-zigbee
[nrf52833]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52833
[nrf5-sdk-section]: #nordic-semiconductors-nrf5-sdk-for-thread-and-zigbee
## Prerequisites
@ -26,13 +26,13 @@ $ ./script/bootstrap
### Flashing and debugging tools
[nRF5-Command-Line-Tools]: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF5-Command-Line-Tools
[nrf5-command-line-tools]: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF5-Command-Line-Tools
Install the [nRF5 Command Line Tools][nRF5-Command-Line-Tools] to flash, debug, and make use of logging features on the nRF52833 DK with SEGGER J-Link.
Install the [nRF5 Command Line Tools][nrf5-command-line-tools] to flash, debug, and make use of logging features on the nRF52833 DK with SEGGER J-Link.
## Building the examples
To build the examples, run the following command in Bash:
To build the examples, run the following command in Bash:
```bash
$ cd <path-to-openthread>
@ -40,50 +40,48 @@ $ ./bootstrap
$ make -f examples/Makefile-nrf52833
```
After a successful build, the `elf` files can be found in
`<path-to-openthread>/output/nrf52833/bin`.
You can convert them to hex using `arm-none-eabi-objcopy`:
After a successful build, the `elf` files can be found in `<path-to-openthread>/output/nrf52833/bin`. You can convert them to hex using `arm-none-eabi-objcopy`:
```bash
$ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex
```
### USB CDC ACM support
You can build the libraries with support for the native USB CDC ACM as a serial transport.
To do so, build the firmware with the following parameter:
You can build the libraries with support for the native USB CDC ACM as a serial transport. To do so, build the firmware with the following parameter:
```
$ make -f examples/Makefile-nrf52833 USB=1
```
Note that the USB CDC ACM serial transport is not supported with Engineering sample A of the nRF52833 chip.
If you are using Windows 7 or earlier, you must load an additional USB CDC driver.
The driver can be found in `third_party/NordicSemiconductor/libraries/usb/nordic_cdc_acm_example.inf`.
If you are using Windows 7 or earlier, you must load an additional USB CDC driver. The driver can be found in `third_party/NordicSemiconductor/libraries/usb/nordic_cdc_acm_example.inf`.
### Bootloader support
The examples support the following bootloaders for performing a Device Firmware Upgrade (DFU):
* USB bootloader
* UART bootloader
* BLE bootloader
- USB bootloader
- UART bootloader
- BLE bootloader
The support for a particular bootloader can be enabled with the following switches:
* USB: `BOOTLOADER=USB`
* UART: `BOOTLOADER=UART`
* BLE: `BOOTLOADER=BLE`
- USB: `BOOTLOADER=USB`
- UART: `BOOTLOADER=UART`
- BLE: `BOOTLOADER=BLE`
### Native SPI support
You can build the libraries with support for native SPI Slave.
To build the libraries, run make with the following parameter:
You can build the libraries with support for native SPI Slave. To build the libraries, run make with the following parameter:
```
$ make -f examples/Makefile-nrf52833 NCP_SPI=1
```
With this option enabled, SPI communication between the NCP example and wpantund is possible
(provided that the wpantund host supports SPI Master). To achieve that, an appropriate SPI device
should be chosen in wpantund configuration file, `/etc/wpantund.conf`. You can find an example below.
With this option enabled, SPI communication between the NCP example and wpantund is possible (provided that the wpantund host supports SPI Master). To achieve that, an appropriate SPI device should be chosen in wpantund configuration file, `/etc/wpantund.conf`. You can find an example below.
```
Config:NCP:SocketPath "system:/usr/bin/spi-hdlc-adapter --gpio-int /sys/class/gpio/gpio25 /dev/spidev0.0"
```
@ -92,8 +90,7 @@ In this example, [spi-hdlc-adapter][spi-hdlc-adapter] is a tool that you can use
The default SPI Slave pin configuration for nRF52833 is defined in `examples/platforms/nrf52833/transport-config.h`.
Note that the native SPI Slave support is not intended to be used with Engineering sample A of the nRF52833 chip due to
single transfer size limitation.
Note that the native SPI Slave support is not intended to be used with Engineering sample A of the nRF52833 chip due to single transfer size limitation.
[spi-hdlc-adapter]: https://github.com/openthread/openthread/tree/master/tools/spi-hdlc-adapter
@ -106,7 +103,9 @@ You can prefix the compiler command using the CCPREFIX parameter. This speeds up
```
$ make -f examples/Makefile-nrf52833 USB=1 CCPREFIX=ccache
```
### Optional mbedTLS threading support
By default, mbedTLS library is built without support for multiple threads. You can enable this built-in support by building OpenThread with the following parameter:
```
@ -134,8 +133,9 @@ See [mbedTls Thread Safety and Multi Threading][mbedtls-thread-safety-and-multi-
When the Thread device is configured to obtain the Thread Network security credentials with either Thread Commissioning or an out-of-band method, the extended MAC address should be constructed out of the globally unique IEEE EUI-64.
The IEEE EUI-64 address consists of two parts:
- 24 bits of MA-L (MAC Address Block Large), formerly called OUI (Organizationally Unique Identifier)
- 40-bit device unique identifier
- 24 bits of MA-L (MAC Address Block Large), formerly called OUI (Organizationally Unique Identifier)
- 40-bit device unique identifier
By default, the device uses Nordic Semiconductor's MA-L (f4-ce-36). You can modify it by overwriting the `OPENTHREAD_CONFIG_STACK_VENDOR_OUI` define, located in the `openthread-core-nrf52833-config.h` file. This value must be publicly registered by the IEEE Registration Authority.
@ -145,8 +145,7 @@ After the Thread Network security credentials have been successfully obtained, t
## Flashing the binaries
Flash the compiled binaries onto nRF52833 using `nrfjprog` which is
part of the [nRF5 Command Line Tools][nRF5-Command-Line-Tools].
Flash the compiled binaries onto nRF52833 using `nrfjprog` which is part of the [nRF5 Command Line Tools][nrf5-command-line-tools].
```bash
$ nrfjprog -f nrf52 --chiperase --program output/nrf52833/bin/ot-cli-ftd.hex --reset
@ -164,12 +163,11 @@ To test the example:
b. Connect to the used COM port with the following direct UART settings:
* Baud rate: 115200
* 8 data bits
* 1 stop bit
* No parity
* HW flow control: RTS/CTS
This allows you to view the raw UART output.
- Baud rate: 115200
- 8 data bits
- 1 stop bit
- No parity
- HW flow control: RTS/CTS This allows you to view the raw UART output.
On Linux system a port name should be called e.g. `/dev/ttyACM0` or `/dev/ttyACM1`.
@ -251,9 +249,9 @@ To test the example:
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: ./../../../src/cli/README.md
[cli]: ./../../../src/cli/README.md
## SEGGER J-Link tools
@ -261,12 +259,12 @@ SEGGER J-Link tools allow to debug and flash generated firmware using on-board d
### Working with RTT logging
By default, the OpenThread's logging module provides functions to output logging
information over SEGGER's Real Time Transfer (RTT).
By default, the OpenThread's logging module provides functions to output logging information over SEGGER's Real Time Transfer (RTT).
You can set the desired log level by using the `OPENTHREAD_CONFIG_LOG_LEVEL` define.
To enable the highest verbosity level, append `FULL_LOGS` flag to the `make` command:
```
$ make -f examples/Makefile-nrf52833 FULL_LOGS=1
```
@ -282,10 +280,13 @@ $ make -f examples/Makefile-nrf52833 FULL_LOGS=1
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52833_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID> -RTTTelnetPort 19021
```
3. Run `JLinkRTTTelnet` to obtain the RTT logs from the connected device in a separate console. For example:
```
JLinkRTTClient -RTTTelnetPort 19021
```
@ -301,22 +302,28 @@ Depending on your version, due to a known issue in SEGGER's J-Link firmware, you
3. From the Specify Target Device dropdown menu, select `NRF52833_XXAA`.
4. From the Target Interface & Speed dropdown menu, select `SWD`.
5. Run the following command:
```
MSDDisable
```
6. Power cycle the DK.
#### Disabling the Mass Storage Device on Linux
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52833_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID>
```
3. Run the following command:
```
MSDDisable
```
4. Power cycle the DK.
### Hardware Flow Control detection
@ -334,61 +341,67 @@ To avoid potential race conditions, you can force HWFC and bypass the runtime au
3. From the Specify Target Device dropdown menu, select `NRF52833_XXAA`.
4. From the Target Interface & Speed dropdown menu, select `SWD`.
5. Run the following command:
```
SetHWFC Force
```
6. Power cycle the DK.
#### Disabling the HWFC detection on Linux
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52833_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID>
```
3. Run the following command:
```
SetHWFC Force
```
4. Power cycle the DK.
You can find more details [here][J-Link-OB].
You can find more details [here][j-link-ob].
[J-Link-OB]: https://wiki.segger.com/J-Link_OB_SAM3U_NordicSemi#Hardware_flow_control_support
[j-link-ob]: https://wiki.segger.com/J-Link_OB_SAM3U_NordicSemi#Hardware_flow_control_support
## Diagnostic module
nRF52833 port extends [OpenThread Diagnostics Module][DIAG].
nRF52833 port extends [OpenThread Diagnostics Module][diag].
You can read about all the features [here][nRFDIAG].
You can read about all the features [here][nrfdiag].
[DIAG]: ./../../../src/core/diags/README.md
[nRFDIAG]: ./../DIAG.md
[diag]: ./../../../src/core/diags/README.md
[nrfdiag]: ./../DIAG.md
## Radio driver documentation
The radio driver comes with documentation that describes the operation of state
machines in this module. To open the `*.uml` sequence diagrams, use [PlantUML][PlantUML-url].
The radio driver comes with documentation that describes the operation of state machines in this module. To open the `*.uml` sequence diagrams, use [PlantUML][plantuml-url].
[PlantUML-url]: http://plantuml.com/
[plantuml-url]: http://plantuml.com/
# Nordic Semiconductor's nRF5 SDK for Thread and Zigbee
Use [nRF5 Software Development Kit (SDK) for Thread and Zigbee][nRF5-SDK-Thread-Zigbee] when developing Thread products with Nordic Semiconductor's advanced nRF52840, nRF52833 or nRF52811 SoCs.
Use [nRF5 Software Development Kit (SDK) for Thread and Zigbee][nrf5-sdk-thread-zigbee] when developing Thread products with Nordic Semiconductor's advanced nRF52840, nRF52833 or nRF52811 SoCs.
The <i>nRF5 SDK for Thread and Zigbee</i> includes:
- a pre-built OpenThread stack for the Nordic nRF52840, nRF52833 and nRF52811 SoCs,
- support for hardware-accelerated cryptographic operations using ARM® CryptoCell-310,
- unique Thread/Bluetooth Low Energy dynamic multiprotocol solution which allows for concurrent operation of Thread and Bluetooth Low Energy utilizing OpenThread and SoftDevice (Nordic’s Bluetooth Low Energy stack) with accompanying example applications,
- Thread/Bluetooth Low Energy switched multiprotocol solution with accompanying example applications,
- unique support for DFU-over-Thread (Device Firmware Upgrade),
- examples to demonstrate interactions between nodes performing different Thread roles with the use of OpenThread and CoAP, CoAP Secure or MQTT-SN protocols,
- support for OpenThread Network Co-Processor (NCP) and Radio Co-Processor (RCP) using UART, USB or SPI transport protocol,
- Border Router and cloud connectivity example (e.g. with Google Cloud Platform),
- Thread native commissioning with NFC example,
- example applications demonstrating the use of FreeRTOS with OpenThread,
- support for IAR, Keil MDK-ARM and SEGGER Embedded Studio (SES) IDEs for OpenThread stack and all example applications,
- range of PC tools including Thread Topology Monitor and nRF Sniffer for 802.15.4,
- software modules inherited from the nRF5 SDK e.g. peripheral drivers, NFC libraries, Bluetooth Low Energy libraries etc.
[nRF5-SDK-Thread-Zigbee]: https://www.nordicsemi.com/Software-and-Tools/Software/nRF5-SDK-for-Thread-and-Zigbee
- a pre-built OpenThread stack for the Nordic nRF52840, nRF52833 and nRF52811 SoCs,
- support for hardware-accelerated cryptographic operations using ARM® CryptoCell-310,
- unique Thread/Bluetooth Low Energy dynamic multiprotocol solution which allows for concurrent operation of Thread and Bluetooth Low Energy utilizing OpenThread and SoftDevice (Nordic’s Bluetooth Low Energy stack) with accompanying example applications,
- Thread/Bluetooth Low Energy switched multiprotocol solution with accompanying example applications,
- unique support for DFU-over-Thread (Device Firmware Upgrade),
- examples to demonstrate interactions between nodes performing different Thread roles with the use of OpenThread and CoAP, CoAP Secure or MQTT-SN protocols,
- support for OpenThread Network Co-Processor (NCP) and Radio Co-Processor (RCP) using UART, USB or SPI transport protocol,
- Border Router and cloud connectivity example (e.g. with Google Cloud Platform),
- Thread native commissioning with NFC example,
- example applications demonstrating the use of FreeRTOS with OpenThread,
- support for IAR, Keil MDK-ARM and SEGGER Embedded Studio (SES) IDEs for OpenThread stack and all example applications,
- range of PC tools including Thread Topology Monitor and nRF Sniffer for 802.15.4,
- software modules inherited from the nRF5 SDK e.g. peripheral drivers, NFC libraries, Bluetooth Low Energy libraries etc.
[nrf5-sdk-thread-zigbee]: https://www.nordicsemi.com/Software-and-Tools/Software/nRF5-SDK-for-Thread-and-Zigbee

196
examples/platforms/nrf528xx/nrf52840/README.md
View File

@ -4,13 +4,13 @@
<img src="https://cdn.rawgit.com/openthread/openthread/ab4c4e1e/doc/images/certified.svg" alt="Thread Certified Component" width="150px" align="right">
</a>
This directory contains example platform drivers for [Nordic Semiconductor nRF52840 SoC][nRF52840]. The OpenThread stack has been officially certified as a *Thread Certified Component* on this platform.
This directory contains example platform drivers for [Nordic Semiconductor nRF52840 SoC][nrf52840]. The OpenThread stack has been officially certified as a _Thread Certified Component_ on this platform.
[nRF52840]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52840
[nrf52840]: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52840
To facilitate Thread products development with the nRF52840 platform, Nordic Semiconductor provides <i>nRF5 SDK for Thread and Zigbee</i>. See [Nordic Semiconductor's nRF5 SDK for Thread and Zigbee][nRF5-SDK-section] section for more details.
To facilitate Thread products development with the nRF52840 platform, Nordic Semiconductor provides <i>nRF5 SDK for Thread and Zigbee</i>. See [Nordic Semiconductor's nRF5 SDK for Thread and Zigbee][nrf5-sdk-section] section for more details.
[nRF5-SDK-section]: #nordic-semiconductors-nrf5-sdk-for-thread-and-zigbee
[nrf5-sdk-section]: #nordic-semiconductors-nrf5-sdk-for-thread-and-zigbee
## Prerequisites
@ -31,13 +31,13 @@ $ ./script/bootstrap
### Flashing and debugging tools
[nRF-Command-Line-Tools]: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Command-Line-Tools
[nrf-command-line-tools]: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Command-Line-Tools
Install the [nRF Command Line Tools][nRF-Command-Line-Tools] to flash, debug, and make use of logging features on the nRF52840 DK with SEGGER J-Link.
Install the [nRF Command Line Tools][nrf-command-line-tools] to flash, debug, and make use of logging features on the nRF52840 DK with SEGGER J-Link.
## Building the examples
To build the examples, run the following command in Bash:
To build the examples, run the following command in Bash:
```bash
$ cd <path-to-openthread>
@ -45,37 +45,37 @@ $ ./bootstrap
$ make -f examples/Makefile-nrf52840
```
After a successful build, the `elf` files can be found in
`<path-to-openthread>/output/nrf52840/bin`.
You can convert them to hex using `arm-none-eabi-objcopy`:
After a successful build, the `elf` files can be found in `<path-to-openthread>/output/nrf52840/bin`. You can convert them to hex using `arm-none-eabi-objcopy`:
```bash
$ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex
```
### USB CDC ACM support
You can build the libraries with support for the native USB CDC ACM as a serial transport.
To do so, build the firmware with the following parameter:
You can build the libraries with support for the native USB CDC ACM as a serial transport. To do so, build the firmware with the following parameter:
```
$ make -f examples/Makefile-nrf52840 USB=1
```
Note that the USB CDC ACM serial transport is not supported with Engineering sample A of the nRF52840 chip.
If you are using Windows 7 or earlier, you must load an additional USB CDC driver.
The driver can be found in `third_party/NordicSemiconductor/libraries/usb/nordic_cdc_acm_example.inf`.
If you are using Windows 7 or earlier, you must load an additional USB CDC driver. The driver can be found in `third_party/NordicSemiconductor/libraries/usb/nordic_cdc_acm_example.inf`.
### Bootloader support
The examples support the following bootloaders for performing a Device Firmware Upgrade (DFU):
* USB bootloader
* UART bootloader
* BLE bootloader
- USB bootloader
- UART bootloader
- BLE bootloader
The support for a particular bootloader can be enabled with the following switches:
* USB: `BOOTLOADER=USB`
* UART: `BOOTLOADER=UART`
* BLE: `BOOTLOADER=BLE`
- USB: `BOOTLOADER=USB`
- UART: `BOOTLOADER=UART`
- BLE: `BOOTLOADER=BLE`
### nRF52840 dongle support (PCA10059)
@ -93,16 +93,14 @@ See [nRF52840 Dongle Programming][nrf52840-dongle-programming] for more details
### Native SPI support
You can build the libraries with support for native SPI Slave.
To build the libraries, run make with the following parameter:
You can build the libraries with support for native SPI Slave. To build the libraries, run make with the following parameter:
```
$ make -f examples/Makefile-nrf52840 NCP_SPI=1
```
With this option enabled, SPI communication between the NCP example and wpantund is possible
(provided that the wpantund host supports SPI Master). To achieve that, an appropriate SPI device
should be chosen in wpantund configuration file, `/etc/wpantund.conf`. You can find an example below.
With this option enabled, SPI communication between the NCP example and wpantund is possible (provided that the wpantund host supports SPI Master). To achieve that, an appropriate SPI device should be chosen in wpantund configuration file, `/etc/wpantund.conf`. You can find an example below.
```
Config:NCP:SocketPath "system:/usr/bin/spi-hdlc-adapter --gpio-int /sys/class/gpio/gpio25 /dev/spidev0.0"
```
@ -111,8 +109,7 @@ In this example, [spi-hdlc-adapter][spi-hdlc-adapter] is a tool that you can use
The default SPI Slave pin configuration for nRF52840 is defined in `examples/platforms/nrf52840/transport-config.h`.
Note that the native SPI Slave support is not intended to be used with Engineering sample A of the nRF52840 chip due to
single transfer size limitation.
Note that the native SPI Slave support is not intended to be used with Engineering sample A of the nRF52840 chip due to single transfer size limitation.
[spi-hdlc-adapter]: https://github.com/openthread/openthread/tree/master/tools/spi-hdlc-adapter
@ -129,12 +126,14 @@ $ make -f examples/Makefile-nrf52840 USB=1 CCPREFIX=ccache
### CryptoCell 310 support
By default, OpenThread uses mbedTLS library with support for CryptoCell 310 hardware acceleration of cryptographic operations. When building the application, an explicit setup is needed (error checking omitted):
```
mbedtls_platform_set_calloc_free(calloc, free);
mbedtls_platform_setup(NULL);
```
When building an external application with OpenThread libraries and CryptoCell 310 hardware acceleration, use the following configuration:
- Crypto libraries:
- `third_party/NordicSemiconductor/libraries/nrf_security/lib/libmbedcrypto_glue.a`
- `third_party/NordicSemiconductor/libraries/nrf_security/lib/libmbedcrypto_glue_cc310.a`
@ -151,16 +150,19 @@ When building an external application with OpenThread libraries and CryptoCell 3
- `third_party/NordicSemiconductor/libraries/nrf_security/config`
- `third_party/NordicSemiconductor/libraries/nrf_security/nrf_cc310_platform/include`
- Defines:
- `MBEDTLS_CONFIG_FILE` set to `"nrf-config.h"`
- `MBEDTLS_CONFIG_FILE` set to `"nrf-config.h"`
- `MBEDTLS_USER_CONFIG_FILE` set to `"nrf52840-mbedtls-config.h"`
### Optional disabling of CryptoCell 310 support
By default, OpenThread uses mbedTLS library with support for CryptoCell 310 hardware acceleration of cryptographic operations. You can disable CryptoCell 310 and use software cryptography instead by building OpenThread with the following parameter:
```
$ make -f examples/Makefile-nrf52840 DISABLE_BUILTIN_MBEDTLS=0 ...
```
When building an external application with OpenThread libraries and software cryptography, use the following configuration:
- Crypto libraries:
- `output/nrf52840/lib/libmbedcrypto.a` (present after successful build)
- Include directories:
@ -168,12 +170,13 @@ When building an external application with OpenThread libraries and software cry
- `third_party/mbedtls`
- `third_party/mbedtls/repo/include`
- Defines:
- `MBEDTLS_CONFIG_FILE` set to `"mbedtls-config.h"`
- `MBEDTLS_CONFIG_FILE` set to `"mbedtls-config.h"`
- `MBEDTLS_USER_CONFIG_FILE` set to `"nrf52840-mbedtls-config.h"`
### CryptoCell 310 abort mechanism
The CryptoCell 310 platform implements an abort mechanism. By default, any fault in the CryptoCell 310 library results in the system reset. This behavior can be changed by a call to the `nrf_cc310_platform_set_abort()` function. This function must be called before `mbedtls_platform_setup`:
```
void nrf_cc310_platform_set_abort(
nrf_cc310_platform_abort_apis_t const * const apis)
@ -182,6 +185,7 @@ void nrf_cc310_platform_set_abort(
### CryptoCell 310 RTOS support
The hardware-accelerated mbedTLS library supports access from multiple threads. By default, simple blocking implementation of mutexes is used. The locking mechanism can be replaced by using the `nrf_cc310_platform_set_mutexes()` function. This function must be called before `mbedtls_platform_setup`:
```
void nrf_cc310_platform_set_mutexes(nrf_cc310_platform_mutex_apis_t const * const apis,
nrf_cc310_platform_mutexes_t const * const mutexes)
@ -192,6 +196,7 @@ The sample implementation of mutexes for FreeRTOS and Zephyr operating systems c
The sample implementation of the abort functionality for FreeRTOS and Zephyr operating systems can be found in `nrf_cc310_platform_abort_freertos.c` and `nrf_cc310_platform_abort_zephyr.c`. Both files implement the function `void nrf_cc310_platform_abort_init(void)`. This function must be called before `mbedtls_platform_setup`.
The typical setup in the RTOS environment (error checking omitted) is as follows:
```
mbedtls_platform_set_calloc_free(calloc, free);
nrf_cc310_platform_abort_init();
@ -200,6 +205,7 @@ mbedtls_platform_setup(NULL);
```
When building an external application that uses RTOS with OpenThread libraries and the CryptoCell 310 hardware acceleration, use the following configuration:
- Crypto libraries:
- `third_party/NordicSemiconductor/libraries/nrf_security/lib/libmbedcrypto_glue.a`
- `third_party/NordicSemiconductor/libraries/nrf_security/lib/libmbedcrypto_glue_cc310.a`
@ -216,7 +222,7 @@ When building an external application that uses RTOS with OpenThread libraries a
- `third_party/NordicSemiconductor/libraries/nrf_security/config`
- `third_party/NordicSemiconductor/libraries/nrf_security/nrf_cc310_platform/include`
- Defines:
- `MBEDTLS_CONFIG_FILE` set to `"nrf-config.h"`
- `MBEDTLS_CONFIG_FILE` set to `"nrf-config.h"`
- `MBEDTLS_USER_CONFIG_FILE` set to `"nrf52840-mbedtls-config.h"`
- Sources:
- `nrf_cc310_platform_mutex_freertos.c` or `nrf_cc310_platform_mutex_zephyr.c` from `third_party/NordicSemiconductor/libraries/nrf_security/nrf_cc310_platform/src`, depending on the RTOS used.
@ -245,6 +251,7 @@ $ make -f examples/Makefile-nrf52840 MBEDTLS_THREADING=1 MBEDTLS_THREADING_MUTEX
```
When building an external application that uses RTOS with OpenThread libraries and software cryptography, use the following configuration:
- Crypto libraries:
- `output/nrf52840/lib/libmbedcrypto.a` (present after successful build)
- Include directories:
@ -253,7 +260,7 @@ When building an external application that uses RTOS with OpenThread libraries a
- `third_party/mbedtls/repo/include`
- `third_party/NordicSemiconductor/libraries/nrf_security/include/software-only-threading`
- Defines:
- `MBEDTLS_CONFIG_FILE` set to `"mbedtls-config.h"`
- `MBEDTLS_CONFIG_FILE` set to `"mbedtls-config.h"`
- `MBEDTLS_USER_CONFIG_FILE` set to `"nrf52840-mbedtls-config.h"`
- `MBEDTLS_THREADING_C`
- `MBEDTLS_THREADING_ALT`
@ -267,8 +274,9 @@ See [mbedTls Thread Safety and Multi Threading][mbedtls-thread-safety-and-multi-
When the Thread device is configured to obtain the Thread Network security credentials with either Thread Commissioning or an out-of-band method, the extended MAC address should be constructed out of the globally unique IEEE EUI-64.
The IEEE EUI-64 address consists of two parts:
- 24 bits of MA-L (MAC Address Block Large), formerly called OUI (Organizationally Unique Identifier)
- 40-bit device unique identifier
- 24 bits of MA-L (MAC Address Block Large), formerly called OUI (Organizationally Unique Identifier)
- 40-bit device unique identifier
By default, the device uses Nordic Semiconductor's MA-L (f4-ce-36). You can modify it by overwriting the `OPENTHREAD_CONFIG_STACK_VENDOR_OUI` define, located in the `openthread-core-nrf52840-config.h` file. This value must be publicly registered by the IEEE Registration Authority.
@ -278,8 +286,7 @@ After the Thread Network security credentials have been successfully obtained, t
## Flashing the binaries
Flash the compiled binaries onto nRF52840 using `nrfjprog` which is
part of the [nRF Command Line Tools][nRF-Command-Line-Tools].
Flash the compiled binaries onto nRF52840 using `nrfjprog` which is part of the [nRF Command Line Tools][nrf-command-line-tools].
```bash
$ nrfjprog -f nrf52 --chiperase --program output/nrf52840/bin/ot-cli-ftd.hex --reset
@ -297,12 +304,11 @@ To test the example:
b. Connect to the used COM port with the following direct UART settings:
* Baud rate: 115200
* 8 data bits
* 1 stop bit
* No parity
* HW flow control: RTS/CTS
This allows you to view the raw UART output.
- Baud rate: 115200
- 8 data bits
- 1 stop bit
- No parity
- HW flow control: RTS/CTS This allows you to view the raw UART output.
On Linux system a port name should be called e.g. `/dev/ttyACM0` or `/dev/ttyACM1`.
@ -384,9 +390,9 @@ To test the example:
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: ./../../../src/cli/README.md
[cli]: ./../../../src/cli/README.md
## SEGGER J-Link tools
@ -394,12 +400,12 @@ SEGGER J-Link tools allow to debug and flash generated firmware using on-board d
### Working with RTT logging
By default, the OpenThread's logging module provides functions to output logging
information over SEGGER's Real Time Transfer (RTT).
By default, the OpenThread's logging module provides functions to output logging information over SEGGER's Real Time Transfer (RTT).
You can set the desired log level by using the `OPENTHREAD_CONFIG_LOG_LEVEL` define.
To enable the highest verbosity level, append `FULL_LOGS` flag to the `make` command:
```
$ make -f examples/Makefile-nrf52840 FULL_LOGS=1
```
@ -415,10 +421,13 @@ $ make -f examples/Makefile-nrf52840 FULL_LOGS=1
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52840_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID> -RTTTelnetPort 19021
```
3. Run `JLinkRTTTelnet` to obtain the RTT logs from the connected device in a separate console. For example:
```
JLinkRTTClient -RTTTelnetPort 19021
```
@ -434,22 +443,28 @@ Depending on your version, due to a known issue in SEGGER's J-Link firmware, you
3. From the Specify Target Device dropdown menu, select `NRF52840_XXAA`.
4. From the Target Interface & Speed dropdown menu, select `SWD`.
5. Run the following command:
```
MSDDisable
```
6. Power cycle the DK.
#### Disabling the Mass Storage Device on Linux
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52840_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID>
```
3. Run the following command:
```
MSDDisable
```
4. Power cycle the DK.
### Hardware Flow Control detection
@ -467,85 +482,94 @@ To avoid potential race conditions, you can force HWFC and bypass the runtime au
3. From the Specify Target Device dropdown menu, select `NRF52840_XXAA`.
4. From the Target Interface & Speed dropdown menu, select `SWD`.
5. Run the following command:
```
SetHWFC Force
```
6. Power cycle the DK.
#### Disabling the HWFC detection on Linux
1. Connect the DK to your machine with a USB cable.
2. Run `JLinkExe` to connect to the target. For example:
```
JLinkExe -device NRF52840_XXAA -if SWD -speed 4000 -autoconnect 1 -SelectEmuBySN <SEGGER_ID>
```
3. Run the following command:
```
SetHWFC Force
```
4. Power cycle the DK.
You can find more details [here][J-Link-OB].
You can find more details [here][j-link-ob].
[J-Link-OB]: https://wiki.segger.com/J-Link_OB_SAM3U_NordicSemi#Hardware_flow_control_support
[j-link-ob]: https://wiki.segger.com/J-Link_OB_SAM3U_NordicSemi#Hardware_flow_control_support
## Diagnostic module
nRF52840 port extends [OpenThread Diagnostics Module][DIAG].
nRF52840 port extends [OpenThread Diagnostics Module][diag].
You can read about all the features [here][nRFDIAG].
You can read about all the features [here][nrfdiag].
[DIAG]: ./../../../src/core/diags/README.md
[nRFDIAG]: ./../DIAG.md
[diag]: ./../../../src/core/diags/README.md
[nrfdiag]: ./../DIAG.md
## Radio driver documentation
The radio driver comes with documentation that describes the operation of state
machines in this module. To open the `*.uml` sequence diagrams, use [PlantUML][PlantUML-url].
The radio driver comes with documentation that describes the operation of state machines in this module. To open the `*.uml` sequence diagrams, use [PlantUML][plantuml-url].
[PlantUML-url]: http://plantuml.com/
[plantuml-url]: http://plantuml.com/
## Verification
The following development kits have been used for testing and verification:
- PCA10056 1.0.0
- PCA10059 1.0.0
- PCA10068 0.5.0
- PCA10056 1.0.0
- PCA10059 1.0.0
- PCA10068 0.5.0
The following toolchains have been used for testing and verification:
- GCC: GCC ARM Embedded 7.2018 q2 update
- IAR: IAR Workbench 7.80.4
- SES: SES 4.12
- ARM: MDK-ARM version 5.25
The following OpenThread commits have been verified with nRF52840 and nRF52811 examples by Nordic Semiconductor:
- `2279ef6` - 23.05.2019 (the latest checked)
- `23ff101` - 22.03.2019
- `704511c` - 18.09.2018
- `ec59d7e` - 06.04.2018
- `a89eb88` - 16.11.2017
- `6a15261` - 29.06.2017
- `030efba` - 22.04.2017
- `de48acf` - 02.03.2017
- `50db58d` - 23.01.2017
- GCC: GCC ARM Embedded 7.2018 q2 update
- IAR: IAR Workbench 7.80.4
- SES: SES 4.12
- ARM: MDK-ARM version 5.25
The following OpenThread commits have been verified with nRF52840 and nRF52811 examples by Nordic Semiconductor:
- `2279ef6` - 23.05.2019 (the latest checked)
- `23ff101` - 22.03.2019
- `704511c` - 18.09.2018
- `ec59d7e` - 06.04.2018
- `a89eb88` - 16.11.2017
- `6a15261` - 29.06.2017
- `030efba` - 22.04.2017
- `de48acf` - 02.03.2017
- `50db58d` - 23.01.2017
# Nordic Semiconductor's nRF5 SDK for Thread and Zigbee
Use [nRF5 Software Development Kit (SDK) for Thread and Zigbee][nRF5-SDK-Thread-Zigbee] when developing Thread products with Nordic Semiconductor's advanced nRF52840, nRF52833 or nRF52811 SoCs.
Use [nRF5 Software Development Kit (SDK) for Thread and Zigbee][nrf5-sdk-thread-zigbee] when developing Thread products with Nordic Semiconductor's advanced nRF52840, nRF52833 or nRF52811 SoCs.
The <i>nRF5 SDK for Thread and Zigbee</i> includes:
- a pre-built OpenThread stack for the Nordic nRF52840 and nRF52811 SoCs,
- support for hardware-accelerated cryptographic operations using ARM® CryptoCell-310,
- unique Thread/Bluetooth Low Energy dynamic multiprotocol solution which allows for concurrent operation of Thread and Bluetooth Low Energy utilizing OpenThread and SoftDevice (Nordic’s Bluetooth Low Energy stack) with accompanying example applications,
- Thread/Bluetooth Low Energy switched multiprotocol solution with accompanying example applications,
- unique support for DFU-over-Thread (Device Firmware Upgrade),
- examples to demonstrate interactions between nodes performing different Thread roles with the use of OpenThread and CoAP, CoAP Secure or MQTT-SN protocols,
- support for OpenThread Network Co-Processor (NCP) and Radio Co-Processor (RCP) using UART, USB or SPI transport protocol,
- Border Router and cloud connectivity example (e.g. with Google Cloud Platform),
- Thread native commissioning with NFC example,
- example applications demonstrating the use of FreeRTOS with OpenThread,
- support for IAR, Keil MDK-ARM and SEGGER Embedded Studio (SES) IDEs for OpenThread stack and all example applications,
- range of PC tools including Thread Topology Monitor and nRF Sniffer for 802.15.4,
- software modules inherited from the nRF5 SDK e.g. peripheral drivers, NFC libraries, Bluetooth Low Energy libraries etc.
[nRF5-SDK-Thread-Zigbee]: https://www.nordicsemi.com/Software-and-Tools/Software/nRF5-SDK-for-Thread-and-Zigbee
- a pre-built OpenThread stack for the Nordic nRF52840 and nRF52811 SoCs,
- support for hardware-accelerated cryptographic operations using ARM® CryptoCell-310,
- unique Thread/Bluetooth Low Energy dynamic multiprotocol solution which allows for concurrent operation of Thread and Bluetooth Low Energy utilizing OpenThread and SoftDevice (Nordic’s Bluetooth Low Energy stack) with accompanying example applications,
- Thread/Bluetooth Low Energy switched multiprotocol solution with accompanying example applications,
- unique support for DFU-over-Thread (Device Firmware Upgrade),
- examples to demonstrate interactions between nodes performing different Thread roles with the use of OpenThread and CoAP, CoAP Secure or MQTT-SN protocols,
- support for OpenThread Network Co-Processor (NCP) and Radio Co-Processor (RCP) using UART, USB or SPI transport protocol,
- Border Router and cloud connectivity example (e.g. with Google Cloud Platform),
- Thread native commissioning with NFC example,
- example applications demonstrating the use of FreeRTOS with OpenThread,
- support for IAR, Keil MDK-ARM and SEGGER Embedded Studio (SES) IDEs for OpenThread stack and all example applications,
- range of PC tools including Thread Topology Monitor and nRF Sniffer for 802.15.4,
- software modules inherited from the nRF5 SDK e.g. peripheral drivers, NFC libraries, Bluetooth Low Energy libraries etc.
[nrf5-sdk-thread-zigbee]: https://www.nordicsemi.com/Software-and-Tools/Software/nRF5-SDK-for-Thread-and-Zigbee

64
examples/platforms/samr21/README.md
View File

@ -1,14 +1,11 @@
# OpenThread on SAMR21 Example
This directory contains example platform drivers for the [Microchip ATSAMR21G18A][samr21]
based on [SAM R21 Xplained Pro Evaluation Kit][SAMR21_XPLAINED_PRO].
This directory contains example platform drivers for the [Microchip ATSAMR21G18A][samr21] based on [SAM R21 Xplained Pro Evaluation Kit][samr21_xplained_pro].
[samr21]: http://www.microchip.com/wwwproducts/en/ATSAMR21G18A
[SAMR21_XPLAINED_PRO]: https://www.microchip.com/DevelopmentTools/ProductDetails/ATSAMR21-XPRO
[samr21_xplained_pro]: https://www.microchip.com/DevelopmentTools/ProductDetails/ATSAMR21-XPRO
The example platform drivers are intended to present the minimal code
necessary to support OpenThread. See the "Run the example with SAMR21 boards" section below
for an example using basic OpenThread capabilities.
The example platform drivers are intended to present the minimal code necessary to support OpenThread. See the "Run the example with SAMR21 boards" section below for an example using basic OpenThread capabilities.
## Toolchain
@ -16,8 +13,7 @@ Download and install the [GNU toolchain for ARM Cortex-M][gnu-toolchain].
[gnu-toolchain]: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm
In a Bash terminal, follow these instructions to install the GNU toolchain and
other dependencies.
In a Bash terminal, follow these instructions to install the GNU toolchain and other dependencies.
```bash
$ cd <path-to-openthread>
@ -26,14 +22,14 @@ $ ./script/bootstrap
## Build Examples
1. Download [Advanced Software Framework (ASF)][ASF].
1. Download [Advanced Software Framework (ASF)][asf].
[ASF]: https://www.microchip.com/mplab/avr-support/advanced-software-framework
[asf]: https://www.microchip.com/mplab/avr-support/advanced-software-framework
2. Unzip it to <path-to-openthread>/third_party/microchip folder
```bash
$ unzip asf-standalone-archive-3.45.0.85.zip
$ unzip asf-standalone-archive-3.45.0.85.zip
$ cp xdk-asf-3.45.0 -rf <path-to-openthread>/third_party/microchip/asf
```
@ -46,34 +42,32 @@ $ make -f examples/Makefile-samr21
```
4. This example can be built for other SAMR21 based modules e.g.:
* [ATSAMR21G18-MR210UA][MODULE-MR210UA]
* [ATSAMR21B18-MZ210PA][MODULE-MZ210PA]
- [ATSAMR21G18-MR210UA][module-mr210ua]
- [ATSAMR21B18-MZ210PA][module-mz210pa]
To build for these modules set BOARD variable in command line as following:
```bash
$ make -f examples/Makefile-samr21 BOARD=<MODULE>
```
where:
| `<module>` | Board |
| ----------------------|-------------------------------------|
| --------------------- | ----------------------------------- |
| `SAMR21_XPLAINED_PRO` | SAM R21 Xplained Pro Evaluation Kit |
| `SAMR21G18_MODULE` | ATSAMR21G18-MR210UA |
| `SAMR21B18_MODULE` | ATSAMR21B18-MZ210PA |
[MODULE-MR210UA]: http://ww1.microchip.com/downloads/en/devicedoc/atmel-42475-atsamr21g18-mr210ua_datasheet.pdf
[MODULE-MZ210PA]: http://ww1.microchip.com/downloads/en/devicedoc/atmel-42486-atsamr21b18-mz210pa_datasheet.pdf
[module-mr210ua]: http://ww1.microchip.com/downloads/en/devicedoc/atmel-42475-atsamr21g18-mr210ua_datasheet.pdf
[module-mz210pa]: http://ww1.microchip.com/downloads/en/devicedoc/atmel-42486-atsamr21b18-mz210pa_datasheet.pdf
After a successful build, the `elf` files are found in
`<path-to-openthread>/output/samr21/bin`.
After a successful build, the `elf` files are found in `<path-to-openthread>/output/samr21/bin`.
## Flash Binaries
Compiled binaries may be flashed onto the SAM R21 Xplained Pro using embedded
debugger EDBG.
Compiled binaries may be flashed onto the SAM R21 Xplained Pro using embedded debugger EDBG.
```bash
$ openocd -f board/atmel_samr21_xplained_pro.cfg
@ -86,9 +80,9 @@ $ (gdb) c
```
## Run the example with SAM R21 Xplained Pro boards
1. Flash two SAM R21 Xplained Pro boards with the `CLI example` firmware (as shown above).
2. Open terminal to first device `/dev/ttyACM0` (serial port settings: 115200 8-N-1).
Type `help` for a list of commands.
2. Open terminal to first device `/dev/ttyACM0` (serial port settings: 115200 8-N-1). Type `help` for a list of commands.
```bash
> help
@ -147,13 +141,13 @@ $ (gdb) c
wait a couple of seconds...
> state
leader
Done
> state leader Done
```
4. Open terminal to second device `/dev/ttyACM1` (serial port settings: 115200 8-N-1)
and attach it to the Thread network as a Router.
```
4. Open terminal to second device `/dev/ttyACM1` (serial port settings: 115200 8-N-1) and attach it to the Thread network as a Router.
```bash
> dataset masterkey dfd34f0f05cad978ec4e32b0413038ff
@ -192,8 +186,7 @@ $ (gdb) c
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
```
The above example demonstrates basic OpenThread capabilities. Enable more features/roles (e.g. commissioner,
joiner, DHCPv6 Server/Client, etc.) by assigning compile-options before compiling.
The above example demonstrates basic OpenThread capabilities. Enable more features/roles (e.g. commissioner, joiner, DHCPv6 Server/Client, etc.) by assigning compile-options before compiling.
```bash
$ cd <path-to-openthread>
@ -201,14 +194,15 @@ $ ./bootstrap
$ make -f examples/Makefile-samr21 COMMISSIONER=1 JOINER=1 DHCP6_CLIENT=1 DHCP6_SERVER=1
```
For a list of all available commands, visit [OpenThread CLI Reference README.md][CLI].
For a list of all available commands, visit [OpenThread CLI Reference README.md][cli].
[CLI]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
[cli]: https://github.com/openthread/openthread/blob/master/src/cli/README.md
## Other boards
## Verification
The following toolchain has been used for testing and verification:
- gcc version 7.3.1
- Advanced Software Framework (ASF) version 3.45.0
- gcc version 7.3.1
- Advanced Software Framework (ASF) version 3.45.0

317
src/cli/README.md
View File

@ -1,19 +1,12 @@
# OpenThread CLI Reference
The OpenThread CLI exposes configuration and management APIs via a
command line interface. Use the CLI to play with OpenThread, which
can also be used with additional application code. The
OpenThread test scripts use the CLI to execute test cases.
The OpenThread CLI exposes configuration and management APIs via a command line interface. Use the CLI to play with OpenThread, which can also be used with additional application code. The OpenThread test scripts use the CLI to execute test cases.
## Separator and escaping characters
The whitespace character (`' '`) is used to delimit the command name
and the different arguments, together with tab (`'\t'`) and new line
characters (`'\r'`, `'\n'`).
The whitespace character (`' '`) is used to delimit the command name and the different arguments, together with tab (`'\t'`) and new line characters (`'\r'`, `'\n'`).
Some arguments might require to accept whitespaces on them. For those
cases the backslash character (`'\'`) can be used to escape separators
or the backslash itself.
Some arguments might require to accept whitespaces on them. For those cases the backslash character (`'\'`) can be used to escape separators or the backslash itself.
Example:
@ -28,77 +21,77 @@ Done
## OpenThread Command List
* [bbr](#bbr)
* [bufferinfo](#bufferinfo)
* [channel](#channel)
* [child](#child-list)
* [childip](#childip)
* [childmax](#childmax)
* [childtimeout](#childtimeout)
* [coap](README_COAP.md)
* [coaps](README_COAPS.md)
* [commissioner](README_COMMISSIONER.md)
* [contextreusedelay](#contextreusedelay)
* [counters](#counters)
* [dataset](README_DATASET.md)
* [delaytimermin](#delaytimermin)
* [diag](#diag)
* [discover](#discover-channel)
* [dns](#dns-resolve-hostname-dns-server-ip-dns-server-port)
* [domainname](#domainname)
* [eidcache](#eidcache)
* [eui64](#eui64)
* [extaddr](#extaddr)
* [extpanid](#extpanid)
* [factoryreset](#factoryreset)
* [ifconfig](#ifconfig)
* [ipaddr](#ipaddr)
* [ipmaddr](#ipmaddr)
* [joiner](README_JOINER.md)
* [joinerport](#joinerport-port)
* [keysequence](#keysequence-counter)
* [leaderdata](#leaderdata)
* [leaderpartitionid](#leaderpartitionid)
* [leaderweight](#leaderweight)
* [linkquality](#linkquality-extaddr)
* [log](#log-filename-filename)
* [mac](#mac-retries-direct)
* [macfilter](#macfilter)
* [masterkey](#masterkey)
* [mode](#mode)
* [neighbor](#neighbor-list)
* [netdataregister](#netdataregister)
* [netdatashow](#netdatashow)
* [networkdiagnostic](#networkdiagnostic-get-addr-type-)
* [networkidtimeout](#networkidtimeout)
* [networkname](#networkname)
* [networktime](#networktime)
* [panid](#panid)
* [parent](#parent)
* [parentpriority](#parentpriority)
* [ping](#ping-ipaddr-size-count-interval-hoplimit)
* [pollperiod](#pollperiod-pollperiod)
* [preferrouterid](#preferrouterid-routerid)
* [prefix](#prefix-add-prefix-padcrosnD-prf)
* [promiscuous](#promiscuous)
* [pskc](#pskc--p-keypassphrase)
* [releaserouterid](#releaserouterid-routerid)
* [reset](#reset)
* [rloc16](#rloc16)
* [route](#route-add-prefix-s-prf)
* [router](#router-list)
* [routerdowngradethreshold](#routerdowngradethreshold)
* [routereligible](#routereligible)
* [routerselectionjitter](#routerselectionjitter)
* [routerupgradethreshold](#routerupgradethreshold)
* [scan](#scan-channel)
* [service](#service)
* [singleton](#singleton)
* [sntp](#sntp-query-sntp-server-ip-sntp-server-port)
* [state](#state)
* [thread](#thread-start)
* [txpower](#txpower)
* [version](#version)
- [bbr](#bbr)
- [bufferinfo](#bufferinfo)
- [channel](#channel)
- [child](#child-list)
- [childip](#childip)
- [childmax](#childmax)
- [childtimeout](#childtimeout)
- [coap](README_COAP.md)
- [coaps](README_COAPS.md)
- [commissioner](README_COMMISSIONER.md)
- [contextreusedelay](#contextreusedelay)
- [counters](#counters)
- [dataset](README_DATASET.md)
- [delaytimermin](#delaytimermin)
- [diag](#diag)
- [discover](#discover-channel)
- [dns](#dns-resolve-hostname-dns-server-ip-dns-server-port)
- [domainname](#domainname)
- [eidcache](#eidcache)
- [eui64](#eui64)
- [extaddr](#extaddr)
- [extpanid](#extpanid)
- [factoryreset](#factoryreset)
- [ifconfig](#ifconfig)
- [ipaddr](#ipaddr)
- [ipmaddr](#ipmaddr)
- [joiner](README_JOINER.md)
- [joinerport](#joinerport-port)
- [keysequence](#keysequence-counter)
- [leaderdata](#leaderdata)
- [leaderpartitionid](#leaderpartitionid)
- [leaderweight](#leaderweight)
- [linkquality](#linkquality-extaddr)
- [log](#log-filename-filename)
- [mac](#mac-retries-direct)
- [macfilter](#macfilter)
- [masterkey](#masterkey)
- [mode](#mode)
- [neighbor](#neighbor-list)
- [netdataregister](#netdataregister)
- [netdatashow](#netdatashow)
- [networkdiagnostic](#networkdiagnostic-get-addr-type-)
- [networkidtimeout](#networkidtimeout)
- [networkname](#networkname)
- [networktime](#networktime)
- [panid](#panid)
- [parent](#parent)
- [parentpriority](#parentpriority)
- [ping](#ping-ipaddr-size-count-interval-hoplimit)
- [pollperiod](#pollperiod-pollperiod)
- [preferrouterid](#preferrouterid-routerid)
- [prefix](#prefix-add-prefix-padcrosnD-prf)
- [promiscuous](#promiscuous)
- [pskc](#pskc--p-keypassphrase)
- [releaserouterid](#releaserouterid-routerid)
- [reset](#reset)
- [rloc16](#rloc16)
- [route](#route-add-prefix-s-prf)
- [router](#router-list)
- [routerdowngradethreshold](#routerdowngradethreshold)
- [routereligible](#routereligible)
- [routerselectionjitter](#routerselectionjitter)
- [routerupgradethreshold](#routerupgradethreshold)
- [scan](#scan-channel)
- [service](#service)
- [singleton](#singleton)
- [sntp](#sntp-query-sntp-server-ip-sntp-server-port)
- [state](#state)
- [thread](#thread-start)
- [txpower](#txpower)
- [version](#version)
## OpenThread Command Details
@ -123,11 +116,11 @@ Done
```
### bbr state
Show local Backbone state ([`Disabled`,`Primary`, `Secondary`]) for Thread 1.2 FTD.
`OPENTHREAD_CONFIG_BACKBONE_ROUTER_ENABLE` is required.
```bash
> bbr state
Disabled
@ -143,9 +136,8 @@ Done
```
### bbr enable
Enable Backbone Router Service for Thread 1.2 FTD.
`SRV_DATA.ntf` would be triggerred for attached device if there is no
Backbone Router Service in Thread Network Data.
Enable Backbone Router Service for Thread 1.2 FTD. `SRV_DATA.ntf` would be triggerred for attached device if there is no Backbone Router Service in Thread Network Data.
`OPENTHREAD_CONFIG_BACKBONE_ROUTER_ENABLE` is required.
@ -155,10 +147,8 @@ Done
```
### bbr disable
Disable Backbone Router Service for Thread 1.2 FTD.
`SRV_DATA.ntf` would be triggerred if Backbone Router is Primary state.
o
`OPENTHREAD_CONFIG_BACKBONE_ROUTER_ENABLE` is required.
Disable Backbone Router Service for Thread 1.2 FTD. `SRV_DATA.ntf` would be triggerred if Backbone Router is Primary state. o `OPENTHREAD_CONFIG_BACKBONE_ROUTER_ENABLE` is required.
```bash
> bbr disable
@ -166,8 +156,8 @@ Done
```
### bbr register
Register Backbone Router Service for Thread 1.2 FTD.
`SRV_DATA.ntf` would be triggerred for attached device.
Register Backbone Router Service for Thread 1.2 FTD. `SRV_DATA.ntf` would be triggerred for attached device.
`OPENTHREAD_CONFIG_BACKBONE_ROUTER_ENABLE` is required.
@ -192,10 +182,7 @@ Done
### bbr config \[seqno \<seqno\>\] \[delay \<delay\>\] \[timeout \<timeout\>\]
Configure local Backbone Router configuration for Thread 1.2 FTD.
`bbr register` should be issued explicitly to register Backbone Router service to Leader for
Secondary Backbone Router. `SRV_DATA.ntf` would be initiated automatically if BBR Dataset
changes for Primary Backbone Router.
Configure local Backbone Router configuration for Thread 1.2 FTD. `bbr register` should be issued explicitly to register Backbone Router service to Leader for Secondary Backbone Router. `SRV_DATA.ntf` would be initiated automatically if BBR Dataset changes for Primary Backbone Router.
`OPENTHREAD_CONFIG_BACKBONE_ROUTER_ENABLE` is required.
@ -309,7 +296,7 @@ Done
### child \<id\>
Print diagnostic information for an attached Thread Child. The `id` may be a Child ID or an RLOC16.
Print diagnostic information for an attached Thread Child. The `id` may be a Child ID or an RLOC16.
```bash
> child 1
@ -347,8 +334,7 @@ Done
### childip max \<count\>
Set the maximum number of IP addresses that each MTD child may register with this device as parent.
0 to clear the setting and restore the default.
Set the maximum number of IP addresses that each MTD child may register with this device as parent. 0 to clear the setting and restore the default.
`OPENTHREAD_CONFIG_REFERENCE_DEVICE_ENABLE` is required.
@ -503,8 +489,8 @@ Done
Set time sync parameters
* timesyncperiod: The time synchronization period, in seconds.
* xtalthreshold: The XTAL accuracy threshold for a device to become Router-Capable device, in PPM.
- timesyncperiod: The time synchronization period, in seconds.
- xtalthreshold: The XTAL accuracy threshold for a device to become Router-Capable device, in PPM.
```bash
> networktime 100 300
@ -534,7 +520,7 @@ Done
Perform an MLE Discovery operation.
* channel: The channel to discover on. If no channel is provided, the discovery will cover all valid channels.
- channel: The channel to discover on. If no channel is provided, the discovery will cover all valid channels.
```bash
> discover
@ -546,10 +532,10 @@ Done
### dns resolve \<hostname\> \[DNS server IP\] \[DNS server port\]
Send DNS Query to obtain IPv6 address for given hostname.
The latter two parameters have following default values:
* DNS server IP: 2001:4860:4860::8888 (Google DNS Server)
* DNS server port: 53
Send DNS Query to obtain IPv6 address for given hostname. The latter two parameters have following default values:
- DNS server IP: 2001:4860:4860::8888 (Google DNS Server)
- DNS server port: 53
```bash
> dns resolve ipv6.google.com
@ -638,6 +624,7 @@ Done
```
### factoryreset
Delete all stored settings, and signal a platform reset.
```bash
@ -830,8 +817,7 @@ Done
### keysequence guardtime \<guardtime\>
Set Thread Key Switch Guard Time (in hours)
0 means Thread Key Switch imediately if key index match
Set Thread Key Switch Guard Time (in hours) 0 means Thread Key Switch imediately if key index match
```bash
> keysequence guardtime 0
@ -914,9 +900,7 @@ Done
- Note: Simulation Only, ie: `OPENTHREAD_EXAMPLES_SIMULATION`
- Requires `OPENTHREAD_CONFIG_LOG_OUTPUT == OPENTHREAD_CONFIG_LOG_OUTPUT_DEBUG_UART`
Specifies filename to capture otPlatLog() messages, useful when
debugging automated test scripts on Linux when logging disrupts
the automated test scripts.
Specifies filename to capture otPlatLog() messages, useful when debugging automated test scripts on Linux when logging disrupts the automated test scripts.
### log level
@ -960,10 +944,10 @@ Done
Get the Thread Device Mode value.
* r: rx-on-when-idle
* s: Secure IEEE 802.15.4 data requests
* d: Full Thread Device
* n: Full Network Data
- r: rx-on-when-idle
- s: Secure IEEE 802.15.4 data requests
- d: Full Thread Device
- n: Full Network Data
```bash
> mode
@ -975,10 +959,10 @@ Done
Set the Thread Device Mode value.
* r: rx-on-when-idle
* s: Secure IEEE 802.15.4 data requests
* d: Full Thread Device
* n: Full Network Data
- r: rx-on-when-idle
- s: Secure IEEE 802.15.4 data requests
- d: Full Thread Device
- n: Full Network Data
```bash
> mode rsdn
@ -1032,8 +1016,7 @@ Done
Send network diagnostic request to retrieve tlv of \<type\>s.
If \<addr\> is unicast address, `Diagnostic Get` will be sent.
if \<addr\> is multicast address, `Diagnostic Query` will be sent.
If \<addr\> is unicast address, `Diagnostic Get` will be sent. if \<addr\> is multicast address, `Diagnostic Query` will be sent.
```bash
> networkdiagnostic get fdde:ad00:beef:0:0:ff:fe00:fc00 0 1 6
@ -1131,11 +1114,7 @@ Done
Get the diagnostic information for a Thread Router as parent.
Note: When operating as a Thread Router, this command will return the cached
information from when the device was previously attached as a Thread
Child. Returning cached information is necessary to support the Thread
Test Harness - Test Scenario 8.2.x requests the former parent (i.e. Joiner
Router's) MAC address even if the device has already promoted to a router.
Note: When operating as a Thread Router, this command will return the cached information from when the device was previously attached as a Thread Child. Returning cached information is necessary to support the Thread Test Harness - Test Scenario 8.2.x requests the former parent (i.e. Joiner Router's) MAC address even if the device has already promoted to a router.
```bash
> parent
@ -1166,14 +1145,14 @@ Set the assigned parent priority value: 1, 0, -1 or -2.
Done
```
### ping \<ipaddr\> [size] [count] [interval] [hoplimit]
### ping \<ipaddr\> [size][count] [interval][hoplimit]
Send an ICMPv6 Echo Request.
* size: The number of data bytes to be sent.
* count: The number of ICMPv6 Echo Requests to be sent.
* interval: The interval between two consecutive ICMPv6 Echo Requests in seconds. The value may have fractional form, for example `0.5`.
* hoplimit: The hoplimit of ICMPv6 Echo Request to be sent.
- size: The number of data bytes to be sent.
- count: The number of ICMPv6 Echo Requests to be sent.
- interval: The interval between two consecutive ICMPv6 Echo Requests in seconds. The value may have fractional form, for example `0.5`.
- hoplimit: The hoplimit of ICMPv6 Echo Request to be sent.
```bash
> ping fdde:ad00:beef:0:558:f56b:d688:799
@ -1222,6 +1201,7 @@ Done
```
### preferrouterid \<routerid\>
Prefer a Router ID when solicit router id from Leader.
```bash
@ -1231,10 +1211,7 @@ Done
### prefix
Get the prefix list in the local Network Data.
Note: For the Thread 1.2 border router with backbone capability, the local Domain
Prefix would be listed as well (with flag `D`), with preceeding `- ` if backbone
functionality is disabled.
Get the prefix list in the local Network Data. Note: For the Thread 1.2 border router with backbone capability, the local Domain Prefix would be listed as well (with flag `D`), with preceeding `-` if backbone functionality is disabled.
```bash
> prefix
@ -1243,22 +1220,22 @@ Note: For the Thread 1.2 border router with backbone capability, the local Domai
Done
```
### prefix add \<prefix\> [padcrosnD] [prf]
### prefix add \<prefix\> [padcrosnD][prf]
Add a valid prefix to the Network Data.
Note: The Domain Prefix flag (`D`) is only available for Thread 1.2.
* p: Preferred flag
* a: Stateless IPv6 Address Autoconfiguration flag
* d: DHCPv6 IPv6 Address Configuration flag
* c: DHCPv6 Other Configuration flag
* r: Default Route flag
* o: On Mesh flag
* s: Stable flag
* n: Nd Dns flag
* D: Domain Prefix flag
* prf: Default router preference, which may be 'high', 'med', or 'low'.
- p: Preferred flag
- a: Stateless IPv6 Address Autoconfiguration flag
- d: DHCPv6 IPv6 Address Configuration flag
- c: DHCPv6 Other Configuration flag
- r: Default Route flag
- o: On Mesh flag
- s: Stable flag
- n: Nd Dns flag
- D: Domain Prefix flag
- prf: Default router preference, which may be 'high', 'med', or 'low'.
```bash
> prefix add 2001:dead:beef:cafe::/64 paros med
@ -1306,6 +1283,7 @@ Done
```
### releaserouterid \<routerid\>
Release a Router ID that has been allocated by the device in the Leader role.
```bash
@ -1314,6 +1292,7 @@ Done
```
### reset
Signal a platform reset.
```bash
@ -1340,12 +1319,12 @@ Get the external route list in the local Network Data.
Done
```
### route add \<prefix\> [s] [prf]
### route add \<prefix\> [s][prf]
Add a valid external route to the Network Data.
* s: Stable flag
* prf: Default Router Preference, which may be: 'high', 'med', or 'low'.
- s: Stable flag
- prf: Default Router Preference, which may be: 'high', 'med', or 'low'.
```bash
> route add 2001:dead:beef:cafe::/64 s med
@ -1386,7 +1365,7 @@ Done
### router \<id\>
Print diagnostic information for a Thread Router. The `id` may be a Router ID or an RLOC16.
Print diagnostic information for a Thread Router. The `id` may be a Router ID or an RLOC16.
```bash
> router 50
@ -1507,7 +1486,7 @@ Done
Perform an IEEE 802.15.4 Active Scan.
* channel: The channel to scan on. If no channel is provided, the active scan will cover all valid channels.
- channel: The channel to scan on. If no channel is provided, the active scan will cover all valid channels.
```bash
> scan
@ -1521,7 +1500,7 @@ Done
Perform an IEEE 802.15.4 Energy Scan.
* duration: The time in milliseconds to spend scanning each channel.
- duration: The time in milliseconds to spend scanning each channel.
```bash
> scan energy 10
@ -1547,6 +1526,7 @@ Done
```
### singleton
Return true when there are no other nodes in the network, otherwise return false.
```bash
@ -1557,10 +1537,10 @@ Done
### sntp query \[SNTP server IP\] \[SNTP server port\]
Send SNTP Query to obtain current unix epoch time (from 1st January 1970).
The latter two parameters have following default values:
* NTP server IP: 2001:4860:4806:8:: (Google IPv6 NTP Server)
* NTP server port: 123
Send SNTP Query to obtain current unix epoch time (from 1st January 1970). The latter two parameters have following default values:
- NTP server IP: 2001:4860:4806:8:: (Google IPv6 NTP Server)
- NTP server port: 123
```bash
> sntp query
@ -1568,12 +1548,14 @@ The latter two parameters have following default values:
```
You can use NAT64 of OpenThread Border Router to reach e.g. Google IPv4 NTP Server:
```bash
> sntp query 64:ff9b::d8ef:2308
> SNTP response - Unix time: 1540898611 (era: 0)
```
### state
Return state of current state.
```bash
@ -1583,6 +1565,7 @@ Done
```
### state <state>
Try to switch to state `detached`, `child`, `router` or `leader`.
```bash
@ -1741,8 +1724,7 @@ Done
### macfilter addr add \<extaddr\> \[rss\]
Add an IEEE 802.15.4 Extended Address to the address filter, and fixed the received singal strength for
the messages from the address if rss is specified.
Add an IEEE 802.15.4 Extended Address to the address filter, and fixed the received singal strength for the messages from the address if rss is specified.
```bash
> macfilter addr add 0f6127e33af6b403 -95
@ -1785,9 +1767,7 @@ Done
### macfilter rss add \<extaddr\> \<rss\>
Set the received signal strength for the messages from the IEEE802.15.4 Extended Address.
If extaddr is \*, default received signal strength for all received messages would be set.
Set the received signal strength for the messages from the IEEE802.15.4 Extended Address. If extaddr is \*, default received signal strength for all received messages would be set.
```bash
> macfilter rss add * -50
@ -1801,10 +1781,7 @@ Done
### macfilter rss add-lqi \<extaddr\> \<lqi\>
Set the received link quality for the messages from the IEEE802.15.4 Extended Address. Valid lqi range [0,3]
If extaddr is \*, default received link quality for all received messages would be set.
Equivalent with 'filter rss add' with similar usage
Set the received link quality for the messages from the IEEE802.15.4 Extended Address. Valid lqi range [0,3] If extaddr is \*, default received link quality for all received messages would be set. Equivalent with 'filter rss add' with similar usage
```bash
> macfilter rss add-lqi * 3
@ -1818,8 +1795,7 @@ Done
### macfilter rss remove \<extaddr\>
Removes the received signal strength or received link quality setting on the Extended Address.
If extaddr is \*, default received signal strength or link quality for all received messages would be unset.
Removes the received signal strength or received link quality setting on the Extended Address. If extaddr is \*, default received signal strength or link quality for all received messages would be unset.
```bash
> macfilter rss remove *
@ -1842,14 +1818,11 @@ Done
### diag
Factory Diagnostics module is enabled only when building OpenThread with `OPENTHREAD_CONFIG_DIAG_ENABLE=1` option.
Go [diagnostics module][DIAG] for more information.
Factory Diagnostics module is enabled only when building OpenThread with `OPENTHREAD_CONFIG_DIAG_ENABLE=1` option. Go [diagnostics module][diag] for more information.
### service
Module for controlling service registration in Network Data.
Each change in service registration must be sent to leader by `netdataregister` command
before taking effect.
Module for controlling service registration in Network Data. Each change in service registration must be sent to leader by `netdataregister` command before taking effect.
### service add \<enterpriseNumber\> \<serviceData\> \<serverData\>
@ -1886,4 +1859,4 @@ fdde:ad00:beef:0:8ca4:19ed:217a:eff9
Done
```
[DIAG]:../../src/core/diags/README.md
[diag]: ../../src/core/diags/README.md

80
src/cli/README_COAP.md
View File

@ -54,18 +54,18 @@ coap response sent
## Command List
* [help](#help)
* [cancel](#cancel)
* [delete](#delete-address-uri-path-type-payload)
* [get](#get-address-uri-path-type)
* [observe](#observe-address-uri-path-type)
* [parameters](#parameters)
* [post](#post-address-uri-path-type-payload)
* [put](#put-address-uri-path-type-payload)
* [resource](#resource-uri-path)
* [set](#set-new-content)
* [start](#start)
* [stop](#stop)
- [help](#help)
- [cancel](#cancel)
- [delete](#delete-address-uri-path-type-payload)
- [get](#get-address-uri-path-type)
- [observe](#observe-address-uri-path-type)
- [parameters](#parameters)
- [post](#post-address-uri-path-type-payload)
- [put](#put-address-uri-path-type-payload)
- [resource](#resource-uri-path)
- [set](#set-new-content)
- [start](#start)
- [stop](#stop)
## Command Details
@ -92,8 +92,7 @@ List the CoAP CLI commands.
### cancel
Request the cancellation of an existing observation subscription to a remote
resource.
Request the cancellation of an existing observation subscription to a remote resource.
```bash
> coap cancel
@ -102,10 +101,10 @@ Done
### delete \<address\> \<uri-path\> \[type\] \[payload\]
* address: IPv6 address of the CoAP server.
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
* payload: CoAP request payload.
- address: IPv6 address of the CoAP server.
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- payload: CoAP request payload.
```bash
> coap delete fdde:ad00:beef:0:2780:9423:166c:1aac test-resource con payload
@ -114,9 +113,9 @@ Done
### get \<address\> \<uri-path\> \[type\]
* address: IPv6 address of the CoAP server.
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- address: IPv6 address of the CoAP server.
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
```bash
> coap get fdde:ad00:beef:0:2780:9423:166c:1aac test-resource
@ -125,23 +124,22 @@ Done
### observe \<address\> \<uri-path\> \[type\]
This is the same a `get`, but the `Observe` parameter will be sent, set to 0
triggering a subscription request.
This is the same a `get`, but the `Observe` parameter will be sent, set to 0 triggering a subscription request.
* address: IPv6 address of the CoAP server.
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- address: IPv6 address of the CoAP server.
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
```bash
> coap observe fdde:ad00:beef:0:2780:9423:166c:1aac test-resource
Done
```
### parameters \<type\> \["default"|<ack\_timeout\> <ack\_random\_factor\_numerator\> <ack\_random\_factor\_denominator\> <max\_retransmit\>\]
### parameters \<type\> \["default"|<ack_timeout\> <ack_random_factor_numerator\> <ack_random_factor_denominator\> <max_retransmit\>\]
Sets transmission parameters for the following interactions.
* type: "request" for CoAP requests and "response" for CoAP responses.
- type: "request" for CoAP requests and "response" for CoAP responses.
If no more parameters are given, the command prints the current configuration:
@ -162,10 +160,10 @@ Done
```
Also, you can specify the transmission parameters in the command line:
* ack\_timeout (0~UINT32\_MAX): RFC7252 ACK\_TIMEOUT, in milliseconds.
* ack\_random\_factor\_numerator, ack\_random\_factor\_denominator (0~255):
RFC7252 ACK\_RANDOM\_FACTOR=ack\_random\_factor\_numerator/ack\_random\_factor\_denominator.
* max\_retransmit (0~255): RFC7252 MAX_RETRANSMIT.
- ack_timeout (0~UINT32_MAX): RFC7252 ACK_TIMEOUT, in milliseconds.
- ack_random_factor_numerator, ack_random_factor_denominator (0~255): RFC7252 ACK_RANDOM_FACTOR=ack_random_factor_numerator/ack_random_factor_denominator.
- max_retransmit (0~255): RFC7252 MAX_RETRANSMIT.
```bash
> coap parameters request 1000 255 254 2
@ -176,10 +174,10 @@ Done
### post \<address\> \<uri-path\> \[type\] \[payload\]
* address: IPv6 address of the CoAP server.
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
* payload: CoAP request payload.
- address: IPv6 address of the CoAP server.
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- payload: CoAP request payload.
```bash
> coap post fdde:ad00:beef:0:2780:9423:166c:1aac test-resource con payload
@ -188,10 +186,10 @@ Done
### put \<address\> \<uri-path\> \[type\] \[payload\]
* address: IPv6 address of the CoAP server.
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
* payload: CoAP request payload.
- address: IPv6 address of the CoAP server.
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- payload: CoAP request payload.
```bash
> coap put fdde:ad00:beef:0:2780:9423:166c:1aac test-resource con payload
@ -212,7 +210,7 @@ Done
### set \[new-content\]
Sets the content sent by the test resource. If a CoAP client is observing the resource, a notification is sent to that client.
Sets the content sent by the test resource. If a CoAP client is observing the resource, a notification is sent to that client.
```bash
> coap set Testing123

65
src/cli/README_COAPS.md
View File

@ -6,7 +6,7 @@ The OpenThread CoAPS APIs may be invoked via the OpenThread CLI.
### Build with CoAPS API support
Use the `COAPS=1` build switch to enable CoAPS API support.
Use the `COAPS=1` build switch to enable CoAPS API support.
```bash
> ./bootstrap
@ -23,22 +23,23 @@ CoAPS uses DTLS to establish a secure, end-to-end connection.
This example supports two ciphersuites:
* TLS_PSK_WITH_AES_128_CCM_8
- TLS_PSK_WITH_AES_128_CCM_8
```bash
> coaps psk <your-psk> <your-psk-id>
Done
```
* TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
```bash
> coaps x509
Done
```
The X.509 certificate stored in `core/cli/x509_cert_key.hpp`.
The X.509 certificate stored in `core/cli/x509_cert_key.hpp`.
### Node 1
On node 1, setup CoAPS server with resource `test-resource`.
On node 1, setup CoAPS server with resource `test-resource`.
```bash
> coaps start
@ -90,18 +91,18 @@ coaps response sent
## Command List
* [help](#help)
* [connect](#connect-address)
* [delete](#delete-uri-path-type-payload)
* [disconnect](#disconnect)
* [get](#get-uri-path-type)
* [post](#post-uri-path-type-payload)
* [psk](#psk-psk-pskid)
* [put](#put-uri-path-type-payload)
* [resource](#resource-uri-path)
* [start](#start)
* [stop](#stop)
* [x509](#x509)
- [help](#help)
- [connect](#connect-address)
- [delete](#delete-uri-path-type-payload)
- [disconnect](#disconnect)
- [get](#get-uri-path-type)
- [post](#post-uri-path-type-payload)
- [psk](#psk-psk-pskid)
- [put](#put-uri-path-type-payload)
- [resource](#resource-uri-path)
- [start](#start)
- [stop](#stop)
- [x509](#x509)
## Command Details
@ -130,7 +131,7 @@ List the CoAPS CLI commands.
Establish DTLS session.
* address: IPv6 address of the peer.
- address: IPv6 address of the peer.
```bash
> coaps connect fdde:ad00:beef:0:9903:14b:27e0:5744
@ -140,9 +141,9 @@ coaps connected
### delete \<uri-path\> \[type\] \[payload\]
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
* payload: CoAPS request payload.
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- payload: CoAPS request payload.
```bash
> coaps delete test-resource con payload
@ -159,8 +160,8 @@ Done
### get \<uri-path\> \[type\]
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
```bash
> coaps get test-resource
@ -169,9 +170,9 @@ Done
### post \<uri-path\> \[type\] \[payload\]
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
* payload: CoAPS request payload.
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- payload: CoAPS request payload.
```bash
> coaps post test-resource con payload
@ -182,8 +183,8 @@ Done
Set DTLS ciphersuite to `TLS_PSK_WITH_AES_128_CCM_8`.
* psk: pre-shared key
* pskid: pre-shared key identifier
- psk: pre-shared key
- pskid: pre-shared key identifier
```bash
> coaps psk 123 pskid
@ -192,9 +193,9 @@ Done
### put \<uri-path\> \[type\] \[payload\]
* uri-path: URI path of the resource.
* type: "con" for Confirmable or "non-con" for Non-confirmable (default).
* payload: CoAPS request payload.
- uri-path: URI path of the resource.
- type: "con" for Confirmable or "non-con" for Non-confirmable (default).
- payload: CoAPS request payload.
```bash
> coaps put test-resource con payload
@ -217,7 +218,7 @@ Done
Starts the application coaps service.
* checkPeerCert: Peer Certificate Check can be disabled by typing false.
- checkPeerCert: Peer Certificate Check can be disabled by typing false.
```bash
> coaps start

4
src/cli/README_COMMISSIONER.md
View File

@ -85,7 +85,7 @@ Usage: `commissioner joiner add <eui64> <pskd>`
Add a Joiner entry.
- eui64: The IEEE EUI-64 of the Joiner or '*' to match any Joiner.
- eui64: The IEEE EUI-64 of the Joiner or '\*' to match any Joiner.
- pskd: Pre-Shared Key for the Joiner.
```bash
@ -99,7 +99,7 @@ Usage: `commissioner joiner remove <eui64>`
Remove a Joiner entry.
- eui64: The IEEE EUI-64 of the Joiner or '*' to match any Joiner.
- eui64: The IEEE EUI-64 of the Joiner or '\*' to match any Joiner.
```bash
> commissioner joiner remove d45e64fa83f81cf7

52
src/cli/README_COMMISSIONING.md
View File

@ -26,38 +26,38 @@ Form a network with the device that has Commissioner support.
1. Generate and view new network configuration.
```bash
> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 13
Channel Mask: 07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d/64
Master Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrcb
Done
```
```bash
> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 13
Channel Mask: 07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d/64
Master Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrcb
Done
```
2. Commit new dataset to the Active Operational Dataset in non-volatile storage.
```bash
dataset commit active
Done
```
```bash
dataset commit active
Done
```
3. Enable Thread interface
```bash
> ifconfig up
Done
> thread start
Done
```
```bash
> ifconfig up
Done
> thread start
Done
```
### Obtain Joiner IEEE EUI-64

136
src/cli/README_DATASET.md
View File

@ -8,22 +8,22 @@ Thread network configuration parameters are managed using Active and Pending Ope
The Active Operational Dataset includes parameters that are currently in use across an entire Thread network. The Active Operational Dataset contains:
* Active Timestamp
* Channel
* Channel Mask
* Extended PAN ID
* Mesh-Local Prefix
* Network Name
* PAN ID
* PSKc
* Security Policy
- Active Timestamp
- Channel
- Channel Mask
- Extended PAN ID
- Mesh-Local Prefix
- Network Name
- PAN ID
- PSKc
- Security Policy
### Pending Operational Dataset
The Pending Operational Dataset is used to communicate changes to the Active Operational Dataset before they take effect. The Pending Operational Dataset contains all the parameters from the Active Operational Dataset, with the addition of:
* Delay Timer
* Pending Timestamp
- Delay Timer
- Pending Timestamp
## Quick Start
@ -31,38 +31,38 @@ The Pending Operational Dataset is used to communicate changes to the Active Ope
1. Generate and view new network configuration.
```bash
> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 13
Channel Mask: 07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d/64
Master Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrcb
Done
```
```bash
> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 13
Channel Mask: 07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d/64
Master Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrcb
Done
```
2. Commit new dataset to the Active Operational Dataset in non-volatile storage.
```bash
dataset commit active
Done
```
```bash
dataset commit active
Done
```
3. Enable Thread interface
```bash
> ifconfig up
Done
> thread start
Done
```
```bash
> ifconfig up
Done
> thread start
Done
```
### Attach to Existing Network
@ -74,38 +74,38 @@ After the device successfully attaches to a Thread network, the device will retr
1. Create a partial Active Operational Dataset.
```bash
> dataset masterkey dfd34f0f05cad978ec4e32b0413038ff
Done
> dataset commit active
Done
```
```bash
> dataset masterkey dfd34f0f05cad978ec4e32b0413038ff
Done
> dataset commit active
Done
```
2. Enable Thread interface.
```bash
> ifconfig up
Done
> thread start
Done
```
```bash
> ifconfig up
Done
> thread start
Done
```
3. After attaching, validate that the device received the complete Active Operational Dataset.
```bash
> dataset active
Active Timestamp: 1
Channel: 13
Channel Mask: 07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d/64
Master Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrcb
Done
```
```bash
> dataset active
Active Timestamp: 1
Channel: 13
Channel Mask: 07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d/64
Master Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrcb
Done
```
## Command List
@ -395,11 +395,11 @@ Usage: `dataset securitypolicy <rotationtime> [onrcb]`
Set security policy.
* o: Obtaining the Master Key for out-of-band commissioning is enabled.
* n: Native Commissioning using PSKc is allowed.
* r: Thread 1.x Routers are enabled.
* c: External Commissioner authentication is allowed using PSKc.
* b: Thread 1.x Beacons are enabled.
- o: Obtaining the Master Key for out-of-band commissioning is enabled.
- n: Native Commissioning using PSKc is allowed.
- r: Thread 1.x Routers are enabled.
- c: External Commissioner authentication is allowed using PSKc.
- b: Thread 1.x Beacons are enabled.
```bash
> dataset securitypolicy 672 onrcb

12
src/cli/README_JOINER.md
View File

@ -6,10 +6,10 @@ See [README_COMMISSIONING.md](README_COMMISSIONING.md).
## Command List
* [help](#help)
* [id](#id)
* [start](#start)
* [stop](#stop)
- [help](#help)
- [id](#id)
- [start](#start)
- [stop](#stop)
## Command Details
@ -46,8 +46,8 @@ Usage: `joiner start <pskd> [provisioning-url]`
Start the Joiner role.
* pskd: Pre-Shared Key for the Joiner.
* provisioning-url: Provisioning URL for the Joiner (optional).
- pskd: Pre-Shared Key for the Joiner.
- provisioning-url: Provisioning URL for the Joiner (optional).
This command will cause the device to start the Joiner process.

48
src/cli/README_UDP.md
View File

@ -38,12 +38,12 @@ On node 1, you should see a print out similar to below:
## Command List
* [help](#help)
* [bind](#bind-ip-port)
* [close](#close)
* [connect](#connect-ip-port)
* [open](#open)
* [send](#send-ip-port-message)
- [help](#help)
- [bind](#bind-ip-port)
- [close](#close)
- [connect](#connect-ip-port)
- [open](#open)
- [send](#send-ip-port-message)
## Command Details
@ -65,8 +65,9 @@ Done
### bind \<ip\> \<port\>
Assigns a name (i.e. IPv6 address and port) to the example socket.
* ip: the IPv6 address or the unspecified IPv6 address (`::`).
* port: the UDP port
- ip: the IPv6 address or the unspecified IPv6 address (`::`).
- port: the UDP port
```bash
> udp bind :: 1234
@ -86,8 +87,8 @@ Done
Specifies the peer with which the socket is to be associated.
* ip: the peer's IPv6 address.
* port: the peer's UDP port.
- ip: the peer's IPv6 address.
- port: the peer's UDP port.
```bash
> udp connect fdde:ad00:beef:0:bb1:ebd6:ad10:f33 1234
@ -107,26 +108,23 @@ Done
Send a UDP message.
* ip: the IPv6 destination address.
* port: the UDP destination port.
* message: the message to send.
- ip: the IPv6 destination address.
- port: the UDP destination port.
- message: the message to send.
```bash
> udp send fdde:ad00:beef:0:bb1:ebd6:ad10:f33 1234 hello
Done
```
### send \<ip\> \<port\> \<type\> \<value\>
### send \<ip\> \<port\> \<type\> \<value\>
Send a few bytes over UDP.
* ip: the IPv6 destination address.
* port: the UDP destination port.
* type: the type of the message:
* `-t`: text payload in the `value`, same as without specifying the type.
* `-s`: autogenerated payload with specified length indicated in the `value`.
* `-x`: binary data in hexadecimal representation in the `value`.
- ip: the IPv6 destination address.
- port: the UDP destination port.
- type: the type of the message: _ `-t`: text payload in the `value`, same as without specifying the type. _ `-s`: autogenerated payload with specified length indicated in the `value`.
\* `-x`: binary data in hexadecimal representation in the `value`.
```bash
> udp send fdde:ad00:beef:0:bb1:ebd6:ad10:f33 1234 -t hello
@ -139,11 +137,12 @@ Done
Done
```
### send \<message\>
Send a UDP message on a connected socket.
* message: the message to send.
- message: the message to send.
```bash
> udp send hello
@ -154,10 +153,7 @@ Done
Send a few bytes over UDP.
* type: the type of the message:
* `-t`: text payload in the `value`, same as without specifying the type.
* `-s`: autogenerated payload with specified length indicated in the `value`.
* `-x`: binary data in hexadecimal representation in the `value`.
- type: the type of the message: _ `-t`: text payload in the `value`, same as without specifying the type. _ `-s`: autogenerated payload with specified length indicated in the `value`. \* `-x`: binary data in hexadecimal representation in the `value`.
```bash
> udp send -t hello

22
src/core/diags/README.md
View File

@ -4,19 +4,17 @@ The OpenThread diagnostics module is a tool for debugging platform hardware manu
The diagnostics module supports common diagnostics features that are listed below, and it also provides a mechanism for expanding platform specific diagnostics features.
## Common Diagnostics Command List
* [diag](#diag)
* [diag start](#diag-start)
* [diag channel](#diag-channel)
* [diag power](#diag-power)
* [diag send](#diag-send-packets-length)
* [diag repeat](#diag-repeat-delay-length)
* [diag radio](#diag-radio)
* [diag stats](#diag-stats)
* [diag stop](#diag-stop)
- [diag](#diag)
- [diag start](#diag-start)
- [diag channel](#diag-channel)
- [diag power](#diag-power)
- [diag send](#diag-send-packets-length)
- [diag repeat](#diag-repeat-delay-length)
- [diag radio](#diag-radio)
- [diag stats](#diag-stats)
- [diag stop](#diag-stop)
### diag
@ -154,6 +152,7 @@ Clear statistics during diagnostics mode.
> diag stats clear
stats cleared
```
### diag stop
Stop diagnostics mode and print statistics.
@ -168,4 +167,3 @@ last received packet: rssi=-61, lqi=98
stop diagnostics mode
status 0x00
```

27
src/posix/README.md
View File

@ -1,5 +1,4 @@
OpenThread POSIX app
====================
# OpenThread POSIX app
OpenThread supports running its core on POSIX and transmits radio frames through a radio transceiver.
@ -17,8 +16,7 @@ The figure below shows the architecture of OpenThread running in transceiver mod
POSIX Chip
```
Build
-----
## Build
```sh
# build core for POSIX
@ -27,11 +25,9 @@ make -f src/posix/Makefile-posix
make -f examples/Makefile-xxxx
```
Test
----
## Test
**NOTE** Assuming the build system is 64bit Linux, you can use the normal OpenThread CLI as described in the [command line document](../../src/cli/README.md).
You can also perform radio diagnostics using the command [diag](../../src/core/diags/README.md).
**NOTE** Assuming the build system is 64bit Linux, you can use the normal OpenThread CLI as described in the [command line document](../../src/cli/README.md). You can also perform radio diagnostics using the command [diag](../../src/core/diags/README.md).
### With Simulation
@ -44,7 +40,7 @@ make -f examples/Makefile-simulation
#### nRF52840
* USB=0
- USB=0
```sh
make -f examples/Makefile-nrf52840
@ -65,7 +61,7 @@ EOF
./output/posix/x86_64-unknown-linux-gnu/bin/ot-cli /dev/ttyACM0 115200
```
* USB=1
- USB=1
```sh
# without USB=1 may result in failure for serial port issue
@ -86,10 +82,9 @@ python cc2538-bsl/cc2538-bsl.py -b 460800 -e -w -v -p /dev/ttyUSB0 ot-rcp.bin
./output/posix/x86_64-unknown-linux-gnu/bin/ot-cli /dev/ttyUSB0 115200
```
Wpantund Support
----------------
## Wpantund Support
**NOTE** Assuming the build system is 64bit Linux and *wpantund* is already installed and **stopped**.
**NOTE** Assuming the build system is 64bit Linux and _wpantund_ is already installed and **stopped**.
### With Simulation
@ -106,11 +101,9 @@ sudo wpantund -s 'system:./output/posix/x86_64-unknown-linux-gnu/bin/ot-ncp /dev
sudo wpantund -s 'system:./output/posix/x86_64-unknown-linux-gnu/bin/ot-ncp /dev/ttyUSB0 115200'
```
Daemon Mode Support
-------------------
## Daemon Mode Support
OpenThread Posix Daemon mode uses a unix socket as input and output, so that OpenThread core can run as a service. And a client
can communicate with it by connecting to the socket. The protocol is OpenThread CLI.
OpenThread Posix Daemon mode uses a unix socket as input and output, so that OpenThread core can run as a service. And a client can communicate with it by connecting to the socket. The protocol is OpenThread CLI.
```
# build daemon mode core stack for POSIX

5
src/posix/platform/README.md
View File

@ -10,10 +10,9 @@ $ ./bootstrap
$ make -f src/posix/Makefile-posix
```
After a successful build, the `elf` files are found in
`<path-to-openthread>/output/posix/<platform>/bin`.
After a successful build, the `elf` files are found in `<path-to-openthread>/output/posix/<platform>/bin`.
##
##
## Interact

17
tests/scripts/thread-cert/README.md
View File

@ -1,8 +1,6 @@
OpenThread Certification Tests
==============================
# OpenThread Certification Tests
Inspector
--------
## Inspector
Inspect nodes status by the following modification:
@ -37,14 +35,15 @@ face
### CLI reference
#### `#` mode
This is selection mode. You may select the node to inspect here.
- `list` - list available nodes.
- `exit` - end inspecting, continue running test case.
- \<number\> - select the node with id \<number\>. This will result in entering `>` mode.
- `list` - list available nodes.
- `exit` - end inspecting, continue running test case.
- \<number\> - select the node with id \<number\>. This will result in entering `>` mode.
#### `>` mode
This is node mode. You may run OpenThread CLI here.
* `exit` - go back to `#` mode.
- `exit` - go back to `#` mode.

46
tests/toranj/README.md
View File

@ -6,13 +6,12 @@
- It can be used to simulate multiple nodes forming complex network topologies.
- It allows testing of network interactions between many nodes (IPv6 traffic exchanges).
`toranj` is developed in Python. `toranj` runs wpantund natively with OpenThread in NCP mode on POSIX simulation platform.
`toranj` tests will run as part of GitHub Actions pull request validation in OpenThread and/or `wpantund` GitHub projects.
`toranj` is developed in Python. `toranj` runs wpantund natively with OpenThread in NCP mode on POSIX simulation platform. `toranj` tests will run as part of GitHub Actions pull request validation in OpenThread and/or `wpantund` GitHub projects.
## Setup
`toranj` requires `wpantund` to be installed.
- Please follow [`wpantund` installation guide](https://github.com/openthread/wpantund/blob/master/INSTALL.md#wpantund-installation-guide). Note that `toranj` expects `wpantund` installed from latest master branch.
- Alternative way to install `wpantund` is to use the same commands from git workflow [Simulation](https://github.com/openthread/openthread/blob/4b55284bd20f99a88e8e2c617ba358a0a5547f5d/.github/workflows/simulation.yml#L336-L341) for build target `toranj-test-framework`.
@ -39,7 +38,6 @@ To run a specific test
`wpan.Node()` class creates a Thread node instance. It creates a sub-process to run `wpantund` and OpenThread, and provides methods to control the node.
```python
>>> import wpan
>>> node1 = wpan.Node()
@ -49,6 +47,7 @@ Node (index=1, interface_name=wpan1)
>>> node2
Node (index=2, interface_name=wpan2)
```
Note: You may need to run as `sudo` to allow `wpantund` to create tunnel interface (i.e., use `sudo python`).
### `wpan.Node` methods providing `wpanctl` commands
@ -65,6 +64,7 @@ Note: You may need to run as `sudo` to allow `wpantund` to create tunnel interfa
```
Example:
```python
>>> node.get(wpan.WPAN_NAME)
'"test-network"'
@ -77,6 +77,7 @@ Example:
```
- Common network operations:
```python
node.reset() # Reset the NCP
node.status() # Get current status
@ -91,6 +92,7 @@ Example:
```
Example:
```python
>>> result = node.status()
>>> print result
@ -126,6 +128,7 @@ wpan1 => [
```
- Scan:
```python
node.active_scan(channel=None)
node.energy_scan(channel=None)
@ -133,7 +136,8 @@ wpan1 => [
node.permit_join(duration_sec=None, port=None, udp=True, tcp=True)
```
- On-mesh prefixes and off-mesh routes:
- On-mesh prefixes and off-mesh routes:
```python
node.config_gateway(prefix, default_route=False)
node.add_route(route_prefix, prefix_len_in_bytes=None, priority=None)
@ -144,22 +148,15 @@ A direct `wpanctl` command can be issued using `node.wpanctl(command)` with a gi
`wpan` module provides variables for different `wpantund` properties. Some commonly used are:
- Network/NCP properties:
WPAN_STATE, WPAN_NAME, WPAN_PANID, WPAN_XPANID, WPAN_KEY, WPAN_CHANNEL, WPAN_HW_ADDRESS,
WPAN_EXT_ADDRESS, WPAN_POLL_INTERVAL, WPAN_NODE_TYPE, WPAN_ROLE, WPAN_PARTITION_ID
- Network/NCP properties: WPAN_STATE, WPAN_NAME, WPAN_PANID, WPAN_XPANID, WPAN_KEY, WPAN_CHANNEL, WPAN_HW_ADDRESS, WPAN_EXT_ADDRESS, WPAN_POLL_INTERVAL, WPAN_NODE_TYPE, WPAN_ROLE, WPAN_PARTITION_ID
- IPv6 Addresses:
WPAN_IP6_LINK_LOCAL_ADDRESS, WPAN_IP6_MESH_LOCAL_ADDRESS, WPAN_IP6_MESH_LOCAL_PREFIX,
WPAN_IP6_ALL_ADDRESSES, WPAN_IP6_MULTICAST_ADDRESSES
- IPv6 Addresses: WPAN_IP6_LINK_LOCAL_ADDRESS, WPAN_IP6_MESH_LOCAL_ADDRESS, WPAN_IP6_MESH_LOCAL_PREFIX, WPAN_IP6_ALL_ADDRESSES, WPAN_IP6_MULTICAST_ADDRESSES
- Thread Properties:
WPAN_THREAD_RLOC16, WPAN_THREAD_ROUTER_ID, WPAN_THREAD_LEADER_ADDRESS,
WPAN_THREAD_LEADER_ROUTER_ID, WPAN_THREAD_LEADER_WEIGHT, WPAN_THREAD_LEADER_NETWORK_DATA,
- Thread Properties: WPAN_THREAD_RLOC16, WPAN_THREAD_ROUTER_ID, WPAN_THREAD_LEADER_ADDRESS, WPAN_THREAD_LEADER_ROUTER_ID, WPAN_THREAD_LEADER_WEIGHT, WPAN_THREAD_LEADER_NETWORK_DATA,
WPAN_THREAD_CHILD_TABLE, WPAN_THREAD_CHILD_TABLE_ADDRESSES, WPAN_THREAD_NEIGHBOR_TABLE,
WPAN_THREAD_ROUTER_TABLE
Method `join_node()` can be used by a node to join another node:
```python
@ -177,6 +174,7 @@ Method `whitelist_node()` can be used to add a given node to the whitelist of th
#### Example (simple 3-node topology)
Script below shows how to create a 3-node network topology with `node1` and `node2` being routers, and `node3` an end-device connected to `node2`:
```python
>>> import wpan
>>> node1 = wpan.Node()
@ -223,12 +221,14 @@ Script below shows how to create a 3-node network topology with `node1` and `nod
```
- `src` and `dst` can be
- either a string containing an IPv6 address
- or a tuple (ipv6 address as string, port). if no port is given, a random port number is used.
- either a string containing an IPv6 address
- or a tuple (ipv6 address as string, port). if no port is given, a random port number is used.
- `data` can be
- either a string containing the message to be sent,
- or an int indicating size of the message (a random message with the given length will be generated).
- either a string containing the message to be sent,
- or an int indicating size of the message (a random message with the given length will be generated).
- `count` gives number of times the message will be sent (default is 1).
@ -256,6 +256,7 @@ After `perform_async_tx_rx()` is done, the `AsyncSender` and `AsyncReceiver` obj
#### Example
Sending 10 messages containing `"Hello there!"` from `node1` to `node2` using their mesh-local addresses:
```python
# `node1` and `node2` are already joined and are part of the same Thread network.
@ -301,12 +302,12 @@ True
### Logs and Verbose mode
Every `wpan.Node()` instance will save its corresponding `wpantund` logs. By default the logs are saved in a file
`wpantun-log<node_index>.log`. By setting `wpan.Node__TUND_LOG_TO_FILE` to `False` the logs are written to `stdout` as the test-cases are executed.
Every `wpan.Node()` instance will save its corresponding `wpantund` logs. By default the logs are saved in a file `wpantun-log<node_index>.log`. By setting `wpan.Node__TUND_LOG_TO_FILE` to `False` the logs are written to `stdout` as the test-cases are executed.
When `start.sh` script is used to run all test-cases, if any test fails, to help with debugging of the issue, the last 30 lines of `wpantund` logs of every node involved in the test-case is dumped to `stdout`.
A `wpan.Node()` instance can also provide additional logs and info as the test-cases are run (verbose mode). By default this is disabled. It can be enabled for a node instance when it is created:
```python
node = wpan.Node(verbose=True) # `node` instance will provide extra logs.
```
@ -336,6 +337,7 @@ recver = node2.prepare_rx(sender)
wpan.Node.perform_async_tx_rx()
```
```
$ Node1.__init__() cmd: /usr/local/sbin/wpantund -o Config:NCP:SocketPath "system:../../examples/apps/ncp/ot-ncp-ftd 1" -o Config:TUN:InterfaceName wpan1 -o Config:NCP:DriverName spinel -o Daemon:SyslogMask "all -debug"
$ Node2.__init__() cmd: /usr/local/sbin/wpantund -o Config:NCP:SocketPath "system:../../examples/apps/ncp/ot-ncp-ftd 2" -o Config:TUN:InterfaceName wpan2 -o Config:NCP:DriverName spinel -o Daemon:SyslogMask "all -debug"
@ -366,6 +368,6 @@ $ Node2.wpanctl('get -v IPv6:LinkLocalAddress') -> '"fe80::ec08:f348:646f:d37d"'
```
------
---
What does `"toranj"` mean? it's the name of a common symmetric weaving [pattern](https://en.wikipedia.org/wiki/Persian_carpet#/media/File:Toranj_-_special_circular_design_of_Iranian_carpets.JPG) used in Persian carpets.

31
tools/gerrit/README.md
View File

@ -1,29 +1,26 @@
git-squash-merge tool
================
# git-squash-merge tool
`git-squash-merge` is a bash script to help squash merge a given branch
into the current branch. This tool is helpful for synchronizing
git repositories which work with `gerrit`.
`git-squash-merge` is a bash script to help squash merge a given branch into the current branch. This tool is helpful for synchronizing git repositories which work with `gerrit`.
This command squash merges all commits from a given branch into the current branch.
By default the changes are committed with a commit message containing the list
of all squashed commits.
This command squash merges all commits from a given branch into the current branch. By default the changes are committed with a commit message containing the list of all squashed commits.
## Syntax ##
## Syntax
```
git-squash-merge [--no-list] [--no-commit] <branch> [<commit msg>]"
```
## Parameters ##
* `<branch>` specifies the name of branch to merge into current branch.
* `<commit msg>` is an optional parameter specifying text to add to the commit message.
## Parameters
## Options ##
* `--no-list` when used the commit message will not include the list of squashed commits.
* `--no-commit` when used, the tool squashes and stages the changes but does not commit"
- `<branch>` specifies the name of branch to merge into current branch.
- `<commit msg>` is an optional parameter specifying text to add to the commit message.
## Example of Use ##
## Options
- `--no-list` when used the commit message will not include the list of squashed commits.
- `--no-commit` when used, the tool squashes and stages the changes but does not commit"
## Example of Use
```
~/sw/openthread $ ./tools/gerrit/git-squash-merge.sh github/master "OpenThread GitHub sync"
@ -64,4 +61,4 @@ Date: Tue Aug 14 14:53:33 2018 -0700
Change-Id: I2fd7b537fc1e0251082f091cb897b9ac25e105dd
Successfully squash merged branch 'github/master' into 'HEAD'
```
```

23
tools/harness-sniffer/README.md
View File

@ -1,17 +1,16 @@
OpenThread Sniffer Integration with Thread Test Harness
=============================
# OpenThread Sniffer Integration with Thread Test Harness
After following the steps below, you will be able to run Test Harness with OpenThread sniffer.
1) require python3 is installed on windows and in the system environment path.
2) require TestHarness is updated on `ReportEngine.pyd`
1. require python3 is installed on windows and in the system environment path.
2. require TestHarness is updated on `ReportEngine.pyd`
## Setup
1. install pyspinel (for python3 only)
```
git clone https://github.com/openthread/pyspinel.git
cd <path-to-pyspinel>
python setup.py install
```
```
git clone https://github.com/openthread/pyspinel.git
cd <path-to-pyspinel>
python setup.py install
```
2. Copy "OT_Sniffer.py" to `C:\GRL\Thread1.1\Thread_Harness\Sniffer`.

48
tools/harness-thci/README.md
View File

@ -1,21 +1,15 @@
THCI & Test Environment Setup
=============================
# THCI & Test Environment Setup
THCI (Thread Host Controller Interface) is an implementation of the Python abstract class template "IThci",
which is used by the Thread Test Harness Software to control OpenThread-based reference devices according to each test
scenario.
THCI (Thread Host Controller Interface) is an implementation of the Python abstract class template "IThci", which is used by the Thread Test Harness Software to control OpenThread-based reference devices according to each test scenario.
Currently, there are two THCI implementations for OpenThread:
* OpenThread CLI — Based on the CC2538 example platform, which is included in the current Thread Test Harness Software
release.
* OpenThread `wpanctl` — Based on `wpantund` running on a Linux host (for example, a Raspberry Pi 3B) working with a Network
Co-Processor (NCP) (for example, a Nordic Semiconductor nRF52840) running an OpenThread NCP image.
- OpenThread CLI — Based on the CC2538 example platform, which is included in the current Thread Test Harness Software release.
- OpenThread `wpanctl` — Based on `wpantund` running on a Linux host (for example, a Raspberry Pi 3B) working with a Network Co-Processor (NCP) (for example, a Nordic Semiconductor nRF52840) running an OpenThread NCP image.
Platform developers should modify the THCI implementation directly to match their platform (for example, serial baud rate).
Alternatively, platform developers may follow the instructions below to add a new THCI implementation to the Test Harness.
Platform developers should modify the THCI implementation directly to match their platform (for example, serial baud rate). Alternatively, platform developers may follow the instructions below to add a new THCI implementation to the Test Harness.
## OpenThread Environment Setup ##
## OpenThread Environment Setup
1. Copy "OpenThread.png" to `C:\GRL\Thread1.1\Web\images`.
@ -23,8 +17,7 @@ Alternatively, platform developers may follow the instructions below to add a ne
3. Copy "OpenThread.py" to `C:GRL\Thread1.1\Thread_Harness\THCI`.
4. Connect the DUT (Device Under Test), a sniffer, and CC2538DK (or other hardware running OpenThread, as the reference device)
to the Host PC.
4. Connect the DUT (Device Under Test), a sniffer, and CC2538DK (or other hardware running OpenThread, as the reference device) to the Host PC.
5. Launch the Thread Test Harness Software, modify the default configuration if needed, and select **Start**.
@ -32,8 +25,7 @@ Alternatively, platform developers may follow the instructions below to add a ne
7. Select one or more test cases to execute.
## OpenThread WpanCtl Environment Setup ##
## OpenThread WpanCtl Environment Setup
1. Copy "OpenThread_WpanCtl.png" to `C:\GRL\Thread1.1\Web\images`.
@ -43,14 +35,11 @@ Alternatively, platform developers may follow the instructions below to add a ne
4. Connect the NCP board (nRF52840) to the Raspberry Pi's USB port and verify that the `wpanctl` command works.
5. Connect the Raspberry Pi's GPIOs (for Raspberry Pi 3B, link Pin8 as TXD, Pin10 as RXD, and Pin14 as GND) with
a UART2USB adapter.
5. Connect the Raspberry Pi's GPIOs (for Raspberry Pi 3B, link Pin8 as TXD, Pin10 as RXD, and Pin14 as GND) with a UART2USB adapter.
6. Connect the DUT (with Step 5's adapter), sniffer, and other golden devices (as reference devices) to the Host PC.
7. Get the DUT serial port hardware identifier and add a new platform group named OpenThread_WpanCtl in
`C:\GRL\Thread1.1\Config\Configuration.ini`. See https://openthread.io/certification/automation-setup#acting_as_a_new_reference_platform
for more information.
7. Get the DUT serial port hardware identifier and add a new platform group named OpenThread_WpanCtl in `C:\GRL\Thread1.1\Config\Configuration.ini`. See https://openthread.io/certification/automation-setup#acting_as_a_new_reference_platform for more information.
8. Launch the Thread Test Harness Software, modify the default configuration if needed, and select **Start**.
@ -58,10 +47,7 @@ Alternatively, platform developers may follow the instructions below to add a ne
10. Select one or more test cases to execute.
The above is for the serial connection mode between the DUT and the Host PC. The ssh connection mode is
also supported for OpenThread WpanCtl, but it can not be auto-discovered and only can be used via ‘Drag and Add’ way
in the ‘Configure Test Bed’ Page of Test Harness. The configuration is as following:
The above is for the serial connection mode between the DUT and the Host PC. The ssh connection mode is also supported for OpenThread WpanCtl, but it can not be auto-discovered and only can be used via ‘Drag and Add’ way in the ‘Configure Test Bed’ Page of Test Harness. The configuration is as following:
1. Make Raspberry Pi and Host PC in the same LAN.
@ -71,20 +57,12 @@ in the ‘Configure Test Bed’ Page of Test Harness. The configuration is as fo
4. Copy "OpenThread_WpanCtl.png" to `C:\GRL\Thread1.1\Web\images`.
5. Modify the Device section "forParam" values referring to the following indication then
Copy "deviceInputFields.xml" to `C:\GRL\Thread1.1\Web\data`.
TelnetIP : device's IP address
Param5 : 'ip' for SSH login
Param6 : SSH username
Param7 : SSH password
Param8 : comma separated CLI prompt, Wpan command prefix, Wpan interface
Param9 : comma separated device's setting commands before test
5. Modify the Device section "forParam" values referring to the following indication then Copy "deviceInputFields.xml" to `C:\GRL\Thread1.1\Web\data`. TelnetIP : device's IP address Param5 : 'ip' for SSH login Param6 : SSH username Param7 : SSH password Param8 : comma separated CLI prompt, Wpan command prefix, Wpan interface Param9 : comma separated device's setting commands before test
6. Copy "OpenThread_WpanCtl.py" to `C:\GRL\Thread1.1\Thread_Harness\THCI`.
7. Launch the Thread Test Harness Software, modify the default configuration if needed, and select **Start**.
8. Drag the "OpenThread_WpanCtl: Wpantund + NCP (SSH)" reference device to the **Test Bed** section with the desired number.
Then fill in the Raspberry Pi IPv4 address and port and click `connect` icon button to get the NCP version.
8. Drag the "OpenThread_WpanCtl: Wpantund + NCP (SSH)" reference device to the **Test Bed** section with the desired number. Then fill in the Raspberry Pi IPv4 address and port and click `connect` icon button to get the NCP version.
9. Select one or more test cases to execute.

91
tools/spi-hdlc-adapter/README.md
View File

@ -1,93 +1,52 @@
SPI/HDLC Adapter
================
# SPI/HDLC Adapter
`spi-hdlc-adapter` is an adapter tool for using a SPI interface as if
it were an HDLC-lite encoded bidirectional asynchronous serial stream.
It uses the SPI protocol outlined in [Appendix A.2][1] of the Spinel
protocol document.
`spi-hdlc-adapter` is an adapter tool for using a SPI interface as if it were an HDLC-lite encoded bidirectional asynchronous serial stream. It uses the SPI protocol outlined in [Appendix A.2][1] of the Spinel protocol document.
[1]: https://goo.gl/gt18O4
## Syntax ##
## Syntax
spi-hdlc-adapter [options] <spi-device-path>
## Options ##
## Options
* `--stdio`: Use `stdin` and `stdout` for HDLC input/output. Useful
when directly started by the program that will be using it.
* `--pty`: Create a pseudo terminal for HDLC input/output. The path
of the newly-created PTY will be written to `stdout`, followed by
a newline.
* `--raw`: Do not encode/decode packets using HDLC. Instead, write
whole, raw frames to the specified input and output FDs. This is
useful for emulating a serial port, or when datagram-based sockets
are supplied for `stdin` and `stdout` (when used with `--stdio`).
* `--mtu=[MTU]`: Specify the MTU. Currently only used in raw mode.
Default and maximum value is 2043. Must be greater than zero.
* `--gpio-int[=gpio-path]`: Specify a path to the Linux
sysfs-exported GPIO directory for the `I̅N̅T̅` pin. If not
specified, `spi-hdlc-adapter` will fall back to polling, which is
inefficient.
* `--gpio-reset[=gpio-path]`: Specify a path to the Linux
sysfs-exported GPIO directory for the `R̅E̅S̅` pin.
* `--spi-mode[=mode]`: Specify the SPI mode to use (0-3). Default
value is `0`.
* `--spi-speed[=hertz]`: Specify the SPI speed in hertz. Default
value is `1000000` (1MHz).
* `--spi-cs-delay[=usec]`: Specify the delay after C̅S̅ assertion,
in microseconds. Default is 20µs. Note that this may need to be
set to zero for spi-hdlc-adapter to work with some SPI drivers.
* `--spi-align-allowance[=n]`: Specify the maximum number of 0xFF
bytes to clip from start of MISO frame. This makes this tool usable
with SPI slaves which have buggy SPI blocks that prepend a variable
number of 0xFF bytes to the start of MISO frame. Default value is `0`.
Maximum value is `16`. *This should be set to `7` for chips in the
SiLabs EM35x family.*
* `--spi-small-packet=[n]`: Specify the smallest packet we can receive
in a single SPI transaction. Packets sent by the slave which are smaller
than or equal to this size will require only a single SPI transaction
to be successfully transmitted. Increasing this value will (up to a point)
decrease latency for smaller packets at the expense of overall bandwidth.
Default value is 32. The minimum value is 0. The maximum value is 2043.
* `--verbose[=num]`: Change log verbosity level (Repeatable).
num argument is optional and value 1 is default when not specified. Every
instance of this option will increment or decrement (when num is negative)
the syslog log level accordingly. Starting log level is LOG_NOTICE (5).
* `--help`: Print out usage information to `stdout` and exit.
- `--stdio`: Use `stdin` and `stdout` for HDLC input/output. Useful when directly started by the program that will be using it.
- `--pty`: Create a pseudo terminal for HDLC input/output. The path of the newly-created PTY will be written to `stdout`, followed by a newline.
- `--raw`: Do not encode/decode packets using HDLC. Instead, write whole, raw frames to the specified input and output FDs. This is useful for emulating a serial port, or when datagram-based sockets are supplied for `stdin` and `stdout` (when used with `--stdio`).
- `--mtu=[MTU]`: Specify the MTU. Currently only used in raw mode. Default and maximum value is 2043. Must be greater than zero.
- `--gpio-int[=gpio-path]`: Specify a path to the Linux sysfs-exported GPIO directory for the `I̅N̅T̅` pin. If not specified, `spi-hdlc-adapter` will fall back to polling, which is inefficient.
- `--gpio-reset[=gpio-path]`: Specify a path to the Linux sysfs-exported GPIO directory for the `R̅E̅S̅` pin.
- `--spi-mode[=mode]`: Specify the SPI mode to use (0-3). Default value is `0`.
- `--spi-speed[=hertz]`: Specify the SPI speed in hertz. Default value is `1000000` (1MHz).
- `--spi-cs-delay[=usec]`: Specify the delay after C̅S̅ assertion, in microseconds. Default is 20µs. Note that this may need to be set to zero for spi-hdlc-adapter to work with some SPI drivers.
- `--spi-align-allowance[=n]`: Specify the maximum number of 0xFF bytes to clip from start of MISO frame. This makes this tool usable with SPI slaves which have buggy SPI blocks that prepend a variable number of 0xFF bytes to the start of MISO frame. Default value is `0`. Maximum value is `16`. _This should be set to `7` for chips in the SiLabs EM35x family._
- `--spi-small-packet=[n]`: Specify the smallest packet we can receive in a single SPI transaction. Packets sent by the slave which are smaller than or equal to this size will require only a single SPI transaction to be successfully transmitted. Increasing this value will (up to a point) decrease latency for smaller packets at the expense of overall bandwidth. Default value is 32. The minimum value is 0. The maximum value is 2043.
- `--verbose[=num]`: Change log verbosity level (Repeatable). num argument is optional and value 1 is default when not specified. Every instance of this option will increment or decrement (when num is negative) the syslog log level accordingly. Starting log level is LOG_NOTICE (5).
- `--help`: Print out usage information to `stdout` and exit.
`spi-device-path` is a required argument since it indicates which SPI
device to use. An example path might be `/dev/spidev1.0`.
`spi-device-path` is a required argument since it indicates which SPI device to use. An example path might be `/dev/spidev1.0`.
The GPIO paths are to the top-level directory for that GPIO. They must
be already be exported before `spi-hdlc-adapter` can use them.
The GPIO paths are to the top-level directory for that GPIO. They must be already be exported before `spi-hdlc-adapter` can use them.
## Behavior ##
## Behavior
If an MCU reset is detected by the reset bit being set on a SPI frame,
the special vendor-specific HDLC-lite symbol `0xF8` is emitted. If
`--gpio-reset` is specified, the HDLC client can trigger an MCU reset
by sending the symbols `0x7E 0x13 0x11 0x7E` or by sending `SIGUSR1`.
If an MCU reset is detected by the reset bit being set on a SPI frame, the special vendor-specific HDLC-lite symbol `0xF8` is emitted. If `--gpio-reset` is specified, the HDLC client can trigger an MCU reset by sending the symbols `0x7E 0x13 0x11 0x7E` or by sending `SIGUSR1`.
When started, `spi-hdlc-adapter` will configure the following
properties on the GPIOs:
When started, `spi-hdlc-adapter` will configure the following properties on the GPIOs:
1. Set `I̅N̅T̅/direction` to `in`.
2. Set `I̅N̅T̅/edge` to `falling`.
3. Set `R̅E̅S̅/direction` to `high`.
When resetting the slave device, `spi-hdlc` performs the following
procedure:
When resetting the slave device, `spi-hdlc` performs the following procedure:
1. Set `R̅E̅S̅/direction` to `low`.
2. Sleep for 30ms.
3. Set `R̅E̅S̅/direction` to `high`.
## Statistics ##
## Statistics
Some simple usage statistics are printed out to syslog at exit and
whenever the `SIGUSR1` signal is received. The easiest way to send
that signal to `spi-hdlc-adapter` is like this:
Some simple usage statistics are printed out to syslog at exit and whenever the `SIGUSR1` signal is received. The easiest way to send that signal to `spi-hdlc-adapter` is like this:
# killall -sigusr1 spi-hdlc-adapter