MSSP SPI von PIC = Kuriosität, aber Bit-Banging funktioniert?

Ich versuche, einen PIC16LF1825- Master dazu zu bringen, mit einem ADXL362- Slave über SPI bei 1,8 V zu kommunizieren.

Zuerst habe ich den MSSP (serieller Port des PIC) ausprobiert, der für Hardware-SPI bei 4 MHz FOSC, 1 MHz SPI-Rate (mindestens die von ADXL empfohlene) bei 3,2 V konfiguriert ist. Es hat irgendwie funktioniert und den folgenden SCK und MOSI für den ADXL produziert:

Beachten Sie, dass MOSI zwischen den Bytes hoch gehalten wird. Das erste gesendete Byte ist 0x0B (Leseregisterbefehl), gefolgt von 0x00 (Geräte-ID). Das dritte Byte sollte also die zurückgegebenen Daten sein ...

Was der ADXL jedoch zurückschickte, war falsch. Es sollte 0xAD sein, aber stattdessen bekam ich alle möglichen falschen Werte, 0x90 wird angezeigt. Ich habe alle CPOL- und CPHA-Modi ohne Erfolg ausprobiert. Wird das MOSI zwischen den Bytes hoch gehalten, was zu einer Beschädigung der interpretierten Daten durch ADXL führt? Würde ich nicht glauben ... Das Seltsamste ist, dass sich dieser zurückgegebene Wert scheinbar zufällig ändert, obwohl nichts sichtbar mit SCK oder den anderen Pins passiert ist. Ich habe nach einem Muster mit möglichen zurückgegebenen Werten gesucht (zeigte es tatsächliche Registerinhalte an?), fand aber keine Korrelation. Das Trennen der Oszilloskopsonden (parasitäre Kapazität) hatte keine Wirkung. Der XC8-Code, den ich ursprünglich ausprobiert habe, sah so aus:

/* Routine to fully exchange a byte with the ADXL362 - requires MSSP */
extern uint8_t ExchangeADXL(uint8_t txCommand, uint8_t txAddress, uint8_t txData) {
    SS_ADXL_SetLow();           // SS low
    SSP1CON1bits.WCOL = 0;      // clear any write collision flag

    SSPBUF = txCommand;         // send read/write/fifo byte
    while (!SSP1STATbits.BF);   // wait for exchange

    SSPBUF = txAddress;         // send address byte
    while (!SSP1STATbits.BF);   // wait for exchange

    SSPBUF = txData;            // send byte or dummy byte
    while (!SSP1STATbits.BF);   // wait for exchange (read result)

    SS_ADXL_SetHigh();          // SS high
    return (SSPBUF);            // return result
}

Dies verwendet den Microchip Code Configurator (MCC), um eine Grundkonfiguration für das Gerät zu generieren (Zeit ist natürlich von entscheidender Bedeutung).

Also versuchte ich es mit Bit-Banging. Also habe ich ein wirklich haarig aussehendes Stück Code geschrieben, speziell um MOSI zwischen den Bytes auf Low gehen zu lassen, und siehe da, es hat funktioniert! (Der FOSC wurde hier auf 250 kHz und Vdd auf 1,8 V reduziert.)

Beachten Sie jedoch das "Rauschen" in der MISO-Leitung. Das ist neu und war vorher nicht da. Alle Bypass-Kappen, Masse, Vdds, Übersprechen, Oszilloskopsonden usw. doppelt überprüft. Keine Ahnung, was es außer dem ADXL verursacht.

Wie auch immer, ich habe den Code wieder auf die Verwendung des MSSP umgestellt, anstatt Bit-Banging, um zu sehen, ob die Hardware mit einer viel reduzierten Geschwindigkeit arbeiten würde. Die Befehle werden sehr klar an ADXL gesendet, aber das einzige, was es zurückgibt, ist Folgendes:

Hat jemand eine Ahnung, was hier los ist? Der Lärm ist kein großes Problem ... das Fehlen einer Antwort ist. Es hat vorher (fälschlicherweise) mit einer SPI-Rate von 62,5 Hz und 1,8 V geantwortet, jetzt tut es nichts und Rauschen ist sichtbar. Ich würde viel lieber den Hardwaretreiber für SPI verwenden, wenn dies möglich ist.

(nicht gezeigt) verhält sich SS für alle Instanzen so, wie es sollte. Soweit ich das beurteilen kann, liegen alle Timings innerhalb der Spezifikationen des ziemlich anspruchsvollen ADXL-Datenblatts. Danke für deine Hilfe!