Forum: Mikrocontroller und Digitale Elektronik Display mit AVR


von Dex D. (dexter)


Lesenswert?

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

von FlipFlop (Gast)


Lesenswert?

Dieses Display wirst du nicht mit einem kleinen atmega steuern können.

von Dex D. (dexter)


Lesenswert?

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,...?)

von Falk B. (falk)


Lesenswert?


von Sebastian (Gast)


Lesenswert?

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)

von Sebastian (Gast)


Lesenswert?

Sorry, Falk, aber der Link ist unzutreffend. Dort geht es nur um Text 
("Character")-LCDs, nicht um ein unintelligentes Grafikdisplay 
(TFT-Panel) wie hier.

von *__* (Gast)


Lesenswert?

2ten avr, der die ansteuerung übernimmt?

von Dex D. (dexter)


Lesenswert?

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?

von dasrotemopped (Gast)


Lesenswert?

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.

von Sebastian (Gast)


Lesenswert?

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.

von Dex D. (dexter)


Lesenswert?

Also würde es eigentlich mit einem FPGA (Altera CyclonII) 
funktionieren!?
(SRAM, RAM, Flash vorhanden)

Habe ich das richtig verstanden?

von Steffen (Gast)


Lesenswert?

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"

von Sebastian (Gast)


Lesenswert?

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.

von dasrotemopped (Gast)


Lesenswert?

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.

von Sebastian (Gast)


Lesenswert?

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.

von dasrotemopped (Gast)


Lesenswert?

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.

von Daniel V. (danvet)


Lesenswert?

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

von haha (Gast)


Lesenswert?

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

von Daniel V. (danvet)


Lesenswert?

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)

von (nicht "Gast") (Gast)


Lesenswert?

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!)

von dasrotemopped (Gast)


Lesenswert?

@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.

von Dex D. (dexter)


Lesenswert?

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

von Dex D. (dexter)


Lesenswert?

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 )

von Dex D. (dexter)


Lesenswert?

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

von dasrotemopped (Gast)


Lesenswert?

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.

von Dex D. (dexter)


Angehängte Dateien:

Lesenswert?

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

von dasrotemopped (Gast)


Lesenswert?

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.

von Dex D. (dexter)


Lesenswert?

Ja in einem ersten Schritt wird das ganze mal mit dem Demoboard gelöst.
Später dann noch die Hardware selbst nachgebildet.

von Dex D. (dexter)


Lesenswert?

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
Noch kein Account? Hier anmelden.