www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SCL Takt generieren


Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Community!

Ich möchte mit eine 8051er, den ich mit 25MhZ takte, einen
SCL-Takt von 400 kBit/s erzeugen.


Am liebsten würde ich einen Timer benutzen der mir dieses Signal 
erzeugt.


Ist es überhaupt möglich mit einem µC einen solchen Takt zu erzeugen?

Wenn Ja!

Wie?

Welchen Timer soll ich benutzen und was für einstellwerte?

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat keiner ne Idee???

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinst du für SPI? Oder einen Ausgangspin mit 400khz erzeugen?
Für SPI würde Vorteiler 64 hinkommen, da hast du dannn 390625 Baud.
Als Timer könntest du einen ohne Prescaler mit Compareinterrupt nehmen 
und den bei 62 oder 63 (62,5) auslösen lassen. Weiß aber nicht, ob der 
8051 sowas hat.
Oder habe ich die Frage jetzt falsch verstanden?

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denk' schon, denn SCL ist die typ. Bezeichnung für die Taktleitung 
des I2C.

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Blöd, stimmt ja, SPI ist SCK. Das macht das ganze dann komplizierter.

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe jetzt kein brauchbares 8051 Datenblatt gefunden, aber nach dem 
Mega8 Datenblatt (falls das übertragbar ist) muss der Vorteiler auf 1 
und das Bitratenregister auf 6. Dannn kommt man auch auf 390625 Baud.
Ansonsten im passenden Datenblatt nachlesen und entsprechend umformen.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Danke für euere Antworten.

Ich meinte Natürlich SCL für I2C.

Aus RN habe ich den folgenden Eintrag gelesen:

Dabei betrug die Übertragungsrate nur 100 kBit/s bei einer zulässigen 
Bus-Kapazität von 400 pF. Den ständig steigenden Leistungsanforderungen 
folgend, wurde die Übertragungsrate 1992 und 1998 auf 400 kBit/s bzw. 
3,4 Mbit/s angehoben.

Nun wollte ich wissen wie man dies mit µC erreichen kann.

Muss vielleicht ein anderer her der mit 1GHZ getaktet wird??

Also wenn ich nur den Port P0.0 toggle komm ich auf 6µs/Bit.

Wenn ich den X2 einschalte, d.h. 6 Maschinenzyklen anstatt 12 komm ich 
auf 1,4µs/Bit aber irgendwie hab ich den verdacht, dass das einen 
Nachteil hat.

Autor: MC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das maximale Taktsignal, dass du bei 25MHz@X2 bekommen kannst, beträgt 
ca. 2MHz. Dann ist der µC aber voll beschäftigt. Da du aber nur 
400kBit/s möchtest, solltest du das locker hinbekommen.
Da du den X2-Mode erwähnt hast, vermute ich, dass du ein ATMEL-8051er 
hast. Nenn doch mal bitte den Typ, dann kann man wahrscheinlich was mit 
dem Timer2 basteln, da der ein Taktsignal generieren kann.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MC

Es handelt sich konkret um den AT89C51ED2.

Autor: Klaus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@MC

>Also wenn ich nur den Port P0.0 toggle komm ich auf 6µs/Bit.
Muss mich Korrigieren es sind 1.4µs bei X2.

