-         
Ergebnis 1 bis 5 von 5

Thema: SPI Interrupt wird nicht ausgelöst nach Sendevorgang

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    18.08.2010
    Beiträge
    12

    SPI Interrupt wird nicht ausgelöst nach Sendevorgang

    Anzeige

    Hallo an alle,

    Ich habe ein Problem mit der SPI, und zwar wird nach dem Senden der Daten das Interrupt Flag nicht gesetzt. Es geht um ein dsPic33E.

    Hier die SPI und Interrupt Einstellungen:
    Code:
    INTCON2bits.GIE=0;    
    IFS2bits.SPI2IF=0;//clear Interrupt flag
        IEC2bits.SPI2IE=0;//disable interrupt
        
        SPI2STATbits.SPIEN=0;
        SPI2CON1bits.DISSCK=0; 
        SPI2CON1bits.DISSDO=0; 
        SPI2CON1bits.MODE16=0; 
        SPI2CON1bits.MSTEN=1; 
        SPI2CON1bits.SMP=0;
        SPI2CON1bits.CKE=0; 
        SPI2CON1bits.CKP=0; 
    
    
        SPI2STATbits.SISEL=0b101; //interrupt when transmit is complete
        IPC8bits.SPI2IP=0b001; //priorioty 1
               
        SPI2STATbits.SPIEN=1; // ENABLE spi
        
        SPI2BUF=0x00;//clear buf
        SPI2STATbits.SPITBF=0; //clear BF
        
        IFS2bits.SPI2IF=0;//clear int flag
    
    
        INTCON2bits.GIE=1;
        IEC2bits.SPI2IE=1; //enable interrupt
    Hier der Sendevorgang :
    Code:
           CS=0; 
           SPI2BUF=0xAD;
            CS=0; //no operation 
            while(IFS2bits.SPI2IF==0); // wait
            IFS2bits.SPI2IF=0;//clear Int flag.
            dummy=SPI2BUF;
            CS=1;
    Die SPI funktioniert, die Daten samt Takt kommen am Oszi an. JEDOCH wird das IFS2bits.SPI2IF Flag nie gesetzt.. Die Einstellungen sind genau so wie aus dem Microchip Datenblatt empfohlen.
    Das Problem mit while(SPI2STATbits.SPITBF==1); ist, dass der gesetzt wird wenn der Buffer leer ist, jedoch arbeitet das Schieberegister dann noch, auch gut im Zeitdiagramm zu sehen.

    Wer weiß was hier nicht stimmt ?

    Vielen dank
    Liebe Grüße,
    steckplatte

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.03.2011
    Beiträge
    1.513
    Zitat Zitat von steckplatte Beitrag anzeigen
    Hier der Sendevorgang :
    Code:
           CS=0; 
           SPI2BUF=0xAD;
            CS=0; //no operation 
            while(IFS2bits.SPI2IF==0); // wait
            IFS2bits.SPI2IF=0;//clear Int flag.
            dummy=SPI2BUF;
            CS=1;
    Die SPI funktioniert, die Daten samt Takt kommen am Oszi an. JEDOCH wird das IFS2bits.SPI2IF Flag nie gesetzt.. Die Einstellungen sind genau so wie aus dem Microchip Datenblatt empfohlen.
    Das Problem mit while(SPI2STATbits.SPITBF==1); ist, dass der gesetzt wird wenn der Buffer leer ist, jedoch arbeitet das Schieberegister dann noch, auch gut im Zeitdiagramm zu sehen.
    Hallo,

    ich hab zwar gerade einen PIC24EPxxx am Wickel, der sollte da identisch sein, komme aber nicht dazu etwas zu testen. Ich würd das mal anders probieren und das Receivebuffer-Flag testen

    Code:
    uint8_t Send( uint8_t data)
    {
        int temp;
        CS = 0;
        temp = SPI1BUF;                // empty receive buffer
        SPI1BUF = data;                  // data into buffer
        while( !SPI1STATbits.SPIRBF ) {   // all bits are shifted, receivebuffer is full
            ;
        }
        CS = 1;
        return SPI1BUF;
    }
    Wenn der Receivebuffer am Anfang leer ist, kann er erst voll sein, wenn alle Bits einmal durchgeschoben worden sind.

    Noch zwei Hinweise deinen Code für andere lesbarer zu machen: wenn hier mit CS=0; //no operation gemeint ist, was der Kommentar sagt, schreib Nop(): hin. Sonst muß man dauernd überlegen, warum hier CS behandelt wird. Und rück bei while(IFS2bits.SPI2IF==0); // wait
    wenigstens das Semikolon auf die nächste Zeile. Dann erkennt jemand, der den Code nicht gut kennt (und das bist auch du selbst in 3 Monaten) sofort die Schleife. Ich schreib das normalerweise noch etwas ausführlicher. Dann kann man da auch mal schnell irgendwelchen (Debug)Code einfügen und auch wieder rauskommentieren.

    Vielleicht hilfts ja

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  3. #3
    Neuer Benutzer Öfters hier
    Registriert seit
    18.08.2010
    Beiträge
    12
    Hallo Klebwax,

    Vielen dank für deine Antwort.
    Leider funktioniert auch das nicht. Ist auch gut im Zeitdiagramm zu erkennen. Möchte auch nicht mit vielen delays und NOP's arbeiten um diese paar Taktzyklen aufzufüllen bis das Receive buffer wieder auf low ist..mit einem Interrupt ist das viel sauberer und genauer.
    Das Datenblatt schlägt ja auch vor mit einem Interrupt zu arbeiten, verstehe nur eben nicht warum das nicht funktioniert..

    Und Danke für die Tipps, werde das berücksichtigen!

    Liebe GrüßeKlicke auf die Grafik für eine größere Ansicht

