Bleps on nRF about bleps

[bjoernQ]

Hi!

Great to hear you were able to use it on nRF52! Would be nice to see it on something other than ESP32-xx (actually the predecessor of this was targeting some other RISC_V BLE/WIFI MCU)

Replace embedded-io/embedded-io-async with a HciDriver trait which operates on HCI packets. This maps better to non-serial HCI interfaces. (Serial adaption wrappers can be built)

An HciDriver operating on HCI packets is probably the right thing to do. Actually in esp-wifi we serialize the packets we get from the driver into embedded-io-* streams which isn't too smart.

Refactor the current blocking/async approach into something event-driven and build async on top of that, which should remove most of the duplication that's there now and perhaps work better with multiple connections.

The whole async thing here was introduced in a quite hacky way - your suggestion sounds like a good idea.

The statement on the front page is mostly to lower expectations. I started this since I wasn't able to find anything useable and t.b.h. I was hoping for the community to come up with something else (which didn't happen yet).

I would really like to see something "more serious" - I don't care much if that would be bleps, a hard-fork of bleps or even a rewrite which might or might not be based on bleps. But definitely contributions are very welcome

[lulf]

I'm closing this issue for now, I got my question answered :) Happy to make some PRs to bleps eventually. I'm currently spending some time exploring what APIs make sense and reading specs, so it will probably spend some time in my own fork. I'll come back once I have something ready for a wider audience.