Ideen gesucht für schnelle Port Erweiterung

Warum verwirklichst du dann deine Vorstellung nicht einfach?
Anders wird es wohl kaum gehen. Du koenntest vielleicht noch etwas
Platz sparen indem du die Register in ein FPGA packst.

Ich wunder mich aber das du soviel Wert auf Geschwindigkeit legst.
Kannst die Daten die dann so schnell reinkommen auch schnell genug
verarbeiten?

Olaf

Hi Olaf,

"Warum verwirklichst du dann deine Vorstellung nicht einfach?"

Weil ich mir eben nicht sicher bin, und ich weis eben nicht ob es noch
viel bessere Lösungen gibt. Zudem möchte ich ja von dem eventuell
bestehendem Wissen und Erfahrungen anderer lernen, deshalb fragt man ja
auch in Foren nach, oder ? ;) Das heist ich möchte eventuell noch dazu
lernen.


"Ich wunder mich aber das du soviel Wert auf Geschwindigkeit legst.
Kannst die Daten die dann so schnell reinkommen auch schnell genug
verarbeiten?"

Die Daten werden rausgeschickt, es handelt sich also um Ausgabe Ports
ohne Eingabemöglichkeit. Es geht also nicht darum eventuell rankommende
Daten so schnell wie möglich im AVR zu verarbeiten, sondern so schnell
wie möglich die Daten des AVRs rauszubekommen. Eben damit der AVR mehr
Rechenzeit übrig hat.

Ich dachte das dieses Thema auch von allgemeinem Interesse sein
könnte.

Gruß Hagen

Schon mal an I2C-Buserweiterungen gedacht? PCFirgendwas hat IIRC doch 8
Ports, davon also 8 Stück an einen I2C-Bus, und du hast deine 64 Ports.

@Sebastian: Lies Dir Hagen's Post noch mal genau durch ;)

@Hagen: Mich würd das auch interessieren, aber erfahrung habe ich damit
leider nicht...

Ein Wiki Beitrag dazu wäre sehr schön!

das mit den latched bräuchte doch nur 3 befehle, also 3 takte.
schneller, und vor allem einfacher und billiger aufzubauen kann ich mir
kaum vorstellen (was nicht zu viel heissen soll :)

Für Einzelbitausgabe würden sich auch 74xx259 eignen.

Hi Peter

ich bin mir noch nicht so ganz im klaren wie das angeschlossen werden
soll. Will aber noch präzesieren das noch ein 32K SRAM am Bus hängt.
Somit gibt es schon einen 75hc573 als Addresslatch für den SRAM.

Also 8 74hc573 liegen mit ihren Eingängen an AD0 bis AD7. Der 3 zu 8
Dekoder liegt an AD0 bis AD2 und die Enable Eingänge an A13 bis A15.
Deren Ausgänge steuern die 8 74hc573 am LE Eingang. Nur frage ich mich
jetzt wie der RD Ausgang des AVRs dort ins Spiel kommt. Müsste man da
nicht entwerder RD statt A13 an einem Enable Eingang des 74hc238
anschließen, oder aber durch zusätzliche AND gatter die richtige Logik
erzeugen ?

Bisher habe ich 3 unterschiedliche Methoden herausgearbeitet:

A.) 8 * 74hc573 + 1 * 74hc238 zur Adressdekodierung, wie in deinem
Vorschlag

B.) 8 * 74hc295 -> adressierbares Latch + 1 * 74hc573
Die 74hc295 werden mit ihrem 1 Bit Input D jeweils an AD0 bis AD7
angeschlossen. D.h. jedes dieser 8 Latches ist für 1 Bit des 8Bit
Datenwortes zuständig. Die Adresseingänge A0-A2 dieser Latches landen
alle an den A0-A2 Ausgängen des schon eh vorhandenen 75hc573. Die LE
Eingänge dieser Latches müssen nun alle per NAND gatter an A15+WR des
AVRs.

C.) FPGA, CPLD's sind Bücher mit 7 Siegeln für mich aber denoch sehr
interessante Alternativen, allerdings ob das noch für Hobbisten machbar
ist ? Klar das diese Alternative die eleganteste wäre.

Gruß Hagen

"C.) FPGA, CPLD's sind Bücher mit 7 Siegeln für mich aber denoch sehr
interessante Alternativen, allerdings ob das noch für Hobbisten
machbar
ist ? Klar das diese Alternative die eleganteste wäre."

Das ist im Endeffekt die günstigste Lösung: Nicht teuer, wenig
Platinenplatz und die Software ist kostenlos und auch von Leuten
bedienbar, die nicht so richtig verstehen, was ein CPLD eigentlich ist.

Hier mal mein Beitrag. Habe das prinzipiell so in in Betrieb, ist
schnell und funktioniert. An die Portausgänge können auch direkt LEDs
mit Vorwiderstand gehängt werden. Der Strom reicht aus; hab's mit
HC-Typen gemacht. Die 74HC245 gestatten ein Zurücklesen der
geschriebenen Daten, was ein "Port$4000 ++" erlaubt. Zudem ist der
obere Port auch als reiner Eingang schaltbar. Der 74HC273 hängt an
RESET.
Ok, sind zwar einige ICs verbaut. Aber wegen Diesem gleich in VHDL zu
springen? Muß jeder selber überlegen. Bei geschicktem Routing der
Register oben und unten in SMD ist der Platzbedarf überschaubar.

Vereinfachung: Zwei 138-er verwenden, der eine mit IOR an G2B, der
andere mit IOW. Erspart die OR/NOR-Stufe.

Wo ich grad dabei bin: Die NORs kommen mir ein bischen komisch vor.
Liest sich für mich so, als ob die Enables der 245-er grad verkehrt
herum laufen, d.h. beim Schreibzyklus (/RD=1 also /$4000_R=0 also 245
eingeschaltet) sind beide aktiv und der stärkere Treiber (Proz vs 245)
gewinnt. Mit OR-Gate ok, aber NOR???