Forum: FPGA, VHDL & Co. Display-Ansteueung mittels Xilinx-FPGA

Na da wirst du einiges an arbeit haben.
also

zu 1.) Das kannst du am besten dem Datenblatt entnehmen. Ich denke mal
du hast eine VGA Schnittstelle? Dann stehen im Datenblatt bestimmt auch
die Werte für Back porch, front porch etc. Am besten schaust du mal in
diesem Userguide vom Spartan3 Starter Kit (ab Seite 21)


zu 2.) siehe zu 1 :-)



zu 3 ) Tja da ist es ganz wichtig was du machen willst. Möchtest du
texte ausgeben oder einzelne Pixel setzen??? Da stexkt einiges hinter.
Es gibt aber glaub ich ne VGA ansteuerung in Verilog bei
www.opencores.org

zu 4.) siehe zu 1.)

zu 5.) Also wie schon gesagt einfach mal bei opencores.org. Ansonsten
hat www.fpga4fun.com hat ein Ponggame auf denen Seite erläutert. Ist
zwar auch Verilog, aber evtl helfen dir ja dort die Erklärungen.

Viel erfolg, wenn du noch fragen hast, frag !!!


Axel MEineke

also es sollen in erster Linie Grafiken auf dem Display ausgeben werden,
die vorher in ein RAM geladen wurden. Das ganze soll über eine
RGB-Schnittstelle laufen. Ein Lösung ?

http://www.opencores.org/projects.cgi/web/vga_lcd/overview
Das wär was in Verilog.
Sowas suchst du doch oder???
Du kannst ja die anderen Module in VHDL programmieren, wenn du noch was
extra haben willst. Damit kommt das WebPack zurecht.

Im Prinzip suche ich so etwas. Die Auflösung muß MINDESTENS 800 x 480
betragen (am besten noch frei skalierbar). Allerdings bräuchte ich eine
Lösung in VHDL.

Danke...

Hmmm... ich denke mal ne komplettlösung frei Haus wird schwer werden.
Was spricht gegen die Verilog-Lösung??? du kannst duch auch mit vhdl
die module ansprechen. Das ding ist glaube ich sehr gut dokumentiert,
so das du nur die schnitstellenparameter ermitteln must. Ansonsten ist
das schätzchen von Opencores einfach als Black Box anzusehen.
Oder warum möchtest du das ganze in VHDL haben ???

Du kannst es doch sicher per hand umcoden.
Ich habe auchmal einen smalltalk sourcecode in C umwandeln müssen,
obwohl ich kein smalltalk kann. Für jemand der halbwegs eine ahnung
davon hat was er da tut ist das absolut kein problem.

Das Umcoden von Virtex in VHDL ist zwar net so schwer, aber das
Verilog-Projekt für die VGA_schnittstelle auf opencores.org ist schon
ziemlich umfangreich. Also ich würde dir vorschlagen (TPSK) dich
erstmal in den aufbau eines Videosignals einzulesen. Dannach würde ich
einfach mal ein paar Testbilder generieren. (z.B. Graukeile die sind
einfach mit dem dekrementieren von 255 auf 0 Graustufen zu erzeugen).
So kannst du sehen ob deine ansteuerung stimmt.
Du willst nur feste Grafiken darstellen die in deinem Speicher liegen
oder? Du benötigst keine Zeichensätze? Na dann bist du an deisem Punkt
schon fast am Ende. Wie du den Speicher händeln kannst, bin ich auch
etwas überfragt. So grosse Datenmengen muste ich bis jetzt noch nicht
bewältigen. Aber wenn du die Addressierung der Speicheraddressen
verstanden und realisiert hast, ist es vom Graukeil zum fertigen Bild
kein grosser aufwand mehr. Ich habe selber mal ein On Screen Display
programmiert. Das geht ja in etwa in die Richtung. Wenn du also bei der
realisierung mal hängen bleibst, frag einfach. So schwer ist das mit dem
RGB-Signal nicht.
Wie weit bist du denn bei deiner Realisierung? Für welche Hardware hast
du dich entschieden?

Hallo Axel,

Du scheinst ja etwas Erfahrung mit der Sache zu haben. Also baue ich
mal schwer auf dich. Im Moment bin ich dabei, mich in den Aufbau von
Videosignalen zu beschäftigen ....Uff !!!

Zurück zu meinen Problem: also ich möchte Grafiken aus einem RAM auf
einem Display darstellen.

