Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - FAQ - Zum CC1-Forum - Zum CC-Pro-Forum

Wichtig: Bevor Du wegen einem Problem mit der CC2 postest, stelle sicher, daß Du
die neueste OS-Version, die neuseste Compiler-DLL und die neuesten Modulversionen benutzt!
Beachte, daß sich auf der CD zur CC2-Unit/Station auch jetzt noch die ältesten Dateien befinden!
Es gelten folgende Anleitung und Regeln: Regeln CC2Net.de-Forum
Zurück zum Artikel  (Blaue Felder sind Pflichtfelder)


Name:   UserID: 
 E-Mail:
Kategorie
Betreff
Homepage:
Link-Titel:
Link-URL:
Cookie für Name, UserID, E-Mail, Homepage-URL setzen
(Erspart die Neueingabe bei Beiträgen und Antworten)
(Zum Löschen des Cookies hier klicken)
Ich nutze:
C-Control II Unit
C164CI-Controllerboard
C-Control II Station
CCRP5 mit CC2-Unit (Conrad Roboter)
CC2-Application-Board
CC2-StarterBoard
CC2-ReglerBoard
eigenes Board
original OS     OSOPT_V2     OSOPT V3.0 OSOPT V3.1

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, > > > > Wobei ja diese ständigen 10mS ... > > "ms" bitte, nicht "mS". "mS" sind milli-Siemens, eine Einheit für den Leitwert. > > >... , die hier im Bezug auf RN-Motor genannt > > werden, völlig aus der Luft gegriffen sind. > > Ich weiss nicht wer das erfunden hat, jedenfalls gemessen hat er es nicht! > > > > Bei einzelnen Bytes benötigt RN-Motor in der Regel unter 0,1 ms !!!! > > Lediglich bei dem letzten Byte, einer 5 Byte Befehlssequenz, kann > > es zu einer Verzögerung im Millisekundenbereich kommen, diese ist aber je > > nach Befehl unterschiedlich. Bei den üblichen einfachen Befehlen, die öfters mal > > übertragen werden, ist das aber auch nur ca. 0,8 ms für die ganzen 5 Byte. > > Nur einige komplexere Befehle benötigen bei "einem Byte pro Sequenz" eine etwas höhere > > Zeit. > > Sorry. Ich bin von 10ms ausgegangen, die Harald gepostet hatte. > 0,1ms sind natürlich bedeutend weniger. > > > Insgesamt wird aber der I2C-Bus bei RN-Motor gering belastet. Da gibt es z.B. hier bei > > den Bauanleitungen im CC2net Schaltungen die den I2C Bus viel viel mehr belasten. > > Zum Beispiel die Drehzahlmessung wo ständig der Timer überläuft und gelesen werden muss usw. > > Ich weiß hier absolut nicht, was Du meinst. > Wo soll hier bitte eine Schaltung zur Drehzahlmessung über den I²C-Bus existieren ??? > > > Nun gut, ich hoffe ich konnte ein wenig mit dem falsch geäußerten Dingen hier > > aufräumen. Vielleicht hat´s ja auch dazu beigetragen das endlich mal die CC II > > Routinen überarbeitet werden - dann haben die Mißverständnisse wenigstens > > was positives gebracht. > > Fakt ist, daß Clocksteching in 99,9% der Fälle nicht benötigt wird. > Selbst sämtliche Phillips Slave-ICs "strechen" nicht. > Und auch beim ATMega8 bei eigenen Tests und beim Test einiger komplexer Slaveanwendungen, > die nicht von mir stammen, kommen ohne Streching aus. > Es ist halt alles eine Sache der Optimierung der Kommunikation. > Und, da Du fragst, ob ich nun auf ATMega umsteige, kann ich hier nur ein deutliches Nein äußern. > Ich beschäftige mich nur mit den Atmelcontrollern, da ich einige Slaveanwendungen > für den I²C-Bus erstellen will. > Für solche kleinen Aufgaben sind die ATMegas gut zu gebrauchen. > Aber eine CC2 ersetzen können diese nicht, wenn ich da an die größeren > Projekte denke, die ich betreue, würde eine Lösung mit ATMegas schon an > der Speichergröße scheitern. (Flash & RAM) > Der größte ATMega hat gerade einmal 128kB Flash und 4kB RAM. > > Wenn jemand aber doch einmal Clockstreching benötigt, kann man folgende Funktion > in den C2-Code einbinden: > <code>inline function waitI2C_Ready() > { > inline vmcodes.VM_LOAD_ABSOLUTE_INT; > inline 0xFFC6; > inline vmcodes.VM_LOAD_IMMEDIATE_INT; > inline 0xFCFF; //P3.8 als Eingang > inline vmcodes.VM_AND; > inline vmcodes.VM_STORE_ABSOLUTE_INT; > inline 0xFFC6; > inline vmcodes.VM_BRANCH; > inline 1; > inline vmcodes.VM_YIELD; > inline vmcodes.VM_LOAD_ABSOLUTE_INT; > inline 0xFFC4; > inline vmcodes.VM_LOAD_IMMEDIATE_INT; > inline 0x0100; > inline vmcodes.VM_AND; > inline vmcodes.VM_BRANCH_IF_ZERO; > inline -8; > }</code> > > Jedoch kann die Ausführung bei I²C-Slaves, die kein Clock-Streching betreiben, > u.U. zu Problemen führen, da das Umschalten der Clk-Leitung auf Eingang > als Clock-Pulse interpretiert werden kann. > Das kann man zwar verhindern, wenn man das Clockstreching in die Write und Read-Routinen > des OS einbindet, jedoch ist hier der Aufwand gegenüber dem Nutzen zu groß, > so daß ich das wahrscheinlich nicht machen werde. (Höchstens, wenn ich wirklich > einmal Zeit haben sollte.) > > MfG André H.
Dateianhang: (.gif, .png., .jpg, .zip, .rar)
max. 256kB
max. 256kB