Instabiler I²C Bus

[Sebastian B. (sebastian_b86)]

Gibt es irgendwelche Debug möglichkeiten um herauszufinden warum mein 
I²C bus instabil ist? Meistens kommen sinnvolle Werte daher, in vielen 
Fällen (geschätzte 40%) aber umgeflogene bits etc... (wobei eigentlich 
sind die bits nicht umgeflogen. Das ergebnis nach dem auslesen ist 
einfach nicht dass was ich erwartet hätte. Am Oszi schauen die werte 
genau so aus wie ich sie dann später lese - dH entweder ist SDA/SCL 
nicht im sync oder der sensor liefert mir bei einem der boards einfach 
falsche werte, siehe unten)
Die Übertragung selber scheint aber immer zu funktionieren, nur in 
wenigen Fällen spuckt das Oszi ein falsches dekoding aus (zB glaubt es 
dann dass der write command die bytes vom read beinhaltet etc)
Ich hab die SDA und SCL mit 4,7kOhm Pullups versehen, hab auch 10k 
versucht, allerdings wird es da eher schlimmer...

Interessanterweise funktioniert das ganze setup mit einem teensy 2.0 
sehr gut, lediglich auf meinem TI Tiva C Launchpad Connected klappt es 
nicht wirklich.

Mit dem Oszi sehe ich in beiden Fällen etwa die selbe Flankensteilheit, 
die selben Vpp und ähnliche dauer für Read/Write sowie die selbe SCL von 
100kHz.
Als vergleich anbei ein Screenshot vom Begin der Kommunikation (Bild 
20).
Interessant finde ich dass vorm ACK ein kleiner Rise vom SDA kommt, 
bevor er wieder low gezogen wird. Ist das normal (Bild 24)? Weiteres 
merkwürdig ist, dass scheinbar das Tiva Board 1ms braucht um zwischen 
den Bytes irgendwas zu tun. Ich mache zwischen den Reads eigentlich 
nichts... (Bild 23) Zum vergleich das lesem am teensy (Bild 15)
Ist es möglich dass durch die lange wartezeit irgendwas verschmissen 
wird? Sollte ja eigentlich nicht passieren - im datenblatt vom sensor 
steht jetzt nicht wirklich etwas ob es ein timeout gibt in dem die werte 
abgeholt werden müssen)

Das nach dem 3. byte beim lesen kein ACK kommt ist im Protokoll von dem 
Sensor übrigens so vorgesehen.

Das Device mit dem ich rede steckt im Breadboard, ist die Kapazität da 
zu hoch? Normalerweise sollte das bei 100kHz ja noch kein Problem sein 
oder?

[Patrick B. (p51d)]

Meine Güte, zeig mal Schema und Layout. Das sieht aus, als ob du riesige 
Kapazitäten auf der datenleitung hast (ev. auch die Sonde des Oszis?)...
Der Pegel kann nie auf die richtigen Werte kommen (siehe Bild 23 3 
Datenpuls).

[Sebastian B. (sebastian_b86)]

Patrick B. schrieb:
> Meine Güte, zeig mal Schema und Layout. Das sieht aus, als ob du riesige
> Kapazitäten auf der datenleitung hast (ev. auch die Sonde des Oszis?)...
> Der Pegel kann nie auf die richtigen Werte kommen (siehe Bild 23 3
> Datenpuls).

Siehe Seite 6: http://www.farnell.com/datasheets/1780639.pdf
Pullups sind 4.7k

Wie gesagt es steckt derzeit alles auf dem Breadboard - dort ist das ja 
mit den Kapazitäten nicht so toll...
Auch wenn ich die probes rausnehme wird es nicht besser.
Wie gesagt komisch ist das es mit dem teensy perfekt geht. Hat der tiva 
etwa schon von haus aus mehr C?

[Martin (Gast)]

> ... zeig mal Schema und Layout ...

Besser ist es einen Schaltplan zu posten.

[Patrick B. (p51d)]

Dein Problem liegt alleine bei der SDA Leitung. CLK sieht ja ok aus. Sie 
mal nach, ob du irgendwo Lötspritzer, Kurzschlüsse oder sonst was hast.

Hast du die Schaltung selber zusammengelötet?

[Mark R. (stevestrong)]

SDA und SCL haben unterschiedlich steile Flanken. Hast du 
unterschiedliche Wiederstände daran? Oder interne pull-ups an SDA nicht 
aktiviert?
Versuch mal extern mit 2k2 stat 4k7.

