Grafik über BAS mit AVR - Projekt

[WendlaB]

So! Hallo, ich bin neu hier im Forum! =)
und ich möchte gleich mal anfangen und meine Pläne vorstellen. Weil ich noch nicht sonderlich bewandert bin und außer einer guten Begabung und Erfahrung für alles was in Richtung Programmierung geht (*hust*) nichts an Skill vorweisen kann und gerade erst mit AVRs angefangen habe, denke ich mir: lesen ist nicht alles! Ich habe nicht genug Ahnung von allem was in Richtung Aktive Bauteile geht, und hier im Forum bekomme ich bestimmt konstruktive Kritik!
ich habe einen recht guten Überblick über Assembler und alles, was mit einem µc möglich ist und habe die Zeit und die Motivation, folgendes zu verwirklichen:

ein AVR-basiertes BAS-PAL Signal in S/W das mit möglichst wenig hardware trotzdem >grafik<-fähig ist. Es soll über UART angesteuert werden.

Es gibt ja bereits eine ganze Batterie an AVR-terminals, aber ich möchte eben Grafik haben; und die Grafik-lösungen die ich gefunden habe waren mir zu hardwarelastig, (z.B. RGB-wandler und solche späße, denn wenn man Ahnung hat, dann macht man es offensichtlich gleich vernünftig ^^)

meine geplante Hardware soll sein:

-AVR, am liebsten atmega8, atmega16 oder atmega32, die gefallen mit am meisten, aber offensichtlich kann es gut sein dass es auf einen 8515 hinauslaufen wird, weil da die speicherverwaltung leichter extern gelöst werden kann. (habe ich das richtig verstanden?)

-externer RAM, ich habe mir ein 64k x 1 oder ein 32k x 8 in meine nähere betrachtung gezogen. (beide bei reichelt um 1€)

-ein paar Widerstände, ein 16MHz Quarz-Oszillator und Kabel.

meine Fragen lauten nun:

-ist der spaß überhaupt realisierbar oder mache ich irgendwelche Fehler, wie z.B. dass ich nicht genügend Ports frei habe oder irgendwas in dem Kaliber?

-der kleinere RAM ist schneller (10ns) und braucht weniger anschlüsse an meinem AVR, kann jedoch maximal die Auflösung 280*210 rausholen. Der größere RAM ist groß genug, dass die maximale Auflösung durch den AVR begrenzt wird, ist aber wesentlich langsamer (70ns) und braucht wesentlich mehr pins. Was ist geeigneter?

-welchen AVR soll ich nehmen und welche Auflösung kann ich mit dieser Hardwarelösung maximal rauskitzeln?

Bevor ich ins offene Messer springe und einfach Hardware kaufe um später zu merken dass das was ich vor habe gar nicht geht, frage ich hier um einen guten Rat zu bekommen worauf ich achten sollte und ob es überhaupt geht.

Vielen Dank im Voraus =))
Wendla

[BASTIUniversal]

Hi!
Ganz neu und schon ins falsche Forum gepostet :-(

Verschoben!

MfG
Basti

[roboterheld]

....ein AVR-basiertes BAS-PAL Signal in S/W das mit möglichst wenig hardware trotzdem >grafik<-fähig ist. Es soll über UART angesteuert werden. ....

gibt es schon.

schau hier im forum oder hier , die grafikauflösung ist nicht so hoch :

http://www.mikrocontroller.net/topic/53140#new

[WendlaB]

ich wollte es wirklich grafik werden lassen und nicht text-basiert, also für jeden pixel auch ein bit speichern, das missverständnis tut mir leid =/

mache ich da einen denkfehler?

vielen dank!
wendla

[roboterheld]

brauchst nur die zyklen-zeit umschreiben um das schnell genug zu machen , sram dran und schon hast du grafik.

mfg

[WendlaB]

mir ist schon klar, dass ich viel übernehmen kann, ich werd mir auch angucken wie genau die syncs realisiert wurden usw.

aber im gegensatz zu dem terminal bei dem link möchte ich nicht meinen bildschirminhalt in form von einem array aus ascii-zeichen speichern, sondern die speicher-intensivere variante wählen und pixel für pixel abspeichern, was (so glaube ich) ein kleines stück schneller geht als in der bibliothek mit dem zeichensatz nachzusehen und etwas mehr flexibilität gibt. (GRAFIK! z.B. könnte man eine maus anschließen oder eine funktion zeichnen lassen oder sinnvoll irgendwelche spiele programmieren, mit einem ascii-speicher geht das nicht so)

dass es möglich ist, ist mir schon klar, und du hast ja auch gerade genau das gesagt was ich mit meinem ersten post ausdrücken wollte (vielleicht hab ichs zu ungenau gesagt)

aber ich habe eben noch ein paar fragen (siehe oben) zu denen ich gerne etwas hilfe hätte :-S

[JanB]

Hallo,
die Erzeugung des BAS-Signales direkt mit Pixelgrafik ist erheblich
einfacher als mit ASCII-Zeichenspeicher.
Du brauchst halt nur reichlich SRAM.
Ich würde eine der großen AtMegas nehmen mit 8K SRAM.
Damit kannst du problemlos Auflösungen bis 256x256 in Schwarz-Weiss erreichen.
Oder z.B 180x180 mit vier Graustufen.
Externer Speicher hat den Nachteil, das die Zugriffe langsamer sind.

Gruß Jan

[WendlaB]

oho! der legendäre JanB! Professionelle Hilfe!

also ich schwanke noch zwischen reichelt RAM 64K X 1 (http://www.datasheetcatalog.net/de/datasheets_pdf/7/C/1/8/7C187-20.shtml ) und reichelt SR 32KX8 28P http://www.reichelt.de/?;ACTION=6;LA=3;ARTICLE=2673;GROUPID=2954;GROUP=A3 4;SID=25@j3w8on8AAAIAABuS1h74531ad2b486d5d710e8a6e 8d20e6814

der erste ist schneller und hat weniger speicher, der zweite ist langsamer und hat mehr speicher. ich kann mich nicht entscheiden welcher von beiden geeigneter ist. vielleicht könnt ihr mir helfen?

(@ JanB)
du würdest an meiner stelle den 64K-speiher nehmen, wenn ich dich richtig verstanden habe? gibt es dafür einen besonderen grund? ist größerer speicher vielleicht nicht sinnvoll weil der avr nicht schnell genug ist?

[CowZ]

Hi,

schöner Zufall, ich plane genau(!) das gleiche :D

Was problematisch ist: du musst das RAM verdammt schnell ansteuern. Du hast pro Bildzeile 52µs Zeit, den Pixel als Analogwert zu wandeln. Ich plane das RAM mit 5MHz anzusteuern und so ~250 Pixel Auflösung zu erhalten. Das ganze soll extern vom µC laufen, der da ernsthafte Probleme bekommen wird, gleichzeitig noch vom UART zu empfangen.

Ich habe zwei RAMs, eines, von dem das Bild zu BAS gewandelt wird, und eines, in das der µC schreiben kann (die Daten vom UART). Sobald ein Bild fertig übertragen ist, schaltet der µC das RAM um.

Vielleicht können wir uns darüber ja nochmal per ICQ oder so unterhalten, haben ja sicherlich die gleichen Probleme :)

Gruß, CowZ

[JanB]

Hallo,

du würdest an meiner stelle den 64K-speiher nehmen,
wenn ich dich richtig verstanden habe?
Nein, meine Idee war ganz auf externes RAM zu verzichten
und direkt einen AVR mit 8k-Bytes internem SRAM zu nehmen.
z.B. MEGA640, MEGA1280 oder so. Ohne weitere externe Hardware.

Ein interessantes Projekt übrigens.
Da könnten wir evtl. auch gemeinsam dran basteln.
Wenn es um den Spaß an der Entwicklung geht,
und weniger um praktische Anwendung, dann könnte man
das auch einfach und kostengünstig auf einem Mega32 entwickeln.
Der hat 2K-SRAM, das ermöglicht auch schon eine Auflösung
von 128x128 sw ohne externe Hardware. Nur der Mega32 alleine.
Da könnte man die ganze Videosignalerzeugung aber auch die
Grafikroutinen für Linien, Kreise, Schrift usw. drauf programmieren.
Rechenpower und Flash hat der genug.

Gruß Jan

[CowZ]

Hi,

@JanB:
was ich auch bei deinem (auf mikrocontroller.net) vorgestellten Projekt nicht verstanden habe... Wie schaffst du es, die Daten auf dem µC so schnell zu verarbeiten?

Bei ner Auflösung brauchst du ja ne Pixelfrequenz von etwa 2,5MHz. Wenn der µC jetzt noch Daten empfangen oder gar selber berechnen soll!? Wie soll das gehen? (du hast es ja geschafft :P)

Gruß, Lasse

[JanB]

Hi Lasse,
keine Ahnung wie du auf 2.5 MHz Pixelfrequenz kommst ?
Das Terminalprogramm in der letzten Version macht 40 Zeichen pro Zeile.
Diese 40 Zeichen werden in 40us ausgegeben. (52us wäre TV-Norm, aber dann
siehst du die ersten und letzten Zeichen nicht mehr auf jedem TV wg. Overscan)
Jedes Zeichen hat 8 Pixel, also 40x8 macht 320 Pixel pro Zeile.
320 Pixel in 40us ergibt eine Pixelfrequenz von 8 MHz.
Ist ja auch klar, denn die Pixel schiebe ich aus dem SPI-Port raus,
und der SPI Taktteiler in meinen Programm ist 2.

Die Videoausgabe erfolgt interruptgesteuert und beansprucht
ca. 50% der Rechenzeit des Mega8.
Der hat also noch reichlich "Freizeit" für die Bedienung des USART
und für das Terminalprogramm.
Und er könnte auch noch andere Sachen machen, wenn diese mit
den ständigen Unterbrechungen durch die Videoausgabe leben können.
Leider ist es mir bisher noch nicht gelungen die Abfrage einer
PS2-Tastatur in dem Timing mit unterzubringen.
Das hätte ich nämlich gerne noch gemacht. Naja, mal sehen...

Aber wir sind jetzt etwas OT hier, mal sehen wie WENDLA mit seiner Idee weitermachen will.

Gruß Jan