HIVE-Project

Moin,

ich hatte mir gestern ein bisschen die Doku vom Propeller angeschaut.

Also wenn:

PLLA/FrameClocks = PLLA/PixelClocks
Und Source immer mit 0 geladen wird

So könnte mit hilfe von 16 farben ausgeben.

Die einzige frage die da noch austeht ist das Timing und die Anpassung auf Longformat mit Pixel rotieren.
= 8 Pixel pro long

Der Code wird zu lang so geht das nicht.
Die Ausgaben müssen mit zwei Befehlen pro Pixel auskommen.
Das ist mit waitvid nicht machbar.
Die Anderen signale sollten normal mit der Videosteuerung erzeugt werden.

Mal in ruhe darüber köcheln.

blub blub ....

Für die Ausgabe kommen 3 COGs zur Anwendung.

Der 1. ist zur Erzeugung des Videorahmen zuständig. ( eventuell geht das Auch ohne Pins zu blockieren)
Der 2. und 3. wechseln sich ab mit der Ausgabe (eventuell reicht auch einer)

blub blub ...

Vollkommen neues Konzept!

1. Prob 1. COG : Hier werden nur die Videosignale H und V erzeugt keine farben. 2 Pin
1. Prob 2. COG : Syncrones Videotiming nur das hier die farbe ROT_1 ausgegeben wird. (10K) 1 Pin
1. Prob 3. COG : Syncrones Videotiming nur das hier die farbe GRÜN_1 ausgegeben wird. (10K) 1 Pin
1. Prob 4. COG : Syncrones Videotiming nur das hier die farbe BLAU_1 ausgegeben wird. (10K) 1 pin

Der 2. Prob benutzt den gleichen Quarzoszilator den der 1. Prop verwendet.
Die props werden über ein pin bei Startfreigabe Syncronisiert

2. Prob 1. COG : Syncrones Videotiming nur das hier die farbe ROT_2 ausgegeben wird. (10K) 1 Pin
2. Prob 2. COG : Syncrones Videotiming nur das hier die farbe GRÜN_2 ausgegeben wird. (10K) 1 Pin
2. Prob 3. COG : Syncrones Videotiming nur das hier die farbe BLAU_2 ausgegeben wird. (10K) 1 pin

Syncrones Videotiming wird erreicht in dem die Farb-COGs nicht das waitvid verwenden sondern waitpnq und mit zwei Pinns das H und V Signal überwachen.
Damit ist die Ausgabe an den COG-Takt gebunden das muss beim Videotiming berücksichtigt werden.
das heist die frequenz des Quarzes sollte 4x so hoch sein wie die des Pixeltaktes.

Bei einer Auflösung von 320x 256 ständen 64 farben pro Pixel zur verfügung.
Ein Weiterer Prop würde das auf 512 Farben erweitern.

Mehrere propeller Syncron mit interner PLL ? ..... denkste ist nicht.
Die können bis zu 15 Tacktperrioden daneben liegen oder noch Phasenverschoben sein.

Also einen externen Quarzoszi mit 80Mhz. Ok den gibt es aber nur mit 5V Streitaxt.

Den Takt werde ich über ein 5V tollerantes Gatter ziehen und damit den Prop bedienen.
Spannungsteiler kommen wegen der Eigeninduktivität der Wiederstände nicht in Frage. ODER doch in SMD? (2x1k sollten da auch reichen.)

PIC18F2550 hat geschrieben:Mehrere propeller Syncron mit interner PLL ? ..... denkste ist nicht.
Die können bis zu 15 Tacktperrioden daneben liegen oder noch Phasenverschoben sein.

Also einen externen Quarzoszi mit 80Mhz. Ok den gibt es aber nur mit 5V Streitaxt.

Selbst damit steht Dir noch die RCSLOW/RCFAST boot sequence im Weg. Mit anderen Worten, synchronisieren musst Du so oder so.

Jo weis ich desshalb auch die synchronisation über ein Koppelpinn (vom Boot-COG gesteuert)
Das Rücklesen erfolgt durch die Video-COGs in den Propeller. Dieser wartet mit der Initalisierung bis das Koppelpin seinen Pegel H/L wechselt.
Damit wird ein taktsynchrones Startsignal an alle Videoprozesse gesendet deren Abweichung damit gegen 0 geht da die PLL des Video generators eingerastet ist.