You all love the @PINE64 #Pinephone, right?
You also like #LoRa, right?
If so, you'll love this : LoRa on the Pinephone!
YES, thanks to the LoRa backplate, you can send and receive LoRa messages on the Pinephone!
https://codingfield.com/blog/2021-11/a-driver-for-the-pinephone-lora-backplate/
CC: @lupyuen
1/3
Flashing the LoRa backplate for the PinePhone
https://codingfield.com/blog/2021-11/flash-the-lora-pinephone-backplate/
3/3
hi @JF can you give me a quick explanation on the buffer sync in your c++ driver? I'm trying to write a python driver and so far cannot get anything to work, wondering if it's related to not performing this sync. https://codeberg.org/JF002/pinedio-lora-driver/src/branch/master/src/pinephone/PinephoneBackplate.cpp#L113
@captain_morgan That part is a bit tricky. When you write data, the I²C bridge transmits them to the SPI device. At the same time, all data read on the SPI side will be stored in a ring buffer. Your app can then read this ring buffer from I²C. However, the bridge provides no way to know how many bytes are available or to clear the buffer. It means that you have to ensure that your app will read each and every bytes from this buffer, no less, no more.
@captain_morgan I wrote the sync procedure to ensure that the read buffer is "empty", and that the next bytes I'll read are the ones coming from the request I'll send. For this, I send a command to the SX1262 for which I know exactly what it'll answer. Then I read the whole ring buffer until I read the data I expected to read. When finished, I know that the read cursor on the ring buffer is correctly positioned.
@JF Awesome, this answers a bunch of questions, like how to handle reset states. Will give the python code another go this evening.
@captain_morgan This is needed because you don't know what happened on the I²C bus before you app is started : maybe a previous app crashed leaving the buffer in an inconsistent state, maybe a few glitches were generated while the phone was booting (and those glitches could have been interpreted as valid clock/data signal,...
You can have a look at this code to check how the bridge firmware is working : https://github.com/zschroeder6212/tiny-i2c-spi/blob/master/src/main.c#L67