Hi, Ich muss von 2 AVRs (sehr schnell) abwechselnd ein SRam IC ansteuern, und muss die 24 Adress- und Datenleitungen der AVRs jetzt irgendwie trennen, aber ohne Treiber ICs zu verwenden. Mit Treiber ICs könnte ich einfach 2 mal 3 8-fach Treiber verwenden, und die dann entsprechend per "output enable" zu- bzw. wegschalten. Da ich aber leider keinen Platz für 6 zusätzliche ICs + Leitungen habe, suche ich irgend eine simplere Möglichkeit, wie ich das z.b. mit ein paar Widerständen, Transistoren und evtl. entsprechender Programmierung der AVRs lösen kann. Das ganze muss recht schnell gehen, und daher geht es leider nicht jeweils 24 I/O-Ausgänge der AVRs auf hochohmig bzw. Output zu setzen, ausser das ginge natürlich mit 1 Befehl... Falls jemand eine Idee hat, dann lasst es mich bitte wissen...
vielleicht dual-port rams??? welche anwendung hast du da, dass du sowas machen musst? 73 deoe6jwf / Hans
hi, an sowas bin ich auch schon länger interessiert, nur hab ich nie etwas entsprechendes gefunden... Nur von Dallas den DS1609, der allerdings "not recommended for new designs" ist und nur 256 Bytes speichern tut. Ich suche etwas in der Größenordnung 32 KB Gruß Benjamin
tjo die gibts ned mehr so häufig... ursprünglich wurdn die dinger ja auf grakfik karten verbaut.. und jetzt da ja sowieso alles auf minimalen raum sein muss wegen der frequenzn macht man den controller gleich auf den chip... aber schau doch mal auf die cypress-page..die baun die dinger... z.b CY7C133.... 73 de OE6JWF / Hans
Hallo Elektrofuzzi Was soll das geben? Vielleicht ein EPRPOM-Emulator? Gruss Peter
Das sollte ganz ohne Probleme gehen. Man kann doch das externe Speicherinterface disablen und damit sind die belegten Pins ganz normale IOs, d.h. hochohmig. Du brauchst nur noch 1 oder 2 Drähte zwischen den AVRs damit sich die beiden einigen können, wer denn jetzt nun zugreifen darf. Z.B.darf der Slave immer und der Master sagt über einen Draht, daß er jetzt mal ran möchte. Und nachdem der Slave den gerade laufenden Zugriff beendet hat sagt er über den 2. Draht dem Master, daß er fertig ist und der Master nun ran darf. Peter
Hi, Das Ding soll ein Controller für Grafik-LCD-Displays werden. Ich habe ziemlich viele verschiedene Displays, und mit einer allgemeinlösung kann ich alle damit ansteuern und muss nur die SW ein bisschen ändern. Leider habe ich da keine Zeit für Handshakes, etc.. für die Kommunikation zwischen den AVRs, daher wäre es am besten, ich könnte von dem AVR zuständig für die Ausgabe auf dem Display den anderen AVR zu bzw. wegschalten. Mit Treibern wäre das sehr einfach mäglich, aber ich will halt nicht 6 Treiber (2 * 16+8 Adress/Datenleitungen) zusätzlich einbauen müssen. Wenn es natürlich SRam gibt, das ich gleichzeitig beschreiben und lesen kann (über verschiedene Adress/Daten-Leitungen) wäre das natürlich fein.... Jetzt müsste ich nur noch wissen, wo es sowas gibt in grössen ab 32 K. :-)
"Leider habe ich da keine Zeit für Handshakes" Ein IN oder OUT kostet bei 16MHz ja gerademal 62ns. Du wirst ja wohl noch ein bischen was anderes machen, z.B. die Daten aufbereiten müssen und nicht nur Speicher hin und her schaufeln. Man sollte erstmal realistisch ermitteln welche Datenrate da eigentlich benötigt wird. Der Overhead für das Handshake dürfte auf etwa 1..10% zu drücken sein, wenn man Paket orientiert arbeitet und nicht jedes Byte einzeln handshaked. Wenn Du aber wirklich jeder einzelnen ns hinterherjagen willst, dürfte der AVR wohl nicht ganz das richtige sein. Peter
"Ein IN oder OUT kostet bei 16MHz ja gerademal 62ns." Genau, und ich habe 7 * 62.6 ns Zeit um die Daten 1 mal auszulesen und einzulesen. Wenn man da die Zusatztakte für's SRam und das LCD-Display abzieht, bleibt da nimmer viel übrig. Mit 6 Treibern gehts (rein theoretisch), aber ich habe für die eben keinen Platz. Die AVR-Lösung ist für meine Zwecke trotzdem das beste, da ich damit sehr flexibel sein kann. Alles was ich brauche, ist eine Möglichkeit, die 16 Adress- und 8 Datenleitungen vom AVR-2 mit dem AVR-1 mit einem Takt auf das SRam zu- bzw. wegzuschalten. Das muss doch irgendwie zu machen sein, oder ?
"...bleibt da nimmer viel übrig..."
Das reicht doch hinten und vorne nicht, übrig bleibt da erst recht
nichts.
Ein LD + ST dauert ja schon 6 Zyklen:
loop:
LD ;3 hole vom RAM
ST ;3 lade ins Display
DEC loopcounter ;1
BRNE loop ;2
Du brauchst also mindestens 9 Zyklen und hast keinerlei Zeit noch was
anderes zu machen.
Meistens ist aber das Display mit Controller, d.h. Du must noch einen
Busy-Test mit machen bzw. zwischen Daten und Befehlen umschalten.
Also selbst mit Dual-Port-RAM gehen 7 Zyklen nie und nimmer !
Und ohne Dual-Port-RAM brauchst Du immer ein Handshake, sonst zieht der
eine dem anderen den SRAM unterm Hintern weg und der stellt dann nur
noch Müll im Display dar.
Aber auch mit Dual-Port-RAM brauchst Du eine Art Protokoll, damit der
eine weiß, welche Daten gültig sind und neu dargestellt werden müssen
und welche nicht.
Peter
"Das reicht doch hinten und vorne nicht, übrig bleibt da erst recht nichts." Doch das geht schon, der Lesezyklus muss eben immer laufen (fürs LCD Display) aber schreiben reicht alle 2 oder 3 Lesezyklen. Und lesen + Daten ans LCD kann ich in 4 takten. Und wenn ich die Schleife von byteweise auf zeilenweise ausdehne, brauche in die 2 Befehle dafür auch nicht. Ich muss nur die Ausgänge irgendwie zu bzw. wegschalten können. Anliegen an den ausgängen tun die richtigen werte bereits...
"Ein LD + ST dauert ja schon 6 Zyklen:" BTW: Ich dachte eine schreibezyklus auf einem Mega32 dauert genau 1 takt. Hab ich da vielleicht etwas falsch verstanden ?
Ein LD oder ST dauert 2 Zyklen, aber nach außen mindestens einen mehr, wenn man superschnelle RAMs hat und ohne Waits auskommt. Ich war jetzt mal davon ausgegangen, daß das Display auch im externen RAM-Bereich liegt, deshalb die mindestens 9 Zyklen. Aber wenn Du da eine Möglichkeit siehst, das kürzer zu schaffen, bin ich brennend daran interesssiert, wie Du das schaffst. Soweit ich weiß, sind Dual-Ported RAMs teuer, da zu speziell. In den heutigen PCs und Grafikkarten wird sowas voll über ASICs oder den Grafikprocessor mit normalen DDR-RAMs gemacht.. Peter
Hi Elektrofuzzi, vor dem Problem mit der Display-Ansteuerung stand ich auch mal. Damals kam auch die Idee auf mit 2 AVR's an einem RAM. Hatten dann damals festgestellt dass das nicht machbar ist. (Selbst wenn es funktioniert hätte wäre es zu langsam für das Display gewesen). Ich weis nicht genau welche Art Display du hast, aber eventuell hätte ich da einen Tipp: Wir haben unsere Displays mit einem EPSON SED1335F angesteuert. (Datenblatt: http://www.seiko-usa-ecd.com/lcd/products/graphic_mods/pdf/sed1335f.pdf) Schau's dir mal an. vielleicht hilft es dir ja weiter ;-) Viel Erfolg noch beim Basteln! Andreas
"Hatten dann damals festgestellt dass das nicht machbar ist. (Selbst wenn es funktioniert hätte wäre es zu langsam für das Display gewesen)." Warum ? Ich bin immer davon ausgegangen, dass ich in einem Takt den Pegel eines AVR-Ausganges per "out" ändern kann. Damit lässt sich locker ein Sram + ein LCD display (320x240) ansteuern. Den 2. avr brauche ich nur um Daten in das SRam reinzuschreiben, und um zusätzliche Steuerfunktionen auszuführen (Taster, RS232, AD-Wandler, etc...). Und nach meiner vorstellung benötige ich etwa 5-6 Takte (inklusive allen Timings) pro byte, und habe ca 7-8 Zeit. Ich bin also etwas schneller... Ausserdem ging es mir immer darum mit einer Schaltung verschiedene Displays ansteuern zu können, und damit viel flexibler zu sein. mit einem sed ist's da halt nicht allzuweit. Wenn man mal davon absieht, dass die Dinger auch recht teuer sind...
"Ich bin immer davon ausgegangen, dass ich in einem Takt den Pegel eines AVR-Ausganges per "out" ändern kann." Stimmt. Aber woher soll das LCD wissen, daß da neue Daten am Port anliegen ? Du mußt also noch ein /WE-Signal takten. Und ob Du dafür 3 OUT oder 1 ST nimmst, kommt aufs gleiche raus. Siehe mein Beispiel mit 9 Zyklen, darunter kommst Du nicht ! Peter
<<"Hatten dann damals festgestellt dass das nicht machbar ist. (Selbst wenn es funktioniert hätte wäre es zu langsam für das Display gewesen)." Warum ?>> Der AVR ist zu langsam um eine vernünftige Bildwiederholfrequenz zu erzeugen => das Display flimmert
Angehängte Dateien:
-
lcd.jpg
110 KB
@cd6ri "Der AVR ist zu langsam um eine vernünftige Bildwiederholfrequenz zu erzeugen => das Display flimmert" wie hoch war denn die erzeugte Frequenz ? @Peter "Und ob Du dafür 3 OUT oder 1 ST nimmst, kommt aufs gleiche raus. Siehe mein Beispiel mit 9 Zyklen, darunter kommst Du nicht !" ich dachte mir das sieht so aus: a. Die Ausgänge vom SRAM sind direkt ans LCD-Display und an einen Treiber des 2. avr angeschlossen. b. Der 1. AVR ist an 2 kaskadierte 8-bit zähler angeschlossen, die an die adresspins des srams angeschlossen sind. c. 2 weitere Treiberbausteine sind mit zwischen die adresspins des srams und dem 2. avr angeschlossen. d. Die takte des rams, der zähler, des lcds und der 3 treiber werden vom 1. avr aus gesteuert, wobei das sram über 2 leitungen angesteuert wird. einmal normal, und einmal mit einem "and" mit einem ready-pin des avr 2. Ich hänge das ganze als Bild mal mit ran. Auf diese Weise kann ich: - das lcd direkt vom s-ram mit daten füttern - das sram mit daten vom avr 2 laden, wenn der ready pin gesetzt ist - zwischen zähler- und treiber-adressierung toggeln - komplette lesesteuerung vom avr 1 - schreiben wenn avr 2 daten in treiber abgelegt,und ready pin gesetzt und das ganze sieht in pseudocode in etwa so aus: (zeilen die direkt untereinander stehen sind an einem 1 i/o Pin) 1 disablen doppel-takt sram sram auf read treiber disablen zählern enablen 2 enablen sram ausgabe -> daten ans lcd ausgeben 3 enablen 16-bit zähler -> zählt eins weiter enablen lcd -> daten übernehmen disablen sram ausgabe 4 nop für lcd (benötigt 110 ns) 5 disablen 16-bit zähler disablen lcd sram auf write treiber enablen zählern disablen 6 enablen doppel-takt sram -> daten einlesen wenn avr 2 auf ready Also 6 takte, ohne schleife. Quasi in einem "unrolled-loop". sollte doch hinhauen, oder ? Falls du da einen Fehler drin siehst, dann lass es mich bitte wissen... :-)
Irgendwie hatte ich den Eindruck, Du hast nur wenig Platz. Und nun sind doch diverse Zähler, Treiber und ein AVR mit drauf. Wärs da nicht besser, alles mit einem CPLD zu machen, z.B. XCR3128 ? Aber versuch mal, Deinen Ablaufplan in richtigen Code umzusetzen, dann kann man besser sehen obs geht. Sind ja doch ne Menge Umschaltungen mit dabei, auch wenn Du die Schleife wegläßt. Peter
"Irgendwie hatte ich den Eindruck, Du hast nur wenig Platz." Deswegen... :-) "Wärs da nicht besser, alles mit einem CPLD zu machen, z.B. XCR3128 ?" Schon, nur wo bekomme ich in D so ein Teil günstig her ? Die Teile für die LCD-Ansteuerung kosten mich ca 12 Euro. "Aber versuch mal, Deinen Ablaufplan in richtigen Code umzusetzen, dann kann man besser sehen obs geht." Das wären nur diverse outs + 1 nop für takt 4: out DDRD, r1 out DDRD, r2 out DDRD, r3 nop out DDRD, r4 out DDRD, r5 Die register muss ich natürlich noch zuvor mit den richtigen Werten laden. Aber 6 outs pro byte sind locker drin. Ich könnte sogar langsames sram (> 62,5ns) nehmen und endsprechend nops einfügen. "Sind ja doch ne Menge Umschaltungen mit dabei, auch wenn Du die Schleife wegläßt." Schon, aber alle I/o pins kann ich mit einem out ändern. Daher sollte es rein theoretisch schon gehen. Das einzige was mich stört sind die 3 Treiber für die speicherung der Adressen+Daten beim reinschreiben in das Sram. Aber keiner kennt da eine Möglichkeit, wie ich das ohne Ics (und auch ohne 24 Transistoren !) lösen kann, leider ! Falls du da was kennen solltest... ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.