Seid gegruesst werte Mitbastler! Habe gestern einen Beschleunigungssensor von ST (LIS302DLH)per i2c an meinen Mikrocontroller angeschlossen (tiny2313). Das Folgende ist alles auf Software basierend aufgebaut, keine TWI-Hardware benutzt. 1. Habe die Addresse gesendet und ein "Write" am Ende angehaengt (8bit alles zusammen) und ein acknowledge zurueckerhalten. 2. Dann die Sub-Addresse (Registerauswahl) geschickt und wiederum ein Acknowledge erhalten. 3. Daraufhin habe ich wieder die Addresse geschickt diesmal mit einem "Read" im Anhang (8Bit alles zusammen) und noch ein Acknoledge erhalten. Laut Datenblatt sollte nun der Controller anfangen, den Registerinhalt auf der SDA Leitung mit jedem Taktsignal hinaus zu "shiften", bekomme aber nur Einsen zurueck und keine Informtionen, obwohl ich das Who_am_I Register auslese, welches nicht leer sein sollte. Bzgl. meiner Vorgehensweise: Da ich hier kein Oszi zur Verfuegung habe, benutze ich momentan den Dragon zum Debuggen. Sprich ich gehe Schritt fuer Schritt durch den Code und schaue mir an, was die Pins sagen. Konnte da bis jetzt auch noch keinen Fehler feststellen. Noch eine Verstaendnissfrage: 1. Waehrend die Clock low ist, kann ich doch auf der SDA Leitung machen was ich will, dass sollte den Slave eigentlich nicht kuemmern oder? 2. Bedingt durch den Debugmodus des AVRDragons betreibe ich den Chip momentan mit einer Clockfrequency von rd. 1Hz ist das evtl. zu wenig? Konnte dazu keine Angaben im Datenblatt finden. Einzig die Slave Datahold Time koennte damit was zu tun haben, die besagt, dass die Daten nach der fallenden Flanke des ClockSignals noch 4 Microsekunden anliegen. Da ich jedoch noch waehrend der High periode auslese sollte das keine Probleme geben. Fuer eure Tips, Anregungen und Erfahrungen bin ich euch dankbar. Ich hoffe, dass ich mit eurer Unterstuetzung das Teil zur Kommunikation bekommen werde.
Achso nochwas: 1. Programmiere in ASM 2. der Chip antwortet nur, wenn ich die korrekte Addresse schicke. Auf die Falsche Addresse scheint er nicht zu reagieren. Zumindest dieser Teil geht also schonmal wuerde ich sagen. Gruesse Tueftler
>1. Waehrend die Clock low ist, kann ich doch auf der SDA Leitung machen >was ich will, dass sollte den Slave eigentlich nicht kuemmern oder? Und was machst du da?
Durch die Pullups kann es passieren, dass die Leitung auf high geht, z.B. wenn ich den SDA-Port im Muc von Ausgang auf Eingang umschalte, beim Umschalten von Senden zu Empfangen bzw bei der Auswertung des Acknowledge.
Hallo, die Bedingungen bei I2C werden so signalisiert (Start, Stop), ich habe kein Diagramm hier zur Hand um nachzuschauen, es ist auf jeden Fall ungünstig. I2C ist prinzipiell ein Bus, an dem die Leitungen OpenDrain sind und ihr H über die PullUps erhalten. Auch CLK darf z.B. kein PushPull-Ausgang sein, weil ein Slve mit Clock-Stretching CLK auf L halten darf, wenn er mehr Zeit braucht. Das finden dann beide bei AVR mit aktiv H auf CLK nicht so lustig. Für Software I2C als: externe PullUp, PORT auf L und DDR als Eingang ergibt den Eingang für SDA/SCL und Ausgang als H durch externen PullUp. Für Ausgang L jetzt nur DDR auf Ausgang und aktiv L liegt an. So ist man normgerecht und vermeidet unangenehme Überraschungen, spätestens, wenn man ein anderes I2C mit seinen Routinen benutzt, das diese Bedingungen auch ausnutzt. Selbst die uralte AVR-Appnote für TWI hat z.B. Clock-Stretching nicht berücksichtigt, womit ich promt bei einem MAS3507D tagelang nach dem Fehler gesucht habe... Gruß aus Berlin Michael
Vielleicht solltest Du auch START/STOP senden. Es ist im allgemeinen recht unnütz, zu beschreiben, was man meint, in der SW programmiert zu haben. Der kommentierte Quelltext (als Dateianhang!) ist deutlich informativer. Einen praktischen I2C-Sniffer kann man sich schnell basteln: Beitrag "I2C (TWI) Sniffer mit AVR" Peter
Hallo vielen Dank erstmal fuer Eure Beitraege. Werde den Quellcode heute Abend mal posten. Hab auch an Start+Stop im Quellcode gedacht, nur vergessen hier zu erwaehnen. @Michael: Hab ich Dich nun richtig verstanden: 1. Fuer die Highpase: Clockpin im MuC als Eingang definieren (externe Pullups heben dann die Spannung an) DDR= 0 und PORT = 0 2. Fuer die Lowphase: Clockpin als Ausgang, mit DDR= 1 und PORT = 0. Ja scheint eine gute Idee zu sein. Gleiches Prinzip geht ja auch mit der Datenleitung wenn ich jetzt nicht irgendwas grob uebersehen habe oder? Werde mal meinen Code dieser Idee anpassen und dann hier posten. @Peter: Ja ist mir dann auch bewusst geworden, habe aber leider keinen Quellcode zur Hand gehabt (Mittagspause, war auf Arbeit). Aber ich entnehme euren Beitraegen dass es erstmal nicht an einer zu langsamen Clock-Taktung liegen sollte, da man auch eine sehr langsame Clock benutzen koennen sollte? Vielen Dank erstmal, bis bald. Tueftler
Hallo, Tueftler86 schrieb: > @Michael: Hab ich Dich nun richtig verstanden: > > 1. Fuer die Highpase: Clockpin im MuC als Eingang definieren > (externe Pullups heben dann die Spannung an) > DDR= 0 und PORT = 0 > > 2. Fuer die Lowphase: Clockpin als Ausgang, mit > DDR= 1 und PORT = 0. > > Ja scheint eine gute Idee zu sein. > > Gleiches Prinzip geht ja auch mit der Datenleitung wenn ich jetzt nicht > irgendwas grob uebersehen habe oder? > Werde mal meinen Code dieser Idee anpassen und dann hier posten. Ja. Port bleibt so immer auf 0, Geschaltet wird nur mit DDR und man kann jederzeit den tatsächlichen Zustand des Pins lesen. CLK als H gesetzt und L zurückgelesen würde dann eben zum Warten zwingen, bis der Slave CLK wieder freigibt (Clock-Stretching eben). Gilt für beide Leitungen, dann ist zumindest die Hardware mit allen I2C-ICs kompatibel. Zum Takt: mir ist nicht aufgefallen, ob ein Hersteller inen minimalen Takt angibt, allerdings habe ich auch nicht so darauf geachtet. Gruß aus Berlin Michael
So ich bins nochmal, Hab jetzt den Code auf den "Pull-up"-Betrieb umgeschrieben. Und siehe da, nun sagt mir der Sensor wenigstens wie er heisst. Hängt vermutlich auch damit zusammen, dass ich den ganzen Code nochmal detailliert durchgegangen bin. Dabei sind mir noch ein par Fehler aufgefallen. Hab den Code mal angehängt. Muss nur noch die Wartezeiten anpassen, da ich bis jetzt nur per Dragon debuggt habe, wobei das Timing unkritisch, da sowieso viel zu langsam, ist. Bei weiteren Fragen komme ich nochmal auf euch zurueck. Mit Grüßen, Tueftler
Angehängte Dateien:
-
IMG_9623.JPG
180 KB
Und hier noch ein Bild vom Sensor, Per Dead-Bug aufgelötet. Das geht erstaunlich gut schnell und einfach und ist selbst bei kleineren Pinabständen noch möglich (mit normalem Lötkolben und ausreichend Flussmittel wohlgemerkt)
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.