[ATTiny44+PI4] TWI Slave nur mit langsamen Clocks

Ich würde das mit einem Logic-Analyzer untersuchen.

Mampf F. schrieb:

> ich hab einen ATTiny44, der per TWI an einem Pi4 hängt und habe
> festgestellt, dass das nur so richtig funktioniert, wenn ich den Clock
> auf 10kHz in der /boot/config.txt ändere.

Ist ja auch die denkbarst ungünstige Wahl der Konfiguration. Der Raspi 
kann kein Clock-Stretching und der Tiny44 kann I2C nur sehr notdürftig 
(via USI). Und dann auch noch Implementierung des Tiny-Programms in C, 
was mit Interrupts seine liebe Mühe hat, wo aber blöderweise gerade bei 
der notdürftigen I2C-Unterstützung des Tiny alles nur noch davon 
abhängt, dass entweder der Tiny schnell genug reagiert (um ohne 
Clockstretching auszukommen) oder aber der Master halt mit 
Clockstretching vernünftig umgehen kann.

Sprich: krasser Fehler beim Design, nämlich bei der Wahl der Waffen und 
der Komponenten. Das passt halt einfach alles nicht zusammen.

Als Hauptproblem würde ich hier allerdings diesen Raspi-Dreck ansehen. 
Clock-Stretching ist schließlich definitiv Teil des I2C-Standards, eben 
um auch Slaves zu unterstützen, die bezüglich der Antwortzeiten nicht so 
ganz auf der Höhe der Zeit sind.
Wer das nicht kann, hat nicht das Recht, seine entsprechende 
Schnittstelle als I2C-Schnittstelle zu bezeichnen. Das ist reine 
Kundenverarschung!

(prx) A. K. schrieb:

> Das ändert sich auch nicht durch eine bessere Implementierung von I2C im
> µC, als per USI im Tiny. Man hat da auch nicht mehr Zeit zur Reaktion.

Mehr Zeit hat man natürlich nicht. Aber man kann diese besser nutzen. 
Z.B. auch so gut, dass es funktioniert. Auch wieder so ein "Wunder", was 
nur in Asm relativ einfach geht...

Aber klar: auch in Asm hängt es stark davon ab, was der Tiny eigentlich 
im Kern tun soll, die Kommunikation ist ja eigentlich Nebensache. Aber 
es geht halt in Asm sehr viel mehr als in C.

Eben deshalb, weil man die volle Kontrolle über alle Resourcen und die 
volle Kontrolle über das Timing hat.

(prx) A. K. schrieb:

> Auch ohne andere Interrupts wird es eng.

Eng ja. Aber eben nicht zu eng. Bei 8Mhz Systemtakt und 100kHz-Bus geht 
das schon. In systemweit optimiertem Asm natürlich...

Und bei 16kHz (bei einigen Tinys ja per PLL-Takt möglich) geht das schon 
recht problemlos, ja es gehen sogar konkurrierende Interrupts, zumindest 
einer. Der muss sich natürlich ganz dünn machen.

Peter D. schrieb:

> Man kann es ja umgekehrt machen, d.h. den Pi4 als Slave. Der AVR kann ja
> als single Master Clock Stretching.

Es geht hier um einen Tiny. Der hat keine TWI-Schnittstelle wie die 
Megas, die du wohl nur kennst. Der hat ein USI und dessen rudimentäre 
I2C-Unterstützung. Mehr nicht.

(prx) A. K. schrieb:

> Ich war deshalb auf die serielle Schnittstelle umgestiegen. Das ist zwar
> umständlicher, weil Stream statt Message als Grundlage, ist aber
> verlässlich.

Bei eine Tiny als Client (jedenfalls für alle ohne echte USART, also die 
allermeisten) gilt das aber auch nur bei recht geringen Bitraten. Und 
die Einschränkungen bezüglich konkurrierender Interrupts sind natürlich 
ähnlich rigide.
Dazu kommt, dass UART-Kommunikation nur mit einiger zusätzlicher Mühe 
busfähig zu machen ist.

Nö, das ist kein Ausweg, der Ausweg für den AVR-Slave ist: Asm.

Oder halt: Master gegen was Brauchbares tauschen. Frank M. schlägt da ja 
was vor. Kenne ich nicht, kann also nicht sagen, ob die Sache hält, was 
sie verspricht. Aber zumindest theoretisch könnte das wohl durchaus 
funktionieren.

c-hater schrieb:
> Und dann auch noch Implementierung des Tiny-Programms in C

Du laberst Scheiße! Sorry, das muss man mal so klar und deutlich sagen. 
Dein dümmliche C-Bashing ist wie immer fehl am Platz. Suche dir dafür 
einen anderen Wort wo sich deinesgleichen tummeln. Da bekommst du dann 
auch die positive Zustimmung, die dir so sehr fehlt.

