rust-iot / radio-hal Goto Github PK

Hi @ryankurte,

I am working on bindgen'ing OpenThread (https://gitlab.com/markushx/opentrust/) and am looking for an easy way to fulfil its required platform functions.

Several questions:

• Would it be possible to use rust-radio-hal for the radio-related platform (https://docs.rs/openthread-sys/0.1.4/openthread_sys/all.html?search=otPlatRadio and https://docs.rs/openthread-sys/0.1.4/openthread_sys/all.html?search=otPlatBle) functions?
• How actively is the radio HAL maintained currently?
• Is there a HAL implementation for nrf52/53?

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.

Seems like the CI is broken since we updated the embedded-hal version: e3e2350

@ryankurte hint hint ;)

I'm looking into somewhat similar as discussed in #6 (a prototype that relies on OpenThread for communication, based on NRF52*).
Can https://github.com/braun-embedded/rust-ieee802.15.4 be used with radio-hal or at least some effort coordinated?

Now async/await has landed it should be possible to implement async functions over the existing pollable traits.

A mock driver would be useful for testing radio consumers

Should be possible to implement default blocking and non-blocking modes over existing traits to minimise complexity for users who do not need explicit control of the device state.

unresolved import `embedded_hal::delay::blocking`

Path which would resolve in alpha v7 but is not working properly in alpha v9

Consider using an exact version specifier like this:

embedded_hal = "=1.0.0-alpha.7"

with the updated register trait (#19) we need to go and write out the registers for existing radios to use this new API. this is basically just a bunch of wrote-copying from datasheets, see radio-at86rf23x [1, 2] for an updated example.

• radio-at86rf212
• radio-sx127x
• radio-sx128x

This is an issue I encountered when implementing LoRaWAN device behavior. When a class A device transmits a message, it should first wait 1 second and then try to receive a message on the RX1 channel. If it doesn't receive anything, it should wait until 2 seconds after transmission and try to receive on RX2. The problem is that receiving a message can take longer than a full second.

The current implementation of do_receive returns when it either completely received the message, or when a timeout occurs. Setting the timeout to 1 second will also discard any message that is currently being received (unless the implementation of check_receive blocks the thread until it can return true, but that is undesirable, as it is also used for the nonblocking traits), so the timeout must be longer than 1 second, but then the radio will be too late to switch to RX2 if it doesn't receive anything on RX1. Therefore, I think the radio traits should be able to determine whether or not a radio is busy receiving an actual message, even before having received it completely.

One simple solution could be to add a oneshot_receive method to BlockingReceive, which is identical to do_receive but with self.check_receive(false) instead of self.check_receive(true), but I'm not sure if that's the best option. Would love to know what others think about this!