Make SPI pins (MOSI, MISO, SS, SCK) configurable in struct lmic_pinmap

[cyberman54]

using format compatible to pins_arduino.h, like

// SPI LoRa Radio
#define LORA_SCK 5      // GPIO5  - SX1276 SCK
#define LORA_MISO 19    // GPIO19 - SX1276 MISO
#define LORA_MOSI 27    // GPIO27 - SX1276 MOSI
#define LORA_CS 18      // GPIO18 - SX1276 CS

[terrillmoore]

Thanks for your contribution. I want to do this, but it will take a slightly different approach.

1. Any change to lmic_pinmap is a breaking change for everyone depending on this library. So we need to push this info into the package in a different way. I broke a bunch of MCCI libraries the last time I changed this, and given how much use this library is getting, I don't want to break everybody.

   I have a pending change to add an "IOCTL" function so that the portable code can send messages to the "hal" code. That way, if more info is needed, we don't break platforms that don't need to use it. This is needed for platforms like the Murata module that need TCXO control. We can add a new lmic_init variant that passes in the IOCTL function pointer, and set things up so that if platforms don't use this, there's no impact.

2. Different board support packages handle SPI initialization different ways -- the breaking compiles for non-Adafrut show this clearly. I don't think there's a way to do this portably in the LMIC code -- instead, the LMIC code has to call a method function (as it were) of the platform, using the ioctl function mentioned above.

3. I have heard that the RFM95W has a pull-down resistor on (active-low) NSS (so you don't have to hook up more than two wires). So, actually, idling NSS high in between operations is bad for power use. Instead, after stopping the clock, we should restore the CS to the "best idle state". We can't do that -- it's a platform issue, but we can at least notify the platform that we're through with SPI for now.

I'm in the middle of a delivery cycle for another project, so it will probably take me a week or so to make a concrete suggestion that you can then test.

[terrillmoore]

OK, I had a chance to look more closely at this. Unfortunately, the Adafruit BSP doesn't have a SPI.begin() that takes 4 arguments. Instead their SPI instances are tied to specific hardware ports, and the pins are configured elsewhere.

So we can't portably support configuring via the SPI pins via the LMIC pin table. What we we can do, once we add IOCTL support, is add a getter to fetch a pointer to the SPI in use. Then (perhaps combined with #158) we would use pSpi->X() to access the SPI method X rather than SPI.X(). This would let the advanced user configure different SPI ports or software SPI.

[cyberman54]

@terrillmoore this approach sounds reasonable to me. Too bad that SPI pins are hardwired in Arduino.

[terrillmoore]

Closed by #190