Wenn der Raspi kein Clock-Stretching kann, dann darf man das auf dem 
Slave halt nicht nutzen. Basta. Dafür kann weder der ATtiny was, noch 
die Programmiersprache.

Doch ob das hier überhaupt der Knackpunkt ist, liegt nach noch im 
Bereich der wilden Phantasien. Geprüft (gemessen) hat es noch niemand.

Stefan ⛄ F. schrieb:

> Du laberst Scheiße!

Sagst du, aber frag' mal einen geistig Gesunden.

> Wenn der Raspi kein Clock-Stretching kann, dann darf man das auf dem
> Slave halt nicht nutzen.

Du hast nicht verstanden, dass das ein Manko des Raspi ist. Der Standard 
sieht Clock-Stretching obligatorisch vor. Ein Master, der das nicht 
kann, taugt schlicht nix.

> Dafür kann weder der ATtiny was, noch
> die Programmiersprache.

Das stimmt. Nur kann man eben mit Asm den Tiny soweit ertüchtigen, dass 
er kein Clockstretching mehr benutzen muss (zumindest nicht an einem 
100kHz-Bus) und ihn damit sogar zu einem völlig unfähigen Master wie dem 
Raspi kompatibel machen. Genau das geht aber eben NUR in Asm relativ 
einfach.

Was erneut die unendliche Überlegenheit von Asm aufzeigt, für alle 
Fälle, wo es "eng" wird.

> Bereich der wilden Phantasien. Geprüft (gemessen) hat es noch niemand.

Du bist definitiv ein Idiot! Man braucht das weder prüfen noch messen. 
Man kann das einfach am Code "ausrechnen". Eigentlich ist Ausrechnen 
noch zu viel gesagt, es handelt sich ja eigentlich um kaum mehr als ein 
simples Abzählen von Takten von Instruktionen. Das einzig halbwegs 
Anspruchsvolle dabei ist: finde den worst case des Gesamtsystems.

Sowas fällt bei einem Programm, welches komplett in Asm implementiert 
ist, naturgemäß sehr viel leichter, weil das da schon im Source 
abzählbar dasteht...

c-hater schrieb:
> Du bist definitiv ein Idiot!

Ein Idiot, der es einfach macht. Meines Slaves empfangen 10 Bytes mit 
4MHz Taktfrequenz in C völlig ohne Tricks und ohne Probleme - ohne 
Clock-Stretching. Dabei läuft nebenbei noch eine 10 Kanalige Soft-PWM.

Aber was nicht sein darf, kann nicht sein, nicht wahr?

Stefan ⛄ F. schrieb:

> Ein Idiot, der es einfach macht. Meines Slaves empfangen 10 Bytes mit
> 4MHz Taktfrequenz in C völlig ohne Tricks und ohne Probleme - ohne
> Clock-Stretching. Dabei läuft nebenbei noch eine 10 Kanalige Soft-PWM.

Bei welchem Bustakt? Und welcher µC ist der Slave?

c-hater schrieb:

> Bei welchem Bustakt? Und welcher µC ist der Slave?

Und natürlich: Ist der Master wirklich ein RasPi mit der normalen 
Hardware-I2C-Schnittstelle?

c-hater schrieb:
> Bei welchem Bustakt? Und welcher µC ist der Slave?

100 kHz Bustakt, ATtiny26 und ATtiny2313.

Stefan ⛄ F. schrieb:

> 100 kHz Bustakt, ATtiny26 und ATtiny2313.

OK, und was ist mit dem Master? Der ist ja schließlich hier der 
Knackpunkt. Mit einem standardmäßigen Master kann's jeder Doofe, weil 
halt das Protokoll dafür ausgelegt ist und eben Clock-Stretching für 
diesen Fall vorsieht.

Der Rottweiler hat sich fest gebissen.

Stefan ⛄ F. schrieb:

> Der Rottweiler hat sich fest gebissen.

Aha, aha. Da haben wir den Lügner wohl erwischt. Es läuft eben wohl doch 
nicht ohne Clock-Stretching. Sondern vermutlich mit der von Frank M. im 
Thread vorgeschlagenen Alternative zum Raspi-Normal. Oder an einem 
völlig anderen Master, der halt von Haus aus Clock-Stretching 
unterstützt (so wie es sein sollte).

Die Lüge war also im Kern die Behauptung, dass der C-Scheiß auf dem Tiny 
ohne Clockstretching-Unterstützung durch den Master funktioniert. Und 
das kann nur eine Lüge sein. Um das heraus zu finden, brauchst du nicht 
einmal den Code zu zeigen, dazu muss man nur Rechnen können...

