This repository has been archived by the owner on May 18, 2022. It is now read-only.
Design a better hardware/radio interface #48
Labels
area: hal
Code Area: Radio hardware interfacing code
status: needs design
Needs design work (API, communication between components, etc.)
type: enhancement
A new feature or an improvement for an existing one
The current interface relies on undocumented assumptions and isn't very clean. It should be fixed before we start supporting more MCUs to avoid introducing too much technical debt.
(the timer interface is basically fine at this point, this issue is about the radio interface)
For example, the
transmit_advertising
andtransmit_data
methods on theTransmitter
trait behave very differently sincetransmit_data
also ensuresT_IFS
is respected. This isn't really wrong, but it should also be done bytransmit_advertising
, except when we're just a beacon. The solution for this, I think, is to split theTransmitter
trait into "beacon-only" and "connection" functionality:T_IFS
). It's very simple to implement.T_IFS
, on both advertising and data channels. It is more difficult to implement.Another problem @Chocol4te has faced is that the current
BleRadio
implementation for the nRF52810 only works with a properLinkLayer
, and doesn't allow plugging in aBeaconScanner
. This is ultimately an interface decision made by the device crate, but maybe we can find a solution in Rubble itself (perhaps via some sort ofPacketSink
trait?) that makes this easier.The text was updated successfully, but these errors were encountered: