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

[Klebwax]

Ich kenn mich mit den PIC18 nicht so wirklich aus, aber die neueren PIC16, die ich so verwende, bekommt man mit der PLL auf 32 MHz. Das halbiert die Zeit.

Ich würd mal versuchen, mir vom SlaveSelect einen Interrupt auslösen zu lassen und ab dann alles im Interrupthandler per Pollig zu machen. Damit ist aber dies Problem nicht gelöst:

Wenn ich ein Kommando sende und unmittelbar eine Antwort haben möchte, bleibt dem Slave meiner Meinung nach ja keien Zeit das Kommando auszuwerten, bzw. müste das ja dann innerhalb eines Clockzyklus erledigt sein. Empfang auslesen auswerten und Ergebnis Byte schnell genug ins Register zum Ausschieben packen.

SPI-Flash im Fast-Modus erwarten ein Dummy-Byte nach der Adresse, bevor sie anfangen, Daten zu schicken. Die machen das intern aber rein in Hardware, Fast heißt da leicht 80MHz.

Beim PCI-Bus kann der Slave mit NAK quittieren, und der Master muß bis zu vier mal das gleiche Kommando wiederholen. Da hat sich der Slave schon beim ersten Mal die Adresse gemerkt.

Und bei I2C kommt erst ein Write mit dem Datenpointer, da kann der Slave schon mal den Adresszeiger aufsetzen, und dann der Read. Das könnte man auch mit SPI machen. Select low, ein Write Command, dann die Adresse. Select wieder High. Dann Select low, Read Command, der Slave hat das erste Byte schon parat und schickt es. Währen es geschickt wird, holt er das nächste, usw. bis Select wieder High wird.

Das sind so Beispiele, die mir einfallen.

MfG Klebwax

[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

[NRicola]

Hallo zusammen,

noch zu den Timings: oben hat sich ein Fehler eingeschlichen. Die 3,3µs waren nicht korrekt. Sie kamen daher, dass ein Interrupt ca. 11,5µs benötigt, um einsatzfähig zu sein. Bei meinen 1MHz SCLK waren die 8 gesendeten Bits schon nach 8µs durch. Die Differenz waren die rund 3,3µs.

Ich habe nun eine Zuordnung zu 8 Adressen (case-Struktur) gebaut und etwas mit den Timings rumgespielt.

1. Ohne Pause zwischen Byte 1 (MOSI) und Byte 2 (MISO): SCLK darf nicht mehr als 125kHz betragen. Die Gesamtübertragungsdauer für beide Bytes beträgt dann 132µs
2. Pause zwischen den beiden Bytes (also SCLK ausgesetzt) bei einem SCLK=1MHz: bei mir waren rund 9-10µs notwendig, damit der PIC18 genug Zeit hatte zu reagieren. Übertragungsdauer gesamt 25µs
3. Pause zwischen beiden Bytes, wenn die Dauer des ersten übertragenen Bytes in etwa dem Interrupt Verzug von 11,5µs entspricht (SCLK=700kHz): etwa 6,5µs muss die Pause betragen. Übertragungsdauer ca. 28,8µs.

Wie schon erwähnt, basieren die Werte auf einen 16MHz-Clock beim µC.

Grüß
NRicola