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