Vielleicht kannst du mir dazu noch ein paar Sachen erklären. Soviel ich
weiß, benötige ich ja neben meinem RGB-Signalen, V- und H-Synch noch
irgendwelche Koordinaten, wo und wie die einzelnen Pixel meiner Grafik
im Speicher liegen (bitte korrigiert mich, wenn ich falsch liege...).
Außerdem muß man noch die Spalten und Zeilen des Displays ansteuern.
Kannst du mir erklären, wie das funktioniert (speziell die
Koordinatensache und die Spalten/Zeilensteuerung) und wie man das
realsiert ?

Noch ein paar fragen:

- Wieviel Verbindungen zum Display benötige ich (3 für RGB, 2 für Synch
und 2 für X/Y ????)

- Wie sieht die RGB-Schnittstelle zum Display aus ?

- wie baue so einfach die Testbilder mit den Graukeilen auf ????
Einfach durch eine autarke VHDL-Realsierung der Sync-Signale und
irgendwelcher RGB-Signale ???

- wie sehen genau die RGB-Signale aus

- wie sieht das Timing für ein Display aus (X/Y, dazu RGB-Signale und
zwischendurch irgendwelche Sync-Signale)

Sorry, dass ich noch soviel Fragen habe (blutiger Anfänger in diesem
Bereich). Aber ich finde irgendwie keine richtigen Antworten im Netz
darüber (Links ???).

Mit meiner Realisierung habe ich noch nicht angefangen - ich kenne nur
das Soll-Ziel (Grins). Im Moment beginne ich mit der Vorbereitung
darauf. Bevor ich aber damit anfange, will/muss ich aber erstmal noch
einen Berg voll Fragen beseitigen.

Danke und Gruß

Also erstmal zu den einfachen dingen...

- Wieviel Verbindungen zum Display benötige ich (3 für RGB, 2 für
Synch
und 2 für X/Y ????)
Du brauchst HSync VSync R, G, B.

- Wie sieht die RGB-Schnittstelle zum Display aus ?
An den Ausgängen für RGB musst du jeweils, wenn mich nicht alles
Täuscht, nen 270 Ohm Widerstand packen.

- wie sieht das Timing für ein Display aus (X/Y, dazu RGB-Signale und
zwischendurch irgendwelche Sync-Signale)
WICHTIG ist das du alles in FSM realisierst (Statemachine). So kannst
du  gleich die Position des Bildpunktes ermitteln. Hsync und Vsync sind
so auch am besten umzusetzen.

- wie sehen genau die RGB-Signale aus
Das RGB Signal kannst du am besten mit 8bit je Farbe realisieren. Ich
weiss ja nicht wie viele Farben dein Bild hat.

Die position musst du versuchen geschickt mit dem Speuicher zu
verknüpften. Ich habe es mit dem Blockram realisiert. Aber du brauchst
ja mehr Speicher oder? Also bei deinem SRam kann ich dir leider nicht
all zu sehr behilflich sein... noch nicht.
Also ich habe viel Text ausgegeben und habe den Blockram von der breite
so dimensiooniert, wie ein Zeichen breit ist... in meinem Fall 16 bit.
War das zu verwirrent geschrieben? Wenn ja frag noch mal.

Also keine Angst, ich kann dein Leiden nachempfinden.

Wenn du nicht mehr weiterkommst müssen wir sonst mal das Telefon
konsultieren. Das ist sonst doch etwas viel zu tippen. Ich glaube
teilweise ist das auch sau schwer zu verstehen was ich hier tippe :-(.
naja die E-Mail steht ja oben drin.

Good Luck

Axel

Hi

schau mal hier rein
http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html

Wähle mal VGA 640x480 aus, dann hast du folgende Werte:

Pixelclock = 25.17 MHz, der VGA Code sollte also mit 25 Mhz getaktet
werden. Bei jedem Takt muß also der HCounter -> Horizontal Counter um
+1 inkrementiert werden.

Gehe zu Punkt 3. und drücke Button Calculate.
Gehe zu Punkt 4. dort siehst du das der HCounter bis 800 laufen muß,
danach wird VCounter -> Vertical Counter +1 inkrementiert bis er bei
524 zurückgesetzt wird und ein Bild fertig ist. Die Werte 800x524 sind
also die absoluten Counter Werte um ein 640x480 VGA Bild mit 60.04 Hz
Bildwiederholrate zu erzeugen.

So nun zerlegen wir die 800x524 in die einzelnen Bereiche, sprich Bild
+ Back Porch + Sync Pulse + Front Porch. Egal ob Horizontal oder
Vertikal das Timing enthält immer 4 Abschnitte. Normalerweise zuerst
das Front Porch == Schwarzer Rand Links am Bild, dann Bilddaten selber,
also 640 Horizontal Pixel und 480 Vertikale Zeilen, dann Back Porch ==
schwarzer Rand Rechts und als vierten Teil der Synchronizations Puls.

Ich handhabe es aber so das wir die 4 Abschnitte im VHDL anders
gruppieren.
1.) Bild
2.) Back Porch
3.) Sync Pulse
4.) Front Porch

