-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Link layer interfaces #460
Conversation
@authmillenon let's put the discussion about this multiplexer in the next year. |
It was not meant for this release anyways ;-) |
No longer WIP. Test project is des-testbed/RIOT-projects#84 |
Added some more functions and make shell commands (untested) |
Again WIP! |
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
style changes in own commit |
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
Again no longer WIP |
Known issue: build test fails for all boards where I don't know the transceiver. |
How about implementing #432 |
The problem is that the modules for the radio drivers are not added in the makefile ;) so your proposal would not work either (i'm technically doing this in auto_init) |
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
Your answer is due to a lack of creativity when reading the issue ;-) Let's discuss this over at that issue. |
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
Rebased and changing NET_IF_L3P_ a bit. |
mesg.content.ptr = (char *) &tcmd; | ||
|
||
if (argc > 1) { | ||
a = atoll(argv[1]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RIOT/sys/shell/commands/sc_transceiver.c:100: undefined reference to atoll'
on MSP-430 platforms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
On MSB-A2 and examples/default
Rest seems to work fine. |
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
|
@@ -0,0 +1,50 @@ | |||
#### |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obsolete style test Makefile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not good enough - have a look at the other test Makefiles, or this: #759
For msp-430:
I guess this needs an |
Not part of this PR, but here is the fix: #808. |
Wouldn't it make more sense to have this as a part of this PR (and squashed into one of it's commits) to avoid non-compilable revisons (which are nasty for |
Or we merge #808 first... ;) |
merge #808 first ;-) |
int iface = net_if_init_interface(0, transceivers); | ||
|
||
if (iface >= 0) { | ||
DEBUG("Interface %d initialized\n", iface) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
; missing
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
Apart from the missing Ready to be merged in my eyes. |
(Don't forget: without #644 the IoT network stack won't work) |
Thanks for the reminder. I'll try to review the other two PRs today and would suggest to merge them within a short time frame. |
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
@OlegHahm please comment on file changes, not on commits ;-) |
@@ -102,3 +102,15 @@ ifneq (,$(filter vtimer,$(USEMODULE))) | |||
USEMODULE += timex | |||
endif | |||
endif | |||
|
|||
ifneq (,$(findstring net_if,$(USEMODULE))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use filter instead
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
|
||
export INCLUDES += -I$(RIOTBASE)/sys/net/include | ||
|
||
ifeq ($(BOARD),msba2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is superfluous.
IEEE 802.15.4 has two addressing modes: 16-bit short and the device's EUI-64. Currently RIOT supports only sending of packets with 16-bit short addresses via the transceiver interface. This patch allows at least for the radio chips that support IEEE 802.15.4 to let the application/upper layer decide which addressing mode to use. Upper layer implementation will be implemented in follow-up PR to RIOT-OS#460
Currently every module above link layer defines their ways to communicate with the transceivers. This results e. g. that the sixlowpan module to this day basically just speaks to cc1100 (and if not, it treets the transceiver like one). To abstract from this I introduced an interface layer similar to the network interfaces in unixoid operating systems. It is basically a wrapper for the transceiver module, with the capability to associate certain upper layer addresses with the a transceiver.