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();
und dann BF einlesen...
i2c.cstart(PCF or 65);
if i2c.readlast() > 0x7F warten; //BF ist 1, Display noch nicht fertig
i2c.stop();
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.
1.Ist es möglich, das BF-Flag mit dem PCF-Modul auszulesen und wenn ja, wie?
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?
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)
4.Wenn es nicht möglich wäre, das BF-Flag einzulesen, warum ist es dann verschaltet?
Dann, zum Treiber:
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.
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. Also So:
byte globalcapture;
function abc()
{
capture globalcapture // <--- setzt globalcapture
i2c.cstart(addr); // <--- setzt ic2.capture
i2c.write();
i2c.stop(); // <--- löscht ic2.capture
release; // <--- löscht globalcapture
}
Ist das korrekt?
Auch ein Funktionscapture mĂĽste dann gehen.
Ist das auch korrekt?
GruĂ? Rolf
Antwort schreiben
Antworten:
Re: Init LCD in lcdext vs. pcflcd (von André H. - 22.08.2003 16:54)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)