Das hat den Vorteil das die Counter -> HCounter und VCounter bei 0
beginnend sofort das Bild darstellen, ergo solange HCounter < 640 ist
werden Pixel dargestellt, so lange VCounter < 480 ist werden Bildzeilen
dargestellt.

So die Werte für Front/Back Porch und Sync Pulse findest du auf der
obigen WEB Seite.

Vereinfacht sieht es also so aus:

1.) mit einem Takt von 25.17 MHz inkrementiere HCounter
2.) solange HCounter < 640 gebe an R,G,B die Pixel aus, setze HSync auf
1
3.) solange HCounter >= 640 und HCounter < 640 + Back Porch, gebe
schwarze Pixel aus, setze HSync aus 1
4.) solange HCounter >= 640 + Back Porch und HCounter < 640 + Back
Porch + Sync Pulse, gebe schwarze Pixel aus und setze HSync auf 0
5.) solange HCounter < 800 ist gebe schwarze Pixel aus, setze HSync auf
1
6.) wenn HConter >= 800 dann setzen HCounter = 0;

7.) bei Flanke HSync von 1 auf 0 inkrementiere VCounter
8.) solange VCounter < 480 gebe Pixel aus und setze VSync = 1
9.) solange VCounter >= 480 und VCounter < 480 + Back Porch gebe
schwarze Pixel aus und setze VSync = 1
10.) solange VCounter >= 480 + Back Porch und VCounter < 480 + Back
Porch + VSync Pulse gebe schwarze Pixel aus und setze VSync = 0
11.) solange VCounter < 524 gebe schwarze Pixel aus und setze VSync =
1
12.) wenn VCounter >= 524 setze VCounter = 0.

Also hast du minimal zwei Processe. Eine der mit Clock = 25 MHz
getaktet wird und immer HCounter inkrementiert bis er 799 ist.
Und einen zweiten der durch HSync getaktet wird und immer VCounter
inkrementiert bis er bei 524 überläuft.

Solange HCounter < 640 und VCounter < 480 ist gibst du die RGB Werte
der Pixel aus. Dazu nimmst du einen Addresscounter der jedesmal um RGB
Bits inkrementiert wird. An der Speicheraddresse dieses Addresscounters
stehen im SRAM deine Bilddaten, linear und sequentiell mit 640 Pixel zu
480 Zeilen.
So bald HCounter >= 640 oder VCounter >= 480 ist gibts du grundsätzlich
Schwarze Pixel aus und der Addressconter wird NICHT inkrementiert.
Alternativ kannst du natürlich auch VCounter || HCounter als
Addresszeiger benutzen, wenn du zb. mit 512 oder 1024 Pixeln pro Zeile
arbeitest.

Solange HCounter >= 640 + HBack Porch und HCounter < 640 + HBack Porch
+ HSync Pulse ist wird HSync auf 0 gesetzt, oder eben in invertierter
Ansteuerung von 0 auf 1 gesetzt. Das hängt vom Monitor ab.

Das gleiche Schema gilt für VCounter, VBack Porch, VSync Pulse.

Ist also relativ einfach die ganze Sache, problematischer ist der
gemeinsamme Zugriff auf den Display SRAM.

Gruß Hagen

Hallo Axel,

erstmal Danke für deine Hilfe.

Also nochmal zurück zu deinen Antworten.

Die Realisierung mit der Statemachine habe ich schon ein paar mal
gelesen. Kannst du mir das etwas genauer erklären ? Mir sagt, dass
überhaupt nichts. Hast du oder jmd. ein Beispiel dafür, wie soetwas
auszusehen hat (evtl. deine Blockram-Realisierung)?