Wäre aber trotzdem spannend, ihn zu sehen. Ich könnte dann taktgenau 
deine frechen Lüge nachweisen. Und, ganz ehrlich: ich hätte sogar 
richtig Spaß daran, genau das zu tun...

Wenn du also auch nur einen Rest Glaubwürdigkeit bewahren willst, dann 
poste den Code. Notfalls auch nur das *.hex. Aber klar: Beides würde mir 
vollkommen reichen, dich der Lüge zu überführen, also wirst du das wohl 
eher nicht tun...

c-hater schrieb:
> Es läuft eben wohl doch nicht ohne Clock-Stretching.

Du hast keine Ahnung, über was du da urteilst. Ich habe keine Lust mich 
weiter mit die abzugeben, nachdem du mich Lügner genannt hast. Du hast 
mal wieder deinen Platz auf meiner List mit dem weisen Mann bekräftigt.

Stefan ⛄ F. schrieb:

> Du hast keine Ahnung, über was du da urteilst.

Ja, stimmt. Du hast schließlich immer noch nicht nicht den Code 
geposted, der das Unmögliche angeblich möglich macht...

Ein I2C-slave (oder wie die jetzt heissen) macht ja clock stretching 
nicht wegen I2C, sondern weil ein Rückgabewert noch nicht vorliegt z.B. 
weil Sensoren erst noch abgefragt werden müssen. Das kann man aber auf 
den Attiny oberhalb von I2C anders lösen ... (z.B. einen speziellen Wert 
für "ich bin noch nicht fertig" zurückliefern).

LG, Sebastian

Clock-Stretching ist nur eine von vielen möglichen Knackpunkten.

Bevor du da Zeit und Geld versenkst, überprüfe doch erstmal die 
Vermutung bezüglich des Clock Stretchings. Denn vielleicht hast du ein 
ganz anderes Problem.

Der Klassiker bei I²C ist die Nutzung von zu hochohmigen Pull-Up 
Widerständen wie sie auf quasi allen Chinesischen Modulen bestückt sind. 
Und die billigen 1-Transistor Pegelwandler tun sich mit 
Serienwiderständen und schwachen Bustreibern schwer.

Mit einem Oszilloskop prüft man die Qualität der Signalpegel. Wenn du 
dir keins leisten kannst, dann wird dir ein DSO-150 gute Dienste 
leisten. Dieses "Spielzeug" ist immer noch viel besser, als gar keins zu 
haben. Kostet ca. 40 Euro bei Amazon.

Danach kannst du die Kommunikation auf Bitebene mit einem Logic Analyzer 
und dem Programm PulseView kontrollieren. Kostet ca 10 Euro bei Amazon.

Wenn du Zeit hast bestellst du die Sachen zum halben Preis bei 
Aliexpress.

Sebastian schrieb:

> Ein I2C-slave (oder wie die jetzt heissen) macht ja clock stretching
> nicht wegen I2C, sondern weil ein Rückgabewert noch nicht vorliegt z.B.
> weil Sensoren erst noch abgefragt werden müssen.

Neeeiiin. Das machen nur so richtig lausig beschissene 
*Anwendungs*-Implementierungen deshalb.

Das Problem steckt (zumindest mit USI) ganz wo anders. An zwei Stellen 
im Treiber, also der Transport-Ebene.

Erstmal muss der Slave überhaupt mal eine Aktivität am Bus erkennen 
(also eine start condition). Dann muss er schnell genug sein USI dazu 
konfigurieren, überhaupt erstmal eine Adresse zu empfangen. Das ist noch 
ein relativ einfaches Problem.

Die zweite, noch viel kritischere Stelle ist das (jedes!) Byte-Ende. 
Hier ist das ACK schnell genug zu empfangen/zu senden und dann ggf. noch 
das nächste Byte zu empfangen/zu senden.
Um das alles richtig zu machen, muss der Treiber allerdings erstmal 
herausfinden, wo in einem I2C-Transfer er eigentlich gerade steckt.
Schafft er das alles nicht, passiert wieder unweigerlich 
Clock-Stretching (durch die Hardware).

Hier kann man allerdings erheblich tricksen, indem man ab erkannter 
start condition "pollt". Das entschärft das Problem, verhindert aber 
dann auch effizient konkurrierende Interrupts in dieser ganzen langen 
Zeit des kompletten I2C-Transfers.

Aber als Assembler-Programmierer muss man das eben nicht, da kann man 
auch dieses Problem tatsächlich noch vollständig in der entsprechenden 
ISR abhandeln.

> Das kann man aber auf
> den Attiny oberhalb von I2C anders lösen ... (z.B. einen speziellen Wert
> für "ich bin noch nicht fertig" zurückliefern).

