Hi biwa,

There are no tutorial or documentation of ticker or mayfly in the Zephyr repository.

Ticker and Mayfly implementation are specific to BLE controller scheduling and they are barebones implementation contributed to Zephyr Project.

We are constantly refactoring the implementation to use Zephyr OS features.

Some of the continued issues needing contributions are:

https://github.com/zephyrproject-rtos/zephyr/issues/2244

https://github.com/zephyrproject-rtos/zephyr/issues/2247

https://github.com/zephyrproject-rtos/zephyr/issues/2248

To be short, Mayfly schedule functions to be run deferred in another execution context.

Currently the BLE controller uses them to call functions in interrupt contexts.

Zephyr threads or work queues that suffice the controller needs will replace mayfly.

If you can be more specific on what you are interested in Ticker/Mayfly, I can provide more details.

Regards,

Vinayak

Hi there,

No, unfortunately there are no tutorials or even documentation about the ticker or the mayfly. That said, their author is Vinayak from Nordic, and you can reach him on IRC, he’s usually there. Try the channel #zephyr-bt on freenode.net.

Regards,

Carles

Tomasz,

I understand that implementations vary from the IEEE standard. I tend to treat the standard as the reference and try to grep the implementation based on this framework. I guess I need to dig into net_app…

On data frames, at least for version 2011 (didn't check later ones), nothing forces AR to be 1, see 5.2.2.2.
Moreover if your protocol handles re-transmission on its own you don't want 15.4 to add-up.
Also, until 2015 version, which is not supported atm, this "re-transmission" mechanism from 15.4 is just plain
crap: ACK frames are unidentified, non-secured, etc...

The observation we had from my 802.11 days is that it was generally better to have retries at the RF level due to the tighter timings then to have the higher layer protocols handle the retries (which they will do anyway if the 802.11 retry mechanism exhausts the retry limit). I don’t have as much experience with the network characteristics of an 802.15.4 setup but I would think that it would also benefit from the tighter retry logic timing of the protocol… but this is a knob to tune when setting up a network I guess.

David

 To clarify my general question, what I’m trying to understand is how do we generally expect to initialize/configure the 802.15.4 stack within our system or application? The IEEE802.15.4 specification defines several SAPs for MCPS and for MLME which is what I would expect to see on an interface (like 802.11 which I’m more familiar with)

You won't see the exact same interfaces a described in the specs. PHYs don't even follow it either btw.
Actually a good amount of the specs will probably never end up being coded at all (FFD part for instance).

. I can see some of the logical mappings between IEEE802.15.4 MLME operations to the NET_REQUEST_IEEE802154_CMD types we have in Zephyr but not all of them yet (still grepping the code/logic). And I see we have these net_mgmt() functions to set these values. Is it through these net_mgmt() functions that we are expected to setup the values?

Yes, and you probably just want to use net_app lib for it.

 With respect to the AR bit, I don’t understand your response about the AR bit in the frame control. If a frame is being transmitted from an IEEE Std 802 protocol then the AR field should follow the needs of the frame where a broadcast or group address frame has the AR field set to 0 and directed data frames have the AR field set to 1. The other 802.15.4 management frames all each have their own rules on setting or clearing this bit from what I can tell. I don’t get why there is even an API to enable/disable this as the frame type should be driving the needs of this bit.

Looks like forcing AR bit setting to 0 on broadcast type got forgotten, as it used to be always 0.
For MAC command frame it's properly handled.

On data frames, at least for version 2011 (didn't check later ones), nothing forces AR to be 1, see 5.2.2.2.
Moreover if your protocol handles re-transmission on its own you don't want 15.4 to add-up.
Also, until 2015 version, which is not supported atm, this "re-transmission" mechanism from 15.4 is just plain
crap: ACK frames are unidentified, non-secured, etc...

Br,

Tomasz

Tomaz,

Thank you for the response.

To clarify my general question, what I’m trying to understand is how do we generally expect to initialize/configure the 802.15.4 stack within our system or application? The IEEE802.15.4 specification defines several SAPs for MCPS and for MLME which is what I would expect to see on an interface (like 802.11 which I’m more familiar with). I can see some of the logical mappings between IEEE802.15.4 MLME operations to the NET_REQUEST_IEEE802154_CMD types we have in Zephyr but not all of them yet (still grepping the code/logic). And I see we have these net_mgmt() functions to set these values. Is it through these net_mgmt() functions that we are expected to setup the values?

With respect to the AR bit, I don’t understand your response about the AR bit in the frame control. If a frame is being transmitted from an IEEE Std 802 protocol then the AR field should follow the needs of the frame where a broadcast or group address frame has the AR field set to 0 and directed data frames have the AR field set to 1. The other 802.15.4 management frames all each have their own rules on setting or clearing this bit from what I can tell. I don’t get why there is even an API to enable/disable this as the frame type should be driving the needs of this bit.

David

How is the 15.4 stack interaction supposed to work when trying to tie it to something like the echo client/server?

As any L2. The IP layer and net application (whatever it is) has no knowledge of its inner logic. All is abstracted via net_if

 

I’m looking at debug output and noting that the stack sends data frames and retries them all because it seems like it doesn’t know to set the “ack required” field in the frame control. I can see that there seems to be these net_mgmt() commands to SET_ACK but it isn’t clear to me when these actually should be invoked and what the expected behavior is.

Hopefully IP stack does not request ACK flag by itself. That's completely up to the application and should be used very carefully.
echo apps are some kind of basic flooding apps just to see if the whole net logic works, and is really not a proper 15.4 test case.
But it's fine, as long as most of the packets go through. You can have losses, 15.4 (2011 version at least) is not meant to be a reliable
technology.

 

Also, the shell_cmd_ack() function in ieee802154_shell.c doesn’t seem right in that the unset command is still invoking the NET_REQUEST_IEEE802154_SET_ACK instead of the UNSET_ACK.

Yep, a q&d c/p issue. Will fix it.
I don't think anybody uses that shell, even myself actually.


Tomasz

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 

** PROPRIETARY & COMPANY-CONFIDENTIAL **

 

_______________________________________________

Zephyr-devel mailing list

Zephyr-devel@...

https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

How is the 15.4 stack interaction supposed to work when trying to tie it to something like the echo client/server?

I’m looking at debug output and noting that the stack sends data frames and retries them all because it seems like it doesn’t know to set the “ack required” field in the frame control. I can see that there seems to be these net_mgmt() commands to SET_ACK but it isn’t clear to me when these actually should be invoked and what the expected behavior is.

Also, the shell_cmd_ack() function in ieee802154_shell.c doesn’t seem right in that the unset command is still invoking the NET_REQUEST_IEEE802154_SET_ACK instead of the UNSET_ACK.

David Leach

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

** PROPRIETARY & COMPANY-CONFIDENTIAL **

This is the wrong project, you are looking for something different, This Zephyr project is not related to Jira, this is an RTOS.

Anas

Hello,

We are currently using 2 instances of Jira and Confluence which we are merging into 1 instance.

However, we encounter problems in merging the Zephyr for Jira add-on.

Can you explain to me how to export Zephyr data from one database and import into another database?

Hope to hearing from you soon.

HQ: Parmentierplein 1 • 3088 GN • Rotterdam • The Netherlands • www.steinweg.com

---
The General Terms and Conditions of C. Steinweg-Handelsveem B.V. ("Steinweg Conditions") are applicable to all our activities. Depending on the nature of the activities general sectoral terms and conditions are also declared applicable in these Steinweg Conditions. Chartering of vessels or other means of transport are exclusively performed in our capacity of forwarder ("expediteur"), even if these services are performed pursuant to a transport order. These Steinweg Conditions confer exclusive jurisdiction to the Court of Rotterdam.

The Steinweg Conditions can be downloaded from http://www.steinweg.com/conditions/, they are filed at the registry of the Court of Rotterdam and at request they will be sent to you free of charge.

Company Registration No. 24001123
---