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.
Hallo Christian,
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)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
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.![]()
MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!
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é
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 ...![]()
Hallo,
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)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
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 ...
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.
Lesezeichen