VGA Terminal mit ATMega644

gvs schrieb:
> Dumm nur das es eigentlich keine analoge Schittstelle mehr dafür gibt,
> oder glaubst du wirklich dass DVI mit Anlogeingang an digitalen Geräten
> zukunftsfähig ist?

Naja, so lange 99,999% aller Projektoren in Firmen nur ein VGA-Kabel zum 
Tisch darunter liegen haben, wird VGA weiter existieren.

matrixstorm schrieb:
> Aber gibts zu dem Projekt denn noch sowas wie Gerber/Boardfiles?

Es gibt alles dazu auf der Seite der TU-BS oder bei Bedarf von mir.

Zu "warum VGA?": Natürlich ist das aus der Steinzeit. Ich nehme das als 
Debug Terminal für diverse Schaltungen. Ein alter 17" Monitor, ein 
Hackbrett und diese kleine Zigarettenschachtel. Mit extra serieller 
Schnittstelle per USB am PC habe ich keine allzu guten Erfahrungen.

stefanus schrieb:
> Wann hat er überhaupt Zeit, die auszugebenden Bytes zu berechnen?

War der nicht bereits auf 25MHz uebertaktet?

MfG

@ stefanus (Gast)

>Ich stelle mir die Programmierung spannend vor. Das war bestimmt nicht
>einfach, das richtige Timing für die Ausgabe hinzubekommen.

Mit dem richtigen Trick7Konzept geht das. Das ist nicht neu. BAS 
Videosignale wurden auch schon per AVR erzeugt, VGA hat hat mindesten 
doppelte Zeilenfrequnz.

>Wann hat er überhaupt Zeit, die auszugebenden Bytes zu berechnen?

Es reicht. Eine Verschnaufpause und deutlich Rechenzeit gibt es kurz 
zwischen den Zeilen (Horizontale Austastlücke) und länger zwischen den 
Bildern (vertikale Austastlücke). Bei 31,x kHz Zeilenfrequenz immer noch 
schnell genung, den UART per Polling abzufragen.

@ c-hater (Gast)

>Only ASM rules.

Jaja. Wer einen Controller missbraucht, um die niedere, geradezu 
triviale Aufgabe eines Zeichengenerators zu übernehmen, frisst auch 
kleine Kinder. ASM-Programmierer sowieso ;-)

>Das allerdings ist leider nur zu wahr. Leider ist es bis heute nicht
>möglich, nur mit einem AVR-Controller eine (monochrome) Vollgrafik in
>VGA-Auflösung anzubieten, weil Atmel einfach keinen im Sortiment hat,
>der dafür genug SRAM intern bieten würde.

Wozu auch? Siehe oben. Ausserdem gibt es längst genügend Alternativen. 
Diese VGA/Terminalgeneratoren sind "nur" eine Leistungsdemonstration der 
AVRs bzw. anderer Controller, nicht wirklich die Hauptanwendung.

> Die dafür nötige
>Rechenleistung hingegen haben sie schon seit langem.

Für volles VGA? Kaum.

>VGA-Timing, exakt entsprechend "VGA" (im engeren Sinne) oder auch dem
>256Farben-Modus von SVGA).

Kauf dir ein passendes LCD mit Intelligenz und fertig.
Du wirst die Unmengen alter VGA Monitore mit diesem Terminal nicht vor 
der Verschrottung retten.

>Alles keine große Kunst, wenn man programmieren kann, insbesondere in
>der einzigen Sprache, die eine optimale Ausnutzung der verfügbaren
>Resourcen ermöglicht. Und nein, das ist definitiv nicht C...

https://de.wikipedia.org/wiki/Fetischismus_%28Religion%29

c-hater schrieb:

> Das allerdings ist leider nur zu wahr. Leider ist es bis heute nicht
> möglich, nur mit einem AVR-Controller eine (monochrome) Vollgrafik in
> VGA-Auflösung anzubieten, weil Atmel einfach keinen im Sortiment hat,
> der dafür genug SRAM intern bieten würde. Die dafür nötige
> Rechenleistung hingegen haben sie schon seit langem.

Dann nimmt man halt was anderes. ZB PIC24FJ256DA206. 96k RAM eingebaut, 
Grafikcontroller drin, Grafikbeschleuniger drin. Und das alles in einem 
64 Pin TQFP. Es gibt auch ein Leben nach dem AVR.

fchk

Zur Info: Die erste Charge der Platinen ist vergeben. Die Bestellung 
läuft.

Update: Leiterplatten sind produziert und in der Post.

Die Platinen sind nach den Unterlagen auf der TU-BS Seite gefertigt. 
Eagle meint, Schaltbild und Platine seien konsistent. Als muss das 
Schaltbild (nicht das PDF, das Schaltbild aus dem ZIP!) dort auch zum 
Bestückungsdruck passen und eine BOM sollte man daraus auch generieren 
können.

Noch ein Hinweis: Der Quelltext auf der Projektseite lässt sich nicht 
fehlerfrei linken. Im ZIP-File sind aber ein ELF und ein HEX File 
enthalten, die man auf einen ATMega644 flashen kann und die 
funktionieren.

Momentan ist hier etwas Stress. Eventuell schaffe ich es am Wochenende, 
einen Satz konsistente Unterlagen zu erstellen.

c-hater schrieb:
> Das allerdings ist leider nur zu wahr. Leider ist es bis heute nicht
> möglich, nur mit einem AVR-Controller eine (monochrome) Vollgrafik in
> VGA-Auflösung anzubieten, weil Atmel einfach keinen im Sortiment hat,
> der dafür genug SRAM intern bieten würde. Die dafür nötige
> Rechenleistung hingegen haben sie schon seit langem.

