Announcement: there is an English version of this forum on Hi Experten, ich habe hier im Forum schon nach ähnlichen Ideen gesucht und die meisten Vorschläge beziehen sich auf serielle Shiftregister. Es geht darum ca. 8 Ausgabe Ports a 8Bit = 64 Leitungen an einem ATMega162 zu realisieren. Die meisten Vorschläge zielen auf die Anwendung von Shiftregistern ab, nur benötigt man dann minimal 140 MCU Takte um diese Register zu befüllen, Hardware SPI vorrausgesetzt. Der ATmega162 hat aber ein externes Memory Interface das man bestimmt auch für solch eine Porterweiterung benutzen könnte. Der Vorteil wäre eben das man im besten Falle nur 3 Taktzyklen benötigte um 8 Bit anzusteuern im gesammten also 24 Taktzyklen statt 140. Hat jemand von euch ähnlich viele und schnelle Ports benötigt und auf Basis des externen Memory Interfaces realisiert ? ich bin an allem interessiert, Schaltpläne, Links, Tipps und Tricks. Meine bisherigen Vorstellungen zielen auf die Verwendung eines Adressdekoders -> 3 zu 8 ab und daran 8 mal 8Bit Buslatches. Gruß hagen
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
Der 74HC238 muß hinter das Adeßlatch, also an A0..A2 und da es ja Ausgänge werden sollen, muß ein /Enable des 74HC238 an den /WR. 8 * 74HC295 geht natürlich auch, spart sogar Platz und Verdrahtung ein. Peter
"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.
Angehängte Dateien:
-
Porterweiterung.gif
110 KB
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???
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.