nuttx/drivers/wireless/ieee802154/xbee/Kconfig
Xiang Xiao cde88cabcc Run codespell -w with the latest dictonary again
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
2020-02-23 22:27:46 +01:00

71 lines
2.2 KiB
Plaintext

#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#
if IEEE802154_XBEE
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
config IEEE802154_XBEE_FREQUENCY
int "SPI Frequency for XBee Radio"
default 2000000
---help---
SPI SLCK frequency in Hz
config XBEE_NETDEV_RECVRPRIO
int "Priority of frame receiver registered with the MAC layer"
default 1
---help---
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.
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).
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.
endif # IEEE802154_XBEE