-         
Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 16 von 16

Thema: SPI Interrupt wird ZU SPT ausgelst nach Sendevorgang

  1. #11
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    14.04.2005
    Ort
    Freiberg
    Alter
    34
    Beitrge
    292
    Anzeige

    Hallo zusammen,

    interessante Diskussion, die hier losgebrochen ist.
    Aber zum Thema: Danke Siro fr die Aufklrung. Den ASM-Code habe ich nun auch ausgeben und so halbwegs nachvollziehen knnen. Im nchsten Schritt wollte ich mich natrlich daran machen, einige Zeilen auszusparen, um zu schauen, auf welche er womglich sogar verzichten knnte. 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 eingefgt sind, nimmt mein Zeitverzug (immernoch der provisorische INT0-Auslser) von 11s auf 25s zu. Das scheint also schon alles Hand und Fu zu haben.

    Das bringt mich natrlich dazu, das erstmal so zu akzeptieren und ich muss mal drber nachdenken, wie ich es schaffe, damit umzugehen.
    Ursprnglich war mein Ziel, dass ich ein Address-Byte ber SPI bertrage und der gleich anschlieend eine Antwort (z.B. Wert einer Variable) bersendet. Bei einem SCLK-Takt von 1MHz und diesem verspteten Interrupt, wo dann SSPBUF gleich den zu bertragenden Wert der Variable htte rein bekommen sollen, klappt das natrlich nicht. Jetzt muss ich womglich 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 wre zwar mglich, ist aber genau dann unschn, wenn der Master auf Adressen schreiben mchte. Dann wrde 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 wre 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
    Gurken schmecken mir nicht, wenn sie Pelz haben!

  2. #12
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    05.11.2007
    Ort
    Berlin
    Beitrge
    610
    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 mchte,
    bleibt dem Slave meiner Meinung nach ja keien Zeit das Kommando auszuwerten,
    bzw. mste das ja dann innerhalb eines Clockzyklus erledigt sein.
    Empfang auslesen auswerten und Ergenis Byte schnell genug ins Register zum Ausschieben packen.
    Hier wrde ich, sofern das berhaupt mglich ist, nach dem Senden eines Kommandobytes
    entweder eine Pause einfgen oder einfach 1 oder mehr Dummy Bytes senden.
    Dann weis der Master, z.B. dass die ersten n Rckgabebytes ignoriert werden mssen.

    Vielleicht haben hier schon andere Erfahrungen mit gemacht
    und knnen dazu etwas Info geben. Wre fr mich auch mal interessant.

  3. #13
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    14.04.2005
    Ort
    Freiberg
    Alter
    34
    Beitrge
    292
    Ich habe gerade nochmal etwas ge-internet-sucht. Ich bin lediglich auf das hier gestoen, wo ebenfalls der Master ausgebremst wird:
    https://www.ccsinfo.com/forum/viewtopic.php?t=39145
    Hier sind es 100s Wartezeit. Das geht womglich nur ber Software-SPI. Aber schon ziemlich suboptimal. Zwar kann man mit der SCLK schn aufdrehen (bei meinen 1MHz sind die zwei Byte eigentlich binnen ca. 16,6s durch) - aber wenn man jetzt nochmal >11s oder gar bis 100s warten muss, dann wird man schon ganz ordentlich ausgebremst.

    Sollte da jemand noch eine elegantere Lsung fr PICs/Cs haben, wre sie herzlich willkommen!
    Man kann die Frage auch andersherum stellen: hat jemand einen C vor sich, der binnen (weit) weniger als 11s bei 16MHz die Interrupt-Routine betreten hat?

    Gr
    NRicola
    Gurken schmecken mir nicht, wenn sie Pelz haben!

  4. #14
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.03.2011
    Beitrge
    1.487
    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 wrd mal versuchen, mir vom SlaveSelect einen Interrupt auslsen zu lassen und ab dann alles im Interrupthandler per Pollig zu machen. Damit ist aber dies Problem nicht gelst:
    Zitat Zitat von Siro Beitrag anzeigen
    Wenn ich ein Kommando sende und unmittelbar eine Antwort haben mchte, bleibt dem Slave meiner Meinung nach ja keien Zeit das Kommando auszuwerten, bzw. mste 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 heit 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 knnte 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. Whren es geschickt wird, holt er das nchste, usw. bis Select wieder High wird.

    Das sind so Beispiele, die mir einfallen.

    MfG Klebwax
    Strom fliet auch durch krumme Drhte !

  5. #15
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    14.04.2005
    Ort
    Freiberg
    Alter
    34
    Beitrge
    292
    Hallo zusammen,

    ich mchte mal das Thema abrunden mit der folgenden Lsung, 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,5s bei 16MHz lsst sich wohl nichts rtteln.
    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,5s dennoch hier nicht haben zu mssen, habe ich jetzt folgende Strategie angewandt:


    1. SPI kann keinen Interrupt mehr auslsen:
      Code:
      SPIE1bits.SSPIE = 0;
    2. das SS-Signal (PA5) wird gleichzeitig auf den INT0-Pin (RB0) gelegt
    3. INT0 aktivieren:
      Code:
      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:
      Code:
      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 durchfhren
              SSPEN=1;
              PIR1bits.SSPIF = 0;
              INTCONbits.INT0IF = 0;
          }
      }

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

    Gr
    NRicola
    Gendert von NRicola (13.06.2018 um 12:22 Uhr)
    Gurken schmecken mir nicht, wenn sie Pelz haben!

  6. #16
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    14.04.2005
    Ort
    Freiberg
    Alter
    34
    Beitrge
    292
    Hallo zusammen,

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

    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 Gesamtbertragungsdauer fr beide Bytes betrgt dann 132s
    2. Pause zwischen den beiden Bytes (also SCLK ausgesetzt) bei einem SCLK=1MHz: bei mir waren rund 9-10s notwendig, damit der PIC18 genug Zeit hatte zu reagieren. bertragungsdauer gesamt 25s
    3. Pause zwischen beiden Bytes, wenn die Dauer des ersten bertragenen Bytes in etwa dem Interrupt Verzug von 11,5s entspricht (SCLK=700kHz): etwa 6,5s muss die Pause betragen. bertragungsdauer ca. 28,8s.


    Wie schon erwhnt, basieren die Werte auf einen 16MHz-Clock beim C.

    Gr
    NRicola
    Gurken schmecken mir nicht, wenn sie Pelz haben!

Seite 2 von 2 ErsteErste 12

hnliche Themen

  1. SPI Interrupt wird nicht ausgelst nach Sendevorgang
    Von steckplatte im Forum PIC Controller
    Antworten: 4
    Letzter Beitrag: 25.04.2018, 20:08
  2. Interrupt wird nicht ausgelst.
    Von DarkSoldier im Forum C - Programmierung (GCC u.a.)
    Antworten: 1
    Letzter Beitrag: 28.04.2013, 14:42
  3. Interrupt wird nicht ausgelst
    Von Michael_am32 im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 02.08.2010, 00:37
  4. Es wird kein Interrupt ausgelst
    Von MrTaco im Forum C - Programmierung (GCC u.a.)
    Antworten: 9
    Letzter Beitrag: 19.07.2010, 16:48
  5. Wann wird ein Interrupt ausgelst?
    Von CKroll im Forum PIC Controller
    Antworten: 2
    Letzter Beitrag: 08.09.2004, 08:16

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhnge hochladen: Nein
  • Beitrge bearbeiten: Nein
  •