This commit new configuration option `enable-multiple-instances` and its corresponding option `OPENTHREAD_ENABLE_MULTIPLE_INSTANCES`. When enabled OpenThread supports handling of multiple instances. By default this is disabled. This commit also adds two optimizations for single instance case to simplify the code and also help reduce memory/RAM usage: (1) OpenThread objects/classes typically keep a reference to a higher level object (e.g., many classes keep track of owning `ThreadNetif`) to be able to access other objects/methods within OpenThread class hierarchy. In single instance mode, the reference member variables are removed and instead global functions are used to access the singleton objects from one class to the other. To implement this, a group of `<Object>Locator` classes are defined (e.g., `ThreadNetifLocator`, etc.) which are then used as base class of other OpenThread classes. (2) OpenThread objects which provide a callback/handler (e.g., `Timer`, `Tasklet`, etc.) have `void *mContext` member variable which is used to keep track of the owner of the object. In single instance mode the `mConext` member variables are removed since the owner is expected to be a singleton and can be uniquely determined from the callback function. To implement this, two changes are made: First the handler methods are modified to provide a reference to the object (e.g., `Timer` handler will provide a `Timer &aTimer` as a parameter of its handler callback). Second, a new base class `Context` is introduced which hides the implementation providing an arbitrary context information. A new static method `GetOwner(aContext)` is added to classes which own a callback providing objects. This method help convert a `Context` to the reference of the owner class object.
OpenThread CLI Example
This example application demonstrates a minimal OpenThread application that exposes the OpenThread configuration and management interfaces via a basic command-line interface. The steps below take you through the minimal steps required to ping one emulated Thread device from another emulated Thread device.
1. Build
$ cd <path-to-openthread>
$ ./bootstrap
$ make -f examples/Makefile-posix
2. Start node 1
Spawn the process:
$ cd <path-to-openthread>/output/<platform>/bin
$ ./ot-cli-ftd 1
Set the PAN ID:
> panid 0x1234
Bring up the IPv6 interface:
> ifconfig up
Done
Start Thread protocol operation:
> thread start
Done
Wait a few seconds and verify that the device has become a Thread Leader:
> state
leader
Done
View IPv6 addresses assigned to Node 1's Thread interface:
> ipaddr
fdde:ad00:beef:0:0:ff:fe00:0
fdde:ad00:beef:0:558:f56b:d688:799
fe80:0:0:0:f3d9:2a82:c8d8:fe43
Done
2. Start node 2
Spawn the process:
$ cd <path-to-openthread>/output/<platform>/bin
$ ./ot-cli-ftd 2
Set the PAN ID:
> panid 0x1234
Bring up the IPv6 interface:
> ifconfig up
Done
Start Thread protocol operation:
> thread start
Done
Wait a few seconds and verify that the device has become a Thread Router:
> state
router
Done
3. Ping Node 1 from Node 2
> ping fdde:ad00:beef:0:558:f56b:d688:799
16 bytes from fdde:ad00:beef:0:558:f56b:d688:799: icmp_seq=1 hlim=64
4. Want more?
You may note that the example above did not include any network parameter configuration, such as the IEEE 802.15.4 PAN ID or the Thread Master Key. OpenThread currently implements default values for network parameters, however, you may use the CLI to change network parameters, other configurations, and perform other operations.
See the OpenThread CLI Reference README.md to explore more.