Gibt es auch noch andere Realisierungsmöglichkeiten, wie ich eine
Grafik auf einem Display anzeigen kann (besonders die x/y-Position,
Sync etc.)?

Im Moment beschaffe ich mir einige Grundlagen über Bildsignale etc.
Dabei werden sich bestimmt noch einge Fragen ergeben. Evtl. würde ich
auch auf dein Angebot, dich einfach mal anzurufen, zurückkommen.

Also dann viele Grüße

TPSK

Noch eine weitere Frage:

Wie lade bei einem FPGA eine Grafik in ein RAM ?

Wie spreche ich das RAM anschl. wieder an ?

Kennt ihr irgendwelche Links, VHDL-Modelle, Literatur mit
Realisierungen etc.

Danke....

Und meine Recherche geht weiter...

Um eine Grafik auf dem Display auszugeben, bräuchte ich doch im prinzip
so ein Gebilde wie in der angehängten Grafik, oder ?

Hat irgendeiner eine Idee, wie man das ganze mittel VHDL realisiert ?

Die X/Y-Signale steuern doch die Pixel der Grafik im Speicher. Wie muss
ich mir das vorstellen ?
Also ich lese Pixel für Pixel aus dem Speicher. Jedes Pixel besteht aus
3 RGB-Werten, die ich dann unter korrekten Synch Pixel für Pixel über
meine RGB-Leitungen an das Display schicke. Stimmts ? Bitte korrigiert
mich....

So und nun noch mal zur State Machine.. .Wo liegt a dein Problem???
Grundsätzlich im aufbau einer FSM oder an dem genauen Aufbau??? Ich
habe irgendwo noch ne Statemachine die ich mal für ein 5 MegaPixel
disblay erstellt habe. Hier schmeisst er dir auch gleich die x und y
Koordinate aus. Würde dir das was weiterhelfen? Dann muss ich mal
schauen ob ich das irgendwo finde. Ansonsten mus ich noch mal überlegen
ob ich das erneut erstellen kann.
Mit deinem Speicherproblem kann ich dir leider nicht viel weiter
helfen.  Da hast du aber ja im anderen Thread gute und kompetente leute
an der Hand.

Also das Problem ist grundsätzlich die State Machine. Ich habe keine
Ahnung, wie so etwas funktioniert bzw. aufgebaut ist.

Es wäre echt super, wenn du mir dein Beispiel mal schicken könntest
(hoffe, du findest es noch...). Das wäre klasse.

Also die X/Y-Position beschreiben die Koordinaten jedes Pixels meiner
Grafik. Wie "liegt" die Grafik im Speicher (erstes Pixel oben links
hat Koordinate 0,0 und belegt die ersten 24 Bits, also je 8 Bit für RGB
??? Dann das 2. pixel usw.)
Wie bekomme ich eine Grafik in den Speicher, also wie speichere ich
eine Grafik (welches Format)? Kannst du mir da helfen.

Danke für deine Unterstützung. Gruß

Hallo TPSK

also ich würde deinen Display-Inhalt im RGB-Format in drei SRAMs von je
512kByte abspeichern - quasi für jeden Farbkanal ein SRAM. Da dein
Display 800x480 Pixel hat, brauchst du davon sogar nur 384kByte.

Die SRAMS schließt du dann allesamt an den gleichen Adressbus. Damit
wird gewährleistet, dass du für jedes Pixel auch den richtigen
RGB-Wert. Die drei Datenbusse zu je 8Bit schließt du dann an deine A/D
Wandler für  die VGA-Ausgabe an.
Falls du willst, kann ich dir da mal 'n Layout schicken wie wir das
hier schon seit 'nem Jahr benutzen. VHDL-Code kann ich dir allerdings
aus wettberbs- und lizenztechnischen Gründen nicht geben.
Ein TFT-Display haben wir jedenfalls mit diesem Board auch schon
angesteuert.

Hoffe ich konnte dir weiterhelfen ...

@ Michael...
Oh die ansteuerung würde mich auch interessieren. Momentan bin ich in
sachen SRam ansteuerung noch nen Noob. Kannst dzu das Layout hier im
Forum posten?

@Michael...

auf jedenfall bin ich an dem Layout interessiert (die Lösung klingt
interessant). Wäre super, wenn du es mir schicken könntest oder hier
posten könntest.

Gruß TPSK

@ Axel & TSPK

ist das Layout für unser XCV100E-Board. Hoffe man kann noch was drauf
erkennen. Ist nämlich ein A3-Blatt was ich nur abfotografieren kann
wegen mangelnder scan-hardware ;)

