> > 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.
Antwort schreiben
Antworten:
Re: 82c55 an C2 Ports (von Chokr - 27.10.2008 16:40)Re: 82c55 an C2 Ports (von André H. - 7.08.2003 16:24)