2017-09-15 16:37:55 +02:00
|
|
|
#
|
|
|
|
|
# For a description of the syntax of this configuration file,
|
|
|
|
|
# see the file kconfig-language.txt in the NuttX tools repository.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
if IEEE802154_XBEE
|
|
|
|
|
|
2019-08-20 00:24:32 +02:00
|
|
|
config XBEE_DEFAULT_PREFIX_0
|
|
|
|
|
hex "IPv6 Prefix 0"
|
|
|
|
|
default 0xfe80
|
|
|
|
|
---help---
|
|
|
|
|
First section of IPv6 Prefix
|
|
|
|
|
|
|
|
|
|
config XBEE_DEFAULT_PREFIX_1
|
|
|
|
|
hex "IPv6 Prefix 1"
|
|
|
|
|
default 0x0000
|
|
|
|
|
---help---
|
|
|
|
|
Second section of IPv6 Prefix
|
|
|
|
|
|
|
|
|
|
config XBEE_DEFAULT_PREFIX_2
|
|
|
|
|
hex "IPv6 Prefix 2"
|
|
|
|
|
default 0x0000
|
|
|
|
|
---help---
|
|
|
|
|
Third section of IPv6 Prefix
|
|
|
|
|
|
|
|
|
|
config XBEE_DEFAULT_PREFIX_3
|
|
|
|
|
hex "IPv6 Prefix 3"
|
|
|
|
|
default 0x0000
|
|
|
|
|
---help---
|
|
|
|
|
Fourth section of IPv6 Prefix
|
|
|
|
|
|
2017-09-15 16:37:55 +02:00
|
|
|
config IEEE802154_XBEE_FREQUENCY
|
|
|
|
|
int "SPI Frequency for XBee Radio"
|
|
|
|
|
default 2000000
|
|
|
|
|
---help---
|
|
|
|
|
SPI SLCK frequency in Hz
|
|
|
|
|
|
2017-11-01 21:15:21 +01:00
|
|
|
config XBEE_NETDEV_RECVRPRIO
|
2020-02-23 09:50:23 +01:00
|
|
|
int "Priority of frame receiver registered with the MAC layer"
|
2017-11-01 21:15:21 +01:00
|
|
|
default 1
|
2017-09-15 16:37:55 +02:00
|
|
|
---help---
|
2017-11-01 21:15:21 +01:00
|
|
|
When the MAC layer receives an incoming data frame, it passes the frame
|
|
|
|
|
to registered receivers, in order of receiver priority, until one of the
|
|
|
|
|
receivers claim the frame.
|
2017-09-15 16:37:55 +02:00
|
|
|
|
2017-11-01 21:15:21 +01:00
|
|
|
An example case would be when 6LoWPAN and the MAC character driver are
|
|
|
|
|
enabled. Both have receivers registered with the MAC. The 6LoWPAN layer
|
|
|
|
|
should get assigned a higher priority than the character driver. In this
|
|
|
|
|
case, the 6LoWPAN receiver will receive the frame first. If the frame is
|
|
|
|
|
a 6LoWPAN frame, it will claim the frame and the MAC will not pass the
|
|
|
|
|
frame to any additional receivers. If it does not claim the frame, the
|
|
|
|
|
MAC layer will call the next highest priority receiver, in this case,
|
|
|
|
|
the MAC character driver (which should always be lowest priority since
|
|
|
|
|
it is a "catch-all" type receiver).
|
2017-09-15 16:37:55 +02:00
|
|
|
|
2019-01-10 09:13:52 +01:00
|
|
|
config XBEE_LOCKUP_WORKAROUND
|
|
|
|
|
bool "Enable workaround to counteract XBee lockup"
|
|
|
|
|
default y
|
|
|
|
|
---help---
|
|
|
|
|
When receiving large amounts of data over the XBee, there is some probability
|
|
|
|
|
that the XBee will lockup and stop sending us data over SPI. In most cases,
|
|
|
|
|
querying the XBee will get it out of this state and communication will resume.
|
|
|
|
|
In some cases however, the XBee will freeze completely and won't ever respond
|
|
|
|
|
to our queries.
|
|
|
|
|
|
|
|
|
|
This workaround periodically queries the XBee if there hasn't been any
|
|
|
|
|
recent interaction. Additionally, if any query does not get a response
|
|
|
|
|
after 10 attempts, the XBee is reset.
|
|
|
|
|
|
2017-09-15 16:37:55 +02:00
|
|
|
endif # IEEE802154_XBEE
|