Was euch evtl. besonders interessiert ist alles was an Pin 3-66 hängt.
Die VGA-Treiber sind allerdings nicht mit auf diesem Schematic. Diese
befinden sich auf einer anderen Platine, die über die 40poligen
Steckverbinder "Huckepack" auf die Mutterplatine gesteckt wird.
Die Speicherdaten haben wir entsprechend im FPGA "durchgeschliffen"
... naja werde aus dem Schaltplan schlau wer kann und muss :-P
Ich stehe euch aber gerne fuer Fragen diesbezüglich zur Verfügung

Donnerschlag... gute auflösung .-) Da kann man ganz gut ranzoomen. Wenn
ich mal Zeit habe werd ich mirdas mal zu gemüte führen. Danke dir.

N'abend

habe nochmal in unser Archiv geschaut und das hier gefunden (siehe
Anhang). Du hattest doch gefragt wie man ein VGA-Display an den FPGA
anschließt.
Hier hast du den 3x8-bit DAC für die 3 Farbkanäle. Du kannst an die
15Pin SubD Buchse dann jedes TFT, jeden CRT oder ähnliche Geräte mit
SUBD-Eingang anschliessen.

Hoffe das hilft dir bei "Wie anschließen?" weiter ...

Erst mal vieln Dank für eure Unterstützung (war/ist große Hilfe für mein
Projekt). Besonderen Dank an Axel M. ;-)

Jetzt aber genug des Dankes und der Grüße und zurück zu meinem Problem.
OK, das Prinzip zur Erzeugung der Synch-Signale etc. habe ich jetzt
soweit verstanden. Allerdings habe ich noch einige kleine Fragen:

1)

Wie berechne ich die Werte für
- HCounter
- VCounter
- Back Porch + Sync Pulse + Front Porch etc.
für bestimmte Display-Auflösungen ? -> Formel ?

2)

Ich benötige zusätzlich X/Y-Positionen, die die jedes Pixels meiner
Grafik im Speicher beschreiben.

- Wie "liegt" die Grafik im Speicher (erstes Pixel oben links
hat Koordinate 0,0 und belegt die ersten 24 Bits, also je 8 Bit für RGB
??? Dann das 2. pixel usw.)

- Welchen Speicher benutzt man am besten und warum (DDR-SDRAM, SRAM,
etc.)?

- Wie bekomme ich eine Grafik in den Speicher, also wie speichere ich
eine Grafik und lade sie in einen Speicher ? Ist mir noch unklar.

- Irgendwelche Beispiele zur Realisierungen in VHDL ?

Vielen Dank

>>Wie berechne ich die Werte für ....

http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html
http://xtiming.sourceforge.net/cgi-bin/xtiming.pl

sollte ausreichend sein.

Gruß Hagen

Ja, die Seiten sind schon echt prima, aber ich bin an Formeln zur
Berechnung der Werte interessiert.

siehe: Fragen 1) und 2)

Gruß...Danke !!!

Hi...
schau dir mal den VHDL Code, den ich dir geschickt habe an. Da wird
automatisch auch immer der x und y Wert ausgegeben.

>- Wie "liegt" die Grafik im Speicher (erstes Pixel oben links
>hat Koordinate 0,0 und belegt die ersten 24 Bits, also je 8 Bit für
>RGB
>??? Dann das 2. pixel usw.)
Genau so ist es. Du solltest jeden Pixelwert einzeln abspeichern. So
wie du es selbst beschrieben hast, ist es schon meinmer meinung nach
die beste Lösung. (siehe BMP Bilder ohne Header)

Zum Thema Berechnungsformeln muss ich auch grad passen. Schau mal nach
VGa spezifikation oder der gleichen im Internet. Evtl hilf dir das
weiter.

@TPSK

>- Wie "liegt" die Grafik im Speicher (erstes Pixel oben links
>hat Koordinate 0,0 und belegt die ersten 24 Bits, also je 8 Bit für
RGB
>??? Dann das 2. pixel usw.)
>
>- Welchen Speicher benutzt man am besten und warum (DDR-SDRAM, SRAM,
>etc.)?
siehe mein Beitrag gleicher fred weiter oben
http://www.mikrocontroller.net/forum/read-9-184389.html#187983

