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 die Unit, ein App-Board und möchte ein 8255 an die Ports bringen. > > > Ich möchte mir aber so weing wie möglich Peripherie des APP-Boards "unbrauchbar" machen. > > > Jetzt sind z.B. die Ports P1H0-H3 Interuptleitungen/Counter und am P1L4-7 hängt das externe Display. > > > > Das LCD benötigt außerdem noch P1L.0, .1 & .2 . Also ist von P1L nur P1L.3 wirklich frei. > > Äh... das wuste ich nicht... damit ist die Möglichkeit des Umbaus auf P1H gestorben. > Dummerweise geht das übriges auch nicht aus irgendeiner Doku hervor... oder ich habs überlesen > (was warscheinlicher ist). > > Davon abgesehen, gibt es irgendwo eine tabellarische Übersicht, welche Ports mit welchen Funktionen > vorbelegt sind? Ich meine für die Unit selbst ist das ja noch raus zu kriegen aber ich finde die Info's immer nur > Stückchenweise. Und das APP-Boardmanual ist nicht sehr ergiebig. Wenns das noch nicht gib, versuche > ich mal sowas zu machen und Du müstest das noch mal korrigieren und dann in die Site setzen. > > > > Ich brauche für den 8255 ca 4-5 Steuerleitungen und ein 8 Bit Datenbus. Das bedeutet letztlich, > > > egal welchen Port ich verwende, ich beschneide mir immer die IO-Möglichkeiten des APP-Boards. > > > Jetzt dache ich, ich verwende ein PCF-85474 um damit weitere Leitunen per i2c zu kriegen. > > > Damit kann ich z.B. den Datenbus für den 8255 realisieren und habe die Möglichkeit, P1H4-H7 > > > und P1L0-3 als Steuerleitungen zu verwenden. Das hat aber den Nachteil, das ich ständig > > > den PCF umprogrammieren muß und da i2c nicht besonders schnell ist, bremst das mächtig. > > > > So "mächtig" bremst der I²C-Bus das Programm nicht aus. > > Man kann von ca. der halben Geschwindiglkeit wie bei den I/Os ausgehen. > > Der Vorteil am PCF8574 ist, daß es ein Quasi-Bidirektioner Baustein ist. > > D.h. Es gibt nur die Pegel low und high und keine Eingangs-und Ausgangseinstellungen > > bzw. Register dafür. Ist ein Port im Highpegel, so ist dieser gleichzeitig ein Eingang. > > (im High-Pegel ist der Strom auf 100µA begrenzt) > > Man muß beim lesen also nur einmal Sicherstellen, daß alle Ports am PCF8574 einen > > High-Pegel besitzen. (Einmal 0xFF schreiben.) > > Hm... hm... dann wäre es ja fast einfacher, wenn ich 3 PCF-Bausteine verwende denn ob ich nun 12 Byte > für eine Aktion an der Peripherie über den i2c jage oder 4 + Bausteinprogrammierung im 82c55 mit 3 Ports, > das geht sich fast gleich bzw. ist sogar vermutlich mit PCF einfacher zu lösen. > > Es gibt ja scheinbar ein i2c-16Bit PCF... würde ich den verwenden, was würde mir das bringen? > Vorausgesetzt, ich will mir 8 Datenleitungen (bi) und 16 Adressen (out) bauen. Ich denke, ich würde > gengenüber 2 8Bit-PCF ein Start- und ein Stopzyklus sparen... ist das so richtig? > > > > Also dachte ich, nimm den PCF für die Steuerleitungen, dann sind sie nur Ausgang... dann > > > habe ich aber kein zusammenhängendes Byte zum aus/eingeben der Datenleitungen. > > > Eine programmierung über Nibles wäre möglich, erhöht jedoch wider den Aufwand. > > > > Stimmt. > > Und offensichtlich kriege ich dan Trouble mit dem Display.... wegen der mir bisher noch nicht bekannten Ports. > > > > > > Eine Lösung wäre evtl. das Dsiplay auf die Ports P1H4-7 zu legen. Dazu müste ich aber > > > wohl den Treiber umschreiben (was nicht ohne weiteres geht da André den in Asm geschrieben hat > > > und der Quellcode für sys0001 scheinbar nicht offen ist) so das P1L0-7 komplett frei ist. > > > > Dann wäre aber P1H.0 bis auf einen Port komplett belegt. Es brächte also keine Vorteile. > > Außerdem: Du hast bereits den Quellcode zu sys0001.hex. In der ZIP sys0001.zip > > liegt die Datei sys0001.asm. Das ist der ganze Quellcode. :-) ) > > Äh.. ja... bin blind....sorry... kann es sein, das ich in eine alte Datei geguckt hab? > irgendwie hab ich letztens den Source nicht gesehen... aber is auch egal.... > > > > Ein i2c-Display wäre die allerletzte mögliche Lösung... allerdings wäre dann die Ausgabe wieder > > > grottenlahm und würde mir zusätzlichen Trafic auf dem i2c verschaffen.. > > > > Lahm ist das Display am I²C-Bus sicher nicht. > > Es hat ca. die 50% Geschwindigkeit des externen LCDs mit lcdext.c2 bis V2.1. > > Jedoch wird pro Zeichen 4Byte Traffic am Bus erzeugt. Das fällt aber nicht so > > sehr ins Gewicht, wenn man nicht gerade einen schnellen Counter, oder einen Scrollenden > > Text am Display anzeigen will. > > (pcflcd.c2 bekommt irgendwann auch noch eine ASM-Treiber, aber erst Im Herbst oder Winter) > > hm.. ich dachte es würde mehr bremsen... dann wäre das noch ne Alternative. Damit wären > dann alle P1L Ports frei und ohne weitere Funktion (bis auf Drucker vermutlich, aber damit kann ich leben) > Die P1H4-7 müsten dann auch frei sein. Damit kann ich dann z.B. selektieren... > Ob man dann da ein 82c55 oder besser mehrere 74hct373/573 bzw. 74hc245 dann hängt, lasse ich mal offen. > Ich würde das mal als Variante 2 bezeichnen. > Die Lösung mit mehreren PCF-Bausteinen als Variante 1. > > > > Irgenwie finde ich keine Lösung, die schnell und ohne großen Aufwand mit dem APPBoard umsetzbar ist. > > > Weis jemand Rat? > > > > Mein Tip: Setze das Display entweder auf den I²C-Bus oder benutze das SR-LCD-Interface. > > Das ist nur minimal langsamer als lcdext.c2 ab V2.2 und benötigt nur 3 statt 7(6) Ports > > für das Display. Zwei Ports können evtl. mit anderer Hardware geteilt werden. > > Von der SR-Geschichte halte ich nicht so viel. Es ist i2c ohne jeglichen Protokollrahmen und daher > etwas störanfälliger. Ich weis das es funktioniert aber es ist eben nicht mein Ding. > > > Die nächste Möglichkeit: > > Du machst aus P1L einen 8-Bit Datenbus, der gemeinsam für das LCD und den 82c55 benutzt > > wird. Für das Display werden dann noch zwei Steuerleitungen benötigt. > > (R/W kann fest auf Masse gelegt werden) > > Gibt das nicht Trouble mit dem Display - weil dann nicht mehr abgefragt werden kann ob es Ready ist. > Ergo : Buchstabensalat > > > Somit hättest Du aber nurnoch 6 Ports von P1H frei. Jedoch könntest Du RS vom Display > > mit einer Steuerleitung des Displays teilen. > > Eine weitere Möglichkeit, um an Ports zum kommen wäre, wenn Du > > z.B. den Ports der Host-Taste(P3.4), Die PLM-Ports (P8.0, P8.1, P3.6) oder > > die Frequenzports(P8.2, P8.3) benutzt. > > All diese Ports kann man auch als normale Ein-und Ausgänge benutzte. > > (Mehr dazu siehe sfr.c2 und das Handbuch zum C164CI auf der CC2-CD: c164_um_v11.pdf) > > Ich glaub, ich muß mich tatsächlich mit den Internas des C164 beschäftigen... hab ich eigentlich keine Zeit zu > aber was solls... rumfrickeln kostet auch Zeit.... Ich hab schon mal gedacht ob das mit den AD-Ports geht aber > die sind glaube ich nur gemultiplext auf ein AD-Wandler geführt... das bringt dann nichts. > > Welche von beiden Lösungen V1 oder V2 würdest Du jetzt bevorzugen und warum? > > > MfG André H.
