| Autor |
I2C-Bus Ack + Interrupt unterbrechung
Suche nach: i2c (576) |
|
|
|
|
BID = 738754
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
| 
 
|
Das mit dem Auslastung messen mache ich morgen mal. Heute geh ich nimmer in den kalten Keller.
Der ADC ist im Moment testweise schon abgeschaltet. Später soll er auch sporadisch Werte liefern. |
|
BID = 738756
Racingsascha
Schreibmaschine
Beiträge: 2247
Wohnort: Gundelsheim
| 
|
Solange irgendein Flagbit beim Interruptende noch gesetzt sein sollte, wird gleich wieder zum Interruptvektor gesprungen, sofern es einen Interrupt auslösen kann. (siehe Sprut) Aber da du alle aktivierten Interrupts abfrägst, abarbeitest und löschst, sollte das kein Problem sein.
Was mich wundert ist: Du nennst den Interrupt an RB0 RB0 Pinchange, allerdings ist das der externe Interrupt (INTF), den Pinchange-Interrupt gibt es nur an RB4-7. Du frägst hier das falsche Flag ab:
| Code : |
intb0
;PortB0 Pin Change Interrupt?
btfss INTCON,RBIF falsches Flag
goto intEnde ; Interrupt kam von wo anders
MOVLW B'00000001' ;LED togglen wenn Int
XORWF PORTD,1
INCF FreqCounterFeuchtZwischen1
BTFSC STATUS,Z
INCF FreqCounterFeuchtZwischen2
;In den nächsten beiden Zeile Vermute ich den Fehler.
BCF INTCON,INTF ; den Interrupt Flag de Pins Löschen
BCF INTCON,RBIF ; den Interrupt Flag de Pins Löschen
|
|
Du löschst zwar das richtige Bit (bcf INTCON,INTF) überprüfst es aber nicht.
Desweiteren scheinst du PCLATH nicht im Interrupt zu speichern, denn am Ende holst du ihn auch nicht wieder (siehe Sprut). Bei mehr als 2k Programmcode wird das Fatal, denn dann springt der PIC wirklich in den Hyperraum (selbst schon erlebt  )
_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie. |
|
BID = 738763
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Ui perfekt. 2 Hinweise, die zielführend sein könnten!
Ich bin wirklich nicht so bewandert in diesen Dingen hier, ich mach das alles autodidaktisch per Trial + Error. So wie das hald als Hobbyist abläuft. Meine Frustrationstoleranz ist inzwischen schon sehr hoch 
Der Programmcode ist im Moment 485 Byte lang
|
BID = 738781
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Hmm. Jetzt hab ich alle Fehler im Programm beseitigt aber das Problem tritt immernoch auf.
Interessanterweise kann ich das Problem durch einen MCLR nicht beheben. Die Abfrage der Internen Register geht nach dem MCLR wieder, der I2C bus klemmt Nach wie Vor.
Ich gehe davon aus, dass mir doch irgend ein Baustein auf dem I2C-Bus Aussteigt und diesen blockiert. Also nochmal alle anderen Datenblätter wälzen.
|
BID = 739144
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Weitere ermüdende Tests später bin ich der Auffassung, dass es doch am Bus oder der I2C Hardware liegt. Der Bus steigt bei allen Schreib/Lese-Operationen (unabhängig von deren Länge oder der Zieladresse) ab und zu aus. Ich werde mal mit dem Timing spielen. (kann man die Busgeschwindigkeit auch zu langsam einstellen?)
|
BID = 739406
DonComi
Inventar
Beiträge: 8605
Wohnort: Amerika
|
Welche Freq. hast du denn als SCL-Takt?
Slaves, die nicht mitkommen, können SCL nach GND ziehen und so den Takt „dehnen“. 100kHz sollten alle Slaves schaffen (steht aber auch in den Datenblättern drin).
Vielleicht ist deine I²C-Hardware nicht richtig initialisiert?!
Edit:
Zu langsamer Takt:
Glaub ich kaum, aber auch das sollte Datenblättern entnommen werden können.
100kHz ist so der Standard und damit sollte das auch alles klappen.
_________________
[ Diese Nachricht wurde geändert von: DonComi am 8 Jan 2011 23:20 ]
|
BID = 739407
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Mit den Taktraten hab ich inzwischen alles durch. von extrem langsam bis 300kHz war alles dabei. Keine Veränderung des Fehlers. Für live Updates bei der Fehlersuche empfehle ich euch, mir auf Twitter zu folgen.
Hier mein Account.
Ich hab da ein paar tipps von amerikanischen bastlerkollegen bekommen, bisher hat nichts geholfen.
Ich poste jetzt als letzten Notnagel mal meinen kompletten Code hier, langsam komm ich nämlich an diese ominöse stelle, wo ein Projekt dann stirbt, weil mir der Elan fehlt so einen Fehler weiter zu suchen. Ich hab ehrlich gesagt auch keinen Bock, meinen Bus abzuklemmen um zu sehen ob da ein externes Bauteil Zicken macht, aber ich werde wohl nicht drumrum kommen. Wenn ihr Lust und Zeit habt könnt ihr euch den Code ja mal ansehen.
|
BID = 739433
DonComi
Inventar
Beiträge: 8605
Wohnort: Amerika
|
Du meintest ja, dass er unkontrolliert abnippelt, richtig?
Wenn ja, dann sind immer Sequenzen wie folgende verdächtig:
| Code : |
i2c_send
movwf SSPBUF ; -> zum I2C-Slave übertragen
i2c_t2
btfss PIR1, SSPIF ; ACK schon empfangen?
goto i2c_t2 ; nein, noch nicht
|
|
Hier landet der µc in einer Endlosschleife, wenn der Slave kein ACK sendet. Dass er kein ACK sendet kann ja an vielen Gründen liegen, vom Defekt über ein falsches Protokoll etc.
Soll etwas wirklich zuverlässig sein und man ein paar Bytes überhaben, kann man sowas machen (Pseudocode):
; auf Slaves ACK warten
timer = 1000 ; Mikrosekunden
while ( timer <> 0 )
do
if( ACK ) then break
timer = timer - 1
done
Also:
Es gibt zwei Abbruchkriterien für die Schleife: entweder, der Slave übermittelt innerhalb der willkürlichen Zeit von etwa einer Millisekunde das ACK-Bit, oder der Timer läuft ab und beendet die Schleife ebenfalls.
Hierzu gehört dann aber weiterer Code, der dann entsprechend auf das (vermeintliche) Fehlverhalten des Slaves aufmerksam macht.
Da du etwas später noch so ein Konstrukt im Quellkode hast, könnte ich mir gut vorstellen, dass der µC genau in so einer Schleife stecken bleibt.
_________________
|
BID = 739435
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Danke fürs lesen und die Antwort! Ich schau mir das morgen früh gleich mal an.
EDIT: Interrupts sollten aber dennoch behandelt werden. Bei mir blinken aber nicht mal mehr die LED die in der Interrupt-Routine an und abgeschaltet werden.
[ Diese Nachricht wurde geändert von: QuirinO am 9 Jan 2011 1:02 ]
|
BID = 739494
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Ich habe jetzt folgende Fehlerbehandlungs-Routine in meine I2C Empfangs und Sende-Routinen eingebaut:
| Code : |
i2c_send
movwf SSPBUF ; -> zum I2C-Slave übertragen
;Einen Zähler initialisieren, der herunterzählt und nach 255 Schleifendurchläufen das Warten beendet und eine Fehlerbehandlung startet
movlw D'255' ; 40Us Pause
movwf loops
i2c_t2
nop
nop
decfsz loops, F ;Counter abgelaufen?
goto i2c_nichtabgelaufen ;dieser befehl wird übersprungen wenn der counter abläuft
goto i2c_send_fehler ;dann wird zur Fehlerbehandlung gesprungen
i2c_nichtabgelaufen ;Ansonsten wird das Ack abgefragt
btfss PIR1, SSPIF ; ACK schon empfangen?
goto i2c_t2 ; nein, noch nicht
bcf PIR1, SSPIF ; ja, Daten sind im Slave, nun noch SSPIF zurücksetzen
goto i2c_send_ende ;das Senden ist normal abgeschlossen - gehe zum Return
i2c_send_fehler
;Fehlerbehandlung hier einfügen
BSF PORTD,7
i2c_send_ende
return ;weiter im programm |
|
Dabei wird im Fehlerfall eine Anzeigeled gesetzt.
Das programm wird dadurch noch instabiler - bei einem Absturz geht KEINE (!) der beiden LED an... Der Prozessor scheint in einen undefinierten Zustand zu geraten.
Ich gehe inzwischen davon aus, dass einfach der Prozessortakt zu langsam ist, um all diese Interrupts auszuwerten. Kann das sein?
[ Diese Nachricht wurde geändert von: QuirinO am 9 Jan 2011 13:16 ]
|
BID = 739496
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Ich habe gerade den Zeitfressendsten Interrupt - nämlich den Frequenzzähler deaktiviert - dadurch treten die Abstürze nicht mehr auf! Ich bau mal einen externen Quarz mit 20 MHz ein und berichte erneut!
|
BID = 739523
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
So. 20Meg Quarz drin, Schaltung läuft 5 mal so schnell. Led blinken 5 mal so schnell, insofern alles ok. Baudrate angepasst - Der I2C Bus stürzt nicht mehr ab. Nur die kontroll - LED gehen trotzem aus, d.h. irgend ein komischer undefinierter Zustand tritt trotz allem ein.
Vielleicht haben sich da 2 Probleme gegenseitig überdeckt?
|
BID = 739545
DonComi
Inventar
Beiträge: 8605
Wohnort: Amerika
|
Möglich.
Kann aber auch sein, dass der Prozessor wirklich zu langsam war (hatte ich ja auch schon vermutet!)
Der PIC wird aber nicht erst seit gestern hergestellt, also wird der Fehler schon irgendwo in deinem Programm liegen .
Es ist naheliegend, dass der Fehler irgendwo in der ISR für den f-Zähler liegt, zumindest aus deiner Beschreibung folgere ich das.
(oder, dass die ISR zu lange dauert)
Aber wie gesagt, mit PICs kenne ich mich absolut nicht aus, daher kann es sein, dass hier gleich jemand aufkreuzt, der damit seit Jahren arbeitet und sagt, „da setzt du ein falsches Bit“ oder so.
Was passiert denn nu, wenn ein IRQ auftritt, während der Prozessor eine ISR abarbeitet? Konntest du das in Erfahrung bringen (interessiert mich einfach ).
Hast du schon den Auslastungstest gemacht (siehe vorherige Posts von mir)?
_________________
|
BID = 739546
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Ich mach den Auslastungstest jetzt gleich mal.
Bin mal im Keller... 
|
BID = 739560
QuirinO
Schreibmaschine
Beiträge: 2205
Wohnort: Behringersdorf
|
Die Prozessorauslastung bei 20MHz berägt - während der normalen Frequenzmessung - durch die ISR etwa 3%
EDIT: Interessanterweise ist bei der Messung der Prozessor kein einziges Mal abgestürzt. Der W-Lan Empfang da unten ist wesentlich schlechter als an meinem PC und die Latenz grösser... Das verringert jedoch nicht den gesamt - Traffic. Was kann das sein?
EDIT2: Ich habe gerade beim Testen hier oben bemerkt (ja, ich habe wieder einen Absturz verursacht) dass die ISR weiterhin bedient wird (die LED für die Messung der ISR-Zeit verändert ihre Helligkeit nicht) nur werden eben der Timer0 Interrupt und der externe Interrupt nicht mehr bedient. Bzw die LEDn nicht mehr geschaltet.
[ Diese Nachricht wurde geändert von: QuirinO am 9 Jan 2011 17:25 ]
|
