| Re: Clockstretching Kategorie: I²C-Bus (von KönigDichBauch - 28.11.2005 9:02) | ||
| Als Antwort auf Re: Clockstretching von André H. - 27.11.2005 17:07 | ||
| ||
|
> 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: 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 --- 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: > > MOV R10, #0400h > _i2cR2: > CMPD1 R10, #0h > JMPR cc_EQ, _i2cR2a > JNB MRST,_i2cR2 > _i2cR2a: > 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 | ||
Antwort schreiben Antworten: | ||