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ß
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.
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:
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.
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.
PCB_SDA_SCL.png
(160 KB)
schematic.png
(120 KB)
