Skip to content

Commit

Permalink
Merged in merlin17/apps (pull request apache#109)
Browse files Browse the repository at this point in the history
i8sak: Updates README to include details about socket interface and new addressing setup and fixes warning

* i8sak: Updates README to include details about socket interface and new addressing setup

* i8sak: Fixes warning about unitintialized variable

Approved-by: Gregory Nutt <gnutt@nuttx.org>
  • Loading branch information
antmerlino authored and gregory-nutt committed Sep 15, 2017
1 parent c9bd210 commit 43e3da9
Show file tree
Hide file tree
Showing 2 changed files with 35 additions and 20 deletions.
53 changes: 34 additions & 19 deletions wireless/ieee802154/i8sak/README.txt
Original file line number Diff line number Diff line change
Expand Up @@ -8,12 +8,20 @@ It also serves as a starting place for learning how to interface with the
NuttX IEEE 802.15.4 MAC layer.

The i8sak CLI can be used to manipulate multiple MAC layer networks at once.
IEEE 802.15.4 MAC character drivers show up in NuttX as /dev/ieeeN by default.
When you invoke the first call to i8sak with a specified devname, it creates
Both a MAC character driver interface and a network interface using sockets
are supported. The MAC character driver is used in cases where networking is
not enabled and you want your application to use IEEE 802.15.4 directly. In
most cases however, you will probably be using 6LoWPAN networking support and
therefore, the MAC can be controlled directly from the socket interface rather
than the MAC character driver. IEEE 802.15.4 MAC character drivers show up in
NuttX as /dev/ieeeN by default.

When you invoke the first call to i8sak with a specified interface name, it creates
an i8sak instance and launches a deamon to handle processing work. The instance
is considered sticky, so it is possible to run `i8 /dev/ieee0` at the beginning
of a session and then can exclude the devname from all future calls. The number
of i8sak instances supported is controllable through menuconfig.
is considered sticky, so it is possible to run `i8 /dev/ieee0` or 'i8 wpan0' at
the beginning of a session and then can exclude the interface name from all
future calls. The number of i8sak instances supported is controllable through
menuconfig.

The i8sak app has many settings that can be configured. Most options are "sticky",
meaning, if you set the endpoint short address once, any future operation using
Expand All @@ -31,13 +39,11 @@ We'll refer to that as device A.

On that device, run:
```
i8 /dev/ieee0 startpan
i8 /dev/ieee0 startpan cd:ab
```
For now, this function assumes that we are operating a non-beacon enabled PAN,
since, as of this writing, beacon-enabled networks are unfinished. Unless you
have previously overriden address settings, the startpan command will also
configure the devices address to be that of CONFIG_I8SAK_PANCOORD_XXX. It
will then set the endpoint to be the CONFIG_I8SAK_DEV_XXX address.
This will tell the MAC layer that it should now act as a PAN coordinator using
PAN ID CD:AB. For now, this function assumes that we are operating a non-beacon
enabled PAN, since, as of this writing, beacon-enabled networks are unfinished.

Next, on the same device, run:
```
Expand All @@ -53,29 +59,26 @@ accept requests from a single device by specifying the extended address with opt
-e.

For instance:
```

i8 acceptassoc -e DEADBEEF00FADE0B
```

But for this example, let's just use the command with no arguments.

Now, the second device will act as an endpoint device. The i8sak instance defaults
to being in endpoint mode. Let's refer to the second device as device B.

On device B, run:
```

i8 /dev/ieee0 assoc
```
This command without any options defaults the endpoint address to the default
PANCOORD address settings, and sends an association request to that device.

This command attempts to associate with the node at the configured endpoint address.
If everything is setup correctly, device A should have log information saying
that a device tried to associate and that it accepted the assocation. On device
B, the console should show that the association request was successful. With all
default settings, device B should have been allocated a short address of 0x000B.

If you are following along with a packet sniffer, you should see the following
transactions:
If you are following along with a packet sniffer, you should see something
similar to the following:

1) Association Request
Frame Type - CMD
Expand Down Expand Up @@ -118,6 +121,18 @@ transactions:
Sequence Number - 0


The default endpoint address can be configured via Kconfig or set dynamically
using the 'set' command.

Here is how to set the endpoint short address

i8 set ep_saddr 0a:00

When setting the address, it's important to make sure the endpoint addressing
mode is configured the way you want: Use 's' for short addressing or 'e' for extended

i8 set ep_addrmode s

Device B has now successfully associated with device A. If you want to send data
from device B to device A, run the following on device B:
```
Expand Down
2 changes: 1 addition & 1 deletion wireless/ieee802154/i8sak/i8sak_events.c
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,7 @@ static pthread_addr_t i8sak_eventthread(pthread_addr_t arg)
struct ieee802154_netmac_s netarg;
#endif
FAR struct i8sak_eventreceiver_s *receiver;
FAR struct ieee802154_notif_s *notif;
FAR struct ieee802154_notif_s *notif = NULL;
int ret;

if (i8sak->mode == I8SAK_MODE_CHAR)
Expand Down

0 comments on commit 43e3da9

Please sign in to comment.