Mbed-os: Add LoRa radio pins to HAL for targets with LoRa board

Created on 19 Feb 2018 · 11Comments · Source: ARMmbed/mbed-os

Description

Type: Enhancement

Enhancement

Reason to enhance or problem with existing solution

A variety of targets have a LoRa radio on board. This radio is connected to the MCU via some pins, and these pins won't change over the lifetime of the device. However, to write an application which supports all LoRa modules that we have, we need to write lengthy #ifdef's or target_overrides (for example in mbed-os-example-lorawan. Every demo application of our stack is going to have the same issue.

Suggested enhancement

Add LORA_RADIO_* definitions to the HAL of all targets that have an embedded LoRa module. Also a TARGET_HAS_EMBEDDED_LORA definition (or something) would be nice to have.

Pros

Don't have to repeat ourselves in demo applications.

Cons

Might be something that lives in user space instead. Could add it to https://github.com/ARMmbed/mbed-semtech-lora-rf-drivers instead.

@hasnainvirk what's your opinion.

CLOSED networking mirrored

Source

janjongboom

👍2 🎉1

Most helpful comment

@0xc0170 I agree on the pins, I'm wondering about the HAS_ONBOARD_LORA_RADIO macro.
[Mirrored to Jira]

janjongboom on 9 Apr 2018

👍2

All 11 comments

I love this idea @janjongboom. We had been trying to take a similar approach for cellular but then we had to stop as addition to device_has[] fields in targets.json was not permitted. I am up for it and we should try getting this idea materialised as soon as possible.
[Mirrored to Jira]

hasnainvirk on 6 Apr 2018

👍1

@sg- What's the reason we cannot add anything to device_has? In this case it seems like a pretty useful macro.

@hasnainvirk Additionally we could add it to the device.h section in the targets, and not in targets.json, but would need some blessing from core OS team as well.
[Mirrored to Jira]

janjongboom on 9 Apr 2018

@sg- What's the reason we cannot add anything to device_has? In this case it seems like a pretty useful macro.

The config is for this purpose. Device has is specific to targets capabilities = HAL.

@hasnainvirk Additionally we could add it to the device.h section in the targets, and not in targets.json, but would need some blessing from core OS team as well.

Why not target config? Reading the headline - this is about pins. The pins are defined in PinNames. And can be actually set in the config. There are already few instances there like stdio that are set in PinNames and they take the value from targets config (few targets have it configurable).
[Mirrored to Jira]

0xc0170 on 9 Apr 2018

@0xc0170 I agree on the pins, I'm wondering about the HAS_ONBOARD_LORA_RADIO macro.
[Mirrored to Jira]

janjongboom on 9 Apr 2018

👍2

@janjongboom I would suggest having something like:

"device_has": [LORA_RADIO_ONBOARD]

Reason for not having such a flag in Cellular was an argument that device_has[] field belongs to the chip. But now I can see that there STDIO and EMAC flags beings added. So I don't see any reason why we can't add LORA_RADIO_ONBOARD.
[Mirrored to Jira]

hasnainvirk on 9 Apr 2018

Due to the C porting interface for existing HAL drivers, device_has provided in #if 0 implementation in the code where this wasn't available. With a move towards C++ virtual base classes for more complex radio drivers and interfaces needing synchronization. I dont understand why the get_default_instance and static member initialization aren't enough. The pattern in USB and Ethernet looks like the pattern that would correct some confusion we have with PPP and cellular.

More to come soon with regards to what a board, module and mcu are (and aren't).
[Mirrored to Jira]