Ich möchte zwei ATtiny (aktuell im Test: ATtiny1614 auf eigenem Board bzw. ATtiny817 auf ATtin817 Xplained Board) per I2C verbinden, der eine also als Master, der andere als Slave. Ahnungslos wie ich bin habe ich gedacht, ich mache das mit der Treibersoftware, die Microchip über Atmel Start zur Verfügung stellt. Diese Software ist ein Graus und weitestgehend undurchschaubar, zumindest für meinen (beschränkten) Kenntnisstand in C-Programmierung. Nach LANGER Suche habe ich zwei Beiträge gefunden, die sich mit dem Problem zumindest auf Seiten des Masters auseinandersetzen: https://www.avrfreaks.net/forum/tiny-avr-1-series-twi-woes https://www.avrfreaks.net/comment/2294056#comment-2294056 Der Code dort ist zumindest kurz und überschaubar. So richtig zufriedenstellend ist es aber nicht, wenn man liest, dass das alles "irgendwie" funktioniert und sich beide Verfasser nicht ganz einig sind, welche Statusbits jeweils für zuverlässige Funktion gesetzt werden müssen. Offenbar funktioniert auch nicht alles in der Atmel-Hardware so, wie im Datenblatt vorgesehen. Für Series 0 und Series 1 gibt es jeweils im Anhang der Datenblätter erschreckend klingende (und leicht unterschiedliche) Fehlerlisten. Das ist nicht sehr vertrauenerweckend. Frage: kennt jemand eine bewährte Quelle für zuverlässige I2C-Routinen (Master und Slave) für diese Prozessoren? Gibt es jenseits der Microchip-Treiber so etwa wie eine Standardbibliothek dafür? Für Tips und Links wäre ich sehr dankbar. Ich will keine großartigen Sachen machen, nur kurze Messages, wenige Byte lang, zwischen beiden Prozessoren austauschen.
Es scheint in den angegebenen Orten um Code zum LM75 und USART zu handeln. Vielleicht auch Arduino. Einzige Stelle die ich kenne ist bei www.jtronic.de zu finden. Ob es auf deiner Hardware läuft kann ich nicht sagen. Versuche selber was zum Attiny 841 und I2C zu finden. Wenn du was findest oder schreibst würde mich auch interessieren. LG Peer
Peer schrieb: > > www.jtronics.de Das hilft leider nicht weiter. Jtroncics schreibt, dass er die Bibliothek von Peter Fleury verwendet. Das ist Software-Bitbanging, darauf wird auch hier verwiesen: https://www.mikrocontroller.net/articles/AVR_TWI (ganz unten auf der Seite). Die neueren Series 0 / Series 1 ATtinys haben dafür ein Hardware-Interface. Das ist bloß nicht besonders gut beschrieben und mein Verständnis der Dokumentation deckt sich nur bedingt mit den Quellen im Avrfreaks-Forum. Daher meine Frage, ob es etwas gibt, das verlässlicher ist.
Schade wenn es nicht hilft. Verwende selber die Datein von Peter für meine anderen Prozessor. Für USI verwende ich auch die Datein von jtonics. Da hilft woll nur weiter suchen oder was eigenes schreiben.
Beispiel in Assembler: https://community.atmel.com/projects/avr-megatiny-series-01-twi-master-sensor-hyt271
GermanFranz schrieb: > Beispiel in Assembler: > https://community.atmel.com/projects/avr-megatiny-series-01-twi-master-sensor-hyt271 Hallo GermanFranz. Danke. Und schon sind wir wieder voll in der von mir angesprochenen Problematik: "kennt jemand eine bewährte Quelle für ZUVERLÄSSIGE I2C-Routinen (Master und Slave) für diese Prozessoren?" Der Code initialisiert lt. Kommentar den Chip im Smartmode (SET (SMARTMODE-) MASTER ACK). Dazu die Errata im Datenblatt: TWI Smart mode gives extra clock pulse TWI Master with Smart mode enabled gives an extra clock pulse on SCL line after sending NACK. Fix/Workaround: None. Ist das nun problematisch, unsicher, oder egal?
:
Bearbeitet durch User
Dieter R. schrieb: > Ist das nun problematisch, unsicher, oder egal? Den Peter Fleury willst ja nicht nehmen gell, weil das is ja das verpöhnte Bitbanging, was ja soooo scheisse ist.
Warum in die Schwerne feifen, das Gute liegt so nah! Beitrag "AVR: I2C Master Software Library für alle AVR"
Dumpfbacke schrieb: > Warum in die Schwerne feifen, das Gute liegt so nah! > > Beitrag "AVR: I2C Master Software Library für alle AVR" Ich will mich mal bemühen, ernsthaft auf Dumpfbacke zu antworten, obwohl das schwer fällt: 1. Das ist von 2015 und nur für "alle" AVR, die es da gab. Series 0/1 und die Fragen nach der Register- und Statusbehandlung bei selbigen gab es noch nicht. Ein bisschen dazu steht übrigens in den eingangs von mir zitierten Sources bzw. Posts, samt den beim Debugging aufgetretenen Problemen. Das muss man aber lesen, um zu verstehen, dass es nicht ganz so trivial ist. 2. Warum Bitbanging nicht das Mittel der Wahl ist, wenn es im Prozessor eine komplette I2C-Engine gibt, nur schlecht dokumentiert, brauch wohl keine Erläuterung. Natürlich ist Bitbanging unter diesen Umständen Scheiße, wenn man das denn so ausdrücken möchte. Ich suche eine kompetente Lösung und kein Gefrickel.
Dieter R. schrieb: > Dazu die Errata im Datenblatt: > TWI Smart mode gives extra clock pulse Interessant. Der Hinweis findet sich bei der 0-series Errata nicht und der Code funktioniert auf einem Mega4808 auch anstandslos. Soweit ich das bislang verglichen habe ist das TWI Modul mit dem der 1-series identisch!? Davon abgesehen muß der Smartmode ja nicht unbedingt Verwendung finden. Man kann ihn vor dem Senden von NACK im Master-Read auch abschalten bzw. ganz außen vor lassen und sein ACK konventionell über die Command bits senden.
Dieter R. schrieb: > ZUVERLÄSSIGE I2C-Routinen frage: welche software kann fuer ihre fehlerfreiheit garantieren???
Zweifelnder schrieb: > Dieter R. schrieb: >> ZUVERLÄSSIGE I2C-Routinen > > frage: welche software kann fuer ihre fehlerfreiheit garantieren??? Beeil dich, du bist spät, der Kindergarten hat schon seit 8 Uhr geöffnet. Ernsthaft: zuverlässig heißt z. B., dass mögliche Fehlerbedingungen abgefangen werden, Timeouts vorhanden sind für Abbruch nach eventuellen Übertragungsstörungen usw. Bewährt heißt, dass die Software nicht nur beim Verfasser läuft, sondern in einer möglichst großen Breite von verschiedenen Applikationen. Die Series 0/1-Prozessoren von Atmel/Microchip sind ja als ausgesprochene Massenprodukte positioniert. Umso mehr erstaunt es mich, dass es anscheinend wenig brauchbare Unterstützung für die I2C-Schnittstelle gibt - wenn man mal von der Microchip-Originalsoftware absieht, die ich in der Tat für wenig brauchbar halte. Vielleicht bin ich auch bloß zu doof zum finden. Hier zumindest ist bisher auch nicht viel Ernsthaftes gekommen, abgesehen von den Ansätzen durch GermanFranz, wofür ich mich nochmals bedanke.
GermanFranz schrieb: > Dieter R. schrieb: >> Dazu die Errata im Datenblatt: >> TWI Smart mode gives extra clock pulse > > Interessant. > Der Hinweis findet sich bei der 0-series Errata nicht ... Das hat mich auch ganz erheblich irritiert und nährt weitere Zweifel an der Atmel-Dokumentation. Series 0 kam ja nach Series 1 auf den Markt. Wenn dafür neue Masken mit Fehlerbehebungen genommen wurden, sollte man annehmen, dass diese Fehlerbehebungen auch in Series 1 eingeflossen sind (bei den minimalen Unterschieden zwischen den ICs habe ich sowieso Schwierigkeiten, mir vorzustellen, dass das lauter verschiedene Maskenversionen sind). Meine frisch gekauften ATtiny1614 melden sich aber mit Revision A, also erste Maske. Mindestens einen weiteren nicht dokumentierten Chip-Fehler habe ich inzwischen an ganz anderer Stelle gefunden. Will man den UART-Ausgangspin selbst ansteuern (weil man z. B. noch andere Peripherie daran angeschlossen hat, in meinem Fall eine LED), dann muss man manchmal (also vorsichtshalber immer) das Transmitter Empty Flag setzen, sonst kann man nicht auf den Ausgang zugreifen - auch, wenn nie ein Zeichen gesendet wurde, der Transmitter also ganz bestimmt empty ist. Die Chips scheinen etwas mit der heißen Nadel bzw. Maske gestrickt zu sein. Genau deshalb suche ich Code, der schon einen möglichst breiten Realitätstest bestanden hat. Scheint aber schwierig zu sein.
Dieter R. schrieb: > Offenbar funktioniert auch nicht alles in der Atmel-Hardware so, > wie im Datenblatt vorgesehen. Für Series 0 und Series 1 gibt es jeweils > im Anhang der Datenblätter erschreckend klingende (und leicht > unterschiedliche) Fehlerlisten. Das ist nicht sehr vertrauenerweckend. Der sicherste Weg ist, entweder andere Prozesoren (keine AVRs) oder was anderes als I2C für die Kommunikation zwischen den Prozessoren zu nehmen. Die I2C-Implementierung im AVR war noch nie eine Erfolgsgeschichte. Oliver
Oliver S. schrieb: > Die I2C-Implementierung im AVR war noch nie eine > Erfolgsgeschichte. Ach woher denn. Ich kenne zwar andere Controller nicht genauer und weiß daher nicht, ob die I2C Maschinerie dort einfacher und sicherer zu bedienen ist. Beim AVR hat aber noch jedes diesbezügliche Programm funktioniert und warum sollte das bei den aktuellen Typen anders sein? Das einzige was (neuerdings) ziemlich stiefmütterlich behandelt wird sind die Datenblätter...
Dumpfbacke schrieb: > Den Peter Fleury willst ja nicht nehmen gell, weil das is > ja das verpöhnte Bitbanging, was ja soooo scheisse ist. Und stimmt ja auch gar nicht. Wenn man sich mal mit dem Code beschäftigt, erfährt man schnell, das es davon abhängt, welche Datei man nun ins Projekt nimmt. Wählt man die 'i2cmaster.s', ist es Bitbanging. Wählt man 'twimaster.c', wird das Hardware Interface benutzt.
Matthias S. schrieb: > Dumpfbacke schrieb: >> Den Peter Fleury willst ja nicht nehmen gell, weil das is >> ja das verpöhnte Bitbanging, was ja soooo scheisse ist. > > Und stimmt ja auch gar nicht. Sorry, ich habe mir zwar das ZIP-File von Peter Fleury Website heruntergeladen, im Beispielprogramm aber nur den Hinweis auf die Assembler-Source für Bitbanging gesehen. Dass twimaster.c die Hardware benutzt, habe ich übersehen. Irgendwie scheint er mir den Hinweis darauf gut versteckt zu haben. Ich werde mir das noch mal genauer ansehen. Drei Fragen sind damit aber (noch) nicht gelöst: 1. Was ist bei Portierung auf Series 0/1 zu beachten? 2. Generell fehlt mir die Fehlerbehandlung. Ich sehe z. B. keine Timeouts, falls der Slave nicht antwortet. Vielleicht übersehe ich da aber auch etwas, ich habe jetzt bloß mal kurz reingeguckt (Die I2C-Spezifikation fordert meines Wissens keine Timeouts, aber praktisch muss man ja irgendwas machen, damit die Software nicht hängt). 3. Slave?
Oliver S. schrieb: > > Der sicherste Weg ist, entweder andere Prozesoren (keine AVRs) oder was > anderes als I2C für die Kommunikation zwischen den Prozessoren zu > nehmen. Die I2C-Implementierung im AVR war noch nie eine > Erfolgsgeschichte. Gehen wir das mal von der praktischen Seite an. Hast du einen Vorschlag, was man/ich statt ATtiny1614/1616/1617 nehmen soll? Feature-Set, Mindestanforderungen: Capacitive Touch (mit Unterstützung für Slider) Configurable Logic mit Response Time << 1us ADC USART (bloß zum Debuggen, aber da ganz praktisch) I2C Vielleicht habe ich noch was vergessen, aber das ist aktuell in Gebrauch bzw. in Arbeit, neben üblichem Kleinkram wie Timer, Watchdog usw. Ich bin nicht auf Atmel fixiert, sondern für jede Alternative offen (auch wenn es lästig wäre, den vorhandenen Code auf eine andere Plattform zu portieren).
Dieter R. schrieb: > Timeouts, falls der Slave nicht antwortet. Vielleicht übersehe ich da > aber auch etwas, ich habe jetzt bloß mal kurz reingeguckt (Die > I2C-Spezifikation fordert meines Wissens keine Timeouts, aber praktisch > muss man ja irgendwas machen, damit die Software nicht hängt Nach dem Schreiben der Adresse (im UNKOWN Busstatus) wird doch WIF gesetzt bzw. der zugehörige Interrupt ausgelöst und Du kannst RXACK nachprüfen. Da hängt nichts.
Ich habe das jetzt nicht überprüft, nur als Frage: was ist mit RIF? Kann das nicht hängen, wenn der Slave nicht antwortet?
Dieter R. schrieb: > Ich habe das jetzt nicht überprüft, nur als Frage: was ist mit > RIF? Kann das nicht hängen, wenn der Slave nicht antwortet? Gehen wir davon aus daß die Adresse wie beschrieben vom Slave bestätigt wurde. RIF wird jetzt beim weiteren Lesen im Master-Read nur dann ausgelöst wenn das nächste Byte vom Slave ordnungsgemäß empfangen wurde. Die Software ist nun am Zuge und hält den Leseprozess mit dem Auslesen von MDATA weiter am Laufen (oder beendet ihn). Käme es beim Empfang zu Problemen würde statt dessen automatisch WIF gesetzt und man kann der Fehlerursache via MSTATUS (im Interrupt) auf den Grund gehen und geeignete Maßnahmen ergreifen.
GermanFranz schrieb: > Nach dem Schreiben der Adresse (im UNKOWN Busstatus) wird doch WIF > gesetzt... Kleine Korrektur: Natürlich im IDLE Status, den man im UNKNOWN Status nach TWI Enable herbeiführen kann!
1. Nach weiteren Tests und tieferem Einstieg in das Datenblatt: der oben von mir zitierte Code (von beiden Verfassern) aus dem avrfreaks-Forum scheint mir fraglich zu sein. Ich neige inzwischen der Meinung zu, dass es unverstandenes Zeug ist und der Prozessor falsch bedient wird. Weiteres aber später, ich bin noch am Testen. 2. Nochmal Nachfrage zum Timeout. Wenn ich den Code von Peter Fleury richtig verstehe, dann hängt twimaster.c, wenn kein I2C Device angeschlossen ist und man versucht, Daten zu lesen. Kann das jemand, der einen von Fleury unterstützten Prozessor hat, testen und bestätigen? Wäre für mich sehr hilfreich.
Dieter R. schrieb: > Die Chips scheinen etwas mit der heißen Nadel bzw. Maske gestrickt zu > sein. Was manche Leute hier immer rumjammern müssen. Die Teile funktionieren super und von den Erratas gibts bei anderen Marken viel längere. >Genau deshalb suche ich Code, der schon einen möglichst breiten > Realitätstest bestanden hat. Scheint aber schwierig... Schwierig bei Chips die noch nicht lang am Markt sind! Meinst Du nicht auch? Hoffentlich lässt Du uns an den bald zu erwartenden profunden Erkenntnissen teilhaben!
Nach dem voranstehenden Müll nochmals meine Bitte an ernsthafte Forumsmitglieder: Nachfrage zum Timeout. Wenn ich den Code von Peter Fleury richtig verstehe, dann hängt twimaster.c, wenn kein I2C Device angeschlossen ist und man versucht, Daten zu lesen. Kann das jemand, der einen von Fleury unterstützten Prozessor hat, testen und bestätigen? Wäre für mich sehr hilfreich. Danke.
Dieter R. schrieb: > Wenn ich den Code von Peter Fleury richtig verstehe, dann hängt > twimaster.c, wenn kein I2C Device angeschlossen ist und man versucht, > Daten zu lesen. Nö, nicht, wenn man es richtig macht.
1 | void send_I2C(uint8_t isCommand) |
2 | {
|
3 | uint8_t ret; |
4 | ret = i2c_start(TIANMA_ADDRESS+I2C_WRITE); // set device address and write mode |
5 | if ( ret ) { |
6 | /* failed to issue start condition, possibly no device found */
|
7 | i2c_stop(); |
8 | theAck = 0; |
9 | }else { |
10 | /* issuing start condition ok, device accessible */
|
11 | if (isCommand) theData = 0x00 ; else theData = 0x40; |
12 | i2c_write(theData); // |
13 | i2c_write(theData2); // |
14 | i2c_stop(); // set stop conditon = release bus |
15 | theAck = 1; |
16 | }
|
17 | }
|
Ist 'ret' beim START Kommando also ungleich 0, ist das Device nicht vorhanden und man sollte gar nicht erst probieren, Daten zu schreiben. Gerade erst beim Ausklingeln eines unbekannten Pollin LCD erfolgreich ausprobiert - auf der Suche nach der I²C Adresse des lustigen Teiles. MC war ein Mega328.
:
Bearbeitet durch User
Matthias S. schrieb: > Dieter R. schrieb: >> Wenn ich den Code von Peter Fleury richtig verstehe, dann hängt >> twimaster.c, wenn kein I2C Device angeschlossen ist und man versucht, >> Daten zu lesen. > > Nö, nicht, wenn man es richtig macht. > > Ist 'ret' beim START Kommando also ungleich 0, ist das Device nicht > vorhanden und man sollte gar nicht erst probieren, Daten zu schreiben. > Da möchte ich aber vorsichtig widersprechen. Das Thema in der Praxis (nicht beim Quick-and-Dirty-Test, der mir ja reichen würde) ist nicht, dass das Device überhaupt nicht vorhanden ist, sondern dass es im ungünstigen Moment eine Bus-Störung gibt und das Device dann nicht mehr vorhanden ist (also beispielsweise zwischen Adressierung und Read). Auch dann sollte die Software nicht hängen, sondern einen geordneten Ausstieg mit Fehlermeldung produzieren. Soweit ich das sehe (daher ja meine Frage nach praktischem Test) ist der Code bei der Adressierung unkritisch, das Statusbit wird in jedem Fall gesetzt, da die Adresse immer geschrieben wird und die Antwort nur ACK bzw. NACK sein kann, auch wenn gar kein Device da ist. READ hängt dann aber im von mir beschriebenen Szenario.
:
Bearbeitet durch User
Dieter R. schrieb: > ist nicht, > dass das Device überhaupt nicht vorhanden ist So hattest du es aber geschrieben: Dieter R. schrieb: > wenn kein I2C Device angeschlossen ist und man versucht, > Daten zu lesen. Von Busstörungen war bisher nicht die Rede. Dafür gibt es von Philips eine Routine, die du aber mit Bitbanging implementieren solltest. Dazu clockt der Master SCL solange (max. 9 Bits), bis SDA wieder high wird. Genaueres gibts in den I²C Grundlagen von den Holländern in https://www.nxp.com/documents/user_manual/UM10204.pdf Hier speziell Abschnitt 3.1.16
:
Bearbeitet durch User
Matthias S. schrieb: > Von Busstörungen war bisher nicht die Rede. Dafür gibt es von Philips > eine Routine, die du aber mit Bitbanging implementieren solltest. Dazu > clockt der Master SCL solange (max. 9 Bits), bis SDA wieder high wird. > Genaueres gibts in den I²C Grundlagen von den Holländern in > https://www.nxp.com/documents/user_manual/UM10204.pdf > > Hier speziell Abschnitt 3.1.16 Danke für den Hinweis. Ich hatte eingangs mal etwas von "zuverlässig" geschrieben. Zur Zuverlässigkeit gehört nach meinem Dafürhalten, dass nach Übertragungsstörungen ein definiertes Verhalten vorliegt und ein neues Aufsetzen der Verbindung möglich ist. Mindestens ist mein Ziel, dass meine bzw. die von mir verwendete Software das schlussendlich leistet. Dazu jetzt noch mal meine Frage: Der Fleury-Code hängt unter der angegebenen Bedingung? Oder haben die "alten" Atmels da einen eingebauten Timeout-Mechanismus bzw. verstehe ich den Code falsch? Um den Bus frei zu clocken, muss man ja erst einmal aus einer hängenden Übertragung herauskommen. Und dazu weitere Fragen: Ich würde ungern mit Bitbanging in die vorhandene I2C-Engine hineinpfuschen. Reicht es, BUSSTATE auf IDLE zu setzen und so lange neu zu adressieren, bis sich der Slave wieder meldet? Ich sehe jetzt nicht, was dabei anderes passiert als 9 x irgendwas zu clocken. Gibt es dazu Literatur oder Sources? In meiner aktuellen (unfertigen und nicht ausgetesteten) Version mache ich das so, aber bloß in der einfachen Annahme, dass viel Adressieren viel hilft. Wie kann man so etwas testen?
Ein guter Rat: Wenn Du wirklich was zuverlässiges haben willst, lass die Finger von dem I2C Dreck. Lies dir mal die App von Analog Devices durch, wie groß muß da die Verzweifelung gewesen sein wenn man seinen Kunden zu solch einem Murks rät. https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf
Dieter R. schrieb: > Matthias S. schrieb: > > Und dazu weitere Fragen: Ich würde ungern mit Bitbanging in die > vorhandene I2C-Engine hineinpfuschen. Reicht es, BUSSTATE auf IDLE zu > setzen und so lange neu zu adressieren, bis sich der Slave wieder > meldet? Ich sehe jetzt nicht, was dabei anderes passiert als 9 x > irgendwas zu clocken. Gibt es dazu Literatur oder Sources? In meiner > aktuellen (unfertigen und nicht ausgetesteten) Version mache ich das so, > aber bloß in der einfachen Annahme, dass viel Adressieren viel hilft. > Wie kann man so etwas testen? Es gibt beim I2C "deadlocks" die sich auch mit 9 mal schieben nicht auflösen lassen. Da hilft nur den "Stecker" zu ziehen und zu hoffen das es beim nächsten Versuch besser geht.
@EdgarS und weitere: der Thread hat eine gewisse Tendenz, vom Thema abzuweichen. Ich wäre sehr dankbar, wenn sich zukünftige Antworten auf das eigentliche Thema beschränken könnten. Zur Erinnerung, das ist I2C mit ATtiny 0/1 Series. Dabei möchte ich nämlich vorankommen, und da ich sicher nicht der einzige bin, der mit diesem Prozessor arbeitet, hilft es vielleicht auch ein paar anderen. Danke.
Dieter R. schrieb: > ungünstigen Moment eine Bus-Störung gibt und das Device dann nicht mehr > vorhanden ist (also beispielsweise zwischen Adressierung und Read). Auch > dann sollte die Software nicht hängen So schwierig es ist, diesen Fall nach erfolgreicher Adress-Bestätigung durch den Slave nachzustellen so selten dürfte der Fall auch in der Praxis auftreten. Aber nochmal: Das würde mit gesetztem WIF Bit und in MSTATUS angezeigt, der Bus geht auf BUSY und man kann drauf reagieren. Da hängt nichts in dem Sinne dass es nicht in Software zu behandeln wäre. > da die Adresse immer geschrieben wird und die Antwort nur ACK > bzw. NACK sein kann, auch wenn gar kein Device da ist. Wenn das Device nicht da ist kann kein ACK kommen. > Reicht es, BUSSTATE auf IDLE zu > setzen und so lange neu zu adressieren, bis sich der Slave wieder > meldet? Wenn es nicht ausdrücklich auf Performance ankommt wär mein Vorschlag, das TWI dazu kurz außer Betrieb zu nehmen und neu zu starten. Wenn sich dann der Slave nicht melden würde hättest Du definitiv ein grundsätzliches Problem. Aber es ist mit der fehlenden ACK Bestätigung nach der Adressierung zumindest klar ersichtlich.
Edgar S. schrieb: > Es gibt beim I2C "deadlocks" die sich auch mit 9 mal schieben nicht > auflösen lassen. Da hilft nur den "Stecker" zu ziehen und zu hoffen > das es beim nächsten Versuch besser geht. Extrem selten aber, ACK, selbst erlebt. Ein I2C Sensor hatte sich in einer Weise aufgehängt dass nichts anderes mehr half. Immerhin hat der TO seine Devices hier komplett selber in der Hand da er ja nur zwei Controller verbinden möchte.
Ich hatte in einem Gerät Multimaster-I2C mit Philips P80C652 aufgebaut. Das lief auf Anhieb und super stabil. Timeout war nicht nötig. Dann habe ich es auf den Flash-MC P89C668 geändert, weiterhin alles in Butter. Dann hat aber NXP nach der Phillips Übernahme das ganze 8051-Zeugs fallen gelassen, wie eine heiße Kartoffel. Ich hab dann auf Atmel 80C51 und AVR gewechselt und es lief gar nichts mehr. Ich mußte dann mit Pin-Change-Interrupt und Timeout prüfen, ob sich der Bus aufgehängt hatte und ihn ständig resetten, typisch so alle 10s. Ich hab auch den Nachbau des P89C668 von TEKMOS (TK89C668) probiert, aber dessen I2C ist auch Schrott. Ich hab daher den Verdacht, daß nur Phillips als I2C-Erfinder den I2C-Bus richtig verstanden und fehlerfrei implementiert hat.
Vorbemerkung: ich beziehe mich in meinen Äußerungen auf Fleury, da ich sinnvoller- und einfacherweise in einem C-Projekt nur C-Software einsetzen möchte. GermanFranz schrieb: >> da die Adresse immer geschrieben wird und die Antwort nur ACK >> bzw. NACK sein kann, auch wenn gar kein Device da ist. > > Wenn das Device nicht da ist kann kein ACK kommen. Klar doch. Mein Satz bezog sich darauf, dass die while-Schleife immer terminiert, egal ob ACK oder NACK kommt, also auch dann, wenn kein Device da ist. Beim READ ist das aber nicht so. > >> Reicht es, BUSSTATE auf IDLE zu >> setzen und so lange neu zu adressieren, bis sich der Slave wieder >> meldet? > > Wenn es nicht ausdrücklich auf Performance ankommt wär mein Vorschlag, > das TWI dazu kurz außer Betrieb zu nehmen und neu zu starten. Wenn sich > dann der Slave nicht melden würde hättest Du definitiv ein > grundsätzliches Problem. Aber es ist mit der fehlenden ACK Bestätigung > nach der Adressierung zumindest klar ersichtlich. Ich habe jetzt folgende Idee, für die mir im Moment das Test-Szenario fehlt, die aber nach meinem Verständnis genau das tut, was Philips/NXP empfiehlt: void I2C_recover(void) // clock out I2C bus if in invalid state (e.g. after incomplete transaction) { TWI0.MSTATUS |= TWI_BUSSTATE_IDLE_gc; // force bus idle I2C_start(0xff); // send byte, all bits high I2C_stop(); } Die State Machine wird auf Idle gesetzt, dann wird FF adressiert (was natürlich erfolglos bleibt) und die Transaktion beendet. Kommentare dazu erbeten.
Peter D. schrieb: > Ich hab daher den Verdacht, daß nur Phillips als I2C-Erfinder den > I2C-Bus richtig verstanden und fehlerfrei implementiert hat. Wer wollte das bis ins letzte Detail nachprüfen. Fakt ist aber, daß mehr als genug I2C Programme auch mit AVR zuverlässig und stabil im Einsatz sind. Das gilt für meine aktuell seit Wochen durchlaufende Kombination von M4808 und einem HYT271 genauso. Dennoch: Elektronik kann sensibel sein und ausfallen. Warum sollte das bei I2C/TWI anders sein. Da hilft dann die zuverlässigste Software nicht mehr...
Dieter R. schrieb: > I2C_start(0xff); // send byte, all bits high > I2C_stop(); Diese Sequenz ist illegal und führt lt. Doku zu einem Busfehler. Das wäre mein Kommentar.
GermanFranz schrieb: > Dieter R. schrieb: >> I2C_start(0xff); // send byte, all bits high >> I2C_stop(); > > Diese Sequenz ist illegal und führt lt. Doku zu einem Busfehler. Das > wäre mein Kommentar. Was an der Sequenz ist illegal? Genau das empfiehlt (nach meinem Verständnis) die Application Note von AMD (siehe EdgarS): https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf und auch bei NXP sehe ich jetzt nicht, was dagegen spricht. Zitat AMD: 1) Master tries to assert a Logic 1 on the SDA line 2) Master still sees a Logic 0 and then generates a clock pulse on SCL (1-0-1 transition) 3) Master examines SDA. If SDA = 0, go to Step 2; if SDA = 1, go to Step 4 4) Generate a STOP condition Schritt 2/3 kann man (siehe NXP) einfach 9x durchlaufen lassen. Das sollte mein Code-Vorschlag tun (wenn ich mich nicht irre).
Naja wir sind hier nicht bei NXP oder AMD. Schau mal in die Erklärung des BUSERR Bits im Datenblatt!
Ach so, moment mal. Passt schon. Hatte gerade nur Start/Stop Bit Senden wahrgenommen. Sorry. Bin nicht so der C-Freak.
GermanFranz schrieb: > Naja wir sind hier nicht bei NXP oder AMD. Schau mal in die Erklärung > des BUSERR Bits im Datenblatt! Hmm, ob BUSERR gesetzt ist, sollte egal sein, aber ich glaube, es geht wirklich nicht, das scheint mir das entscheidende Problem zu sein (falls der Slave SDA low hält): "and the SCL line is released" Der clockt gar nicht. Jetzt fehlt mir erst mal eine gute Idee. 9 x die ganze Prozedur? Einfach ein FF-Datenbyte senden? Adresse 00 senden?
:
Bearbeitet durch User
Dieter R. schrieb: > Wenn ich den Code von Peter Fleury richtig verstehe, dann hängt > twimaster.c, wenn kein I2C Device angeschlossen ist und man versucht, > Daten zu lesen. > > Kann das jemand, der einen von Fleury unterstützten Prozessor hat, > testen und bestätigen? Wäre für mich sehr hilfreich. Danke. Der Fleury-Code enthält keinerlei Timeouts oder irgendwelche Recoveries aus Fehlerzuständen. Das ist lediglich eine straight-forward-Implementierung der I2C-Grundfunktionen. Oliver
Oliver S. schrieb: > Dieter R. schrieb: >> Wenn ich den Code von Peter Fleury richtig verstehe, dann hängt >> twimaster.c, wenn kein I2C Device angeschlossen ist und man versucht, >> Daten zu lesen. >> >> Kann das jemand, der einen von Fleury unterstützten Prozessor hat, >> testen und bestätigen? Wäre für mich sehr hilfreich. Danke. > > Der Fleury-Code enthält keinerlei Timeouts oder irgendwelche Recoveries > aus Fehlerzuständen. Das ist lediglich eine > straight-forward-Implementierung der I2C-Grundfunktionen. > > Oliver Danke, wie vermutet. Ich bin etwas erstaunt, das ein (offenbar/angeblich) weit verbreiteter Code wie der von Fleury solche Dinge nicht berücksichtigt. Den Timeout habe ich inzwischen drin, vorsichtshalber in allen while-Loops. Jetzt fehlt mir eigentlich nur noch eine gute Idee für Recovery aus illegalem Bus-Zustand, siehe direkt darüber. Im Moment bin ich da etwas ratlos.
Ich habe jetzt etwas interessantes gefunden, direkt vom Erfinder bzw. dessen Nachfahren: https://www.nxp.com/docs/en/application-note/AN4803.pdf Das ist offenbar für NXP-Prozessoren mit eingebautem I2C-Hardware-Interface. Auf S. 18 wird die Recovery-Routine beschrieben, 9 x clocken, alles zu Fuß. Wenn schon NXP das so macht, dann bleibt einem bei ATtiny wohl auch nichts anderes übrig. Es sei denn, es hat jemand doch noch eine bessere Idee...
Dieter R. schrieb: > Ich bin etwas erstaunt, das ein > (offenbar/angeblich) weit verbreiteter Code wie der von Fleury solche > Dinge nicht berücksichtigt. Vielleicht, weil sie gar nicht so praxisrelevant sind wie Du meinst? > noch eine gute Idee für Recovery aus illegalem Bus-Zustand, siehe direkt > darüber. Im Moment bin ich da etwas ratlos. Was hindert Dich an einem simplen Reset beider TWI Interfaces? Geht es nicht nach wie vor um die Verbindung zweier Tinys? > Auf S. 18 wird die Recovery-Routine beschrieben, 9 x clocken, alles zu > Fuß. Was macht Dich sicher, daß diese mit TWI samt aller daran angeschlossenen I2C Devices kompatibel wäre? Es schaut so aus als suchtest Du die perfekte, alle Problemfälle erschlagende Lösung. Daran dürfte man sich verheben, schon gar nicht kann man alle denkbaren Problemfälle durchtesten. Ich denke Du solltest pragmatischer an die Sache herangehen und Deine Master-Slave Kommunikation erstmal in der Low-Speed Grundfunktionalität auf die Beine stellen. Möglicherweise kommst Du dann zum Schluss, dass alle Bemühungen um irgendwelche weitergehenden komplexen Fehlerszenarien vergebliche Liebesmüh war :)
GermanFranz schrieb: > Dieter R. schrieb: >> Ich bin etwas erstaunt, das ein >> (offenbar/angeblich) weit verbreiteter Code wie der von Fleury solche >> Dinge nicht berücksichtigt. > > Vielleicht, weil sie gar nicht so praxisrelevant sind wie Du meinst? > Och, ich hatte mal das Vergnügen, mit der Entwicklung von Bareboard-Testern befasst zu sein, wobei die Messelektronik über USB angebunden war und im Testsystem Impulsströme auftreten konnten. Wenn's geknallt hat, war gelegentlich das USB-Device weg. Wir haben das Problem dann letztlich gelöst, aber es hat mehrere Entwickler viele Tage und lange Versuche gekostet. USB ist zweifellos etwas prekärer als I2C, wenn es um die Fehlerbehandlung geht. Jedenfalls weiß ich seitdem, wie wichtig Fehlerbehandlung ist. Man sollte jedenfalls alle Fehlerzustände behandeln, die bekannt und dokumentiert sind, siehe NXP. Die unbekannten können dann immer noch dazu kommen. >> Auf S. 18 wird die Recovery-Routine beschrieben, 9 x clocken, alles zu >> Fuß. > > Was macht Dich sicher, daß diese mit TWI samt aller daran > angeschlossenen I2C Devices kompatibel wäre? Die Protokolldefinition verbunden mit der Tatsache, dass es die offizielle Lösung von Philips/NXP ist.
:
Bearbeitet durch User
Dieter R. schrieb: > Die Protokolldefinition verbunden mit der Tatsache, dass es die > offizielle Lösung von Philips/NXP ist. Das Problem ist nur (Zitat von de.i2c.org): > Clock Stretching > Busteilnehmer können die Taktleitung während der Low-Phase gegen Masse > halten und so ein erneutes Steigen der Flanke verhindern. Hierdurch kann > die Übertragung aktiv verzögert werden. Dieses Verhalten wird als Clock > Stretching bzw. Clock Synchronisation bezeichnet. > Bemerkenswert ist, daß die I2C-Spezifikation keine Maximalzeiten für das > Stretching vorsieht, so daß diese Verzögerung beliebig lange andauern > darf. Sprich: es kann KEINE endgültige Lösung für das Problem geben. Und auch diese sog. "offizielle" Lösung löst das Problem nicht, denn du kannst keine Takte ausgeben, wenn ein abgeschmierter Client (wegen aktiven Clock-Stretchings) dauerhaft SCL auf Low hält (übrigens auch keine stop condition). Trotz dieser unbestreitbaren Tatsachen laufen aber milliardenfach I2C-Busse ohne das geringste Problem. Das allein sagt schon aus, wie gering die Signifikanz des Problems tatsächlich ist. Wenn der Bus elektrisch korrekt ausgeführt und die Software fehlerfrei ist, hängt da niemals etwas. Und wenn das nicht der Fall ist, hat halt der Bus korrekt designed zu werden und die Bugs der Peers haben gefixed zu werden und nicht irgendwelche schrägen Workarounds implementiert zu werden, seien sie auch noch so "offiziell"... Und wenn halt die Hardware irgendeines Device ein Erratum hat, für das kein wirksamer Workaround in der Firmware des Device möglich ist, dann darf man diese Hardware halt nicht benutzen und muss dann halt notfalls auf Bitbanging ausweichen, wenn I2c und der Einsatz dieses Device unumgänglich sind. So einfach ist das.
c-hater schrieb: > hängt da niemals etwas Full ACK. Ich habe hier einige Geräte inkl. einem Frequenzzähler von Philips, der ausschliesslich über I²C kommuniziert und der immer zuverlässig funktioniert. Man muss eben auch mal die Kirche im Dorf lassen. I²C bzw. TWI (so nennen das die Firmen, die sich Lizenzgebühren sparen wollen) ist kein universelles, weitreichendes Bussystem mit doppeltem Boden, sondern ein einfacher Bus zur Kommunikation auf einem Board zwischen ein paar ICs. Er ist nicht störungsgesichert und er verlässt sich auf richtiges Handling durch alle Beteiligten. Die Implementationen unterscheiden sich und ich habe z.B. sowohl mit der Soft- als auch der Hardware Variante von Peter Fleury gute Erfahrungen und stabile Systeme gebaut - die sich auch in Konsumerhänden befinden und jedesmal gut laufen.
c-hater schrieb: > Wenn der Bus elektrisch korrekt ausgeführt und die Software fehlerfrei > ist, hängt da niemals etwas. Falsch Lies die AMD-Applikation, dann weißt du, wie dieser Zustand eintreten kann. Bei ansonsten korrekt funktionierenden Devices, die unabhängig voneinander arbeiten. Das weiß nicht nur AMD, das weiß auch Philips, deshalb haben sie ja das Recovery "erfunden" und dokumentiert.
Dieter R. schrieb: > Lies die AMD-Applikation, dann weißt du, wie dieser Zustand eintreten > kann Also, was ich jetzt gelesen hab, tritt das Problem bei fehlerhaften IRQ-Routinen auf, die nicht alles gesichert haben. Ich wuerde mal sagen, Workarounds fuer solche IRQ-Routinen sind sinnlos, da potentiell ausufernd. Kannst du das Problem genauer schildern? Danke, leo
Dieter R. schrieb: > c-hater schrieb: > >> Wenn der Bus elektrisch korrekt ausgeführt und die Software fehlerfrei >> ist, hängt da niemals etwas. > > *Falsch* > > Lies die AMD-Applikation, dann weißt du, wie dieser Zustand eintreten > kann. Zeig' mir den entsprechenden Text. Wenn es ihn tatsächlich gibt, sollte das kein Problem sein...
leo schrieb: > Dieter R. schrieb: >> Lies die AMD-Applikation, dann weißt du, wie dieser Zustand eintreten >> kann > > Also, was ich jetzt gelesen hab, tritt das Problem bei *fehlerhaften* > IRQ-Routinen auf, die nicht alles gesichert haben. > Ich wuerde mal sagen, Workarounds fuer solche IRQ-Routinen sind sinnlos, > da potentiell ausufernd. > > Kannst du das Problem genauer schildern? > > Danke, leo Ja, gerne: Frequently the master, which is usually a microcontroller or a gate array, will be interrupted in the middle of its communication with an I2C slave and, upon return, find a stuck bus. Initially this looks like a device problem, but it is not. The slave is still waiting to send the remainder of the data requested by the master. The problem is that the master has forgotten where it was when it was interrupted or reset. An extraneous reset on the processor will generally create this condition, especially if the processor cannot save its status. At this point, the slave will have put the next bit out on the SDA line (because the SCL line may have dropped to a low on reset) and awaits the next clock on SCL. Of course the processor does not send it, and as a result this slave just waits and waits. Der entscheidende Satz ist: An extraneous reset on the processor will generally create this condition, especially if the processor cannot save its status. Nehmen wir an, durch einen Störimpuls (oder auch, soll ja vorkommen, ein selten auftretender Software-Fehler) hat der Watchdog beim Master zugeschlagen oder der Master wurde aus einem anderen Grund (Brownout) resettet, der Slave aber nicht. Dann haben wir die beschriebene Situation. Dann hilft nur Stecker ziehen oder eben rausclocken. Jedenfalls ist das mein Verständnis.
Dieter R. schrieb: > The problem is that the > master has forgotten where it was when it was interrupted Hab ich gelesen, danke. Kaputte IRQs (oder Hardware) an einer Stelle (I2C) fixen zu wollen ist sinnlos. Was macht derweil andere Hardware, die ev. auch betroffen ist und fuer die es keinen "Fix" gibt? Die zaeumen das Pferd von hinten auf. leo
Dieter R. schrieb: > Frequently the master, which is usually a microcontroller or a gate > array, will be interrupted in the middle of its communication with an > I2C slave and, upon return, find a stuck bus. Ah, OK. Was also soll einen Master "mitten in" seiner Kommunikation unterbrechen? > Initially this looks like > a device problem, but it is not. The slave is still waiting to send the > remainder of the data requested by the master. The problem is that the > master has forgotten where it was when it was interrupted or reset. Alles klar: Der Master ist beschissen programmiert oder wurde resetted. Gegen die beschissene Programmierung hilft eine korrekte Programmierung und gegen die Auswirkungen eines alleinigen Reset des Masters (auch der kann eigentlich nur aus inkorrekter Programmierung stammen, z.B. aus dem Einsatz eines Watchdog zum Vertuschen von Programmfehlern) hilft nur ein nachfolgender Reset aller Busteilnehmer, sprich: ein "power cycle". So einfach ist das. Problem->Lösung. Man muss einfach nur korrekte Programme schreiben.
c-hater schrieb: > Gegen die beschissene Programmierung ... Die wortgewaltige Ausdrucksweise des Posters unterstützt wohl meine Argumentation ;-) leo
c-hater schrieb: > So einfach ist das. Problem->Lösung. Man muss einfach nur korrekte > Programme schreiben. (Vergessen:) wichtige Ergänzung: I2C ist so einfach gestrickt, dass es möglich ist, BEWEISBAR fehlerfreie Implementierungen zu schreiben...
leo schrieb: > Die wortgewaltige Ausdrucksweise des Posters unterstützt wohl meine > Argumentation ;-) Das sagst du, aber frag' mal IRGENDEINEN, der seit Jahrzehnten mit Software sein Geld verdient...
c-hater schrieb: > leo schrieb: > >> Die wortgewaltige Ausdrucksweise des Posters unterstützt wohl meine >> Argumentation ;-) > > Das sagst du, aber frag' mal IRGENDEINEN, der seit Jahrzehnten mit > Software sein Geld verdient... Hab ich - und wenn ich mit kaputter Umgebung arbeiten musste, dann fixte ich zuerst die Umgebung. leo
Leute, regt euch ab. Auch mit beweisbar (haha) fehlerfreier Software kann man keinen Brownout verhindern. Watchdogs wurden übrigens u. a. deshalb erfunden, weil das mit der Beweisbarkeit so seine Sache ist. Deshalb muss ein zuverlässiges System so etwas eben abfangen. Ich bemühe mich, daran zu arbeiten. Dauert aber noch ein bisschen. Falls zwischenzeitlich noch jemand Ideen oder Tips zur Sache beisteuern möchte, gerne.
Dieter R. schrieb: > Leute, regt euch ab. Auch mit beweisbar (haha) fehlerfreier Software > kann man keinen Brownout verhindern. Nö, dafür gibt es brownout detectors. Und übrigens ist es absolut nicht lächerlich, Protokolle, die sich einfach beweisbar fehlerfrei umsetzen lassen auch tatsächlich so zu implementieren... > Watchdogs wurden übrigens u. a. > deshalb erfunden, weil das mit der Beweisbarkeit so seine Sache ist. Ja. Es gibt viele Sachen, deren Komplexität so hoch ist, dass sich deren Fehlerfreiheit nicht in akzeptabler Zeit beweisen läßt. Eine I2C-Implementierung gehört aber zum Glück nicht zu dieser Klasse von Problemen. > Deshalb muss ein zuverlässiges System so etwas eben abfangen. Dann setze doch einfach auf einen Watchdog. In allen Devices am Bus. Merkst du jetzt, wie vollständig idiotisch dein Ansatz ist?
c-hater schrieb: > Dann setze doch einfach auf einen Watchdog. In allen Devices am Bus. > Merkst du jetzt, wie vollständig idiotisch dein Ansatz ist? Idiotisch ist ein starkes Wort. Ich bemühe mich, solch starke Worte zu vermeiden. Du dagegen scheinst es nicht begreifen zu wollen. Der Ansatz ist nicht von mir, sondern von Philips, und AMD hat ihn zitiert. Ich bemühe mich nur, das, was dort steht, in einer sauberen Implementierung umzusetzen, weil ich nach Durchlesen zu der Überzeugung gekommen bin, dass es relevant ist. Man kann natürlich der Meinung sein, dass Applikationsschriften von NXP zur I2C-Fehlerbehandlung irrelevant sind, aber dann sollte man schon bessere Argumente haben als "idiotisch". Übrigens gibt es weder (um mal wieder ein Beispiel zu nennen) I2C-I/O-Expander mit Watchdog noch ist das hier überhaupt das Thema, was dem Slave helfen würde. Das Thema ist, ach, lassen wir das ...
Dieter R. schrieb: > Man kann natürlich der Meinung sein, dass > Applikationsschriften von NXP zur I2C-Fehlerbehandlung irrelevant sind, > aber dann sollte man schon bessere Argumente haben als "idiotisch". Das habe ich im Thread bereits getan. Um 17:32.
c-hater schrieb: > Dieter R. schrieb: > >> Man kann natürlich der Meinung sein, dass >> Applikationsschriften von NXP zur I2C-Fehlerbehandlung irrelevant sind, >> aber dann sollte man schon bessere Argumente haben als "idiotisch". > > Das habe ich im Thread bereits getan. Um 17:32. Tja, Matus Plachy hat halt keine Ahnung. Er hat zwar mindestens ein Dutzend Applikationsschriften verfasst und tritt als Redner auf IoT-Konferenzen auf, aber du weißt es sicher besser. Klar, auch er kann irren. Ich halte mich aber zumindest derzeit lieber an seine Ratschläge. Auch wenn die Implementierung dadurch etwas aufwendiger wird.
Dieter R. schrieb: > Ich halte mich aber zumindest derzeit lieber > an seine Ratschläge. Auch wenn die Implementierung dadurch etwas > aufwendiger wird. Denn mach. Wenn du sowieso machst, was du willst, warum fragst du dann hier? Das ergibt doch keinen Sinn.
Autor: Dieter R. (drei) Datum: 07.05.2019 19:07 Ist gut. Trink deinen Kakao, oder falls du schon älter bist, ein gutes Glas Rotwein.
Der Ansatz ist aber trotzdem fraglich. Ich kann jedes Protokoll zum Absturz bringen, wenn ich schlechte Software dafür implementiere. Und das ist z.B. die Fleury Lib sicher nicht. Ich kann z.B. ISRs während der Routinen aufrufen, ohne das irgendwas abschmiert, wenn ich mir nur ein wenig Gedanken über den Ablauf mache und keine ISR einsetze, die den MC endlos blockiert. Wenn du aber Bedenken hast, dann nimm doch was anderes. Kein Mensch zwingt dich zur Benutzung von I²C oder TWI.
Dieter R. schrieb: > Deshalb muss ein zuverlässiges System so etwas eben abfangen. Zu einem solchen gehört immer Software, Protokoll und Hardware. Leider ist nichts davon perfekt. Dieter R. schrieb: > 1. Nach weiteren Tests und tieferem Einstieg in das Datenblatt: > der oben von mir zitierte Code (von beiden Verfassern) aus dem > avrfreaks-Forum scheint mir fraglich zu sein. Ich neige inzwischen der > Meinung zu, dass es unverstandenes Zeug ist und der Prozessor falsch > bedient wird. Weiteres aber später... Ich bin gespannt welche Belege Du für diese Behauptung vorbringen wirst. Bis dahin würde ich es mal mit einer Grundregel aus der Medizin halten: Wer heilt hat recht.
Matthias S. schrieb: > Der Ansatz ist aber trotzdem fraglich. Ich kann jedes Protokoll > zum Absturz bringen, wenn ich schlechte Software dafür implementiere. Im Grunde setzt der TO hier die falschen Prioritäten. Anstatt sein System ingesamt sicher gegen Spannungseinbrüche oder entgleisendes Interrupt Design zu machen glaubt er, mit so aufwendig wie zweifelhaft abgesichertem I2C Treiber seine Controller-Welt ins Paradies perfekter Zuverlässigkeit führen zu können. Dabei wären mit einem ordentlichem System-Design in einem Abwasch sowohl I2C Fehler ausgeschlossen wie auch die sichere Funktion aller übrigen Teile in maximal möglicher Weise sichergestellt.
GermanFranz schrieb: > Matthias S. schrieb: >> Der Ansatz ist aber trotzdem fraglich. Ich kann jedes Protokoll >> zum Absturz bringen, wenn ich schlechte Software dafür implementiere. > > Im Grunde setzt der TO hier die falschen Prioritäten. Lieber GermanFranz, ich habe deine fachlichen Anregungen gerne aufgenommen, aber die Diskussion hier ist mittlerweile ins Absurde abgeglitten. Mein Ziel ist simpel, die Vorgaben von Philips/NXP (und AMD) in deren Applikationsschriften in ein Softwaredesign umzusetzen, das für mich (und vielleicht auch andere) überschaubarer ist als der Originalcode, den Atmel Start generiert. Dieses Ziel ist einzig daran ausgerichtet, robusten Code zu generieren und völlig frei von Erwägungen, ob die Hardware, auf welcher der Code läuft, irgendwelche funktionalen Mängel hat. Bei meinem konkreten Projekt kann ich bisher solche funktionalen Mängel mit hoher Wahrscheinlichkeit ausschließen. Sollten sie sich doch zeigen, werden sie behoben. Da es sich um ein Projekt handelt, wo der Controller jahrelang (ggf. jahrzehntelang) unbeaufsichtigt durchlaufen soll, sind fehlertolerante Schnittstellentreiber eine Grundvoraussetzung. Ich war einige Jahre mit dem System- und Hardware-Design von Linux-basierten Systemen im 24/7-Einsatz befasst, mir sind die Anforderungen bewusst. Ich habe (weiß nicht mehr genau, wann, ca. Ende der 80er) I2C-Treiber in Assembler für damals brandneue digitale Video-Decoder von Philips geschrieben. Ich vermute stark, dass meine damalige Software nicht fehlertolerant war, aber die Geräte hatten auch einen Ausschalter. Kundenbeschwerden hat es übrigens nicht gegeben, unser Produkt galt als qualitative Spitze. Ist lange her, heute sind die Ansprüche höher. Sobald ich ein vorzeigbares Resultat habe, werde ich mich bemühen, dieses vorzustellen - aber sicher nicht in diesem Forum. Die mehr (oder leider zunehmend weniger) fachliche Seite der Diskussion in diesem Forum möchte ich hiermit abschließen. Wenn jemand einen Vorschlag hat, in welchem Forum man sich mit Gewinn für alle Beteiligten fachlich weiter austauschen kann, bin ich für eine persönliche Mitteilung dankbar. Nach den aktuellen Erfahrungen wird es wohl kein deutschsprachiges Forum sein. @Autor: Rolf (Gast): missverstandenes Handling von RIF und WIF, u. a. in TWI_Start. Soweit läuft es bei mir jetzt richtig. Der Slave ist noch unvollständig, das Recovery-Clocking noch nicht drin, und vor allem fehlt der Härtetest mit realen I2C-ICs.
:
Bearbeitet durch User
Matthias S. schrieb: > Wenn du aber Bedenken hast, dann nimm doch was anderes. Kein Mensch > zwingt dich zur Benutzung von I²C oder TWI. Genau, schau hier: Frage, wieviel TWI-Devices? Bei nur einem Device geht es auch zur Not so: Und kann in ein bereits vorhandenes Programm reingesetzt werden, das jede Menge Interrupts und noch Warteschleifen, dann sogar noch 8N1 9k6 UART Ausgabe hat. Idee war, wie man LCDs gegen LCDs einfach austauscht. Eins hat den üblichen Port-Standard. Ein anderes nur die I2C-Portbelegung. https://www.avrfreaks.net/forum/lcd-sainsmart2004-connecting-attiny2313-usi Beitrag "Re: Anfänger Will ATtiny2313 mit Display uber I2C verbinden" ciao gustav
@TE Du scheinst die Tatsache, dass Millionen I2C Apps auch ohne den von Dir angestrebten Sicherungsaufwand problemlos laufen (können) völlig zu ignorieren. Sie tun das weil Schaltungsaufbau und Software schlicht und einfach passen! Das bedeutet: I2C Fehler sind nur Symptome einer tieferliegenden Fehlkonzeption! Was Du in symptombekämpfender Kosmetik nur erreichst ist ein aufgeblähter Treiber mit unnötig viel Code, der noch dazu naturgemäß schwerer zu durchschauen und damit fehlerträchtiger ist. Geht es nicht viel mehr um den psychogischen Effekt, dass Du Dich persönlich mit dem angenommenen "Sicherheitsgewinn" wohler fühlst? Die 9er Clock-Routine zur "Lösung von I2C Blockaden" ist bei der angestrebten Verbindung zwei gleicher Controller übrigens völliger Nonsens.
Rolf schrieb: > Du scheinst die Tatsache, dass Millionen I2C Apps auch ohne den von Dir > angestrebten Sicherungsaufwand problemlos laufen (können) völlig zu > ignorieren. > Sie tun das weil Schaltungsaufbau und Software schlicht und einfach > passen! Leider sind Aufbau und Software nicht die einzigen Fehlerquellen, sondern auch die Implementation des I2C im MC kann buggy sein und daran kann man aber nichts ändern. Wie gesagt, die Multimasteranwendung mit bis zu 6 Modulen mit Philips-MCs (P80C652 bzw. P89C668) funktionierte ohne Timeout, d.h. der Bus hängte sich nicht auf. Probleme machte nur die verbugte I2C-Hardware der AVR und 8051 von Atmel. Die interne Statemaschine des I2C hängt sich auf und die kann der MC aber nicht auslesen. https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html Ich fand den Multimaster-Mode sehr elegant, weil man den Bus nicht mit unnötigen Polling-Zyklen belasten muß. Nach den schlechten Erfahrungen mit dem I2C der Atmels habe ich dann auf den CAN-Bus gewechselt.
Dieter R. schrieb: > Mein Ziel ist simpel, die Vorgaben von Philips/NXP (und AMD) in deren > Applikationsschriften in ein Softwaredesign umzusetzen, das für mich > (und vielleicht auch andere) überschaubarer ist als der Originalcode, > den Atmel Start generiert. Dieses Ziel ist einzig daran ausgerichtet, > robusten Code zu generieren und völlig frei von Erwägungen, ob die > Hardware, auf welcher der Code läuft, irgendwelche funktionalen Mängel > hat. Die technische Umsetzung des I2C Protokolls hat Microchip/Atmel ja schon für Dich vorgenommen. Du sollst/kannst/brauchst deren Hardware nur noch richtig ansteuern und die gebotenen Fehleranzeigen nutzen. Und mit "robustem" Code kannst Du doch nicht ernsthaft funktionale Mängel kaschieren wollen! Nein, letztere sind zu beheben. I2C Fehler können geradezu Sensor dafür sein- eine Funktion auf die Du offensichtlich gerne verzichtest. Man könnte dieses Zukleisternwollen offensichtlicher Mängel realistischerweise auch unsaubere Arbeit nennen! Peter D. schrieb: > Leider sind Aufbau und Software nicht die einzigen Fehlerquellen, > sondern auch die Implementation des I2C im MC kann buggy sein und daran > kann man aber nichts ändern. Und schon gar nicht mit "robustem" Code! Nachdem sich > https://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html > auf ältere AVRs bezieht kann man sich nur wünschen, daß sich da was mit den neuen Serien funktionell verbessert hat. Insofern man überhaupt solche komplexen Busse mit mehreren Mastern betreiben will.
GermanFranz schrieb: > > Die technische Umsetzung des I2C Protokolls hat Microchip/Atmel ja schon > für Dich vorgenommen. Wenn du deren Code gelesen hättest, würdest du das vielleicht zurückhaltender formulieren. Beispiel: void I2C_0_error_handler() { while (1) ; } Der funktionale Ablauf ist versteckt in ca. 3-fach verschachtelten Callbacks. Ich bin gerade dabei, das zu entwirren. Soweit der Slave. Der Master ist so unübersichtlich (zumindest für meine C-Kenntnisse), dass ich den Atmel-Code komplett weggeschmissen und alles neu gemacht habe, nur ein paar Register-Initialisierungen habe ich abgeguckt. Und selbst da scheint mir noch einiges fraglich. Aber ich arbeite dran, wird schon werden, dauert aber mindestens 10x so lange, wie ich erwartet hatte. Soweit zum Status. Ich möchte die Grundsatzdiskussion jetzt aber abschließen, die bringt keine neuen Erkenntnisse. Alle, die glauben, dass Error Recovery ein überflüssiges Thema ist, bitte ich nochmals, die zitierte AMD-Applikationsschrift durchzulesen, ggf. auch den ebenfalls zitierten Treiber von NXP und das dort geschilderte Szenario zu durchdenken und zu verstehen. Es hat überhaupt nichts mit unsauberem Systemaufbau zu tun oder mit schlecht geschriebener Software. Ihr wollt doch bitte nicht ernsthaft behaupten, dass da mehrere renommierte Leute Software-Krücken erfinden, bloß um von den Defiziten ihrer Schaltungsentwicklung abzulenken?!? Dass ihr das alle in der Praxis nie erlebt habt (ich übrigens auch nicht), hat den einfachen Grund darin, dass die Eintrittswahrscheinlichkeit gering ist. Sie ist aber nicht Null, und das muss in hochverfügbaren Systemen berücksichtigt werden. Falls noch ernsthafte technische Erörterungen kommen, bin ich dafür jederzeit offen - ebenso für alle Vorschläge, die zu einer Verschlankung der Atmel-Treiber führen.
Grundsätzlich Daumen hoch wenn sich einer hinsetzt und das zugegebenermaßen unschöne Atmel-Start Zeugs in eine brauchbare Form bringt. Es müsste nur nicht Dieter R. schrieb: > mindestens 10x so lange, wie ich erwartet hatte. oder noch länger dauern wenn Du Dich auf das beschränken würdest was wirklich vonnöten ist! > Es hat überhaupt nichts mit unsauberem > Systemaufbau zu tun oder mit schlecht geschriebener Software. Du scheinst den Hintergrund der I2C Fehler immer noch nicht zu begreifen. Systeme in denen es zu ungeplanten Neustarts kommt sind per se fehlkonstruiert! > Dass ihr das alle in der Praxis nie > erlebt habt (ich übrigens auch nicht), hat den einfachen Grund darin, > dass die Eintrittswahrscheinlichkeit gering ist. Sie ist aber nicht > Null, Irrtum. Sie ist sauber umgesetzt Null- oder eben gerade so hoch wie elektronische Systeme generell und nicht auf einzelne Teile begrenzt ausfallgefährdet sind. > Falls noch ernsthafte technische Erörterungen kommen, bin ich dafür > jederzeit offen - ebenso für alle Vorschläge, die zu einer Verschlankung > der Atmel-Treiber führen. Die kommen unentwegt, indem sie dazu auffordern, sich nicht in unnütz übertriebenem, eierlegenden Fehlerbehandlungs- Wollschwein Design zu verlieren. Kombiniert mit Dieter R. schrieb: > meinen (beschränkten) Kenntnisstand in C-Programmierung lässt das nichts Gutes erahnen und dürfte zu keinem brauchbar schlanken, übersichtlichen Treiber führen. Dein Horizont ist hier einfach zu sehr aufs I2C fachspezifische fixiert um zu realisieren, was ein zuverlässiges Gesamt- System wirklich ausmacht. Nur ein schlanker Treiber, der fehlerfrei das tut was wirklich zu tun ist kann dafür ein Gewinn sein. Viel Erfolg!
Rolf schrieb: > Systeme in denen es zu ungeplanten Neustarts kommt sind per > se fehlkonstruiert! Ich wollte ja eigentlich nichts mehr dazu sagen. Es ist offenbar (oder doch nur anscheinend? - man soll ja nie die Hoffnung aufgeben) chancenlos. Wie willst du denn in einem netzversorgten, aber ungepufferten System Brownouts vermeiden, wie willst du ohne ein zentrales Reset erreichen, dass die gesamte Peripherie darauf identisch reagiert? Das muss aber auch gar nicht sein, wenn es dafür ein funktionierendes Recovery gibt. Das muss man nur richtig handhaben! Philips/NXP weiß das, AMD auch, bloß Rolf (Gast) hat da anhaltende Verständnisprobleme. Hast du wirklich schon mal professionell mit 24/7-Systemen zu tun gehabt? Mit Systemen, die in störverseuchter Umgebung arbeiten (das muss gar nichts besonderes sein, da reicht ein PC-gesteuertes System im Großhotel, im Betriebsraum neben der Aufzugsmaschine)? Hast du in solchen Systemen schon mal (um von I2C wegzukommen und ein anderes Beispiel zu bringen) USB-Peripherie betrieben? Dann müsstest du dich eigentlich eine ganze Menge mit Error Recovery herumgeschlagen haben. Mit deinem Ansatz, das ist dann eben eine Fehlkonstruktion, kommst du da jedenfalls nicht weiter. Die originale Atmel-Treibersoftware erweist sich übrigens als um so kränker, je tiefer man einsteigt. Da gibt es doppelte Funktionen und sogar eine Funktion, die den Bus kurzschließt. Glücklicherweise wird sie im Beispielprogramm nicht aufgerufen. Alles hübsch geschrieben und sorgfältig kommentiert, aber es sieht sehr so aus, als hätte da jemand die Übersicht verloren.
Dieter R. schrieb: > Wie willst du denn in einem netzversorgten, aber > ungepufferten System Brownouts vermeiden, wie willst du ohne ein > zentrales Reset erreichen, dass die gesamte Peripherie darauf identisch > reagiert? Ja, man muß nur die richtigen Fragen stellen, dann kommt man auch zu richtigen Lösungen. Sprich: Es muß halt ein zentrales Reset-System realisiert werden... Und schon löst sich das Problem, für das der AMD/NXP-Workaround die (notwendigerweise sowieso unvollständige) Lösung sein soll, vollkommen in Luft auf... Kannst du das kapieren?
c-hater schrieb: > > Kannst du das kapieren? Nein, du Wichtigtuer. Könnte es sein, dass du zwar viel schwätzt, dich aber mit I2C-Peripherie nicht besonders gut auskennst? So etwas gibt es nämlich bei vielen oder vermutlich sogar bei den meisten I2C-Devices nicht (nicht einmal bei welchen, die für Medical Equipment qualifiziert sind) noch überhaupt bei USB (das Beispiel hast du wohl auch nicht verstanden). Aber du kannst dich ja mal als Halbleiterhersteller versuchen und selbst die entsprechenden ICs anbieten - falls du gerade ein paar Hundert Millionen übrig hast, darunter wirst du wohl keine Fertigung aufbauen können. Du solltest aber vorsichtig mit deinem Investment sein, der Halbleitermarkt schwächelt gerade. Und bei USB wird das echt schwierig, der Mechanismus ist nämlich im Protokoll nicht vorgesehen, du musst also erst einmal einen neuen Standard etablieren. Bei I2C ist das einfacher, da ist es im Standard vorgesehen. Das hat sich nur noch nicht überall herumgesprochen, besonder nicht bei den Wichtigtuern in diesem Forum.
Dieter R. schrieb: > Nein, du Wichtigtuer. Könnte es sein, dass du zwar viel schwätzt, dich > aber mit I2C-Peripherie nicht besonders gut auskennst? > So etwas gibt es > nämlich bei vielen oder vermutlich sogar bei den meisten I2C-Devices > nicht Doch, gibt es (zumindest implizit). Notfalls über eine geeignete Gestaltung der Versorgung. Wenn es keinen anderen Mechanismus gibt, mindestens PowerOn-Reset kann nämlich wirklich absolut jedes Device, ohne jede Ausnahme. Wenn du nichtmal diesen simplen Sachverhalt erkennen kannst, dann bist du definitiv nicht ermächtigt, mich einen Wichtigtuer zu nennen. Du kannst es aber ruhig weiter tun, wenn dir das Kraft gibt... ;o) Besser wäre allerdings, du würdest darüber nachdenken, was dir die Erwachsenen empfehlen.
Dieter R. schrieb: > Wie willst du denn in einem netzversorgten, aber > ungepufferten System Brownouts vermeiden > Hast du wirklich schon mal professionell mit 24/7-Systemen zu tun > gehabt? Hier ist doch nicht etwa vom selben System die Rede? > Hast du in > solchen Systemen schon mal (um von I2C wegzukommen und ein anderes > Beispiel zu bringen) USB-Peripherie betrieben? Bleiben wir doch mal schön bei I2C, USB ist was ganz anderes. > Die originale Atmel-Treibersoftware erweist sich übrigens als um so > kränker, je tiefer man einsteigt Und Du beurteilst das jetzt mit, nach eigener Aussage beschränkten C-Kenntnissen? > aber es sieht sehr so aus, als hätte da jemand > die Übersicht verloren ... denk ich mir manches Mal wenn ich Deine Kommentare so lese. Aber wollen wir es mal nicht zu hoch hängen. Es läuft ja doch immer auf die gleiche Weise: - bestehender Code wird schlecht gemacht - natürlich kann man alles viel besser und verspricht das Blaue vom Himmel - die Umsetzung dauert plötzlich länger und länger - naja, das Ende des Liedes wie üblich- nix ward mehr gehört vom Genius.
Lieber Rolf (Gast), melde dich als Forumsteilnehmer an, mach mir (per PM) einen Vorschlag, in welchem ernsthaften Forum wir uns über den Fortgang der Sache austauschen können, und dann sehen wir gerne weiter. Zur Qualität der Atmel-Treibersoftware (hier: für den Slave) hatte ich mich ja schon summarisch geäußert. Hier gerne die Details: void I2C_0_close(void) schließt den Bus kurz. Warum, könnte ich dir jetzt erklären, aber es wird dich vermutlich gar nicht interessieren. void I2C_0_open(void) und void I2C_0_enable(void) sind identisch, einer von beiden ist übeflüssig. Eigentlich sind aber beide überflüssig, weil der Bus schon bei der Initialisierung enabled wird und das Disable (close) wie erwähnt sowieso nicht funktioniert. Die dreifache Verschachtelungstiefe bei Funktionen, die nur aus einem einzigen Befehl bestehen (!), innerhalb einer Interruptroutine, halte ich auch nicht gerade für effektive Programmierung. Insbesondere, wenn dieser einzige Befehl im ganzen Programm sowieso nur ein einziges Mal aufgerufen wird. Resultat: 3 Druckseiten Original-Atmel-Code, zusammengestrichen auf die dahinter stehende Substanz, ergeben nicht mehr als eine knappe Seite. Es ist wirklich nicht kompliziert und kein Aufreger, nur völlig unübersichtlich und teilweise (siehe Fehlerbehandlung) unvollständig. Der Master-Code sind bei mir derzeit 149 Zeilen, mit Leerzeilen und ausführlichen Kommentaren. Bei Atmel war es ein (jedenfalls für mich) undurchdringliches Dickicht, was ein Vielfaches an Programmcode wie bei meiner jetzigen Version produziert hat. Funktionalität ist die Gleiche, d. h. bei beiden fehlt noch das Recovery. Kommt noch, bei mir. Und, ja, es ist von einem 24/7-System die Rede. Nicht mein erstes.
c-hater schrieb: > > Doch, gibt es (zumindest implizit). Notfalls über eine geeignete > Gestaltung der Versorgung. Wenn es keinen anderen Mechanismus gibt, > mindestens PowerOn-Reset kann nämlich wirklich absolut jedes Device, > ohne jede Ausnahme. > Power Cycling würde theoretisch immer das Problem lösen, ist aber nicht in jedem System möglich und oftmals weder erforderlich noch wünschenswert. Es gibt nämlich den anderen Mechanismus. Lies Abschnitt 3.1.16 (Bus clear) der offiziellen I2C-Spezifikation. Du wirst staunen. Letzte mir bekannte Ausgabe ist UM10204, I2C-bus specification and user manual, Rev. 6 — 4 April 2014. In der Version von 1995 (The I2C-bus and how to use it, including specifications, 1995 update) steht es interessanterweise noch nicht. Nach dieser doch sehr länglichen und kontrovers geführten Diskussion gewinne ich den Eindruck, dass das Wissen über dieses Thema in weiten Kreisen auf dem Stand von 1995 stehen geblieben ist.
Also ich hab den Eindruck, bislang hören wir hier nur Sprüche. Gehts nur mir so? Bemerkenswert wieviel Zeit man doch verbringen kann um sich über einen solchen Firlefanz zu echauffieren der für nahezu alle praktischen Fälle irrelevant und von dem alles andere als sicher ist, welche der zahlreichen I2C Hardware auf dem Markt das überhaupt unterstützt. Der Treiber könnte längst fertig sein, soviel Substanz ist nun wirklich nicht am neuen TWI Interface!
Dieter R. schrieb: > Die dreifache Verschachtelungstiefe bei Funktionen, die nur aus einem > einzigen Befehl bestehen (!), innerhalb einer Interruptroutine, halte > ich auch nicht gerade für effektive Programmierung. Hi, kann leider nicht mitreden, da ich nur gut auskommentierten ASM-Code bevorzuge. Da ist man IMHO auch wesentlich näher am Target und überlässt nicht irgendeinem Compiler die "Drecksarbeit". Die können ja auch einmal "falsch" liegen. ciao gustav
Rolf schrieb: > Der Treiber könnte längst fertig sein, soviel Substanz ist nun wirklich > nicht am neuen TWI Interface! Womit wir wieder am Anfang wären, Frage: kennt jemand eine bewährte Quelle für zuverlässige I2C-Routinen (Master und Slave) für diese Prozessoren? Gibt es jenseits der Microchip-Treiber so etwa wie eine Standardbibliothek dafür? Für Tips und Links wäre ich sehr dankbar. Ich will keine großartigen Sachen machen, nur kurze Messages, wenige Byte lang, zwischen beiden Prozessoren austauschen. Hast du denn eine Antwort auf diese Frage? Dann poste doch bitte einen Link auf entsprechenden C-Code.
Dieter R. schrieb: > Frage: kennt jemand eine bewährte Quelle für zuverlässige I2C-Routinen > (Master und Slave) für diese Prozessoren? Nein die gibt es nicht. Jedenfalls nicht für Dein Verständnis von Zuverlässigkeit. Ansonsten findest Du bei den AVRfreaks funktionierenden und kompakten Code. Vermutlich hast Du mit was Eigenem noch nicht mal angefangen. > Gibt es jenseits der > Microchip-Treiber so etwa wie eine Standardbibliothek dafür? Nein. Wie oft fragst Du noch? > Ich will keine großartigen Sachen > machen, nur kurze Messages, wenige Byte lang, zwischen beiden > Prozessoren austauschen. Dafür dieses Gezeter?
Rolf schrieb: > Dieter R. schrieb: >> Frage: kennt jemand eine bewährte Quelle für zuverlässige I2C-Routinen >> (Master und Slave) für diese Prozessoren? > > Vermutlich hast Du mit was Eigenem noch nicht mal angefangen. Der Satz spricht jetzt nicht unbedingt für deine Lesekompetenz. Ich hatte ja schon einige Details berichtet. Und über die Unzulänglichkeiten im Atmel-Code. Deren Slave funktioniert bei mir übrigens nicht, ich suche noch nach dem Fehler. > Ansonsten > findest Du bei den AVRfreaks funktionierenden und kompakten Code. Du weißt ja, ich bin dumm. Deshalb brauche ich etwas Hilfestellung von dir. Wo finde ich den Code für Series 1? Für Master und Slave?
Dieter R. schrieb: > suche noch nach dem Fehler. Nein. Du bist die ganze Zeit nur mit diesem Forum beschäftigt.
Dieter R. schrieb: > Zur Qualität der Atmel-Treibersoftware (hier: für den Slave) hatte ich > mich ja schon summarisch geäußert. es gibt mehrere Quellen im Netz das ein AVR Master kein Clockstretching vom Slave erkennt, sollen das alle Ahnungslose sein? Abhilfe ist wohl für viele am Clock Port SCL einen weiteren Port anzuklemmen der die Zeit für Clock low stoppt und einen I2C Reset durchführt. Ich bin aber nicht sicher ob jeder Slave darauf reagiert, deswegen wohl zusätzlich power on reset am Slave durchführen was noch eine Leitung bedeutet. Wer I2C selber soft implementiert kann das natürlich eleganter machen? jedenfalls alles ohne power on reset für den slave denn das hat mit dem I2C Protokoll ja nichts zu tun.
:
Bearbeitet durch User
Angehängte Dateien:
Joachim B. schrieb: > Dieter R. schrieb: >> Zur Qualität der Atmel-Treibersoftware (hier: für den Slave) hatte ich >> mich ja schon summarisch geäußert. > > es gibt mehrere Quellen im Netz das ein AVR Master kein Clockstretching > vom Slave erkennt, sollen das alle Ahnungslose sein? > Nach aktuellem Status (mit meinem Master und dem originalen Slave aus Atmel Start) kann ich bestätigen, dass der Slave bei Master Read Clock Stretching generiert und der Master darauf korrekt reagiert. Ich kriege aber noch keine validen Daten vom Slave übertragen und das ACK vom Master funktioniert nicht. Ersteres erscheint mir im Moment unverständlich, letzteres dürfte ein Programmierfehler von mir sein. Siehe Screenshot dazu, ich habe in den Leitungen zum Slave Längswiderstände eingefügt, so dass man an den Low-Pegeln sieht, was vom Master und was vom Slave ist. Der "Kinken" in der Clock ist das Clock Stretching. Meine vage Vermutung ist, dass das Verhalten vom Timing der Register-Zugriffe abhängt. Das würde erstens die unterschiedlichen Ergebnisse verschiedener Autoren erklären, ist aber zweitens von mir noch nicht sehr fundiert. Kann auch ganz was anderes sein. Außer dem Hinweis auf die AMD-Publikation hat diese elendige Forumsdiskussion leider keinerlei Substanz erbracht. Aber ich gebe die Hoffnung nicht auf, vielleicht liest irgendwann mal jemand mit, der tatsächlich was zum Thema beisteuern kann.
Dieter R. schrieb: > Nach aktuellem Status (mit meinem Master und dem originalen Slave aus > Atmel Start) kann ich bestätigen, dass der Slave bei Master Read Clock > Stretching generiert und der Master darauf korrekt reagiert. Ich kriege > aber noch keine validen Daten vom Slave übertragen und das ACK vom > Master funktioniert nicht. Ersteres erscheint mir im Moment > unverständlich wieso das unverständlich denn? ACK kommt doch nur wenn weitere Byte folgen, erwartet werden, es kann durchaus sein das du NACK setzen musst. aber dazu verrätst du zu wenig.
Joachim B. schrieb: > Dieter R. schrieb: >> Nach aktuellem Status (mit meinem Master und dem originalen Slave aus >> Atmel Start) kann ich bestätigen, dass der Slave bei Master Read Clock >> Stretching generiert und der Master darauf korrekt reagiert. Ich kriege >> aber noch keine validen Daten vom Slave übertragen und das ACK vom >> Master funktioniert nicht. Ersteres erscheint mir im Moment >> unverständlich > > wieso das unverständlich denn? > > ACK kommt doch nur wenn weitere Byte folgen, erwartet werden, es kann > durchaus sein das du NACK setzen musst. > > aber dazu verrätst du zu wenig. Ich hab aber in meinem Test-Code ACK gesetzt und will eigentlich ein zweites Byte lesen. Die Baustelle kommt aber später dran, erst einmal muss ich rauskriegen, warum der Slave immer 12 sendet, egal was er soll.
ich habe mal mit der fleury I2C Lib am m32 angefangen ohne Probleme! http://homepage.hispeed.ch/peterfleury/avr-software.html#libs Dort soll auch eine Soft I2C drin sein aber mit fleury und tiny817 bist du ja nicht der einzige mit Probleme https://www.google.com/search?client=firefox-b&q=attiny817+i2c&spell=1&sa=X&ved=0ahUKEwjHme-x5JDiAhVLbVAKHXRRDXUQBQgqKAA&biw=1720&bih=921 weiss natürlich nicht wer Schuld hat, microchip/atmel, fleury oder der Anwender.
Dieter R. schrieb: > Meine vage Vermutung ist, dass das Verhalten vom Timing der > Register-Zugriffe abhängt. Das würde erstens die unterschiedlichen > Ergebnisse verschiedener Autoren erklären, ist aber zweitens von mir > noch nicht sehr fundiert. Kann auch ganz was anderes sein. Kurze Zeit später, gedämpfter Jubel: ich habe mal vor dem Schreiben in TWI0.SDATA ein Delay von 20 us eingefügt. Ergebnis: gewaltiges Clock-Stretching vor dem ersten Daten-Bit, das vom Master richtig erkannt wird. Und der Slave überträgt die korrekten Daten! Das erfordert jetzt genauere Untersuchungen, ich kann die Software schließlich nicht von einem zufällig gewählten Delay abhängig machen. Das Ganze mit dem unveränderten Atmel-Slave. Nun würde ich gerne wissen, unter welchen Umständen der beim Atmel-Programmierer überhaupt gelaufen ist. Mit dem von Atmel-Start generierten Code offensichtlich nicht.
Falls noch einer mitliest: while (!(TWI0.SSTATUS & TWI_CLKHOLD_bm)) ; Dann kann man ins Daten-Register schreiben. Für Assembler-Programmierer sinngemäß. Für eine robuste Version (ich weiß, einige hören hier sowas nicht gerne) sollte noch ein Timeout rein. Atmel behauptet zwar, dass genau das nicht notwendig ist, sondern automatisch sichergestellt ist, aber dem ist wohl nicht so.
So, Master (polled) + Slave (Interrupt) läuft, in allen Varianten von Start/Repeated Start/Read/Write/Stop. Master ist 178 Byte Code + 75 Byte Data (!) kürzer als Atmels Original, Slave habe ich jetzt nicht nachgeguckt. Wenn man funktionierenden Code hat, versteht man auch das Datenblatt, jedenfalls geht es mir so. Andersrum ist es schwierig. Es bleiben aber Fragen, dazu bin ich in Kontakt mit Atmel.
Dieter R. schrieb: > So, Master (polled) + Slave (Interrupt) läuft, in allen Varianten von > Start/Repeated Start/Read/Write/Stop. und warum zeigst du den Code nicht?
Siehe dort: Autor: Dieter R. (drei) Datum: 08.05.2019 07:59 Unabhängig davon warte ich erst einmal ab, was Atmel zu den von mir gefundenen/vermuteten Problemen/Bugs sagt. Ich möchte keinen halbgaren Code in die Welt setzen, dazu gibt es schon zu vieles zu genau diesem Thema.
Hi >Autor: Dieter R. (drei) >Datum: 08.05.2019 07:59 >... Warum setzt du nicht einfach einen auf den Beitrag: Beitrag "Re: I2C mit ATtiny 0/1-series (z. B. ATtin817)" ? MfG Spess
Joachim B. schrieb: > und warum zeigst du den Code nicht? Dieter R. schrieb: > Siehe dort: > > Autor: Dieter R. (drei) > Datum: 08.05.2019 07:59 oh man, nicht mal ein Link Beitrag "Re: I2C mit ATtiny 0/1-series (z. B. ATtin817)" und dabei steht dort kein Code..... ich fühle mich etwas verschaukelt!
Joachim B. schrieb: > und dabei steht dort kein Code..... Findet Euch mit ab, es wird hier nie Code geben.
Dieter R. schrieb: > Master ist 178 Byte Code + 75 > Byte Data (!) kürzer als Atmels Original Mastercode 178 klingt für C-Verhältnisse gut, aber wozu verbrätst Du 75 Datenbyte? Etwas Stack für den Interrupt, viel mehr brauchts da nicht. > Wenn man funktionierenden Code hat, versteht man auch das Datenblatt, > jedenfalls geht es mir so. Andersrum ist es schwierig. Kann ich bestätigen. Das Datenblatt ist da nicht sehr übersichtlich, verständlich und vollständig in seiner Beschreibung.
Für die zwei oder drei am Thema interresierten: https://www.avrfreaks.net/forum/i2c-masterslave-code-attiny-series-1 Bitte das AVR-Forum nicht auch noch mit Gebrüll vollspammen, sondern dort nur sachdienliche Fachbeiträge. Danke
GermanFranz schrieb: > Dieter R. schrieb: >> Master ist 178 Byte Code + 75 >> Byte Data (!) kürzer als Atmels Original > > Mastercode 178 klingt für C-Verhältnisse gut, aber wozu verbrätst Du 75 > Datenbyte? Etwas Stack für den Interrupt, viel mehr brauchts da nicht. > Nicht 75 Datenbyte, sondern 75 Datenbyte KÜRZER als der Microchip-Originalcode. Die verbraten die ungeheuren Mengen, vermutlich für (überflüssige) Callback-Pointer und ähnliches Zeug.
Dieter R. schrieb: > Nicht 75 Datenbyte, sondern 75 Datenbyte KÜRZER als der > Microchip-Originalcode. Ach bloss kürzer... Aufschlussreicher wär die Angabe gewesen was nun wirklich Sache ist!? Und wie hat denn Microchip auf welche > gefundenen/vermuteten Problemen/Bugs reagiert?
"4. This software is strictly NOT intended for safety-critical ... applications" Also irgendwie wurde das beschworene Zuverlässigkeits- Ziel hier nicht erreicht, oder wie siehst Du das?
Wichtigtuer. Punkt 4 ist ein juristischer Disclaimer. Findet sich z. B. auch bei zahlreichen IC-Herstellern, vermutlich auch bei Microchip. Das bedeutet mitnichten, dass die Devices oder der Code nicht funktionieren, sondern dass für solche Applikationen zusätzliche Zertifizierung erforderlich ist. Das steht da auch, du hättest den Satz mal vollständig zitieren sollen! Erreicht wurde: I have made extensive tests arbitrarily shorting the signal lines against ground. During these tests both master and slave recovered under all circumstances. Reicht das für deine Ansprüche? Der Original-Code von Microchip blockiert unter diesen Bedingungen sofort. Vielleicht findet aber noch jemand ein Testszenario, wo es trotzdem zum Verbindungsabbruch kommt. U. a. solche Tests könnten helfen, eventuelle Schwachstellen im Code zu identifizieren und ggf. zu beheben, aber nicht dieses elende Bashing in diesem Forum. Auf weitere Beiträge in diesem Forum und zu diesem Thema werde ich aus sicher nachvollziehbaren Gründen nicht mehr reagieren. Es gibt ja andere Möglichkeiten zur Diskussion, wenn denn ernsthaftes fachliches Interesse besteht.
:
Bearbeitet durch User
Rolf schrieb: > Findet Euch mit ab, es wird hier nie Code geben. Hi, bist Du sicher? /* * I2C.c * * I2C Master * * Created: 10/05/2019 * Author: D*** R*** * * Tested with Alternate Pinout * * This software is covered by a modified MIT License, see paragraphs 4 and 5 * * Copyright (c) 2019 D*** R*** * OK. Du hast das Copyright. Stop listening that's my music? ciao gustav
Ein allerallerletztes Mal: https://de.wikipedia.org/wiki/MIT-Lizenz Da steht die Übersetzung. Dies ist eine permissive Lizenz (tatsächlich die kürzeste mir bekannte außer dem Satz "free as in speech, not as in beer"), die aber die Attribution zum Urheber beinhaltet, siehe hier (hab leider keine deutsche Quelle dafür): https://softwareengineering.stackexchange.com/questions/218331/what-are-the-requirements-for-attribution-in-the-mit-license
:
Bearbeitet durch User
Dieter R. schrieb: > I have made extensive tests arbitrarily shorting the signal lines > against ground. During these tests both master and slave recovered under > all circumstances. > > Reicht das für deine Ansprüche? Nein. Masse-Kurzschlüsse dürften selten die Ursache sein wenn der Bus bzw. ein Teilnehmer daran blockiert. Viel eher schon Störimpulse, Unter/Überspannungen oder Amok laufende Programme. Das ist aber alles unmöglich im I2C Treiber abzufangen und auch nicht auszutesten. Ein geordneter PowerOFF/ON Reset ist die einzig sichere Methode zur Wiederherstellung der Funktionsfähigkeit, wenn denn kein Bauelement im System defekt ist. Wenn dem aber so ist macht es wenig Sinn, den I2C Treiber über die Auswertung der ohnehin vorgesehenen Statusinformationen hinaus unnötig aufzublasen. Angesichts der absoluten Seltenheit solcher I2C Blockaden und dem Vorhandensein viel effektiverer Gegenmaßnahmen mit gutem Schaltungsdesign ist ein schlanker, schneller Treiber allemal mehr wert. > Auf weitere Beiträge in diesem Forum und zu diesem Thema werde ich aus > sicher nachvollziehbaren Gründen nicht mehr reagieren. Das ist auch überflüssig wenn kritische Einwände und Nachfragen nur als Gebrüll und "elendes Bashing" abqualifiziert werden!
Mann, Junge, ich weiß nicht, warum ich mich überhaupt noch damit befasse und immer noch zu Stellungnahmen herausgefordert fühle - vielleicht, um weniger erfahrenen Entwicklern eine Hilfestellung zu geben, damit sie nicht auf das dumme Zeug reinfallen, was hier unablässig verbreitet wird?? Vom Effekt her ist das doch das Gleiche!!! Die Bus-Übertragung wird gestört, zu beliebigen Zeitpunkten und in unvorhersehbarer Weise. Ob durch Kurzschluss oder Störimpulse wissen die Teilnehmer nicht, die sehen bloß illegale Signale. Für den Test ist es letztlich wichtig, sich ein handhabbares Testszenario zu verschaffen, das Störungen aus Sicht der Busteilnehmer erzeugt, und nicht, die ESD-Festigkeit der Eingänge zu prüfen. Da ist das Erzeugen von Kurzschlüssen nun mal der einfachste und ziemlich wirkungsvolle Testaufbau. Genau so haben wir es (weiter oben von mir geschildert) vor einiger Zeit mal mit dem Test eines industriellen USB-basierten Systems gemacht, dort haben wir ein Relais mit Zeitgeber angeschlossen und zyklisch den Bus kurzgeschlossen. Die realen Ausfälle hatten selbstverständliche andere Ursachen (vermutlich irgendwelche undefinierten Einstreuungen im Kundensystem, der Kunde war ein paar Tausend km weg und das konnten wir nicht prüfen), aber das Testszenario hat dazu geführt, dass wir die Treiber bzw. das ganze Linux-System ausreichend "härten" konnten. Die Treiber waren auch nicht von uns, aber wir hatten die Rechte an den Sources. Im übrigen verweise ich mal auf andere Beiträge in diesem Fachforum, z. B. diesen hier: Beitrag "I2C hängt sich auf" Ist von 2015, schon "damals" war das Problem bekannt, Zitate: Autor: Klaus (Gast) 8 mal mit SCL wackeln und dann prüfen, ob SCL und SDA high sind, ist die gängige Prozedur einen verklemmten I2C Bus zu reseten. Autor: Olaf (Gast) Da gehört immer auch ein Zaehler rein und bei Ablauf wird der Bus mit Dummytakten resettet und die I2C-Maschine im Controller neu initialisiert. Dort wird auch, wie in der zitierten AD-Applikation, geschildert, wie und warum das Problem in der Praxis auftreten kann und warum es überhaupt nichts mit gutem oder schlechtem Design zu tun hat. Wieso wird von den "Experten" in diesem Thread eigentlich unablässig bezweifelt, was vor 4 Jahren schon allgemeines Wissen war? Oder hier, ist von 2012, da ist auch der Verweis auf die NXP-Spezifikation: https://www.microchip.com/forums/m175368.aspx
:
Bearbeitet durch User
Dieter R. schrieb: > Vom Effekt her ist das doch das Gleiche!!! Die Bus-Übertragung wird > gestört, zu beliebigen Zeitpunkten und in unvorhersehbarer Weise. Da unterliegst Du einem schweren Irrtum. Die blanke Unterbrechung des Protokolls ist nur einer von vielen Blockier-Gründen und ausgerechnet jener, der sich mit entsprechenden Mitteln einer stabilen Spannungsversorgung und stabiler Software ohnehin vermeiden lässt. Kommt es zum ungeplanten System-Reset ist das ein unbedingt zu vermeidender (und vermeidbarer!) Super-Gau. Aber Du glaubst jetzt ausgerechnet mit Deinem fetten I2C Treiber die Lösung der Probleme an anderer Stelle zu sein? Lächerlich! Das Pferd von hinten aufgezäumt! Hier ist schlicht sauberes, absturzfreies Systemdesign angesagt, begreif das doch endlich. Hör auf von der Spezifikation als dem Maßstab aller Dinge zu träumen. Die konkrete Hardware spielt eine nicht minder ausschlaggebende Rolle. Diverse eingestreute Störimpulse bzw. die ganze ESD Problematik sind noch ein ganz anderes, die Hardware verriegelndes Kaliber und da ist und bleibt ein Power-Reset angesagt.
GermanFranz schrieb: > Aufschlussreicher wär die Angabe gewesen was nun > wirklich Sache ist!? Bitte sehr, jeweils code size, aus link map, dezimale Angaben, Atmel/eigener Code: i2c_master 1344 i2c_master + i2c_master_example 1496 I2C (ohne I2C_read_bytes/write_bytes) 642 I2C (mit I2C_read_bytes/write_bytes) 916 i2c_master + i2c_master_example entspricht etwa I2C mit I2C_read_bytes, ohne write Jaja, "mit Deinem fetten I2C Treiber ..." > Und wie hat denn Microchip auf welche > gefundenen/vermuteten Problemen/Bugs reagiert? Support Case ID assigned. So schnell sind die nicht. Slave hab ich jetzt nicht nachgesehen. Kann ja mal jemand anders machen, der selbst ernsthaft an dem Thema arbeitet.
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.