Consolidate all LORA physical layer implementations behind one API

[ceekdee]

This issue arises out of the discussion regarding the recent addition of an implementation to support the Semtech sx126x LORA chips:

#985 (comment)

I hope to start working on this project in December, or to contribute to other initiatives that start before then. In the meantime, this issue serves as a launchpad for a discussion on expectations developers have for a LORA physical layer implementation and API that supports Semtech LORA chips and MCU variants. It would be most helpful if envisioned use cases can be added here to shape the discussion.

My personal focus at this time is on a point-to-point (P2P) implementation that requires only the LORA physical layer. However, I see great value in interfacing the physical layer implementation with - for example - the Drogue IoT project.

[lulf]

Commenting here instead of #1041

A brief synopsis of architectural thoughts to this point for the implementation in issue 1023. A bit premature, but I will be unavailable to work on an implementation until the end of November and want to encourage other thoughts.

• produce a trait that describes LoRa API functions that are prevalent across Semtech chips (the base API, largely present in the sx126x implementation - https://github.com/embassy-rs/embassy/blob/master/embassy-lora/src/sx126x/sx126x_lora/mod.rs - which closely followed the Semtech C implementation);
• produce additional traits for LoRa API functions unique to different flavors of Semtech chips;
  *implement enums and structs which support the various concerns represented across the full API, making each as generic as possible to support present and future LoRa chips (this will build on the separation of concerns in the stm32wl driver);
• implement an orchestrator for each MCU/LoRa chip combination. For example, the rak4631 will have an orchestrator, as will a STM32 nucleo board;
• each orchestrator is a lightweight implementation which grabs the device-specific pins and SPI bus and assembles the necessary enums and structures to support the MCU/LoRa chip combination;
• the LoRa generic and board-specific API for an MCU/LoRa chip combination will be accessed through the orchestrator.

I agree on the approach. However, in terms of where this happens, I think we should leave board-specifics out of embassy-lora itself, and perhaps surface the orchestrator concept, at least initially, in a separate create (some kind of BSP?). Most likely outside the embassy main repo? I think what you're describing is not only a solution for lora specifically, but a pattern that applies to other types of networking.

With all these traits its also a potential downside of making the APIs a bit harder to use, so keeping embassy-lora somewhat focused on the drivers + integrating with rust-lorawan I think is the appropriate scope for that, because some might want to use it at that level rather than binding to some orchestrator for their board.

[ceekdee]

Adding additional comment moved from #1041:

Perhaps a better way to envision the "orchestrator" is as a builder which returns a LoRa structure supporting the API for an MCU/LoRa chip combination.

Since the only current interfaces to Semtech chips of which I am aware are SPI and pin setting/checking, the hope is to hide any dependencies on STM32WL or nRF52 for this behind the LoRa API.

[ceekdee]

@jbeaurivage, @lulf: I am back after a 3 week hiatus.

I am making a note here regarding the fix in #1064. We will need to consider the setting of the polarity bit for both the LoRa P2P case and the LoRaWAN case. I assume that for the P2P case inverted polarity should not be set. Perhaps the P2P case should not use PhyTxRx.

[jbeaurivage]

Agreed; considering that PhyTxRx is a construct specific to lorawan-device it probably shouldn't be used for non-LoRaWAN operations.

[ceekdee]

It appears that to this point the Embassy emphasis within lora has been on the LoRaWAN use case, so I'm not sure whether PhyTxRx should be solely a LoRaWAN construct when P2P is considered. In any case, I will need to adjust the Embassy repository's P2P examples sooner rather than later to support our decision.

LoRa P2P is quite useful. I believe it supports Meshtastic's off grid communication project, and I have used it in order to hand my neighbor a device that receives and reports - as an example - my home's temperature while I am away. Our homes are separated by a significant distance, so it helps that they can be alerted to a malfunctioning furnace remotely.

[jbeaurivage]

LoRa P2P is quite useful.

Oh no doubt, all I'm saying is that PhyTxRx is a trait provided by lorawan-device. Maybe we'd be better off making that dep optional behind a lorawan Cargo feature? We can certainly also provide P2P impls with sane defaults for the modulation/packet parameters.

[lulf]

So, the original intent for embassy-lora was to be an integration point between lorawan-device and embassy HALs.

As I think you correctly point out, there is a useful use case for LoRa P2P as well. An alternative to adding a lorawan feature flag to enable that integration would be to move the existing stuff into a new crate embassy-lorawan and then use the existing embassy-lora for the basic lora functionality/parameters.

However, is also some work ongoing in rust-iot/radio-hal#24 - and I'm wondering if time would be better spent making that work with async/embassy, as it would probably cover most of the functionality for LoRa p2p. The additional work would then to make the lorawan-device work with the 'radio-hal' drivers.

At the time when embassy-lora was created, there was no embedded-hal-async, so keeping it inside embassy was the easiest. Now I think maybe more of the drivers could live in radio-hal (which would need to use embedded-hal-async), and only the bits that depend on embassy HALs need to live in the embassy repo.

Thoughts?

[ceekdee]

It should be easy enough for me to open a separate issue to fix the LoRa P2P examples to use Sx1262xRadio's lora implementation directly.

Hopefully the automatic GitHub reference placed in the pertinent radio-hal pull request will gauge interest within that team.

The decision comes down to what functionality Embassy itself should encompass. There was a decision to place the BLE implementation represented by nrf-softdevice outside Embassy. LoRa also provides device-device communication, so maybe it should also move out of Embassy. And then what does that mean for embassy-net?

However, given the trouble I've had getting both LoRa and BLE functionality to cargo up together to use the full functionality of the RAK4631 module, I'd currently vote to keep LoRa in Embassy and move BLE in there :). To be fair, I haven't put much effort into hammering LoRa/BLE together and realize prospects will improve as these features head toward release.

[lulf]

First of all, let me say I'm very grateful for your contributions to embassy-lora and embassy, and I hope you will continue to feel motivated for that. So please take my disagreement with your stance only as a disagreement. And in any case, it's just my personal opinion, I'm happy for things to go in a different direction if that's what other maintainers want.

It should be easy enough for me to open a separate issue to fix the LoRa P2P examples to use Sx1262xRadio's lora implementation directly.

Hopefully the automatic GitHub reference placed in the pertinent radio-hal pull request will gauge interest within that team.

The decision comes down to what functionality Embassy itself should encompass. There was a decision to place the BLE implementation represented by nrf-softdevice outside Embassy. LoRa also provides device-device communication, so maybe it should also move out of Embassy. And then what does that mean for embassy-net?

My take is that Rust/Cargo already has a mechanism for writing independent libraries that compose with traits + crates.io. IMO the reason for keeping a module in the embassy repo itself is that it

a. is not releasable (yet) and depended on by the HALs or the executor
c. significantly simplifies the issue tracking, CI and release process

The downside of having a module in embassy repo is that it increases the review, CI and release bottleneck of the module itself.

The reason why embassy-net and embassy-lora is in the tree is a bit historical: there was no public embedded-nal-async, embedded-io, embassy-time or embassy-sync crates. However, embassy-stm32 depends on embassy-net, which is something you don't have for embassy-lora.

The reason why nrf-softdevice is not in embassy I don't know, but I think it makes sense to keep it separate, especially now that it doesn't directly depend on embassy other than utlities like embassy-sync, and softdevice also being deprecated by Nordic, so it doesn't really make sense to add that now.

Now that embedded-hal-async exists, drivers like sx127x or sx126x only really needs to rely on those gpio and SPI traits. The added benefit is that those drivers can be used in frameworks like RTIC or on an ESP32 easily without depending on embassy, which is a win-win for everyone. Keeping them in embassy will make it perceived to be embassy-specific, and it makes changes and releasing those drivers a slower process. Keeping them in a separate repo will be easier because there will be a smaller set of maintainers that are focused on those drivers instead.

stm32wl is a bit of a special case where there is a dependency on embassy-stm32, but I don't think it should drive the direction. I'm sure we can figure something out for that.

However, given the trouble I've had getting both LoRa and BLE functionality to cargo up together to use the full functionality of the RAK4631 module, I'd currently vote to keep LoRa in Embassy and move BLE in there :). To be fair, I haven't put much effort into hammering LoRa/BLE together and realize prospects will improve as these features head toward release.

To summarize my stance: I think that would be moving in the wrong direction, and you loose the benefits you get when there is a dependency manager like cargo, an ecosystem like crates.io, and the standardized traits where you can mix and match. I'm not against having examples in embassy that tie everything together.

In any case I think @Dirbaio should have the final say in where we're heading.

[ceekdee]

Excellent response! I do not have the big picture here, and this response helps. While I'll start implementing the LoRa consolidation feature (the root subject of this issue) in Embassy itself, it should be easy to move it to a better crate as this shakes out. I will also review the embedded-hal-async crate in detail to ensure the LoRa consolidation feature relies on it for SPI and GPIO.

[ceekdee]

Milestone on the path to creating one LoRa driver base:

a STM32WL device successfully sends P2P packets to a RAK4631 (nrf52480) device using basically the same sx126x implementation recently added to Embassy and now being developed as a separate package.

Since the ST folks decided to go away from using regular pins for LoRa chip control, the existing Embassy subghz code informed the specific implementation of the following trait for STM32WL:

pub trait InterfaceVariant {
async fn set_nss_low(&mut self) -> Result<(), RadioError>;
async fn set_nss_high(&mut self) -> Result<(), RadioError>;
async fn reset(&mut self) -> Result<(), RadioError>;
async fn wait_on_busy(&mut self) -> Result<(), RadioError>;
async fn await_irq(&mut self) -> Result<(), RadioError>;
}

The implementation of these functions will be dependent on the RTOS and the chip. The actual SPI implementation will be dependent on the RTOS and chip also, but the LoRa driver requires embedded_hal_async::spi. Hopefully this will allow the LoRa driver base to move outside Embassy, with Embassy providing sample usage through STM32WL, STM32L0, and NRF examples.

As indicated in a previous question on the Embassy chat, the STM32WL SUBGHZSPI ST implementation is “different”. Given that I didn’t receive a response to my question there about getting it hooked up through an async interface (DMAMUX1, but no DMA TX/RX), I wrapped code from the existing Embassy subghz SPI implementation with BlockingAsync for the time being. That satisfies embedded_hal_async::spi.

There is still much to do to modify the “C-like” sx126x implementation into a “Rust-like” generic implementation. Several of the Semtech LoRa chips follow the same basic opcode/register processing as the sx126x. However, the sx127x opcode/register processing is significantly different.

[ceekdee]

Adding the following to pub trait InterfaceVariant:

async fn enable_rf_switch_rx(&mut self) -> Result<(), RadioError>;
async fn enable_rf_switch_tx(&mut self) -> Result<(), RadioError>;
async fn disable_rf_switch(&mut self) -> Result<(), RadioError>;

since there is no guarantee the antenna switching logic (the old RadioSwitch) will always be driven by a control pin.

[lulf]

I think that some of the SPI operations benefit from async, and some not. I wonder if it is possible to make the API use blocking fn for things like enable_rf_switch, but maybe async for "tx this buffer"? It would require templating each fn using the appropriate SPI interface, and pass a &mut of the Spi Bus, maybe that makes the code very complex.

[ceekdee]

The initial version of the implementation is now on https://github.com/ceekdee

Separate LoRa package (lora):

• currently, I place the LoRa package and Embassy at the same level in my projects hierarchy to allow LoRa package access from Embassy through direct folder access;
• the LoRa package will need a new home once implementation is complete;
• there is still significant work to do to support chips other than the sx126x using a better modular approach; however, the current progress is worth reviewing since it tackles the significant disparity between the STM32WL control interface to a LoRa chip and a pin-based control interface used elsewhere.

Embassy updates (embassy):

• new examples to demonstrate LoRa P2P between a STM32WL55 (stm32wl: lora_p2p_send) and a RAK4631 (nrf: lora_p2p_receive).

• new lora modules in embassy-stm32 and embassy-nrf to support InterfaceVariant – the processing that is RTOS and MCU/LoRa chip dependent. Note that the existing embassy-lora processing and examples remain valid.

• a change to stm32 SPI function visibility to allow usage of the subghz SPI setup from outside Embassy:
  -- pub(crate) fn new_internal() => pub fn new_subghz()

[ceekdee]

@lulf: See the previous comment for some background information. Updates follow.

Enough of the LoRa physical layer processing refactor is completed to allow a discussion if this is on track to:

1. provide a LoRa physical layer API that supports both P2P and LoRaWAN for various LoRa chips;
2. define a reasonably limited interface for the unique aspects of each RTOS/MCU/LoRa chip combo;
3. otherwise depend on only embedded-hal-async, opening up LoRa physical layer processing for a range of developments outside Embassy, as long as the RTOS supports embedded-hal-async.

In short, is this on the way to meeting the goals we have discussed?

The evolving LoRa physical layer API (only flushed out so far for the SX1261/2 Tx path; see the commented out code to get an idea of what remains) is here:

https://github.com/ceekdee/lora/blob/main/lora/src/lib.rs

A stm32wl example using it (Tx only) is here:

https://github.com/ceekdee/embassy/blob/master/examples/stm32wl/src/bin/lora_p2p_send.rs

An nrf example (setup only) is here:

https://github.com/ceekdee/embassy/blob/master/examples/nrf/src/bin/lora_p2p_receive.rs

The trait for the interface between the MCU and LoRa board is here:

https://github.com/ceekdee/lora/blob/main/lora/src/mod_traits.rs (the InterfaceVariant trait)

A couple of implementations are here:

https://github.com/ceekdee/embassy/blob/master/embassy-stm32/src/lora.rs
https://github.com/ceekdee/embassy/blob/master/embassy-nrf/src/lora.rs

Note that these additions to Embassy allow the existing Embassy LoRa implementations and examples to co-exist with the new lora crate. The transition between embassy-lora and a separate lora crate for the guts of LoRa physical layer processing should be reasonably straight-forward.

Each kind of LoRa chip will have a separate implementation of the RadioKind trait:

https://github.com/ceekdee/lora/blob/main/lora/src/mod_traits.rs (only fleshed out for SX1261/2 for the Tx functionality currently).

I am reasonably confident that the three functions here:

https://github.com/ceekdee/lora/blob/main/lora/src/interface.rs

will handle all of the known ways (OpCode vs. Register methods) that Semtech currently uses for their SX126x and SX127x chips.

In order for this new lora crate to be adopted:

1. (perhaps my opinion only, but I’d like to set clear domain boundaries) existing LoRaWAN implementations will need to change to recognize which attributes are controlled at the LoRa level and which are controlled at the LoRaWAN level. For instance, enums for bandwidth, spreading factor, coding rate, and the like would come from the lora crate. The lora crate should be agnostic to P2P and LoRaWAN usage. LoRaWAN-specific traits would be defined and implemented elsewhere to use the LoRa API in the lora crate.

2. there will need to be some consensus on where the lora crate should live (certainly not in the ceekdee github repository). I have tried to incorporate many of the good ideas from other LoRa implementations, and I hope we can all come together and move forward from one base. What is currently in the ceekdee github repository is simply an attempt to capture some goals from our previous discussions.

While there is much left to be implemented, I hope enough is there to start discussing architecture and course corrections. I have been working with nrf52840 and stm32wl55 with sx1262, and have an STM32L0  with sx1276 on order. I also have an rp2040 on order, and once I understand how to get that to work with Embassy, I plan to order some Semtech chip for that.

[lulf]

@lulf: See the previous comment for some background information. Updates follow.

Enough of the LoRa physical layer processing refactor is completed to allow a discussion if this is on track to:

1. provide a LoRa physical layer API that supports both P2P and LoRaWAN for various LoRa chips;
2. define a reasonably limited interface for the unique aspects of each RTOS/MCU/LoRa chip combo;
3. otherwise depend on only embedded-hal-async, opening up LoRa physical layer processing for a range of developments outside Embassy, as long as the RTOS supports embedded-hal-async.

In short, is this on the way to meeting the goals we have discussed?

I think this is spot on, thanks for putting in the work so far 🚀

The evolving LoRa physical layer API (only flushed out so far for the SX1261/2 Tx path; see the commented out code to get an idea of what remains) is here:

https://github.com/ceekdee/lora/blob/main/lora/src/lib.rs

A stm32wl example using it (Tx only) is here:

https://github.com/ceekdee/embassy/blob/master/examples/stm32wl/src/bin/lora_p2p_send.rs

An nrf example (setup only) is here:

https://github.com/ceekdee/embassy/blob/master/examples/nrf/src/bin/lora_p2p_receive.rs

The trait for the interface between the MCU and LoRa board is here:

https://github.com/ceekdee/lora/blob/main/lora/src/mod_traits.rs (the InterfaceVariant trait)

I think all of the above makes sense in general and I won't nitpick on stuff right now. This very much aligns with my interpretation of what we agreed!

A couple of implementations are here:

https://github.com/ceekdee/embassy/blob/master/embassy-stm32/src/lora.rs https://github.com/ceekdee/embassy/blob/master/embassy-nrf/src/lora.rs

Note that these additions to Embassy allow the existing Embassy LoRa implementations and examples to co-exist with the new lora crate. The transition between embassy-lora and a separate lora crate for the guts of LoRa physical layer processing should be reasonably straight-forward.

Each kind of LoRa chip will have a separate implementation of the RadioKind trait:

https://github.com/ceekdee/lora/blob/main/lora/src/mod_traits.rs (only fleshed out for SX1261/2 for the Tx functionality currently).

I am reasonably confident that the three functions here:

https://github.com/ceekdee/lora/blob/main/lora/src/interface.rs

will handle all of the known ways (OpCode vs. Register methods) that Semtech currently uses for their SX126x and SX127x chips.

In order for this new lora crate to be adopted:

1. (perhaps my opinion only, but I’d like to set clear domain boundaries) existing LoRaWAN implementations will need to change to recognize which attributes are controlled at the LoRa level and which are controlled at the LoRaWAN level. For instance, enums for bandwidth, spreading factor, coding rate, and the like would come from the lora crate. The lora crate should be agnostic to P2P and LoRaWAN usage. LoRaWAN-specific traits would be defined and implemented elsewhere to use the LoRa API in the lora crate.

I think that's a valid goal. On using/requiring reexporting types from lora, I think requiring something like Into<SpreadingFactor> for the lora crate APIs could allow the best of both worlds: reuse existing types from lora crate or your own types that are guaranteed to translate to the lora types. This could allow some interop with types from https://github.com/rust-iot/radio-hal if it gets merged.

2. there will need to be some consensus on where the lora crate should live (certainly not in the ceekdee github repository). I have tried to incorporate many of the good ideas from other LoRa implementations, and I hope we can all come together and move forward from one base. What is currently in the ceekdee github repository is simply an attempt to capture some goals from our previous discussions.

I think hosting the repo in the embassy org could be fine if you're OK with that. Otherwise as long as it gets maintained I think it can live anywhere.

While there is much left to be implemented, I hope enough is there to start discussing architecture and course corrections. I have been working with nrf52840 and stm32wl55 with sx1262, and have an STM32L0  with sx1276 on order. I also have an rp2040 on order, and once I understand how to get that to work with Embassy, I plan to order some Semtech chip for that.

