Hallo, habe ein TFT Farbdisplay mit 320x240 Pixel, digital RGB Interface. Mein Prozessor hat ein serielles Interface (SPI) für die Displaykommunikation. Speicherzugriff auf den Arbeitsspreicher des Prozessors ist mit DMA organisiert, was ja den Prozessor entlastet, aber den Bus trotzdem verstopft. Jetzt die Frage: Kann man nicht nur 1 bis 2-mal pro Sekunde ein komplettes Bild an einen PLD schicken, der sich zwischen Prozessor und Display befindet und die Umsetzung realisiert (Daten konvertieren und Erzeugen der Sync/CLK-Signale)? Das würde man den Bus (Arbeitsspeicher <-> Prozessor) "sauber" halten und man könnte eine extra grafik-Speicher sparen. Es gib zwar integrierte Lösungen (beisielsweise von Epson), die sind aber sehr teuer. Wie funktioniert das eigentlich bei Notebooks mit shared memory Grafikspeicher. Danke und gruß, Benjamin
Hi, >habe ein TFT Farbdisplay mit 320x240 Pixel, digital RGB Interface. [..] >Kann man nicht nur 1 bis 2-mal pro Sekunde ein komplettes Bild an einen >PLD schicken, ja - wenn Du mir einen CPLD nennst in welchem Du 320x240x16 Bit (falls es 16 Bit pro Pixel sein sollten) = 150 kByte zwischenspeichern kannst: das TFT nämlich mit jedem V-/H-Sync neue Daten haben - und der VSync dürfte im Bereich 50/60 Hz liegen Gruß Jochen
Was den Shared Memory angeht kann ich dir leider nicht weiterhelfen. Ich vermute mal, dass dafür einfach Speicher genommen wird, der im Mittel schnell genug für alle Zugriffe ist (entsprechend schnell muss dann natürlich auch der Bus sein). Die "traditionelle" Variante ist ein separater Speicher, der zwar auch am Bus hängt, aber über diesen nur angesprochen wird, wenn sich im Bild tatsächlich was ändert. Ansonsten wird dieser Speicher über einen weiteren Controller ausgelesen (ohne dabei den Bus zu benutzen), der dann die Daten an das Display schiebt. Der Auslese-Controller kann dann z.B. über ein CPLD realisiert sein. Der Graphikspeicher muss entweder ein Dual-Port-Speicher sein (um gleichzeitige Zugriffe beim Auslesen und über den Bus zu ermöglichen), oder eine extra-Schaltung gibt dem Auslesen Vorrang vor dem Bus, indem z.B. der Bus angehalten wird (falls möglich) oder der Zugriff auf irgendeine Art als fehlerhaft gemeldet wird und wiederholt wird.
@ Joko: Das Bild soll nicht im CPLD gespeichert werden (da das nicht geht). Vielmehr gibt er den seriellen Datenstrom des Prozessors gleich wieder raus (also eigentlich seriell zu parallel Converter [Schieberegister]) plus Sync-Signale). Ein komplettes Bild wird dann zügig geschrieben, aber eben nur ein bis zwei Bilder pro Sekunde, um den Bus zw. Prozessor und seinem Arbeitsspeicher frei zu halten. Meinst das dies funktionieren kann? Kann man zwischen den Schreibzyklen das Bild halten (Data Enable Pin off).
@ Morin
>Meinst das dies funktionieren kann? Kann man zwischen den Schreibzyklen> >das
Bild halten (Data Enable Pin off).
Das wird weniger mir dem "Data Enable Pin" zu tun haben, als vielmehr
mit der Datenerhaltung in den TFT-Transistoren: je 'besser' diese ihren
Ladezustand halten können, um so länger bleibt das Bild erhalten.
(Default-Zustand, in den sie zurückstreben, ist 'helles Pixel')
Auch wenn der Bildinhalt sich nicht ändert ,schreiben alle Datenblätter
von TFTs, die ICH kenne, eine 'Refresh-Rate' von <= 20 ms vor.
Das heiß aber nicht, daß das Bild 'unleserlich' wird - nur daß ggf. die
Spec. nicht eingehalten wird (was aber i.A. nicht so toll ist)
Gruß
Jochen
Benjamin Ziebarth wrote: > aber eben nur ein bis zwei Bilder pro Sekunde, um den Bus zw. Prozessor > und seinem Arbeitsspeicher frei zu halten. Was wird das Display zerstören, da dann DC am LCD anliegt, wenn die Signale fehlen und sich so alles zersetzt. Zwar nicht sofort, aber im Laufe der Zeit. Zunächst wird das Bild nur einbrennen, was man durch längeres Ausschalten mehr oder weniger regenerieren kann.
@ Benedikt K. (benedikt) >Was wird das Display zerstören, da dann DC am LCD anliegt, wenn die >Signale fehlen und sich so alles zersetzt. TFT mit RGB-Interface != einfaches LCD !!! MFG Falk
Falk Brunner wrote:
> TFT mit RGB-Interface != einfaches LCD !!!
Ja und ?
Trotzdem ist ein TFT ein LCD, und das geht kaputt wenn eine
Gleichspannung anliegt. Und genau das passiert, wenn die Ansteuersignale
fehlen. Aus diesem Grund wird auch eine minimale Vertikalfrequenz
spezifiziert.
Okay, also komme ich um den extra Speicher nicht umhin. Das Schwierigste ist wahrscheinlich die Speicherorganisation, um gleichzeitig lesen und schreiben zu können. @Morin: Das mit dem Dual-Port-Speicher klingt sehr interssant; ist aber neu für mich. Ich möchte gerne eine CPLD Lösung von Altera nutzen. Kann mir jemand einen geeigneten (=günstigen) Typen empfehlen? und einen geeigneten Dual-Port-Speicher? Gibt es ein Eval-Board mit diesem Speicher oder speziell für diese Applikation?
@ Benjamin Ziebarth (Firma neuling) (benjamin-z) >Okay, also komme ich um den extra Speicher nicht umhin. Ja. >Das Schwierigste ist wahrscheinlich die Speicherorganisation, um >gleichzeitig lesen und schreiben zu können. Mehr oder weniger. >Das mit dem Dual-Port-Speicher klingt sehr interssant; ist aber neu für >mich. Kann man machen. Allerdings sind Dual Port RAMS schwierig zu bekommen. Günstiger ist meist die Verwendung von Standard-RAMs. >Ich möchte gerne eine CPLD Lösung von Altera nutzen. Kann mir jemand >einen geeigneten (=günstigen) Typen empfehlen? und einen geeigneten >Dual-Port-Speicher? Informiere dich doch erstmal über CPLDs und FPGAs. Dann wirst du ernüchtert feststellen, dass ein CPLD keine RAMs hat, ein FPGA sehr wohl. > Gibt es ein Eval-Board mit diesem Speicher oder Ja. Die meisten FPGA-Boards haben ordentlich Speicher drauf. > speziell für diese Applikation? Nein. MFG Falk
> Informiere dich doch erstmal über CPLDs und FPGAs. Dann wirst du > ernüchtert feststellen, dass ein CPLD keine RAMs hat, ein FPGA sehr > wohl. @ Falk Brunner: Danke für die Antworten. Ja, es gibt SRAM basierte FPGA's, z. B. Spartan3AN. Leider brauche ich sehr viel Speicher (Farbbild): 320x240 Pixel x (gewünschter) Farbtiefe, aber nicht so viele I/O Pins. Große (integrierte) Speicher sind nur in großen FPGA's möglich, die zu viele Gatter haben und somit (so meine Vermutung) teurer sind als die getrennte Lösung (CPLD plus extra SRAM). Oder liege ich falsch?
Die meisten FPGAs haben integrierten SRAM, aber wie du schon festgestellt hast nicht genug für deine Zwecke (außer den allergrößten und teuersten). Also externer RAM. Von DRAM würd ich dir abraten. Das ist zwar die Profi-Lösung, aber auch ziemlich kompliziert: da müssen regelmäßig alle Zellen refreshed werden, damit sie ihren Wert nicht verlieren. Das muss dann zeitlich mit den anderen Zugriffen gemultiplexed werden, entweder von deinem Controller (aufwendig) oder intern vom Speicher (wodurch Zugriffe unbestimmt verzögert werden können). Also externer SRAM. Auch da must du immer noch Buszugriffe und Zugriffe für die Ausgabe zeitlich multiplexen. Wenn dein Speicher schnell genug ist, kannst du einfach immer abwechselnd je einen Zugriff vom Bus, dann einen für die Ausgabe erlauben (setzt voraus dass Bus-Zugriffe vom Bus-Slave um mind. 1 Clock verzögert werden können). Ansonsten (Speicher zu langsam dafür) kannst du Zugriffe vom Bus z.B. nur in den Blank-Pausen (Bildschirmrand) durchführen.
@ Benjamin Ziebarth (Firma neuling) (benjamin-z) >Ja, es gibt SRAM basierte FPGA's, z. B. Spartan3AN. ;-) Da verwechselst du was. Die Bezeichung "SRAM-basierend" bedeutet, dass der Konfigurationsspeicher aus SRAM besteht, als der Speicher, wo die Logik festgelegt wird, die du mal durch dein VHDL beschrieben hast. Darauf hat man als Anwender aber keinen Zugriff, wozu auch. Der RAM von dem die Rede war sind RAM-Blöcke, die man in seiner Anwenderlogik verwenden kann. Die ersten Generatioenen von FPGAs (z.B. die 4000 von Xilinx) waren auch SRAM basierend, hatten aber keine RAM-Blöcke (jaja, Distributed RAM zählen wir hier mal nicht). Die neuen ala Spartan II/3 whatever haben grosse RAM-Blöcke. Aber wie bereits gesagt immer noch viel zu wenig für ein VGA-Bild. >Vermutung) teurer sind als die getrennte Lösung (CPLD plus extra SRAM). Genau. MFG Falk
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.