Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > Hallo Frank, > > > Dies ist nicht korrekt! RN-Motor ist 100% I2c konform, hie rhat André leider > > was falsches geschrieben! > > Hier ein eindeutigen Jain. > Das Clockstreching ist nicht dazu gedacht, den I²C-Bus wirklich unnötig zu blockieren, > sondern, daß <b>langsame</b> Peripheriebausteine etwas Zeit zum Verarbeiten bekommen. > Die meisten Controller benutzen bei der Ansteuerung des I²C-Busses als Master > ein Timeout im ms-Bereich. Meist aber nie mehr als 10ms. > > Ich dachte immer, die Atmel-Controller seihen so schnell. > Aber, wenn für das Verarbeiten von nur einem simplen Byte 10ms gebraucht wird, > kann ich nur den Kopf schütteln. > Da ist ja eine CC1 schon schneller. ;-) > Wenn jetzt jemand z.B. 100 Byte zum RN-Motor sendet, wird sein System > für eine ganze Sekunde blockiert. > Ob es hier noch Sinn macht, die "achso schnellen" Atmels zu benutzen, wenn > der Controller extern auf unter CC1-V1.1-Niveau abgebremst wird ? > > Das zum Thema "Atmel-Lobby". ;-) > > > Das Problem liegt eindeutig bei den CC2 I2C Routinen die offenbar nicht ganz ausgereift sind. > > > > Ich habe nie geschrieben, daß die Routinen ausgereift seien. > Jedoch macht es in einem Multithreading-System keinen Sinn, das gesamte System zu blockieren. > Aber mit einem kleinem vierzeiler kann man den Code der CC2 C2-seitig > erweitern, daß auch endlos auf den Slave nach jedem Byte gewartet wird. > > > Nach der I2C Norm ... > > Welche Norm ?? > Der I²C-Bus ist eine herstellerspezifische Spezifikation, die lediglich von anderen > Halbleiterherstellern übernommen wurden. > (Manche nennen das dann TWI, um keine Lizenzgebühren an Phillips zahlen zu müssen.) > Das Institut für Normung oder andere Ämter für Normung werden hier nichts festgelegt haben. > > > ... darf der Slave die Taktleitung auf Low ziehen > > um den Master zu zwingen zu warten bis der Befehl ausgeführt wurde. Der Master muss > > also stets die Taktleitung überwachen. > > Das ganze nennt sich Clockstretching und war nicht von Anfang an Bestandteil > in den I²C-Spezifikationen. > Jedoch ist das Clockstretching in den meisten Mastern so implementiert, > daß dieser die Übertragung nach einem Timeout "abbricht". > > > Würden die I2C Routinen korrekt sein, dann wäre > > ein Sleep nicht notwendig. Ein eindeutiger Bug bei den CC II Routinen. > > Wie gesagt, der Bug liegt eigentlich nicht im CC2-OS, sondern eher > in der sehr starken und unnötigen Ausbremsung des I²C-Busses. > > > Im übrigen nutzt auch RN-Motor dien Hardware I2C Bus der Atmel Controller, > > auch das wurde hier falsch beschrieben. > > Ich weiß, daß Du die TWI-Hardware des Atmels nutzt. > Wo soll ich bitte etwas anderes geschrieben haben. > Ich behaupte nur, daß Du nicht die TWI-Interrupts benutzt. > Denn, das sind zwei paar Schuhe. > Benutzt man beim Atmel das TWI-Interface ohne Interrupt und fragt > das TWI-Statusregister zu selten ab, kommt es nämlich genau zu diesem Phänomen. > > Ich programmiere mittlerweile auch ATMegas als I²C-Slave. > Ich konnte bei meinen bisherigen teils sehr umfangreichen(=umfangreichere Programme > im Atmel) Versuchen keinerlei Notwendigeit für Zwangspausen feststellen. > > Auch Hansi mit seinem FS20-I²C-Modul auf Atmel-Basis hat sicher auch noch > kein Problem mit Clockstretching gehabt, da er die TWI-Interrupts nutzt. > Bei ihm ist die Anwendung beim Atmel wirklich rechenintensiv. > > Ich bleib deshalb bei meiner Behauptung, das die Firmware des RN-Motor > in dieser Hinsicht stark verbesserungswürdig ist. > > > > Also bitte erst kundig machen - dann kritisieren ;-) > > > > Keine Sorge, das mache ich immer voher. > Und ich kann wirklich behaupten, daß ich den I²C-Bus besser kenne, als Du. > > > MfG André H.
