Hello.
[Putting Adrei in CC as well, not sure if he is subscribed to linux-wpan]
On 31.05.20 18:13, Christopher Friedt wrote:
Hi Koen,
On Sat, May 30, 2020 at 2:10 PM Koen Zandberg <koen@xxxxxxxxxxxx> wrote:
Hello all,
Long term RIOT maintainer here.
I'm willing to work on this for a RIOT implementation, assuming there is
some documentation available on the USB protocol side :)
I think I should be able to get a relative generic firmware application
able to run on any of our hardware boards as long as they have a radio
and a USB interface.
That's great news!
Also, I heard from the original wpanusb author and he said he'll put
submitting a patch any day now.
Happy to see that we finally have the critical mass to get this moved
forward. :-)
Here is my take on what I think needs to be done.
On a first review I found nothing wrong with the design. It needs
further extending and flexibility in my opinion, though.
o Add a GET_EXTENDED_ADDR command to receive the extended address
provided by the transceiver itself, or firmware in some way.
o Adding a GET_CAPABILITIES command to query device capabilities
during init to enable and set needed ieee802154_ops based on the
device. Given that we aim to support as many transceivers as possible we
can't rely on static device knowledge to configure wpanusb correctly.
o Add opcode for set_lbt in USB spec
o Add opcode for set_frame_retries USB spec. (If a transceiver does not
support AutoACK in hardware do Zephyr and RIOT support a software
fallback to handle AutoACK?)
o How are we going to handle transceiver which allow MTUs > 127? Not a
high priority as the kernel part does not support this either right now.
o Do Zephyr or RIOT expose additional functionality we should support here?
o Koen, you offered to look into implementing the firmware support for
the USB spec in RIOT. Does the spec fit what RIOT has as abstraction for
ieee802154?
o Adrei, Chris, I understand it you would work on the wpanusb as well as
the Zephyr firmware side, correct?
o I see additional use cases for a bare metal firmwares (a different fw
to support wpanusb on the atusb device or CC2531 comes to mind). But
none of those are critical in the beginning.
regards
Stefan Schmidt