Genau. So löst man das Problem auf Anwendungsebenene richtig, statt 
durch Missbrauch des Clock-Stretching-Mechanismus der Transport-Ebene. 
Davon sollte die Anwendungsebene im Idealfall ja garnix wissen.

Ändert aber eben nur leider nichts an den Timing-Problemen auf der 
Transport-Ebene...

Ich denke auch, dass das Timing vom ACK der kritische Punkt ist. ACK 
soll ja bestätigen, dass das Byte angenommen wurde bzw. das ein Kommando 
erfolgreich ausgeführt wurde. Der Empfänger muss innerhalb eines 
Bustaktes entscheiden, ob er mit ACK antworten will - sonst wird daraus 
automatisch ein NAK.

Die Entscheidung, ob der Slave mit ACK oder NAK antworten will erfordert 
oft irgendeine Prüfung. Und die braucht halt ihre Zeit. Dazu kommt: Wenn 
die Bytes in einer ISR verarbeitet werden, dann geht einem schon die 
Verzögerung des Interrupt-Aufrufes und der Prolog (Sichern der Register) 
von dieser kostbaren Zeit verloren.

Macht man es hingegen in der Hauptschleife, können Interrupthandler 
(z.B. vom Timer) zu viel Zeit in Anspruch nehmen. Da muss man ziemlich 
aufpassen und sich auf wenige Aktionen beschränken.

Clock Stretching kann man nutzen, um diese Zeitspanne zu verlängern. Das 
sollte sich dann aber immer noch im Rahmen von weit unter 1 ms 
abspielen, weil der ganze I²C so lange blockiert ist. Bei einigen 
Geräten kommt Clock Stretching gar nicht in Frage weil es nicht 
implementiert wurde.

Wenn die Verarbeitung von Daten länger dauert, sollte man die 
Verarbeitung asynchron machen. Der Slave kann für den Status Flags 
(arbeite noch, fertig, Erfolg, Fehler) bereit stellen, die der Master 
jederzeit ohne warten zu müssen abfragen darf (Polling). Das 
Kommunikationsmuster aus Sicht des Master wäre dann:

1) Kommando Senden
2) Status abfragen
3) Wiederhole 2, wenn noch nicht fertig
4) Ergebnis abholen

C-hater, du hast das alles gut beschrieben, ich stimme dir weitgehend 
zu. Bis auf diesen Punkt:

c-hater schrieb:
> Aber als Assembler-Programmierer muss man das eben nicht, da
> kann man auch dieses Problem tatsächlich noch vollständig in der
> entsprechenden ISR abhandeln.

Je nach Verhältnis zwischen CPU und Bustakt kann man das auch in C 
vollständig in der ISR abhandeln, ohne Klimmzüge zu machen. Doch der gcc 
Compiler optimiert inzwischen sehr gut. Er sichert nur die nötigsten CPU 
Register, deswegen kann es "einfach so" klappen. Und wenn nicht, dann 
gibt es immer noch "naked ISR", falls du das nicht kennst.

Ein Blick ins Assembler Listing kann dabei ziemlich aufschlussreich 
sein, wenn man es denn lesen kann. Deswegen sage ich oft, dass ein 
kleines bisschen Assembler Kenntnisse auch für C Entwickler nützlich 
sind.

(prx) A. K. schrieb:
> mit c-hater über die Vorzüge von C diskutieren? ;-)

In diesem Thread und bei dieser Problemstellung sind Vorzüge für C nicht 
erkennbar. Da ist's wichtig, dass sich der emulierte Slave möglichst wie 
richtige Hardware verhält und das ist am Einfachsten mit Assembler 
machbar, man muss es halt auch können und nicht nur darüber 
phantasieren.

Wäre zur reinen Funktionalität das I2C-Protokoll sprechen zu können, 
eine kompliziertere Verarbeitung von Messwerten, etc. gefragt, dann erst 
macht eine Hochsprache Sinn. Und selbst dann würde man die I2C-Fähigkeit 
als HAL in Assembler ausführen. Da weiß man einfach was man bekommt, 
während man Hochsprachen durch entsprechende Parameter da hinschubsen 
muss, wo man hin will.

(prx) A. K. schrieb:
> Und seither offenbar keinen Finger mehr gerührt um den
> Bug zu beseitigen.

Es wurde der Punkt des "good enough" erreicht.

Peter D. schrieb:
> Die Philips Dokumentatiion ist vorbildlich,

Ist das so? Immerhin enthält sie keine Empfehlung, geschweige denn ein 
Gebot, auf Anwendungsebene kein "lausiges" "beschissenes" clock 
stretching durchzuführen. Siehe z.B. Sensirion SHT21 hold master mode, 
der SCL low bis zu 85ms (!) stretcht (für den es allerdings auch die 
Alternative no hold master mode gibt).

LG, Sebastian