Hallo zusammen, Ich habe eine Frage zu einem Projekt. Und zwar möchte ich mein Display mit dem Development-Board STK500 ansteuern. Meine Frage nun: Ist dies überhaubt möglich? Welcher uP ist am besten geeignet? Benötige ich sonst noch Peripherie? Gruss Dexter Display: http://www.mikrocontroller.net/attachment/50452/ET057007DHU.pdf Board: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2735
Dan lag ich mit meinen Vermutungen wohl richtig... Welcher Typ wäre dann ein geeigneter? (Nicht für dieses Board) Bzw. auf was muss ich achten? Peripherie? (RAM, FLASH, ENCODER,...?)
Für solche Displays gibt es eigentlich vier Möglichkeiten: a) zusätzlicher Display-Controller, z.B. Seiko Epson S1D13505. Dieser wird dann vom AVR angesteuert. Da der Mikrocontroller entlastet wird, kann er klein und einfach sein. Allerdings muß man die Bilddaten auch irgendwo speichern können. b) Mikrocontroller mit integriertem Interface für LCD-Panel. Das sind immer große Typen, meistens ARM9-basiert, und oft nicht mehr ganz einfach in der Handhabung c) großer ARM7 oder ARM966T Mikrocontroller, z.B. LPC2378 oder STR9-Typen. Zusammen mit externem SRAM kann dann das Display komplett in Software bedient werden. Der Ressourcenverbrauch ist erheblich, das Timing nicht ganz unkritisch. Allerdings ist diese Lösung unter Umständen billiger als die anderen. d) Display über programmierbare Logik (wahrscheinlich FPGA, eventuell großes CPLD) bedienen, dies erfordert jedoch Kenntnis einer Logikbeschreibungssprache (VHDL, Verilog, ggf. ABEL)
Sorry, Falk, aber der Link ist unzutreffend. Dort geht es nur um Text ("Character")-LCDs, nicht um ein unintelligentes Grafikdisplay (TFT-Panel) wie hier.
Ich brauche ja eigentlich 3Byte (RGB), Vsync, Hsync Der Controller hat allerdings keine 3Byte..!? Ich fände es interessanter die Ansteuerung selbst zu realisieren. Kritisch ist dann eben das Timing. 2ter AVR hatte ich auch mal als Idee. Allerdings müsste es ja immernoch ein Grösserer sein!? Idee: Ein AVR führt Berechnungen usw. druch. Sobald er ein Bild hat wird dieses in einem Speicher abgelegt. Dem 2ten AVR wird dies mitgeteilt und das neue Bild wird geladen. Der zweite wäre dann also nur da, um die CLKs zu generieren und die Pixeldaten bereithalten. Habe ich da richtige Vorstellungen oder liege ich völlig falsch?
Für das Display braucht man einen VGA Controller ohne RAMDAC, der die Videodaten digital einspeisen kann. Für einen 8 Bit Atmel die Farbtiefe von 16,7 Mio Farben auf 256 Farben reduzieren, einen XMega und ein FPGA mit Dual Port RAM Controller + 1 MByte RAM für VGA Controller und Atmel als Bildspeicher. Ist ein anspruchsvolles Projekt aber interessant. Gruß, dasrotemopped.
Ein normaler ATMEGA ist zu langsam. Bei dem vom Display gefordernen Takt von über 20 MHz kann er nicht einmal die Takterzeugung übernehmen. Er könnte natürlich die Bilddaten in den Videospeicher schreiben. Ein XMEGA ist im Speicherzugriff zu langsam, um die Daten in Echtzeit zur Verfügung zu stellen. Also, wenn man selber bauen will: - muß der Bildspeicher (RAM) über (programmierbare) Logik bedient werden. - muß der Zugriff auf den RAM von beiden Seiten erfolgen können, vom Atmel aus schreibend und vom Display aus lesend. Da Dual-Port in der benötigten Größe teuer ist, muß man zwei Zugriffszyklen einplanen, einen, in dem der AVR schreiben kann (aber nicht muß) und einen zweiten, in dem das jeweils nächste Datenwort auf das Display gegeben wird. Das ist ganz schön knackig, man landet da bei etwa 20 ns Zugriffszeit für den Speicher. Das kann man mit Masse bewältigen (große Speicherbank aus SRAMs) oder mit Intelligenz, indem man die Datenbusbreite des Speichers erhöht, in einem Lesezyklus vier Bytes einliest, im CPLD/FPGA puffert und diese in vier folgenden Zyklen an das Display ausgibt. Dann würde nur in jedem vierten Zyklus auf den RAM zugegriffen werden. Übrigens kann man dann billigen DRAM verwenden - da man ständig liest, braucht man keinen Refresh mehr.
Also würde es eigentlich mit einem FPGA (Altera CyclonII) funktionieren!? (SRAM, RAM, Flash vorhanden) Habe ich das richtig verstanden?
Ein sehr schönes Thema! Die Lösung über einen FPGA interressiert mich auch. Hab es mit eimnem XMega Versucht. Leider stimmt es, dass der Speicherzugriff zu langsam ist. siehe: Beitrag "Re: Xmega Programmierung in ASM" Xmega Programmierung in ASM Beitrag "Re: Xmega Programmierung in ASM"
Ja, mit einem FPGA kann man so ein Display ansteuern. Ein einfaches Beispiel (in Verilog) wird bei fpga4fun.com beschrieben: http://www.fpga4fun.com/GraphicLCDpanel.html Allerdings ist dies alles nur ein Teil vom ganzen, denn das Beispiel ist a) nur schwarzweiß und b) werden nur statische Muster erzeugt, den RAM spart man sich hier. Ein Cyclone II ist schon ziemlich mächtig. Natürlich kann man so ein Display damit ansteuern, aber auch kleinere FPGAs genügen bereits. Aus der Firma kenne ich ein Kundengerät, bei dem ein unintelligentes (s/w-)Panel mit einem "ACEX" EP1K30 (+SRAM) angesteuert wird. Die Hardware würde wahrscheinlich auch für Farbe reichen, der RAM ist so groß, daß ich vermute, die arbeiten mit mindestens zwei umschatbaren Speicherbänken. Das ist gar nicht unpraktisch, denn wenn man eine Möglichkeit vorsieht, synchron zum Bild-Refresh die genutzte Speicherseite umzuschalten, und eventuell bei einem Refresh den Inhalt einer Speicherseite in die nächste zu kopieren, so spart man sich das "Interleaving", das Ineinanderschachteln von Schreib- und Lesezugriffen. Ein solches Projekt interessiert mich eigentlich auch - alternativ auch Erzeugung eines VGA-Signals -, aber ich verstehe letztendlich doch zu wenig von FPGAs, um es wirklich in Angriff zu nehmen.
ein Cyclone I reicht schon aus um einen 8 Bit Prozessor plus VGA Controller (mit 64 Farben und 512 kByte Framebuffer) im FPGA zu implementieren. Bei grösseren FPGAs reichts dann für einen 32 Bit Prozessor und High Colour VGA Controller mit ein paar MB RAM. Es gibt Eval Boards,die das schon fertig aufgebaut anbieten, meisst mit massig Peripherie drumherum : http://home.arcor.de/markus.horbach/bilder/fpga_cyclone.jpg Die Kunst wäre es jetzt, ein kleinen FPGA oder grossen CPLD so zu programmieren, dass ein XMega sein externes RAM über einen FPGA ansteuert, der den DualPort RAMcontroller und den VGA Controller enthält. Das uVGA/TinyVGA Projekt benutzt z.B. einen Xilinx + RAM, nur die Schnittstelle zum uC ist halt eine serielle und kein Speicherinterface. Ich denke, ich könnte zu dem Projekt was beitragen, aber allein würde ich das jetzt auch nicht stemmen wollen. Gruß, dasrotemopped.
Für den Hobbybereich ist ja eigentlich eine Low-Cost Lösung interessant. Kaum einer wird hier BGA löten wollen, und ein teures Board zu opfern nur als Displaycontroller ist auch nicht jedermanns Sache. Aber da hier offensichtlich genug Fachwissen für so eine Abschätzung vorliegt, mal eine Frage an meinen Vorredner: Wenn man sich tatsächlich auf das absolute Minimum beschränkt, wieviel Makrozellen bräuchte man denn in einem CPLD? Meiner bescheidenen Erfahrung nach lohnt sich ein CPLD preislich eigentlich nur bis 64 Makrozellen, die 128er sind schon recht teuer, so daß man dann eventuell bereits einen kleinen FPGA nehmen könnte. Das Design auf zwei kleine CPLDs aufzuteilen kann sogar billiger sein als ein doppelt so großer, falls technisch möglich.
Um einen Framebuffer von 1 MB Speicher bei 8 Bit addressieren zu können benötigt man 20 Adressleitungen+ 8 Datenleitungen und noch ein paar Steuerleitungen, so das man auf mindestens 32 IO Pins am FPGA braucht um den uC anzuschliessen, ebensoviele Leitungen braucht man für den RAM Baustein selbst. Der VGA Port braucht 8 Datenleitungen für die Farbinformationen und HSync + VSync. Ein 25 MHz Clock für 640x480 Punkte Auflösung muss auch noch eingespeisst werden. 32 + 32 + 10 + 1 = 75 IO-Pins am FPGA minimum. Damit es hinterher nicht an einem Mangel an IOs scheitert würde ich einen Cyclone I im TQFP-144 Gehäuse wählen wie diesen hier : 544-1058-ND ( Digikey ArtNr für ca 15 Euro ). Da kann man den XMega ruhig mit 8 MB Speicher ausstatten, genug IOs sind dann vorhanden und Platz für Grafik sollte man im Speicher vorsehen und nicht nur den Framebuffer. Ist dann auch kompatibel mit den Eval Boards für den Xmega. Wieviel Makrozellen dann wirklich nötig sind kann ich so nicht sagen, aber ich denke, das der Cyclone EP1C6T144C8 ausreichen sollte. Ggf. reicht der Platz noch für einen Coprozessor für die Grafik ( Linien und Rechtecke zeichnen ) oder Zusatzperipherie. Beim Synthetisieren der FPGA Schaltung kann man ja schnell sehen, ob es passt, da hat man ja dann noch kein Geld für Hardware ausgegeben, also kein Risiko. Das gesammte Board sollte sich für unter 50 Euro Hardwarekomponenten realisieren lassen, das liegt im Rahmen für eine Hobbyentwicklung. Allerdings ist das Niveau nicht gerade einsteigerfreundlich. Gruß, dasrotemopped.
Dex Dexter schrieb: > Hallo zusammen, > > Meine Frage nun: Ist dies überhaubt möglich? Welcher uP ist am besten > geeignet? > Gruss Dexter > > > Display: http://www.mikrocontroller.net/attachment/50452/ET... > Board: http://www.atmel.com/dyn/products/tools_card.asp?t... Vielleicht probierst du einen AVR32: http://www.elektronik-projekt.de/thread.php?threadid=4404&threadview=0&hilight=&hilightuser=0&page=1 5 letzter Beitrag auf der ersten Seite ( mit dem kleinen Video) Gruß, Daniel
Nein, bleib bei fpga :) Das interresiert mich nämlich viel mehr. Ich bin auch gerade dabei in das Thema einzusteigen... Aus (anfänglich) Spass (naja nicht mehr wirklich) bin ich dabei ein Platine für einen fpga zu entwickeln, vielmehr versuche ich die Design Regeln für solch ein hochfrequentes Board zu entdecken. Nun habe ich z.B. gelesen, dass man darauf achten soll das die Länge der Leiterbahn zu einem Pfostenstecker alle gleich lang sowie gleich ohmig sein sollten? Wo kann ich in Eagle die länge einer Leiterbahn anschauen bzw. ihren ohmischen Wert? Desweitern habe ich gelesen, dass unbedingt mehrere Layer fürs saubere Routen der verschiedenen Versorgungsspannungslayer benutzt werden sollten? Das würde ja einen Selbstbau wider erschweren? Macht mich mal schlau. mfg jonas Biensack
haha schrieb: > z.B. gelesen, dass man darauf achten soll das die Länge der Leiterbahn > zu einem Pfostenstecker alle gleich lang sowie gleich ohmig sein > sollten? Wo kann ich in Eagle die länge einer Leiterbahn anschauen bzw. > ihren ohmischen Wert? Desweitern habe ich gelesen, dass unbedingt > mehrere Layer fürs saubere Routen der verschiedenen > Versorgungsspannungslayer benutzt werden sollten? Das würde ja einen > Selbstbau wider erschweren? http://www.elektronikpraxis.vogel.de/leiterplatten/articles/63952/ Kannst du nachbestellen bzw. kostenlos bekommen (ganz unten)
Daniel V. schrieb: > http://www.elektronikpraxis.vogel.de/leiterplatten/articles/63952/ > 20-Lagen-Multilayer-Aufbau > Übertragungsbandbreiten von bis zu 60 GBit/s MF (meine Fresse!)
@jonas Impedanz != ohmscher Widerstand Schau mal auf der Webseite von Polar Instruments die gut erklärten Dokumente zu impedanzkontrollierten Leiterplatten an( Impedanzkontrolle->Applikationsschriften ). Und in Sachen FPGA erst mal mit kleineren Brötchen anfangen : http://www.pyroelectro.com/tutorials/cpld_board/index.html Wenn du weisst, was du tun musst ist auch Eagle ausreichend fürs Layout. Gruß, dasrotemopped.
Dann werd ich das mal mit dem FPGA versuchen. Bin gespannt wie gut das geht. Mein Ziel ist es, eine SD-Card oder HardDisk auszulesen und auf dem Bildschirm darzustellen (FileExplorer). Dann hab ich mal eine Grundstruktur und kann darauf aufbauen.;) Mal schauen was dabei so rauskommt. Meine Ergebnis werde ich dann euch hier mitteilen.;) Gruss
Das angegebene Display hat auf der Rückseite einen Zusatzprint, welcher diverse Spannungen erzeugt. Weiss jemand ob es von diesem ein Schema gibt, oder ob man den einzeln irgendwo bekommt? ( http://www.mikrocontroller.net/attachment/50452/ET057007DHU.pdf )
Hallo zusammen, Ich habe nun mit dem Projekt begonnen und habe mal eine Frage. Beim FPGA will ich einen NIOS II generieren für die Display-Ansteuerung. der SOPC-Builder hat einen "Video Sync Generator". Jedoch schaffe ich es nicht,diesen zu integrieren und richtig anzuschliessen. Weiss jemand was es da sonst noch alles dazu braucht, oder wie ich den anschliessen muss? Gruss Dexter
dann zeigt doch mal wie dein Projekt bis jetzt aussieht ( Schaltplan, Konzept, usw. ). Aus dem Nios schliesse ich mal ein Altera FPGA. Soll der Nios den Atmel ersetzen ? Gruß, dasrotemopped.
Ja der AVR wird mit einem FPGA von Altera (Cyclon II) ersetzte. Konkret vorerst mal mit dem Demoboard DE1. Da ja zuerst alles eingerichtet werden muss hab ich noch nicht so viel das ich zeigen kann.;) Als erstes möchte ich einfach mal das Display synchronisieren und ein festes bild aus dem Speicher ausgeben. Dann kann weiter gearbeitet werden. Display: http://www.mikrocontroller.net/attachment/50452/ET057007DHU.pdf
Ah ja, dann ist aus dem Hardwareprojekt ein reines FPGA Software Projekt geworden. Das Demoboard sieht ganz vernünftig aus, hat ja schon alles onboard für ein uC Softcore System mit VGA Ausgang. Von der Quartus Software habe ich zu wenig Ahnung als das ich da Tips geben könnte. Gruß, dasrotemopped.
Ja in einem ersten Schritt wird das ganze mal mit dem Demoboard gelöst. Später dann noch die Hardware selbst nachgebildet.
Display wird übrigens nicht über den VGA-Anschluss angesteuert sondern über normale Pins die ohne Zwischenstufe.
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.