search

rust-iot / radio-hal

Embedded rust radio abstraction crate
https://ryan.kurte.nz/notes/2020-01-05-rust-radio
MIT License
71 stars 13 forks source link

rfm95 Support #9

Closed BlinkyStitt closed 4 years ago

BlinkyStitt commented 4 years ago

Hello! I'm just starting a project and was planning on using a rfm95 lora radio. It looks like you don't yet have support for lora, but I was wondering if you have put any thoughts into it yet. I'm not ready to write this part of the code yet, but would be happy to help.

ryankurte commented 4 years ago

I believe the rfm95 is driver compatible with the sx127x series (though I have not tried it). I do have ryankurte/rust-radio-sx127x for these devices, which provides lora and gfsk support, using this crate (though it is in need of an update due to some churn both here and in embedded-hal).

I have been planning to extract the LoRa modulation enums from the sx127x and sx128x drivers to provide a lora module in this crate and a common LoRaChannel that can be used with the Channel trait to support generic use of LoRa compatible radios.

If this meets your requirements I'd be happy to accept PRs! And if you have other ideas I'd be interested to hear em.

BlinkyStitt commented 4 years ago

Thanks! I think it would.

I'm not set on using the rfm95 yet, it's just what I happen to have right now (from the prototype of this project that I wrote in C). It does look like it is compatible with the sx127x.

Is there a module you'd recommend? I just care about having good range so LoRa sounded like the right thing to use. Existing support for rust would be great. I don't want to spend too much time writing libraries for specific hardware when a library for something similar already works. Although I definitely expect to be writing some library code since embedded rust is so new still.

On Jul 11, 2020, at 11:41 PM, Ryan notifications@github.com wrote:

 I believe the rfm95 is driver compatible with the sx127x series (though I have not tried it). I do have ryankurte/rust-radio-sx127x for these devices, which provides lora and gfsk support, using this crate (though it is in need of an update due to some churn both here and in embedded-hal).

I have been planning to extract the LoRa modulation enums from the sx127x and sx128x drivers to provide a lora module in this crate and a common LoRaChannel that can be used with the Channel trait to support generic use of LoRa compatible radios.

If this meets your requirements I'd be happy to accept PRs! And if you have other ideas I'd be interested to hear em.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

BlinkyStitt commented 4 years ago

So the rfm95 (at least the one I'm using: https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module/pinouts) doesn't seem to have a busy_pin. What should I do to skip that pin?

ryankurte commented 4 years ago

it's probably due a rename (or document) but BUSY is DIO0 and READY is DIO1 as they are configured by default, so you should be able to just use them.

BlinkyStitt commented 4 years ago

Thank you! That’s very helpful. Those are available on this feather, they just aren’t pre-wired.

On Jul 19, 2020, at 5:07 PM, Ryan notifications@github.com wrote:

it's probably due a rename (or document) but BUSY is DIO0 and READY is DIO1 as they are configured by default, so you should be able to just use them.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ryankurte/rust-radio-hal/issues/9#issuecomment-660731913, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEYMXNW7OJ52XLIAOVT4K3R4ODCPANCNFSM4OXU6YUQ.

ryankurte commented 4 years ago

No worries! The SPI protocol leans heavily on BUSY to wait for radio command responses, so if possible you'll need to wire that up (or make some not insignificant mods to the library).

This library doesn't use READY yet, so you should be alright without that. It is however particularly useful to avoid polling on state (which you can see in the sx128x driver), so I would recommend wiring it if you can.

To support both having and not-having either pin we would need a default impl of is_ready() in the base that uses SPI to check for masked interrupts, with a specific impl for types where READY (or DIO1) implements InputPin, this has been on the list for a while but again, it's a wee bit tricky and not critical for my use so hasn't been done yet.

I also always intended to rename the types to DIO0-1 but never got around to it, happy to accept PRs doing any of these things if you like.

BlinkyStitt commented 4 years ago

tl;dr: yes, use https://github.com/ryankurte/rust-radio-sx127x