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

[Siro]

Jetzt hab ichs, glaube ich:
Der Interrupt Vector liegt ja bei 0x0008 bzw. 0x0018
und dort ist folgender Code zu finden, nämlich der Eintritt in die Interrupt Funktion
Hier werden alle notwendigen Register gerettet, erstmal unabhängig davon ob diese benutzt werden.

0008  821B     BSF btemp, 1, ACCESS
000A  CFFA     MOVFF PCLATH, __pcstackCOMRAM
000C  F001     NOP
000E  CFFB     MOVFF PCLATU, 0x2
0010  F002     NOP
0012  CFE9     MOVFF FSR0, 0x3
0014  F003     NOP
0016  CFEA     MOVFF FSR0H, 0x4
0018  F004     NOP
001A  CFE1     MOVFF FSR1, 0x5
001C  F005     NOP
001E  CFE2     MOVFF FSR1H, 0x6
0020  F006     NOP
0022  CFD9     MOVFF FSR2, 0x7
0024  F007     NOP
0026  CFDA     MOVFF FSR2H, 0x8
0028  F008     NOP
002A  CFF3     MOVFF PROD, 0x9
002C  F009     NOP
002E  CFF4     MOVFF PRODH, 0xA
0030  F00A     NOP
0032  CFF6     MOVFF TBLPTR, 0xB
0034  F00B     NOP
0036  CFF7     MOVFF TBLPTRH, 0xC
0038  F00C     NOP
003A  CFF8     MOVFF TBLPTRU, 0xD
003C  F00D     NOP
003E  CFF5     MOVFF TABLAT, 0xE
0040  F00E     NOP
0042  C01B     MOVFF btemp, 0xF
0044  F00F     NOP
0046  C01C     MOVFF 0x1C, 0x10
0048  F010     NOP
004A  C01D     MOVFF 0x1D, 0x11
004C  F011     NOP
004E  C01E     MOVFF 0x1E, 0x12
0050  F012     NOP
00D8  0012     RETURN 0
54:

!! Die NOP s sind NICHT etwa reingebastelt um Code zu verschwenden, obwohl ich das auch am Anfangs dachte....
das ist Prozessorbedingt so bei einem Befehl MOVFF.

er kommt auch bei einem Interrupt in diesen Code rein, habe ich grad mal simuliert und das dauert dann 40 Cycles für diesen Codeabschnitt

Bei 16 MHz / 4 wegen der Pipeline Struktur = 4 MHz =250ns pro Cycle
Bei 40 Cycles also 40*250ns sind 10 us und das entspricht deinem Fehler.

Vermutlich kommt hier dann die "Optimierung" zur Geltung, wenn man eine Pro Version hat.Ich kann das leider nicht testen, habe nur die Freie VersionIch glaube man kann sich aber auch eine Pro Version Testweise runterladenIdee: Du könntest noch die PLL im Chip einschalten und die Zeit damit vierteln.
Also den internen Takt vervierfachen. Must deine SPI Einstellung vermutlich noch ändern.

[NRicola]

Hallo zusammen,

interessante Diskussion, die hier losgebrochen ist.  
Aber zum Thema: Danke Siro für die Aufklärung. Den ASM-Code habe ich nun auch ausgeben und so halbwegs nachvollziehen können. Im nächsten Schritt wollte ich mich natürlich daran machen, einige Zeilen auszusparen, um zu schauen, auf welche er womöglich sogar verzichten könnte. So hatte ich versucht, Teile des C-Codes durch asm("...") zu ersetzen. Allerdings klappte das nicht so, da ich versucht hatte, es genauso anzuordnen, wie in der listing.disasm. Das bedeutet aber, dass Befehle zwischen void interrupt isr(void) und der "geschweiften Klammer auf" stehen. Das hat dem Compiler erstmal nicht so gefallen.
Aber ich habe festgestellt, wenn die Befehle dann nach der geschweiften Klammer eingefügt sind, nimmt mein Zeitverzug (immernoch der provisorische INT0-Auslöser) von 11µs auf 25µs zu. Das scheint also schon alles Hand und Fuß zu haben.

