SPI-Master-Slave-Kommunikation - "ein Bit verrutscht"

[A. S. (rava)]

Hallo zusammen,

ich baue gerade an einer SPI-Kommunikation zwischen einem Atmega162 
(master) und einem PIC18F46 (slave)
Die Verleiterbahnung erlaubt keine SS-Synchronisation. Stattdessen 
werden vom Slave die empfangenen Bits gezählt und immer 8 Bits zu einem 
Byte zusammengesetzt.
Da es sich um eine Daisy chain handeln kann, wird ein Latch-Clock-Signal 
(RCK, StorageClock) an INT0 verwendet, um im Slave 
Schieberegisterverhalten zu erzeugen.


Mein Testszenario sieht vor, dass der Master einen uint8_t von 0...255 
inkrementiert und die Werte über die Leitung schickt.
Allerdings empfängt der Slave die Bytes um ein Bit verschoben: das LSB 
wird MSB des nächsten/vorigen Bytes. Möglicherweise so:
MASTER
00000000,00000001,00000010,00000011,00000100,00000101...
SLAVE
?0000000,00000000,10000001,00000001,10000010,00000010,1...
Höchstwarscheinlich sieht es so aus. Ansehen kann ich die Bytes nur 
ungefähr (Bargraph). Aber ich weiß, dass das MSB im Slave schnell 
flippt. Alle anderen Bits zählen normal, aber etwas langsam. Daher meine 
Interpretation.

SCK-Frequenz sind 4MHz, Leitungslänge ca. 15cm (ungeschirmt, in der Luft 
hängend). Das Verhalten ist deterministisch (=immer so!).

Hier mal der Code. Die Idee: Der Reset des Slaves hängt zur 
Synchronisation einem out-pin des Masters. Durch Resetten des Slaves 
kann der Master anzeigen, wo die Übertragung beginnt.



Master:

void StorageClkOut()
{
  loop_until_bit_is_set(SPSR, SPIF);
  SPIPORT |=  (1<<RCK);
  SPIPORT &= ~(1<<RCK);
}
void SlaveResetEdge()
{
  SPIPORT &= ~(1<<SLAVE_RESET);  // 0
  wait10msec(50);          // 500msec
  SPIPORT |=  (1<<SLAVE_RESET);  // 1
  wait10msec(50);          // 500msec
}
void static inline init_timing()
{
  // ClockPrescaler auf 1 schalten --> ca. 8 MHz (interner Takt)
  CLKPR = (1<<CLKPCE);  // PreScaler vorwarnen, dass er gleich benutzt wird
  CLKPR = (0<<CLKPS3)|(0<<CLKPS2)|(0<<CLKPS1)|(0<<CLKPS0);  // PreScaler auf 1x schalten und CLKPCE auf 0 setzen
  wait10msec(1);
}
void static inline init_SPI()
{
  // DDRB - die SPI Pins als Ausgänge konfigurieren (auch das unbenutzte SS)
  SPIDDR |= (1 << OUT) | (1 << SCK) | (1 << RCK) | (1 << PL);
  // SPI-Modul konfigurieren (Master & Enable & positive idle & sample@positive edge)
  SPCR |= (1 << MSTR)| (1 << SPE) | (1 << CPOL) | (1 << CPHA);
  // Double Speed aktivieren, maximale Geschwindigkeit, Datenblatt S. 163 unten
  SPSR |= (1<<SPI2X);
  // Dummy Daten
  SPDR = 0;
  loop_until_bit_is_set(SPSR, SPIF);      // Auf Übertragung warten
}
void static inline initAll()
{
  init_timing();
  init_SPI();

  DDRB |= 1<<SLAVE_RESET;
}
int main()
{
  // Initialisierung
  initAll();
  SlaveResetEdge();


  uint8_t counter=0;
  while(1)
  {
    SPDR = counter++;              // rechtes Digit auf den Bus legen, dazu DP
    StorageClkOut();

    wait10msec(1);
    
  }
}

Slave:

volatile u8 inputBuffer;

void interrupt high_priority ISR_highPriority()
{
    
    // external interrupt (i.e. Latch Clock)
    if(INTCONbits.INT0F == 1)
    {
        INTCONbits.INT0F = 0;
        // copy current Data
        inputBuffer = SSP1BUF;
    }
}

