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.
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.
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
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!