[Klaus (Gast)]

Was mir auffällt, ist daß SCL in Bild 24 nicht richtig auf low geht. 
Außerdem ist die steigende Flanke von SCL steil gegen die von SDA, als 
ob aktiv high getrieben wird, statt mit dem Pullup. Wenn das so ist, 
gibt es "clock stretching" Probleme.

Sebastian B. schrieb:
> Interessant finde ich dass vorm ACK ein kleiner Rise vom SDA kommt,
> bevor er wieder low gezogen wird. Ist das normal (Bild 24)?

Ja. Der Master läßt SDA los, der Pullup wirkt, dann zieht etwas später 
der Slave SDA zum ACK auf low

Patrick B. schrieb:
> Dein Problem liegt alleine bei der SDA Leitung. CLK sieht ja ok aus. Sie
> mal nach, ob du irgendwo Lötspritzer, Kurzschlüsse oder sonst was hast.

Das sehe ich genau anders herum

MfG Klaus

[Sebastian B. (sebastian_b86)]

Ich hab zwei sensoren auf breakoutboards, die hab ich beide selber 
reflowed und auch getestet - es funktionieren beide und haben keine 
Probleme.
Ich hab es mit dem zweiten Sensor auch probiert, dort schauen SDA und 
SCL genauso aus.
Wie gesagt das Zeug steck auf einem breadboard... wer spaß an tollen 
fotos hat, ich hab das setup hochgeladen...

edit: ja es waren zwei unterschiedliche pull ups drin...  nach dem 
wechseln zu 2k2 schaut es so aus.

das low vor dem ersten byte kommt vom sensor selber. dieser hält SCL 
solange low bis er werte hat. danach die low kommen vermutlich vom tiva 
board, das zwischen den reads wartet (warum auch immer)

[Maximillian (Gast)]

Die Vorgängergeschichte von Tiva war Stellaris, wenn ich mich nicht 
täusche und da gab es auch I²C-Probleme. Externe Pull-Ups waren zwingend 
und die API für I²C-Error-Flag-Abfrage war auch falsch.

[Patrick B. (p51d)]

Klaus schrieb:
> Patrick B. schrieb:
>> Dein Problem liegt alleine bei der SDA Leitung. CLK sieht ja ok aus. Sie
>> mal nach, ob du irgendwo Lötspritzer, Kurzschlüsse oder sonst was hast.
>
> Das sehe ich genau anders herum

Wieso? Wenn CLK von 0 auf 1 geht und das SDA Signal irgendwo zwischen 0 
und 1 hängt (aufgrund der Ladekonstante oder was auch immer), kommen 
einmal solche oder andere Werte. Das ist eher ein Zufallsgenerator.

Hast du ein anderer I2C Port zum Testen. Schau mal nach, ob auf dem 
Board schon irgendwas an dem Pin hängt. Eventuell mal die Buskapazitäten 
messen (sollten laut Datenblatt max. 400pF sein).

[Sebastian B. (sebastian_b86)]

Wie messe ich das am besten? Ich hab jetzt mittels schneller 
internetsuche nicht wirklich was gefunden das mir weiterhilft...

[Klausw (Gast)]

Patrick B. schrieb:
> Klaus schrieb:
>> Patrick B. schrieb:
>>> Dein Problem liegt alleine bei der SDA Leitung. CLK sieht ja ok aus. Sie
>>> mal nach, ob du irgendwo Lötspritzer, Kurzschlüsse oder sonst was hast.
>>
>> Das sehe ich genau anders herum
>
> Wieso? Wenn CLK von 0 auf 1 geht und das SDA Signal irgendwo zwischen 0
> und 1 hängt (aufgrund der Ladekonstante oder was auch immer), kommen
> einmal solche oder andere Werte. Das ist eher ein Zufallsgenerator.

Da SCL genau so wie SDA Open-Collector ist und von beiden (Master als 
auch Slave) getrieben werden, sollten beide einen "krummen" Anstieg 
haben, und wenn beide Pullups etwa gleich sind, auch etwa gleich. SCL 
hat aber einen fast senkrechten Anstieg. Warum?

Sebastian B. schrieb:
> das low vor dem ersten byte kommt vom sensor selber. dieser hält SCL
> solange low bis er werte hat

