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 André > > > Kommen wir zuerst zum Datenblatt des PCF8574. > > Der PCF8574 ist ein quasi-bidirektionaler Baustein. > > D.h. er kennt nur zwei Zustände: Low und High. > > Dabei ist der High-Pegel gleichzeitig Eingang, da die Ausgänge Open-Drain > > sind und eine 100µA Konstantstromquelle für den nötigen Pull-Up sorgt. > > Sehe ich auch so.... > > > > In dem Augenblick wo ich 0x2 auf das PCF schreibe, beginnt aber auf den Datenleitungen ein Kurzschluß > > > weil beide Bausteine zu diesem Zeitpunkt als Ausgang laufen. Dieser Kurzschluß wird erst behoben wenn > > > der PCF in den Lesemodus geschaltet wird wobei dann die RS und RW-Leitungen hochohmig werden dürften. > > > Beim zurückschalten des Displays auf Schreibbetrieb passiert etwas ähnliches. > > > > Das passiert wie gesagt nur, wenn die Ports, die als eingänge genutzt werden sollen, > > vorher keinen High-Pegel besitzen. > > Das Display hat aber ggf. auf dem Datenbus beim lesen D4-D7 Lowpegel, damit wäre ein Kurzschluß > durchaus denkbar. Jedoch wäre der auf 100µA begrenzt, was das Display und der PCF aushalten müste. > Da hast Du sicher recht. > > Jedoch ist zum Zeitpunkt des Einlesens die Information für RS und R/W beides logisch 1 (durch eben dieses > verhalten beim Lesen des PCF so das also letztlich der Low Pegel für RS nicht zustande kommt. > Dadurch wird aus dem Leseversuch von CGRAM / DDRAM Addr bzw. BF immer ein Leseversuch des DDRAM. > An die Info von BF und CGRAM / DDRAM Addr komme ich aber damit so nicht. > Ursache dafür ist wie gesagt der Umstand, das beim Lesen die Pullups des PCF aktiv sind. > Es hat also relativ wenig damit zu tun, welchen Pegel die Ports vorher hatten da zum Zeitpunkt des Leseversuchs > RS auf 1 "gepullt" und das falsche Register gelesen wird. > > > > 1.Ist es möglich, das BF-Flag mit dem PCF-Modul auszulesen und wenn ja, wie? > > > > Es ist möglich: > > > > i2c.cstart(addr); > > i2c.write(0xF2); > > i2c.write(0xF6); > > i2c.stop(); > > i2c.cstart(addr or 1); > > BF= (i2c.readlast() and 0x80)!=0; > > i2c.stop(); > > i2c.cstart(addr); > > i2c.write(0xF2); > > i2c.write(0xF0); > > i2c.stop(); > > > > Jedoch benötigt man das BF i.d.R. nicht, da die Ansteuerung über I²C > > langsam genug ist. Und bei Clear und Home kennt man schließlich die nötigen > > Wartezeiten. > > Genau das möchte ich überprüfen und deshalb interessiert mich das BF-Flag. > Ich habe aus diversen Publikationen entnommen, das im 4-Bit Modus die Verarbeitungszeiten höher sind > als im 8-Bit-Modus und bis zu 4 ms dauern können bis BF wieder 0 ist. Ausserdem habe ich gelesen, > das auch andere Befehle als Clear und Home bedeutend länger brauchen sollen. Um das zu prüfen will > ich an das Flag. > > Zu Deinem Codesegment, man müste wohl 2 Nibble lesen damit das Display nicht aus dem 4-Bit-Tritt kommt. > Wenn ich das richtig erkenne, liest Du dort nur ein Nibble. Das nur nebenbei. > Das Problem des RS-Bits und damit der Zugang zu BF ist mit dem Codesegemet aber noch nicht gelöst, > da zum Zeitpunkt des Einlesens das falsche Register gelesen wird.. > > > > 2.Müsten dazu in die Datenleitung nicht Widerstände von min. 10 K damit der Kurzschluß nicht das Display > > > oder den PCF zerstört? > > > > Nein, das setzen von Widerständen ist nicht möglich, da die meisten Displays > > Pull-Ups besitzen, und dies dann eher störend auf die Datenübertragung wirkt. > > (Habe ich damals ausprobiert) > > Zum Trost: Daß der PCF8574 davon zerstört werden kann, ist eher unwahrscheilich. > > Und die meisten Display halten auch kurze Kurzschlüsse aus. > > (zumindest bei denen mir das schon bei Versuchsaufbauten passiert ist. > > Hat sich geklärt, siehe oben die 100µA-Geschichte. > > > > 3.Müste an die RS-Leitungnicht nicht ein Pulldown und an die RW-Leitung nicht ein Pullup damit im hochohmigen > > > Lese-Zustand die Signale für RS und RW nicht verloren gehen? > > > (dann wäre es auch nicht nötig, den Baustein vorher mit 0x2 zu setzen) > > > > Das macht keinen Sinn. > > Bei einem Pull-Down an einer Leitung könnte man nie RS=1 setzen. (Datenplatt PCF8574) > > Und da man die Ports eines PCF8574 einzeln als Ein- und Ausgänge benutzen kann, > > macht es keinen Sinn. > > Da bin ich noch nicht mit einverstanden. > Ein passender Pulldown, der in der Lage ist, die 100µA auf 0-Pegel zu ziehen (schätze mal 3,3K Ohm) > kann durchaus mit einem 1-Pegel und deutlich höheren Ausgangsströmen im Schreibmodus des PCF > eingesetzt werden und würde den Ausgang nur gering belasten. Der Pulldown müste ja nur dem Pullup im > PCF übersteuern, bei Ansteuerung als Ausgang fließen ja doch ggf. höhre Ströme die dann den Pulldown > egalisieren. Ich habe soetwas beim 68HC11 Prozessor schon gemacht. > > Wie auch immer - das läst sich ja austesten. Wie anders wollte man RS wärend des Lesens > und damit bei aktiven Pullups des PCF auf Pegel 0 kriegen? Genau das ist aber der Zustand > der Ports beim Einlesen über den PCF. Allerdings ließe sich dann (mit Pulldown) auch nicht mer das DDRAM > auslesen da es im Lesebetrieb nicht mehr auf 1 zu kriegen ist. (anders als im Schreibbetrieb) > > > > 4.Wenn es nicht möglich wäre, das BF-Flag einzulesen, warum ist es dann verschaltet? > > > > Pinkompatibilität zu P1L an der CC2. :-) > > Außerdem könnte schließlich jemand Daten aus dem CG- oder CC-RAM > > auslesen wollen. > > Hm... wenn ich die Wahl hätte, nur eins von beiden Registern lesen zu können, würde mich das mit BF und den > aktuellen Adressen aber mehr interessieren als der Inhalt vom Displayram - zumal genau dieses meist irgendwo > in einer Stringvariable im System vorhanden ist. > > > > Die PCF-LCD's sind gereadezu prädestiniert für den Betrieb als Anwendung mit mehrfachen LCD's. > > > Will man jedoch z.B. pro Thread ein LCD verwalten, kriegt man relativ schnell Probleme mit der selektion des > > > richtigen LCD. Ich habs ausprobiert und mir ein zweites PCF-Modul auf einem Steckboard nachgebaut. > > > Von da her wäre es nicht nur in der Init-Funktion sondern in allen Funktionen interessant, ein > > > function init (byte pcfnr) // Displaynummer > > > { > > > setpcf(pcfnr); // wird hier selektiert (ggf. auch direkt mit if.... ) > > > light=light and 8; > > > > > > auszuführen. Jeder Thread müste dann nur seine Displaynummer kennen und schon lassen sich 2 oder mehr > > > Displays bequem steuern. Das Argument zur Inkompatibilität mit lcdext kann ich nachvollziehen aber es wäre > > > sowieso unmöglich, 15 Module über lcdext zu steuern... Ein Festplattentreiber muß ja auch nicht kompatibel > > > zu einem Floppytreiber sein obwohl bei beiden die gleichen physikalischen Vorgänge ablaufen. > > > Und zudem ist es nur eine parametrische und keine funktionelle Inkompatibilität. Ich denke, das man wegen > > > der besonderen Anwendungsweise auf Parameterkompatibilität verzichten kann zumal das die Verwaltung > > > im Thread vereinfacht. Das als Vorschlag. > > > > Am Anfang wollte ich auch Adressparameter für die einzelnen Befehle vorsehen. > > Jedoch wird so alles unnötig verlangsamt. > > I.d.R gibt sendet man schließlich mehrer Befehle am Stück an ein LCD. :-) > > Das PCF-Display läuft als i2c (100 KBit) also seriell in 4 Bit Modus! Welche Rolle spielt es da, ob ein zusätzlicher > Parameter übergeben wird? Das Argument kann ich beim lcdext nachvollziehen, beim EEPROM-Treiber fand > ich es schon bedenklich aber hier im PCFLCD-Modul ist es am falschen Platz. > Der Overhead für ein zusätzlichen Parameter dürfte nur ein 10tel bis 100stel einer einzigen i2c-Operation sein. > Wenn nicht sogar noch weniger. (Wobei pro Buchstabe auf dem Display min. 4 i2c-Befehle nötig sind) > > > Deshalb muß man bei einem mehr-Display-Betrieb auch ein explizites Capture verwenden. > > (Das war mit ein Grund, für das neue I²C-Capture) > > Also z.B.: > > > > thread A: > > capture var.pcflcdflag; > > pcflcd.setpcf(0) > > pcflcd.line(1); > > pcflcd.print2(str); > > pcflcd.line(2); > > pcflcd.zahl4n1(wert); > > release; > > > > thread A: > > capture var.pcflcdflag; > > pcflcd.setpcf(1) > > pcflcd.line(1); > > pcflcd.time(0) > > pcflcd.line(2); > > pcflcd.print("Irgendetwas") > > pcflcd.line(3); > > pcflcd.date(1); > > release; > > In diesem Beispiel sperren sich die Treads gegenseitig aus. > Wenn man sich zusätzliche Tastatureingaben/Menübehandlung in den Treads vorstellt, > ist das Ergebnis katastrophal da jeweils nur ein "Terminal" benutzt werden könnte. > Man stelle sich das ganze doch mal als i2c-Hausbus mit mehreren Terminals vor. > Wärend Eingaben auf Terminal A gemacht werden, muss der Thread B warten und wenn > Tread A z.b. in einer Endlosschleife hängt weil eine Eingabe nicht abgeschlossen wurde, > (was man natürlich auch wieder mit Timern abfangen könnte) > gibts im Tread 2 keine Möglichkeit zur Datenausgabe (und ggf. weitere Dinge). > Damit kriege ich also eine ganze Anlage zum Stillstand weil ich das Multithreading > auf oberster Ebene ausgehebelt habe. Das kann es nicht sein. > > > Ich finde diese Variante besser, als wenn man bei jedem Befehl > > einen Parameter übergeben muß. > > Na die Nachteile scheinen mir gegenüber der Möglichkeit mit Displaynurmmern > zu arbeiten aber gewaltig. Das berührt aber auch schon wieder meine und Deine Ansicht > von Single/Multithreadig.. > > > Außerdem kann man so sogar ohne Probleme mit mehreren Thread > > auf das selbe Display zugreifen. (Obwohl ich das nicht unbedingt empfehle :-) ) > > Das geht auch wenn alle Threads die gleiche Displaynurmmer verwenden. > > Mir ist noch was aufgefallen was das Timing der Displays angeht. > Zwischen Pegel RS bzw. RW und steigender Flanke von E müsssen min. 40ns liegen. > Das läst sich nur erreichen wenn man nicht > > i2c.write((cmd and 0xF0) or light or 0x4);// HighNibble > i2c.write((cmd and 0xF0) or light); //Datenübername E > > sondern einen Vorlauf einbaut. > > i2c.write((cmd and 0xF0) or light); // Vorlauf > i2c.write((cmd and 0xF0) or light or 0x4);// HighNibble > i2c.write((cmd and 0xF0) or light); //Datenübername E > > Im Low Nibble ist dann schon alles korrekt gesetzt, da reicht dann ein > > i2c.write((cmd shl 4) or light or 0x4); // LowNibble > i2c.write((cmd shl 4) or light); > > Kommt jetzt ein Datenbyte für das DDRAM, hätte man das gleiche Problem dort auch. > Da das Display aber zunächst mit der Verarbeitung beschäftigt ist, kann ich den PCF > schon in den Modus für DDRAM setzen. Dann brauche ich den Aufwand später nicht mehr zu treiben > Da mehr Daten, als Steuerbytes geschrieben werden, lohnt sich diese Aufteilung auch. > > i2c.write(light or 0x1); > > Da _alle_ Kommandos scheinbar mehr Zeit benötigen _können_ , je nach dem aktuellen Vorgang im Display > sollte die Wartezeit für das Display auch in WriteCmd mit sleep gesetzt werden. 2 ms sollten ausreichen, das > würde ich aber gerne noch mit dem BF-Flag verifizieren. > > Die Funktion WriteCmd müste als Beispiel dann so aussehen: > > function WriteCmd (byte cmd) > { > i2c.cstart(PCF); > i2c.write((cmd and 0xF0) or light); > i2c.write((cmd and 0xF0) or light or 0x4);// HighNibble > i2c.write((cmd and 0xF0) or light); > i2c.write((cmd shl 4) or light or 0x4); // LowNibble > i2c.write((cmd shl 4) or light); > i2c.write(light or 0x1); > i2c.stop(); > sleep 2; //evtl auch 4 > } > > Das Timingproblem haben übrigens scheinbar alle LCD-Module. > Ich beziehe mich ausdrücklich auf die Datenblätter von Hitachi und die Werte für tAS > > Gruß Rolf >

Dateianhang: (.gif, .png., .jpg, .zip, .rar)

max. 256kB

max. 256kB