Implement BLE KISS support

[cfr34k]

It would be nice if this firmware would support KISS over BLE, following the existing specification. This would provide a generic interface to send and receive LoRa-APRS packets.

Necessary steps:

• [ ] Add the specified services and characteristics.
• [ ] Allow packets to be queued for transmission internally.
• [ ] Implement a conversion between the text-based APRS frame format and AX.25.
• [x] Find an app to test with, or write some test scripts.

[glxplz]

I would really like to try using the T-Echo with the codec2talkie therefore i think this would be the missing feature. I think some code could be reused from esp32_loraprs.

[cfr34k]

Interesting idea! And finally there’s an Android app I could test against :)

Unfortunately, I don't really have the time currently to start implementing this feature. It’s quite some work because some new infrastructure would be needed, especially since codec2talkie will probably require a faster modulation settings than the usual LoRa-APRS. I need to think about that, so please don't expect an update in the next few weeks.

[glxplz]

Hey, no pressure at all. I am thinking of rewriting the project in Rust as there are plenty of libraries available to do some of the heavy lifting like nrf-hal, bme280-rs, embedded-graphics and not to forget aprs-parser-rs. But similarly to you i don't have that much spare time on my hands. Did you ever create an architecture diagram of your code that you could share?

[cfr34k]

A Rust program on the T-Echo would be interesting. I wrote a small firmware for the Raspberry Pi Pico some time ago in Rust, but I can't say that I had the feeling that I „did it right“ most of the time :D . So a rewrite of this firmware would be something I could learn from, I think.

There’s not much documentation of the internals, unfortunately. Just two notes that may help if you want to read the code:

• Everything is event-driven (by interrupts or timers). The Nordic framework therefore calls callback function whenever something happens (for example, timers expire, BLE packets arrive, SPI transmissions complete, etc.). As there are no blocking calls, the peripheral drivers (ePaper, LoRa module, GPS), are implemented as state machines that send a command to the module and then return. When the command is complete, a callback function advances the state and sends the next command or calls a callback function with an Event Code. Most high-level events are handled in main.c.
• I tried to document the functions using doxygen comments. I'm not sure right now how complete that is, but it may help as well. If you don't want to set up Doxygen, just look at the header files.