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

radios: Remove default radio flags from init #10355

Closed

Conversation

bergzand
Copy link
Member

@bergzand bergzand commented Nov 9, 2018

Contribution description

This removes the default flag configuration from the initialization function of the supported radios. Instead, the upper layer network function configures the required/enabled flags on the radio.

The idea is to have a more centralized configuration of these flags instead of every radio enabling a different set of flags on init.

Testing procedure

Test if every radio correctly configures flags based on the configuration in sys/include/net/ieee802154.h

  • cc2538 (Supports only autoack as far as I know)
  • at86rf2xx
  • cc2420
  • kw2xrf
  • mrf24j40

Issues/PRs references

requires #9592

@bergzand bergzand added Area: network Area: Networking Type: new feature The issue requests / The PR implemements a new feature for RIOT State: waiting for other PR State: The PR requires another PR to be merged first Area: drivers Area: Device drivers labels Nov 9, 2018
@@ -104,8 +104,6 @@ void kw2xrf_reset_phy(kw2xrf_t *dev)

kw2xrf_set_rx_watermark(dev, 1);

kw2xrf_set_option(dev, KW2XRF_OPT_AUTOACK, true);
kw2xrf_set_option(dev, KW2XRF_OPT_ACK_REQ, true);
kw2xrf_set_option(dev, KW2XRF_OPT_AUTOCCA, true);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept the AUTOCCA flag here as it has a slightly different meaning than the CSMA netopt. It also has its own netopt option.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alternative could be to try setting csma first, and if that fails, try to set autocca. What do you think of this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment the kw2xrf is the only radio using the NETOPT_AUTOCCA option, so I'd rather leave it to a follow up PR if we want this change.

I was thinking, if we combine this CCA feature with some exponential back off timer, we effectively have CSMA right? Would this be something that we want to have for this radio?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can copy the behavior from kw41zrf. I did exactly what you describe in order to provide csma for that radio.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Someone else will have to provide the PR. I don't have the hardware and have no interest in the kw2xdrf

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Someone else will have to provide the PR. I don't have the hardware and have no interest in the kw2xdrf

Same for me to be honest

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we're all short in time but we (HAW Hamburg) have certain interest in that radio so it might be us to do the follow-up. @gebart, @bergzand could you please open a feature request issue?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PeterKietzmann I opened #10364 as a reminder

@PeterKietzmann
Copy link
Member

@jia200x I assume you know this PR. IMO we should try to address this one in conjunction with #11473

@stale
Copy link

stale bot commented Nov 22, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Nov 22, 2019
@stale stale bot closed this Dec 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers Area: network Area: Networking State: stale State: The issue / PR has no activity for >185 days State: waiting for other PR State: The PR requires another PR to be merged first Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants