www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RAM Timing bei Videoadapter mit ATMEGA8515


Autor: Hobbybastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab vor einen Videoadapter mit einem 16MHz ATMEGA 8515 zu bauen, der aus
einem externen Speicher Videodaten liest und ein FBAS Signal generiert
(das ganze soll später, falls der Adapter funktioniert, zu ner kleinen
8Bit Spielkonsole erweitert werden).

Die Theorie ist soweit folgende: timergesteuert wird alle 64µs ein
Interrupt ausgelöst, der das Zeilensignal generiert. Dabei beträgt die
Auflösung der Konsole 160 Zeilen, die aber gedoppelt werden damit die
Pixel nicht "zu klein" sind. Es werden damit 320 FBAS Zeilen
generiert, bleiben also später rund (575-320)/575 = 44% der CPU
Ressourcen für das Spiel.

Das Zeilensignal wird wie folgt generiert: Schwarzschulter, dann 52µs
die Pixel ausgeben, 1 Byte im Speicher = ein Pixel; Pixel werden aus
dem Speicher gelesen und (um Zeit zu sparen) direkt an einen 8 Bit
Ausgabeport angelegt. Dort werden 2 Bit Luminanz (-> 4
Helligkeitsstufen) und 6 Bit Chrominanz (4 Bit Farbton = 16 Farben und
2 Bit Sättigung) abgegriffen, macht insgesamt 3*(3*16+1)+1 = 148 Farben
weil sich unter den 256 einige doppeln. Die Einzelsignale werden jeweils
an DAUs angelegt und dann als FBAS Signal zusammengeschaltet.

Jetzt stellt sich aber die Frage wie schnell der RAM sein muss. Würde
gerne den 128k x8 mit 70ns Zugriffszeit von Reichelt verwednen weil der
so schön billig ist. aber reicht das? Laut Datenblatt braucht der ATMEL
4 Taktzyklen zum lesen; heißt dass das 4 Taktzyklen mindestens 70ns
lang sein müssen (das wäre dann bei 16MHz kein Problem weil 4 Zyklen
sogar 250ns dauern) oder dass das für EINEN Takzyklus gelten muss (wäre
dann schon ein Problem, weil 62.5µs).

Ich kann auch keinen langsameren ATMEL nehmen, weil pro Pixel 6 Takte
gebraucht werden (4 fürs Lesen, 1 für Portausgabe, 1 um Leseadresse
weiterzuschalten), d.h., ich komme ohnehin schon nur auf
52µs/(6*62.5ns) = 138 Pixel pro Zeile. Das ist eigentlich zu wenig, ich
wollte 200 Pixel pro Zeile. Alternativ könnte man zwar auch einen 20MHz
ATMELl nehmen (käme man immerhin 173 Pixel), aber den 8515 gibts bei
Reichelt nicht als 20MHz Version, außerdem bräuchte man dann einen 50ns
RAM (?) und ein ziemlich schnelles Latch.

Hat einer ne Idee wie man das Ganze schneller bekommen und (wenn
möglich) dabei trotzdem den 16MHz ATMEL verwenden könnte? (z.B. die 6
Takte irgendwie auf 4 drücken)? Reicht nun der 70ns RAM?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kommst du auf die 56% CPU Auslastung ?
Ein TV Bild hat 625 und nicht 575 Zeilen.

Desweiteren ist die Berechnung für die Taktzyklen falsch:
3 Takte zum Lesen aus dem RAM und Adresse erhöhen, 1 Takt zum Ausgeben,
einen um die Adresse zu vergleichen und zwei für den Spring zum
Schleifenanfang, macht also 7 Takte.

Ein kleinwenig kann man den AVR übertakten: 18,432MHz sind eigentlich
immer möglich.

Autor: leo9 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hobbybastler: nimms mir nicht böse, aber ich würde "kleiner"
anfangen.
Dein Konzept klingt zwar recht schlüssig, aber ein paar Stolpersteine
verbergen sich:

1) >>timergesteuert wird alle 64µs ..
beachte dass der Int. während ein, zwei- und dreizyklischen Befehlen
auftreten kann -> Jitter bis zu +125ns (und die sind mehr als deutlich
sichtbar)

2) >>die aber gedoppelt werden  ..
bauchst du nicht extra doppeln, du musst sowieso zwei Halbbilder
generieren. (zu 312 und 313 Zeilen)

3) >>(575-320)/575 = 44% der CPU ..
du musst aber auch in den "nicht Bildzeilen" das Sync-Signal
generieren (64us/4,7us -> ca. 7%Belastung) und dann gibts noch die
Vor-, Haupt- und Nachtrabanten die zusätzliche Belastung darstellen.

4) >>an DAUs angelegt und dann als FBAS Signal zusammengeschaltet ..
du meinst wahrscheinlich DACs? Wie stellst du dir das
"Zusammenschalten" vor? Für Farbe brauchst du einen Farbträger und
modulierte Signale, du wirst um einen speziellen RGB - FBAS Wandler
nicht herumkommen.

5) >>52µs/(6*62.5ns) = 138 Pixel pro Zeile.
die 52us geben die theoretische "Bildbreite" an, in der Praxis wirst
du wohl nur die mittleren ca. 45us am Schirm sehen.