Wenn dann der Low-Pegel unsauber ist, sagt mir das, daß da Ausgänge 
gegeneinder arbeiten und nicht zwei Open-Collector gegen einen 
gemeinsamen Pullup. Da es Zustände gibt, bei den SCL auf Null geht, ist 
auch der Pullup im grünen Bereich.

Ich vermute SW-I2C mit suboptimaler Library,

Sebastian B. schrieb:
> Interessanterweise funktioniert das ganze setup mit einem teensy 2.0
> sehr gut

und hier HW oder bessere Library.

MfG Klaus

[Sebastian B. (sebastian_b86)]

mh, es ist eigentlich ein HW I2C... auf beiden boards.
aber alles was ich bis jetzt über das launchpad und i2c gelesen habe ist 
dass es eher ein krampf zu sein scheint.

um das breadboard auszuschließen, hab ich mal eine platine gefräst. das 
ist von den kapazitäten her auch nicht so optimal wie eine geätze 
platine aber sollte besser als das breadboard gehen. Die flanken schauen 
immer noch so aus, vllt gefühlt ein wenig steiler.

pullups sind jetzt 2.2k...

[Sebastian B. (sebastian_b86)]

Okay, wieder einen Fehler gefunden:
Die SCL Probe war eine 1:10, die SDA eine 1:1. Ich hab jetzt beide auf 
eine 1:10 gesetzt und jetzt schauen die Flanken beide sehr gleich aus.

Jedoch empfange ich immer noch blödsinn... scheint so als wäre es 
zumindest jetzt nur noch ein Software problem

Ich hab auch mal manuell das nachgerechnet was ich am oszi lese und es 
passt.
Nun bin ich beim debuggen drauf gekommen das die bytes die ich lese 
immer in irgendeiner reihenfolge ankommen! Also wirklich irgendwie... es 
ist komplett zufällig welches als erstes kommt... Ich hab das gefühl die 
lib hat einen schaden und überschreibt irgendwo buffer falsch -.-

[Mike (Gast)]

Sebastian B. schrieb:
> Die SCL Probe war eine 1:10, die SDA eine 1:1.