Name:	Bildschirmfoto 2018-04-25 um 09.39.46.png
Hits:	8
Größe:	69,8 KB
ID:	33428

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.03.2011
    Beiträge
    1.513
    Zitat Zitat von steckplatte Beitrag anzeigen
    Leider funktioniert auch das nicht. Ist auch gut im Zeitdiagramm zu erkennen. Möchte auch nicht mit vielen delays und NOP's arbeiten um diese paar Taktzyklen aufzufüllen bis das Receive buffer wieder auf low ist..mit einem Interrupt ist das viel sauberer und genauer.
    Auf deinem Bild ist zwar kaum was zu erkennen, wenn ich aber die gelben Marken mal ernst nehme, schaust du aufs falsche Signal. Es geht um SPIRBF, ganz unten rechts. Das wird low, sobal du SPI1BUF liest, ( temp = SPI1BUF; ) ganz egal wann das ist, sonst könnte man das Byte je mehrmals auslesen ohne es zu merken. Und es wird high, wenn ein Datenwort hinausgetaktet worden ist. Das ist genau was du willst. Im Gegensatz zum Interruptflag kommt es immer, auch wenn man die Interruptbedingung mal falsch konfiguriert hat. Erst wenn du die FIFOs benutzt, hat das Interruptflag Vorteile. Nach der Theorie sollte es gehen und ich glaub, ich hab das auch schon so gemacht. Ich hab bloß im Moment keinen Code zur Hand, um nachzuschauen.

    MfG Klebwax

    P.S. Hab in meinem alten Code gefunden, daß ich das genauso gemacht habe.
    Strom fließt auch durch krumme Drähte !

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    18.08.2010
    Beiträge
    12
    Hallo Klebwax,

    Oh tut mir leid, habe nicht gemerkt dass das Bild so klein geraten ist. Die gelben Marken waren um zu zeigen was ich eingestellt habe(CKE/CKP..)
    Okay eventuell war mein Fehler dass ich vorher den Buffer nicht ausgelesen habe, damit der SPIRBF auf Low geht.
    Werde dann das hier morgen ausprobieren, hoffe es klappt.
    Code:
    CS=0;
    dummy=SPI2BUF; // auslesen damit SPIRBF auf Low geht
    SPI2BUF=0xAD;
    while(SPI2STATbits.SPIRBF==0)
    ; // warten bis SPIRBF wieder High wird
    dummy=SPI2BUF;
    CS=1;
    Es wundert mich nur warum das mit dem Interrupt Flag nicht funktioniert. Hab im Microchip forum viele Problem Threads dazu gelesen, dass das Interrupt Flag einfach nicht gesetzt wird. Da kam auch die Lösung wegen den Remappable Pins, zuerst das SCK auf Eingang zu setzen und dann erst als Ausgang. Aber so richtig geklappt hat das noch nicht.

    lG
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Bildschirmfoto 2018-04-25 um 20.23.21.jpg  

Ähnliche Themen

  1. Timer Interrupt wird nicht mehr ausgelöst
    Von damnit im Forum C - Programmierung (GCC u.a.)
    Antworten: 7
    Letzter Beitrag: 25.10.2013, 06:45
  2. Interrupt wird nicht ausgelöst.
    Von DarkSoldier im Forum C - Programmierung (GCC u.a.)
    Antworten: 1
    Letzter Beitrag: 28.04.2013, 14:42
  3. Interrupt wird nicht ausgelöst
    Von Michael_am32 im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 02.08.2010, 00:37
  4. Interrupt wird nicht ausgelöst
    Von einballimwas im Forum C - Programmierung (GCC u.a.)
    Antworten: 10
    Letzter Beitrag: 01.09.2009, 14:29
  5. Interrupt wird nicht ausgelöst
    Von PcVirus im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 10.04.2008, 15:14

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •