Hallo, hab hier grad etwas Probleme nen Luftmengensensor zum laufen zu bekommen. Geht um einen Honeywell Zephyr http://sensing.honeywell.com/honeywell%20zephyr%E2%84%A2%20digital%20airflow%20sensors%20haf%20series%20%28high%20accuracy%29 Der Sensor liefert nach senden der Adresse 2 Bytes und soll vorrübergehend einfach auf einem LCD ausgegeben werden, verwende nen Arduino mit LCD Shield als Platform, jedoch mit Standard AVR Entwicklungsumgebung. Programmaufbau beschränkt sich auf I2C Adresse Schicken, 2 Bytes lesen, Wert an LCD Senden. IMG_0690 zeigt den Testaufbau, Pinzuordnung/Sensorkennschlüssel wurde mehrmals überprüft, SDA Pullup 1k. Bekomme auch schon Daten zurück, dabei gibts jetzt mehrere Probleme: Bild Scope 0 zeigt den Datenverkehr (SDA/SCL) mit AVR Hardware TWI Schnittstelle. Statt Adresse 0x49 reagiert der Sensor auf Adresse 0x93 (0x49 um ein Bit nach links geschoben) aber sendet immerhin Daten zurück. Die Pegel sehen dabei allerdings schon abenteuerlich aus. Bild Scope 1 zeigt die Bit-Banging Variante (bitbang.txt) mit Adresse 0x49, Scope 2 mit 0x93, bei der der Sensor reagiert, ich schätze indem er SDA zum ACK auf LOW ziehen will und dadurch ganz komische Sachen verursacht. Hab jetzt schon verschiedene Timings, Pausen, Taktraten, Pullups etc. versucht, aber mir kommts so vor als gäbs irgendwo nen größeren Fehler den ich nicht finde. Ohne niederohmigen Pullup (1k) zieht der Sensor im übrigen schon beim anschließen die Datenleitung auf max. 2,5V... hoffe wirklich jemand sieht da einfach einen simplen Fehler den ich übersehen habe. Gruß Johannes
Angehängte Dateien:
-
IMG_0690.JPG
560 KB -
scope_0.png
9,4 KB -
scope_1.png
8,8 KB -
scope_2.png
9,4 KB
Mit der Hardware-TWI ist das zwar alles schön und gut, aber ich würde trotzdem mal auf 4,7k-Widerstände gehen und PFleurys SW-I2C-Implementation nehmen. 2,5V-Pegel sind zwar nicht toll, aber immer noch in Ordnung.
> Statt Adresse 0x49 reagiert der Sensor auf Adresse 0x93 (0x49 um ein Bit nach
links geschoben)
Ist normal. Im I2C wird mit Bit 0 mitgeteilt ob du schreiben oder lesen
willst.
D.h. man muss bei den Datenblättern immer aufpassen, ob die Adressangabe
schon diese Verschiebung um 1 Bit beeinhaltet oder nicht.
Johannes H. schrieb: > Statt Adresse 0x49 reagiert der Sensor auf Adresse 0x93 > (0x49 um ein Bit nach links geschoben) Die Adresse wird oft um eins verschoben angegeben, da das letzte Bit lediglich read/~write anzeigt. Bei SCA kommt normalerweise auch ein Pullup rein, wobei die Pegel laut Oszi gut aussehen.
Hast Du Dir die Startup-Sequence im Datenblatt auf Seite 2 angeschaut? Geschwindigkeit mal auf max 100kHz setzen und Pullups einfügen. Und 1ms zwischen den Reads warten. Was ist denn jetzt genau das Problem? Evtl. auch LCD-Probleme?
Angehängte Dateien:
-
scope_4.png
12 KB
Karl Heinz Buchegger schrieb: >> Statt Adresse 0x49 reagiert der Sensor auf Adresse 0x93 (0x49 um ein Bit nach > links geschoben) > > Ist normal. Im I2C wird mit Bit 0 mitgeteilt ob du schreiben oder lesen > willst. > > D.h. man muss bei den Datenblättern immer aufpassen, ob die Adressangabe > schon diese Verschiebung um 1 Bit beeinhaltet oder nicht. Ok, stimmt ;) Hatte bisjetzt nur ICs, bei denen die Adresse mit 0 am Ende angegeben war. Hab's nochmal mit 4,7k Widerständen versucht, damit startet das Ding allerdings garnicht. Mit 1k gehts, richtig gelesen wird wohl grad trotzdem nicht. Frequenz ist aktuell 40kHz, Messung alle 200ms. Die Fluery Libs benutz ich schon, hab mal das Haupt-Programm in den Anhang gepackt (sensor.txt). Scope 4 Zeigt die aktuelle Rückgabe, frage mich grad ob die 0x92 vom Sensor kommen oder irgeindwie noch TWDR-Leichen von senden sind... werd nochmal rumtesten. Finde die Pegel immernoch etwas komisch... wie auf dem Scope Bild zu sehen, ist die SDA Leitung selbst mit 1k schon auf 3,8V unten.
Sag mal du hast da so ein schönes Scope, hast du die "Serial Bus" Option mit gekauft? Wenn ja, mach sie mal an. Sparen wir uns das olle Bit zählen. (Rechts gibts nen knopf mit "Serial") Irgendwie sind auch die steigenden Flanken zu Steil, der Clock hat das typische Open-Drain und die Data sieht zu sauber aus, sicher das da alles richtig läuft?
Angehängte Dateien:
-
scope_5.png
12 KB
Nen schönes Scope wär schön ;D ist nen 2000er Agilent, bei dem die Serieldekodier-Funktion nicht dazugekauft werden kann (und ja den Knopf dafür gibts trotzdem...) Hab spaßeshalber mal nen sriellen Widerstand (200 Ohm) zwischen Sensor und µC gehauen, um zu sehen, wer denn von beiden was LOW zieht. Wie auf dem Bild zu sehen zieht der Sensor definitiv das ACK Low, bei den beiden i2c_readAck() funktionen gibt jedoch der Master den Pegel vor und sendet munter das TWDR... nen Test mit TWDR Änderung vor den Lese-Funktionen hat das auch bestätigt, leider grad kein Bild gemacht. Hoffe es ist ok, wenn ich hier häppchenweise den Fortschritt ins Fourm spamme. Hat die Pin I/O Initialisierung eigentlich irgend eine Auswirkung, oder wird die überschrieben, sobald man das TWI Modul aktiviert? Kurze Tests mit unterschiedlichen DDR/PORT definitionen kamen immer zum gleichen Ergebnis.
Hi >Hat die Pin I/O Initialisierung eigentlich irgend eine Auswirkung, Nein. >oder wird die überschrieben, sobald man das TWI Modul aktiviert? Ja. MfG Spess
Stimmt überhaupt die Zahl der SCL Impulse? Im mittleren Bild sieht man schön, wie vom slave beim 9.Impuls das ACK-Signal abgegeben wird. Offensichtlich schafft er es bei 1k pullup aber nicht, die Leitung auf L zu ziehen. Der zehnte Impuls hat hier doch nichts zu suchen. Vom Zeitablauf auf dem Scope-Bild nicht genau zu sehen: laufen die Änderungen auf SDA "gleichzeitig" mit der Flanke von SCL? Das darf nicht sein, Änderungen von SDA sind nur im L-Zustand von SCL erlaubt. Bei "gleichzeitig" könnte das, je nach Laufzeit schief gehen. Im Zweifelsfalle noch ein paar NOPs dazwischen legen. Hier könnte SDA im L-Zustand wechseln. Das würde als Start oder Stop-Signal gelesen.
Erstmal Sorry für meine Blödheit, waren ehrlichgesagt doch Anfängerfehler die das Problem verursacht haben. 0x92 ist natürlich die Write Adresse, was den Versuch etwas zu Lesen sinnlos macht. Mit 0x93 wird gelesen. Noch das zweite i2c_readAck in ein i2c_readNak geändert und es funktioniert (seihe Bild, noch mit seriellem Widerstand). Der verhältnismäßig niederohmige Pullup verwundert mich aber immernoch, der wird trotzdem gebraucht. Auf die Lösung kam ich im übrigen als ich mir nach dem i2c_start das TWSR in einer Variable gespeichert und später auf dem LCD ausgegeben habe. Darin war mit 0x18 = "Start zum Schreiben" alles gesagt. Aber gut, vielen Dank nochmal für die schnelle Hilfe!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.