PAL mit ATtiny?

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.

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.

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.

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

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.

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?

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.

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.