> ich hab noch mehr Fragen zum pcflcd-Modul bzw. desen Treiber.
>
> Wenn ich das BF-Flag auslesen möchte, müste ich zunächst den pcf so aufsetzen, das er auf der RS=0 und
> RW=1 ist. Also so etwa...
> i2c.cstart(PCF or 64);
> i2c.write(0x2);
> i2c.stop();
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.
Also müssen die Ports, die Du als Eingang benutzen willst, einen High-Pegel
besitzen. Sonst steigt der Stromverbrauch "etwas". :-)
Somit muÃ? der Baustein auf 0xF2 gesetzt werden.
> und dann BF einlesen...
>
> i2c.cstart(PCF or 65);
> if i2c.readlast() > 0x7F warten; //BF ist 1, Display noch nicht fertig
> i2c.stop();
Das geht auch, aber
if i2c.readlast() and 0x80 ...
wäre besser. (da übersichtlicher)
> 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.
> 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.
> 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.
> 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.
> 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.
> 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. :-)
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;
Ich finde diese Variante besser, als wenn man bei jedem Befehl
einen Parameter übergeben mu�.
AuÃ?erdem kann man so sogar ohne Probleme mit mehreren Thread
auf das selbe Display zugreifen. (Obwohl ich das nicht unbedingt empfehle :-) )
Man könnte das ganze auch noch vereinfachen, wenn man
für das Capturing eine eigene Fuktion bildet:
function CapPCFlcd(byte PCF)
{
capture var.pcflcdflag;
pcflcd.setpcf(PCF)
}
Jedoch darf man nicht vergessen, das release zu setzen. :-)
> Dann wollte ich noch wissen, wie sich das genau mit i2c.cstart und Captures verhält.
> Das Handbuch zur cc2 sagt definitiv, nur ein Capture pro Funktion.
> Mit i2c.cstart setze ich ein Capture.. allerdings eines das nich das System selbst verwaltet.
> Demnach müste ich ja die Möglichkeit haben, zusätzlich zu dem Capture des i2c-Bus noch ein Capture pro
> Funktion zu setzen.
Darum habe ich die erweiterten 16 Captures(Modul cap.c2) und das (17.) I²C-Capture geschaffen.
All diese Captures können nach belieben verschachtelt werden, und sind
vom Capture des Betriebssystems 100%ig unabhängig.
Man hat so, mit dem oiginal Capture, bis zu 18 "Capture-Ebenen". :-)
> Ist das korrekt?
Ja.
> Auch ein Funktionscapture müste dann gehen.
> Ist das auch korrekt?
Du meinst das Implizite Capture ?
Das sollte gehen.
MfG André H.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: Init LCD in lcdext vs. pcflcd (von Rolf - 23.08.2003 17:16)Re: Init LCD in lcdext vs. pcflcd (von Rolf - 22.08.2003 23:02)Re: Init LCD in lcdext vs. pcflcd (von André H. - 23.08.2003 0:50)Re: Init LCD in lcdext vs. pcflcd (von Rolf - 23.08.2003 2:14)Re: Init LCD in lcdext vs. pcflcd (von Rolf - 23.08.2003 13:27)Re: Init LCD in lcdext vs. pcflcd (von Rolf - 23.08.2003 0:43)