> 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.
Lies doch bitte endlich das Datenblatt des PCF8574 komplett durch !
Es gibt keinen getrennten Schreib und lese Modus beim PCF8574 !!
Wenn Du z.B. 0xF2 an den PCF8574 schreibst, und dann die Portzustände
wieder zurücklist, erhälst Du wieder 0xF2 und nicht 0xFF.
Darum heiÃ?t der Baustein auch "quasi-bidirektional"
Ein normaler I/O kennt 3 Zustände(Eingang, Low und High)
Beim PCF8574 gibt's nur zwei (High=Eingang. max. mit 100µA belastbar und
Low max 20mA belastbar)
Ist ein Port des PCF8574 auf High-Pegel, so kann man ihn als Eingang verwenden.
Darum verstehe ich nicht, warum Du meinst, daÃ? RS auf high stehen soll,
wenn man den Baustein abfragt.
> 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.
Falsch.
Die Ausführung im 4-Bit-Mode ist genauso lang wie im 8-Bit-Mode.
Die "Execution-Time" wird immer ab der Enable-Low-Flanke gerechnet.
Im 4-Bit-Mode gilt dies jeweils ab dem zweiten Nibble.
> 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.
Der Code sollte nur zeigen, wie man ein Nibble vom LCD-liest.
Das zweite Nibble sieht schlieÃ?lich genauso aus, nur, daÃ? nicht in die
Variable BF geschrieben wird.
> 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..
Stimmt absolut nicht !
Hier gibt es keinerlei Probleme !!
Beim PCF8574 können die 8 Ports einzeln als Ein- oder Ausgang verwendet werden !
> 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.
Falsch. Im high-Pegel kann der PCF8574 nicht mehr als 100µA treiben.
Ein Pull-Down würde bedeuten, da� der Port für immer und ewig einen Low-Pegel hat.
> 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?
Indem man den Port einfach per i2c.write auf low setzt.
> 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)
Ich sag nur wieder: Das Datenblatt des PCF8574 komplett durchlesen !
> > 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)
Der Overhead ist gering, aber total unnötig.
Und nebenbei wird das Programm bei jedem zusätzlichen Parameter
um ein bis zwei unnötige VM-Words grö�er.
> In diesem Beispiel sperren sich die Treads gegenseitig aus.
Warum denn das. Das Beispiel sollten nur kurze Segmente aus zwei Threads sein.
gecaptured wird nur während der Ausgabe.
> 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.
Ã?hh. Das ist irgendwie komplett daneben.
Meinst Du ich programmiere nur Mist !!???
Ich habe schon einige grö�ere Projekte realisiert, bei denen der I²C-Bus
ausgiebig von von mehreren Threads genutzt wird. U.a. auch Displays am Bus.
Und um das noch deutlicher zu sagen:
Ich verwende die CC2 beruflich, und bin kein Hobbybastler.
Das einzige, wo es momentan Probleme geben könnte, wäre bei der Displaybeleuchtung,
da es hier nur eine Variable zum Zwischenspeichern gibt.
> > 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..
Da zeigt es wieder wie naiv (sorry, das muÃ? sein) Du von anderen denkst.
Ich verwende wahrscheinlich Multithreading in viel komplexeren Projekten
als Du. Damit meine ich nicht ein paar wenige Threads, sondern bis zu 100 Threads
in einem Projekt. (Diese haben teilw. 120kB VM-Code und auch einiges an ASM-Routinen.)
Ich fasse dies als direkte Beleidigung Deinerseits auf, da Du sozusagen
hier im Forum öffentlich schreibst, ich verstünde nichts vom Programmieren
oder von Hardware !
Fakt ist wahrscheinlich eher, daÃ? Du so gut wie nichts von der CC2 weiÃ?t
und auch mit Hardware wenig am Hut hast, oder Dich zumindest weigerst
Datenblätter genau zu lesen.(zwecks PCF8574)
> 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.
Auch das muÃ? ich dementieren.
Ich habe bis jetzt ca. 40 versch. LCD-Typen (alle HD44780 & kompatibel)
am PCF-LCD-Interface gehabt. Und es gab noch nie Probleme.
Das liegt besonders daran, daÃ? die Werte mit fallender Flanke an Enable
übernommen werden.
Nur, wenn zwischen Lesen und Schreiben am Display gewechselt wird,
muÃ? Enable auf low sein.
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 2:14)Re: Init LCD in lcdext vs. pcflcd (von Rolf - 23.08.2003 13:27)