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 ! > > Ich bin am Überlegen, die I²C-Routinen komplett zu überarbeiten. > > Jedoch werde ich dann nur Clockstreching nur eingeschränkt implementieren. > > D.h., es wird ein Timeout geben und nicht beliebig lange auf die "Freigabe" von SCL gewartet. > > Ist ja schon komisch, das in der I22-Spec nichts über timeout steht. > Von welcher heilen Welt sind die denn ausgegangen. ;D > > Für alle, die die Spec nicht zur hand haben: > > <b>Generation of clock signals on the I2C-bus is always the > responsibility of master devices; each master generates its > own clock signals when transferring data on the bus. Bus > clock signals from a master can only be altered when they > are stretched by a slow-slave device holding-down the > clock line, or by another master when arbitration occurs. > > If a slave can’t > receive or transmit another complete byte of data until it > has performed some other function, for example servicing > an internal interrupt, it can hold the clock line SCL LOW to > force the master into a wait state. Data transfer then > continues when the slave is ready for another byte of data > and releases clock line SCL. > > HIGH period of the SCL clock tHIGH Min 4.0us Max --- > </b> > Selbst bei der Länge des HIGH pegels wurde kein MAX angegeben. > > > Das ist notwendig, da die I²C-Bus-Routinen nicht im Hintergrund ausgeführt werden > > und somit das Programm verzögern würden, wenn z.B. SCL aus irgendeinem Grund auf low gezogen würde. > > Mehr als verständlich. > > > Evtl. werde ich auch sehen, daß ich eine Art Hintergrundausgabe beim I²C-Bus mache, > > wie es beispielsweise bei den COM-Send-Routinen der Fall ist. > > Aber dafür brauche ich etwas mehr Zeit am Stück. > > Das führt aber auch zu sendbuffer gedanken, die dann vom Anwender der API implementiert werden muß. > > > Ich habe testweise die original I²C-Read-Routine modifiziert, die ein Timeout > > von 1024 Schleifendurchläufen bei jedem Clock-Zyklus hat. > > Eine Timeout-Schleife sieht hier so aus: > > <asm> > > MOV R10, #0400h > > _i2cR2: > > CMPD1 R10, #0h > > JMPR cc_EQ, _i2cR2a > > JNB MRST,_i2cR2 > > _i2cR2a: > > </asm> > > Was bedeutet das maximal in msec. Bin zu faul das zu errechnen oder auszuprobieren. :( > > > Zusätzlich ist habe ich die Clockleitung von Push-Pull in OD geändert wie es > > beim I²C-Bus natürlich sein soll. > > Ich verwende derzeit dieses einfache Clockstreching für experimentelle > > ASM-Routinen zum eDIP240, da die CC2 in ASM einfach viel zu schnell ist, > > damit der Controller des Displays bei der Datenübertragung hinterherkommt. > > Die komplette Routine kann ich aber derzeit nicht veröffentlichen, da ich hier > > etwas zu viel probiert habe und der Code entsprechend aussieht. ;-) > > Bin zu jedem Test bereit. Vier Lötung und ein "Suchen Ersetzen" und schon kann ich es > sehen ob es läuft oder nicht. > > > Vielleicht werde ich übergangsweise auch ein ASM-Modul schreiben, welches > > statt den OS die I²C-Bus-Routinen verwendet werden kann. > > Das wäre auf jeden Fall kurzfristiger realisierbar und OS-unabhängig. > > Wie schon gesagt immer her damit. > > Gruß > Thomas
