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
>Welches Interface ist zu bevorzugen: SPI, RGB, RD/RW???
Ich glaub ich hole Popcorn...
Im Ernst, der STM32F4xx ist die bessere Wahl als ein Mega64.
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.html http://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.
Erstmal danke für eure Antworten!!! Seh ich das richtig? Im Idealfall braucht die Schnittstelle 17ns für ein Pixel (bei 50Hz)??
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
Hallo m.n., danke für die Erklärung! Wie siehts eigentlich mit der maximalen Kabellänge zwischen DisplayController und µC aus? Gibts da ein Limit? Habe mal bischen im Internet rumgestöbert und bin auf folgende Displays gestoßen!(ja beides 800x480, würde nur ungern eine geringere Auflösung nehmen :-)) Beide mit DisplayContoller! und eigenem Speicher!?? 1. http://www.lcdstore.de/epages/17406888.sf/de_DE/?ObjectPath=/Shops/17406888/Products/CFAF480800FT2-040T Problem is wohl der Anschluss: Flexfolie 45polig. Nullkraftstecker, gibts doch sicherlich einen passenden Adapter!? 2. http://www.ebay.de/itm/7-inch-TFT-LCD-module-800x480-SSD1963-w-touchpad-PWM-arduino-AVR-STM32-ARM-/121017488870 Mal naiv gefragt: Kann ich die beiden Displays problemlos in Verbindung mit dem STM32F4 Discoveryboard nutzen? Gruss Uwe
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
Arno schrieb: > Das ist natürlich aufwändiger als ein > Display mit integriertem Framebuffer anzusteuern. Nö, wieso sollte es?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.