Nanostack configuration options added #396
Conversation
|
|
||
| To minimize the size of the produced stack, Nanostack defines a set of build options. | ||
| The build time configuration of Nanostack uses the Mbed configuration system. The application needs to create an `mbed_app.json` configuration file if you want to use settings other than default settings. You can also minimize the size of the produced stack by using different build options. | ||
|
|
||
| #### Build options |
There was a problem hiding this comment.
The below table shows binary size in Mbed OS 5.5. Because we're going into 5.8, should we update the table, or is it OK as is?
There was a problem hiding this comment.
Could we just mention something like ->
The binary sizes in the table are just for showing the difference between different builds.
| @@ -33,7 +33,7 @@ Select the device role: | |||
| - Mesh network. A router. (default) | |||
| - Star network. A non-routing device. Also known as a host, or sleepy host. | |||
|
|
|||
| Modify your `mbed_app.json` file to tell which Nanostack configuration to choose and which configrations to use on [Mbed Mesh API](/docs/v5.6/reference/mesh.html). | |||
| Modify your `mbed_app.json` file to direct which Nanostack configuration to choose. The [Mbed Mesh API](https://github.com/ARMmbed/mbed-os/blob/master/features/nanostack/FEATURE_NANOSTACK/mbed-mesh-api/mbed_lib.json) lists all configurations (6LoWPAN and Thread). | |||
There was a problem hiding this comment.
We don't like to link to GitHub. Ideally, the code for the mesh API would be fixed and merged, and we'd link to the generated Doxygen for it.
| @@ -74,3 +74,47 @@ Then you may optionally choose to select the non-routing mode for those networks | |||
| |Mesh router (default) | `thread_router` | `MESH_DEVICE_TYPE_THREAD_ROUTER` | | |||
| |Non-routing device | `thread_end_device` | `MESH_DEVICE_TYPE_THREAD_SLEEPY_END_DEVICE` | | |||
|
|
|||
| ##### Configuration parameters for 6LoWPAN-ND and Thread | |||
There was a problem hiding this comment.
We have a PR to move configuration content to the configuration section: #366
Could you please update that PR with this content in the format of the other sections?
There was a problem hiding this comment.
That might be ok, need to have a link pointing to the configuration page. Though I like the current table format, for me it is more readable.
Minor edits
Make minor copy edits for active voice and formatting.
kseverinkangas-zg
force-pushed
the
new_engine
branch
from
17b5e9f to
9442d33
Compare
Make minor formatting and style changes.
Copy edit file for active voice.
Add line to explain the table based on comments.
| @@ -55,6 +57,8 @@ Once you have completed the details, proceed to generate the QR code for your en | |||
|
|
|||
| #### Using the Thread commissioning application | |||
|
|
|||
| When building a Thread example application, do not change any of the PSKc related parameters (network name, extended PAN ID or PSKc). PSKc has been precalculated for the application. The nanostack has no capability to generate PSKc on runtime. | |||
There was a problem hiding this comment.
no one has it is not limitation of nanostack but universe. only the one who knows the actual password can calculate those values
There was a problem hiding this comment.
So maybe better to remove this sentence -> The nanostack has no capability to generate PSKc on runtime. Should it be also here mentioned that we have used the "Thread Network" as a passwd?
There was a problem hiding this comment.
yes that is the most important information for the user. "
"Thread Network" is the network password that is required by commissioning application"
Something like that
Point to new engine branch.
Update README instructions.
|
|
||
| Thread router devices require more RAM/ROM memory than end devices. How much RAM memory the device needs depends on the size of the network and how big and many packets need to be buffered. | ||
|
|
||
| The recommended heap values: |
There was a problem hiding this comment.
Are these memory figures actually minimum values? How about other device types?
|
|
||
| The panid can be used to identify each network, but the only way to ensure that each Thread network stays in its own partition is to have different master key for each network. | ||
|
|
||
| The Thread network channel may be different for each network to avoid some unnecessary packet processing (if the networks can hear each other). |
|
|
||
| Also it is possible to define the number of packets that can be buffered in the parent device. | ||
| If end nodes are running cloud client, that sets requirements for the parent device to buffer the messages during the handshake. By default the router device has 10 message buffer size to support the cloud client requirements. | ||
| Note, that if many end nodes start the cloud client in the same time that may lead to the packet drops. And increasing the buffer size requires more nanostack heap (RAM). |
There was a problem hiding this comment.
Could this sentence be rephrased somehow?
| Note, that if many end nodes start the cloud client in the same time that may lead to the packet drops. And increasing the buffer size requires more nanostack heap (RAM). | ||
|
|
||
| Application can use the nanostack net_interface.h API and the function `arm_nwk_sleepy_device_parent_buffer_size_set` to adjust the buffer size for the router (parent) devices. | ||
| The API will require interface_id that can be read by using MeshInterfaceNanostack interface and the function get_interface_id(). |
There was a problem hiding this comment.
Please add ticks around function names
| - `"thread-config-channel": 22,` | ||
|
|
||
| For the devices to be commissioned, the only thing needed is PSKd and eui64. | ||
| Both values can be set by using ThreadInterface.h. Alternatively PSKd can be configured in .json: |
| - Thread SED: 16kb | ||
|
|
||
| Also it is possible to define the number of packets that can be buffered in the parent device. | ||
| If end nodes are running cloud client, that sets requirements for the parent device to buffer the messages during the handshake. By default the router device has 10 message buffer size to support the cloud client requirements. |
Copy edit file for active voice, branding and consistent capitalization, as well as other minor grammar fixes.
| @@ -36,14 +36,16 @@ Mbed Thread is implemented in the Nanostack library, which also supports the 6Lo | |||
| - To connect to the Thread network, use the [Thread interface API](https://github.com/ARMmbed/mbed-os/blob/master/features/nanostack/FEATURE_NANOSTACK/mbed-mesh-api/mbed-mesh-api/ThreadInterface.h). | |||
| - For the socket communication over the Thread network, use the [Mbed sockets API](/docs/v5.7/reference/network-socket.html). | |||
|
|
|||
| Nanostack provides a set of C API headers with more functionalities. The [nanostack repository](https://github.com/ARMmbed/mbed-os/tree/master/features/nanostack/FEATURE_NANOSTACK/sal-stack-nanostack/nanostack) has the following header files(): | |||
| Nanostack provides a set of C API headers with more functionalities. The [Nanostack repository](https://github.com/ARMmbed/mbed-os/tree/master/features/nanostack/FEATURE_NANOSTACK/sal-stack-nanostack/nanostack) has the following header files(): | |||
There was a problem hiding this comment.
We don't like to link to GitHub. Is there a Doxygen page to which we could link instead?
There was a problem hiding this comment.
Yes, a doxygen page would be better when they are available
|
|
||
| For an end device or a router example, see [mesh minimal example](https://github.com/ARMmbed/mbed-os-example-mesh-minimal). | ||
| For an end device or a router example, see the [mesh minimal example](https://github.com/ARMmbed/mbed-os-example-mesh-minimal). |
There was a problem hiding this comment.
We don't like to link to GitHub. Is there a Doxygen page or teams example to which we could link instead?
There was a problem hiding this comment.
In this case no there isn't.
|
|
||
| Also, it is possible to define the number of packets that can be buffered in the parent device. | ||
|
|
||
| If Thread end nodes are running Mbed Cloud Client, that sets requirements for the parent device to buffer the messages during the handshake. By default, the router device has 10 message buffer size to support the Mbed Cloud Client requirements. Note that if many end nodes start the Mbed Cloud Client at the same time, it may lead to the packet drops in the parent device. |
There was a problem hiding this comment.
Query: Does it make sense to discuss Mbed Cloud Client in this part of the Mbed OS documentation?
There was a problem hiding this comment.
They are already aware of this.
|
Closing because I think a newer PR overrides this. Please feel free to reopen if you feel this is still relevant |
Module configuration moved from the socket.
Related to ONME-3434