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?
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.
@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
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.