um nocheinmal auszuholen/zusammenzufassen:
Also du wirst kaum einen Speicher mit 24bit Organisation finden. Daher
empfehle ich dir entweder zwei asynchrone SRAMs zu je 16bit (wovon im
ersten zwei und im zweiten nur ein Farbkanal zu je 8bit abgelegt ist)
oder drei asynch. SRAMs zu je 8bit ... halt fuer jeden Farbkanal
einen.

>- Wie bekomme ich eine Grafik in den Speicher, also wie speichere ich
>eine Grafik und lade sie in einen Speicher ? Ist mir noch unklar.

Wie bekomme ich die Milch ins Glas? Nee, Scherz ;). Deine
Bildinformation musst du dir entweder von extern (z.B. einem Flash oder
RS232) holen, oder du generierst dir halt selbst ein Bildchen (weiß
jetzt nicht so genau was du machen musst/willst).
Für das WIE speichern solltest du dir mal ein Datenblatt von einen
SRAM durchlesen. Da sind die Schreib- und Lesezyklen eigentlich gut
dokumentiert.

SD-RAM/DDR-RAM und generell alle synchronen RAMS würde ich dir als
Anfänger nicht empfehlen, da du alleine hier Wochen ins Land gehen
lassen kannst, um die Timings und Ansteuerung in einem FPGA zu
implentieren.

gruß
Michael

Hey schaut mal bitte in diesen Forum-Beitrag:

http://www.mikrocontroller.net/forum/read-1-193289.html#new

Ich habe da noch ein paar Fragen...

Gruß

Mein Tip an dich:

erklaer mal Leuten hier (evtl. in einem separaten fred) was genau du
vorhast und was fuer Hardware dir zur Verfuegung steht.

Habe jetzt in deinem anderen thread zur Display-Ansteuerung gerade
gelesen, dass du eigentlich ein digitales Display verwendest.
Da kannst du naemlich schon mal die Haelfte meine Postings hier in den
Skat druecken, weil die nicht wirklich zur Problemloesung beitragen, da
ich dachte, dass du ein stinknormales VGA-Display mit RGB-Eingang hast.

Und ich kann mich leider nur Rufus anschließen: Nutze mehr die
Dokumentationen/Datenblaetter. Dadurch verringern sich deine Fragen
alleine um die Haelfte ...

Gruss

PS: bring mal hier ein wenig mehr Durchblick[TM] in die Kiste
Du hast jetzt hier schon 4 oder 5 freds aufgemacht, die sich alle
irgendwie ums gleiche Thema drehen. aber ich steig da langsam nicht
mehr durch

Hi... na da muss ich mich dem Michael anschliessen. Ich verleir so
langsam auch den durchblick. Das hätte man doch super bei den beiden
threads belassen können. UIch denke es fehlen noch viele Basics. Zum
beispiel würdest du die Probleme mit dem Coden bestimmt selber lösen
können, wenn du dir mal die FSM reinziehen würdest. Dann brauchst du
auch keine Codeschnippsel. Ach ja und aus eigener Erfahrung kann ich
nur sagen, das die Displays gerade in TFT Bereich immer mindestens die
Daten für Hsync VSync, oder wie es auch immer genannt werden, zu finden
sind. Wär doch schlimm wenn da keine Infos zur Verfügung stünden.

Was dich jetzt aber nicht von fragen abhalten soll... :-). Oder ist die
beschreibung deines Auftraggebers so schwammig? Sowas kenne ich ja
leider auch. Aber da hilft nur penetrantes Nachfragen...

OK, Ihr habt wahrscheinlich recht. Ich werde mich jetzt erstmal mit den
Basics beschäftigen...(Datenblätter durchforsten, timings studieren
etc.)

Und trotzdem muß ich sagen, dass alle Eure Beiträge mir (als blutiger
Anfänger im Ansteuern von Displays) schon für das Verständnis enorm
weitergeholfen haben...VIELEN DANK dafür.

Bevor ich jetzt die nächsten Fragen stelle (ganz abgeschreckt habt ihr
mich noch nicht ;-), werde ich mich noch etwas intensiver mit dem Thema
beschäftigen. Wahrscheinlich kann ich dann auch meine Fragen präzisieren
und minimieren.
Ich weiß ja auch, dass Ihr recht habt, aber manchmal sieht man halt nur
einen großen Berg vor sich und weiß gar nicht, wo man anfangen soll
(...zu fragen).

Dennoch bin ich immer offen für weitere Beiträge zu meinen bereits
gestellten Fragen.

Also dann Gruß