Is it possible to add a driver for RAK3172 or similar LoRa-SoM?

[Kampi]

Is your feature request related to a problem? Please describe.

I´m thinking about creating driver for a RAK3172 SoM and if it makes sense to do it or use it as user space application. The problem is that, if I understand it correctly, Zephyr is using a driver structure for the LoRa PHY and the LoRaWAN stack from Semtech which uses the LoRa PHY. But the RAK3172 (as an example) is a complete solution for LoRa and LoRaWAN. So I´m not sure if this type of device can be added properly to Zephyr and how the ideal approach looks like.

Describe the solution you'd like

Some brainstorming or suggestions if and how such an AT command based LoRa SoM can get integrated in Zephyr.

Additional context

RAK3172 documentation

[nordicjm]

If the module supports replacing the in-built firmware then you can flash your own zephyr firmware to it, you would need to ensure you have drivers for all the parts

[Kampi]

Hi @nordicjm

you got me wrong :)
I want to use the module with a host MCU which is running Zephyr. So from Zephyr´s perspective it´s a peripheral component.

[nordicjm]

You would need to create a driver that interacts with it then, nothing in-tree does that

[Kampi]

Okay. But Zephyr already contains a Subsystem for LoRaWAN and a LoRa driver. Is it possible to implement a driver that is based on the LoRaWAN Subsystem APi (but not the code because the module has a LoRaWAN stack implemented) and the LoRa driver API?

The issue is that both systems build up on one another so it sounds quite complex to me to integrate the module in such a way that the normal Zephyr APIs can be used.

[nordicjm]

The driver you refer to in zephyr is the stack itself, the module you link to has it's own stack, you do not use a stack to communicate with it, you would need to use UART commands so the drivers in zephyr have no relation to this at all. Hence why you would need to implement it yourself

[ronsegal]

The module is pre-programmed with its own LoRaWAN stack but of course can easily be reprogrammed to support the Zephyr LoRaWAN stack. The RAK3172 is essentially an STM32WLE5 with regulator and RF antenna support circuitry. So you can essentially use the Zephyr drivers for the STM32WLE5 as a base. For example you could modify the drivers for an STM Nucleo with similar chip: https://docs.zephyrproject.org/latest/boards/st/nucleo_wl55jc/doc/nucleo_wl55jc.html with changes to account for whatever is provided on the board that is using the RAK3172.

[Kampi]

Hi @ronsegal
it was my idea to add a driver to use the LoRaWAN stack from the RAK3172 with the LoRaWAN API from Zephyr. I don´t want to run Zephyr on the STM32WLE5. But it´s not that easy because the LoRaWAN API from Zephyr is based on a LoRa chip driver and some other drivers and has no option yet to directly communicate with an external LoRaWAN stack.

[ronsegal]

Right, understood. Seems quite unusual. Isn't the RAK stack based on STM's fork of Semtech's, which in that case uses its own event timer functionality rather than an RToS. I've used both and found the Zephyr stack to be more reliable and easier to integrate with real applications. Perhaps because STM's has in the past at least been based on Semtech's development branch, with in my view inadequate testing, although to be fair Semtech has been slow to move their stack forward with much important functionality that STM obviously felt the need to use essentially stuck in development. Cheers.