I2C auf 16F876A klappt nicht

**RoboHolIC** · 29.10.2015, 15:58

@witkatz
Das Programm durchläuft - den LCD-Anzeigen nach zu urteilen - den ganzen Vorspann, landet in der Hauptschleife und zeigt auch den pro Schleifendurchlauf sich erhöhenden Zähler 'loopcount' an. Lediglich die scheinbar von I2C gelesenen Zeichen sind hartnäckig 0xFF.
Im Augenblick - mit der geposteten Initalisierung - hängt es sich gar nicht auf. In manchen Situationen (fragt mich nicht, wovon das abhängt: experimentelle Codevariationen, Luftdruck ...) läuft das Programm bisweilen nur 3x, 7x, 84x ... durch die Hauptschleife, bevor es steckenbleibt.

Programmtechnisch kommen in der Hauptschleife als Bremskeile eigentlich nur in Frage:
- die Abfragen auf die Vollendung von Busaktivitäten des Masters (ziemlich unplausibel, da nur vom Baud Rate Generator abhängig)
- die ausbleibenden Reaktionen des Slave
Maßgeblich für das Eintreten dieser Ereignisse ist das Interruptbit SSPIF.

@Andre_S
Danke für deinen Codeextrakt. Ich habe ihn mit meinen Werken verglichen, soweit das wegen der unterschiedlichen Strukturierung überschaubar war. In den wesentlichen Passagen könnte ich glatt von Dir abgeschrieben haben. Aus meiner Sicht also kein Fortschritt - allerdings wird man mit der Zeit ja auch betriebsblind für die selbst programmierten Fehler...

An dieser Stelle wäre es bestimmt aufschlussreich, mit einem DSO den gesamten Verlauf auf SLC und SDA anzusehen; auf dem analogen Oszi sehe ich vermutlich nur den Havaristen, nicht aber das Riff.

**Peter(TOO)** · 29.10.2015, 18:27

Hallo,

Zitat von RoboHolIC

Das Programm durchläuft - den LCD-Anzeigen nach zu urteilen - den ganzen Vorspann, landet in der Hauptschleife und zeigt auch den pro Schleifendurchlauf sich erhöhenden Zähler 'loopcount' an. Lediglich die scheinbar von I2C gelesenen Zeichen sind hartnäckig 0xFF.
Im Augenblick - mit der geposteten Initalisierung - hängt es sich gar nicht auf. In manchen Situationen (fragt mich nicht, wovon das abhängt: experimentelle Codevariationen, Luftdruck ...) läuft das Programm bisweilen nur 3x, 7x, 84x ... durch die Hauptschleife, bevor es steckenbleibt.

Das sieht nach Störungen aus. Liegt dann am konkreten Aufbau.

MfG Peter(TOO)

**RoboHolIC** · 29.10.2015, 21:46

Zitat von Peter(TOO)

Das sieht nach Störungen aus. Liegt dann am konkreten Aufbau.

Das ist allmählich auch mein Verdacht. Die Software wurde hier ja von vielen Seiten erfolglos beleuchtet und mit funktionierendem Code verglichen.
Was wie ein Hardwaredefekt oder Programmierfehler aussieht, ist vielleicht doch "nur" ein blockierter Bus bzw. wartender Master aufgrund einer einzigen elektrischen Störung, die nicht so leicht dingfest zu machen ist.

Wie bereits angedeutet hängt vom Ausgang dieses Threads nicht Erfolg oder Scheitern eines Projekts ab. Daher würde ich ihn jetzt gerne beenden.
Vielen Dank nochmals Euch allen, die Ihr Euch intensiv um eine Lösung bemüht habt!

Christian.

**Peter(TOO)** · 30.10.2015, 01:54

Hallo Christian,

Zitat von RoboHolIC

Wie bereits angedeutet hängt vom Ausgang dieses Threads nicht Erfolg oder Scheitern eines Projekts ab. Daher würde ich ihn jetzt gerne beenden.

Allerdings würde eine Lösung des Problems dazu führen, dass du den selben Fehler in Zukunft nicht mehr machst!

Genau dies ist ein Teil des Profi-Wissens, wenn man weiss wie es nicht geht und, vor allem, warum es so nicht geht.

Du solltest vor allem die Führung der Masseleitungen unter die Lupe nehmen und auch nicht zu wenige Abblockkondensatoren verwenden.

Vor rund 40 Jahren habe ich Logikschaltungen für 60MHz entwickelt.
Heute gewinnt man damit keinen Blumentopf mehr, aber damals ging dies nur mit der 74Sxx TTL-Familie oder ECL. Damalige µP liefen noch typischerweise mit rund 1MHz und schnelle ROMs und SRAMs hatten Zugriffszeiten von 450ns (Die langsamen lagen knapp unter 1µs).
Die damals gemachten Erfahrungen, und damit erlerntes Wissen, bringen mir aber auch heute noch oft Vorteile wenn es Probleme gibt.

