I2C auf 16F876A klappt nicht

[RoboHolIC]

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)]

Hallo Christian,

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]

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]

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]

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

OT:

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 . . .

- - -

...

• 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]

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)]

Hallo,

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)

[Andre_S]

Nochmals herzlichen Dank an alle!
Christian.

Hallo Christian,

super das es nun klappt und wir Dir doch noch helfen konnten!


Gruß Andre

[RoboHolIC]

Aber in Zukunft wirst du den STOP immer drin haben

Aber klar doch - sofern er ins Protokoll gehört, denn ich kenne einen I2C-Kandidaten, wo im selben Zusammenhang statt STOP - START ein RepeatedSTART hingehört ...

möglicherweise funktioniert es auch nicht bei jedem '886 ...

Darauf würde ich es auch gar nicht nicht ankommen lassen. Wissentlich gegen die Spezifikation zu verstoßen "weil es aber doch funktioniert" wäre unclever.

Gruß
Christian.

[Klebwax]

Auf dem I2C-Bus beginnt jede Transaktion mit einem START und endet mit einem STOP. Die I2C Spec sagt dazu:

Data transfers follow the format shown in Fig.10. After the START condition (S), a slave address is sent. This address is 7 bits long followed by an eighth bit which is a data direction bit (R/W) - a ‘zero’ indicates a transmission (WRITE), a ‘one’ indicates a request for data (READ). A data transfer is always terminated by a STOP condition (P) generated by the master.

und:

START and STOP conditions are always generated by the master. The bus is considered to be busy after the START condition. The bus is considered to be free again a certain time after the STOP condition.

Solage also am Ende einer Transaktion kein STOP kommt, gilt der Bus also als belegt.

Eine Transaktion hat immer nur eine Richtung, in der Daten übertragen werden. Die Richtung macht sich am R/W Bit im Adressbyte fest. Wenn man also sowohl schreiben, z.B. eine Registeradresse, als auch lesen will, z.B. den Registerinhalt, braucht man zwei Transaktionen. Zu jeder gehören ein START am Anfang und ein STOP am Ende.

Aber klar doch - sofern er ins Protokoll gehört, denn ich kenne einen I2C-Kandidaten, wo im selben Zusammenhang statt STOP - START ein RepeatedSTART hingehört ...

STOP-START und repeated START sind equivalent. Die Spec sagt dazu:

The bus stays busy if a repeated START (Sr) is generated instead of a STOP condition. In this respect, the START (S) and repeated START (Sr) conditions are functionally identical (see Fig. 10). For the remainder of this document, therefore, the S symbol will be used as a generic term to represent both the START and repeated START conditions, unless Sr is particularly relevant.

Der einzige Unterschied ist, daß der Bus zwischen zwei Transaktionen nicht frei wird. Das spielt eine Rolle beim Multimasterbetrieb. Da könnte sonst ein anderer Master Kontrolle über den Bus und den gerade adressierten Slave bekommen und zum Beispiel die gerade gesetzte Registeradresse umprogrammieren.

Ein I2C Slave, der der I2C Spec entspricht, muß also auf ein repeated START genauso reagieren wie auf STOP-START und natürlich umgekehrt. Ein I2C Master muß aber jede Transaktion mit einem STOP oder einem repeated START abschließen.

Nun ist es aber gut möglich, daß die HW eines I2C Masters START und repeated START auf die gleiche Weise erzeugt. So kann also ein Programm funktionieren, ohne daß explizit ein STOP erzeugt wird, da statt START ein repeated START entsteht. Sind die Umstände aber anders (Timing ?, andere HW ?) versagt es.

MfG Klebwax