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?
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?
Ich denk' schon, denn SCL ist die typ. Bezeichnung für die Taktleitung des I2C.
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.
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.
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.
Angehängte Dateien:
-
Aufzeichnen.PNG
4,9 KB
@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.
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.
>>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.
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
@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.
@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
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?
@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. ;-)
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!
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
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
@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.
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
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
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
Angehängte Dateien:
-
Aufzeichnen2.PNG
5,1 KB
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.
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
@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
Hi! Ja und nein. Es gibt in der Spec etwas Kleingedrucktes: http://www.standardics.nxp.com/support/documents/i2c/pdf/i2c.bus.specification.pdf 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
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
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
@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
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.
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.
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
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
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/doc4348.pdf Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.