Hey, Ich versuche einen 4,3 Zoll 480x272 TFT über eine RGB-Schnittstelle 16Bit(5-6-5) anzusteuern. Bis jetzt bekomme ich nur die Hintergrundbeleuchtung zum Laufen. Ich möchte es so einfach wie möglich aufbauen, um die Prozesse zu verstehen. Auf der Platine hab ich einen PIC32MX795F512L Das PDF ist von einem baugleichen TFT.
Hast Du mal ein Oszilloskop an die verschiedenen Signale (CLK, DE, HSYNC/VSYNC) gehängt und Dir die erzeugten Frequenzen betrachtet? Du setzt zu Beginn von main() das Reset-Signal auf Lowpegel, aber nirgends wieder auf Highpegel. Das Display in Deinem PDF hat einen Low-aktiven Reset-Eingang ...
Bevor Du darauf wartest, leg' mal die Reset-Leitung in main() auf High-Pegel. Das kann durchaus Erhellung bringen.
Anatol G. schrieb: > Hey, > Ich versuche einen 4,3 Zoll 480x272 TFT über eine RGB-Schnittstelle > 16Bit(5-6-5) anzusteuern. Bis jetzt bekomme ich nur die > Hintergrundbeleuchtung zum Laufen. Ich möchte es so einfach wie möglich > aufbauen, um die Prozesse zu verstehen. > Auf der Platine hab ich einen PIC32MX795F512L Dein PIC32 hat keinen integrierten Displaycontroller, der ein solches Display ansteuern könnte. Dein Display hat nämlich keinen internen Speicher, sondern der PIC muss ihm 60 mal pro Sekunde 480*272*3=393680 Bytes in einem genau festgelegten Timing (!) schicken. Daher hat er (a) die erforderliche Controllereinheit nicht und (b) nicht genug RAM, um den Bildschirmspeicher irgendwo abzuspeichern (und ja, es muss RAM sein, Flash geht nicht). Heißt also: Du hast verloren. Dabei ist es nicht so, dass das prinzipiell nicht gehen würde - Du hast Dir nur nicht den richtigen PIC ausgesucht. Der hier könnte das z.B.: https://www.microchip.com/en-us/product/PIC32MZ2064DAS176 fchk
Anatol G. schrieb: > Ich möchte es so einfach wie möglich > aufbauen, um die Prozesse zu verstehen. Von welche Prozessen redest Du? Frank K. schrieb: > Dein PIC32 hat keinen integrierten Displaycontroller, der ein solches > Display ansteuern könnte. Der ist nicht zwingend notwendig, wohl aber genug RAM. Ein Beispiel, wie man das mit einem µC per DMA machen kann: Beitrag "4,3" TFT-Controller STM32F730" Wenn die Ansprüche nicht zu hoch sind und der µC beschaffbar sein soll, geht auch ein Pico-Board mit RP2040. Das RAM reicht als Bildspeicher und die Ansteuerung läuft per PIO-Modul. Mit 16-bit Farbtiefe ist man mit den IO-Leitungen aber leider schnell am Ende. Reduziert man sich auf 8 prägnante oder 256 'bunte' Farben, sieht alles viel besser aus für die "Prozesse".
Lesenswertes Buch zu dem Thema: Lucio Di Jasio Programming 32-bit Microcontrollers in C Exploring the PIC32 Allerdings S/W und nicht RGB.
m.n. schrieb: > Von welche Prozessen redest Du? m.n. schrieb: > Frank K. schrieb: >> Displaycontroller... > Der ist nicht zwingend notwendig, wohl aber genug RAM. Ich vermute, er denkt dabei an das Procedere der Ansteuerung so eines Displays. Naja, ein Displaycontroller ist in jedem Falle nötig, entweder einer aus Hardware (eingebaut oder separat) oder eben einer in Software. Gerade bei den PIC32 ist mir erinnerlich, daß die lange sowas nicht hatten, weswegen es Frickel-Lösungen dafür gab: mit DMA und Interrupthandlern. Sowas ist immer nicht optimal. Ich selbst hatte früher sowas mit einem CPLD und noch früher mit einer Handvoll GAL's erledigt. War auch frickelig, denn es läuft immer darauf hinaus, daß 2 Akteure zugleich auf den RAM zugreifen wollen (Displaysteuerung und CPU) und man Probleme hat, diese zwei asynchron zueinander laufenden Zugriffe zu regeln. Und wenn man heutzutage genug RAM im System haben will, kommt man an kleineren SDRAM nur schwer vorbei. Und dafür muß der µC ein passendes Interface haben und wenn es durchsatzmäßig kein Desaster werden soll, dann muß er auch breit zugreifen können, was wiederum einen integrierten Displaycontroller voraussetzt, der die Displaydaten blockweise aus dem RAM holt, zwischenspeichert und dann im Displaytakt ausgibt. Wir reden hier von 20..40 MHz Pixeltakt. Ich hab das alles durch und wenn ich ein buntes Grafikdisplay am µC brauche, dann suche ich lieber mir den µC danach aus, daß er dafür einen Controller enthält, als daß ich sowas selber mache. Es geht ja, aber es gehört nicht zu meinen Lieblingsarbeiten. W.S.
W.S. schrieb: > mit DMA und > Interrupthandlern. Sowas ist immer nicht optimal. Und Du entscheidest nun, was optimal sei? Nur weil Du Dich vielleicht mit Deinen Lösungen verzettelt hast, gilt das nicht für alles und jeden. W.S. schrieb: > denn es läuft immer darauf > hinaus, daß 2 Akteure zugleich auf den RAM zugreifen wollen > (Displaysteuerung und CPU) und man Probleme hat, diese zwei asynchron > zueinander laufenden Zugriffe zu regeln. Aktuelle Controller haben damit kein Problem und burst-Modus nebst FIFO bei DMA gibt es auch schon lange. Darum muß man sich doch garnicht kümmern. W.S. schrieb: > Wir reden hier von 20..40 MHz Pixeltakt. Ich hab das alles durch QVGA braucht 6,4 MHz, der TO mit seinem WQVGA gerade mal 9 MHz und selbst VGA 'nur' 25 MHz. Letzteres habe ich gerade mit einem RP2040 gemacht. Und c-hater könnte Dir verraten, wie er es mit 800x480 macht. Tut er aber nicht, weil er sich auch für oberschlau hält ;-) Aber suche ruhig nach Deinem Traumcontroller und bete, daß er in zwei Jahren wieder lieferbar ist.
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.