inline void MainInit(void) {
    // 16MHz
    OSCCONbits.IRCF2 = 1;
    OSCCONbits.IRCF1 = 1;
    OSCCONbits.IRCF0 = 1;
    // PLL x4 = 64 MHz
    OSCTUNEbits.PLLEN = 1;


    // global interrupts
    INTCONbits.PEIE = 1;
    INTCONbits.GIE = 1;
}
inline void InitMSSP1(void)
{    
    // MSSP1 configured as SPI Slave
    SSP1STATbits.SMP1 = 0;      // clear bit for slave operation
    SSP1STATbits.CKE1 = 1;      // set output before positive edge (idle->active)
    SSP1CON1bits.CKP1 = 0;      // transmission on positive edge (active=positive)
    SSP1CON1bits.SSPM = 0b0101;    // SPI Slave Mode, SS1 disabled (software input)
    SSP1CON1bits.WCOL1 = 0;     // clear indicator bit
    SSP1CON1bits.SSPOV1 = 0;    // clear indicator bit

    SSP1CON3bits.BOEN = 0;      // disable buffer overflow
                                //  since some data may just be running through the daisy chain

    // MSSP1 data directions
    TRISCbits.RC3 = 1;  // CLK
    ANSELCbits.ANSC3 = 0;   // digital
    TRISCbits.RC4 = 1;  // DATA IN
    ANSELCbits.ANSC4 = 0;   // digital
    TRISCbits.RC5 = 0;  // DATA OUT
    ANSELCbits.ANSC5 = 0;   // digital

    // wait for clock line to be idle
    while(PORTCbits.RC3==0)
        ;
    SSP1CON1bits.SSPEN1 = 1;    // enable serial port
}
int main(void/*int argc, char** argv*/)
{
    // init timing
    MainInit();

    // start MSSP1 in SPI slave mode
    InitMSSP1();

    // activate INT0 (positive edge triggered)
    TRISBbits.RB0 = 1;      // INT0 input
    ANSELBbits.ANSB0 = 0;       // digital
    INTCON2bits.INTEDG0 = 1;            // edge
    INTCONbits.INT0E = 1;    // enable

    // continuous operation: gather new data while mux and sensing continues to run
    while(1)
  Bargraph(inputBuffer);
}

seht ihr irgendwas? Habe ich die Konfiguration der SPI-Peripherie 
verbockt?
also: init_SPI(void) vs. InitMSSP1(void)

[A. S. (rava)]

ich habe mittlerweile viel an der SPI-Konfiguration des Slaves gedreht 
und jede Parameteränderung hat es schlechter gemacht.

Daher glaube ich mittlerweile, dass die Konfiguration richtig ist. Aus 
irgendeinem Grund scheint der Slave zu Beginn ein zusätzliches Bit zu 
empfangen, das nicht da ist.

Ein dreckiger workaround wäre, and der SCK Leiteung einfach manuell 7x 
zu wackeln und dann im slave das erste empfangene Byte wegzuwerfen.

Besser wäre es wohl, zu verstehen, warum das Ding das tut was es tut. 
Ideen?

[Chefkoch (Gast)]

Habe zwar keinen Plan von SPI bei PICs aber hatte vor kurzem selbst ein 
ähnliches Problem, dass ein einziger DAC alleine am Atmega nicht ging. 
Die Überprüfung mit dem Logicanalyzer ergab korrekte Daten/Timing und 
auf einmal lief es, aber nur während der LA mit auf den Leitungen 
hing!!! Änderungen der Datenrate auf den kleinsmöglichen Wert waren 
erfolglos. Erst das korrekte kurze Verdrahten brachte Erfolg, auch mit 
maximaler Datenrate.

[unl34shed (Gast)]

Sicher, dass du beide µC mit den selben Einstellungen fürs SPI 
programmiert hast?

Also gleiche polarität und flanke zum sampeln?
Klingt nämlich so, als würde dein Slave das Signal zu früh sampeln.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

A. S. schrieb:
> Die Verleiterbahnung erlaubt keine SS-Synchronisation.
Das ist nicht gut. Nur mit einer Frame-Synchronisation über den SS 
bekommst du nämlich sicher keinen Versatz! Alles andere ist Murks und 
geht frühestens nach dem ersten kleinen EMV-Impuls schief.

A. S. schrieb:
> Ein dreckiger workaround wäre, and der SCK Leiteung einfach manuell 7x
> zu wackeln und dann im slave das erste empfangene Byte wegzuwerfen.
Und was machst du dann, wenn der Kollege das Licht ausschlatet und so 
einen klitzekleinen Störimpuls erzeugt?

> Daher glaube ich mittlerweile
Das ist keine Glaubensfrage.

dass die Konfiguration richtig ist. Aus
> irgendeinem Grund scheint der Slave zu Beginn ein zusätzliches Bit zu
> empfangen, das nicht da ist.
Hast du mit einem Oszilloskop schon mal die Taktleitung gemessen?

[Peter D. (peda)]

A. S. schrieb:
> Stattdessen
> werden vom Slave die empfangenen Bits gezählt und immer 8 Bits zu einem
> Byte zusammengesetzt.

Wo und wie erfolgt das denn?

Ich hätte vermutet, INTCONbits.INT0F wäre ein externer Interrupt, aber 
in dem Handler wird nirgends bis 8 gezählt.

Du müßtest Deinen PIC-Code mal genauer kommentieren.

[moeb (Gast)]

clock polarity prüfen!