Für dieses Forum muß Javascript im Browser aktiviert werden!
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é, > 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: > <code> > > 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 > } > > </code> > > Ist das korrekt? > Auch ein Funktionscapture müste dann gehen. > Ist das auch korrekt? > > Gruß Rolf