There should be plenty of examples for that, and it implements embedded-hal-async already so hopefully you should be good to go :)

Thanks for putting this amazing amount of work, it's great to see it all coming together!

[ceekdee]

@Dirbaio , @lulf :

We are at the next discussion point for this implementation. There is much context above, but the README file and associated documentation is now the best reference:

https://github.com/ceekdee/lora

Questions:

• will the LoRa physical layer crate have value to the embedded community?
• if so, where should the crate live? We discussed placing it in Embassy previously, but I believe it needs to live outside any embedded framework, as it seeks to be of value everywhere embedded-hal-async is supported. On that note, perhaps it might be placed in:

https://github.com/rust-embedded

but I am new to the embedded community and do not know the challenges involved in placing the crate there.

• are the Embassy updates proposed to use this crate in Embassy acceptable (best to follow the links from the README file to evaluate this)?

I believe the stm32l0/sx1276 and nrf/sx1262 support in the lora crate is on track to be more useful than that in embassy-lora (and I can speak authoritatively on nrf/sx1262 ... :) ). I took the approach to stm32wl that it has an sx1262, so it should be possible to use the newer sx126x implementation as base, referring to the Embassy subghz implementation for inspiration where the STM folks tried to subsume the sx1262 in their own machinations. I imagine there will be a few gear grindings in their machine to overcome, but the Embassy subghz implementation helps immensely.

[lulf]

@Dirbaio , @lulf :

We are at the next discussion point for this implementation. There is much context above, but the README file and associated documentation is now the best reference:

https://github.com/ceekdee/lora

Questions:

• will the LoRa physical layer crate have value to the embedded community?

I think it would, as it would be a useful source for writing new drivers and reusing code between them.

• if so, where should the crate live? We discussed placing it in Embassy previously, but I believe it needs to live outside any embedded framework, as it seeks to be of value everywhere embedded-hal-async is supported. On that note, perhaps it might be placed in:

https://github.com/rust-embedded

but I am new to the embedded community and do not know the challenges involved in placing the crate there.

I think projects that end up in rust-embedded tend to be crates that span the entire ecosystem, like the cortex-m crates for instance. Moving this repo there is going to be a hard sell I think, because of the required process for all WG repos.

Another alternative could be the rust-embedded-community org, which is a bit like 'org for embedded crates in the community that don't belong to a particular project'.

However, I would argue that this repo could live in the embassy-rs org, because it's focused on async, and embassy is a community of various embedded async projects.

• are the Embassy updates proposed to use this crate in Embassy acceptable (best to follow the links from the README file to evaluate this)?

Assuming we can get all the existing lora examples working, I think it makes sense to do that.

Looking at https://github.com/ceekdee/embassy/blob/master/embassy-stm32/src/lora.rs - I think we should make sure dependency on lora crate is optional and only enabled via some feature flag or based on the 'subghz' feature.

I believe the stm32l0/sx1276 and nrf/sx1262 support in the lora crate is on track to be more useful than that in embassy-lora (and I can speak authoritatively on nrf/sx1262 ... :) ). I took the approach to stm32wl that it has an sx1262, so it should be possible to use the newer sx126x implementation as base, referring to the Embassy subghz implementation for inspiration where the STM folks tried to subsume the sx1262 in their own machinations. I imagine there will be a few gear grindings in their machine to overcome, but the Embassy subghz implementation helps immensely.

I'd be happy to test out this driver on stm32wl. Is your embassy fork the best place to try it out?

[ceekdee]

@lulf:

Feature flag external-lora has been added to make the lora crate optional.

ceekdee@416b6d1

The lora crate is still needed for some of the examples for stm32wl, stm32l0, and nrf52840, but the lora crate is optional when building one's own application. The flag has not been extended to make the LoRa implementations in embassy-lora optional. Perhaps we will do that later, but it seems premature currently.

[lulf]

Couple of comment reviewing this:

• I don't think embassy-nrf should have a dependency on lora, because the Nrf52840InterfaceVariant doesn't really have anything to do with embassy-nrf at all does it, it just relies on embedded-hal-async.
• Same for embassy-stm32, the stm32l0 interface variant also doesn't really have anything to do with embassy-stm32 HAL, only embassy-sync and embedded-hal-async. It's more like a generic Sx1276Interface?
• For the STM32WL variant, there is a dependency on embassy-stm32, so that's a special case I think, but one can access the pac outside the embassy-stm32 crate if enabling a feature, so I think it could live outside as well.

Wrt. the existing implementations, I think they can be removed when embassy-lora is migrated to use the lora crate instead of the builtin drivers. I wonder if the interface variants should be placed there, because it seems to become the integration point between lorawan-device, embassy and the lora crate.

My only reservation is the current Subghz implementation for stm32wl, and if there are features in the stm32wl variant of sx126x that is missed by removing the current Subghz impl in embassy.

Thoughts?

[ceekdee]

The update:

ceekdee@caa072c

consolidates InterfaceVariant processing in embassy-lora, updating embedded-hal there to:

embedded-hal-02 = { package = "embedded-hal", version = "0.2.6", features = ["unproven"] }

for consistency with other Cargo.toml instances. This still keeps the original LoRa implementations independent of the implementation for the external lora crate - both features sets are still available. We can deprecate and then remove the original LoRa implementations once there is significant usage and testing of the new lora crate features.

[ceekdee]

@Dirbaio, @lulf:

Following is a proposal to expand LoRa functionality using Embassy. I am sure there are considerations I am missing, but I believe there is enough substance here to warrant moving forward.

• https://github.com/ceekdee/lora
  -- move this repository to embassy-rs;
  -- prepare v1.0.0 within the embassy-rs lora crate repo, then place in crates.io.

• https://github.com/ceekdee/embassy
  -- make necessary updates to reference the version of the lora crate on crates.io, then submit an embassy PR.
  -- deprecate the existing embassy-lora sx126x and sx127x implementations, but leave the stm32wl implementation as-is for the time being.

• https://github.com/ceekdee/rust-lorawan
  -- submit a rust-lorawan PR to add support for a PhyRxTx implementation using the lora crate.

• update embassy examples to include lorawan examples using rust-lorawan and the lora crate, after figuring out how to reference the appropriate version of rust-lorawan that includes the PhyRxTx update.

[lulf]

I'm not sure if you meant to perform the steps in the order you wrote them, but overall I agree with them. Some comments below.

@Dirbaio, @lulf:

Following is a proposal to expand LoRa functionality using Embassy. I am sure there are considerations I am missing, but I believe there is enough substance here to warrant moving forward.

* https://github.com/ceekdee/lora
  -- move this repository to embassy-rs;
  -- prepare v1.0.0 within the embassy-rs lora crate repo, then place in crates.io.

This sounds like a good idea. I think @Dirbaio who owns the organization would need to agree and accept this. I'm also wondering if lora-radio is a more descriptive name of the crate?

* https://github.com/ceekdee/embassy
  -- make necessary updates to reference the version of the lora crate on crates.io, then submit an embassy PR.
  -- deprecate the existing embassy-lora sx126x and sx127x implementations, but leave the stm32wl implementation as-is for the time being.

I think it's fine to remove the embassy-lora implementations assuming the new ones work, we don't have any backwards compatibility guarantee for unreleased crates, and overall I think it would be less work to just remove it.

* https://github.com/ceekdee/rust-lorawan
  -- submit a rust-lorawan PR to add support for a PhyRxTx implementation using the lora crate.

* update embassy examples to include lorawan examples using rust-lorawan and the lora crate, after figuring out how to reference the appropriate version of rust-lorawan that includes the PhyRxTx update.

I think these last two should be done before the lora crate integration, so that we don't keep things in an intermediate step. I can help with review and releasing a new version of the rust-lorawan crate, so that it can be used in embassy.

[ceekdee]

Issue resolved by PR #1396.