Und bei diesen "hyperintelligenten" DSOs merkt man das nicht mal, weil 
die gleich den Tastkopf wieder rausrechnen :-(

[Easylife (Gast)]

Das Timing ist irgendwie nicht besonders I2C konform.
Es dürften niemals beide Flanken (SCL und SDA) gleichzeitig auftreten.
Dabei besteht die Gefahr, dass eine der Seiten dies als START oder STOP 
condition interpretiert...

Zeig uns doch mal auch einen READ vom Sensor (die Datenphase).
Was für ein Sensor ist das?

[Easylife (Gast)]

Das Timing ist irgendwie nicht besonders I2C konform.
Es dürften niemals beide Flanken (SCL und SDA) gleichzeitig auftreten.
Dabei besteht die Gefahr, dass eine der Seiten die CLOCK noch high sieht 
und dann eine START oder STOP condition interpretiert...

Zeig uns doch mal auch einen READ vom Sensor (die Datenphase).
Was für ein Sensor ist das?

[Mark R. (stevestrong)]

Ich wette auf LIB Problem.
Versuch mal testweise die HW selbst per SW zu steuern, und die Daten so 
auszulesen.

[Sebastian B. (sebastian_b86)]

Hi,
@Easylife: Ja hab noch eins angehängt. Der Sensor ist ein Sensirion 
SHT21.
Beim I2C soll doch bei der steigenden Flanke gesamplet werden oder? dH 
um einen korrekten 1er zu lesen muss SDA schon high sein bevor SCL auf 
high geht oder? Wenn ich mir die Daten vom Sensor anschaue, sieht das 
sehr vernümpftig aus denke ich.

@Mark: Ja es schaut ganz danach aus. Ich hab gestern noch versucht zu 
verstehen was die lib da alles genau macht, aber sie verwendet dann die 
Funktionen aus einer TI Lib für deren I2C Bus Controller - aber ich hab 
denen mal einen Bugreport geschickt und werd versuchen die TI 
Entwicklungsumgebung mal auf einem Windows PC aufzusetzen... vllt geht 
es ja damit besser.


Generell bei dem Bild sieht man auch auf SCL dass er nur kurz auf Low 
geht und sich dann über den Pullup wieder aufläd - das sollte ja nicht 
sein. Kann es sein dass die HW hier nicht korrekt arbeitet oder einfach 
schlecht konfiguriert ist? Wie schon mal erwähnt: wenn der Sensor den 
Bus auf SCL low zieht bin ich exakt auf GND. Dort scheint das sehr gut 
zu funktionieren...

Noch eine generelle Frage: Die Kapazität am Bus messe ich rechnerisch 
durch Risetime / Pullup = C?

[Mark R. (stevestrong)]

Sebastian B. schrieb:
> Ich hab gestern noch versucht zu
> verstehen was die lib da alles genau macht, aber sie verwendet dann die
> Funktionen aus einer TI Lib für deren I2C Bus Controller

Mehr als paar Register konfigurieren (setup) und im Betrieb einige Flags 
abzufragen und davon abhängig einige Register schreiben/lesen soll es 
auch nicht sein, oder?

Das Bild zeigt, dass der Sensor I2C konform reagiert.

[Sebastian B. (sebastian_b86)]

Ich hab vorher nur mit AVR gearbeitet und noch nie mit dem TI zeugs... 
die TI I2C lib schaut zieeemlich groß aus (muss ja nix heißen) und in 
der Energia Lib werden auch sehr viele Funktionen verwendet...
Da ich Linux am Rechner verwende muss man die libs von TI aus einem exe 
entpacken (die geben die ja nur für windows her und dann immer nur als 
installer) und sich die build umgebung irgendwie selber 
zusammenfrickeln. Daher hab ich erstmal das Arduino-alike genommen, da 
dass zumindest direkt übersetzen sollte.
Also ich werd mich die tage mal hinsetzen und versuchen zu verstehen wo 
man die libs rauskopieren muss und wie dieses openocd funktioniert...

Falls wer einen tipp hat wie das alles funktioniert für das board wär 
ich auch dankbar!

[Easylife (Gast)]

Sebastian B. schrieb:
> Generell bei dem Bild sieht man auch auf SCL dass er nur kurz auf Low
> geht und sich dann über den Pullup wieder aufläd

Du meinst die paar mV... Also, solange das LOW unter 0.5V bleibt, würde 
ich mir keine Sorgen machen.
Die Signale sehen sehr sauber und gut aus. Daran wird's nicht liegen.

In DS2_QuickPrint30 wird das Datenwort vom Controller nicht mit ACK 
bestätigt.
Ist das Absicht? Das heisst normalerweise, dass das der letzte Read vor 
einer STOP condition ist...

[Sebastian B. (sebastian_b86)]

mh ich bin mir nicht sicher welches byte das ist, wenn es das dritte war 
dann sollte ein NACK und das ein Stop signal kommen.
Aber mir ist auch aufgefallen das der controller zT irgendwas macht 
(also vermutlich die lib...)
Der teensy macht das sehr sauber, dort sehe ich B1 ACK B2 ACK B3 NACK 
STOP

[Easylife (Gast)]

Also ich denke der Fehler liegt eher in der Kommunikation mit dem 
Sensor.

Beim READ darauf achten, dass der Controller alle Bytes ACKed, bis auf 
das letzte, das bekommt kein ACK.

Wenn du im "No Hold Master" Mode arbeitest, musst du das ACK bit 
Auswerten, dass der Sensor beim Senden der Adresse+READ schickt...
Und evtl. die 20us wait time nach dem Senden des Commands einhalten.

Lies dir nochmal Kapitel "5.4 Hold / No Hold Master Mode" durch.
In welchem mode betreibst du den Sensor?

[Michael R. (Firma: Brainit GmbH) (fisa)]

@Sebastian: Vielleicht steh ich auf dem Schlauch, aber dein letztes Bild 
"DS2_Quickprint30" versteh ich nicht: ist SCL hier invertiert? Warum ist 
es vor und nach der Übertragung low statt high?

ich kann auch nicht wirklich eine START Condition erkennen: Diese ist 
doch ein Wechsel von SDA von high nach low bei gleichzeitig SCL=High?

[Patrick B. (p51d)]

Irgendwie stimmt weder Start- noch Stopbedingung 
(http://i2c.info/i2c-bus-specification)

Dass die Peripherie dann irgendwelchen Müll empfängt ist absolut 
logisch. Die weiss ja nicht, wann die Daten anfangen und wann fertig 
ist.

Vorschlag:
-Anderer Master nehmen, bei dem du weisst, dass das I2C funktioniert und 
dann Testen
-Anderer Slave nehmen und dein alten Master
-Andere Lib (z.B Software I2C)

[Sebastian B. (sebastian_b86)]

Na moment, das ist ja nicht die gesamte kommunikation! Das war genau ein 
byte...

Das gesamte Protokoll vom SHT21 ist eh im Datenblatt beschrieben, es ist 
im Grunde sehr einfach: Start, Write 0x40, Data 0xE5, Read 0x40, <hold 
master vom sensor>, byte 1, byte 2, crc (1byte), Stop
Nach dem CRC soll man ein NACK senden.
Im Bild sieht man sehr gut, dass das Protokoll wunderbar decoded und 
auch die Werte passen wenn man sie manuell nachrechnet (28.98°C (erstes 
Paket) und 55.66%RH (zweites Paket)) Ich hatte zwar keine Referenz aber 
es war warm und schwül gestern, aber es ist auf jeden fall plausibel.

Das der SCL auf Low ist, liegt daran dass zunächst der Sensor den Bus 
auf low hält solange die messung erfolgt (ca 66ms bei Temperatur und ca 
22ms bei Feuchtigkeit, die werte stimmen sehr exact mit dem datenblatt 
überein!) und dass dann der master scheinbar den bus immer 1ms zwischen 
jedem byte read low hält.

Wie schon erwähnt: mit dem teensy geht es super und auch wenn ich die 
werte vom oszi ablese passt es. mit einem zweiten sensor ist es genau 
gleich.
Also es wird irgendwas in der software sein aber das kann ich erst die 
tage mal testen...

[Michael R. (Firma: Brainit GmbH) (fisa)]

Sebastian B. schrieb:
> Na moment, das ist ja nicht die gesamte kommunikation! Das war genau ein
> byte...

ah ok, das erklärt einiges...

> Das der SCL auf Low ist, liegt daran dass zunächst der Sensor den Bus
> auf low hält solange die messung erfolgt (ca 66ms bei Temperatur und ca
> 22ms bei Feuchtigkeit, die werte stimmen sehr exact mit dem datenblatt
> überein!)

Könnte darauf hindeuten, dass dein master mit dem (extremen) Clock 
stretching nicht klarkommt.

[Patrick B. (p51d)]

Ok, dann vieleicht mal das Schema von deinem Master-Board ansehen und 
überprüfen, ob wirklich nichts an den Leitungen sonst hängt.

Und mahl einen Blick in die Errata-Sheets des Controllers werfen (hatte 
bei einem STM32F4xx auch schon Probleme mit dem DCMI und USB: Das ganze 
sollte über DMA laufen und dann crashte der Prozessor immer in einen 
Hardfault-Interrupt. Resultat war, dass die irgendwas beim DMA verbockt 
haben. Dieser konnte keine grossen Datenmengen von mehreren Peripherien 
abarbeiten)

[Sebastian B. (sebastian_b86)]

bitte sehr ;) 
http://www.ti.com/ww/en/launchpad/launchpads-connected-ek-tm4c1294xl.html

[Patrick B. (p51d)]

öhm, soll ich jetzt für dich die verlinkte Seite durchsuchen (wenn ich 
wollte, hätte ich das wohl selber gefunden. Denkst du nicht?)? Oder hast 
du den Fehler bei DEINER Hardware oder Software schon gefunden?

Hier werden normalerweise LösungsVORSCHLÄGE gemacht, und nicht einem die 
Arbeit abgenommen.

[Sebastian B. (sebastian_b86)]

nein, du brauchst nichts auf der seite suchen.

ich hatte ja schon geschrieben, dass ich breadboard gegen eine platine 
getauscht habe, die sensoren gewechselt und auch den master getauscht 
habe und nur das die lösung brachte.
Also wird sich das problem sehr wahrscheinlich auf der seite des Tiva C 
abspielen (ob HW oder SW).
Ich hab mir den Schaltplan und das layout angesehen und soweit ich das 
sagen kann hängen die I2C pins direkt am µc. Im Errata steht zu I2C 
nichts.
Also bleibt die Software übrig.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Sebastian B. schrieb:
> Also bleibt die Software übrig.

Kannst das mit dem "Clock-stretching" weiterverfolgen? die 66ms scheinen 
mir recht lang, vielleicht läuft der da in ein Timeout?

[Sebastian B. (sebastian_b86)]

ich kann mal versuchen den no-hold-master zu implementieren, vllt geht 
das ja besser.

[Easylife (Gast)]

Guck dir nochmal "DS2_QuickPrint31.png" an.
Da steh bei deinen Reads immer ACKed "no".
Guck mal nach, ob schon die Adresse nich geACKed wurde. Das heisst dann 
nämlich, du solltest den Read nach der Adresse abbrechen, und nicht 
weitere Bytes lesen.
In dem Fall "pollst" du die Adresse (read) so lange, bis sie geACKed 
wird. Erst dann kannst du valide Daten lesen.

[Easylife (Gast)]

Was ich in deinem Aufbau auch nicht erkennen kann ist ein decoupling 
Capacitor.
Löte doch mal 100nF direkt auf dieses kleine grüne PCB zwischen VCC und 
GND.

[Sebastian B. (sebastian_b86)]

@Easylife: Die 3 byte read sollten mit einem NACK und Stop beendet 
werden? Zumindest steht das im Datenblatt.
Den Cap hatte ich am Breadboard drauf aber nicht auf der Platine, ja.. 
Da lässt sich aber noch einer einlöten.

[Easylife (Gast)]

Sebastian B. schrieb:
> Die 3 byte read sollten mit einem NACK und Stop beendet
> werden? Zumindest steht das im Datenblatt.

Ja, das ist richtig. Man kann nicht erkennen, was das Oszi als NACK 
markiert hat.
Wenn es schon die Adresse beim Read wäre, wäre das ein Problem.
Wenn es das letzte Daten-Byte ist, ist alles okay.

Was ist eigentlich, wenn du fehlerhafte Messwerte bekommst. Ist dann die 
Checksumme trotzdem richtig?

[Easylife (Gast)]

Was ich auch nicht ganz verstehe ist das Pinout.
Im Datenblatt des SH21 ist das ganz anders, als in deinem Aufbau, oder 
markiert der Punk auf dem Gehäuse die dem Pin 1 gegenüberliegende Ecke?

Was ist mit dem Center Pad? Hast du das mit GND verbunden?

[Easylife (Gast)]

Centerpad kannst du floaten lassen, das ist laut Datenblatt okay.
Aber mach mal die 100nF rein. "Power supply pins Supply Voltage (VDD) 
and Ground (VSS) must be decoupled with a 100nF capacitor, that shall be 
placed as close to the sensor as possible"

[Takao K. (takao_k)]

Easylife schrieb:
> Centerpad kannst du floaten lassen, das ist laut Datenblatt okay.
> Aber mach mal die 100nF rein. "Power supply pins Supply Voltage (VDD)
> and Ground (VSS) must be decoupled with a 100nF capacitor, that shall be
> placed as close to the sensor as possible"

Musste ich schon einmal eine Filterdrossel einbauen, I2C ist sehr 
sensibel. 10uF sind besser als 100nF, vielleicht auch beides.

Ansonsten mal mit software I2C (bitbang) versuchen?

[Sebastian B. (sebastian_b86)]

@Easylife: auf dem breakoutboard gibts kein centerpad und das pin1 lt 
beschriftung ist nicht pin1. ich orientiere mich nach dem DIE ausschnitt 
am sensor.
Checksumme hab ich zwar berechnet aber die war immer falsch (vermutlich 
aber weil er blödsinn gelesen hat). sollte cih auch nochmal manuell 
checken.

hab grad 4h gebraucht um von TI die libs zu laden, jetzt probier ich es 
mal direkt mit denen. Die seite ist ja extrem instabil - immer wieder 
verbindungsabrüche beim download [/rant]

[Sebastian B. (sebastian_b86)]

So ich hab jetzt das sample Programm mit der TI Lib kompiliert bekommen 
und bin dort auf interessante dinge gestoßen:
* Sie verwenden nicht den I2C Port sondern SPI, wobei im Anschlussplan 
MOSI als I2C7SDA und MISO als I2C7SCL geführt wird.
* Im Code sieht man folgendes:

    // Select the I2C function for these pins.  This function will also
    // configure the GPIO pins pins for I2C operation, setting them to
    // open-drain operation with weak pull-ups.  Consult the data sheet
    // to see which functions are allocated per pin.
    //
    GPIOPinTypeI2CSCL(GPIO_PORTD_BASE, GPIO_PIN_0);
    ROM_GPIOPinTypeI2C(GPIO_PORTD_BASE, GPIO_PIN_1);

Ich hab das Scope jetzt leider nicht bei der Hand und kann daher nicht 
sagen ob auch von der HW Seite der Bus sauberer aussieht aber die 
Software sagt mir jetzt dass sie temperatur und luftfeuchte lesen 
kann...
Wenn ich die Werte mit dem Thermometer an der Wand vergleiche kommt das 
hin.

Wenn ich wieder vorm scope sitze werd ich nochmal schauen wie jetzt der 
bus aussieht.

danke an alle die hier mitgeholfen haben!

[Easylife (Gast)]

Sebastian B. schrieb:
> Wenn ich wieder vorm scope sitze werd ich nochmal schauen wie jetzt der
> bus aussieht.

Ja bitte dokumentiere das noch für die Allgemeinheit.
Scheint ja ein heftiger Bug in der zunächst verwendeten I2C 
Implementierung zu sein (welche war das genau?)

Liegt aber nicht zufällig daran, dass du jetzt auch den 100nF 
Kondensator auf dem Board hast?

[Sebastian B. (sebastian_b86)]

nein, es ist jetzt sogar über 20cm lange jumperwire angeschlossen da das 
board jetzt nicht mehr auf die pins passt... werd aber die tage noch ein 
neues machen und auch den kondensator drauf setzen.

ich hab vorher die Energia libs verwendet, hab denen auch einen 
Bugreport geschrieben.

[Max G. (l0wside)]

Sebastian B. schrieb:
> Beim I2C soll doch bei der steigenden Flanke gesamplet werden oder? dH
> um einen korrekten 1er zu lesen muss SDA schon high sein bevor SCL auf
> high geht oder? Wenn ich mir die Daten vom Sensor anschaue, sieht das
> sehr vernümpftig aus denke ich.

WIMRE kann man beim MSP430 (auch TI) einstellen, ob der bei der 
fallenden oder bei der steigenden CLK-Flanke sampelt. Wenn du da die 
falsche Einstellung gewählt hast, ist das eine mögliche Ursache für den 
zurückgelesenen Käse.

Max

[Sebastian B. (sebastian_b86)]

Ist das nicht konvention das immer auf der rising edge gesampled wird? 
Ich hab mir die komplette I2C protokoll description nicht durchgelesen 
aber was ich gelesen hatte war dass es rising ist?

[Klaus (Gast)]

Sebastian B. schrieb:
> Ist das nicht konvention das immer auf der rising edge gesampled wird?

Während der High Phase von SCL müssen die Daten stabil sein und können 
also gesampelt werden. Das ist nicht Konvention, sondern Pflicht. Die 
High-Flanke ist der früheste Zeitpunkt in der High Phase.

MfG Klaus

[Sebastian B. (sebastian_b86)]

mh aber wieso sollte das dann konfigurierbar sein ob ich auf rising oder 
falling edge sample?

[Sebastian B. (sebastian_b86)]

Also ich hab mir die gesamte Übertragung jetzt nochmal mit dem Oszi 
angesehen.
Noch was vorweg:
* Der Sensor ist jetzt mit ca 15cm Kabel dazwischen angeschlossen, da 
das Pinout jetzt anders ist. Daher schaut das Signal vermutlich nicht 
mehr so klar aus... Muss erstmal ein neues Board machen dann könnte ich 
die Messungen nochmal machen...
* Diese Implementation verwendet jetzt no-hold Master und pollt den 
sensor nach einer gewissen dauer (die im datenblatt angegeben worst-case 
zeiten + 10ms oder so was in der richtung)
* Der CRC wird hier nicht ausgelesen. Dies kann man erreichen indem nach 
den beiden Daten bytes ein NACK statt einem ACK gesendet wird.

Bild 32: Master sendet Befehl an den Sensor
Bild 35: Read anfrage und die 2 bytes daten vom sensor
Bild 34: die gesamte kommunikation (jetzt F statt E für no-hold und nur 
zwei byte statt 3)
Bild 37: ein paar daten zu den signalen
Bild 39: Rise time am bus

[Michael R. (Firma: Brainit GmbH) (fisa)]

sorry für die offtopic-Frage: Welches oszi benutzt du? (extrem neidig 
auf die i2c-auswertung bin...)

[Sebastian B. (sebastian_b86)]

Rigol DS2072 (ist aber nicht meins ;))

[Marcus H. (Firma: www.harerod.de) (lungfish)]

@Michael: Vielleicht ist das "Digilent Analog Discovery" was für Dich?
Ist eine gute Ergänzung zu meinem TPS2024 mit seinen vier 
potentialfreien Eingängen. :)