SPI Interrupt wird ZU SPÄT ausgelöst nach Sendevorgang

[NRicola]

Hallo zusammen,

ich möchte mal das Thema abrunden mit der folgenden Lösung, die ich nun umgesetzt habe und dem folgenden Fazit:
An dem Zeitverzug zwischen <Interrupt wird angefordert> und <ich mache irgendwas in der ISR> von ca. 11,5µs bei 16MHz lässt sich wohl nichts rütteln.
Deshalb muss beim SPI-Master eine Wartepause eingelegt werden, sodass der PIC18-Slave Zeit hat, das erste MOSI-Byte (=Adresse) zu verarbeiten.

Um den Zeitverzug von 11,5µs dennoch hier nicht haben zu müssen, habe ich jetzt folgende Strategie angewandt:

1. SPI kann keinen Interrupt mehr auslösen:
   

   SPIE1bits.SSPIE = 0;

2. das SS-Signal (PA5) wird gleichzeitig auf den INT0-Pin (RB0) gelegt
3. INT0 aktivieren:
   

   INTCONbits.INT0IE = 1;
   INTCON2bits.INTEDG0 = 0;    //interrupt on rising edge:=1 (Je nach SPI-Modus)

4. ISR-Routine bereitet sich bei INT0 bereits vor und wartet den SPI-Interrupt-Flag ab:
   

   void interrupt isr(void){
       if (INTCONbits.INT0IF==1){
           while(PIR1bits.SSPIF == 0);      // auf SPI-Interrupt warten
           spi_reg_addr=SSPBUF;
           SSPEN=0;
           //tu' noch irgendwas, z.B. einen Adress-Anfragen-Vergleich durchführen
           SSPEN=1;
           PIR1bits.SSPIF = 0;
           INTCONbits.INT0IF = 0;
       }
   }

Damit habe ich nicht mehr die 11,5µs Zeitverzug abzuwarten, sondern nur noch ca. 3,3µs. damit könnte man womöglich noch ohne Warten des Masters bei einem SCLK von 100-200kHz hinkommen. Zumindest ist das besser als die 100µs Wartezeit von dem Forumsbeitrag von ccsinfo (siehe oben).

Grüß
NRicola