Autor: MC (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang ist das Datenblatt des Controllers. Schau dir mal den Timer2 
an (Kapitel 12 im Datasheet; Kap. 12.2 ist Timer2 als Taktgenerator).
Der kann einen einstellbaren externen Takt generieren. Die I²C 
Kommunikation kannst du, wenn du den Takt hast, problemlos in die 
Interrupt-Service-Routine des Timer2 setzen.
Ich hoffe, dass hilft dir weiter.

Autor: Klaus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@MC

Nochmal die Aufzeichnung des Ports P1.0 mit X2 Mode

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MC

Danke für deine Hilfe, werd ich mir gleich mal reinziehen.

Gute Nacht.

Autor: MC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Also wenn ich nur den Port P0.0 toggle komm ich auf 6µs/Bit.
>Muss mich Korrigieren es sind 1.4µs bei X2.
In welcher Sprache programmierst du? Ich bin von Assembler ausgegangen, 
wobei ich die Werte nur überschlagen habe. Außerdem ist der Wert relativ 
uninteressant, da 1,4µs immerhin noch der Periodendauer von 714kHz 
entsprechen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bevor man in irgendeinen Geschwindigkeitsrausch verfällt, sollte man 
erstmal hinterfragen wozu das nütze ist.

Wenn Dein I2C bei 100kHz schon nur 1..5% der CPU-Last ausmacht, dann 
merkt man eine Erhöhung kaum.

Und in den meisten Anwendungen ist I2C Daten schaufeln nicht die 
Hauptaufgabe, sondern die CPU hat auch noch anderes zu tun (rechnen 
usw.).

So mal über I2C ein LCD auszugeben, Relais zu schalten oder Kontakte 
abzufragen, dazu brauchts keine 400kHz, das sind alles langsame Sachen.


Peter

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter
Im Prinzip hast Du recht aber ich will eben die 400kHz erreichen 
Interesser halber und weil es mich reizt.

Ich habe ein Grafik-LCD über I2C Expander PCF5874 aber die Ausgabe ist 
mir zu langsam.
Deshalb die Idee den PCF8574 gegen einen schnelleren I/O auszutauschen 
um
die Übertragung schneller zumachen.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MC

>In welcher Sprache programmierst du?
In Assembler

> Außerdem ist der Wert relativ uninteressant, da 1,4µs immerhin noch der 
>Periodendauer von 714kHz entsprechen.
 Ja schon aber wenn man einen Timer benutzt sieht es da schon anders 
aus.
 Bei meinem ersten versuch habe ich Timer 0 benutzt und dirt den Port 
getoggelt. Da komme ich nur noch auf 166kHz.

 Aber der Tipp mit Timer 2 werde ich jetzt verfolgen.

Danke

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entschuldige bitte,

aber was soll das Ganze überhaupt?

Du musst doch nicht nur den Takt generieren, sondern auch die Daten 
ausgeben oder einlesen. Und wenn Du dann noch ein Device ansteuerst, 
dass in der Lage ist, den I2C-Datenverkehr ANZUHALTEN, indem SCL oder 
SDA auf 0 gezogen wird, dann musst Du das auch noch abtesten...

400 KHz sind 2,5 us. Bei einem normalen 8051 mit 25 MHz sind das ca. 5 
Befehle. Und das schaffst Du nicht? Könntest Du mal Dein Programm zur 
I2C-Ausgabe posten? Und sagen, welches Device am anderen Ende hängt bzw 
ob es den Datenverkehr aufhalten kann?

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolfgang

>aber was soll das Ganze überhaupt?

Nun! Mein bisheriger Treiber für die I2C  funktioniert soweit gut.


Ich will es einfach mal probieren und was soll dagegen sprechen.
Ich weiß, das ich das sog. Portstretching realisieren müsste und Tests 
einbauen.

Es gibt nun mal Bausteine die bis 400kBit/s betrieben werden können, 
warum sollte man die nur mit 100kBit/s betreiben?.

Das wäre ungefähr so als würde man Porsche besitzen aber nie schneller 
wie ein VW-Käfer fahren. ;-)

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dagegen spricht, dass Du SCL und SDA zeitlich passend aufsetzen musst. 
Wenn Du SCL mit einem Timer realisierst, wie schaffst Du es denn, die 
Daten an SDA zeitsynchron dazu auszugeben? Das ist m.E. nach so, als 
würdest Du ein Pferd am Schwanz aufzäumen.

RLC      A            ;1
MOV      SDA,C        ;2
SETB     SCL          ;1
CLR      SCL          ;1

das sind beim normalen 8051 5 Maschinenzyklen. Bei 25 MHz ergibt das ca.
416 KHz (als Minimum, ohne Warten auf die Gegenseite). Bei einem 
X2-Prozessor müsste es noch eine Ecke schneller sein. Das Ganze 8 x 
hintereinander, dann noch Start/Stop drum herum, und fertig ist die 
Byteausgabe.

