Moin, ich versuche einen AS7261 XYZ+NIR Sensor (https://ams.com/en/as7261) mit einem atmega328p über I2C zum laufen zu bekommen. Betrieben wird der 328p mit einem 12Mhz Quarz ( ist im schem noch ein 16Mhz, das stimmt leider nicht 100%). Meine Erfahrungen mit beiden sind leider sehr beschränkt. Habe jedoch auch shcon diverse Kollegen um Rat gefragt und wir sind nicht weiter gekommen: Das Problem ist, dass ich bei der I2C initialisierung kein ACK vom sensor bekomme. Ich habe zusätzlich versucht das I2C mit einer DS1307 RTC (https://www.linkerkit.de/index.php?title=LK-RTC) aus getestet, jedoch hier genau das gleiche Problem (die RTC wurde mit 5V versorgt und nicht mit 3,3V wie der Sensor). wir haben mit einem Logic analysator geschaut ob denn der output vom 328p stimmt, dies scheint soweit der fall zu sein, bis auf das weder von der RTC noch vom sensor ein ack zurück kommt... SCL ist laut dem logic analysator die eingestellten 100k Hz und die richtige addresse + r/w bit kommt auch hinten raus aus dem 328p. nur halt keine ack Antwort.... Der 328p gibt als Status ausgabe 0x20 aus, also SLA_w transmitted - no ack dies passiert sowohl bei der addresse der RTC als auch beim sensor. Ebenso wenn ich 0x00 als addresse verwende, welche laut datenblatt des 328p ein "general call" ist auf den alle slaves mit ack antworten sollten. Spannung liegt soweit an allen Anschlüssen wie vorgesehen an, für den as7261 ist auch der i2c_enable auf 3,3V gezogen. die Pullups R2 und R3 sind 2k Ohm. In meiner Verzweiflung habe ich auch schon 4,7k Ohm eingelötet da dies zumindest für die RTC im Beispiel schematic genutzt wurde, einfach nur um es auszuprobieren... der I2C code basiert auf dem von peter fleury. zur Zeit bin ich ratlos wo das Problem ist. Irritierend ist, dass auch die RTC nicht antwortet, ansonsten hätte ich auf Hardwareprobleme an der Sensorseite geschlossen. daher hoffe ich hier hilfe zu finden :)
Hi, schonmal den IIC scanner durchlaufen lassen ? evtl hast du ja einfach nur die flaschen Adressen ;) Ich hab gerade ein ähnliches Problem, baue gerade ein Testgerät um Module zu prüfen. Durch die Leitungslänge bekomm ich beim ersten Versuch das Modul an zu sprechen auch kein ACK (aufem Ozi sehen die Pakete, jedenfalls das erste immer, nicht gut aus) hab als workaround mir ne schleife geschrieben, dass der Controller bis zu 20x versucht ne verbindung auf zu bauen. Meistens kommt das ACK nach den 2. oder 3. Versuch. Ist zwar nicht optimal aber für mein Zweck ist das in Ordnung. Gruß
- Im Datasheet sind noch 100nF beim AS7262 eingezeichnet. - AREF nicht beschaltet - Versuche mal 0x92 als Adresse (8-bit)
Was soll das?
1 | /* I2C clock in Hz */
|
2 | #define SCL_CLOCK 1000
|
Moin, in deinem ersten Bild hängt der 3,3V Via von R3 auf SCL. Nicht so schön. Viele Grüße Hannes
MP schrieb: > Main_c.txt > i2cmaster_h.txt > twimaster_c.txt > UART_h.txt Kleiner Tipp: häng *.c Dateien einfach als *.c Dateien und *.h Dateien als *.h Dateien an. Dann gibts Syntax-Highlighting kostenlos... > wir haben mit einem Logic analysator geschaut Habt ihr auch mal mit dem Oszi geschaut, ob die Signale "gut aussehen", also nicht zappeln, klingeln und vor allem die Flanken gut aussehen? > ob denn der output vom 328p stimmt, dies scheint soweit der fall zu sein, Und passt das Timing sonst zu dem, was der AS7261 erwartet? Hanni schrieb: > in deinem ersten Bild hängt der 3,3V Via von R3 auf SCL. Das ist nur die Kupferfreistellung. Allerdings ist der C5 als Blockkondensator im Layout völlig wirkungslos.
:
Bearbeitet durch Moderator
Moin, hmm schrieb: > schonmal den IIC scanner durchlaufen lassen ? > evtl hast du ja einfach nur die flaschen Adressen ;) ja, es kommt leider weder von der RTC noch vom sensor eine antwort auf irgendwelchen kanälen Pete K. schrieb: > - Im Datasheet sind noch 100nF beim AS7262 eingezeichnet. > - AREF nicht beschaltet > - Versuche mal 0x92 als Adresse (8-bit) die hardware habe ich so von einem kollegen übernommen, der ist leider ausgeschieden bevor er weiter mit arbeiten konnte. Das habe ich tatsächlich nicht gesehen und schau mal ob ich das noch verschalten kann. Es ist leider schon eine platine... ich bin für solche prototypen ja eher der Fan von Steckboards... Du meinst an VDD 1/2 zusätzlich zu dem 10uF oder? bei mir im bild C5 normalerweise sollte es doch eigentlich aber auch ohn den 100nF funktionieren wenn die signale gut aussehen oder? Zudem hat ja auch die RTC probleme, welche ich im endeffekt nur an die SCL und SDA vom 328p angeschlossen hab ( RTC hatte eine eigene stromversorgung, habe allerdings die GNDs zusammen geschaltet. Da der 328p wie gesagt schon auf Platine verlötet ist, war das etwas adhoc und sollte auch nur hardwarefehler auf der 328p seite ausschließen) 0x92 für den AS7261 habe ich auch schon direkt probiert ( ebenso 0x93 welches slave+r/w sein soll) Pete K. schrieb: > Was soll das?/* I2C clock in Hz */ > #define SCL_CLOCK 1000 sorry das ist noch überbleibsel meiner versuche. Nachdem sowohl 100k Hz als auch 400k Hz nicht funktioniert haben habe ich versucht die SCL clock extrem niedrig zu stellen (fragt mich nicht wo, aber irgendwo habe ich das als möglichen lösungsversuch gelesen) der AS7261 soll sowohl normal als auch fast-i2c können Lothar M. schrieb: >> wir haben mit einem Logic analysator geschaut > Habt ihr auch mal mit dem Oszi geschaut, ob die Signale "gut aussehen", > also nicht zappeln, klingeln und vor allem die Flanken gut aussehen? > ja wir haben auch mit dem oszi geschaut, die signale sahen soweit alle "sauber" aus ( siehe bild vom SCL) die SDA leitung habe ich leider nicht richtig raufbekommen, da der start bit ca. 100ms vor der Ack anfrage gesendet wird und mein oszi das leider nicht gemeinsam aufnimmt ( ist das evt. der kasus knacktus das zwischen start und eigentlichen daten soviel zeit vergeht?) beim aufnehmen von dem Bild eben ist mir aufgefallen, das der SCL nur mit 50k Hz läuft. da schau ich nochmal nach, aber eigentlich sollte es doch trotzdem gehen? >> ob denn der output vom 328p stimmt, dies scheint soweit der fall zu sein, Und > passt das Timing sonst zu dem, was der AS7261 erwartet? der AS7261 soll 100k und 400k Hz SCL können. Meines wissens nach sollte ein langsamerer SCL auch kein problem darstellen oder? Lothar M. schrieb: > Kleiner Tipp: häng *.c Dateien einfach als *.c Dateien und *.h Dateien > als *.h Dateien an. Dann gibts Syntax-Highlighting kostenlos... ok, ich werde mich zukünftig daran halten, war mein erster beitrag :)
MP schrieb: > ja wir haben auch mit dem oszi geschaut, die signale sahen soweit alle > "sauber" aus ( Das Bild, was du da zeigst? Gruselig! Der Ruhepegel bei I2C ist High, bei dir sieht er Low aus. Die steigende Flanke ist oben auch sehr scharfkantig. Bei 100 oder gar 400 kHz hätte ich da etwas verschleifen erwartet.
EAF schrieb: > MP schrieb: >> ja wir haben auch mit dem oszi geschaut, die signale sahen soweit alle >> "sauber" aus ( > > Das Bild, was du da zeigst? > Gruselig! > > Der Ruhepegel bei I2C ist High, bei dir sieht er Low aus. > Die steigende Flanke ist oben auch sehr scharfkantig. > Bei 100 oder gar 400 kHz hätte ich da etwas verschleifen erwartet. du hast recht, der SCL is auf low. Das ist mir auf dem bild tatsächlich nicht aufgefallen. Eine nochmalige Messung hat ergeben: der SCL witrd erst auf low gezogen, wenn ich mit dem 328p die Kommunikation starte, ansonsten ist der nämlich auf 3,3V. Ich hätte jetzt erwartet, dass solch scharfkantige flanken gut sind? ich hab da wie gesagt leider wenig erfahrung.
MP schrieb: > Ich hätte jetzt erwartet, dass solch scharfkantige flanken gut sind? Im Grunde hast du ja auch recht..... Nur, je nach den Umständen verschleift es doch etwas. Ich zeige dir mal ein Bild, wo das noch im stabilen Rahmen ist. Insgesamt 4 Busteilnehmer ca 5K Pullup, an 5V Recht lange parallel geführte Leitungen, also recht hohe Kapazität.
Ich habe noch einmal über den SCL auf low nachgedacht: es macht sinn, dass dort der SCL zu beginn auf low ist. Ich habe das oszi getriggert auf steigender flanke eingestellt. daher ist der SCL von der vom 328p gesendeten start condition auf LOW gezogen. Das wird nur nicht mehr angezeigt, da das oszi auf 25us zeitintervall gestellt ist. Im normalzustand ist der SCL wie gesagt auf 3,3V hochgezogen. im logik analyzer ist das zeitintervall ziwschen dem start und der eigentlichen ACK anfrage mit der i2c addreese wie gesagt auch irgendwie sehr lang gewesen. die gründe dafür sind mir allerdings nicht so richtig ersichtlich
MP schrieb: > irgendwie sehr lang gewesen. Wieviel ist "sehr lang" in Sekunden? > im logik analyzer Das ist doch schon mal der richtige Ansatz. Jetzt musst du aber nicht nur "Messen", sondern dein Messergebnis und den zeitlichen Verlauf von SDA UND SCL auch mit dem Timing und den Werten aus dem Datenblatt vergleichen. Dann findest du auch heraus, welche dieser Zeilen aus der "Main_c.txt" die Richtige ist:
1 | */ also tried : i2c_start(AS72621_ADDR+I2C_WRITE) / i2c_start((AS72621_ADDR) |
2 | ret = i2c_start((AS72621_ADDR<<1)+I2C_WRITE); |
Die Richtige ist nämlich die, die die korrekte Bitreihenfolge erzeugt.
:
Bearbeitet durch Moderator
Pete K. schrieb: > - Versuche mal 0x92 als Adresse (8-bit) Das ist für die Library von P. Fleury auf jeden Fall richtig. 0x92 ist die W Adresse und 0x93 dann die R Adresse.
:
Bearbeitet durch User
Lothar M. schrieb: > Die Richtige ist nämlich die, die die korrekte Bitreihenfolge erzeugt. Die Reihenfolge der Bits ist unabhängig von der Adresse, daher ist die Reihenfolge immer richtig oder immer falsch. Bei Peter Fleury wird sie immer richtig sein und ich kenne keine andere Reihenfolge beim I2C Bus Protokoll.
Falls sich das nicht schon erledigt hat: Ich hatte eben das gleiche Problem - kein ACK vom AS7261. Bei mir war das Problem, dass der AS7261 nach einem Reset anscheinend relativ lange (>200ms) braucht, bis er auf I2C antwortet. Nach einer Sekunde Wartezeit ging es. Und: Der AS7261 braucht am SPI einen Flash mit Firmware.
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.