hast du dir mal den m1284p angesehen ?

ich war erstaunt 16kB Ram warum gibts das nicht im m328p ? oder einen 
Arduino mit dem ?

der 1284p hat sogar mehr SRAM als der m2560

Dann mal auf die Schnelle Schaltbild, Bestückungsplan und BoM für die 
aktuelle Platine. Um die Soft kümmere ich mich später (oder ein anderer 
tut es).

Noch ein Hinweis: mit einem ATMega644 muss man die Keyboard Routinen aus 
dem "alten" Thread auf MKC.NET nehmen und anpassen. Der Quältext auf der 
aktuellen TU-BS Seite möchte einen ATMega mit 2 UARTs sehen, ATMega1284p 
als Beispiel.

Der Linker Fehler lässt sich bei Verwendung eines ATMega1284p 
beseitigen, wenn man in den Custom Options big_align passend rauf setzt, 
auf 0x6000 zum Beispiel.

Klar tut es das. Jeder AVR kann damit leben (oder vegetieren?). Ein 
Kondensator und ein Pullup am Reset wären hilfreich gegen Störungen. 
Ohne alles ist es recht hochohmig. Aber notfalls geht es auch so.

Harald Nagy schrieb:
> Statt den 0 Ohm Widerständen funktionieren auch Drahtbrücken oder
> 1 Ohm?

Wie viel Ohm hat eine Drahtbrücke? Annähernd 0 würde ich vermuten.

Ich habe mit Drahtbrücken bestückt.

karadur schrieb:
> Liegt wahrscheinlich am falschen
> Quellcode.

Wenn du Erfolge hast, bitte posten. Der Kiosk Mode kann ja wohl raus. 
Welchen Prozessor nimmst du?

karadur schrieb:
> wo ist der andere Quellcode zu finden?

Auf der TU-BS Webseite findest du die "moderne" Version, die mit dem 
aktuellen GCC fast ohne Warnungen übersetzt wird. In den custom linker 
options nur big-align passend setzen, beim 644 sollte 0x6000 gut sein 
(dort wandert der Font hin).

Den alten Quelltext (Keyboard ohne Scancode Übersetzung, einlesen nicht 
via UART) findest du hier im Thread 
Beitrag "AVR VGA Terminal" (mehrere 
Versionen, die letzte ist wohl am besten).

Ich habe momentan leider wenig Zeit. Aber gemeinsam sollten wir ein 
"rundum sorglos Paket" hinbekommen.

ohne Bootlader, Takt = externer Oszillator, Brown Out falls gewünscht, 
Watchdog an die Leine.

Harald Nagy schrieb:
> meinen Monitor dazu bringe, das ganze
> Bild anzuzeigen

Mein 17" Acer TFT brauchte dazu nur einen Druck auf die Taste 
"Automatischer Abgleich" :-)
Was für einen Monitor hast du? Der verwendete Modus ist eigentlich in 
jedem Monitor drin, ist was ganz übliches.

Guten Abend,

hat zufällig einer von euch noch ein oder zwei Sätze der Anschluss 
Buchsen übrig.Die in diesem Projekt verwendet werden.


Gruß und Danke.

Ronny

Harald Nagy schrieb:
> Neuigkeiten von der Front?

Demnächst... zu viele Projekte, zu wenig Zeit.

Zwischenbericht:
Der ATMega644 funktioniert nicht, das zweite UART fehlt. Mit dem 
ATMega644A würde es klappen. Das RAM ist dann aber zu 99% voll. Also 
sollte man gleich den ATMega1284P nehmen.

Die Platine hat einen Fehler. Der Tastatur Takt geht an XCK0 (Pin 1) und 
nicht an XCK1 (Pin 18),wo er hin sollte. Also bitte die Verbindung von 
Pin 18 zum MAX232 auf der Unterseite trennen und einen Draht zwischen 
Pin 1 ud Pin 18 legen.

Eine erste lauffähige Software kommt innerhalb der nächsten zwei Wochen 
- hoffe ich.

Hier eine Version mit Propeller.
Beitrag "VT100-Terminal (VGA+PS2)"

Anbei der erste Versuch einer Software. Abweichend vom Original wird ein 
VT52 Terminal rudimentär emuliert (mein CP/M aus der Steinzeit mag so 
moderne Terminals wie das VT100 nicht, ich bekomme den Wordmaster nicht 
dafür gepatcht).

Es fehlt die Ansteuerung der LEDs in der Tastatur. Da habe ich noch 
keine Idee, wie ich das bei dem engen Timing machen kann.

Es sind nicht alle Tastenkombinationen dekodiert bzw liefern Codes, die 
für dumme Systeme unverständlich sind.

Es ist noch nicht alles entrümpelt. Diverse Dinge, die vermutlich aus 
historischen Gründen im Code enthalten waren, sind nur auskommentiert.

Fehler bitte melden (am besten gleich mit Reparaturanweisung :-) )

Harald Nagy schrieb:
> (interessanterweise nur mit original PS/2; USB-Tastatur mit Adapter
> funktioniert nicht)

"USB-Tastatur mit Adapter" funktioniert nur, wenn die Tastatur 
bilingual ist, wenn sie also sowohl USB als auch PS/2 unterstützt. Der 
Adapter ist dumm, der sagt der Tastatur nur, welches Protokoll sie 
verwenden soll.

Und damit ist so ein Adapter für nicht-bilinguale USB-Tastaturen nicht 
zu gebrauchen.

Bei Mäusen ist das übrigens genauso, und war auch "damals" schon so, als 
der Wechsel von Mäusen für RS232 auf PS/2 stattfand.

Harald schrieb:
> Neuigkeiten

Es funktioniert hinreichend.