Hallo zusammen, habe einen Chip (MGC3130) von Microchip der mit I²C angesteuert wird. Ich möchte von Ihm nur Daten lesen. Der Chip verwendet das Clock Stretching. Meine Frage kann das ein Amtega 644p oder Atmega 64? Habe das Datenblatt durchgelsen aber nichts von Clock Stretching gefunden. Oder ist Clock Stretching bei der normalen TWI implementierung dabei die im Controller vorhanden ist? Vielen Dank schonmal!
Ich behaupte mal, dass ein µC, der eine I2C-HW-Unit besitzt, sich an den I2C-Standard hält, der Clock-Stretching beinhaltet. Auch wenn Atmel es bis heute nicht geschafft hat, TWI wieder I2C zu nennen, nachdem das I2C-Patent ausgelaufen war. :-)
Hast du mal die Such-Funktion deines PDF-Programms ausprobiert? Stichwort "stretch", zweiter Treffer, erklärt dass der ATmega644 selber die Clock stretcht: "While the TWINT Flag is set, the SCL low period is stretched". Ich gehe davon aus, dass er es auch versteht wenn ein anderes Gerät das tut.
Das I²C Protokoll des Chips ist wenn ich es am Oszi anschaue gestrecht mit dem Beispielprogramm aber wenn ich die TWI HW (Atmel) benutze ist es nicht mehr gestrecht. Danke für die Info vom Datenblatt, habe immer nach Clock stretching gesucht. Mhh dann seid ihr also der Meinung das es der Controller hinbekommen müsste?
Ich weis halt nicht, wenn das Signal nicht gestrecht ist und ich die Empfangenen Daten mit ACK bestätige ob das dan nicht zu schnell geht und der Chip das ACK nicht erkennt. Danke übrigens für eure Hilfe
>Das I²C Protokoll des Chips ist wenn ich es am Oszi anschaue gestrecht Bild zeigen. >mit dem Beispielprogramm aber wenn ich die TWI HW (Atmel) benutze ist es >nicht mehr gestrecht. Dann benutz doch die TWI HW wenns dann nicht mehr gestrecht ist. Wo ist eigentlich dein Problem?
Das läuft doch alles über die HW-Units. Ein Empfangen eines ACKs wird über die HW-Unit zur Verfügung gestellt und ein Senden eines ACKs automatisch generiert. Ich weiß also nicht, was Du da noch irgendwie selber generieren möchtest. Wenn Du via zwei GPIOs SW-I2C implementieren möchtest, gebe ich Dir Recht. Aber das wäre dann eher Sadomaso.
>Wenn Du via zwei GPIOs SW-I2C implementieren möchtest, gebe ich Dir >Recht. Aber das wäre dann eher Sadomaso. Das ist oft einfacher als die vergurkte I2C Hardware so manchen uCs zu benutzen;)
holger schrieb: > Das ist oft einfacher als die vergurkte I2C Hardware so manchen > uCs zu benutzen;) Beispiele?
Das sehe ich anders. Trotz möglicher Fehler in I2C-Units (siehe Errata sheets) erhält man hier eine standardkonforme I2C-Implementierung. Und die bezweifle ich bei einer SW-Lösung.
>Trotz möglicher Fehler in I2C-Units (siehe Errata sheets) erhält man >hier eine standardkonforme I2C-Implementierung. > >Und die bezweifle ich bei einer SW-Lösung. Warum sollte eine SW Lösung nicht Standard konform sein? Das kommt ja wohl ganz auf die Software an.
Weil ich behaupte, dass ein SW-Entwickler gar nicht in der Lage ist, eine derart komplexe SW fehlerfrei zu schreiben, die dem I2C-Standard entspricht.
Guten morgen zusammen, mein Problem liegt darin das mir der Chip keine Daten schickt und ich nehme an das es daran liegt, dass das ack welches der Controller sendet zu schnell kommt. Und im Datenblatt steht das der Chip das Stretching macht und wollte nun wissen ob es meine Twi Hardware auch einfach so macht oder ich alles von Hand ( ganze Twi )selber schreiben muss.
Hi >Guten morgen zusammen, mein Problem liegt darin das mir der Chip keine >Daten schickt und ich nehme an das es daran liegt, dass das ack welches >der Controller sendet zu schnell kommt. Das hat mit großer Sicherheit andere Ursachen. MfG Spess
Angehängte Dateien:
-
Unbenannt.PNG
46 KB
Mhh, hab mir halt am Oszi angeschaut wie es aussehen soll und da ist mir halt aufgefallen das das ACK erst anch einer bestimmten zeit kommt also gestrecht und wollte halt wissen ob das der atmel auch erkennt. Weil das ACK schickt ja der µC zum Chip. Sobald der Chip es erlaubt. So hab ichs bis jetzt verstanden. Vielen Dank bis hier hin
yvger schrieb: > Und die bezweifle ich bei einer SW-Lösung. Ach komm. Was ist so kompliziert daran, den SCL als open-drain zu benutzen und die Abfrage einzufügen:
1 | while( SCL_in == 0 ); |
Die meisten SW-I2C benutzen nur dumme Slaves (PCF8574 usw.), da ist SCL ein Eingang. Deshalb schenken die sich die Abfrage.
yvger schrieb: > Weil ich behaupte, dass ein SW-Entwickler gar nicht in der Lage ist, > eine derart komplexe SW fehlerfrei zu schreiben, die dem I2C-Standard > entspricht. Wie kommst du darauf? Ich kenne I2C noch lange nicht bis ins hinterste Detail, allerdings scheint mir das ganze nun wirklich nicht eine hochkomplexe Sache zu sein, zumindest nicht was eine simple Kommunikation mit irgendwelhen Standard Bausteinen angeht. Habe auf der Arbeit selbst einige Projekte am laufen, habe bisher immer SW-I2C benutzt und hatte bisher noch nie Probleme damit.
Peter Dannegger schrieb: > Ach komm. > Was ist so kompliziert daran, den SCL als open-drain zu benutzen und die > Abfrage einzufügen:while( SCL_in == 0 ); Hoffentlich wird hier nicht aktiv auf das Ende der Clock-Stretching-Phase gewartet. > Die meisten SW-I2C benutzen nur dumme Slaves (PCF8574 usw.), da ist SCL > ein Eingang. Deshalb schenken die sich die Abfrage. Das mag sein. Ich spreche hier aber die ganze Zeit von der Umsetzung einer HW-I2C-Unit in Software und nicht um eine bis auf die minimalen Funktionen abgespeckte SW-Lösung, die nur bei den einfachsten I2C-Slaves funktioniert. > Wie kommst du darauf? Ich kenne I2C noch lange nicht bis ins hinterste > Detail, allerdings scheint mir das ganze nun wirklich nicht eine > hochkomplexe Sache zu sein, Da hast Du Dir die Antwort schon selber gegeben. Wie willst Du die Komplexität beurteilen, wenn Du (noch nicht einmal) die I2C-Spezifikation kennst? > zumindest nicht was eine simple > Kommunikation mit irgendwelhen Standard Bausteinen angeht. Davon war auch von meiner Seite aus nie die Rede, s.o. > Habe auf der Arbeit selbst einige Projekte am laufen, habe bisher immer > SW-I2C benutzt und hatte bisher noch nie Probleme damit. Selber die SW-I2C-Lösung programmiert oder existierend übernommen? Und wenn, dann (wohl?) wie schon oben angedeutet, nur um sehr einfache I2C-Slaves anzubinden? Hier liegt die aktuelle I2C-Spezifikation (Version 6 vom 04.04.2014): http://www.nxp.com/documents/user_manual/UM10204.pdf Und da will man mir erzählen, es wäre eine Leichtigkeit, eine HW-I2C-Unit in SW zu programmieren?
yvger schrieb: > ch spreche hier aber die ganze Zeit von der Umsetzung > einer HW-I2C-Unit in Software und nicht um eine bis auf die minimalen > Funktionen abgespeckte SW-Lösung, die nur bei den einfachsten I2C-Slaves > funktioniert. Wie schon gesagt, als Single-Master muß man nur die While-Schleife zum SCL testen hinzufügen. Und schon hat man die komplette standard konforme Funktion eines Single I2C-Masters für Slaves mit Clock-Stretching. Man könnte noch ein Timeout hinzufügen, falls der Slave mal hängt. Das muß man beim HW-TWI des AVRs dann aber auch machen. Die ganzen Multimaster- und Slavefunktionen braucht man nicht. Die sind auch in SW zumindest mit einem AVR nicht zu wuppen, da der AVR nicht garantierte <4µs Response schafft, wenn er noch andere Tasks ausführen soll.
Peter Dannegger schrieb: > Wie schon gesagt, als Single-Master muß man nur die While-Schleife zum > SCL testen hinzufügen. Aber mit Sicherheit nicht, indem man aktiv während des Programmablaufs wartet. Schön, dass man dann mittels Timeout wenigstens überhaupt noch aus dieser Schleife käme (mit darauf folgendem Fehlerhandling?)... Das Hinzufügen der erwähnten Schleife ist die Quick-and-Dirty-Lösung, wenn es einem egal ist, dass man die Ausführung seines restlichen Codes blockiert. Wir sprechen hier bestimmt nicht über ein darunter liegendes präemptives Multitasting OS.
Hi also bist du der Meinung, das man mit dem normalen twi hardware konfig bei atmel ein stretching hinbekommt?
yvger schrieb: > Aber mit Sicherheit nicht, indem man aktiv während des Programmablaufs > wartet. Doch. SW-Lösungen können nur warten. Sie haben keine HW, die einen Interrupt auslöst. Aber auch die meisten AVR-Beispiele mit HW-TWI sind nicht interrupt basiert. Sie warten aktiv auf das Setzen des Interruptbits, notfalls für immer. Sie sind damit kein jota effektiver als SW-I2C. Ob auf nen Pin warten oder auf das Interruptbit, das ist Jacke wie Hose.
F1234567 schrieb: > Hi also bist du der Meinung, das man mit dem normalen twi hardware > konfig bei atmel ein stretching hinbekommt? Ja. Es läßt sich auch nicht abschalten. Wie gesagt, ein Timeout ist immer zu empfehlen.
F1234567 schrieb: > Mhh, hab mir halt am Oszi angeschaut wie es aussehen soll und da > ist mir > halt aufgefallen das das ACK erst anch einer bestimmten zeit kommt also > gestrecht und wollte halt wissen ob das der atmel auch erkennt. Weil das > ACK schickt ja der µC zum Chip. Sobald der Chip es erlaubt. So hab ichs > bis jetzt verstanden. > > Vielen Dank bis hier hin hm, das sieht aber nicht nach "streching" aus, aber eher nach unregelmässige CLK takten. das kann ich aber nicht GANZ genau beurteilen weil die Auflösung zu niedrig ist. Übrigens, wie erzeugt das Beispielprogramm das CLK Signal? SW? Hast Du Fotos auch über Signale erzeugte vom uC? Soweit ich weiss, ACK soll bei Adressierung und Daten schreiben eigentlich vom Slave kommen, damit der Master weiss das der Ansprechpartner die Daten empfangen hat. Bei lesen sendet der Slave kein ACQ, der macht dann stretching wenn notwendig, das ist aber eher unwarscheinlich solange der Master nicht über 100kHz taktet.
:
Bearbeitet durch User
Mark R. schrieb: hm, das sieht aber nicht nach "streching" aus, aber eher nach unregelmässige CLK takten. das kann ich aber nicht GANZ genau beurteilen weil die Auflösung zu iedrig ist. Soweit ich weiss, ACK soll bei Adressierung und Daten schreiben eigentlich vom Slave kommen, damit der Master weiss das der Ansprechpartner die Daten empfangen hat. Antwort: Ja das ACK kommt vom Slave sobald er die 8bit (adresse) gesendet bekommt, sendet er die Daten an den µC und dieser dann das nächste ACK. Nur sobald der µC das Ack, müsste eien unterbechung des Takts kommen aber mein µC sendet leider das Ack gleich mit nach den 8 bit ohen das 9 bit zu stretchen.
F1234567 schrieb: > Antwort: Ja das ACK kommt vom Slave sobald er die 8bit (adresse) > gesendet bekommt, sendet er die Daten an den µC und dieser dann das > nächste ACK. Nur sobald der µC das Ack, müsste eien unterbechung des > Takts kommen aber mein µC sendet leider das Ack gleich mit nach den 8 > bit ohen das 9 bit zu stretchen. Wenn der Master (uC) beim Lesen das 9. bit Ack-ed, das bedeutet der will noch mehr bytes lesen. Stretchen sollte nur der Slave wenn er nicht schafft rechtzeitig das nächste byte dem Master zur Verfügung zu stellen. Wenn der Master noch nicht bereit ist das nächste byte zu lesen (da die SW die Daten aus dem HW-Register noch nicht ausgelesen hat), er generiert einfach das SCK Signal für die Datenübertragung nicht (ja gut, das könnte man eventuell als "stretching" sehen, ist es aber nicht). Solange die SW die Daten zeitnah ausliest, dann geht die SCK Signal ungestört weiter. Und das ist normal so, muss keine Unterbrechung da sein. Deswegen verstehe ich immer noch nicht wo du ein Problem siehst.
:
Bearbeitet durch User
> Wenn der Master (uC) beim Lesen das 9. bit Ack-ed, das bedeutet der will > noch mehr bytes lesen. Stretchen sollte nur der Slave wenn er nicht > schafft rechtzeitig das nächste byte dem Master zur Verfügung zu > stellen. > Wenn der Master noch nicht bereit ist das nächste byte zu lesen (da die > SW die Daten aus dem HW-Register noch nicht ausgelesen hat), er > generiert einfach das SCK Signal für die Datenübertragung nicht. > Deswegen verstehe ich immer noch nicht wo du ein Problem siehst. Mein Problem ist, dass ich Daten vom Chip lesen möchte. Wenn ich die 8 Bit emfpange auf dem µC gibt der ein ACK raus. Jetzt ist es aber so das der Chip nur 0 schreibt. Als ich das Protokoll des Starter kit mit dem Oszi beobachtet habe war der einzige unterschied, dass das 9bit (ACK) des µC mit einem jeweils unterschiedlichen Abstand zu den vorher 8 Datenbits kommt.
F1234567 schrieb: > Mein Problem ist, dass ich Daten vom Chip lesen möchte. Wenn ich die 8 > Bit emfpange auf dem µC gibt der ein ACK raus. Jetzt ist es aber so das > der Chip nur 0 schreibt. Als ich das Protokoll des Starter kit mit dem > Oszi beobachtet habe war der einzige unterschied, dass das 9bit (ACK) > des µC mit einem jeweils unterschiedlichen Abstand zu den vorher 8 > Datenbits kommt. Wieviele bytes liest du auf einmal (mit einer Adressierung)? Das CLK Signal für 9. bit (ACK) wird vom Master verspätet generiert nur wenn der Master nicht bereit ist die Daten zu lesen => die Master SW hat die HW-Register (Master I2C Data reg.) noch nicht ausgelesen. Das kann eventuell mit dem Starter-Kit vorkommen, aber warscheinlich nicht mit dem stand-alone uC. Das sollte aber auf keinem Fall Wirkung auf den gelesenen Wert (byte) haben! Wenn doch, dann kannst Du mit dem uC auch probeweise einen delay einfügen, vielleicht unterstützt der Slave den realen stretching nicht, oder die interne HW des Chips erzeugt die richtige Daten nicht schnell genug.
:
Bearbeitet durch User
Und welches byte hat den falschen Wert? Delay sollte man vor dem Auslesen der falschen byte einfügen.
Mhh nach den ersten 16 Byte (1 mal auslesen) kommt das (2mal auslesen und da sind alle empfangenen bytes müll und wie schon gesagt es sieht alles gleich aus wie beim starterkit bis auf das ack das kommt in meinem programm gleich nach den 8 bit (1byte).
Es werden 16 bytes 2 mal hintereinander ausgelesen, richtig? Beim ersten Mal auslesen sind alle 16 bytes OK, richtig? Beim zweiten Mal sind alle ausgelesene bytes falsch (obwohl I2C protokoll gleich ist wie beim ersten Mal), richtig? Wenn es so ist, dann muss man sich Fragen ob es am Chip zeitkritische Anwendungen ablaufen, die zwischen die 2x Auslesen die richtige Daten nicht rechtzeitig generieren können. In diesem Fall man muss einen delay zwischen 1. auslesen und 2. auslesen hinzufügen.
Mhh ja, das könnte sein aber im Datenblatt ist nichts zu finden. Deswegen glaub ich fast das mein µC das ACK nach dem Empfang der Daten zu schnell rausschickt und der Slave noch nicht bereit ist das ACK zu erkennen.
>Mhh ja, das könnte sein aber im Datenblatt ist nichts zu finden. >Deswegen glaub ich fast das mein µC das ACK nach dem Empfang der Daten >zu schnell rausschickt Schick für das letzte zu lesende Byte ein NACK, so wie es sein muss. Sonst kann es sein das der Slave sauer reagiert.
Peter Dannegger schrieb: > Doch. > SW-Lösungen können nur warten. Sie haben keine HW, die einen Interrupt > auslöst. Entweder reden wir hier nebeneinander her...? Was meinst Du mit "SW-Lösungen?" genau? Reine SW ohne irgendeine Form einer Hardware? Zwei Lösungen wären hier z.B. ein Zeitscheibenmodell mit kooperativem Multitasking oder ein präemptives Multitasking mittels OS. Oder sprechen wir hier nicht über eine SW, die auf einem µC laufen soll? Wenn man Clock stretching erkennt wird nicht aktiv gewartet, sondern mit anderen Aufgaben weiter gemacht, bis das nächste Mal erneut auf Clock stretching geprüft wird.
yvger schrieb: > Auch wenn Atmel es bis heute nicht geschafft hat, TWI wieder I2C > zu nennen, nachdem das I2C-Patent ausgelaufen war. Das Auslaufen des Patentes bedeutet nicht, dass es nicht in allen Zielmärkten von Atmel noch Marken- oder andere Schutzrechte an der Bezeichnung I2C geben könnte.
Wikipedia sagt: "Allerdings ist das ursprüngliche Patent am 1. Oktober 2006 ausgelaufen, so dass keine Lizenzgebühren für die Benutzung von I²C mehr anfallen. I²C ist auch kein eingetragenes Markenzeichen von NXP Semiconductors, Markenschutz besteht lediglich für das Logo." Sicher könnte das auch heißen "das ursprüngliche Patent am 1. Oktober 2006 für Deutschland ausgelaufen", ich dachte, es gelte global.
Hallo yvger, yvger schrieb: > Hier liegt die aktuelle I2C-Spezifikation (Version 6 vom 04.04.2014): > http://www.nxp.com/documents/user_manual/UM10204.pdf Wissen wir, kennen wir, benutzen wir immer als Referenz bei Streitfällen. yvger schrieb: > Weil ich behaupte, dass ein SW-Entwickler gar nicht in der Lage ist, > eine derart komplexe SW fehlerfrei zu schreiben, die dem I2C-Standard > entspricht. yvger schrieb: > Und da will man mir erzählen, es wäre eine Leichtigkeit, eine > HW-I2C-Unit in SW zu programmieren? Dir ist aber schon bekannt dass diverse I2C-Master und I2C-Slave-Bibliotheken im Umlauf sind, die das I2C-Protokoll per uC-Software über normale Ports abwickeln (Fleury, Dannegger, etc.) ? yvger schrieb: > Wenn man Clock stretching erkennt wird nicht aktiv gewartet, sondern > mit anderen Aufgaben weiter gemacht, bis das nächste Mal erneut auf > Clock stretching geprüft wird. Nö, warum. Es soll doch gerade ein Byte gelesen werden. Also wartet die uC-Lib aktiv auf entweder das Ende des Clock-Stretching des Slave oder das erreichen eines Timeout, und tut sonst nichts anderes. yvger schrieb: > Wir sprechen hier bestimmt nicht über ein darunter liegendes präemptives > Multitasting OS. Nein, natürlich nicht. Hat auch niemand. yvger schrieb: > Zwei Lösungen wären hier z.B. ein Zeitscheibenmodell mit kooperativem > Multitasking oder ein präemptives Multitasking mittels OS. > > Oder sprechen wir hier nicht über eine SW, die auf einem µC laufen soll? > > Wenn man Clock stretching erkennt wird nicht aktiv gewartet, sondern > mit anderen Aufgaben weiter gemacht, bis das nächste Mal erneut auf > Clock stretching geprüft wird. Wie gesagt: Über präemptives Multitasking redet hier niemand ausser dir. LG, Sebastian
Hallo F1234567, dummy schrieb: >>Mhh ja, das könnte sein aber im Datenblatt ist nichts zu finden. >>Deswegen glaub ich fast das mein µC das ACK nach dem Empfang der Daten >>zu schnell rausschickt > > Schick für das letzte zu lesende Byte ein NACK, so wie es sein muss. > Sonst kann es sein das der Slave sauer reagiert. Oder du hast einfach das Senden der Stop-Bedingung noch nicht richtig. LG, Sebastian
Sebastian Wangnick schrieb: > Hallo yvger, > > yvger schrieb: >> Hier liegt die aktuelle I2C-Spezifikation (Version 6 vom 04.04.2014): >> http://www.nxp.com/documents/user_manual/UM10204.pdf > > Wissen wir, kennen wir, benutzen wir immer als Referenz bei > Streitfällen. > > yvger schrieb: >> Weil ich behaupte, dass ein SW-Entwickler gar nicht in der Lage ist, >> eine derart komplexe SW fehlerfrei zu schreiben, die dem I2C-Standard >> entspricht. > yvger schrieb: >> Und da will man mir erzählen, es wäre eine Leichtigkeit, eine >> HW-I2C-Unit in SW zu programmieren? > > Dir ist aber schon bekannt dass diverse I2C-Master und > I2C-Slave-Bibliotheken im Umlauf sind, die das I2C-Protokoll per > uC-Software über normale Ports abwickeln (Fleury, Dannegger, etc.) ? Ja ist mir bekannt, sowas soll es geben. > yvger schrieb: >> Wenn man Clock stretching erkennt wird nicht aktiv gewartet, sondern >> mit anderen Aufgaben weiter gemacht, bis das nächste Mal erneut auf >> Clock stretching geprüft wird. > > Nö, warum. Es soll doch gerade ein Byte gelesen werden. Also wartet die > uC-Lib aktiv auf entweder das Ende des Clock-Stretching des Slave oder > das erreichen eines Timeout, und tut sonst nichts anderes. Dö. Sonst blockiert ein Clock stretching unbekannter Dauer die Abarbeitung anderer Aufgaben. Der hoffentlich implementierte Timeout ist nur die Exit-Strategie im Fehlerfall. > yvger schrieb: >> Wir sprechen hier bestimmt nicht über ein darunter liegendes präemptives >> Multitasting OS. > > Nein, natürlich nicht. Hat auch niemand. Wo lebst Du denn? Hinter dem Mond? > yvger schrieb: >> Zwei Lösungen wären hier z.B. ein Zeitscheibenmodell mit kooperativem >> Multitasking oder ein präemptives Multitasking mittels OS. >> >> Oder sprechen wir hier nicht über eine SW, die auf einem µC laufen soll? >> >> Wenn man Clock stretching erkennt wird nicht aktiv gewartet, sondern >> mit anderen Aufgaben weiter gemacht, bis das nächste Mal erneut auf >> Clock stretching geprüft wird. > > Wie gesagt: Über präemptives Multitasking redet hier niemand ausser dir. Weil es die Angelegenheit der aktiv wartenden While-Schleife zumindest entschärfen könnte. Als Antwort auf Peter Danneggers Vorschlag.
yvger schrieb: > Wenn man Clock stretching erkennt wird nicht aktiv gewartet, sondern > mit anderen Aufgaben weiter gemacht, bis das nächste Mal erneut auf > Clock stretching geprüft wird. Das Clock Strechting wird im allgemeinen nicht über 1..10µs dauern. Da lohnt sich ein riesen Brimborium mit Flankeninterrupt einfach nicht. Ein Byte dauert ja schon 90µs. Ab und zu mal 10µs zu warten, macht den AVR nicht spürbar langsamer. Ganz im Gegenteil, ein Interrupt mit Prolog, Epilog usw. würde deutlich mehr CPU-Zeit fressen und das Programm nur unnütz kompliziert machen. Wie es scheint, ist auch weder SW-I2C noch Clock Strechting das Problem des OP. Ich würde erstmal versuchen, dumme Slaves wie PCF8574, AT24C32 zum Laufen zu bringen. Mit 2 SW-Baustellen gleichzeitig macht man es sich nur unnötig kompliziert.
F1234567 schrieb: > Der Chip verwendet das Clock > Stretching. Meine Frage kann das ein Amtega 644p oder Atmega 64? Habe > das Datenblatt durchgelsen aber nichts von Clock Stretching gefunden. Ja, kann er. Steht auch im Datenblatt, 18.3.5: "The Slave can extend the SCL low period by pulling the SCL line low. This is useful if the clock speed set up by the Master is too fast for the Slave, or the Slave needs extra time for processing between the data transmissions. The Slave extending the SCL low period will not affect the SCL high period, which is determined by the Master. As a consequence, the Slave can reduce the TWI data transfer speed by prolonging the SCL duty cycle." F1234567 schrieb: > Mhh ja, das könnte sein aber im Datenblatt ist nichts zu finden. > Deswegen glaub ich fast das mein µC das ACK nach dem Empfang der Daten > zu schnell rausschickt und der Slave noch nicht bereit ist das ACK zu > erkennen. Das klingt unwahrscheinlich. Der Master erhöht ja die SCL-Speed gar nicht. Warum sollte der Slave den ACK also nicht erkennen können? Sollte er allerdings noch nicht bereit sein, das nächste Byte zu senden, dann würde er (der Slave) ja gerade die SCL-Leitung auf LOW halten (das famose clock stretching) bis er soweit ist. F1234567 schrieb: > Antwort: Ja das ACK kommt vom Slave sobald er die 8bit (adresse) > gesendet bekommt, sendet er die Daten an den µC und dieser dann das > nächste ACK. Nur sobald der µC das Ack, müsste eien unterbechung des > Takts kommen aber mein µC sendet leider das Ack gleich mit nach den 8 > bit ohen das 9 bit zu stretchen. Es ist der Slave, der SCL stretched. Der Master bestimmt SCL. Dein Problem liegt mit ziemlicher Sicherheit woanders, insbesonders wenn du einen kompletten Datensatz korrekt empfängst und aber dann den zweiten nicht. Entweder fehlt dir die NACK- oder die STOP-Generierung auf der Master-Seite. Zeig doch noch mal ein benutzbares Oszi-Recording. LG, Sebastian
> F1234567 schrieb: >> Nur sobald der µC das Ack, müsste eien unterbechung des >> Takts kommen aber mein µC sendet leider das Ack gleich mit nach den 8 >> bit ohen das 9 bit zu stretchen. Nö, der AVR Master taktet immer alle 9 Bit am Stück. Der Empfänger muß daher das ACK/NACK schon vor dem Byte setzen. Wenn es ihm erst vor dem Stop einfällt, ist es zu spät. Wenn der Slave das SCL nicht strecht, heißt das, er sieht keinen Grund dazu.
Peter Dannegger schrieb: > Das Clock Strechting wird im allgemeinen nicht über 1..10µs dauern. Da müsste ich jetzt selber noch mal in die Spezifikation schauen. Wie lange darf denn eine Clock-Stretching-Phase maximal sein? Die ~10µs beziehen sich wohl auf einen I2C-Bus mit 100kbit/s. Es soll auch µCs geben, die ein wenig flinker sind und auch in 10µs jede Menge abarbeiten können.
Böse Falle. http://www.i2c-bus.org/de/takterzeugung-clock-stretching-arbitrierung/ "Bemerkenswert ist, daß die I2C-Spezifikation keine Maximalzeiten für das Stretching vorsieht, so daß diese Verzögerung beliebig lange andauern darf."
yvger schrieb: > Wie lange darf denn eine Clock-Stretching-Phase maximal sein? Es gibt bei I2C keine Maximalzeiten. Wenn es Dir gefällt, kannst Du auch 10 Jahre erlauben. In einer Multimasteranwendung habe ich mal 10ms festgelgt. D.h. wenn SDA oder SCL länger als 10ms auf low bleiben, wird der Bus für tot erklärt und alle Teilnehmer disablen kurz ihren I2C-Controller. Die 10µs waren nur ein Schätzwert, in welcher Zeit der I2C-Interrupt bequem abgearbeitet werden kann (AVR mit 16MHz = 160 Zyklen). Bei einem alten original 8051 mit 12MHz/12 wird es länger dauern. Ein Cortex M3 wird bequem mit 1µs hinkommen oder DMA machen (0µs).
yvger schrieb: > Böse Falle. > > http://www.i2c-bus.org/de/takterzeugung-clock-stretching-arbitrierung/ > > "Bemerkenswert ist, daß die I2C-Spezifikation keine Maximalzeiten für > das Stretching vorsieht, so daß diese Verzögerung beliebig lange > andauern darf." Ja böse Falle, deswegen ist auch ein Recovery nach einem Timeout schwierig, da danach der I2C Bus in einen undefinierten Zustand ist. Die SMBUS Spec definiert übrigens einen maximalen Wert an den sich die Slaves halten müssen, zur Not mit einer Watchdog. I2CDevices die länger brauchen sind nicht SMBUS Kompatibel.
Peter Dannegger schrieb: > In einer Multimasteranwendung habe ich mal 10ms festgelgt. Dann haben wir hier aber ein generelles Problem, da man nicht mehr zwischen tatsächlichem "ewig" dauerndem Clock-Stretching und z.B. einem hängenden Bus unterscheiden kann. Wäre clever, wenn zumindest die Hersteller von I2C-Slave-Devices hier ihre maximale Clock-Stretching-Zeit angeben würden. Oder halso in der Spezifikation eine maximal erlaubte Zeit festlegen: "Die SMBUS Spec definiert übrigens einen maximalen Wert an den sich die Slaves halten müssen.". Das Fazit wäre aber bei aktuellen µCs, in der Clock-Stretching-Phase nicht aktiv zu warten, sondern mit anderweitigen Aufgaben weiter zu machen. Dass man sich für einen Timeout selber eine Zeit definieren muss, ist eine böse Schwäche der aktuellen I2C-Spezifikation.
yvger schrieb: > Wäre clever, wenn zumindest die Hersteller von I2C-Slave-Devices hier > ihre maximale Clock-Stretching-Zeit angeben würden. Ja, tun sie aber nicht. Im Timing-Diagramm des MGC3130 sind so drei Takte angedeutet (Figure 6-4), aber das kann natürlich beliebig mehr sein. Also trial and error. Lattice User schrieb: > Ja böse Falle, deswegen ist auch ein Recovery nach einem Timeout > schwierig, da danach der I2C Bus in einen undefinierten Zustand ist. Da hilft nur allen Teilnehmern den Stecker zu ziehen... Im Ernst, wo immer möglich gehe ich dazu über, Peripherie über uC-Ports mit Strom zu versorgen, um garantiert einen definierten Zustand wieder herstellen zu können. Das ist manchmal nicht ganz einfach -- der nRF24L01+ zum Beispiel kann sich mit einen CKOUT-Takt an XT1 über Wasser halten, selbst wenn VCC hochohmig wird! yvger schrieb: > Das Fazit wäre aber bei aktuellen µCs, in der Clock-Stretching-Phase > nicht aktiv zu warten, sondern mit anderweitigen Aufgaben weiter zu > machen. Ja, oder nicht, je nachdem. Wenn der uC nur für diese Gestensteuerung da ist, und der Gestensteuerungschip nicht antwortet, dann hat er halt keine anderweitigen Aufgaben. Dafür braucht es dann auch eben keine interruptgesteuerte I2C-Bedienung, oder I2C-Hardware, sondern SW-I2C mit busy-wait-until reicht aus. Das Fazit kann nur der OP ziehen. LG, Sebastian
Mike schrieb: > holger schrieb: >> Das ist oft einfacher als die vergurkte I2C Hardware so manchen >> uCs zu benutzen;) > > Beispiele? Raspberry Pi :) LG, Sebastian
:
Bearbeitet durch User
Sebastian Wangnick schrieb: > > F1234567 schrieb: >> Antwort: Ja das ACK kommt vom Slave sobald er die 8bit (adresse) >> gesendet bekommt, sendet er die Daten an den µC und dieser dann das >> nächste ACK. Nur sobald der µC das Ack, müsste eien unterbechung des >> Takts kommen aber mein µC sendet leider das Ack gleich mit nach den 8 >> bit ohen das 9 bit zu stretchen. > > Es ist der Slave, der SCL stretched. Der Master bestimmt SCL. Ganz genau, der Master sendet SCL, strechen (wenn notwendig) sollte der Slave. Auch ACK wird beim lesen vom dem Master bestimmt. > > Dein Problem liegt mit ziemlicher Sicherheit woanders, insbesonders wenn > du einen kompletten Datensatz korrekt empfängst und aber dann den > zweiten nicht. Entweder fehlt dir die NACK- oder die STOP-Generierung > auf der Master-Seite. Zeig doch noch mal ein benutzbares Oszi-Recording. > > LG, Sebastian Bin ich auch der Meinung. Was hier tatsächlich Hilfe schaffen würde ist ein zoom-in plot von dem letzten (nr. 16?) richtig empfangenen byte (Ende 1. Datensatz, um die STOP-Bedingung zu erkennen), und das erste empfangene byte (mit faslchem Wert) von dem 2. Datensatz (um ACK zu beurteilen).
:
Bearbeitet durch User
Ich hab gerade den Spec vom MGC3130 gelesen. Da gibt es auch eine TS (Transfer Status) Leitung die vom Master gesteuert werden muss: "The MGC3130 (I2C Slave) uses this line to inform the host controller (I2C Master) that there is data available which can be transferred. The host controller uses the TS line to indicate that data is being transferred and prevents MGC3130 from updating its data buffer." Hast Du das berücksichtigt bzw. Vorschriftsmässig implementiert? Sonnst kann es sein, dass der Chip keine gültige Datensatz zur Verfügung stellen kann, so liest man halt nur Müll raus...
Hallo, wollte mich bedanken für die Unterstützung hab jetzt den Fehler gefunden und es funktioniert. So wie es aussieht war den Chip in einem art Schlafmodus und ist nicht mehr aufgewacht. Desweiteren wollte er die Firmware info die er vershickt mit 132 byte komplett ausgelesen haben und bestätigt. Vielen Dank nochmal an alle!
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.