> Keine Sorge, das mache ich immer voher.
> Und ich kann wirklich behaupten, da� ich den I²C-Bus besser kenne, als Du.
Ich weiss zwar nicht wie du zu der Behauptung kommst. Dabe rdie mangelnden Ausführungen
in diesen Thread als auch bei den CC-I2C Code lä�t mich ein wenig zweifeln.
Aber wir wollen uns da ja nicht streiten. Aber ich bitte dann schon um seriöse Beiträge!
Das es beim I2C Bus üblich ist den Master über die Taktleitungen zu bremsen ist
schon seit Jahren in den Fachbüchern beschrieben. Wieviel ms das genau sein darf ist
nirgends festgelegt.
Wnen die i2C-Routinen bei der CC2 das nicht können, liegt das Problem bei der diesem Code
und nicht bei RN-Motor. Bei den AVR´s gibt es nie Probleme, selbst in Programmiersprachen
wie Bascom Basic klappt das tadellos.
Leider muss ich die auch bei dem TWI wieder berichtigen: Natürlich nutzt RN-Motor die
TWI-Interrupts - alles andere wäre Unsinn
Mit erstaunen höre ich übrigens das du nun auch auf AVR umsteigst. Oder hab ich das falsch
verstanden?
Nun jedenfalls dürftest du dann bald mit dem Wissenstand an dem Punkt sein, wo
du weisst das es natürlich nicht die paar Bytes sind die ein paar Millisekunden Zeit beanspruchen.
Die einzelnen Befehle werden ja deutlich schneller als bei der CC II ausgeführt.
Nein es liegt in der Art der Firmware - diese tut nämlich bereits während der Befehlübertragung
eine ganze Menge mehr. Sicher kann man das noch optimieren indem man diese Arbeiten
nach der Parameterübergabe durchführt. Aber das ist ein Punkt der für die gedachte
Anwendung (Robotik) recht nebensichlich ist.
Es haben ja nur die mangelhaften I2C Routinen der CC II damit Probleme. Und es ist nicht
Aufgabe von RN-Motor die Fehler anderer Routinen auszugleichen
Passender Link: http://www.roboternetz.de
Meine Seite: http://www.roboternetz.de
Antwort schreiben
Antworten:
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)