Announcement: there is an English version of this forum on 
Mit Hilfe eines 8MByte SDRAMs aus einem 168 poligen SDRAM DIMM erzeugt ein mega8515 die Ansteuersignale für einen VGA Monitor mit einer Auflösung von 512x480 Pixel bei 256 frei wählbaren Farben und 60Hz. Hier mal ein Testbild im Grafikmodus. Diese Bild zeigt den Aufbau der Schaltung: Außer dem mega8515, dem SDRAM, dem RAM DAC, einem 18,432MHz Takt und einer Delay Line (oder einfach mehrere Gatter in Reihe schalten) benötigt man keine weiteren Bauteile.
Angehängte Dateien:
-
Grafik.jpg
180 KB
Angehängte Dateien:
-
TextMode.jpg
270 KB
Die eigentliche Idee ist, den uC als Character Generator zu verwenden um 64x60 Zeichen Text auf dem Monitor anzuzeigen. Den Grafikmodus kann man nämlich nicht so recht sinnvoll verwenden, da es eine Ewigkeit dauert bis die 240kB Grafikdaten für eine Bildschirmseite beschrieben sind. Durch den Burst Mode des SDRAMs, reicht ein Befehl und der der SDRAM gibt fortlaufend 512Bytes aus. In dieser Zeit kann der mega8515 schon die Textdaten verarbeiten und in Grafikdaten umwandeln, so dass sich eine Bildschirmseite in <1s aufbauen lässt. Den Aufbau kann man aber umgehen, da bei 8MB Sepicher 32 Bildschirmseiten möglich sind. So kann man mehrere Bilder im Hintergund aufbauen, während das vorhergehende Bild angezeigt wird. Bisher funktioniert das ganze noch nicht, sondern es ist entweder ein Bildaufbau oder eine Bildausgabe, aber nicht beides gleichzeitig möglich. Hier das Testbild zu dem Programm. Dieses schreibt die erste Seite des mega8515 Datenblatts auf den Monitor. Nach jedem Buchstaben wird die Farbe gewechselt, um den RAMDAC zu testen.
Hier noch die beiden Testprogramme: Das Textprogramm zeigt einen in Flash gespeicherten Text an, das Grafikprogramm empfängt eine 512x512 Pixel große BMP Datei mit 256 Farben und zeigt diese auf dem Monitor an. Das SDRAM Timing ist ziemlich kritisch, daher musste der SDRAM Takt mit einer Delayline etwas verzögert werden. Welchen Wert die Verzögerung genau hat, kann ich nicht sagen. Es müsste irgendwas im Bereich 10-50ns sein, und muss warscheinlich bei jedem SDRAM neu angepasst werden. Die Verwendung eines SDRAMs hat aber auf jedenfall den Vorteil, dass die Datenrate so hoch sein kann wie der AVR Takt, und die CPU Last weitaus geringer ist, als bei einem DRAM oder SRAM. Eine genaue Beschreibung zu den Programmen folgt demnächst, wenn der Text und/oder der Grafikmodus fehlerfrei laufen.
Hallo Benedikt (der XVI. ??? ;-)) Sehr schönes und ausgefallenes Projekt. Meinen Glückwunsch dazu. Ist der RAM-DAC ein spezieller, oder welchen hast Du da genommen?
Der RAMDAC stammt aus einer ISA Grafikkarte. Theoretisch kann man so ziemlich jeden RAMDAC nehmen, die Dinger sind seit rund 20 Jahren in der Registerstruktur alle kompatibel.
Hallo Benedikt, Gibt es schon eine genaue Beschreibung dazu ??? Und laufen der Text/Grafik modus jetzt fehlerfrei ?? ~ Lightning
Eine genaue Beschreibung würde zu umfangreich werden, zumindest wenn ich die ganzen SDRAM Grundlagen erklären müsste. Wo ist denn genau das Problem ? Am Textmodus habe ich noch nicht weitergearbeitet, aber den Grafikmodus habe ich stark verbessert. Man kann jetzt ein neues BMP laden, während das alte angezeigt wird. Das gesamte Timing ist extrem kritisch, der AVR ist >90% ausgelastet. Ändert man auch nur eine Zeile im Code (auch wenn es nur ein nop ist), läuft der ganze Code warscheinlich nichtmehr richtig. Da während der Datenausgabe kein Schreibzugriff auf das SDRAM möglich ist, werden die neuen Bilddaten im SRAM des AVR gepuffert und während des Bildrücklaufs in das SDRAM übertragen.
Hallo benedikt, wie weit ist das programm jetzt? wie läuft die grafik? Können wir per email in kontakt treten? Danke dir im vorraus
Noch genauso weit wie zuvor. Es sind andere Projekte dazwischen gekommen, die aller nützlicher sind als die SDRAM Ansteuerung. Da ich an der Schaltung keinen so wirklichen Bedarf habe (ich wollte einfach mal ausprobieren, ob ein SDRAM am AVR läuft), werde ich mit der Grafik auch vorerst nicht weiter machen.
Hi, haste zufällig Daten über Refresh/Ansteuerung SDRAM.. in deinem Source seh' ich nur "out comm, selfrefresh". Ich dachte man müsste CBR, Hidden Refresh oder ähnliche machen? Muss man einfach nur 2-3Pins richtig hinziehen? Also, haste Datenblätter oder Infos?
Ich habe alles, aber bist du sicher, dass du SDRAM und nicht DRAM meinst ? Hidden Refresh und CBR gibt es nämlich nur beim DRAM.
Hmm.. ich hatte mal nen paar Datenblätter und Infos über (DDR)-SDRAM Module, weis nich mehr genau, obs jetzt normale oder DDR waren, auf jedenfall war eins davon über Refreshs. Da standen die 2-3 Arten drin. Kannste die mir mal bitte schicken, dein Infomaterial?
Was brauchst du denn genau ? Ich habe nämlich keine Lust an die 100MB hier hochzuladen... Brauchst du nun Infos zu DRAM oder SDRAM ? Bei SDRAM gibt es nur Auto und Self Refresh. Brauchst du Infos zum Refresh oder generell zur Ansteuerung usw. ?
Hallo, das ist ja mal ein ausgefallenes Projekt. Hast Du das Speichermodul mit Heißluft geschlachtet? Ich würde auch gerne ein paar Infos zur Ansteuerung des SDRAMs haben :) Mit freundlichen Grüßen - cl
Also zu erst die Kategorie: _S_DRAM Dann wäre natürlich die Ansteuerung und der Refresh interessant. Braucht man eigentlich nen Takt?
Der SDRAM stammt aus einem 128MB Riegel der kaputt war. Zumindest wollte der PC mit dem nicht mehr booten. Mit Heißluft bekommt man die ICs super runter. Da bei (S)DRAMs meistens der benötigte Platz für das IC groß ist, haben diese oftmals noch gut lötbare Pinabstände. (Dieser jetzt nicht unbedingt, aber ich habe einige 16MByte DRAMs mit 1,27mm) Das ganze war eigentlich mehr ein Testprojekt um zu zeigen, dass man einen SDRAM sinnvoll an einem AVR betreiben kann. Es funktioniert zwar, aber das Timing ist leider so kritisch, dass es für eine ordentliche Anwendung nicht zu gebrauchen ist. Ein Problem ist, dass nirgends definiert ist, zu welchem Taktzeitpunkt ein AVR die Daten an die Pins legt. Wenn man versucht einen SDRAM zu verstehen, dann darf man nicht versuchen die Steuerleitungen als solche zu verwenden, sondern muss diese als Befehlseingang interpretieren. So kann man jedem Befehl einen konkreten Code (=Zahl) zuweisen, der beim nächten Clock Impuls ausgeführt wird. Wenn man z.B. ein Byte schreiben möchte, dann darf dieser Befehlscode auch nur für 1 Takt anliegen, sonst wird mehrfach geschrieben. Der wichtigste Befehl ist daher nop. Der größe Vorteil des SDRAMs ist der Burst Mode. Im SDRAM befindet sich ein Adresszähler der z.B. bei meinem SDRAM 9bit groß ist. Damit lassen sich also 512Bytes sequentiell ausgeben, ohne dass der uC etwas dafür tun muss. Dasselbe gilt auch für das Schreiben in den SDRAM. Ein weiterer Vorteil ist die Konfiguration: Man kann den Burst Mode sowohl zum Lesen als auch zum Schreiben verwenden, als auch nur zum Lesen (so wie ich es mache). Geschrieben wird bei mir byteweise. Leider lässt sich immer nur eine Spalte kontinuierlich ausgeben, danach muss man die Spalte "schließen" (Precharge) und die nächte aktivieren (Activate). Ich habe mal noch eine Application Note zu SDRAMs angehängt. Ist eine nette Lektüre, aber keine Angst, man muss nicht alles verstehen was da drin steht...
SDRAMs brauchen einen Takt, DRAMs nicht. Der Refresh bei SDRAMs ist einfach: Man legt einfach den Self Refresh (oder auch Auto Refresh) Befehl an, und wartet eine bestimmte Anzahl an Takten. Fertig ist der Refresh. Und noch eine Lektüre...
Habe jetzt den refresh Teil erstmal nur überflogen, aber eine Frage hab ich trotzdem, wenn ich einen refresh Befehl anlege, wird dann der ganze SDRAM refreshed, oder nur eine Bank? Wie lang dauert so ein Refresh im Durchschnitt? Gruß Helmut
Danke für das Zeuchs.. jetzt hab ich was zu lesen ;) Nach den ersten paar Seiten wird einem auch endlich klar (im Gegensatz zu dem Zeugs, was ich vorher hatte) warum das Ding überhaupt _S_DRAM heißt... "on rising edge.."
Pro Refresh (=1 Takt) wird eine Zeile Refreshed. Mein 8MByte SDRAM hat 4 Bänke zu je 4096 Zeilen. Pro Zeile hat man 512 Bytes, macht insgesamt 8388608Bytes. Pro Refresh werden also 4x 512Bytes Refreshed. Man benötigt nun 4096 Refreshs pro 64ms. (diese Angabe steht immer irgendwo am Anfang des Datenblatts) und gilt sowohl für DRAM als auch SDRAM. Ob man jetzt die 4096 Refreshs am Stück macht (=100MHz*4096 Takte=40,96us), falls der SDRAM mit 100MHz läuft, oder ob man kontinuierlich alle 15,625us einen Refresh macht, ist vollkommen egal. Noch was zum Refresh: Die 15,625us hat man bei jedem DRAM (außer bei der Low Power (L bzw. LL) Version. Das heißt, je größer der DRAM ist (je mehr Zeilen er hat), desto mehr Refreshs muss man machen. Während einem Refresh wird die komplette Zeile gelesen und neu geschrieben, was sehr viel Strom verbraucht (kurzzeitig einige 100mA, je nach Speicher). In früheren DRAMs (vor rund 20 Jahren) musste man noch die Adresse der aufzufrischenden Zeile angeben, aber das wurde einem durch den CBR Refresh (=Self Refresh beim SDRAM) abgenommen. Der Auto Refresh ist etwas ähnliches. Sowas gab es auch schon beim DRAM, aber nur bei der L/LL Version. Die hatte dann einfach einen internen Oszillator, der periodisch einen Refresh machte, um möglichst wenig Strom zu verbrauchen (typ. einige mA, meist <10mA). Der interne Aufbau eines (S)DRAMs ist sehr kompliziert. Intern benötigt ein DRAM eine negative Spannung für das Substrat von etwa -2 bis -3V. Diese Spannung lässt sich am eventuell herausschauenden Substrat messen. In einem DRAM steckt also viel mehr, als ein einfacher Adressdekoder und ein Speicherarray.
Read und Write hab ich glaub schon mal kapiert ;), und dasses mit nem nem AVR alleine echt schlimm zum ansteuern ist (ich denke da an den CLK). Andere Frage: was macht die Delay_Line jetzt eigentlich? Der SDRAM hängt an "40".. 18MHz / 40 oder wieviel kommt da an? Wie synchronisierst du das ganze bei Read/Write? Wie wäre es bei andren SDRAM-Anwendungen für den Clock das SPI zu verwenden, indem man CLK/4 macht und zwischendrin einfach Dummy-Bytes in SPDR schiebt (damit der einen Clock macht). Für ein Burst schreiben hätte man damit genug Zeit: IN (1) + ST X+ (2) Das muss man halt ohne (R)JMPs machen. Bei einem 8er Burst würde das SPI auch passend nur 8 Taktsignale liefern. Wie ich gelesen habe kann man ja einfach den Takt ausschalten (CKE), also wenn die 8 Takte pro SPI zu viel sind. Für nen Refresh wäre nen Timer zu gebrauchen, der bei OCR ja glaub bis Takt/2 oder 3 arbeitet. Muss man halt immer schön brav DDRx setzen, dass sich niemand beißt. Viele utopische Ideen.. und noch keinen konkreten Verwendungszweck, höchstens nen billigen Speicher für Dateilisten bei einem (stationären) mp3-Player. (oO.. 10Zeilen G)
Die Delay line verzögert das Tagtsignal, so dass an der steigenden Flanke die Befehle sicher am SDRAM anliegen. Auf einen Burst Write kann man eigentlich verzichten, da der SDRAM so schnell ist, dass auch ein normaler Write ausreicht. Den Takt würde ich auch nicht abschalten, sondern einfach ein nop oder Refresh auf den Bus legen. Außerdem würde ich für einen Datenspeicher lieber ein norameles DRAM verwenden, dass lässt sich um ein Vielfaches besser ansteuern als ein SDRAM Und noch eine Lektüre...
danke vielmals für die Files. Jetzt habe ich genug zu lesen. CU - cl
Großes "Dankeschön" auch von meiner Seite aus!!!!! Bevor ich deine "Lektüren" gelesen habe, hab ich nie die Ansteuerung eines SDRAM´s verstanden, doch jetzt hab ich es glaubich endlich geschnallt :-) Gruß Helmut
Danke auch von mir! Eine Frage bleibt mir trotzdem noch offen: In einer App note eines SDRAM´s von Micron hab ich als Note bei der Read Cycle beschreibung folgendes gelesen: "Each READ command may be to any bank". Heißt dies, das ich von allen Bänken die row x aktiviere und dann mit READ (burst length = full page) alle row´s nacheinander auslesen kann, ohne dazwischen PRECHARGE durchzuführen? Oder ist die Note anders gemeint? MFG Tobias
Ja, so in etwa. Kurz bevor ein Burst Read fertig ist, muss ein Burst Read mit der nächsten Bank gestartet werden, so dass genau zu dem Zeitpunkt wo der erste Burst beendet ist, die Daten des zweiten Bursts ausgegeben werden. So lassen sich z.B. mit einem 4x512x2048 SDRAM 4x512=2048Byte am Stück ausgeben. Danach ist aber Schluss, denn entweder muss man erst die Row schließen (precharge) (wenn man kein Auto Precharge verwendet hat.) Danach kann man erst die nächste Row aktivieren.
bekommt man noch so einen einfachen RAMDAC irgndwo her? Ich finde nur Tripple 8Bit RAMDACs. Aber da könnte man doch sicher auch Rx, Gx und Bx zusammenschalten. Müsste doch dann 8Bit sein, oder? Eventuell ein Datenblatt wie so ein DAC funktioniert? Eventuell müsste ich mir ne ISA Grafikkarte kaufen oder?
Tripple 8Bit RAMDACs ? RAMDAC ist RAMDAC. Wenn es ein RAMDAC ist, dann kann man die Farben direkt programmieren, da muss man nichts zusammenschalten. RAMDACs sind auf jeder Grafikkarte verbaut. Heute allerdings im Grafikcontroller integriert. Als einzelne ICs gab es die nur auf ISA und alten PCI Karten. Erhältlich sind die ICs auch heute noch, z.B. bei Digikey. Ein Datenblatt von den auf Trident Karten verbauten RAMDACs habe ich angehängt.
Jo: http://www.analog.com/UploadedFiles/Data_Sheets/173587347adv7120.pdf 3*8Bit, also 24Bit Farbtiefe.
Das ist kein RAMDAC sondern ein normaler DAC... Wenn man die Bits entsprechend verschaltet, kann man diesen auch verwenden. Die Farben sind dann aber fest und können nicht frei gewählt werden.
Habe ich das richtig verstanden, dass der AVR lediglich den rRefresh macht und die daten von der UART in den RAM schreibt?
Den Refresh macht der SDRAM eigentlich auch selbst. Der AVR macht während der Darstellung rein garnichts, außer Daten vom UART in den SRAM zu speichern. Während des HSyncs wird die nächste Zeile des SDRAMs aktiviert. Während des VSync werden die Daten aus dem SRAM in den SDRAM kopiert. Insgesamt liegt die Auslastung des AVRs vermutlich bei <10%.
Ich habe auf einer alten PCI karte einen MU9C4870-80PC RAMDAC gefunden, zumindest vermute ich das es einer ist :) Weiss jemand wo ich dafür ein Datenblatt bekommen kann? Also sehe ich das richtig, das ein RAMDAC eine Farbpalette speichert und je nachdem welcher wert am Eingang des RAMDACs liegt gibt er die entsprechenden Analogsignale zu der im RAMDAC gespeicherten Farbe aus?
Die Karte war ISA, das ist aber unerheblich denke ich. Ich will das ganze ähnlich nachbauen nur mit SRAM anstatt SDRAM weil mir die SDRAM ansteuerung noch zu kompliziert ist (und ich keine adapter kaufen will und nur uralt 4 bit DRAMs von besagter Grafikkarte habe die wohl nicht vergleichbar sind :)).
Wenn das IC 28 Pin hat, kannst du warscheinlich das Datenblatt vom TR9C1710 verwenden, die RAMDACs sind alle ziemlich gleich.
Also laut recherge handelt es sich bei meinen RAMDAC um einen der auch als DAC benutzt werden kann (16 bit farbtiefe! toll!). Aber ich denke mal der ist abwärtskompatibel, zumindest die versorgungs-spannung und R/G/B signale stimmen überein. Außerdem habe ich eine Anleitung über RAMDAC Programmierung gefunden - natürlich für PCs. Das ganze ist ja viel einfacher als ich befürchtet hatte. Nur eine Frage bleibt noch offen: Wie wird dem Monitor mitgeteilt mit was für einer Auflösung er betrieben wird? Oder weiss der Monitor das gar nicht? Was für eine Frequenz muss an den RAMDAC um zB 640x480 Pixel aus zu geben? Wie errechnet sich das? 640x480x75(Hz)=23,04Mhz ist wohl nicht ganz richtig :) Ich brauch etwas generelle infos über VGA monitore glaube ich... mal schauen was wikipedia und google zu bieten haben.
>640x480x75(Hz)=23,04Mhz ist wohl nicht ganz richtig :)
Doch, das ist fast korrekt: Du musst den Zeilenrücklauf hinzuaddieren:
Aus 640x480 wird dann etwa 800x512
Ich verwende 512x480x60Hz -> 600x512x60Hz = 18,432MHz
ah verstehe... aber ist denn nirgendswo genau definiert wie lange so ein Zeilenrücklauf dauert?
Für alle die's interessiert, das timing findet man hier in Form eines Excel Dokuments: http://www.vesa.org/public/GTF/GTF_V1R1.xls Für 640x480 kommt da eine "tatsächliche" Auflösung von 816x502 raus also warst schon sehr nahe dran :)
Can you give the schematic circuit diagram? Thamks very much. my Email: bromi@icbean.com
Hallo Benedikt, ich seh das Teil hier echt als Alternative zu der ISA Karte, Ich habe auf meiner ISA Karte genau den gleich RAM DAC wie Du ihn hier verwendet hast. Jetzt mal ne Verständnisfrage: Kann man dieses Projekt auch mit einem RAM machen ? Wie funktioniert die Kommunikation zwischen DAC und Speicher ? Ich habe es so verstanden : Ich schreibe die Bilddaten in den RAM in der Zeit in welcher ein Pixel gezeichnet wird ? Ist ein Pixel dran ( als Ausgabe ) dann die entsprechende Adresse (aus H und V sync) anlegen und Raminhalt ausgeben. Pixelclock tackten. Danach habe ich wieder zeit bis zum nächsten Pixel um den Ram zu beschreiben ? Demnach müsste der DAC die angelegten Daten bis zum nächten Pixelclock halten ??? Stimmt das so ?
Ausserdem wie funktioniert horz. und Vertik. Sync ? Ist das PWM ? Ich dachte immer das iss ein analoger Sägezahn ?
Andreas Engler wrote: > Jetzt mal ne Verständnisfrage: > Kann man dieses Projekt auch mit einem RAM machen ? Nein, ich nutze den internen Adresszähler der SDRAMs, der selbständig die Daten ausgibt. > Wie funktioniert die Kommunikation zwischen DAC und Speicher ? Jede Zeile hat 512 Bytes=Pixel. Zu Beginn wird ein kurzer HSync Impuls erzeugt, das SDRAM wird auf Ausgabe gestellt, die entsprechende Zeilenadresse geladen, die Spaltenadresse auf 0 gestellt und die Ausgabe wird gestartet. Mit jedem Takt (=AVR Takt) gibt der SDRAM ein Byte aus, das vom RAMDAC in die RGB Signale umgewandelt wird. Während der Dauer der Zeile hat der AVR nichts zu tun und kann sich anderweitig beschäftigen. Er darf nur das SDRAM nicht stören. Ich puffere die Empfangenen Daten daher im internen SRAM. Ist die Zeile fertig, läd der AVR so schnell wie möglich die neuen Daten in das SDRAM. HSync und VSync sind kurze Impulse. Den Sähezahn zum Ablenken erzeugt ein Monitor selbst.
ah cool danke für die Erklärung. Ich habe hier so einen 5" Tft monitor aus einem Multimedia Interface eines Autos. Das teil hat RGB HS VS und einen Pixelclock. weisst du wozu man den braucht ??? Naja has du eine Ansteuerroutine in C für ein SDRAM
Andreas Engler wrote: > ah cool danke für die Erklärung. > Ich habe hier so einen 5" Tft monitor aus einem Multimedia Interface > eines Autos. Das teil hat RGB HS VS und einen Pixelclock. > weisst du wozu man den braucht ??? Den Pixeltakt ? Für die einzelnen Pixel natürlich. > Naja has du eine Ansteuerroutine in C für ein SDRAM Guter Witz... Vergiss die Idee: Das SDRAM ist extremst timingkritisch. Jeder Takt zählt. 100% ASM ist da schon notwendig.
Pixeltakt.... heisst das ich müsste den Pixeltakt vom RAM DAC auf das Display legen oder ? Wie lange dauert es bis dei deiner Schaltung ein Bild aufgebaut ist ?
Andreas Engler wrote: > Pixeltakt.... heisst das ich müsste den Pixeltakt vom RAM DAC auf das > Display legen oder ? Ja. Hat das Display analoge oder digitale RGB Eingänge ? > Wie lange dauert es bis dei deiner Schaltung ein Bild aufgebaut ist ? Etwa 20s für ein Vollbild. Ich habe schon Ewigkeiten nichts mehr an dieser Software gemacht, da leider nicht viel Optimierungspotential vorhanden ist, und ich mitlerweile bessere Schaltungen habe.
ja welche denn ? Ich brauch unbedingt eine gute VGA Schaltung.... sonst muss ich echt noch mein ETX board benutzen dass ist aber extrem viel Einarbeitung und ausserdem brauch ich noch ein Baseboard für ca 100-150 € Ausserdem muss ich dann ein Betriebsystem installieren Linux oder DOS und das braucht bestimmt ewig zum Hochfahren. Ich hätte dann die Bilder auf einer CF abgelegt und über die Serielle Schnittstelle ausgewählt welches ich anzeigen will. Sowas in die Richtung will ich mit einer SD - Karte & AVR machen wenn sich das Bild schnell genug aufbaut dann lese ich direkt von SD. gut wäre es wenn man mehrere Seiten in den Video Speicher laden könnte. Aber habe bis jetzt noch nix wirklich brauchbares "einfaches" gefunden. Wie machst du es denn jetzt ?
Ausserdem ein kleines Rechenbeispiel: 640 480 8 bits / 125,2kbaud/s ergibt etwa 21s ich glaube deine Serielle Schnittstelle ist der Engpass bei dem ganzen wäre nicht noch ein Port frei + ein paar Steuerleitungen für adress hi/lo daten hi/lo
Andreas Engler wrote: > Ausserdem ein kleines Rechenbeispiel: > > 640 480 8 bits / 125,2kbaud/s > > ergibt etwa 21s > > ich glaube deine Serielle Schnittstelle ist der Engpass bei dem ganzen Richtig. Wenn man die Software etwas anpasst sollten > 100kByte/s möglich sein. Aber um den Umweg mit dem Zwischenspeichern im SRAM wird man nicht rumkommen.
Besteht aus einem S1D13504 und 2MB DRAM. Damit kann ich beliebige LCDs und Monitore ansteuern bis 800x600 und 65536 Farben.
Im Datenblatt vom S1D13504 sind mehrere Möglichkeiten gezeigt (im vollständigen Datenblatt ganz unten, bzw. in den AppNotes). Mehr ist auf meiner Platine auch nicht drauf. Einfacher und billiger geht es eigentlich kaum: S1D13504: 15€ bei CSD, dazu noch ein 1M x16 DRAM von einem 4 oder 8MB PS2 SIMM Speichermodul. Nur die 0,4mm Pinraster sind eine kleine Schwierigkeit... Der 13504 ist zwar abgekündigt, ist aber noch erhältlich. Oder einfach den Nachfolger S1D13506 nehmen. Hier der Link zu den Anschlussbeispielen: http://www.erd.epson.com/index.php?option=com_docman&task=cat_view&gid=248&Itemid=40 Und einem Beispielboard: http://www.erd.epson.com/index.php?option=com_docman&task=cat_view&gid=259&Itemid=40
Hi ich habe so ein EDO RAM geht der auch das ist ein KM44C4104Ak-6 aber im Datenblatt werd ich nicht so schlau wie groß der Speicher jetzt wirklich ist. geht das mit dem Speicher ? Datenbaltt ist im Anhang
hab mir den S1D13506 angeschaut . Hast Du die Adress und Datenleitungen gelachted ? habe mir schon eine Eagle lib dafür gemacht und den Schaltplan angefangen. Muss jetzt nur noch schauen wie ich die Ausgänge und den Memory beschalte. Ich verwende dafür einen Atmega 128. Habe ich dass richtig aus dem Datenblatt verstanden, dass man 2 Bildschirmseiten wählen kann ?
Angehängte Dateien:
-
13504.jpg
100 KB
Andreas Engler wrote: > nee ich meine jetzt für die schaltung mit dem S1D13506 ? Für die braucht man einen 256k x 16 oder einen 1024k x 16 DRAM. > Hast Du die Adress und Datenleitungen gelachted ? Nein, ich habe nur das Latch am AVR dran wie üblich. Ich steuere den Controller auch nur über A0-7 über den Bus an. A8-20 steuere ich per Software. > Habe ich dass richtig aus dem Datenblatt verstanden, dass man 2 > Bildschirmseiten wählen kann ? Nicht ganz: Du kannst soviele Bildschirmseiten verwenden wie Speicher zu Verfügung steht: Bei 640x480@8bit wären das 300kByte pro Seite. Da der Controller über max 2MByte verfügt, kann man also 6,8 Seiten verwenden. Bei kleineren Bildern entsprechend mehr. Ich habe mal ein Foto von meinem Aufbau angehängt: AVR + ein wenig Logik (u.a. um das Wait Signal auszuwerten und um DMA Transfers zwischen USB und 13504 zu ermöglichen.) Überhalb vom 13504 der RAMDAC für den Monitor und rechts Bustreiber für die LCD Ausgänge. Hast du eigentlich eine Bezugsquelle für den 13506 ?
>>Hast du eigentlich eine Bezugsquelle für den 13506 ? Nein noch nicht aber wenn ich eine finde werd ich mir gleich mal 3 Stück bestellen. Kannst du da wen empfehlen ? >>Nein, ich habe nur das Latch am AVR dran wie üblich. Ich steuere den Controller auch nur über A0-7 über den Bus an. A8-20 steuere ich per Software. hat der AVR einen eigebauten latch ? kenn ich ja noch gar nicht ???
Habe es gerade im Datenblatt gelesen "Alternate Functions of Port A" naja ich denk das brauch man nicht unbedingt oder ? Ich hätte mir das mit 4 Latches so gemacht : 1. Port - > 2 latches für Daten 0..15 2. Port - > 2 latches für Adressen 0..15 und einen Teilport mit 16..20 den Speicher bekomm ich wohl hoffentlich bei Conrad , oder wenn du noch welchen hast würde ich dir den gegen einen unkostenbeitrag akaufen genau wie ein 13504. Ich lass dann eine Platine machen in Bulgarien. Die sind ganz gut. für ne 20 € Platine bekommt man alle bauteile drauf ;) Wenn Du mir ein bisschen beim Schaltplan hilfst lass ich ne Platine für Dich mitmachen :) Man könnte anstatt den latches auch 5x8bit Schieberegister nehmen und das ganze über SPI machen ?.. von den Schieberegistern habe ich nächlich noch 20-30 rumliegen ;)
Andreas Engler wrote: >>>Hast du eigentlich eine Bezugsquelle für den 13506 ? > > Nein noch nicht aber wenn ich eine finde werd ich mir gleich mal 3 > Stück bestellen. Kannst du da wen empfehlen ? Ich leider auch nicht. Ich werde aber mal etwas rumfragen, vielleicht kann ich welche auftreiben. Daher habe ich bisher auch nur den 13504 verwendet. Der 13506 wäre aber durchaus interessanter, da er den RAMDAC integriert hat, und direkt ein farbiges TV Bild erzeugen kann. >>>Nein, ich habe nur das Latch am AVR dran wie üblich. Ich steuere den > Controller auch nur über A0-7 über den Bus an. A8-20 steuere ich per > Software. > > hat der AVR einen eigebauten latch ? kenn ich ja noch gar nicht ??? Für was braucht man Adress und Daten Latches ? Auch wenn der 1350x einen 16bit Datenbus hat: Man kann ihn auch mit einem 8bit Bus betreiben (D0-7 parallel an D8-15 anschließen). D0-7 kommen direkt an AD0-7, A0-7 über ein Latch an AD0-7. A8-15 kann man direkt an A8-15 anschließen. A16-20 und MR\ kommen an einen weiteren Port. > den Speicher bekomm ich wohl hoffentlich bei Conrad , oder wenn du noch > welchen hast würde ich dir den gegen einen unkostenbeitrag akaufen genau > wie ein 13504. S1D13504 habe ich leider keine mehr, Speicher löte ich immer aus alten Speichermodulen aus. Das sind dann 1M x16 EDO mit 60ns. > Wenn Du mir ein bisschen beim Schaltplan hilfst lass ich ne Platine für > Dich mitmachen :) Kannst du mir mal die Eagle Lib für den 13506 schicken oder hier posten, dann zeichne ich mal die restliche Schaltung ein wenig drumherum (zumindest den 13506 spezifischen Teil). > Man könnte anstatt den latches auch 5x8bit Schieberegister nehmen und > das ganze über SPI machen ?.. von den Schieberegistern habe ich nächlich > noch 20-30 rumliegen ;) Würde ich nicht machen: Ein 640x480 Bild hat 300kByte. Selbt mit parallelem Interface dauert der Bildaufbau schon je nach (AVR) Controllergeschwindigkeit und Bildquelle 1s aufwärts. Mit SPI wird es sehr viel langsam, da für jedes Bytes/Word 40 SPI Takte benötigt werden.
Ich meine mich zu erinnern, den 13506 bei Digikey gesehen zu haben. Gruß, Matthias
Stimmt: 9.56€ + MwSt, Zoll usw., also etwa 12€ für einen Controller der 800x600@16bit kann und direkt ein PAL/NTSC Signal erzeugt, und sogar 2 Geräte mit unterschiedlichem Bildinhalt ansteuern kann ! Außerdem kann man damit so ziemlich jedes LCD/TFT ansteuern. Da könnte man doch eine kleine Universalplatine machen, Interessenten an einer Low Cost uC Grafikkarte gibt es bestimmt.
Hallo Benedikt hier ist mal die eagle lib ist für das QFP 144 Gehäuse... das hat den größten Pinabstand... also besser zu löten. ist der 13506 Pinkompatibel zu dem 13504 ?
ist schon pinkomatibel aber leider gibts den nur in QFP 128 aber ich mach das Package dazu
So habe mal schnell den neunen 13507 im 128 TQPF "gemalt" der unterschichied in der Höhe wird wohl nicht ausmachen ;)
Ich habe den S1D13506 mal beschaltet. Alle noch freien Pins sind ein bzw. Ausgänge die je nach LCD/Monitor/TV und uC beschaltet werden müssen. Die Pullups an den Speicher Datenleitungen dienen zur Konfiguration. Entweder man bestückt einen Widerstand, oder lässt einen weg, je nach gewünschtem Datenbus. Möchtest du das ganze universell machen, oder geziehlt für einen festen uC und ein festes Display ?
nein ich möchte es eher universell machen damit nicht mehr die Fragen kommen wie z.B: wie kann ich ein Laptop Tft an einen AVR anschließen ?? Es muss halt nur für mein Diplay auch funktionieren das braucht RGB H/V-sync und pixelclock. Man könnte eine Platine entwerfen bei der man noch eine SD-Karte anschließen kann damit man Bilder direkt von Rechner aus laden kann. Das habe ich schon mal mit der Graka von Radig gemacht... Hat aber halt keine gute performence die ganz geschichte. Und Optional vllt. noch einen MCP2515 CAN-Controller ...dafür habe ich mir auch einen schönen Treiber geschrieben. Den CAN Controller brauch ich weil ich das Teil wieder ins Auto einbauen möchte und ich denk bei 1 MBit/s könnte man sogar kleine Bilder von einer Web/Handy Cam rüberschicken ;) ich schau mir jetzt mal den Schaltplan an ;)
Was hälst du davon, den Controller auf eine Platine zu packen, an den Ausgang 3x 74LVC245 anzuschließen, um den Ausgang entweder mit 5V oder 3,3V betreiben zu können. Dann die ganzen Ausgänge an eine 34 oder 40 polige Buchsenreihe zu legen ? Zusätzlich noch einen VGA und Cinch Anschluss vorsehen. So kann man dann entweder einen Stecker anschließen, oder das ganze als Adapterplatine auf eine andere (Lochraster)Platine setzen. Einen AVR würde ich nicht unbedingt auf die Platine packen, da der Controller eher was für die ARM Fraktion ist. Ich würde den Eingang daher an eine 50 polige Buchsenleiste legen. So ist die Platine schön universell und kann mit jedem uC betrieben werden.
So habe ich meinen 13504 mit einem mega8515 verbunden. CLKI beim 13506 würde ich noch mit 33MHz und CLKI2 mit 17,73MHz versorgen. Entweder aus einer PLL oder aus 2 Quarzoszillatoren. 33MHz ist der Optimale Wert für ein 60ns EDO DRAM, und die 17,73MHz werden für ein PAL TV Bild benötigt.
So habe die Schaltung mal weiter gemacht. Was mir noch nicht so ganz klar ist wo die Daten 8..15 herkommen und die restlichen Steuersignale am 13506. Kannst du dir das mal anschauen ? Gruß Andreas
D0-7 sind mit D8-D15 parallel geschaltet, da ich nur 8bit Transfers nutze. Da die Low bytes an D0-7 müssen und die Highbytes an D8-15, wird A0 benutzt um WE/RD 0 und 1 umzuschalten. Du hast die Leitung an AD0 gehängt, die muss aber an D0. A16 bis 20 würde ich auch nicht mitten im Port anfangen, sondern an Bit0. M/R kann man als A21 ansehen. CS muss noch an einen Portpin, Busclk kann man an den Ausgang des Quarztaktes legen. Ohne Auswertung der Wait Leitung muss man mindestens 2 Wait States einfügen (falls das reicht). Falls viel Speicherbandbreite gebraucht wird (z.B. bei 800x600@16bpp), dann gehen sonst Daten verloren. Ich würde keinen mega128 auf die Platine machen, sondern besser die ganzen Pins auf eine Stiftleiste legen. Die meisten Steuersignale kann man auf feste Pegel legen. Das Interface ist recht universell und kommt so ziemlich mit jedem Bus zurechnt. Daher braucht man in de Praxis nur etwa die Hälfte davon.
Ihr braucht 3506 ? Habe 5 Stück abzugeben. TQFP128 mit bis zu 2MB externem Videoram. PackageSize ist wie beim 3706 TQFP100 nur mit engerem Pitch. Ich habe Sie übrig. Es sind keine Samples !!!! Gekaufte Teile! Interesse ? Dirk
Benedikt K. wrote:
> Was möchtest du pro Stück ?
18 Euronen
ich wäre auch interessiert ,bei angemessenem Preis Du Benedikt ich mach den Atmaga runter und mach Buchsenleisten drauf ;) dann kann man es universeller benutzen.
so ic hab mal noch ein bisschen weiter gemacht im Schaltplan
Ich habe mal Ein und Ausgänge hinzugefügt. Das wäre in etwa mein Vorschlag: So kann man das ganze an jeden beliebigen 8 und 16bit Bus anschließen. Die Betriebsspannung der Schaltung beträgt 5V, allerdings kann man das LCD auf mit 2-5V betreiben wenn man VCCIO auf die entsprechende Spannung einstellt, und für die 245er die LVC Version verwendet.
sieht gut aus ;) woher hast du denn die Stiftleisten im Eagle ich habe noch nie welche gefunden. Welcehn suchbegriff oder in welcher lib sind die ? Ich werd morgen das Teil mal Routen
nee halt die vorfreude war zu groß, die Widerstände sind alle auf der falschen seite, Update kommt ;)
so hier das update ... die Stiftleisten für den Host nach unten geführt... der Anschluss für LCD / VGA nach oben
der drc hat noch keepouts festgestellt... die sind nun auch weg ... also das teil üsste jetzt bei einem standard PCB- Hertsller machbar sein...
Angehängte Dateien:
-
s1d13506_top.JPG
100 KB
so sollte die fertige Platine dann aussehen (3d) ohne Speicher s1d13506 hier die oberseite
Angehängte Dateien:
-
s1d13506.jpg
79 KB
So ganz gefällt mir das Layout nicht, es sieht sehr nach Autorouter aus: HF mäßig ist es sogar ziemlich miserabel, da es keine saubere Betriebsspannungsführung gibt. Das DRAM stört mit Sicherheit das Analogsignal am VGA Ausgang. Die neueren Epson Controller sind manchmal etwas empfindlich, ein wenig saubere Leiterbahnführung ist da schon notwenig. Was hälst du von diesem Layout ?
sieht gut aus aber ich habe versucht die platine so klein wie möglich zu bekommen ... nunja mit HF kenn ich mich nicht so aus. Welche maße hat dein Layout jetzt ?
Angehängte Dateien:
-
s1d13506.jpg
140 KB
Die Platine ist etwa 7,9 x 6,2cm groß. Deine Platine ist 8,2 x 5cm groß, also nicht viel kleiner. Ich habe mein Layout darauf optimiert, die Leietrbahnen möglichst kurz, und das ganze HF mäßig so gut wie möglich zu machen. Zusätzlich habe ich noch einen 3,3V Regler auf die Platine gesetzt, und einen Jumper um den Ausgang entweder mit einer externen Spannung, 5V oder 3,3V zu betreiben.
wenn du die "großen Stiftleisten" etwas zentrieren würdest und links und rechts eine kleine 3mm Bohrung dann wärs besser weil man sie dann mit Absctandbolzen befestigen könnte ?? deswegen habe ich je eine Stiftleiste rechts und eine links gemacht damit man es wie ein Modul aufstecken kann. So hast du nur eine Seite zum einstecken... deswegen die Bohrungen.
was ich eigntlich sagen wollte ...aus Stabilitätsgründen ;) würde ich die bohrungen noch machen
wenn ich das Datenblatt richtig verstanden hab kann ich den Pixelclock dann am CLK 1 Pin abgreifen ?
Nicht ganz. Direkt geht das normalerweise garnicht, da bei VGA kein Takt gebraucht wird. Der Pixeltakt kann aus CLKI, CLKI2 und BUSCLK erzeugt werden. Der Takt wird intern ausgewählt und dann noch durch 1, 2, 4 oder 8 geteilt. Wenn man aber gleichzeitig den LCD und den VGA Ausgang aktiviert, dann kann man den LCD Pixeltakt verwenden. Vom S1D13506 sind bei dem Layout jetzt alle Pins rausgeführt bzw. angeschlossen. Man kann also alle Features nutzen.
ok ich lass dann mal 2 platinen machen ;) ich schau morgen mal bei PCB Pool oder so , kannst du dich vllz. um die Grafik controller kümmern ich überweis dir dann das Geld und schick dir dann ne Platine
Was kostet eigentlich eine Platine ? Je nach Preis hätte ich interesse an bis zu 3 Stk.
Kurze Frage, wozu eigentlich die Bustreiber ? Ist das Display so weit weg ? Marco
Teilweise schon, aber die haben auch noch einen anderen Zweck: 5V -> 3,3V. Außerdem ist der 13506 dann besser geschützt: Mir ist es schon ein paarmal passiert, dass ich beim Messen an den Leitungen mit dem Tastkopf abgerutscht bin, und so die 15V VLCD an eine 3,3V Datenleitung gelegt habe. Bei einem 0,5mm Stecker passiert sowas schnell.
Ich habe noch ein paar Kleinigkeiten geändert (hauptsächlich am VGA Ausgang und an der Stromreferenz.) Schau dir mal die Vias unter dem DRAM an, ob die so machbar sind, oder ob die zu nahe an den anderen Leiterbahnen liegen.
Also ich hätte auch Interesse an 2 Platinen und 2 Controllern.
Was ist dann mit hsync vsync dclk den ? Fährst Du mit weniger als 24 Bit rüber und nutzt dann die übrigen für die obigen Signale ? Ich bastle auch gerade an so etwas. Habe nur ein Problem. Die LED Beleuchtung braucht 19,8 V bei 20mA. möchte diese gern aus den 5 V gewinnen. Also Stepup. Hast Du hier eine gute Schaltung ? Marco
Marco wrote: > Was ist dann mit hsync vsync dclk den ? DCLK gibt es beim analogen Ausgang nicht, es liegen nur RGB, H und VSync an. > Fährst Du mit weniger als 24 Bit rüber und nutzt dann die übrigen für > die obigen Signale ? Was meinst du jetzt ? Der Controller kann 16bit, also nur 65536 Farben. > Habe nur ein Problem. Die LED Beleuchtung braucht 19,8 V bei 20mA. > möchte diese gern aus den 5 V gewinnen. Also Stepup. Hast Du hier eine > gute > Schaltung ? Nahezu jeder beliebige Stepup sollte sowas können. Im einfachsten Fall ein MC34063, dessen Feedback Pin über 62 Ohm nach GND verbunden ist, an den die Kathoden der LEDs angeschlossen sind. Das ergibt ziemlich genau 20mA.
Ich weiß. Aber Du hast 3 Bustreiber auf der Platine. Also 24Bit. Die ungenutzen am TFT soll man ja auf 0 ziehen, sofern das Modul 24Bit RGB hat.
2 von den 3 Bustreibern sind für die Daten, der 3. für die Steuersignale.
also bei weniger als 10 stück wird es wohl auf etwa 40€ kommen... aber ich werde das Teil mal in Bulgarien anfragen wegen den Pinabständen beim S1d13506 vielleicht gehts ja doch ... dann kommen wir auf die hälfte vom Preis... muss mein Eagle noch ma neuinstallieren ... wegen Win neuinst.
40€ ist ja ziemlich teuer. Wieviele müsste man bestellen um auf <20€ zu kommen ?
>=10 naja ich hab noch einen Kumpel gefragt... und frag mal morgen noch meinen
Chef ob der auch eine oder zwei will dann sind wir ja schon genug.
ausserdem habe ich die Anfrage an Bilex abgeschickt... das sind die aus
Bulgarien ... da hab ich schon mal eine machen lassen.
Die sind ganz gut nur die können keine so feinen strukturen machen...
mal abwarten was die morgen sagen. Wenns klappt und wir sogar 10 st
brauchen oder mehr könnten die sogar nur 15 € kosten
Wenn ich dich mal was fragen darf... was für nen Beruf hast du denn ?
Ich bin Student. Allerdings arbeite nebenbei bei einer kleinen Firma die sich hauptsächlich mit LCDs beschäftigt. Daher habe ich schon etwas Erfahrung mit den Epson Controllern und allgemein mit LCDs. 15€ wäre ein guter Preis. Ich habe damals glaube ich 8€ für die 13504 Adapterplatine bezahlt, allerdings war die Platine einseitig, ungebohrt, und die Qualität nicht so gut. Falls es dir nicht zuviel arbeit ist: Poste doch mal in Markt, ich denke es haben noch mehr Leute interesse an solch einer Platine. Das Thema TV/VGA Grafikkarte schein ja doch viele zu interessieren. Und billiger/einfacher als mit einem S1D13506 geht es wohl kaum. Nur die 0,4mm sind halt ein eine kleine Schwierigkeit.
@Dirk: >"Benedikt K. wrote: >> Was möchtest du pro Stück ? > >18 Euronen Echt lustig, in einem anderen Thread schreibst Du noch: >S1D13706 = 9.93€ > >S1D13A05 = 11.57€ (allerdings im BGA) geht auch S1D13A04 > >S1D13506 = 9.56€ So kann man auch sein Geld schnell verdienen...
@ Andreas Engler Ich habe auch interesse an einer Platine. Wird das von Benedikt K. erstellte Layout gefertigt?
jep einfach email an andreasengler@gmx.de oder ICQ 103206969
Bei Multi-PCB würden 10 Stück jeweils 18,80 Euro kosten (Netto). Bei 20 sind es nur noch 9,40 Euro. Einzigstes Problem: die liefern nur an Firmen. Aber vielleicht kann da jemand aushelfen.
Eurocircuits ist auch günstig: 5Stk: 82.18€ -> 16,4€ 10Stk: 101.31€ -> 10,1€ 15Stk: 120.33€ -> 8€ 20Stk: 139.27€ -> 7€ Ich glaube da kommen aber noch 21% dazu (MwSt usw.)
Hier mal die Schaltung zu der letzten Version des Layouts.
Ich interessiere mich auch für ein LCD Display. Weiß jemand, welches TFT Touch-Display man an diese Platine anschließen kann? Daten etwa: - Größe ca. 3-6 Zoll - Auflösung ab 320*240 Punkte - Farbe - Touch - Preis egal (naja, sagen wir bis 250,-) Bezugsquelle wäre auch interessant.
Angehängte Dateien:
-
s1d13506.gif
37 KB
So müsste sich das ganze an einen AVR anschließen lassen. Das ganze ist noch nicht getestet, müsste aber so funktionieren. Dadurch dass SBHE\ immer zusammen mit A0 aktiv ist, und das ganze als Big Endian eingestellt ist, werden nur 8bit Transfers verwendet. Beim 13504 funktioniert das ganze bei mir zumindest ähnlich.
Michael wrote: > Ich interessiere mich auch für ein LCD Display. > Weiß jemand, welches TFT Touch-Display man an diese Platine anschließen > kann? So ziemlich jedes TFT oder LCD lässt sich damit ansteuern (bis max 800x600). Wo man solche günstig bekommt kann ich dir leider nicht sagen.
Hallo Für 2 Platinen hätte ich Verwendung. Die Epson Controller könnte ich bei der nächsten Digikey Sammelbestellung mit bestellen.Wenn es mehr werden werden die Teile auch günstiger. LG Michael
Hi, die Platinen von Eurocircuits hören sich gut an. Top Preise da kann man nix sagen. Also wir müssten jetzt mal abklären wer was bestellt. Sollen wir mal einen ICQ - Chat machen ? Oder eine Zeit / Datum wann die endgültige Liste gemacht wird. Wenn jemand die Bauteile incl. Speicher und Quarze bestellen könnte wäre das optimal
@ andreasengler Schreib mir mal was in ICQ, damit ich deinen Contact bekomme. Mein ICQ ist etwas kaputt...
Also alle die eine Platine möchten bitte bei mir per E-mail melden. Natürlich nicht die, die sich bereits (per email) bei mir gemeldet haben. Der Preis für eine Platine wird nicht mehr als 10 € + Versand kosten. Die Bestellung geht spätestens am Fr Nachmittag raus. MFG Andreas
DRAM und Controller können wir auch mitbestellen Controller etwa 12-13 € DRAM 1€ von alten Riegeln getestet aber ohne Garantie einfach in die Mail schreiben Die Quarze natürlich auch
Hmmmm, alte DRAM möchte ich nicht. Wo bekomme ich die DRAM-ICs denn neu?
Der 411616-60T-EDO dort ist genau der passende. Ein 50ns RAM wäre besser, aber der ist extrem selten.
Die Platine mit dem S1D13506 läuft wunderbar. Für alle die diese Platine haben, hier ein paar Dateien dazu (Testprogramm, Pinout, Anschluss an einen ATmega8515 usw.)
Habe meine gestern bekommen, danke an Andreas und an Benedikt für den Support! Jetzt muß ich nur noch diesen fitzeligen Epson-Controller auf die Platine bruzeln... Gruß, Matthias
Das habe ich vorgestern 3 Stunden lang gemacht: Controller war fertig draufgelötet, aber irgendwo war ein Kurzschluss zwischen Vcc und GND. Nach 2 Stunden ergebnisloser Suche habe ich den Controller wieder runter gelötet und komplett neu drauf. Danach ging alles.
Du machst mir Mut! Lötest du jeden Pin einzeln oder gehst du mit der Hohlkehle einmal drüber?
Ich bin das erste mal einmal quer drüber und hab dann das Lötzinn wieder mit Entlötlitze entfernt. Das Ergebnis sah optisch super aus, elektrisch war es auch OK, bis eben auf den einen Kurzschluss. Nach dem Ablöten und beim 2. Auflöten habe ich dann Pin für Pin in die Lötzinnreste gedrückt. Das sieht optisch nicht ganz so gut aus, aber es funktioniert. Ich würde auf jedenfall viel Löthonig, Flussmittel oder ähnliches verwenden. Vermutlich hatte ich zuviel Lötzinn anfangs drauf, das zwischen den Pins hindurch, unter das IC geflossen ist, und dort irgendwo einen Kurzschluss an einer Durchkontaktierung verursacht hat. PS: Ich spiele gerade mit dem 2D Beschleuniger von dem Controller. Der hat nette Features, u.a. kann dieser ein Byte (also 8 SW Pixel) auf 8 Bytes oder Words (je nachdem ob mit 256 oder 65536 Farben gearbeitet wird) erweitert in den Speicher schreiben. Optimal für Textdarstellungen. Der Controller wird übrigends leicht warm. Die Stromaufnahme mit dem Demoprogramm liegt bei 200-300mA, je nachdem ob der Controller neue Daten bekommt oder nicht. In etwa die Hälfte von dem Strom geht ans DRAM, das auch leicht warm wird.
Ein Mitarbeiter erzählte mir das bei einem softwareupdate von einem unserer Produkte vor 7-8 Jahren Chinesische frauen (war auch in china) die Flashs ausgelötet haben, und mit einem 40W löteisen wieder reingelötet. Die haben den an 2 ecken festgemacht und dann mit dem lötkolben drübergezogen (und lötzinn natürlich) brauch nur ein bisschen übung. ein ehem. mitarbeiter hat das auch immer so gemacht.Fans das schon immer krass. Verbrauche auch immer 1 rolle entlötlitze, grins
Hallo, ich verwende den S1d13504 mit etwas anderem Hardwareaufbau. Zumindestens möchte ich das, denn bisher läuft das TFT noch nicht. Da hier ja schon mindestens ein 13506 werkelt hätte ich mal ein paar Fragen: Sind die Bustreiber zum TFT wirklich nötig? Was ist, wenn man wie ich keine verwendet? Hat man überhaupt keine Chance ein Bild angezeigt zu bekommen, oder wird man nur anfälliger für EMV? Die Verbindung zwischen TFT und Controller ist bei mir ca. 30cm lang. Und: Wie funktioniert das mit der Kommunikation zwischen AVR und s1d13506 jetzt genau? Ich hab mir natürlich die Timingdiagramme reingezogen, das Datenblatt gewälzt und mir im Internet alles reingezogen, was ich gefunden habe. Aber irgendwie bin ich mir immernoch nicht sicher, ob ich das alles richtig mache. An sich würde ich gerne mit einem 16Bit Interface arbeiten, aber wenn es mit 8 laufen würde, wäre ich auch schon froh. Warum wertest du z.B. #Wait nicht aus? Uns in welcher Reihenfolge müssen die Signale kommen und wieder weggenommen werden? Müssen sie in einem bestimmten Verhältnis zu den Flanken des Bustaktes stehen? Ich tu mir immer etwas schwer, C-Programme nachzuvollziehen, weil ich C fast nicht kann. Es würde mich also wirklich freuen, wenn mir da jemand helfen kann. Sebastian
Sebastian K wrote: > Sind die Bustreiber zum TFT wirklich nötig? Nein, sind sie nicht. Der 13506 muss aber mit 5V laufen, da 3,3V DRAMs sehr selten sind. Daher haben auch die Ausgangssignale 5V Pegel. Ich habe aber auch LCDs die mit 3,3V laufen, daher habe ich Treiber mit 74LVC245 bestückt, die mit 3,3V laufen und 5V tolerant sind. Die Treiber haben auch einen weiteren Vorteil: Beim Messen an 50poligen Leitungen mit 0,5mm kommt man schnell mal zwischen die Kontakte. Dadurch legt man die LCD Spannung (bis zu 50V) auf die Datenleitung. Ich habe schon etliche Bustreiber gegrillt, der LCD Controller hat es aber bis auf einmal überlebt: Dieser eine hatte keine Bustreiber dazwischen... 30cm sind schon relativ lang. Achte vor allem bei dem Pixeltakt auf eine saubere Terminierung der Leitung. > Und: Wie funktioniert das mit der Kommunikation zwischen AVR und > s1d13506 jetzt genau? Einfacher als beim 13504. Der 13506 wird im ISA Modus betrieben. Datentransfers laufen über RD\ und WR\ ab, der Bus hat 16bits. Daten auf geraden Adressen werden über D0-7, Daten auf ungeraden Adressen über D8-15 übertragen. Sobald Daten über D8-15 aktiv werden, muss auch SHE (System Bus High Enable) aktiviert werden. Dazu verbindet man diesen Pin über einen Inverter mit A0, da dieser Low aktiv ist. Würde man A0 auf Low lassen, und SHE aktivieren (was ja eigentlich nicht passt, denn die Adresse ist gerade und es sollen Daten über D8-15 übertragen werden), dann erkennt der Controller, dass es eine 16bit Übertragung ist. Dieser Fall kann hier aber nicht vorkommen, da A0 und SBHE immer über den Inverter verbunden sind. Beim 13504 läuft das aber etwas anderst, da dieser nicht soviele Bus Modi unterstützt. Dieser besitzt aber die Option den Bus auf 8bit zu beschränken. Was diese Option bewirkt, konnte mir bisher niemand beantworten. Selbst eine Anfrage an Epson verlief sinnlos: Ich soll den Generic Bus Modus mit 16bit verwenden, und je nachdem ob die Übertragung auf einer geraden oder ungeraden Adresse läuft, RD0/WE0 oder RD1/WE1 aktivieren. Im Prinzip also die Schaltung die im Datenblatt als ISA Beispielschaltung oder unter "VR4102 to S1D13504 Interface" beschrieben ist. Der SHE Pin ist wieder der invertierte A0. > Warum wertest du z.B. #Wait nicht aus? Weil der AVR diesen Modus nicht unterstützt. Beim 13504 habe ich dies aber gemacht: Ein JK Flipflop wird mit 32MHz versorgt und erzeugt den Takt des AVRs. Solange WAIT high ist, toggelt das Flipflop und erzeugt 16MHz. Ist Wait Low, wird der Takt für den AVR solange angehalten, bis Wait wieder high ist. Die 32MHz sind auch der Bus und Speichertakt. Ohne die Taktbremse gingen einige Daten verloren, wenn der 13504 stark ausgelastet war (also große Displays angesteuert hat). Beim 13506 ist mir das noch nicht passiert, obwohl ich diese auch voll ausgelastet habe (viele BitBLTs + 800x600 Display). Der 13506 ist also intelligenter, wird dafür aber auch verdammt heiß (>40°C !) wenn er viel zu tun hat. Der Bustakt muss nicht synchron zu den Signalen sein, was die ganze Sache zum Glück vereinfacht. Allerdings ist erfolgt die Ausgabe vom Wait Signal synchron zum Bustakt. > Ich tu mir immer etwas schwer, C-Programme nachzuvollziehen, weil ich C > fast nicht kann. Es würde mich also wirklich freuen, wenn mir da jemand > helfen kann. Ich hätte auch noch einen Assembler Code mit Pseudo DMA Routinen für den AVR die es ermöglichen Daten mit theoretisch 1MByte/s in den 13504 zu laden. Insgesamt ist meine Ansteuerung für den 13504 mittlerweile ziemlich komplex, eben weil dieser DMA Schaltung, mit der ich Daten von einem FT245 direkt in den 13504 lade. Der AVR muss nur noch die Steuersignale erzeugen und die Adresse anlegen.
Dankeschön Benedikt. Da ist einiges dabei, das weiterhelfen könnte. Ich werd's jetzt mal noch mit den neuen Informationen probieren, und wenn mich der Frust packt weil doch nichts läuft, nehm ich einfach den 13506 mit dem Board von hier. DRam hab ich übrigens einen mit 3,3V ergattern können :-). Das Display will bei mir 3,3V, also läuft die ganze Schaltung auf 3,3V. Sebastian
Hallo Benedikt!
a)
Könntest Du noch ein Foto von der Unterseite der Platine hochladen?
Ich habe den Schaltplan und die Platine aber leider hat diese keinen
Bestückungsdruck. 90% der Teile sind zum Glück logisch wo die hin
gehören, aber zur Sicherheit wäre ein Vergleichsbild fein.
b)
Ich bin mir nicht ganz klar wie der Avr angebunden wird, weil das aus
deinem Plan nicht ganz klar hervorgeht.
Z.B. PA0 geht an 1D - 8D
PA1 geht an 1D - 8D
Ich konnte nach kurzem drüber schauen auch im Source Code kein Mapping
finden.
Muß aber auch zugeben das ich mit den Epson Controllern noch nie was
gemacht habe, obwohl mich so eine Ansteuerung schon lange interessiert
hat.
Vielen Dank auch nochmal an Andreas für die Pcbs!
LG
Michael
Angehängte Dateien:
-
s1d13506_unten.jpg
150 KB
Hier das Foto von der Unterseite. PortA0-7 -> D0-7 und D8-15 und an A0-7 über HC573 PortC0-7 -> A8-15 PortB0-4 -> A16-20 PortD5 -> Reset PortD6 -> WR\ PortD7 -> RD\ PortE0 -> MR PortE2 -> CS
Angehängte Dateien:
-
s1d13506_unten2.jpg
140 KB
Hier noch ein Bild von der Unterseite. Die Bauteilwerte kann man hier etwas besser erkennen. Die Kondensatoren sind alle 100nF oder irgendwas in der Richtung was gerade vorhanden ist.
Angehängte Dateien:
-
s1d13506_wait.gif
62 KB
Die Schaltung aus der Zip Datei ist so einfach wie möglich gehalten, funktioniert an sich auch, verstößt aber in ein paar Punkten gegen die Spzifikationen (u.a. beim Busclock und bei den Waits). Für den ersten Test reicht diese aber. Beides lässt sich umgehen, indem man den AVR nicht direkt mit einem Quarz, sondern über ein JK Flipflop versorgt: Solange WAIT\ inaktiv ist, toggelt das Flipflop vor sich hin und versorgt den AVR mit 33MHz/2=16,5MHz. Wenn WAIT\ aktiv Low wird, werden die Takte des AVRs gestoppt, solange bis der S1D13506 bereit ist und WAIT\ wieder deaktiviert. Dadurch kann man die Waitstates beim AVR Speicherinterface auf 1 Wait State reduzieren. Weiterhin stehen nun die 33MHz über den Busclock zur Verfügung, man kann diesen also als Speichertakt verwenden (Register 010h auf 0x01 setzen). Dadurch kann man CLKI nun mit einem anderen Quarz (z.B. 25,4MHz) bestücken was eine größere Vielfalt bei der Pixeltakt Auswahl ermöglicht. Dann sind folgende Pixeltakte in MHz möglich (zumindest bei CRT, bei LCD fallen die 2/3 Optionen weg): 33 33MHz 25,4 25,4MHz 22 33MHz*2/3 17,734 17,734475MHz 16,933 25,4MHz*2/3 16,5 33MHz/2 12,7 25,4MHz/2 11,823 17,734475MHz*2/3 11 33MHz/3 8,86724 17,734475MHz/2 8,4667 25,4MHz/3 8,25 33MHz/4 6,35 25,4MHz/4 5,9115 17,734475MHz/3 4,4336 17,734475MHz/4 Der AVR@16MHz am S1D13506 ist übrigends recht flott: Bei 640x480@8bpp schafft dieser (in Zusammenarbeit mit der BitBLT Engine) pro Sekunde: - 50 zufällige Linien (mit Längen zwischen 0 und 800 Pixel) - 130 zufällige, gefüllt Blöcke (mit Größen zwischen 0x0 und 256x256 Pixel) - 230 Speicher -> Speicher Kopien von 64x64 Bildern Das ganze in einem C Programm, in Assembler könnte man vor allem die Linienanzahl warscheinlich noch verdoppeln. Man kann damit also durchaus schöne Grafikoberflächen oder anderes Programmieren. Vor allem da der 13506 hardwaremäßig einen 64x64 großen Cursor mit 2 Farben + transparentem Hintergrund unterstützt.
Moin, ich hab da mal ne Frage wie man so schön sagt. Ich möchte gerne ein digitales Voltmeter über diesen Controller machen. Dabei ist es wichtig z.B. eine Hintergrundgrafik zu erstellen die auch gut aussehen soll. Das ganze wird dann einmal in den Controller eingelesen und gut. Jetzt meine Kompetensprobleme: Ich will recht große Zahlen mit Einheiten Bildschirmfüllend darstellen (die Hintergrundgrafik soll immer noch da sein). Um eine vernümftige Anzeige zu erzeugen sollen nur diese Zahlen 1 - 2 mal aktualisiert werden. Geht das mit nem Mega8 ... 168 als Bit-Schleuder. Es soll also nach meinem Verständnis Zahlen Fonts (einfarbig) auf buntem oder schwarzem Teilhintergrund (Rest ist bund aber Statisch) mit dem avr aktuallisiert werden. Den Fontspeicher eventuell Flash extern oder CF Karte (ist aber im Moment nicht wichtig). Schaffft der AVR das? Ich habe Probleme das auszurechnen und einen Testaufbau kommt erst noch. Ich möchte weiterhin das ganze am TV ausgeben, das sollte aber mit dem Controller dann wohl kein Problem mehr sein. Da ihr ja schon einige Versuche gemacht habt konnt ihr mir vieleicht etwas zu Zeiten sagen.
DRAMs: Nein. RAMDACs auf PCI Karten sind ziemlich selten. Ich habe zumindest noch nie welche gesehen, zu denen auch ein Datenblatt verfügbar war. Wenn diese kompatibel sind, sollte es gehen. Besser du verwendest einen richtigen Displaycontroller. VGA auf einem AVR ist möglich (was ich mit der Schaltung beweisen wollte), aber die Ladezeiten für ein Bild sind ziemlich lang, und die Prozessorauslastung sehr hoch.
Hier scheint jemand dein Projekt closed-source weiterentwickelt zu haben um mit deinem Projekt Geld zu machen: http://www.microvga.com/ Hier noch dein Code sogar auf dessen Seite, bevor er kommerziell wurde: http://www.tinyvga.com/avr-sdram-vga
Das ja fies .. sieh es als Lob an - fragt sich nur, wo der herkommt!
Ist ein Tscheche. Piss ihm doch ans Bein, der hat nichtmal ein Impressum auf seiner Seite. http://news.nic.com/cgi-bin/whois
Es ist leider schwer zu sagen, ob er diese Software verwendet. Hier sammelt er u.a. alle Projekte die etwas in der Richtung machen: http://www.tinyvga.com/ Dass er einfach alle Projekte ohne Genehmigung und ohne Angabe der Quelle auf seine Seite stellt, ist nach deutschem Recht bestimmt nicht ganz OK, aber egal. Ich vermute, er hat das ganze mit einem ARM oder sowas realisiert, denn er schreibt etwas von einem 2. UART (klar, es gibt auch AVRs mit 2 UARTs). Mit ARMs hat er ja auch schon Erfahrung: http://www.secons.com/en/index.html * Easy connection to almost every microcontroller using only 2 wires (minimum, 4 recommended) Klingt sehr nach einem UART mit RTS + CTS. Klar, kann man auch per Software machen, aber RTS ist etwas ungemütlich zu realisieren, ARMs machen das per Hardware. Weiterhin schreibt er von einer Auflösung von 800x600@60Hz: Das sind 40MHz Pixeltakt, das schafft ein AVR sicher nicht. Falls er also die Schaltung mit dem SDRAM verwendet hat, dann an einem ARM, dsPIC oder sowas. Wobei es bei einem ARM etwas schwerer ist, Taktgenau zu programmieren, da man nie wissen kann, wann der Core auf den Speichercontroller warten muss. Ich würde aber darauf tippen, dass er einen ARM mit TFT Controller verwendet hat. Davon gibt es ja einige. Wir werden es ja sehen, wenn er irgendwann Fotos der Platine auf die Seite stellt.
Ich habe bisher hier sehr interessiert mitgelesen und mir auch andere Beiträge zu dem Thema angeschaut. Ich würde gerne auch eine kleine GraKa basierend auf dem S1D13506 bauen. Im Moment stehe ich vor der Entscheidung, welchen MCU ich nehmen soll. Das Problem ist das Wait-Signal, was kaum einer unterstützt. Am liebsten wäre mir ein ARM7 oder ARM9 von NXP. Weiß jemand aus dem Kopf, ob einer davon das kann? Welche Alternative gibt es sonst noch? Taugen die AVR32 was und können die das? Bitbanging bei ARMs soll nicht so effektiv sein. Und mich nur auf Waitstates zu verlassen, halte ich zu kritisch. Viele Fragen :)
Super Thema, nur leider erst jetzt gefunden. Ich beschäftige mich jetzt auch endlich mit TFT´s siehe: Beitrag "Xmega Programmierung in ASM". Bin dabei allerdings schon frühzeitig auf die Grenzen des Xmega gestoßen und möchte das jetzt auch über einen Epson Controller lösen. Hat vielleicht noch jemand eine fertige Platine mit S1D13506 oder auch nur eine Platine hier aus diesem Tread rumliegen, die er gerne an mich loswerden wollte?? *zwinker LG Steffen
Ich hatte bis vor ein paar Wochen noch eine, mittlerweile ist die aber weg. Sorry! Wenn sich genug Interessenten finden, könnte ich welche bestellen. Mangels Zeit würde ich mich aber nur um die Platinen kümmern.
Schade Micha. Ich warte mal noch eine Weile ob sich doch noch jemand meldet. Wenn nicht wär ich schon mal an 2 Stück interressiert. Hatte auch schon überlegt, ob ich mir einfach eine machen lasse. Aber mit einer Sammelbestellung wird das alles weit aus günstiger. LG Steffen
Wobei ich auch dazu sagen muss, dass ich nicht aktiv suchen werde, sondern nur den Thread hier verfolge. Also wer Interesse hat muss sich hier melden. Preislich sieht es wie folgt aus: Menge 8AT 12AT 2 $ 14,33 $ 13,42 5 $ 7,76 $ 7,27 10 $ 6,02 $ 5,63 15 $ 3,65 $ 3,42 20 $ 3,26 $ 3,05 25 $ 2,79 $ 2,61 30 $ 2,48 $ 2,32 40 $ 2,10 $ 1,96 50 $ 1,94 $ 1,82 75 $ 1,57 $ 1,47 Zzgl. Versand und EUSt.
Gibts jetzt 'ne neue Sammelplatine oder bin ich zu spät? Gruß Michael
Steffen H. schrieb: > Ich wäre immer noch dabei mit 2 Stück. Naja Preise stehen oben. In etwa dürften die noch stimmen. Wie gesagt, wenn ein paar Leute zusammen kommen oder jemand bereit ist das zu bezahlen, ist das mit der Bestellung kein Thema.
Hallo, ich überlege mir ob ich die Platine für mich nachbaue und bin auf einige Fragen gestossen: - Als Display würde ich maximal das Display (800x600x16Bit Farbtiefe) im Anhang nehmen wollen, z.B. von Reichelt oder Glyn - Wo bekomme ich den noch neuen Ram für dem Epson Controller her? Kann auch gerne Digikey und Co. sein. Vielleicht gibt es ja eine Sammelbestellung. Ich glaube nicht mehr, das ich noch alte Edos herumliegen habe, warhscheinlich alles entsorgt. - Gibt es einen "aktuelleren" Grafikcontroller der auch über einen VGA Ausgang verfügt. Bei Epson bin ich nicht fündig geworden Unschlüssig bin ich mir bei den Anschlüssen des TFTs an das Display. Display Epson ENB DRDY HSYNC FPLINE VSYNC FPLINE DCLK FPSHIFT R0..R5, G0..G5 B0..B5 entsprechend der Tabele 5.9 auf Seite 34 des S1d13506 Controllers. Stimmt das soweit? Grüße Peter
Peter schrieb: > - Wo bekomme ich den noch neuen Ram für dem Epson Controller her? Kann > auch gerne Digikey und Co. sein. Vielleicht gibt es ja eine > Sammelbestellung. Ich glaube nicht mehr, das ich noch alte Edos > herumliegen habe, warhscheinlich alles entsorgt. Ich hatte meinen damals bei Ebay bekommen. Such mal dort. Es gibt viele die irgendwelche Restbestände dort verkaufen. > - Gibt es einen "aktuelleren" Grafikcontroller der auch über einen VGA > Ausgang verfügt. Bei Epson bin ich nicht fündig geworden Wieso muss er aktueller sein? Reicht der "alte" (hier verwendete) S1D13506 nicht?
Hallo, ich werde mal ab und an bei Ebay vorbeischauen. Warum einen aktuelleren? Weil es ja Epson Grafikcontroller mit integ. Ram gibt, aber entweder ohne VGA oder nicht als Hobbyist zu löten. Da ich die Grafikkarte ein paar Jahre nutzen wollte, wäre es doof ein solche auf meine Bedürfnisse anzupassen und in 2 Jahren am EDO-Ram Problem (Beschaffbarkeit) zu scheitern. Aber momentan sehe ich keine andere Möglichkeit als zu suchen. Grüße Peter
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.