Eventuell muss vor dem CLR sowieso noch ein NOP wegen der minimalen 
HIGH-Dauer von SCL.

Zeig doch mal, mit welcher Sequenz Du 100 KHz auf Deinem X2 schaffst!

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man die High-Zeit von SCL vergrößern will, kann man die Befehle
auch umschichten;

RLC      A            ;1

MOV      SDA,C        ;2
SETB     SCL          ;1
RLC      A            ;1 schon fürs nächste Bit
CLR      SCL          ;1

MOV      SDA,C        ;2
SETB     SCL          ;1
RLC      A            ;1 schon fürs nächste Bit
CLR      SCL          ;1

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus wrote:
> Ich habe ein Grafik-LCD über I2C Expander PCF5874 aber die Ausgabe ist
> mir zu langsam.

Also nach meinem Datenblatt ist der PCF8574 bei max 100kHz am Ende.

Grafik über I2C ist natürlich schnarch langsam, sowas macht man einfach 
nicht.
SPI (74HC595) ist da erheblich schneller.
Am schnellsten ist aber memory mapped IO (P0 + /WR).


Man darf nicht der CPU die Schuld geben, wenn man für etwas den falschen 
Bus auswählt.


Peter

Autor: MC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolfgang
>Das Ganze 8 x hintereinander, dann noch Start/Stop drum herum, und fertig >ist 
die Byteausgabe.
Das ist natürlich eine Möglichkeit. Du kannst das gerne auch so machen. 
Mir persönlich gefällt diese Lösung aber nicht. Ich will die jetzt nicht 
schlecht machen, aber besonders elegant ist dein Weg nicht.

>Dagegen spricht, dass Du SCL und SDA zeitlich passend aufsetzen musst. >Wenn Du 
SCL mit einem Timer realisierst, wie schaffst Du es denn, die >Daten an SDA 
zeitsynchron dazu auszugeben?
Die zeitsynchrone Ausgabe wird durch die Ausgabe innerhalb der ISR 
ralisiert. Wenn du in der ISR dein Datenbit an SDA ausgibt und dann den 
Taktzustand an SCL änderst, hast du eine Verzögerung von 1 
Maschinenzyklus. Kürzer bekommst du das ohne Trixxereien mit externen 
Gate-Bausteinen nicht hin.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

An alle Beteiligten erstmal vielen Dank für euere Unterstüzung und guter 
Kiritik.

@Wolfgang Mües

Hier mal ein Codeschnipsel meiner Routine:

Hallo!

An alle Beteiligten erstmal vielen Dank für euere Unterstüzung und guter 
Kiritik.

@Wolfgang Mües

Hier mal ein Codeschnipsel meiner Routine:

I2C_WBYTE:
  For REG3 = #0 To #7
   RLC  A
   MOV  SDA,C
   SETB SCL
   NOP
   CLR SCL
     Next
  SETB SDA
  NOP
         SETB SCL
  MOV  C,SDA
  NOP
         CLR SCL
RET

