Hallo zusammen, ich bin seit einiger Zeit dabei, einen SRF02 via I2C auszulesen. Das Ganze gestaltet sich schwieriger als ich dachte. Irgendwie (ich bin kein I2C-Experte, ich wollte den Bus eigentlich "nur" benutzen) bekomme ich ab und zu "willkürliche" Fehler. Ich benutze die Library von Peter Fleury, mit 85kHz I2C-Frequenz. Nun passiert es öfter, dass der I2C ewig lange in einer der Warteschleifen "while(!(TWCR & (1<<TWINT)));" hängt und somit das ganze Programm verzögert wird. Teilweise geht das sogar so weit, dass der Timeout-Watchdog anspringt. Meistens bekomme ich allerdings richtige Werte. Daraus schließe ich, dass die Grundeinstellungen richtig sind. Daher frage ich mich in erster Linie, ob es nicht eine "geeignetere" Library gibt, die bspw. diese while-Schleifen anders handelt. Oder ob ihr Ideen habt, wo es noch dran liegen könnte. Pull-Ups, CPU-Frequenz, etc. sind richtig. Ich würde mich sehr über Tipps freuen!
Alex Chili schrieb: > Ich würde mich sehr über Tipps freuen! Du weist ja, dass der Ultraschallsensor prinzipbedingt eine Weile braucht, bis der dir die Werte geben kann? Es gibt einige US-Sensoren, die beim Ansprechen ihre Messung starten. Diese dauert je nach Entfernung unterschiedlich lange und dann geben sie den Wert zurück. Während der ganzen Zeit der Messung ist der Bus blockiert (SCK vom US auf Low). Da wäre es interessant, auf welche Zeit dein Watchdog eingestellt ist. :-)
hey, darauf habe ich auch geachtet.er braucht > 65 ms. ich habe es mit werten von 70-200 ms getestet...immer die gleichen fehler. also liegt es daran denke ich nicht.
Hab grad mal ins DB geschaut: Was du machen kannst ist: - Messung starten (Register 0 des Sensors beschreiben) - Irgendwas anderes machen - Wert auslesen (Slave antwortet erst wieder, wenn er fertig ist) Dafür muss deine I2C-Routine halt mit nicht antwortenden Slaves klarkommen (NACK). :-)
nun.. das es dafür Pullups benötigt weisst du ja offenbar. .. auch die Leitungen sollten nicht zuuuu lang sein. Eigentlich ist i2C gutmütig (das sage ich jetzt, nachdem ich mir früher den Bart ausgerissen habe weil es nicht klappte,) Wie ist deine Anschlusssituation ? In letzter Zeit bin ich dazu übergegangen statt einem Paar Pullup lt. Datenblatt , jeweils 1 Paar je Teilnehmer (a 10k oder ähnlich) anzuschliessen. klappt auch prima. Grussi Klaussi
@Floh: Das hier: Dafür muss deine I2C-Routine halt mit nicht antwortenden Slaves klarkommen (NACK). :-) scheint ein guter Ansatz zu sein. Wie implementiere ich das Ganze denn? Denn momentan ist es ja so, dass ich zum Abschluss des Lesevorganges die NACK-Routine aufrufe. Kann ich mit einem NACK denn auch pollen, und quasi warten, bis der Sensor fertig ist? @Klaus: Mein Testaufbau hat in einem Fall 2cm lange Leitungen, im Andern ca. 15cm, mit gleichen Ergebnissen. Ich habe auch nur einen TN (den SRF02) dran. Allerdings habe ich 4k7 Widerstände als Pullups. Dass I2C gutmütig ist, kann ich (noch) nicht bestätigen. Bislang ist das der Punkt, der mich am meisten Nerven kostet... :\
>Dass I2C gutmütig ist, kann ich (noch) nicht bestätigen. Bislang ist das > der Punkt, der mich am meisten Nerven kostet Das verstehe ich. Vielleicht erstmal einen PCF Uhrenbaustein nehmen und kommunizieren. Dann hast du eine referenz, da du weisst, dass es klappen kann. Hast du nen Uhrenbaustein da ? könntest du evt. auch Bascom benutzen (nur zum Test) ? Wenn ja, schicke ich dir was . Klaus
Naja..."problematisch" ist, dass meine Software an sich fertig ist, es also nur noch an dem I2C scheitert. Ich habe auch schon ein paar Miniprojekte mit I2C "gebaut", hat alles wunderbar funktioniert. Die nächste Stufe -- das zeitkritische Auslesen des SRF02 -- hatte ich mir nicht so viel schwerer vorgestellt. Wie gesagt, das Timing stimmt (mim Oszi nachgemessen), viele der Werte sind auch absolut korrekt. Ich denke eher, dass es hier Richtig "worst case"-Betrachtung geht, wo der SRF02 dann aussteigt...
Hi Alex, okay.. ich verstehe dass du i2c schon hattest. Aufgrund deines letzten Beitrages ist in meinem hirn aber wieder der Beitrag "Floh" eingeschossen. Er sagte: >Du weist ja, dass der Ultraschallsensor prinzipbedingt eine Weile >braucht, bis der dir die Werte geben kann? >Es gibt einige US-Sensoren, die beim Ansprechen ihre Messung starten. >Diese dauert je nach Entfernung unterschiedlich lange und dann geben sie >den Wert zurück. Während der ganzen Zeit der Messung ist der Bus >blockiert (SCK vom US auf Low). Vielleicht solltest du an der Stelle weiterdenken. Ich kenne SRF02 nicht würde mir aber vorstellen können, das man ggf. die Messung anwerfen kann um dann später das ergebnis anzuholen. Nun geht es also nicht mehr um i2c sondern ist sehr spezifisch. Vielleicht machst du mal einen neuen Thread mit der richtigen Fragestellung auf. "SRF02 auslesen Timeoutproblem Hiiiilfe !!" oder sowas. .. und bedenke-> in verschiedenen deutschen Bundesländern geht die Narrenkappe um (und die Vodkapulle). Das legt sich ab nächsten Donnerstag dann wieder. Gruss Klaus
Ich denke eben nicht, dass es SO ein zeitspezifisches Problem ist, daher habe ich den Threadtitel auch so allgemein gewählt. Ich mache es ja genau so, wie du es gesagt hast. Ich schmeiße die Messung an, mache 70ms etwas anderes und hole sie dann ab. Im Normalfall funktioniert das auch, nur eben bei den Spezialfällen dort oben nicht so wirklich. Daher hatte ich jetzt eher die Idee, dass es etwas mit der Lib von Peter Fleury zu tun hat, in Verbindung mit dem SRF02. Das Problem bei SRF02-Spezifischen Sachen ist, dass der Sensor wohl nicht sooooooo bekannt ist :\
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.