drivers/rail: efr32 radio driver

[kaibeckmann]

Contribution description

This is (going to be) a radio driver for the Silicon Labs Gecko series (Mighty Gecko, Flex Gecko, etc).

It is still work in progress (besides missing features, the structure is probably going to change a bit and not all riot coding conventions are currently followed).

So far it is possible to connect to a border router, get the ip prefixes, do the RPL stuff and ping other devices (UDP might work as well). Not all NETOPs are implemented so far. There is also a performance / latency issue somewhere.

The PR is working with the Silabs Dev-Kits SLWSTK6000B and the Thunderboard SLTB001A .

If the hardware module (only relevant for the SLWSTK6000B) has an 868MHz antenna, the radio can be configured to 868MHz ( radio.h in the BSP).

Thanks to @basilfx the necessary generic parts for this driver are already part of the efm32 support.

At the moment the pkg gecko_sdk is pointing to my fork, but this will be removed after #9127 is merged.

There is the dependency to the Silabs rail driver blob (gcc compiled lib). Since Silabs doesn't publish any documentation for the radio hardware itself, this blob is the only way to use the transceiver.

I would welcome some remarks / feedback for the structure / design of the driver. I started with the at86rf2xx structure, but this doesn't fit so well...

TODOs

• Riot coding convention
• uncrustify the code
• Documentation
• NETOPS get
• NETOPS set
• use of params_t structure to configure the driver
• Fix fragmentation bug
• Find / fix latency problem
• consolidate netdev state and silabs driver state
• ...

Future TODOs

• sleep / pm_ support
• Multiple netdev instances for 2.4GHz and 868MHz in parallel

Issues/PRs references

#8569

[kYc0o]

Thanks for your contribution @kaibeckmann !

Unfortunately, I'm having this error while trying to flash gnrc_networking example using your branch.

Downloading file [/Users/facosta/git/RIOT-OS/RIOT/examples/default/bin/sltb001a/default.bin]...

****** Error: Timeout while checking target RAM, RAMCode did not respond in time. (PC = 0x00000009, CPSR = 0x00000008, LR = 0x81000000)!
Failed to prepare for programming.
Failed to execute RAMCode for RAM check!
Unspecified error -1

And is bricking my boards... I have tested two so far and now they cannot be flashed even in master. I of course flashed something before trying your PR successfully, so something is happen here. I'll investigate further, any hint you might have is greatly appreciated!

[kYc0o]

You might also rebase to current master since I just merged #9127, and update the gecko package to point again to the original source.

[kaibeckmann]

hmm I think I have seen this error before. We have sometimes problems with the normal dev boards (and our custom devices).

Sometimes somehow the debug mode got locked. Or the running application somehow blocks the system.
For the first (normally there is another error message) you need Silabs SimplicityStudio, there is a tool called SimplicityCommander (runs on Windows, Linux, Mac etc) which can reset the uC.
For the second problem you can try to connect with gdb and monitor halt. monitor reset the uC. In another shell you can try to flash it.

[kYc0o]

You might also rebase to current master since I just merged #9127, and update the gecko package to point again to the original source.

[kaibeckmann]

OK, done. Btw. where you able to restore your boards?

[basilfx]

I did a quick review of the code (style). I am not a netdev expert, so this needs a thorough review by someone else :-)

[kYc0o]

Overall, it is very very difficult to review the driver in its actual state (I know, WIP), but I tried.

First of all you need to uncrustify all the code so it's easier to read.

There are several things that are misinterpreted and thus the code it's a bit messy here and there, with config that belong to other modules and a lot of unfinished implementations, which IMHO shouldn't be that complicated to add.

I strongly recommend you to read the at86rf2xx driver to give yourself an idea of what should be implemented where.

However, the driver works correctly so far, with of course the non-implemented functionalities not working, but that's an excellent beginning! I think the high latency is due to the messy handling of the functions and interrupts, I'm pretty sure it will improve when things are implemented correctly.

After you address my comments, and the code is uncrustified, I'll give another review. I'm looking forward to have this merged!

[kaibeckmann]

Thank for all the feedback!
I have to prepare a demo for next Tuesday, after that I can focus on the radio driver again.

But at least for the demo I have to run "real applications" on top of it. So it gets some testing ;)
gcoap works quite good so far.

[basilfx]

@kaibeckmann Just wondering if you have made any progress (or if there is something we can help you with)?

[benemorius]

Ping @kaibeckmann I've rebased and squashed in my patches in this commit. Since previously I fixed some doxygen and other Travis complaints but otherwise I've used it for a while without finding any new bugs to fix. I think this driver is in pretty good shape.

If you can just address consolidate netdev state and silabs driver state I believe this PR would be ready for a next review.

[kaibeckmann]

@benemorius looks good. I'll see what can be done this week. Luckily, I have some more time now :)

[kaibeckmann]

ok, I was able to include @benemorius commits and rebase everything.
It's working with coap on a SLTB001A :)
Fragmentation looks better as well!

I'll look into the state consolidation next.

[reedstrm]

BTW, interested watcher, here. Getting a bulb and a switch from ikea for $13 nets you a ready-to-hack two-node RIOT network, assuming y'all can get this merged up. :)

Hey @benemorius if you want we can do it together. I just need some kicks now and then to get things done sigh. So I'll try to rebase this branch and include your commits today.

Btw. not only Tradfri is a nice platform, Tuya started to use Migthy Geckos as well. See 1 as an example. Here is a overview 2 of ZigBee-certified devices. I got one of these 3, unfortunately the debug / JTAG pins are not exposed nicely ...

Seems Sonoff's new(ish) Zigbee gateway contains a Silabs gecko2 as the Zigbee coprocessor (has an ESP8266 WiSoC and a Silicon Labs EFR32MG21 Gecko Series 2 Cortex-M33), so a potential nice cheap bridge device ($18), as well!

I'm starting to salivate at the idea of RIOT-OS w/ zigbee and mqtt (paho) baked directly into each bulb/switch/sensor. From what I see of the zigbee OTA update mechanism, signed firmware checking is only done by the coordinator when downloading the new firmware, not by the end device over the zigbee network. Since I control the gateway (zigbee2mqtt on a raspberry PI w/ cc2531 dongle) I can ideally OTA commercial, sealed bulbs directly. Not going to do that until I've got something solid, though :) (I suppose I can deconstruct anything I brick to extract dev boards, though, and they are pretty cheap … hmmm)

[benpicco]

In theory the new radio HAL / 802.15.4 MAC should make it easier to write 802.15.4 drivers - I don't know how much of a rework this would mean for this driver.

See #14802 & #14371

[stale]

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.