at86rf2xx: port to netdev2 #4646

miri64 · 2016-01-16T19:05:48Z

Ports at86rf2xx to netdev2

Depends on ~~#4645~~ (merged) and ~~#4678~~ (closed).

kaspar030 · 2016-01-18T09:05:58Z

nice!

biboc · 2016-01-20T10:18:01Z

Great job!

thomaseichinger · 2016-01-20T15:27:07Z

Please consider miri64#25 to get this into a compiling state.

miri64 · 2016-01-20T15:49:13Z

Please be aware, that this PR is still WIP!

miri64 · 2016-01-25T00:31:37Z

No more WIP and #4678 as additional dependency, but there is an issue: When I send an IEEE 802.15.4 frame from a master-build gnrc_networking the addressed node receives it just fine. However, when I send with the test application in this PR (or with gnrc_networking for that matter, too) the _irq_handler in at86rf2xx_netdev.c doesn't even fire... The packets seem to have the same format and the channel is also the same (otherwise the sniffer wouldn't receive), so I have no clue, what's going on.

Here's a dump from the situation: https://www.cloudshark.org/captures/3d0d88044e65.

0x37ba (and 5a:55:44:5c:b9:4c37:ba respectively) is the node with code from master (packets are received by tests/driver_at86rf2xx of this branch)
0x760e is the node with code from this branch (packets are not received by tests/driver_at86rf2xx of this branch [that's why there are resends in 21-24])

thomaseichinger · 2016-01-26T20:46:13Z

@authmillenon Comparing packet 19 and 21 from your dump, the byte order of the PAN id seems the other way around.

miri64 · 2016-01-26T20:47:42Z

Ah thanks! Will fix with the redo of the ieee802154 intermediate layer.

miri64 · 2016-01-28T12:27:35Z

Rebased and adapted to current version of #4645.

miri64 · 2016-01-28T12:49:37Z

drivers/at86rf2xx/at86rf2xx_getset.c

 }

 void at86rf2xx_set_pan(at86rf2xx_t *dev, uint16_t pan)
 {
-    dev->pan = pan;
+    dev->pan = byteorder_htons(pan);


This is the culprit of my previous reception problems, btw. If I assess the situation correctly the byteorder of the PAN is returned wrong on driver->get on most devices, it should be in network byte order but is in little-endian (this PR intentionally doesn't fix that, since it is not topic of this PR).
@haukepetersen @jfischer-phytec-iot @jremmert-phytec-iot @thomaseichinger can you assess the situation for kw2xrf and xbee?

isn't 802.15.4 PAN id supposed to be in little endian byte order (i.e. the opposite of "network byte order")?

Yes in the MAC header (which is the case here). I was talking about the handing of the option to the upper layers. But your comment solicited me to read the doc again and I was wrong: The PAN is supposed to be handed up in host byte order. I guess I was confused because the ifconfig config command of my implementation prints it address-like (as in "in network byte order", though it isn't). Will fix this.

Quote 802.15.4-2011 (emphasis mine):

5.2 MAC frame formats

This subclause specifies the format of the MAC frame (MPDU).
The frames in the MAC sublayer are described as a sequence of fields in a specific order. All frame formats in this subclause are depicted in the order in which they are transmitted by the PHY, from left to right, where the leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost and least significant) to k – 1 (rightmost and most significant), where the length of the field is k bits. Fields that are longer than a single octet are sent to the PHY in the order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits.

Fixed.

@gebart: I know! Again: my comment wasn't about the order in the MAC frame (this was and still is right), but in the RIOT internal representation and storing according to the documentation.

miri64 · 2016-01-28T22:32:31Z

Rebased an squashed... Hopefully for the last time :-)

miri64 · 2016-01-28T23:57:06Z

Nope, the GNRC glue code is still buggy :(

miri64 · 2016-03-16T23:23:49Z

I provided a fix in #5096. Since the bug is already in master I decided to provide the fix separately. To test please merge it in here.

miri64 · 2016-03-17T16:45:54Z

#5096 was merged so I rebased to current master again.

miri64 · 2016-03-18T08:19:23Z

ping?

miri64 · 2016-03-18T09:32:03Z

Rebased and adapted to changes from #4862

OlegHahm · 2016-03-23T16:21:59Z

drivers/at86rf2xx/at86rf2xx.c


+    netdev->driver = &at86rf2xx_driver;


Couldn't (shouldn't) this be done by the caller?

Hm, maybe not, but this casting back seems strange to me.

But I guess

dev->netdev->netdev->driver = &at86rf2xx_driver;

isn't very pretty, either.

The other netdev2s are also the setting the driver in the setup and it makes more sense to me. Why expose the driver when it other stuff needs to be set for the device too.

It was your idea to use this kind of inheritance ;P

(and I warned about the implications)

OlegHahm · 2016-03-23T16:34:04Z

I would say: ready to be squashed and let's have Murdock taking a look then.

miri64 · 2016-03-23T16:45:41Z

Squashed.

OlegHahm · 2016-03-23T20:52:16Z

I am fine with this PR, Murdock is fine, what about you, @haukepetersen?

haukepetersen · 2016-03-24T14:02:29Z

I am good

haukepetersen · 2016-03-24T14:03:03Z

so go!

OlegHahm · 2016-03-24T14:10:23Z

Yeah! Nice work, @authmillenon!

emmanuelsearch · 2016-03-24T14:15:45Z

+1 it's the beginning of a new era ;)

kYc0o · 2016-03-24T14:21:15Z

finally! :D congrats @authmillenon ;-)

miri64 · 2016-03-24T14:51:33Z

Thank you all for the review! :-)

zhuoshuguo · 2016-03-24T15:28:54Z

Congratulations！

