Re: [riot-devel] 802.15.4 Radio HAL RDM
Robert Hartung wrote: > I would like to see a OSI layer model along with common implementations OSI layer documentation has seldom helped people write better code, IMHO. It's a useful abstraction... in the abstract. It's a conceptual model, not a way to structure code. Many have made that confusion over the decades. But, I share your pain. Dealing with systems with pointers to functions but which don't have objects that you can easily follow (or that Eclipse can eat all your ram trying to show you) can make life really difficult. That was my reason for asking for "such as..." messages in the headers where pointers to functions are defined. > So all I am asking for would be a little help, to complete such a > diagram for now, to know all apis and "entry" points and give some > examples on how to access layers. Ideally at one point, my wish would be > fulfilled to be able to easily exchange layers. Functional Block Diagrams, and also time-sequence diagrams would help. Being able to reference them easily the headers is good. Having them in ascii art, easily amended and reviewed good. ASCIIO is a good tool, but alas, it doesn't seem to have a command-line interface! -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] 802.15.4 Radio HAL RDM
I appologize that I have not read the the Pull Request in detail, and thanks to overwork, I'm admitting that I probably won't have the chance. Nor am I an expert in the IEEE 802.15.4 document, where it specifies these "functions". (Maybe Tero Kivinen might help here) My alternative thoughts were to: 1) fill this in the "someday" folder, 2) delete it without comment. I have often been frustrated that many reasonable things that we need to do to make L3 and L2 interfaces work right are not well described by IEEE and one winds up a situation where some mechanisms are not well taken by the STD community because they contravene some abstract 802154 document API, when in reality many systems do not impose hard interfaces between radio/MAC layers and L3 users. My question is whether or not it's worth making any link from this HAL to the primitives that IEEE seems to suggest. It's not my goal to lock us into such a thing (I think that would very bad), but rather to more clearly say where are complying with the spec, and where we have intentionally done something different. (vs unintentionally done something different) My other request is that when there is code like: /** * @brief Prototype of the IEEE802.15.4 device event callback * * @param[in] dev IEEE802.15.4 device descriptor * @param[in] status the status */ typedef void (*ieee802154_cb_t)(ieee802154_dev_t *dev, ieee802154_tx_status_t status); (This might not be new, but I am just latching on it) That we might say in the description: "such as foo_bar_blah_cb() in foo/bar/blah.c" As the functional OOP mechanism in C can be difficult to track. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] 802.15.4 Radio HAL RDM
Good morning RIOT developers, Before giving a review in the mentioned PR, I would like to give some shorts comments on here, that wouldn't fit in the PR. While I really like the new approach to access lower levels directly and making the integration of new network stacks a lot easier, I feel like we are adding more complexity, and another level of abstraction, which makes it hard for a user to change things or even understand how things work. As mentioned in #13771, I feel like the term network stack needs some thoughts and the implementations need some cleanup (which I am happy to assist and commit some of my time to). I would like to see a OSI layer model along with common implementations within RIOT. There *should* be APIs on each level if possible to access individual levels. I would really like to see a good method to exchange layers. At the same point I know that this will not happen over night. It will take time and thoughts of multiple people. I think the existing code is a very good starting point, in order to see what's there and how it currently works and how it "should" work (what would be desireable). I write this, because in the past I found in particular hard to understand the network stack within RIOT and how to access other levels. Additionally, one of my students tried to implement the BPBISv7 DTN protocol for RIOT and was successful, but it was a painful ride, as it was very hard to debug stuff in between. So all I am asking for would be a little help, to complete such a diagram for now, to know all apis and "entry" points and give some examples on how to access layers. Ideally at one point, my wish would be fulfilled to be able to easily exchange layers. Best Regards and have a nice weekend, Robert #13771: https://github.com/RIOT-OS/RIOT/issues/13771 Am 24.04.2020 um 18:51 schrieb José Ignacio Alamos: > Dear RIOT developers, > > I've opened a PR with a new RIOT Developer Memo [1] with a proposal for > a 802.15.4 Radio Hardware Abstraction Layer. > > Abstract: >> This memo describes a Hardware Abstraction Layer (HAL) for radios compliant >> with the IEEE802.15.4 standard. The work follows a technology-specific >> approach >> to provide well defined hardware access that allows to implement agnostic >> IEEE802.15.4 PHY and MAC layers on top. Additionally, the new HAL enables >> integration of network stacks that require direct access to the radio. > Next to the RDM I published an implementation of the Radio HAL API, a test > application and 2 HAL implementations (`at86rf23x` and `nrf52840` radios). > I also appended the memory efficiency compared to the current `netdev` > implementation. > > I would like to request feedback from people that have some experience > with these kind of radios. > > In case of any questions or comments, don't hesitate to reply > (or post directly in the PR) > > Thank you so much in advance! > Have a nice weekend. > > Best, > José > > [1]: https://github.com/RIOT-OS/RIOT/pull/13943 > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
