Kennt jemand einen PAL Video Generator mit Atmel AVR tinyx5?
Info schrieb: > Kennt jemand einen PAL Video Generator mit Atmel AVR tinyx5? Was soll der denn generieren, ein Testbild oder Video? Georg
Georg schrieb: > Info schrieb: >> Kennt jemand einen PAL Video Generator mit Atmel AVR tinyx5? > > Was soll der denn generieren, ein Testbild oder Video? DVD-Player -> ATTiny -> PAL-Signal.
Info schrieb: > DVD-Player -> ATTiny -> PAL-Signal. Was ist das für ein Ausgang am DVD-Player? Egal, was es ist: Vergiss es.
Womöglich kommt da HDMI raus. Ich denke das wäre der typische Fall für einen FPGA. Mit nem Tiny ziemlich unmöglich. In einer Elektorausgabe wurde mit einem ATMega das Spiel "PONG" realisiert, mit popeligem BAS Ausgang. Dabei war der mega an seiner Grenze. Die Bilderzeugung ließ nur noch sehr wenig Raum für das Spielgeschehen. Es ging, aber knapp. Wenn man das so bedenkt... gruß cyblord
Es gibt (fast) alles in diesem Forum: Beitrag "ATMega32 16 MHz PAL mit Farbe ohne externen Chip" http://www.mikrocontroller.net/articles/PAL_Testbildgenerator Ist zwar kein Tiny aber immerhin ein Anfang.
be stucki schrieb: > Es gibt (fast) alles in diesem Forum: > Beitrag "ATMega32 16 MHz PAL mit Farbe ohne externen Chip" > http://www.mikrocontroller.net/articles/PAL_Testbildgenerator > > Ist zwar kein Tiny aber immerhin ein Anfang. das ist ein simpler Testbildgenerator - mehr nicht. Der TO will aber Videos, die von einem DVD-Player kommen, in Echtzeit nach PAL konvertieren. Das ist eine ganz andere Hausnummer. Soll er einfach den SCART-Ausgang vom DVD-Player nehmen, irgendeinen ATTiny mit einem Stückchen Garn um das Kabel wickeln und fertig ist die Laube.
Info schrieb: > DVD-Player -> ATTiny -> PAL-Signal. Das habe nicht ich geschrieben, es macht auch überhaupt keinen Sinn. PAL = Video, es reicht aber ein stets wiederholter Frame = Standbild = Testbild. Es reicht auch ein monochromes Bild (Streifen, Schachbrett). Ja, es gibt zahlreiche Lösungen mit ATmega, aber für die 8-pin Tiny habe ich noch nichts gesehen. Die habe ich parat. Ich brauche das ganze 4x um einen Framegrabber zu testen.
http://homepages.ihug.com.au/~daz2002/tech/TP/index.html Mit den großen Tinys (tiny?61) könnte das schon gehen.
Info schrieb: > Ja, es gibt zahlreiche Lösungen mit ATmega, aber für die 8-pin Tiny habe > ich noch nichts gesehen. Der Unterschied ist doch minimal. Entweder wird tatsächlich vollständig Bitbanging gemacht, dann kannst du den ATMega-Code 1:1 auch auf einem Tiny verwenden. Oder es wird irgendeines der vorhandenen Schieberegister (vorzugsweise SPI) benutzt. Solange es Hardware-SPI ist (und nicht USART im SPI-Mode), kann das Programm auch relativ leicht angepaßt werden, bei einem Tiny nimmt man einfach Timer0 und USI, um das SPI-Zeugs sinngemäß zu ersetzen. Nur wenn USART im SPI-Mode genutzt wird, ist die Sache nicht relativ leicht auf alle Tiny anpassbar, jedenfalls nicht ohne Einschränkungen bezüglich der darstellbaren Bildinhalte gegenüber der ursprünglichen Lösung. Denn das Feature, mit konstanter Bitrate kontinuierlich Ausgaben tätigen zu können, hat eben nur USART im SPI-Mode und das gibt's, soweit ich weiß, nur im 2313A und im 4313, aber in keinem 8-Beiner. Allerdings wird dieses spezielle Feature i.A. für Vollgrafik verwendet, was beim Tiny ja mangels genug Speicher für den Bildwiederholspeicher sowieso unmöglich wäre.
Ein monochromes Schachbrett-Testbild kannst du sicher mit jedem ATTiny/PIC12 hinbekommen.
cyblord ---- schrieb: > In einer Elektorausgabe wurde mit einem ATMega das Spiel "PONG" > realisiert, mit popeligem BAS Ausgang. Dabei war der mega an seiner > Grenze. Die Bilderzeugung ließ nur noch sehr wenig Raum für das > Spielgeschehen. Es ging, aber knapp. Wenn man das so bedenkt... Es gibt ein anderes Projekt, da läuft BoulderDash auf einem Mega644 mit Vollfarbgrafik und Sound. Deine Aussage ist so nicht haltbar. http://bdash.gpio.dk/
Knut Ballhause schrieb: > Es gibt ein anderes Projekt, da läuft BoulderDash auf einem Mega644 mit > Vollfarbgrafik und Sound. Deine Aussage ist so nicht haltbar. > > http://bdash.gpio.dk/ Das ist aber VGA und nicht PAL. BAS und VGA sind vergleichsweise einfach. Die Herausforderung ist die Generierung des Farbsignals bei FBAS/PAL. Hier gibt es ein PAL-Beispiel, das nicht nur ein Testbild ist: http://www.linusakesson.net/scene/phasor/index.php
Knut Ballhause schrieb: > cyblord ---- schrieb: >> In einer Elektorausgabe wurde mit einem ATMega das Spiel "PONG" >> realisiert, mit popeligem BAS Ausgang. Dabei war der mega an seiner >> Grenze. Die Bilderzeugung ließ nur noch sehr wenig Raum für das >> Spielgeschehen. Es ging, aber knapp. Wenn man das so bedenkt... > > Es gibt ein anderes Projekt, da läuft BoulderDash auf einem Mega644 mit > Vollfarbgrafik und Sound. Deine Aussage ist so nicht haltbar. Das war nicht meine Aussage, sondern die des Autors des Elektor Artikels. Außerdem hatten die einen mega8 oder etwas von der Güte. Ist natürlich ein paar Jahre her. Und da es hier immer noch um einen Tiny geht, ist die Aussage sehr wohl haltbar. Ob das mit einem mega644 geht oder mit einem stm32 spielt ja keine Rolle. Die Leistung des angepeilten Controllers liegt in jedem Fall unter einem ATmega.
:
Bearbeitet durch User
info schrieb: > Hier gibt es ein PAL-Beispiel, das nicht nur ein Testbild ist: > http://www.linusakesson.net/scene/phasor/index.php Ja, das ist aber kein normgerechtes Farbsignal und braucht eine schwierig zu kriegende Taktfrequenz. Echtes PAL ist aber natürlich mit der 4-fachen Taktfrequenz auch möglich, sogar mit relativ wenig Programmcode. Man verwendet einfach 4 Register pro "Pixel" und macht einfach wiederholende Sequenzen aus 4 OUT-Befehlen. Damit kann man 8 Pixel am Stück in beliebiger Farbe erzeugen. Dazwischen hat man halt keine Farbe.
Christian Berger schrieb: > info schrieb: >> Hier gibt es ein PAL-Beispiel, das nicht nur ein Testbild ist: >> http://www.linusakesson.net/scene/phasor/index.php > > Ja, das ist aber kein normgerechtes Farbsignal und braucht eine > schwierig zu kriegende Taktfrequenz. Echtes PAL ist aber natürlich mit Tja, dann musst Du jetzt wohl beweisen, dass es auch besser geht. Walk the Talk usw. Phasor ist immer noch der beste PAL-Hack, den ich kenne. > der 4-fachen Taktfrequenz auch möglich, sogar mit relativ wenig > Programmcode. Man verwendet einfach 4 Register pro "Pixel" und macht > einfach wiederholende Sequenzen aus 4 OUT-Befehlen. Damit kann man 8 > Pixel am Stück in beliebiger Farbe erzeugen. Dazwischen hat man halt > keine Farbe. Das ist aber nicht "relativ wenig code", da deine Schleife komplett ausgerollt ist. Außerdem ist der Ansatz ziemlich unflexibel, wie Du ja selbst feststellst.
Info schrieb: > Christian Berger schrieb: >> info schrieb: >>> Hier gibt es ein PAL-Beispiel, das nicht nur ein Testbild ist: >>> http://www.linusakesson.net/scene/phasor/index.php >> >> Ja, das ist aber kein normgerechtes Farbsignal und braucht eine Das ist übrigens ziemlicher Unsinn. Die PAL-Norm schreibt nicht vor, dass zwei aufeinanderfolgende Zeilen die gleichen Y/C-Werte haben müssen. Es gibt nur "nicht normgerechte" Empfänger, die sich die Mittelund der Signale sparen.
Info schrieb: > braucht eine >> schwierig zu kriegende Taktfrequenz. Auch das ist Unsinn. 4x PAL Farbcarrier ist eine absoluter Standardquarz und fast überall zu bekommen.
cyblord ---- schrieb: > Ob das mit einem mega644 geht > oder mit einem stm32 spielt ja keine Rolle. Die Leistung des angepeilten > Controllers liegt in jedem Fall unter einem ATmega. Falsch. Solange man keine Multiplikationsbefehle benutzt, ist ein Tiny bei gleichem Takt exakt genauso schnell wie ein Mega. Und bei einem Framegenerator sehe ich keinerlei Veranlassung, mul* zu verwenden. Bezüglich des BoulderDash: das läuft auf einem Tiny trotz prinzipiell gleicher Rechenleistung deshalb nicht, weil der nicht genug RAM und Flash hat. Für die Generierung eines konstanten Testbilds spielt das aber keine Rolle.
c-hater schrieb: > cyblord ---- schrieb: > >> Ob das mit einem mega644 geht >> oder mit einem stm32 spielt ja keine Rolle. Die Leistung des angepeilten >> Controllers liegt in jedem Fall unter einem ATmega. > Bezüglich des BoulderDash: das läuft auf einem Tiny trotz prinzipiell > gleicher Rechenleistung deshalb nicht, weil der nicht genug RAM und > Flash hat. Aha, merkst jetzt den Unterschied zwischen mega und tiny?
cyblord ---- schrieb: > Aha, merkst jetzt den Unterschied zwischen mega und tiny? Und du lernst ganz neu den Unterschied zwischen der (Rechen-)leistung eines Computers und seiner Speicherkapazität? Vor allem, daß diese beiden Aspekte fast nie in einer direkten Abhängigkeit zueinander stehen?
c-hater schrieb: > cyblord ---- schrieb: > >> Aha, merkst jetzt den Unterschied zwischen mega und tiny? > > Und du lernst ganz neu den Unterschied zwischen der (Rechen-)leistung > eines Computers und seiner Speicherkapazität? leistung != rechenleistung > Vor allem, daß diese beiden Aspekte fast nie in einer direkten > Abhängigkeit zueinander stehen? wo hab ich das behauptet?
cyblord ---- schrieb: > leistung != rechenleistung Schöne Ungleichung. Könnte ich mathematisch durchaus akzeptieren. Allerdings: Das werde ich erst dann tun, wenn du eine zumindest nachvollziehbare Definition für die "Leistung" eines µC liefern kannst, die sich deutlich von dem Zusammenhang ClockFrequency*AvgInstructionsPerClockCycle unterscheidet und da irgendwie die verfügbare Speicherkapazität mit einbringt... Hint: Du kämpfst da gerade auf ziemlich verlorenem Posten. Hier geht es nicht um dümmliches Marketing-Gesülze, sondern um berechenbare Fakten. Das Gesülze überlassen wir wohl lieber den Marketing-Strategen und ihren Zielen, den geistig unterbelichteten BWLern.
Auf ein so ein Kluggescheiße hab ich grad echt keine Lust. Es sollte klar sein was ich meinte. Die Leistung nur an der Rechenleistung zu messen ist doch Unfug. Ich würde hier sogar noch die Peripherie einbringen. Anzahl der Timer usw. sind ebenfalls entscheidend wenn es darum geht, zu entscheiden ob eine Anwendung realisiert werden kann oder nicht. Wers nicht verstehen will oder unbedingt stänkern muss, der solls tun.
:
Bearbeitet durch User
cyblord ---- schrieb: > Inwiefern? Wo ist dein PAL-Umsetzer-Programm auf einem ATTiny? Oder auch > nur ein solches für (F)BAS. Es war garkein "Umsetzer" gefordert, sondern nur ein Testbild-Generator. > Ich sage nur, das geht auf nem Tiny eben > nicht. Na klar geht das. Für CCIR-RGB und für VGA-RGB ohne Probleme. PAL- oder NTSC-Composite hingegen überfordern einen AVR, weil es hier auch darum geht, eine Farbträger zu modulieren, der bei ungefähr einem Viertel der maximalen Taktfrequenz der Teile liegt. Das geht nur, indem man die Muster zur Entwurfszeit komplett vorberechnet. Der Controller arbeitet also zur Laufzeit dann nicht mehr als µC, sondern nur noch als reiner ROM-Speicher-Chip. Sprich: Er läßt sich sehr viel billiger durch einen einfachen ROM-Speicher-Chip ersetzen, z.B. durch einen Flash-ROM entsprechender Kapazität. > Bei nem großen Mega oder noch größer siehts anders aus Nein, genau das ist eben nicht der Fall. Bei CCIRoder VGA ist ein Tiny zur Testbildgenerierung exakt gleich gut geeignet wie ein Mega und bei PAL/NTSC exakt gleich schlecht wie ein Mega. Der Unterschied besteht nicht in der "Leistung", sondern in der Speicherkapazität. Allein die größere Flash-Speicherkapazität der Megas erlaubt auch diese Anwendung, nicht ihre (abgesehen von mul* einfach mal nicht vorhandene) größere Leistung.
cyblord und c-hater - zwei Titanen der gepflegten Diskussionskultur im Internet. Bitte beendet diese aufregende Diskussion. Hier wird nicht einfach ausgestiegen!
Hier mal wieder der echte TO. In http://www.mikrocontroller.net/articles/TV-out#Farbe "per Software" wird ein ASM Projekt mit AT90s2313 erwähnt, dass sich evtl. auf einen 8-Beiner tiny portieren ließe (ich kann es nicht): http://www.serasidis.gr/circuits/colour_bar_gen/colour_bar_gen.htm Könnte man sogar ohne 17.7 MHz "Spezialquarz" auskommen und die interne PLL mit einem Standardquarz tunen?
cyblord ---- schrieb: > Auf ein so ein Kluggescheiße hab ich grad echt keine Lust. Dann tue allen einen Gefallen und halte dich einfach raus.
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.