Das bringt mich natürlich dazu, das erstmal so zu akzeptieren und ich muss mal drüber nachdenken, wie ich es schaffe, damit umzugehen.
Ursprünglich war mein Ziel, dass ich ein Address-Byte über SPI übertrage und der gleich anschließend eine Antwort (z.B. Wert einer Variable) übersendet. Bei einem SCLK-Takt von 1MHz und diesem verspäteten Interrupt, wo dann SSPBUF gleich den zu übertragenden Wert der Variable hätte rein bekommen sollen, klappt das natürlich nicht. Jetzt muss ich womöglich mehrere Variablen-Anfragen verschachteln. Also so in etwa:

1. SS & SCLK aktiv, 1Byte-Adresse1 MOSI; MISO nichts
<mehr oder weniger pause>
2. SS & SCLK aktiv, 1Byte-Adresse2 MOSI; MISO Variable von Adresse 1
<mehr oder weniger pause>
3. SS & SCLK aktiv, 1Byte-Adresse3 MOSI; MISO Variable von Adresse 2
<mehr oder weniger pause>
...
<mehr oder weniger pause>
N. SS & SCLK aktiv, 1Byte-AdresseN MOSI; MISO Variable von Adresse N-1
<mehr oder weniger pause>
N+1. SS & SCLK aktiv, 1Byte Dummy MOSI; MISO Variable von Adresse N

Dieses Vorgehen wäre zwar möglich, ist aber genau dann unschön, wenn der Master auf Adressen schreiben möchte. Dann würde der µC es nicht schaffen nach der Bekanntgabe der Adresse rechtzeitig den SSPBUF leer zu machen, ehe dann auch gleich das Schreibbyte übertragen wird.

Vielleicht wäre es hier geschickter, den Master anzufassen und (bei der Kommunikation mit dem PIC18 ) eine definierte Pause zwischen dem Adress-Byte und dem Read- oder Write-Byte zu machen.

Grüß,
NRicola

[Siro]

Ich muß gestehen dass ich auch noch keine Erfahrung mit dem "Slave Mode" habe.
und stelle mir das auch etwas problematisch vor mit Bidirektionalen Betrieb.
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 Ergenis Byte schnell genug ins Register zum Ausschieben packen.
Hier würde ich, sofern das überhaupt möglich ist, nach dem Senden eines Kommandobytes
entweder eine Pause einfügen oder einfach 1 oder mehr Dummy Bytes senden.
Dann weis der Master, z.B. dass die ersten n Rückgabebytes ignoriert werden müssen.

Vielleicht haben hier schon andere Erfahrungen mit gemacht
und können dazu etwas Info geben. Wäre für mich auch mal interessant.

[NRicola]

Ich habe gerade nochmal etwas ge-internet-sucht. Ich bin lediglich auf das hier gestoßen, wo ebenfalls der Master ausgebremst wird:
https://www.ccsinfo.com/forum/viewtopic.php?t=39145
Hier sind es 100µs Wartezeit. Das geht womöglich nur über Software-SPI. Aber schon ziemlich suboptimal. Zwar kann man mit der SCLK schön aufdrehen (bei meinen 1MHz sind die zwei Byte eigentlich binnen ca. 16,6µs durch) - aber wenn man jetzt nochmal >11µs oder gar bis 100µs warten muss, dann wird man schon ganz ordentlich ausgebremst.

Sollte da jemand noch eine elegantere Lösung für PICs/µCs haben, wäre sie herzlich willkommen!
Man kann die Frage auch andersherum stellen: hat jemand einen µC vor sich, der binnen (weit) weniger als 11µs bei 16MHz die Interrupt-Routine betreten hat?

Grüß
NRicola

[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