ATmega644P - TWI - Sensor schwätz unaufgefordert

[Rush .. (rush)]

Mahlzeit Community....

Nochmal ein Posting in Bezug auf diesen Thread:
Beitrag "Re: ATmega644P TWI-ausgeschaltete Komponenten stören Bus"

Folgendes Problem. Ich habe ein RTC und einen Temperatursensor am 
I²C-Bus dran. Beide Komponenten haben verschiedene Adressen und sind 
dauerhaft mit Spannung versorgt. Nun stört der Sensor die 
Buskommunikation. Ich lasse mir in 500ms Abständen die sekunden des RTCs 
über den UART ausgeben. Ist der Sensor physikalisch nicht angeschlossen, 
so kommen richtige Werte an, also 1, 2, 3, usw....
sobald ich den Sensor anstecke, kommt entweder nur Mist an oder aber nur 
Nullen. Die internen Pullups sind gesetzt.

Hardware: ATmega644P
AVR-Studio 5.0
Sensor: HYT271

Danke schonmal im Voraus.
Konrad

[H.Joachim S. (crazyhorse)]

Ist das Teil auch wirklich für Busbetrieb vorgesehen?
Hatte auch mal Ärger mit einem RFID-Modul (Telid204 glaube ich) - da 
nannte sich die Schnittstelle auch I2C. Funktionierte auch, irgendwo im 
ganz kleingedruckten stand dann was, dass nur dieses Teil am "Bus" 
betrieben werden darf... Ende vom Lied - redesign mit 2.Bus nur dafür 
:-(

[rudi (Gast)]

aus dem Datenblatt:
"Die digitale Schnittstelle entspricht voll dem I2C-Standard und kann 
mit anderen I2C Bausteinen gemeinsam benutzt werden. Zusätzlich zur fest
vorgegebenen Adresse 0x78 kann eine zweite Adresse eingestellt werden. 
Damit ist der gleichzeitige Betrieb von bis zu 126 Sensoren am selben 
I2C Bus möglich."

Ich "vermute" eher, dass der TO die Uhrzeit per Timer-int abholt und in 
der main sporadisch die Luftfeuchte abfragt, was zu überschneidender 
Kommunikation auf dem Bus führt. Mehr gibt meine Glaskugel auch nicht 
her.

[Rush .. (rush)]

Jap, das ding ist laut datenblatt voll I2C fähig. Ich hole die Sekunden 
über eine Funktion ab. also die main ganz simpel aufgebaut..

blabla

while(1)
{
writeChar(get_seconds());
_delay_ms(500);
}

fertig.

Die Adresse von dem Sensor ist standartmäßig auf 0x28 eingestellt. Es 
steht auch geschrieben dass alternative Adresse "vergeben" werden 
können, allerdings ist nirgends im Datenblatt erwähnt wie man das macht. 
Ich vermute diese müssen vom Hersteller vergeben werden.

Der Sensor an sich funktioniert astrein. Habe es in einem seperaten 
Projekt ausprobiert. also einfach nur die Temperatur alle 500ms über den 
UART rausgegeben. Ohne Probleme. Und die Werte geben auch die richtige 
Temperatur wider.

Noch jemand einen Vorschlag?

Gruß, Konrad

[Mike R. (thesealion)]

Scope anschließen und den Bus ansehen.

Ansonsten tippe ich auf einen Fehler in Zeile 42.

[Rush .. (rush)]

ich gucke ja schon mit dem Logicanalyzer drauf. Allerdings erscheint mir 
dort nichts verdächtiges. Habe den Screenshot mal mit drangepackt. Die 
ersten beiden Databytes sind vom rtc. das zweite von denen die sekunden. 
die restlichen vier bytes sind 2 byte feuchte und zwei byte temperatur.
Quellcode hängt auch mit dran.

[[Frank] (Gast)]

>Die internen Pullups sind gesetzt.
Sind also keine externen Pullups für den Bus vorhanden? Wenn nein, dann 
mal probeweise 1-2K einsetzen.

Frank

[Rush .. (rush)]

ne, habe nur die internen an.

[Gerhard. (Gast)]

Hallo Frank,

fand eine vielleicht nützliche Link zum Thema:

http://www.ibrieger.de/?q=node/43

Eines ist mir aufgefallen: Warum sind Deine HYT271 Addressen 0x50/0x51 
und nicht 0x28 wie im Datenblatt angegeben? Hast Du sie mit der 
Fabriksoftware verändert?

Das Datenblatt ist meiner Ansicht nach ziemlich bedürftig. Die Intersema 
DOcs sind im Vergleich viel hilfreicher.

Gruß,

Gerhard

[Michael A. (Gast)]

Rush ... schrieb:
> Es steht auch geschrieben dass alternative Adresse "vergeben" werden
> können, allerdings ist nirgends im Datenblatt erwähnt wie man das macht.

Dafür steht es hier:
Beitrag "Re: HYT371 bzw. baugleich -> Adresse ändern"

[spess53 (Gast)]

Hi

>ne, habe nur die internen an.

Die sind viel zu groß.

MfG Spess

[Tip (Gast)]

Gerhard. schrieb:
> Eines ist mir aufgefallen: Warum sind Deine HYT271 Addressen 0x50/0x51
> und nicht 0x28 wie im Datenblatt angegeben? Hast Du sie mit der
> Fabriksoftware verändert?

0x28 ist die (7-bit) I2C-Adresse, 0x50/0x51 sind die (8-Bit) Adressbytes 
für Schreib- bzw. Lesezugriff

[Gerhard. (Gast)]

Tip schrieb:
> Gerhard. schrieb:
>> Eines ist mir aufgefallen: Warum sind Deine HYT271 Addressen 0x50/0x51
>> und nicht 0x28 wie im Datenblatt angegeben? Hast Du sie mit der
>> Fabriksoftware verändert?
>
> 0x28 ist die (7-bit) I2C-Adresse, 0x50/0x51 sind die (8-Bit) Adressbytes
> für Schreib- bzw. Lesezugriff

Hallo Tip,

ich habe mir noch einmal das Datenblatt angesehen und bleibe dabei weil 
BIT6 im Datenblatt wirklich BIT7 ist. Wenn Du Dir das Datenblatt auf 
Seite 6 ansiehst ist die Gesamtnummer der Bits inklusive dem 
Schreib/Lese Bit gleich 8. Dann kann die Adresse nie und nimmer 
0b01010000 sein und sollte für Befehle 0b00101000(0x28) sein und für 
Lesezugriffe 0b00100001(0x29) sein. Ich glaube wirklich Du irrst Dich.

Auf Seite 6 sollte das Datenblatt mit BIT 7 anfangen und nicht bit6. 
Sonst sind es ja inklusive des Schreib/Lese Bits ja 9 Bits und das geht 
doch nicht. Schreibadressen sind immer 8 bits inklusive des S/L Bits.

Hier ein Auszug aus seiner Source:

#define HYT271_ADR      0b01010000 - (8-bits) = 0x50
#define HYT271_ADR_READ    0b01010001 - 0x51


Gruß,
Gerhard

[Gerhard. (Gast)]

Sollte: 0b00101001(0x29) heissen. Sorry!

Lesezugriffe 0b00100001(0x29) sein. Ich glaube wirklich Du irrst Dich.

[Rush .. (rush)]

Hm... eigentlich steht es ja im datenblatt eindeutig geschrieben. Die 
Adresse geht von bit 6 bis 0. Macht insgesammt 7 bits. Und dann kommt 
noch das R/W bit hinzu. Was für 0x50 und 0x51 sprechen würde. Im Anhang 
nochmal der Auszug aus dem Datenblatt.

[Rush .. (rush)]

Hier ein Auszug aus dem ZMD-Datenblatt:

3.6.1 I2C Features and Timing
The cLiteTM uses an I2C-compatible communication protocol†† with support 
for 100kHz and 400kHz bit rates. The
cLiteTM I2C slave address (00H to 7FH) is selected by the Device_ID bits 
in the Cust_Config EEPROM word (see
Table 5.5 for bit assignments). The device will respond only to this 
address if the communication lock is set by
programming 011B in the Comm_lock bits in the ZMDI_Config EEPROM word 
(see Table 5.2 for bit assignments);
otherwise, the device will respond to all I2C addresses. The factory 
setting for the I2C slave address is 28H with
Comm_lock set.

Verstehe ich das richtig? Der sensor ist serienmäßig auf 0x28 
eingestellt und  Comm_lock ist gesetzt. Dass heisst er antwortet nur auf 
28.

Nun hatte ich vorher, wie Gerhard schon meinte, schreiben und lesen auf 
28 und 29 gestellt. Und der sensor hatte auch geantworet. bei 50 und 51 
tut er es auch. das würde doch darauf hindeuten dass dieses comm_lock 
bit nicht gesetzt ist und der sensor somit auch auf anfragen antwortet 
die eigentlich fürs RTC gedacht sind. oder was meint ihr ?

[Tip (Gast)]

Gerhard. schrieb:
> Hier ein Auszug aus seiner Source:
>
> #define HYT271_ADR      0b01010000 - (8-bits) = 0x50
> #define HYT271_ADR_READ    0b01010001 - 0x51

In den #defines steht das Adressierungsbyte fertig für die Übertragung 
mit dem R/W Bit als Bit 0 und der 7-bit I2C Adresse als Bits 1..7.
In der Protokollbeschreibung sind die Bits der I2C Adresse nummeriert, 
nicht die Bits innerhalb des Bytes. Eigentlich ist doch alles klar.

[Rush .. (rush)]

Ja das ist ja klar mit den Adressen. Ich habe mal spaßhalber versucht 
das teil mit verschiedenen Adressen anzusprechen und siehe da, das ding 
reagiert...
so ein mist...