Hallo Mitstreiter. Ich stehe momentan vor einem kleinen Problem. Ich würde gerne den Sensirion SHT21 rel. Feuchte und Temp.-Sensor mit einem Atmega644p auslesen via I²C auslesen. Dazu gibt es ja einige Beschreibungen und Tuts im Web. Im Prinzip funktioniert es auch recht gut. Alle Daten/Befehle welche ich an den Sensor schicken werden erfolgreich durchgeführt. Soll heißen. Start->Sensoraddy+W->Anweisung zur Temp.Triggerung->Restart->Sensoraddy+R->Interne Messung des Sensors->!!!ab hier passiert aber nichts mehr!!! Das Problem ist also, dass mir der Sensor nichts zurückschickt. Mit dem Oszi konnte ich feststellen, dass weder ClK noch Daten auf dem Bus versendet werden. Daher meine Frage an euch. Liegt es ev. daran, dass der µC kein clk ausgibt? Wenn ja, wie kann ich diesem sagen das er "clocken" soll? Oder liegt das Problem an einer anderen Stelle. Gibt es ev. eine Initialisierung die ich vergessen habe (gibts irgendwo ne Stelle wo ich auf Master Reciever umstellen muss o.ä.) Hat jmd Erfahrungen? Oder kann ich den Sensor gar nicht im Hold Master Mode auslesen? Soweit erst einmal. Danke für Ratschläge.
Wie hast du den Sensor denn angeschlossen? Hast du Pull-Up Widerstände verwendet? (an SDA und SCL) Wie du geschrieben hast, kannst du kein CLK Signal messen. Das ist aber zwingend notwendig um eine synchrone Datenübertragung hinzubekommen. Dieses Signal ist dauerhaft an (zumindest solange man kommunizieren möchte) und kann über den Timer des Atmega gesteuert werden. Hierbei auf die Frequenz achten, diese ist abhängig von der Controllertaktfrequenz. Vllt mal einen Code-Teil (Setup und Ansprechen) oder Schaltung posten. Dann ist es sicher einfacher etwas zu finden. Gruß, wastl
der sensor benötigt einige zeit nachdem der read befehl eingegangen ist um zu messen. Die genaue zeit steht im Datenblatt. Du kannst dir aussuchen ob du im prozessor eine fixe Wartezeit einbaust oder ob du wartest bis sich der sensirion sensor wieder meldet. Der zieht die CLK oder DAT Leitung auf L oder H während des Messvorgangs(weiß ich leider nicht mehr genau). Habe das damals vor ca nem Jahr mit einer Soft-I2C Lösung gemacht auf nem PIC.... funktioniert noch immer tadellos.
Der Hold Master Mode ist das Halten des Sensor der SCL- Taktleitung auf LOW solange er am messen ist. Ich hatte vor 2 Monaten den SHT11 am Wickel und stand vor der Frage, ob ich die I²C-Peripherie verwende oder nicht. Ich habe mich für das Bitklappern entschieden, weil der SHT11 ohnehin den Stadard nicht einhält. Den mühsamen Weg habe ich deshalb gewählt, weil ich jetzt den Sensor an jeden beliebigen Port anschließen kann. Aber das läuft da genauso, die Clockleitung wird auf 0 gehalten. Erst wenn die auf 1 springt, kann man mit dem Auslesen fortfahren. Ich denke Du mußt Dir was einfallen lassen, wie Du mitbekommst, dass der Sensor die Taktleitung nicht mehr auf 0 zieht. Vielleicht ist es sinnvoll dazu einen weiteren PORT-Pin zu spendieren, der nur einliest. Diesen müßtest Du dann pollen. Ich denke die I2C-Schnittstelle auszuschalten und auf Input-Port-Funktion umzukonfigurieren ist machbar aber zu aufwendig. Wenn Du den zusätzlichen Portpin nicht spendieren kannst oder willst, dann wenn den No-Master-Hold-Modus an. Auf Seite 8 steht es beschrieben. Alternativ kannst Du auch einfach die typische Wandlungszeit warten und dann mit etwas zusätzlicher Wartezeit, die Kommunikation fortsetzen. Sollte er dauerhaft die Leitung auf 0 halten, dann würde ich sagen, ist der Sensor falsch konfiguriert oder defekt. Ich habe 6 SHT11 in Betrieb genommen und alle verhalten sich, wie im Datenblatt. Hoffe, dass ich Dir helfen konnte. Viel Erfolg
Pull-ups etc sind dran, auch warte ich 70 ms, welche der Sensor zum Messen braucht. Ich habe gerade eben noch einmal das Datenblatt durchgelesen. Gut möglich das ich die Informationen zum Slave Transmitter Mode einfügen muss damit die Kommunikation klappt. (das hatte ich bisher außer acht gelassen) Sollte ich da nicht zum Ziel kommen, werde ich wohl diese Software I2C Lösung in Betracht ziehen. Sollte dies mit dem Slave Transmitter Mode klappen, werde ich mich noch einmal melden und das Ergebnis vorstellen.
wie gewünscht nochmal der derzeitige Codestand:
//interne Pull ups
DDRC &= ((1<<0) | (1<<1));
PORTC |= (1<<0) | (1<<1);
//Bit Rate Register
TWBR = 12;
// Status Register
TWSR = 0b11111000;
while(1)
{
if (zahl == 1)
{
//Senden Startbedingung
TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN);
//Warten bis diese verschickt wurde
while (!(TWCR & (1<<TWINT)));
//Prüfen, Start mit Bestätigung vorhanden?
if ((TWSR == 0x08))
{
lcd_clear();
lcd_setcursor(0,2);
lcd_string("A");
}
//SLA+W.
TWDR = 0b10000000;
TWCR = (1<<TWINT) | (1<<TWEN);
while (!(TWCR & (1<<TWINT)))
{};
//Senden der Addresse+W und erhaltenes ACK?
if ((TWSR == 0x18))
{
lcd_setcursor(2,2);
lcd_string("B");
}
//Triggern auf Temp.
TWDR = 0b11100011;
TWCR = (1<<TWINT) | (1<<TWEN);
while (!(TWCR & (1<<TWINT)))
{
};
//Daten gesendet und erhaltenes ACK?
if ((TWSR == 0x28))
{
lcd_setcursor(4,2);
lcd_string("C");
}
//Senden erneuten Startbedingung
TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN);
//Warten bis diese verschickt wurde
while (!(TWCR & (1<<TWINT)));
//Senden der Addresse+Readbefehl
TWDR = 0b10000001;
TWCR = (1<<TWINT) | (1<<TWEN);
while (!(TWCR & (1<<TWINT)))
{};
PORTA=TWSR; //gibt0x40 aus, ist also okay
//ab hier passiert nix mehr
_delay_ms(66);
//TWCR = (1<<TWINT) | (1<<TWEN);
status=TWDR;
sprintf(Buffer, "%i", status);
lcd_setcursor(0,1);
lcd_string(Buffer);
Ahnungslos_am_Morgen schrieb: > auch warte ich 70 ms, welche der Sensor zum > Messen braucht. Das ist zu knapp. Das Datenblatt nennt maximal 85 ms in der höchsten Auflösung (die meiner Erinnerung nach die voreingestellte ist, wenn man nichts anderes auswählt). Ansonsten funktionierte das Teil bei mir auch auf Anhieb.
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.