| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, CC2-Application-Board, CC2-StarterBoard, CC2-ReglerBoard, OSOPT V3.0 |
> 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Ã? langsame 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.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: I2C Befehlsfolge (von Frank - 12.02.2005 16:30)Re: I2C Befehlsfolge (von Thomas - 12.02.2005 22:41)Re: I2C Befehlsfolge (von Frank - 13.02.2005 15:43)Re: I2C Befehlsfolge (von André H. - 20.02.2005 13:52)