Hallo Forum, ich bin auf der Suche nach einem Weg ein 7" TFT Display mit Touch (erstmal offen ob resistiv oder kapazitiv) über einen Atmel Controller anzusteuern. Auf dem Display sollen einfache Grafiken, aber auch Bilder angezeigt werden. Die Bilder werden sich nicht oft Ändern, es sind mehr Hitnergrundbilder. Weiterhin sollen keine Videos abgespielt werden. Habe schon einiges hier und im Internet gelesen, aber das passende leider auch nicht gefunden. Folgendes habe ich herausgefunden: Ich könnte natürlich auch ein "interligenes Display" wie z.B. http://www.noritake-itron.com/NewWeb/TFT/Overview/Overview.asp verwenden. Damit habe ich auch schon gearbeitet, kann ich nur empfehlen für diesen Preis! Allerdings will ich das Display selbst direkt ansteuern, auch um offen für neue Anforderungen an mein Projekt zu sein. Wie gesagt würde ich das Display gerne mit einem Atmel µC ansteuern, da ich mich derzeit in den XMEGA A3BU einarbeite und auch das Atmel Software Framework verwende. Deshalb erhoffe ich mir, das ich bestehenden Code (wegen dem Atmel Software Framework) relativ leicht auf einen Leistungsstärkeren Atmel µC übertrage, falls dieser erforderlich ist. Nun ist es ja so, das ich bei kleineren Displays, sagen wir 2,8" eines mit einem ILI9341 controller hätte nehmen können. Wie z.B: https://www.adafruit.com/product/2090 Wenn ich es richtig verstanden habe, lässt sich so ein Display (es verfügt über einen integrierten Controller) relativ leicht mit einem 8Bit µC ansteuern. Bei einem größeren Display gibt es solch einen "simplen" Weg nicht, da diese Displays andere anforderungen an die Ansteuerung stellen. Wenn ich so ein Display mit einem 8Bit µC ansteuern wöllte, könnte ich solch ein Treibermodul zwischen meinem µC und dem Display schalten, wenn ich es richtig vertsanden habe: https://www.adafruit.com/product/1590 Und jetzt meine Frage: Der eleganteste Weg wäre doch sicherlich, wenn mein µC das Display bereits direkt ansprechen kann. Dazu gibt es Leistungsstärkere µC zb. haben die Atmel SMART µC solch einen TFT Treiber eingebaut. Also kann der µC das TFT selbst direkt ansteuern? Über das Atmel Software Framework sollte dies dann hoffendlich auch nicht allzu kompliziert sein. Neben den Atmel SAM µC gibt es auch noch die Atmel UC3 µC. Mir ist nicht klar, welcher jetzt besser zu mir passt. Als Hintergrundinformation: Im Prinzip reicht mir mein XMEGA A3BU föllig aus. Nur ich will eben ein 7" TFT Display am liebsten direkt, also ohne irgendwelche Treiberboards, ansteuern. Vielen Dank für die Hilfe.
Habe gerade vielleicht etwas passendes gefunden: Hier gibt es ein Display mit einem SSD1963 Controller: http://www.sainsmart.com/arduino/arduino-shields/lcd-shields/sainsmart-7-7-inch-tft-lcd-480x800-arduino-due-mega2560-r3-raspberry-pi.html Dies gibt es auch als Set mit einem Mega2560 µC http://www.sainsmart.com/arduino/arduino-shields/lcd-shields/sainsmart-mega2560-r3-7-7-inch-tft-lcd-screen-sd-card-slot-tft-shield-for-arduino.html Dann gehe ich davon aus, das mein Xmega A3BU auch mit dem Display fertig werden sollte? Hat jemand schon Erfahrungen mit dem SSD1963 Controller und Xmega? Leider lässt sich der Controller nur parallel ansteuern ....
Die UC3 Familie von Atmel ist echt toll. Doch leider wird die Linie von Atmel wohl nicht mehr so verfolgt. Also eher Finger weg! Auch wenn die STM Macken haben, so gibt es einen STM32F429, welche einen 2D Beschleuniger für Grafik an Board hat. den würde ich mir an deiner Stelle anschauen. mfg DerDan
Markus W. schrieb: > Damit habe ich auch schon gearbeitet, kann ich nur empfehlen > für diesen Preis! http://www.buydisplay.com/default/7-inch-lcd-module-capacitive-touch-screen-panel-i2c-spi-serial Mit nem großen Winbond Flash und Fontchip ist man bei 40$. In der größe bei der Auflösung wird der RA8875 etwas zu klein.. da hat man nur noch wahlweise 256 Farben 2Layer oder 1Layer 65k Farben. Zwischen den Layern kann man Filter,BTE wie Flash DMA funktionen anwenden. Die Platinen sind auch sehr minimal, wenn man eine Flashchip benutzt muss man den am besten mit einem Adapter verlöten um diesen auch später umflashen zu können.
Hallo, kennst Du schon den FT800? # http://www.ftdichip.com/Products/ICs/FT800.html # http://www.ftdichip.com/EVE.htm Hier sind noch zwei Beispiele von RGF: # https://www.youtube.com/watch?v=7xUxovlC5Pc # https://www.youtube.com/watch?v=d6vosRXQWwQ http://avr.myluna.de/doku.php?id=de:lib-ft800
Markus W. schrieb: > ich bin auf der Suche nach einem Weg ein 7" TFT Display mit Touch > (erstmal offen ob resistiv oder kapazitiv) über einen Atmel Controller > anzusteuern. Überlege doch erst einmal, bevor du derartige Vorgaben machst. "Atmel-Controller" klingt nach AVR und Konsorten, gelle? Es gibt µC heutzutage, die einen dedizierten TFT-Controller bereits eingebaut haben. Vorreiter war Sharp, damals mit den BlueStreaks, jetzt ist es NXP mit den LPC2478..LPC17xx..LPC40xx bis zu den LPC43xx. Auch ST hat inzwischen nachgezogen und möglicherwese auch noch andere Hersteller. Aber das sind alles eher dickere Chips auf ARM- bzw. Cortex-Basis. Du tust deshalb gut daran, dir einen passenden Controller für die Aufgabe auszusuchen und nicht umgekehrt. Ein übliches 7" TFT kommt heutzutage mit 800x480 Pixeln daher und braucht pro Pixel wenigstens 16 Bit, also 2 Byte an RAM, wenn man nicht von vornherein auf Krampf aus ist. Nun rechne dir mal den RAM-Bedarf dafür aus. So ein TFT wird üblicherweise mit einer Pixelrate von etwa 33 MHz angesteuert und der RAM, den du vorsehen mußt, muß so an den µC angebunden sein, daß der Speicherbus durch diese Display-Grundlast nicht bereits ausgelastet ist. Da kommt logischerweise eben nur ein 32 Bit breiter Speicher und ein 32 Bit breiter Bus zum Speicher in Frage, sonst ist der Ärger mit dem Bus als Flaschenhals vorprogrammiert. Tja, und ein RAM, das Zugriffszeiten von deutlich weniger als 33 ns und obendrein 32 Bit datenbreite aufweist, ist nur als SDRAM zu kriegen - DDRAM oder gar LPDDRAM wird m.W. von keinem hier diskutablen µC unterstützt. Merkst du jetzt, wohin die Reise geht? Man kann sich sowas selber basteln, ich hab das bereits getan, aber man MUSS sich vorher im Klaren sein, welche Zutaten man dsfür braucht. W.S.
W.S. schrieb: > So ein TFT wird üblicherweise mit einer Pixelrate von etwa 33 MHz > angesteuert Wieviel MHz hast Du maximal probiert? thx Lars
Vielen Dank für die Antworten, ja der FT800 sieht schon interessant aus, leider kann dieser soweit ich verstanden hab nur Displays von einer Größe bis 5" ansteuern - ich hätte gerne ein 7" Display. Auf dieses hier http://www.buydisplay.com/default/7-inch-lcd-module-capacitive-touch-screen-panel-i2c-spi-serial bin ich auch schon gestoßen, sollte ich mir vielleicht mal näher ansehen. Hat hier schon jemand Erfahrungen mit? Wie ist das z.B. wenn ich ein Bild welches auf der SD-Karte gespeichert ist dastellen will. Kann ich dies mit einem Befehl vom µC direkt von SD-Karte in den Bildspeicher laden, oder dies erst über den µC von der SD-Karte ausgelesen werden und kann dann erst auf das Display übertragen werden.
Ich habe ein kleineres mit dem RA8875 Controller. Der SD-Karten Slot ist nur auf Pins rausgeführt, im Grunde also garnicht angeschlossen. Für direktes DMA lässt sich ein Serial Flash einlöten, welcher dann eingelötet nicht mehr programmiert werden kann.. habe mir mit nem 8Pin Molex anstelle des ICs einen Steckbaren Adapter gebastelt. Man kann dann Backgroundbilder und Buttons wie auch Grafiken auf den Flash proggen und direkt mit Blocktransfer verschieben, kopieren, Filter anwenden und das geht ohne Bildaufbaueffekte. Wie schon geschrieben bin ich mir nicht sicher ob das bei der von dir gewünschten auflösung noch so gut läuft wie bei meinem 480x272.
Lars R. schrieb: > Wieviel MHz hast Du maximal probiert? Ich hab sowas in Betrieb und die Manuals dazu gelesen - offenbar im Gegensatz zu dir. W.S.
Dieses Display kann laut Datenblatt mit bis zu 50MHz getaktet werden: http://www.newhavendisplay.com/capacitive-touch-tft-nhd50800480tfatxlctp-p-6062.html Das ist mehr, als von Dir angegeben. Kennst Du nur Displays, bei denen nur ca. 30 oder 33MHz im Datenblatt stehen? Eine andere Frage ist, ob es sich um eine Begrenzung durch die Elektronik handelt, oder ob der Hersteller davon ausgeht, dass jenseits davon in Kombination mit dem kürzestmöglichen Portch aufgrund der Rise-and-Fall-Zeiten ohnehin nichts Sinnvolles mehr anstellen lässt. Ich bin kein Display-Experte. Deswegen hab ich ja gefragt.
Danke nochmal für die Unterstützung. Ich werde mich wohl für ein "interligentes" Display entscheinden. Trotzdem finde ich das Display http://www.buydisplay.com/default/7-inch-lcd-module-capacitive-touch-screen-panel-i2c-spi-serial mit dem RA8875 Controller sehr interessant. Ist es hier wirklich so, dass sich der Flash Memory Chip nicht im eingelöteten Zustand programmieren lässt? Ich würde mir also einen eigenen Programmer aufbauen müssen? Falls ich auf diesen Chip verzichte, könnte ich doch auch alle benötigten Daten auf die SD-Karte legen, wobei dann der Transfer zum Display viel länger dauert, da ich dann auf DMA verzichten muss. Stimmt das so?
Lars R. schrieb: > Ich bin kein Display-Experte. Ja. Hier geht es um die Bus-Belastung. Mit 33 Megapixel/s und 16 Bit Farbtiefe ist so mancher aus dem Chip herausgeführter Systembus schon arg belastet - und nun fängst du an, von 50 MPixel/s zu schreiben. Ist kontraproduktiv. immerhin braucht man auch noch Bandbreite für den sonstigen Datenverkehr. Wieviel an Grund-Buslast man sich da gönnt, ist zwaar diskutabel, aber ich würde dem Display nicht mehr als etwa 30% freiwillig gönnen - sonst schneckt der Rest nur noch daher. Ach ja, es gibt bei den PIC32-Leutchen von Microchip grandiose "Experten", die sowas wie eine TFT-Bedienung per Mischung aus DMA und Interrupt-Handlern ausgedacht haben und ganz stolz drauf sind. Ist albern, da zwar angeblich nur 2..5% CPU-Zeit gebraucht wird, aber tatsächlich der DMA-Verkehr den Systembus fast lahmlegt. Der Grund dafür ist, daß der DMA Core ja nicht wissen kann, wozu die Bytes benötigt werden und er deshalb immer nur per Timer jeweils ein Pixel transferiert. Bei den echten eingebauten TFT-Cores sieht das anders aus: da werden die Pixel blockweise vom RAM geholt, im TFT-Core gepuffert und von dort aus im richtigen Timing zum Display geschickt. Die blockweise Arbeit auf dem Systembus sorgt dafür, daß dafür längst nicht soviel Overhead stattfindet wie bei all den Bastel-Lösungen. Und nochwas zu großen Displays mit eingebautem Controller: Wenn dieser einen echten Platz im adressierbaren Speichervolumen hat, dann geht's gut. Aber bei allen Displays die mir so bekannt sind, ist das nicht so. Stattdessen werden sie über einen Port angesprochen und damit ist dann die Benutzung ausgesprochen kompliziert und obendrein langsam, denn Pixel per Load-Store von der CPU zu bewegen ist nicht wirklich lustig. W.S.
W.S. schrieb: > Lars R. schrieb: >> Ich bin kein Display-Experte. > > Ja. > > Hier geht es um die Bus-Belastung. Bei mir nicht. Dachte, mit meiner knappen Frage geht das, aber ich hätte mich nicht in den Thread mit hineinhängen sollen. Für den TO ist Dein Post sicher trotzdem hilfreich.
:
Bearbeitet durch User
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.