Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - FAQ - Zum CC1-Forum - Zum CC-Pro-Forum

Wichtig: Bevor Du wegen einem Problem mit der CC2 postest, stelle sicher, daß Du
die neueste OS-Version, die neuseste Compiler-DLL und die neuesten Modulversionen benutzt!
Beachte, daß sich auf der CD zur CC2-Unit/Station auch jetzt noch die ältesten Dateien befinden!
Es gelten folgende Anleitung und Regeln: Regeln CC2Net.de-Forum
Zurück zum Artikel  (Blaue Felder sind Pflichtfelder)


Name:   UserID: 
 E-Mail:
Kategorie
Betreff
Homepage:
Link-Titel:
Link-URL:
Cookie für Name, UserID, E-Mail, Homepage-URL setzen
(Erspart die Neueingabe bei Beiträgen und Antworten)
(Zum Löschen des Cookies hier klicken)
Ich nutze:
C-Control II Unit
C164CI-Controllerboard
C-Control II Station
CCRP5 mit CC2-Unit (Conrad Roboter)
CC2-Application-Board
CC2-StarterBoard
CC2-ReglerBoard
eigenes Board
original OS     OSOPT_V2     OSOPT V3.0 OSOPT V3.1

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 Rolf, > > > 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.
Dateianhang: (.gif, .png., .jpg, .zip, .rar)
max. 256kB
max. 256kB