spi_master for AVR

[fauxpark]

Description

Pulling the SPI code up out of the BLE stuff so we can reuse it. Also replaced as much of the AVR-specific code as I could see, to facilitate Arm support by simply dropping in an appropriate spi_master.

Feel free to point out any dumb mistakes.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• fixes Changing SS Pin for SPI Bluetooth Communication #3187

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[drashna]

Need to test the Ploopy with this, but otherwise, I think it looks good, and travis doesn't object.

[tzarc]

I think we should mirror the i2c driver, and add spi_start/spi_stop.
There will be cases where we might need to change the SPI speed, polarity, and mode, depending on the device that's being talked to.
It would also allow us to specify the pin for slave select, so that manual handling of the slave select isn't required.

[tzarc]

Speed

• in the case of Arm we'd be setting a divisor; I'm not sure what AVR requires
• accept an uint8_t

Polarity/phase:

• https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Mode_numbers
• accept an int8_t

Suggested API:

• void spi_start(some_pin_t slavePin, uint8_t clockDivisor, int8_t spiMode);
• void spi_stop(void);

[fauxpark]

LUFA's implementation of I2C has equivalents for i2c_start()/i2c_stop() in TWI_StartTransmission() and TWI_StopTransmission(), but it seems like it's not really a "thing" for SPI: https://github.com/abcminiuser/lufa/tree/master/LUFA/Drivers/Peripheral/AVR8
I'm not really sure what a stop function would do in the context of SPI. There is no real setup or teardown to speak of, you just put a byte in the register, wait for the SPIF flag, then take a byte out.

[tzarc]

Yep, that's fine, but in the context of whether we want to start and stop communicating with a device, the slave select pin needs to be toggled.

I'm also thinking from the Arm side of things -- ChibiOS's SPI driver does indeed need start/stop, so if we "train" people to use the start/transmit/receive/stop methodology then anyone who wants to swap from an AVR-based design to an Arm-based design won't require extra messing about trying to understand why it works for one and not the other.

[fauxpark]

Got it. How's this for a start:

static pin_t currentSlavePin = NO_PIN;

void spi_start(pin_t slavePin) {
    if (currentSlavePin == NO_PIN && slavePin != NO_PIN) {
        currentSlavePin = slavePin;
        writePinLow(currentSlavePin);
    }
}

void spi_stop(void) {
    if (currentSlavePin != NO_PIN) {
        writePinHigh(currentSlavePin);
        currentSlavePin = NO_PIN;
    }
}

[fauxpark]

With this last commit I've added spi_start(slavePin) and spi_stop(void), however they don't seem to be working... any ideas?

Debug console just keeps printing this:

  > sdep_recv_pkt failed
    failed BLE command: ATE=0: 

and the board will occasionally spam a or b (the two keys I have mapped for testing) briefly, only over USB.

[fauxpark]

Okay, strange. A sprinkling of dprintf in spi_start/spi_stop shows they are both being called, but the sanity check in spi_start is not passing, even though currentSlavePin == NO_PIN (0xFF) and slavePin == 0x34 (B4). Wrapping each side of the && in parentheses didn't help. I'm missing something obvious here.

[fauxpark]

Figured it out. The NO_PIN define was not cast to pin_t, causing it to default to int16. Assigning it to currentSlavePin truncated it to 0xFF. So it was trying to compare that to the original 0xFFFF, and of course, failing.

[tzarc]

Docs look good.

[zvecr]

Brief test on my 34u2 bluefruit - seems happy enough.

@yanfali any chance you could test your fruity60?

[tzarc]

@yanfali confirmed fruity60 working.