Geschätztes Forum,
ein kleines Beispiel wie mit einem ATmega1284p 20MHz ein 640x480 60Hz
VGA-Signal generiert werden kann.
Effektiv können 164x120 RGB-Pixel in 8 Farben dargestellt werden (Rot,
Grün, Blau, Gelb, Magenta, Cyan, Schwarz und Weiß), ein Pixel besteht
aus 4 VGA-Zeilen.
Leider nur 164 X-Pixel, mehr gibt der Pixeltakt nicht her.
Diese Version kann ein Pixel an der Position X,Y setzen, geometrische
Figuren und ASCII-Zeichen beherrscht sie noch nicht.
Ein sogenannter "Turbo-Modus" beschleunigt die Graficdarstellung. Jede
VGA-Zeile wird auf RGB-Dateninhalt geprüft, liegen keine RGB-Daten vor,
dann wird sofort die Interruptroutine verlassen und das Hauptprogramm
kann weiter bearbeitet werden.
Es wird nur ein 16 Bit CTC-Timer benötigt, welcher auch eine
Taktkorrektur vornimmt, denn ein Interrupt wird nicht immer mit der
gleichen Anzahl von Takten angesprungen. Die VGA HSYNC und VSYNC-Impulse
müssen absolut jitterfrei generiert werden, ansonsten zappelt das Bild
oder der VGA-Monitor schaltet sogar ab.
Stimmt etwas mit der Taktkorrektur nicht, dann leuchtet die rote LED.
Ein paar Worte zum Bildspeicheraufbau:
Der Bildspeicher befindet sich im SRAM. Jedes SRAM-Byte speichert 2
Pixel.
164x120=19.680 Pixel :2 Pixel pro Byte = 9.840 Byte
Bit[0] = Rot (linkes Pixel)
Bit[1] = Grün (linkes Pixel)
Bit[2] = Blau (linkes Pixel)
Bit[3] = Reserve (linkes Pixel)
Bit[4] = Rot (rechtes Pixel)
Bit[5] = Grün (rechtes Pixel)
Bit[6] = Blau (rechtes Pixel)
Bit[7] = Reserve (rechtes Pixel)
Die RGB-Pixel werden wie folgt ausgegeben:
1
LD temp,Y+ ; aus SRAM laden (2 Pixel)
2
out PORTB,temp ; linkes PIXEL ausgeben (unteres Nibble)
3
SWAP temp ; Bit-Umkehr
4
nop ; Pause
5
out PORTB,temp ; rechtes PIXEL ausgeben (oberes Nibble)
Für Hinweise und Vorschläge bin ich sehr dankbar.
Bernhard
@alle
In dieser Version arbeitet der µC ATmega1284p leicht übertaktet mit
22MHz.
Nun können 180x160 (28,8k) farbige Pixel dargestellt werden, bei 3
VGA-Zeilen pro Pixel.
Der integrierte 8x12 ASCII Zeichensatz ermöglicht die Anzeige von Text
und Zahlen (22x13), natürlich in Farbe und Bunt :-)
Bei Bedarf kann der Zeichensatz problemlos editiert werden, er ist in
der Tabelle >VGA_TABELLE_ASCII_8x12.asm< hinterlegt, die ASCII-Zeichen
werden so dargestellt, wie sie mit dem Auge in der Tabelle zu sehen
sind.
Einzelne Pixel können per X/Y Koordinaten gesetzt werden, links unten
ist X=0 Y=0.
Der Bildspeicher benötigt 14.400 Byte SRAM (180/2 x 160), bei 2 PIXEL
pro SRAM-Byte.
Ein 20ms TIMER versorgt die interne Uhr, eine DCF-Erweiterung z.B. im
Samplingverfahren wäre möglich.
Ein weiterer TIMER im CTC-Modus stellt eine Frequenz zur Verfügung.
Im Bild "B6_ANZEIGE.JPG" werden die OCR-Einstellungen der Timer
angezeigt und die tatsächlich generierten Frequenzen., vorausgesetzt der
Takt stimmt.
Mit der Ansteuerung der Displays LS7 + LS8 gab es keine Probleme,
funktionierte sofort.
Hier findet Ihr ein paar wertvolle Hinweise zur Übertaktung eines AVR:
Beitrag "ATmega1284p mit 24MHz übertakten">Ob die ARM-Fraktion sowas auf einem AVR für möglich gehalten hätte?>Und ich möchte gern mal das Gleiche in C Plus Plus sehen... ;-)
Oh, damit kann ich leider nicht dienen.
>Beim Thema Pixeltakt: schon mal einen atXmega versucht? Der kann etwas>mehr.
Mich persönlich stört nur die Gehäusebauform eines atXmega.
Bernhard
Eine mögliche Variante, wie ein DCF-77 Signal ausgewertet werden kann.
Das DCF - Signal wird mit einem Samplingverfahren 50 mal pro Sekunde,
also aller 20ms abgetastet um ein DCF-LOW bzw HIGH zu erkennen.
Eine Automatik erkennt, ob das Ausgangssignal des DCF-Empfängers
invertiert oder nicht invertiert ist.
Die Phasenlage des DCF-Signals zur internen Uhr wird überwacht, eine
Genauigkeit von ca. 20ms ist derzeit möglich.
Auf dem Bild sind einige interne DCF-Werte dargestellt. Das P steht z.B.
für die Phasenlage.
Bernhard
Da fehlt jetzt eigentlich nurnoch ein UART oder I2C Input damit der AVR
von außen gesteuert werden kann.
Dann ist das Teil als Bildschirmtreiber für einen Hauptprozessor
nutzbar.
>Da fehlt jetzt eigentlich nurnoch ein UART oder I2C Input damit der AVR>von außen gesteuert werden kann.
Das sehe ich auch so !
Ich stell mir momentan folgende Lösung mit 2 Buffer (FIFO) vor, in
Anlehnung an das EA eDIPTFT32-ATP / EA-EDIP-TFT32ATP :
Der Master sendet in "aller Ruhe" eine Steuersequenz, Beispiel Linie
zeichnen, diese Datenbytes landen im 256 Byte großen Empfangspuffer:
1.Byte: "ESC" - Beginn eines Steuersequenz
2.Byte: 0x06 - Anzahl der Datenbytes incl. PS
3.Byte: "L" - für Linie
4.Byte 0x00 - Koordinate X1
5.Byte 0x00 - Koordinate Y1
6.Byte 0x10 - Koordinate X2
7.Byte 0x10 - Koordinate Y2
8.Byte 0x?? - PS - Prüfsumme
Wurde eine Steuersequenz erfolgeich empfangen, dann werden die Daten in
den Macro-Puffer geschieben, aber dann so schnell wie möglich
abgearbeitet.
Beispiel:
- Steuersequenz "Pause 10ms"
(damit nachfolgende Steuersequenzen noch empfangen werden können,
dann wäre der Bildaufbau schneller)
- Steuersequenz "DISPLAY clear"
- Steuersequenz "FARBE"
- Steuersequenz "Linie mit Koordinaten"
- Steuersequenz "Linie mit Koordinaten"
- Steuersequenz "FARBE"
- Steuersequenz "POSITIONIERUNG TEXT"
- Steuersequenz "TEXT"
Auf eine Rückantwort vom Dislay, ob DATEN erfogreich empfangen wurden,
würde ich sogar verzichten. Im Ernstfall fehlt z.B. mal eine Linie, das
wäre verschmerzbar.
VGA_TESTBILD_FARBBALKEN.JPG
(250 KB)
VGA_TESTBILD_FARBPIXEL.jpg
(240 KB)
VGA_TESTBILD_FARBPIXEL_ZOOM.JPG
(230 KB)
SCHALTUNG_VGA.jpg
(110 KB)
additive_FARBMISCHUNG.gif
(7 KB)