MfG Peter(TOO)

**PICture** · 30.10.2015, 07:07

Hallo!

@ RoboHolIC

Ändern von verwendeten µC habe ich immer in funktionierender Hardware (HW) mit einstecken des per Adapter umsockelnden µC angefangen. Ich kenne deshalb keine Probleme mit Wechseln vom µC für vorher richtig funktionierende HW.

**Andre_S** · 30.10.2015, 08:09

Hallo Christian,

sorry,… es sei mir gegönnt, auch wenn Du das Thema abschließen möchtest, noch einen letzten Hinweis zu geben!
Du hast recht, in weiten Teilen sind die Sequenzen ähnlich. Ich kenne auch Deinen zu lesenden Sensor nicht, scheinbar hat dieser keine low/high Adressierung wie mein Beispiel, aber das ist nicht das Problem.
Was mir aber aufgefallen ist und ich zumindest bei meinen I²C Baugruppen so nicht kenne, ist der Ablauf des Auslesens. Da fehlt mir die Stopp Bedingung, also die erneute Freigabe des Busses beim Lesen von Informationen.
Ich habe aber nur mal eine Ausleseroutine von Deinem Beispiel (Protokollzyklus: Accelerometer auslesen) „versucht“ durchzugehen und ich hoffe ich habe nichts übersehen oder es ist bei Deinem Sensor eventuell nicht notwendig,… dann Sorry für die Verwirrung.

Bus übernehmen
zum schreiben Adressieren
zu lesende Adresse(n) senden
Bus wieder freigeben
Bus erneut übernehmen
Zum Lesen adressieren
Byte lesen
…

Gruß André

**oberallgeier** · 30.10.2015, 08:28

Zitat von Peter(TOO)

.. Genau dies ist ein Teil des Profi-Wissens, wenn man weiss wie es nicht geht und, vor allem, warum es so nicht geht ..

OT:

Zitat von Platon, in Politei: ca. 390 bis ca. 370 v. Chr

Ein guter Bäcker ist aber wohl nicht der, der gute Brötchen bäckt. Ein guter Bäcker ist einer, der weiß wie man schlechte Brötchen bäckt und doch gute macht . . .

- - -

Zitat von Andre_S

...

zu lesende Adresse(n) senden
Bus wieder freigeben
Bus erneut übernehmen
Zum Lesen adressieren
Byte lesen
…

Darüber bin ich viele Tage lang gestolpert :-/

**RoboHolIC** · 30.10.2015, 22:49

Hallo Ihr lieben Helfer.

Zuerst das Wichtigste: Mein Code funktioniert jetzt !
Der Lorbeerkranz dafür gebührt Andre_S mit seinem zutreffenden Hinweis auf den möglicherweise fehlenden STOP-Befehl.
Mein anfänglicher Code für den BMA020 passte tatsächlich nicht zur Spezifikation des Bausteins.

Aber warum ist das nicht schon früher aufgefallen??
Es klingt absurd, aber ich habe es soeben verifiziert: Auf zwei Eigenbauten mit PIC16F886-Controllern funktioniert der I2C-Code tatsächlich auch ohne das zwischengeschaltete STOP-Signal.
Auf dem hier behandelten PIC16F876A-System hingegen klappt es nur mit diesem STOP.

Zur Bestätigung habe ich den existierenden Code für einen anderen Chip (eine RTC: PCF8583) in die PIC16F876A-Software eingebaut - auch hier die bekannte Blockierung.
Gezielte Suche - es fehlte das STOP an der entsprechenden Stelle. STOP eingefügt - und schon lief auch dieser Baustein. Vermutlich hatte ich den zunächst folgenlos bleibenden Fehler bereits früher vom PCF8583-Code in den BMA020-Code übernommen.

Nochmals herzlichen Dank an alle!
Christian.

P.S.: Nein, ich denke nicht im Traum daran, zu erforschen, warum der '886 ohne dieses STOP-Signal auskommt ...

**Peter(TOO)** · 31.10.2015, 00:08

Hallo,

Zitat von RoboHolIC

P.S.: Nein, ich denke nicht im Traum daran, zu erforschen, warum der '886 ohne dieses STOP-Signal auskommt ...

Aber in Zukunft wirst du den STOP immer drin haben

Verstehe mich richtig, ich will jetzt keinen hier runter machen:

Das ist der Unterschied zwischen basteln und professionellem Entwickeln.
Du hast geübt, bis es auf deinem '886 funktioniert hat, hast aber nie überprüft ob du die Spezifikationen auch wirklich erfüllst.
Dann wären noch die Worst Case Berechnungen, möglicherweise funktioniert es auch nicht bei jedem '886 ....

MfG Peter(TOO)