Skip to content
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

Add other radios support for OpenThread pkg #10045

Open
jia200x opened this issue Sep 26, 2018 · 3 comments
Open

Add other radios support for OpenThread pkg #10045

jia200x opened this issue Sep 26, 2018 · 3 comments

Comments

@jia200x
Copy link
Member

@jia200x jia200x commented Sep 26, 2018

The current OpenThread package only supports at86rf2xx radios, although the port is done on top of netdev.

This is why:

  1. The radio setup is in the openthread_bootstrap function.
  2. This is the only radio that implements the NETDEV_EVENT_TX_COMPLETE_DATA_PENDING for handling the frame pending bit in the IEEE802.15.4 ACK

I open this issue to keep track of the OT support for other radios. For adding a new radio to OpenThread, do 1. (we should probably move it to auto_init though!) and add the netdev event NETDEV_EVENT_TX_COMPLETE_DATA_PENDING. It should be simple since it should only involve reading a register :)

EDIT: It's also required to implement the NETOPT_ACK_PENDING!

TODO:

(Am I missing one?)

And when we update/finish this:

  • Reflect changes in pkg documentation (#10048)
@gebart

This comment has been minimized.

Copy link
Member

@gebart gebart commented Sep 26, 2018

(added kw41z to the top post)

@bergzand

This comment has been minimized.

Copy link
Member

@bergzand bergzand commented Sep 29, 2018

It should be simple since it should only involve reading a register :)

Sure, only a register read, how hard could this be on a bunch of different radios, the manufacturer probably thought about exposing this information in an easily accessible way :)

@jia200x To ask the dumb question, do we also have to implement something to configure ACK transmission with frame pending bit?

I'm also not entirely convinced that the current approach here is the best approach (A separate event), but that is something I'll think about in the next days and maybe I'll put in a PR to modify the way it is implemented now. My main issue is that I don't like to have network stack specific defines in the drivers (yes that also counts for gnrc specific defines).

@jia200x

This comment has been minimized.

Copy link
Member Author

@jia200x jia200x commented Oct 5, 2018

Sure, only a register read, how hard could this be on a bunch of different radios, the manufacturer probably thought about exposing this information in an easily accessible way :)

Oh ja :)

@jia200x To ask the dumb question, do we also have to implement something to configure ACK transmission with frame pending bit?

oh, I totally forgot that. Good catch.
Yes, it has to be implemented (it won't have any effects now since pending bit handling is not supported in routers, but it will be added soon).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.