RFM95 enable frontend TX / RX support

[pdgilbert]

I have an RFM95 like radio working in my testing. It uses 9 pins: gnd, vcc, nss(cspin), reset, DIO0, DIO1, and spi(sck, miso, mosi). I can also successfully run my tests using an Ebyte E19-915M30S described in the manual at http://www.ebyte.com/en/product-view-news.aspx?id=223. (See also the description for a slightly different form factor of the same radio in an Arduino project at https://github.com/beegee-tokyo/SX126x-Arduino/#explanation-for-txco-and-antenna-control)

This radio has two additional pins RXEN and TXEN to "enable the antenna" for rx and tx. (I'm not sure what these do, if it is really just PA boost or not?) These I can hard wire, for transmit vcc to TXEN and gnd to RXEN, and the reverse for receive. This works for my testing, which only does one or the other, but it seems like these should be under software control. Is there something I am missing in rust-radio-sx127x to do this?

[ryankurte]

I have an RFM95 like radio working in my testing

neat! this should pretty much just work?

This radio has two additional pins RXEN and TXEN to "enable the antenna" for rx and tx. Is there something I am missing in rust-radio-sx127x to do this?

i'd guess it's enabling the RX or TX paths through the frontend (which may well involve a PA) it's not currently included in the driver.

to work around this one option would be to set the right pins when you change modes in your application (start_transmit(), start_receive(), etc.), though, it's a bit tricky to manage if the state changes internally to the driver.

if you're interested in adding this as feature i think the best approach would be to extend the Base type with enable_tx() and enable_rx() methods with null implementations, and call them from the appropriate places in the driver, then to create a container type that implements Base for your the types in your application and overrides these two functions, though i am definitely open to other ideas if you have em!

[pdgilbert]

I have an RFM95 like radio working in my testing

neat! this should pretty much just work?

Yes, pretty much just works. At least with master branch. When you update-everything I'll rework my tests and put together better examples.

i am definitely open to other ideas if you have em!

Ideas on this are well beyond my current understanding of the crate, and Rust, and embedded. I do see that it would be really nice if the hal is able to handle some radio differences in a way that makes application code more generic. I also see that might have design implications in the crate. In looking around I had the impression that the RXEN and TXEN pins are on some other manufacturers' boards too.

So this should probably be marked as a feature request. No special rush for me.

BTW, also (accidentally) got a LoRa radio with USART interface so I'll play with that when you get around to implementing it.

[ryankurte]

I do see that it would be really nice if the hal is able to handle some radio differences in a way that makes application code more generic.

v much agreed, the tricky thing with rust is how to balance this with the type system. i have done some truly cursed things in other projects to achieve this 😅

Ideas on this are well beyond my current understanding of the crate, and Rust, and embedded So this should probably be marked as a feature request. No special rush for me.

alrighty, i don't have a lot of time to dedicate to working on this so, don't expect it quickly. that said, if you would like to attempt the approach i proposed above i'd be happy to coach you through it! this would look something like:

• [ ] Create a FrontendMode enumeration for Rx, Tx, Disabled
• [ ] Add a configure_frontend(mode: FrontendMode) -> Result<(), Error<...>> to Base with an empty default impl that just returns Ok(())
• [ ] Add calls to configure_frontend through the driver as appropriate (ie. before entering / after leaving tx and rx states, probably just in the set_state function)

then in your application you would create a struct SpiWithFrontend that takes the normal things as well as the rx and tx enable pins and implements the Base trait.

once it's all working we genericise the wrapper and move this and the configure_frontend function out into a ConfigurableFrontend trait in the radio-hal crate but, it's easier to start specific and work towards generic later imo, and the trait-magic to make this work may be a wee bit tricky.

BTW, also (accidentally) got a LoRa radio with USART interface so I'll play with that when you get around to implementing it.

so i don't have any radios running in USART mode yet, but, this is why the Base abstraction exists ^_^ the idea is that this could also be implemented over something implementing the embedded-hal serial traits.

[pdgilbert]

Ok, I'll play with this once I get my examples working again after update-everything. I'm sure it will be a good learning exercise, but possibly a bit advanced for my current skill level. Hope you won't regret the offer to coach. I'll try not to be too demanding.

[pdgilbert]

This issue is out-of-date and effectively resolved.