miri64 added Area: network Area: Networking Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. State: waiting for other PR State: The PR requires another PR to be merged first Area: drivers Area: Device drivers labels Jan 16, 2016

miri64 assigned haukepetersen Jan 16, 2016

miri64 added this to the Release 2016.03 milestone Jan 16, 2016

miri64 force-pushed the at86rf2xx/api/netdev2 branch from 3cdc688 to 274318b Compare January 16, 2016 19:14

miri64 force-pushed the at86rf2xx/api/netdev2 branch 2 times, most recently from 30edbf4 to f8fc6a0 Compare January 18, 2016 20:33

Kijewski added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Jan 20, 2016

miri64 force-pushed the at86rf2xx/api/netdev2 branch 2 times, most recently from b2b5fd3 to 46724d2 Compare January 24, 2016 23:20

miri64 removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Jan 24, 2016

miri64 force-pushed the at86rf2xx/api/netdev2 branch from 46724d2 to ca0c25b Compare January 25, 2016 00:40

miri64 force-pushed the at86rf2xx/api/netdev2 branch from ca0c25b to a662561 Compare January 28, 2016 12:26

miri64 reviewed Jan 28, 2016
View reviewed changes

cgundogan mentioned this pull request Jan 28, 2016

ng_at86rf2xx: implement RAWMODE for sending. #3481

Closed

miri64 mentioned this pull request Jan 28, 2016

Test on big-endian byte order #4710

Closed

miri64 force-pushed the at86rf2xx/api/netdev2 branch 2 times, most recently from 292b1b7 to e365d66 Compare January 28, 2016 22:32

miri64 mentioned this pull request Mar 16, 2016

gnrc_netdev2: do not override res for for ieee802154 #5096

Merged

miri64 added State: waiting for other PR State: The PR requires another PR to be merged first and removed State: waiting for other PR State: The PR requires another PR to be merged first labels Mar 16, 2016

miri64 force-pushed the at86rf2xx/api/netdev2 branch from 4222a17 to 0c1b6ae Compare March 17, 2016 16:45

miri64 force-pushed the at86rf2xx/api/netdev2 branch from 0c1b6ae to 14c6ba3 Compare March 18, 2016 09:31

OlegHahm mentioned this pull request Mar 22, 2016

make: introduce netdev_default pseudomodule #5134

Merged

OlegHahm reviewed Mar 23, 2016
View reviewed changes

miri64 added 3 commits March 23, 2016 17:45

at86rf2xx: port to netdev2

5bfc9e4

auto_init: adapt autoinitialization of at86rf2xx

16e1110

tests: modify driver_at86rf2xx for pure netdev2

dff0c52

miri64 force-pushed the at86rf2xx/api/netdev2 branch from 14c6ba3 to dff0c52 Compare March 23, 2016 16:45

miri64 removed the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Mar 23, 2016

OlegHahm added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Mar 23, 2016

haukepetersen merged commit 2510fe0 into RIOT-OS:master Mar 24, 2016

miri64 deleted the at86rf2xx/api/netdev2 branch March 24, 2016 14:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

at86rf2xx: port to netdev2 #4646

at86rf2xx: port to netdev2 #4646

miri64 commented Jan 16, 2016

kaspar030 commented Jan 18, 2016

biboc commented Jan 20, 2016

thomaseichinger commented Jan 20, 2016

miri64 commented Jan 20, 2016

miri64 commented Jan 25, 2016

thomaseichinger commented Jan 26, 2016

miri64 commented Jan 26, 2016

miri64 commented Jan 28, 2016

miri64 Jan 28, 2016

jnohlgard Jan 28, 2016

miri64 Jan 28, 2016

jnohlgard Jan 28, 2016

miri64 Jan 28, 2016

miri64 commented Jan 28, 2016

miri64 commented Jan 28, 2016

miri64 commented Mar 16, 2016

miri64 commented Mar 17, 2016

miri64 commented Mar 18, 2016

miri64 commented Mar 18, 2016

OlegHahm Mar 23, 2016

OlegHahm Mar 23, 2016

OlegHahm Mar 23, 2016

miri64 Mar 23, 2016

miri64 Mar 23, 2016

OlegHahm commented Mar 23, 2016

miri64 commented Mar 23, 2016

OlegHahm commented Mar 23, 2016

haukepetersen commented Mar 24, 2016

haukepetersen commented Mar 24, 2016

OlegHahm commented Mar 24, 2016

emmanuelsearch commented Mar 24, 2016

kYc0o commented Mar 24, 2016

miri64 commented Mar 24, 2016

zhuoshuguo commented Mar 24, 2016

at86rf2xx: port to netdev2 #4646

at86rf2xx: port to netdev2 #4646

Conversation

miri64 commented Jan 16, 2016

kaspar030 commented Jan 18, 2016

biboc commented Jan 20, 2016

thomaseichinger commented Jan 20, 2016

miri64 commented Jan 20, 2016

miri64 commented Jan 25, 2016

thomaseichinger commented Jan 26, 2016

miri64 commented Jan 26, 2016

miri64 commented Jan 28, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

5.2 MAC frame formats

Choose a reason for hiding this comment

miri64 commented Jan 28, 2016

miri64 commented Jan 28, 2016

miri64 commented Mar 16, 2016

miri64 commented Mar 17, 2016

miri64 commented Mar 18, 2016

miri64 commented Mar 18, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OlegHahm commented Mar 23, 2016

miri64 commented Mar 23, 2016

OlegHahm commented Mar 23, 2016

haukepetersen commented Mar 24, 2016

haukepetersen commented Mar 24, 2016

OlegHahm commented Mar 24, 2016

emmanuelsearch commented Mar 24, 2016

kYc0o commented Mar 24, 2016

miri64 commented Mar 24, 2016

zhuoshuguo commented Mar 24, 2016