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 Rolf, > > > > 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). > > Letzteres. Es steht im Dateikopf von lcdext.c2 unter den Versions-Infos. > > > 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. > > Nein, gibt es nicht. Ich wollte eine solche Tabelle schon für I²C-Busadressen für > die verschiedenen Bausteine/Erweiterungen erstellen, bin aber zeitlich noch nicht dazu gekommen. > So etwas für die Ports zu machen, ist keine schlechte Idee. Hier muß man natürlich alle > HW-Erweiterungen berücksichtigen.(zumindest die, für die es C2-Module gibt) > Die Frage ist nur, wo Stecke ich solche Tabellen auf meine Site hin. :-) > Aber wahrscheinlich unter "Tips & Ergänzungen" oder "Hardwarekomponenten". > > > > So "mächtig" bremst der I²C-Bus das Programm nicht aus. ... > > > > 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? > > Wenn Du ihn irgendwo erhälst, ja. > Der Vorteil lieget hier, daß der PCF8575 für 16bit nur eine Adresse belegt. > Dann mußt Du ihn noch löten. Der PCF8575 ist nämlich nur in µSOP (RM 0,65mm) > erhältlich. Ich habe schon ein paar µSOPs gelötet. Da geht viel Zeit drauf ... > Ich werde vorrausichtlich in wenigen Tagen einen anderen 16Bit-Portexpander im Sortiment haben: > Den Maxim MAX7311CWI (Wide-SO, RM1,27 mm). > Mit dem MAX7311 kann man maximal <b>64</b> verschiedene Adressen am Bus belegen. > (kein Schreibfehler) > Somit hätte man bis zu 1024 echte I/Os extra, wenn man 64 Sück davon am > Bus betreibt. (Man benötigt dann aber ein paar I²C-Extender oder Bus-Puffer(P82B96, den > werd ich vorraussichtlich ab nächster Woche anbieten können) > > > 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? > > Das stimmt. > Wenn Du nur 16 Ausgänge benötigst, reicht auch ein SAA1064. Es ist zwar > ein 7-Segment LED-Treiber, jedoch arbeitet dieser prächtig im > CC2Net-RAM-Interface I²C und im CC2Net-RAM-Device HS. > Da Du ja bereits ein CC2Net-RAM-Interface I²C hast, kannst Du dieses > dafür wunderbar verwenden. Die Pins D0 bis D7 für den Datenbus und A0 bis A15 > für den Adressbus. A16, CS1 bis CS4, WE sind die Ports P.0 bis P.5 des zweiten > PCF8574 auf der Platine. (P.6 und P.7 sind an der 4pol. Stiftleiste herausgeführt.) > > > > 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.... > Nö, der Quellcode war von Anfang an dabei, eben nur in einer ZIP in der ZIP. :-) > > > > Lahm ist das Display am I²C-Bus sicher nicht. ... > > 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. > > > > > 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. > > SR sind so primitiv, daß praktisch nichts schiefgehen kann. Nur sollten die Leitunegn nicht > zu lang sein, wenn man mit ASM arbeitet. > Ein Beispiel für die Geschwindigkeit beim CC2Net-RAM-Device mit ASM-Treiber: > Das Interface I²C schafft ca. 1kB/s . > Das Interface Ports ca. 6,5kB/s . Hier werden 21Bit über 3 Schieberregister geschoben. > Mit Latches kann man auch arbeiten. Aber um das bidirektional hinzubekommen > benötigt man schon einiges an Ports. :-) > (8-Bit Daten-/Adress-Bus, Chipselect(LE) pro Latch, Read/Write(OE) pro Latch(wenn bi)) > > Ich bin auch gerade dabei ein einfaches und günstiges (passives) Interface für 128x64 > Grafik-Display zu entwickeln(samt Treiber). Hier verwende ich drei SR, zwei mit Ausgängen(16Bit) > und eines mit Eingängen(8Bit), da Daten vom Display zurückgelesen werden müssen. > Das Ganze wird dann 4 oder 5 I/Os der CC2 belegen. (Ich muß noch schauen, ob ich > den einen Port sparen kann) > > > > 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 > > Dafür gibt es schließlich Captures :-) > Außerdem wird das Busy-flag des Display garnicht abgefragt, da die Ausführungszeiten > des HD44780 (und komaptibel) bekannt sind. > In vielen "Anwendungen" ist es üblich, für mehrere Komponenten einen gemeinsamen > Datenbus zu verwenden. Beim PC sei hier einmal der ISA(wer ihn noch kennt *grins*) oder > der PCI-Bus genannt. > Außerdem betreibe ich selbst so ein Portsharing mit dem ext. LCD. > Und zwar beim CC2Net-RAM-Interface Ports. Und das funzt dank ASM-Treiber > für LCD und RAM-Interface sogar ohne Captures. > > > 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... > Das ist nicht so wild. Das Modul sfr.c2 nimmt Dir hier viel Arbeit ab. > > >. 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. > > Nein. Die AD-Ports können auch als Ports konfiguriert werden und auch > so genutzt werden. Jedoch nur als Eingänge. Darum habe ich sie nicht genannt. > > > Welche von beiden Lösungen V1 oder V2 würdest Du jetzt bevorzugen und warum? > > Die Lösung mit den Latches wäre hier sicher die bessere, weil schneller (zumindest in ASM). > Andererseits wären so eben quasi alle Ports verbraucht, womit dann doch die I²C-Variante > Ihren Vorteil hätte. > Hier kann ein Mittelweg genommen werden: Für den Datenbus ein PCF8574 > und für den Adressbus die Latches. > Der Vorteil wäre hier, daß man beim sequentiellen Lesen oder Schreiben nurnoch > einmal den PCF8574 adressieren müsste und dann solange mit i2c.write() schreibt > bzw. mit i2c.read() liest, solange der Vorgang dauert. > So ist es auch beim CC2Net-RAM-Interface Ports, eben nur mit SR. Und ich schaffe > damit 6,5kB/s . (Als Peakwert einmal sogar 6,9kB/s) > Bei Deiner Anwendung mit den Latches und ASM lässt sich das sicher auf ca. 10kB/s > erhöhen. Eine reine Latch-Version könnte hier in ASM sicher noch einiges mehr schaffen. > > MfG André H.
