Hallo,
ich habe etwas Erfahrung mit Text-LCDs (an einem Mega8) gesammelt, würde
mir aber nun gerne ein TFT-Display (800x480 mit integriertem
DisplayController und eigenem Speicher, 64k Farben/besser 16Mio)
zulegen.
Nach Durchsicht unzähliger Forumsbeiträgen bin ich allerdings immernoch
unsicher, welche Hardware ich mir zulegen sollte.
Gerne würde ich einen 8-biter wie den AtMega64 verwenden, allerdings
habe ich immer wieder gelesen, dass diese zu langsam sind (oder nur
falls diese als DisplayController eingesetzt werden???).
Wo genau ist der Flaschenhals (langsamer Bildaufbau etc.)? Evtl. die
Schnittstelle zwischen MicroController und DisplayController?
Wie und wo speichere ich die Bild-Daten, die vom MicroController an den
DisplayController gesendet werden. Der Programmspeicher des Mega64, mit
seinen 64KB ist ja schnell ausgeschöpft! Evtl. auf einer SD-Card?
Welches Interface ist zu bevorzugen: SPI, RGB, RD/RW???
Wie siehts z.B. mit dem STM32F4 (32 bit) als Alternative aus, eignet
sich dieser evtl. besser?
Vielleicht das stm32f4 Discoveryboard mit TFT-expansion board
(allerdings nur 3.5 Zoll mit 320*240 ), gibts aber sicher grössere
anschliessbare TFTs!?
Grüsse
Uwe
Hi,
Uwe schrieb:> Gerne würde ich einen 8-biter wie den AtMega64 verwenden, allerdings> habe ich immer wieder gelesen, dass diese zu langsam sind (oder nur> falls diese als DisplayController eingesetzt werden???).
Hast du dich mit Videosignalen schon mal beschäftigt?
Rechne mal den Pixelclock aus: 800 480 50Hz = 19,2 MHz.
Oder denn Speicher den du dafür benötigst? 800 480 1(8Bit) = 375
KiB.
Wie du das mit einem AVR realisieren willst ist mir schleierhaft.
Du musst wohl oder übel einen größeren Mikrocontroller nutzen.
Uwe schrieb:> Welches Interface ist zu bevorzugen: SPI, RGB, RD/RW???
Laß uns einmal rechnen: 800 x 480 x 3 (byte/pixel) = 1,152e6.
Nimm eine Schnittstelle, die 1µs braucht, um ein Pixel zu schreiben: ein
neues Bild braucht dann 1,15 Sekunden, bis es von oben nach unten fertig
geschrieben ist.
Jetzt mußt Du entscheiden, wieviel Bilder Du pro Sekunde ausgeben
möchtest und was dann noch an sinnvollen Schnittstellen übrig bleibt.
Wenn das TFT einen "integrierten" Display-Controller hat, dann
könnte das per SPI, evtl. auch mit nem ext Daten-/Adressbus
funktionieren
(z.B. Atmega128). Dazu muss man die Adressen des Framebuffers allerdings
"seriell" übertragen können bzw. mit indirekter Adressierung.
Wenn das TFT "direkt" per uC betrieben werden soll, dann muss ein
passender Controller her:
1.
Renesas RX62N mit Direct-LCD (DDLCD)
Es wird extern ein SDRAM angeflangscht und per EXT-DMA Modul direkt vom
RAM ins Display geschaufelt. (Ist allerdings für "Anfänger" wohl eher
ein Graus)
2.
Es gibt Cortex-M3 basierte uC, die ein Grafikcontroller integriert
haben.
Im Moment weiss ich nur von NXP, dass die einen haben. Benötigt
allerdings ebenfalls ext. RAM als Framebuffer.
3.
Es gibt in der Richtung DDLCD auch von anderen Herstellern Konzepte, das
ohne ext. Grafikcontroller zu machen. Mit einem Grafikcontroller wird
das "normalerweise" einfacher, allerdings erst nachdem man die paar
hundert Seiten Hardware Manual durch hat ;-)
Soll das nur zu deinem Privatvergnügen sein, dann gibt es diverse
"intelligente" Displays. Allerding würde ich es für den Anfang mal mit
Grafikdisplays probieren, die nicht gerade 800x600 Pixel haben.
Mal ein paar BEispiele:
http://www.lcd-module.de/produkte/edip.htmlhttp://www.lcd-module.de/produkte/grafik.html
Ich hab schon mit nem DOGL128-6 hantiert. Die Zuordnung der Pixel im
Display-RAM ist zwar ein Graus (1 Byte = 8-Pixel vertikal), aber man
kann das Teil relativ schnell in der Griff kriegen.
Uwe schrieb:> Seh ich das richtig? Im Idealfall braucht die Schnittstelle 17ns für ein> Pixel (bei 50Hz)??
Vorsorglich erst einmal: nein
Nachsorglich: was ist "die Schnittstelle"?
Matthias schrieb:> Renesas RX62N mit Direct-LCD (DDLCD)> Es wird extern ein SDRAM angeflangscht und per EXT-DMA Modul direkt vom> RAM ins Display geschaufelt. (Ist allerdings für "Anfänger" wohl eher> ein Graus)
Ein Graus? Nicht unbedingt - es gibt fertigen Code dafür.
Was bei Renesas' 'direct drive' aber gemacht wird, ist ohne Multitasking
sehr ungünstig. Während der Bildausgabe darf der Transfer nicht gestört
werden. Ganz grob gesprochen ist der Bildspeicher 8ms für die Ausgabe
blockiert und die nächsten 8-10ms für Zugriffe frei.
Wenn man ungeschickt programmiert, dauert die Zeichen-/ Bildausgabe
unnötig lange.
m.n. schrieb:> Vorsorglich erst einmal: nein> Nachsorglich: was ist "die Schnittstelle"?
Ich bezog mich auf folgenden Beitrag.
m.n. schrieb:> Uwe schrieb:>> Welches Interface ist zu bevorzugen: SPI, RGB, RD/RW???>> Laß uns einmal rechnen: 800 x 480 x 3 (byte/pixel) = 1,152e6.>> Nimm eine Schnittstelle, die 1µs braucht, um ein Pixel zu schreiben: ein> neues Bild braucht dann 1,15 Sekunden, bis es von oben nach unten fertig> geschrieben ist.> Jetzt mußt Du entscheiden, wieviel Bilder Du pro Sekunde ausgeben> möchtest und was dann noch an sinnvollen Schnittstellen übrig bleibt.
gruss
Uwe
Bei der Berechnung ging ich davon aus, dass ein AVR wohl nicht mehr als
ein Byte/µs in den Display-Controller schreiben kann. Hier eine
Hochrechnung für 50 Bilder/s anzustellen, ist sinnlos. Größere µCs
schreiben mit 16 oder 32 Bit Datenbreite. Das ist die eine
Schnittstelle.
Die zweite Schnittstelle ist die RGB-Übertragung vom Display-Controller
zum TFT selbst. Ein 800x480 TFT wird typisch mit 60Hz aufgefrischt, was
dann bei 24 Bit Datenbreite mit 33MHz erfolgt.
Wie oben schon angedeutet, solltest Du mit einem kleinen Display (z.B.
320x240) anfangen, um einen ersten Überblick zu bekommen.
Die EVE-Teile wurden ja schon erwähnt. Dazu gibt es auch fertige Module,
die auch Texte über interne Zeichensätze ausgeben können.
http://www.digikey.de/product-search/de/optoelectronics/display-modules-lcd-oled-graphic/524918?k=ftdi%20eve
Uwe schrieb:> Problem is wohl der Anschluss:
45 polig im 0,3mm Raster? Viel Vergnügen bei der Suche nach
Steckverbindern. Es ist übrigens ein 4" Display; ggf. Lupe gleich
mitbestellen.
> http://www.ebay.de/itm/7-inch-TFT-LCD-module-800x480-SSD1963-w-touchpad-PWM-arduino-AVR-STM32-ARM-/121017488870
Das sieht besser aus, obwohl in der Beschreibung auch einmal 5"
auftaucht.
Die Kabel sollten so kurz wie möglich sein. Eine 'problemlose' Nutzung
mußt Du Dir wohl erarbeiten :-)
Ansonsten, probiere es aus, am besten gleich mit einem STM32F4..!
Nabend,
m.n. schrieb:> Bei der Berechnung ging ich davon aus, dass ein AVR wohl nicht mehr als> ein Byte/µs in den Display-Controller schreiben kann.
Wie schnell kann ich denn Daten in einen DisplayController mit dem
STM32F4 (180MHz) schreiben (mit 8/16/18bit µC Interface)?
m.n. schrieb:> Ein 800x480 TFT wird typisch mit 60Hz aufgefrischt, was> dann bei 24 Bit Datenbreite mit 33MHz erfolgt.
Mal angenommen ich "übergehe" den DisplayController und mache das ganze
mit dem RGB-Interface! Sind da 60 Bilder/sec realistisch (mit 800x480x3,
d.h dann wohl ca. 1,152 MB in 1/60 sec)? Müsste der STM32F4 doch locker
schaffen mit 5ns-Periodendauer.
Welche PCLK sind denn möglich?
Gruss
Uwe
Uwe schrieb:> wohl ca. 1,152 MB in 1/60 sec)? Müsste der STM32F4 doch locker> schaffen mit 5ns-Periodendauer.
Bei 70 MByte/sec, also 14 nsec pro Byte, wirst Du mit Deinen 5 nsec
nicht weit kommen -- immerhin müsste der Controller die Daten ja auch
noch irgendwo hernehmen ...
>> wohl ca. 1,152 MB in 1/60 sec)? Müsste der STM32F4 doch locker>> schaffen mit 5ns-Periodendauer.>>Bei 70 MByte/sec, also 14 nsec pro Byte, wirst Du mit Deinen 5 nsec>nicht weit kommen -- immerhin müsste der Controller die Daten ja auch>noch irgendwo hernehmen ...
Wenn er Video schauen will sollte er sowieso besser ein Tablett kaufen;)
Uwe schrieb:> Mal angenommen ich "übergehe" den DisplayController und mache das ganze> mit dem RGB-Interface!
Das würde sogar gehen, wäre aber bei Deinem jetzigen Wissensstand reine
Spinnerei.
Hol Dir das oben erwähnte Display mit dem SSD1963-Controller und staune,
was er Dir alles an Arbeit abnimmt.
holger schrieb:> Wenn er Video schauen will sollte er sowieso besser ein Tablett kaufen;)
Wer Gläser und Teller balancieren will, nimmt ein Tablett. Du meinst
bestimmt ein Tablet ;-)
Hallo Uwe,
was genau hast du denn vor? Willst du Videos abspielen oder mehr oder
weniger statische Bilder anzeigen, deren Aufbau Zeit hat? Ein Display
mit eigenem Controller und RAM kann von (so gut wie) jedem Controller
angesteuert werden. Mittlerweile gibt es auch 5" Varianten für kleines
Geld.
Wo der Engpass liegt hängt von deiner Anwendung ab. Wo kommen die Daten
her? Muss der Controller sie erst berechnen oder nur aus einem Speicher
zum Display übertragen? Wie oft ändert sich das Bild? Ändern sich nur
Teilbereiche oder immer alles? ...
Vielleicht hast du bei deiner Suche auch mein KNX-Display gesehen. Es
benutzt einen ATMEGA128 bei 8MHz mit etwas Zusatzhardware und braucht
für den Refresh eines 320x240 Display ca. 300ms. Heute würde ich das
System vielleicht etwas anders aufbauen. Es kommt aber immer auf das
Ziel und die verfügbaren Mittel an. Also: Was genau soll deine Anwendung
machen?
Arno
Nabend,
m.n. schrieb:> Hol Dir das oben erwähnte Display mit dem SSD1963-Controller und staune,> was er Dir alles an Arbeit abnimmt.
Ok. Werde es wohl oder übel ertmal mit dem SSD1963 oder Kompatiblem
versuchen.
Arno schrieb:> was genau hast du denn vor?
Genau genommen soll auf dem Display ein Tachometer dargestellt werden,
der die Umdrehungszahl eines Lüfters (Umdrehungszahl regelbar) anzeigt.
Die Grafik sollte auch etwas aufwendiger sein!
Die Bewegung der Tachonadel sollte möglichst flüssig sein, d.h. keine
plötzlichen Sprünge zum eingestellten Umdrehungszahlwert.(evtl. kleine
Verzögerung programmieren!?)
Es werden sich wohl nur Teilbereiche des Bildes ändern (Tachonadel).
Demnach muss dann nicht das ganze Bild aktualisiert werden.
Grüsse
Uwe
Uwe schrieb:> Es werden sich wohl nur Teilbereiche des Bildes ändern (Tachonadel).> Demnach muss dann nicht das ganze Bild aktualisiert werden.
Dann ist das ganze schon wieder was anderes und ein AVR könnte reichen.
Du kannst ja schonmal die Tachoanzeige entwerfen und dann zählen wieviel
Pixel sich ändern. Mit den beiden Datenblätter (Displaycontroller und
AVR) kannst du dir dann ausrechnen ob das ganze schnell genug für deine
Ansprüche ist.
>Genau genommen soll auf dem Display ein Tachometer dargestellt werden,>der die Umdrehungszahl eines Lüfters (Umdrehungszahl regelbar) anzeigt.
Na das muss ja ein toller Lüfter sein wenn die Anzeige
voll hightech sein muss;)
@TO
Wenn du ein Ergebnis in absehbarer Zeit haben willst dann nimm doch
einfach ein billiges Smartphone und ein IOIO.
https://www.sparkfun.com/products/retired/10748
Wenn du auf unabsehbare Zeit basteln willst mit zweifelhaften Ausgang
dann bitte meinen Post ignorieren.
Uwe schrieb:> Der Programmspeicher des Mega64, mit> seinen 64KB ist ja schnell ausgeschöpft!
Ah ja, der erste Schritt zur Erkenntnis ist getan. Jetzt nur noch tapfer
weitergehen!
Also, selbst wenn man es schafft, ein 800x480 TFT mit "(64k
Farben/besser 16Mio)" mit eigenem Videoram und eigenem Controller und
einer 16 Bit Port-Schnittstelle an einen kleinen 8 Bit µC irgendwie
dranzukriegen, kommt doch die Frage auf, was man denn damit anstellen
will.
(stell dir nen Trabbi als Zugmmaschine vor, dann nen Adapter, dann nen
18 Tonner LKW-Anhänger dran...)
Die wirklich sinnvollsten Wege wären:
- Tablet zum Anzeigen und nen kleinen µC am USB zum Bedienen der
eigentlichen Hardware
- einen 32 Bitter mit integriertem TFT-Controller und externem
ebenfalls 32 bittigem SDRAM, 8 MB reicht vollauf.
- ODER (als Alternativlösung) ein stylisches gemaltes Bild, ein
Schrittmotor und ein netter Zeiger dran. Dafür tut's dann auch ein
ATmega.
W.S.
Uwe schrieb:> Die Bewegung der Tachonadel sollte möglichst flüssig sein, d.h. keine> plötzlichen Sprünge zum eingestellten Umdrehungszahlwert.(evtl. kleine> Verzögerung programmieren!?)
Eine flüssige Darstellung benötigt eine entsprechend hohe Framerate, je
nach maximaler Winkelgeschwindigkeit des Zeigers. Auch wenn bei dir von
einem Frame zum nächsten nur relativ wenige Veränderungen notwendig
sind, summiert sich die Pixelanzahl schnell hoch. Dazu kommen noch
Kontrollbefehle zur Auswahl des Pixelbereichs. Ideal wäre hier ein uC
mit integriertem Grafikcontroller. Das ist natürlich aufwändiger als ein
Display mit integriertem Framebuffer anzusteuern.
Gruß,
Arno
Eumel schrieb:> Nö, wieso sollte es?
Das kommt natürlich auf die verfügbare Hardware an. Du brauchst einen
entsprechenden uController mit Grafiksupport und das passende Display.
Hier ist die Auswahl (noch) deutlich beschränkter, jedenfalls was
"kleine" Lösungen angeht. Ein Raspberry mit HDMI-Display würde ich z.B.
für die Anzeige eines Tachos als oversized, also zu aufwändig
betrachten.
Und warum nicht erstmal ein kleines Grafik-Display wie z.B. die
DOG-Serie? Darauf kannst du schonmal deinen Tacho malen und schnell
genug sollte das auch sein. Und du bekommst Erfahrung. Gleich auf TFT
wird doch nichts.
Bin auf uTube auf folgendes Video gestoßen:
http://www.youtube.com/watch?v=0ETyFmAMFjY
Hardware die zum Einsatz kommt ist ein
STM32F4Discovery board + TFT(nur 240x320) mit SSD1289 Controller +
Motion Player Board(kann ich nix zu sagen!!??)
Interessant wirds ab TC 3min20sec! JPG video wird immerhin flüssig mit
30Bilder/sec abgespielt. Allerdings wurde der STM32 mit 250Mhz
übertaktet!??
Kommt der Stm32F4 hier schon an seine Grenzen, was die fps betrifft??
Gruss
Uwe
Uwe schrieb:> Kommt der Stm32F4 hier schon an seine Grenzen, was die fps betrifft??
Na ja wenn das hier:
Uwe schrieb:> Allerdings wurde der STM32 mit 250Mhz> übertaktet!??
dazu nötig ist offensichtlich schon.