Autor: Wolfgang Mües (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,

da läßt sich wirklich nur noch durch Loop Unrolling und durch 
Codeverschränkung (NOP -> RLC A) was holen.

Und das geht bei Deinem 25 MHz 8051 nur mit 100 KHz? Wieso dass denn?
Hast Du eventuell noch Interrupts laufen, die den größten Teil der 
Rechenzeit fressen? Ich kann mir gar nicht vorstellen, dass Du 10us für 
einen Schleifendurchlauf brauchst. Da muss nochwas faul sein!

Fröhliche Ostern

Wolfgang

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang Mües wrote:
> Und das geht bei Deinem 25 MHz 8051 nur mit 100 KHz? Wieso dass denn?

Nochmal:

Das Nadelöhr ist nicht der 8051, sondern der PCF8574, der kann nur max 
100kHz!


Peter

Autor: Klaus (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

@MC
Dein Tipp mit Timer 2 war Klasse. Timer 2 als Clockout an P1.0 ohne 
Interrupt.

Ich habe jetzt mal meine Routinen für Schreiben und Lesen angepasst.

Anbei mal ein Bild, dass das Timing an einem PCF8574 zeigt, mit 
doppelter
Geschwindigkeit.
Laut Datenblat ja nur 100kHz.

Jetzt lässt sich das Timing von 100khz bis 400khz leicht einstellen und 
kann so den s.g. Fast-Modue  nutzen.

Das Aufsetzen des SDA - Signals auf den SCL-Takt ist bis 400kHz ansich 
problemlos.
Allerdings brauch ich zur Überprüfung noch einen Baustein der den 
Fast-Mode unterstützt.

Trotzdem Danke an alle für eure nützlichen Komentare.

Autor: MC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gern geschehen. Dafür sind wir ja alle hier.
Weiter noch viel Erfolg!

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm... Es ist aber allen schon klar, dass jeder Teilnehmer am Bus das 
Verhalten von SCL mitbestimmt. Der Master gibt keinen Takt vor. Er 
muss lediglich eine Mindestbreite von tHIGH und tLOW vorhalten um den 
anderen Teilnehmern Zeit zur Reaktion zu geben. Diese ziehen dann SCL so 
lange auf LOW, wie sie benötigen um SDA zu lesen oder zu schreiben. Der 
Master kann in dieser Zeit den SCL schon wieder freigeben und muss dann 
so lange warten, bis er von allen Beteiligten auch frei gegeben wurde. 
Dann wartet er die tHIGH ab und zieht SCL mit neuem SDA wieder auf LOW.

Ein I2C Teilnehmer ( egal, ob Master oder Slave) kann den Bus nicht auf 
eine bestimmte Frequenz festlegen ohne die Busspezifikation zu 
verletzen. Er kann nur im optimalen Fall so schnell sein, wie die MIN 
Angaben der Spec vorgeben. Ist jedoch ein einziger langsamerer Baustein 
am Bus, so wird zumindest die Addressierung entscheident verlangsamt. 
Bei dieser hört nämlich auch der langsame Baustein zu und bremst durch 
das ziehen von SCL den Bus aus. Erst wenn er merkt, dass er nicht 
adressiert wurde, kann er sich abklemmen und damit den restlichen 
Bausteinen eine schnellere Kommunikation ermöglichen.

Bei 'intelligenten' Busteilnehmern stellt sich oft keine konstante 
Bitrate ein, sondern sie schwankt, weil die CPU dieser Teilnehmer, die 
I2C auch nur emuliert, unterschiedliche Zeiten benötigt, mit den Daten 
etwas zu machen. Oft kann man auch beobachten, dass bei steigender 
Bitrate die Pausenzeiten zwischen den Bytes oder Sequenzen steigen. Da 
ist es dann eine Frage, ob man wirklich die volle Bitrate ausnutzt, 
dafür aber einige Software darauf verwenden muss zu erkennen, wann der 
Partner wieder bereit ist neue Kommandos zu empfangen.

Gruß, Ulrich

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ulrich P

>Der Master gibt keinen Takt vor. Er
>muss lediglich eine Mindestbreite von tHIGH und tLOW vorhalten um den
>anderen Teilnehmern Zeit zur Reaktion zu geben. Diese ziehen dann SCL so
>lange auf LOW, wie sie benötigen um SDA zu lesen oder zu schreiben.

Also das mit dem SCL auf LOW ziehen leuchtet mir jetzt nicht ein, wär 
mir jetzt neu.
Ich habe dieses verhalten aus dem Datenblatt nicht herauslesen können.
Wenn ich es richtig Verstanden habe muss der Master den Takt erzeugen 
und die Zeiten zum Lesen und Schreiben tHIGH / tLOW  einhalten.

Gruß
Klaus

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ja und nein. Es gibt in der Spec etwas Kleingedrucktes:
http://www.standardics.nxp.com/support/documents/i...
Seite 38 Anmerkung [4]:
... This maximum must only be met if the device does not stretch the LOW 
period (tLOW) of the SCL signal. If
the clock stretches the SCL, the data must be valid by the set-up time 
before it releases the clock.

Wenn also der Partner nicht durchdacht programmiert wurde, dann muss der 
Master aktiv den Takt gestalten. Wenn man es aber richtig macht, dann 
liest der Slave das Bit bei steigender Flanke ein und zieht SCL auf low. 
Ist der Slave sehr schnell muss er ggf. hier die tHIGH abwarten. Diese 
Aussage basiert darauf, dass tHD:DAT mit min=0 angegeben ist auf Seite 
37.

Der Master erkennt an SCL low, dass das Bit verarbeitet wurde und kann 
nun seinerseits das nächste Bit auf SDA ausgeben und nach einer 
Haltezeit von tSU:DAT SCL wieder freigeben. Hier kann es sein, dass der 
Slave noch busy ist und SCL noch weiter auf LOW hält. Daher wartet der 
Master einfach so lange, bis er ein SCL=HIGH erkennt, bevor das Ganze 
wieder von vorne los geht.

Auf diese Art kann jeder Busteilnehmer das Protokoll bremsen, wie es 
nötig ist. Die Bremse kann Bitweise ( Bit-Stretching) und Byteweise ( 
Ack-Stretching) erfolgen.

Bei Sequenz-gesteuerten Systemen, wo ein Master einem Slave ein 
komplettes Kommando überträgt und dann die Ausführung erwartet, gibt es 
noch eine andere Möglichkeit, das ACK-Polling. Hier kann man die Bits/ 
Bytes i.d.R. sehr schnell übertragen, weil der Partner erst die 
komplette Sequenz benötigt, bevor er was tun kann. Danach, also mit dem 
STOP beginnt er zu arbeiten und kann vorübergehend nicht mehr auf den 
I2C hören. Dafür klemmt er sich vom Bus ab. Sendet der Master nun erneut 
die Adresse des Beschäftigten Teilnehmers, stellt der sich tot und der 
Master erhält kein ACK nach der Adresse. Das wiederholt der Master so 
lange, bis der Slave wieder aufpassen kann. Die Zeit, über die wir hier 
reden ist im I2C Datenblatt als verlängerte tBUF zu verstehen.

Diese Methode bewährt sich vor allem bei EEPROMs, da diese in der ersten 
Zeit beim Schreiben und beim Lesen immer viel schneller sind, als die 
Angaben in den Datenblättern für tBUF. Erst mit der Zeit brauchen 
mehrfach reprogrammierte Zellen mehr Zeit zum Löschen und neu 
Beschreiben.
Anstatt nun fest 10ms Pause zwischen zwei Zugriffen einzubauen, nutzt 
man ACK-Polling.

Gruß, Ulrich

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:
> Wenn also der Partner nicht durchdacht programmiert wurde, dann muss der
> Master aktiv den Takt gestalten. Wenn man es aber richtig macht, dann
> liest der Slave das Bit bei steigender Flanke ein und zieht SCL auf low.
> Ist der Slave sehr schnell muss er ggf. hier die tHIGH abwarten. Diese
> Aussage basiert darauf, dass tHD:DAT mit min=0 angegeben ist auf Seite
> 37.

Da hast du wohl etwas falsch Verstanden, der Master generiert den Takt, 
der Slave kann den mittels clock stretching bremsen.

Wie soll der Slave in deiner Variante herausfinden wann er SCL wieder 
freigeben soll?
Zudem wird dadurch tHIGH von SCL verletzt.

Cheers, Roger

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das SCL-Stretching machen in der Regel nur I2C in nem Controller, da ja 
dort gewartet werden muß, bis der Interrupt abgearbeitet ist. Ausnahme 
beim PIC, wenn da der Interrupt nicht schnell genug ist, Pech gehabt.


Bei I2C-Peripherie ist das nicht nötig und der SCL ist nur Eingang. Aber 
da sind mir auch nur max 100kHz bekannt.


Was stört Dich denn an SPI?

Da sind 20MHz keine Problem und die Chips (74HC595) sind auch wesentlich 
billiger.


Peter

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger

>Was stört Dich denn an SPI?
An sich nichts. Da ich mich ja erst mit I2C beschäftigen wollte.

>Da sind 20MHz keine Problem und die Chips (74HC595) sind auch wesentlich
>billiger.

Nun das ist ein Argument um der Sache mal nach zu gehen.
Werd mir mal Datenblat besorgen gehen.


Danke für den Tipp!


gruß Klaus

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Hab mal nach Datenblatt und Vefügbarkeit des 74HC595 geschaut.

Tja! Leider scheint es keine SMD Bauteile zu geben weder beim Grossen 
C...  noch beim R.... zugeben.

Wo bekommt man nun eine brauchbares SPI-protokoll her für nen 8051er um 
es zu Studieren.

Autor: MC (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dein Controller hat hardwaremäßig eine SPI integriert. Die musst du nur 
noch initialisieren und dann ähnlich wie bei dem UART deine Daten nur 
noch ein ein Sende-Register schreiben bzw. aus einem Empfangsregister 
laden.
Das findest du im Datenblatt im Kap. 16 ab Seite 63.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roger Steiner wrote:

> Wie soll der Slave in deiner Variante herausfinden wann er SCL wieder
> freigeben soll?
> Zudem wird dadurch tHIGH von SCL verletzt.
>
tHIGH ist auch nur eine Minimal-Angabe. Nach Einhaltung der tHIGH kann 
der Slave SCL ziehen, der Master kann es aber auch und der Slave kann 
zusätzlich innerhalb der tHD:DAT auch SCL auf LOW klemmen um ein 
nachfolgendes HIGH abzubremsen, also tLOW verlängern.

Bei in Hardware gegossenen Systemen ist mir bislang auch nur ein 
ACK-Stretching bzw. ein verlängertes tBUF untergekommen. Allerdings wird 
I2C auch gerne für diese Hybrid-LCDs oder ähnliche Displays genutzt, bei 
denen I2C erst seid kurzem in Hardware des Controllers gelöst ist. Viele 
ältere Displays nutzen einen Software-I2C weil es da entsprechende 
Controller noch nicht gab. Hier ist es leider nicht so durchsichtig, wie 
man die optimale Geschwindigkeit erreichen kann und wer da optimaler 
weise an welchem Bussignal ziehen und drücken sollte. Da hilft leider 
nur experimentieren.

Gruß, Ulrich

Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:
> Nach Einhaltung der tHIGH kann der Slave SCL ziehen, der Master kann es aber 
auch ...

Nein, der Slave darf erst an SCL ziehen wenn der Master SCL auf low 
gezogen hat. Nochmals: Wie soll der Slave wissen, wann er SCL wieder 
freigeben kann.

In einem konformen I2C System ist tHIGH vom schnellsten Master und tLOW 
vom langsamsten device bestimmt.

Zudem bringt dein Ansatz neben Problemen keinerlei Durchsatzsteigerung 
wenn der Master sowieso auf die max. Frequenz des gewaehlten I2C modes 
konfiguriert ist.

> Viele
> ältere Displays nutzen einen Software-I2C weil es da entsprechende
> Controller noch nicht gab.

HD44780 kompatible LCDs von Philips hatten schon vor ueber 10 Jahren I2C 
im Controller in Hardware implementiert.

> Hier ist es leider nicht so durchsichtig, wie
> man die optimale Geschwindigkeit erreichen kann und wer da optimaler
> weise an welchem Bussignal ziehen und drücken sollte. Da hilft leider
> nur experimentieren.

Absoluter Kaese!

Cheers, Roger

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus wrote:
> Wo bekommt man nun eine brauchbares SPI-protokoll her für nen 8051er um
> es zu Studieren.

http://www.atmel.com/dyn/resources/prod_documents/...


Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.