Work towards a "generic" LoRa interface?

[jwetzell]

There is some work here in this repo which has also been moved to the newer? wireless repo that relates to an interface that could be implemented by a driver here. Curious what cleaning up/refreshing this as well as modernize for what newer (sx128x) chips can do! I currently have dev boards with both SX1262 and SX1280 chips and am almost finished with a basic sx128x driver.

Examples of such a "high-level" abstraction over the radios is something like RadioLib

[jwetzell]

Some other lora work by @soypat I particularly like the Frequency and other type stuff very reminiscent of time.Second and such which might be of some use to the wireless repo as a whole.

[soypat]

I'm all for following both the lora.Config data structure and I/O api proposed in my project as it would be less bug prone than the current channel driven interface. I'd love to help from the sidelines for now though as I am limited in time.

[jwetzell]

Besides only mentioning channels in a comment in the radio_events file there really isn't any channel use in the interface itself difficult to compare that interface to your repo as yours doesn't have a "high level" LoRa API as far as I can see.

The underlying drivers that currently exist do use channels in their implementation though mostly as an alternative to continuous pin polling (which actually is broken when I tried to test the sx126x driver). They also assume there is SetInterrupt support on machine.Pin which is probably bad drivers practice from what I can tell. Blocking Rx/Tx like an RxSync or TxSync.

[soypat]

Yeah, the SetInterrupt is not great design. I'd propose an API that allows for interrupt driven drivers but that does not have hardware constraints:

package lora

type Device interface {
   Tx(packet []byte, timeoutMillis uint32) (err error)
   SetRxCallback(cb func(rxpkt []byte))
   RxPoll(buf []byte, timeoutMillis uint32) (int, error)
}

Inspired by many learnings with networking devices and looking at how other libraries do asynchronous receive.

[jwetzell]

Yeah, that makes sense I was curious if there was any convention for naming or interacting with sync vs. async things in Go world.

[soypat]

When talking async my mind usually goes to exec package.
Synchronous: https://pkg.go.dev/os/exec#Cmd.Run

Async: https://pkg.go.dev/os/exec#Cmd.Start