5) Geschwindigkeitsproblem
hast du ja schon selber erkannt: ad.hoc. würde ich einen externen
Zähler zur Adressierung einsetzen und der avr gibt nur noch Takt und
Enable aus (obs aber mit weniger als 6 Takten klappt bin ich mir nicht
sicher).

trotz allem, noch viel Erfolg für das Projekt ! :-)

Güße leo9

Autor: Hobbybastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank erstmal für die schnelle Hilfe!" :-)
Eine Frage bleibt noch: reicht der 70ns RAM nun wenn man den ATMEL mit
16MHz betreiben will oder braucht es dazu den teureren 60er?

Das man ein FBAS Wandler IC braucht weiß ich zwar. Hatte gehofft da was
kleines billiges zu finden dass mir die schon fertigen Chrominanz und
Luminanz – Signale in FBAS umsetzt, so was scheints aber nirgends zu
geben. Werde deswegen wohl wie empfohlen auf RGB ausweichen (hat
immerhin den Vorteil von 256 Farben statt nur 148), hab da aber nur
zwei Chips gefunden: den AD724 der sauteuer ist, und den MC1377, der
zwar nur 2€ kostet aber auf dem Datenblatt ziemlich schwierig zu
beschalten aussieht (braucht man wohl noch mehrere externe
Komponenten). Alternativ könnte man das Videosignal zwar auch als RGB
lassen, das können viele Fernseher aber nicht. Was ist hier ratsam?
Kennt jemand noch andere ICs?

Die Timerungenauigkeit beim Interrupt (danke für den Hinweis; an sowas
hatte ich nun überhaupt nicht gedacht) müsste sich durch Softwaretricks
in den Griff kriegen lassen: Der Interrupt timt erstmal "grob", d.h.
mit 2 Zyklen Ungenauigkeit, liest dann die Timerregister die auf den
Takt genau gehen (?) und führt entsprechend viele Dummybefehle aus die
jeweils einen Takt dauern um das zu kompensieren bevor die Pixelausgabe
beginnt. Müsste man sich noch mal durch den Befehlssatz wühlen (hab bis
jetzt wenig Erfahrung damit), sollte mich aber wundern wenns da keine
Möglichkeit gäbe.

Das Problem dass das alles zu langsam ist bleibt. Hab da zwar ne
Lösung,aber die ist ziemlich unelegant: Anstatt beim Zeilensignal
"Laden und Adresse inkrementieren; Portausgabe" in eine Schleife zu
verpacken wird das Ganze einfach 200 x hintereinandergeschrieben. Das
drückt die Rechenzeit auf 4 Takte pro Pixel und würde folglich genau
reichen für 208 Pixel bei 52µs (bzw. 180 Pixel im sichtbaren 45µs
Bereich), aber eben auch ziemlich viel Flash verschwenden.

Alternativ werd ich die Sache mit dem externen Zähler vielleicht mal
probieren, das bringt ja höchstens 1 Takt (Adressinkrementierung fällt
weg) und die Portausgabe ist trotzdem nötig weil die Datenleitungen
auch gleichzeitig die Adressleitungen sind (hatte nämlich vorher mal
mit dem Gedanken gespielt die Pixelwerte mit den DACs sonst direkt von
den Datenleitungen zwieschen CPU und RAM abzugreifen bzw. vorher in ein
Latch zu schieben). Außerdem wollte ich die Hardwarekosten so gering wie
nur IRGEND MÖGLICH halten, also alles was irgendwie geht über Software
machen und dabei trotzdem noch ein passables Endergebnis erhalten.

>nimms mir nicht böse, aber ich würde "kleiner" anfangen.

Naja, ist wohl was dran: das ist mein erstes µC Projekt und hab auch
vorher überhaupt noch nie was elektronisches gebastelt (nur im Rahmen
des Studiums mal ein paar kleinere Schaltungen entworfen, aber alles
nur graue Theorie und nichts praktisches). Was solls, werd mein Glück
halt einfach mal versuchen ;-)

MfG

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob das RAM reicht, musst du ausprobieren:
Wenn du dem RAM nach anlegen der Adresse lange genug Zeit lässt, dann
reicht sogar ein 200ns RAM...
Falls du aber ein SRAM an den Datenbus eines ATMega8515 hängst, dann
sollte es 55ns oder schnelle haben.
Mit Pseudo DMA kannst du 3 Takte pro Byte erreichen. Schau dir mal in
der Codesammlung meinen LCD Controller für 640x480 an.

Das mit dem Jitter beim Interrupt wird so nichts:
Die Abfrage, ob sich der Timerzählstand verändert hat, dauert auch
mehrere Takte.
Ich hatte dasselbe Problem bei meinem TV Terminal. Am Ende habe ich die
Ausgaberoutine so geschrieben, dass diese auch ohne den HSync Interrupt
genau am Ende der Zeite fertig wäre, so dass ich immer genau zum selben
Takt in den HSync Interrupt gehe.

Kleiner Tipp: Wenn das wirklich dein erstes AVR Projekt ist, versuch
mal was einfaches, wie z.B. das Spiel erstmal auf einem normalen LCD
mit eigenem Controller laufen zu lassen.
All diese kritischen Timinggeschichten sind relativ kompliziert, da man
manchmal um nicht ganz saubere Tricks nicht herumkommt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.