The leds API did not work in some cases. E.g. with the following sequence:
leds_off(LEDS_ALL);
leds_toggle(LEDS_GREEN);
leds_off(LEDS_ALL);
the green LED was remaining on after the last call.
This was caused by the toggle feature made synonymous with the invert feature,
although it is unrelated. leds_toggle() is indeed supposed to toggle an LED,
while leds_invert() is supposed to change the active level of an LED. However,
all users of leds_invert() actually meant leds_toggle(), and the invert feature
does not make sense in this module because it is not handy due to successive
calls to leds_invert() changing the intended behavior, and hardware active
levels should be managed in leds_arch_set() (e.g. by XORing the passed value
with a hardware-specific constant before setting the output levels of the pins).
Consequently, this change:
- removes the leds_invert() function,
- makes leds_toggle() behave as expected relatively to leds_off() / leds_on(),
- sanitizes the code in the leds module.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
According to IEEE 802.15.4e (§6.4.3.9), in order to detect duplicate received
MAC-layer frames, only the most recently received frame's sequence number needs
to be stored for each unique device address. Doing so limits the possible false
duplicate packet detections to a single sequence number. This also allows to
keep the last sequence number of more device addresses for the same value of
MAX_SEQNOS.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The code detecting duplicate packets in the RDC layer had been copied into most
RDC implementations. Factor it out into a new mac-sequence module in order to
have a single instance of this code.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
According to IEEE 802.15.4 (§5.1.6.1, §6.4.2), the MAC sequence numbers should
be initialized to random values. This was already the case in
framer-802154.c:create(), but not in csma.c:send_packet(), sometimes causing
false detections of duplicate MAC-layer packets in other devices when a device
was restarted too quickly. This patch decreases the probability of such an
event.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
* Mesh: this is the normal case. Nodes route data on behalf of others and the node can be reached via a DAO route.
* Leaf: the node does not route data on behalf of others, but others can route data to the node (it has a RPL DAO route).
* Feather: this is a new type of node. A feather node routes data on behalf of others, but does not install DAO routes in the network. Feather nodes allow having a larger number of nodes than the RPL network can sustain in terms of routing tables.
This commit introduces the RPL node types and the feather mode, but does not add support for the leaf node type.
* Added a DAO lifetime timer that sends out a new DAO after half the lifetime of the DAO. This allows implementing DAO route soft state that avoids routing tables in the network keeping stale routes for ever.
* Added ways to schedule a new DAO transmission as well as cancelling an active DAO transmit timer, which makes it possible to do nodes that don't send DAOs.
