IO funktion

[PIC18F2550]

Hallo,

ich habe mal eine Frage zum timing der COGs zueinander.
Ich habe einen Trggereingang für 3 GOGs.
Die 3 GOGs sollen Syncron Daten Seriel ausgeben.
Ich habe denVerdacht das die GOGs eventuell Phasenverschoben arbeiten Könnten.
Weis da jemand eventuell mehr?

[yeti]

Ich habe denVerdacht das die GOGs eventuell Phasenverschoben arbeiten Könnten.

Jo!
Genau so ist das!
Beziehungsweise sind sie dann vielleicht nur zufällig phasensynchron.

Ein PASM-Befehl braucht 4+n Ticks und wenn alle Cogs in einer Schleife aus mehreren Befehlen das Selbe tun sollen, dauert ein Zyklus der Schleife noch länger. Die Cogs wurden nicht wirklich gleichzeitig gestartet, also ist es zufällig, ob die Verzögerung des Startens zwischen 2 Cogs zufällig auf dies Raster fällt. Mehrheitlich werden dieselben Schleifendurchläufe in den Cogs also nicht zufällig in Phase laufen.

Ich versuch mal was zu finden, was in diese Richtung geht...

***ein_paar_Minuten_Fahrstuhlmusik***

Code: Alles auswählen

$ ~/wrk/propeller/gear/gear-20140703/Gear.exe
bash: /home/yeti/wrk/propeller/gear/gear-20140703/Gear.exe: Kann die Binärdatei nicht ausführen: Fehler im Format der Programmdatei

WHAT DA FUUUUUUUUU.........???

Ich muß da ersmaa was reparierifizieren...

Binfmt_Misc is wohl dorschenanner... mit explizit vorangestelltem "mono" rennt "GEAR.EXE" noch... das reicht erstmal...

AAAaaalsooo...

Gibt man allen Cogs das Selbe zu tun und startet sie nacheinander, dann sind ihre Aktionen vielleicht Phasenverschoben oder nur zufällig synchron:

Code: Alles auswählen

$ cat toggler.spin 
PUB run(pin)
  DIRA[pin]:=1

  repeat
    OUTA[pin]^=1
$ cat toggle7.spin 
CON
  _clkmode = xtal1 + pll16x
  _clkfreq = 80_000_000

OBJ
  blink[7]:"toggler.cog"

PUB demo | id,i

  repeat i from 1 to 7
    id:=blink[i].__cognew
    blink[i].run(i)
$ make
/opt/spin2cpp/bin/fastspin -q -O -w toggler.spin
/opt/spin2cpp/bin/fastspin -q -O toggle7.spin

Wusel ich z.B. ein "waitcnt" da rein, damit zwischen Cogstart der Pin-Wink-Schleife erstmal auf den nächsten Wert, bei dem die unteren 16-Bit alle 1 sind gewartet wird...

Code: Alles auswählen

$ cat toggler.spin 
PUB run(pin)
  DIRA[pin]:=1

  waitcnt($FFFF|cnt)

  repeat
    OUTA[pin]^=1

...dann winken die Pins hybsh in Phase:

War's das, was Du meintest oder suchtest?

[PIC18F2550]

Ja das ist das Was ich meine.
Die frage ist bei Gear nur ob er sich an die Hartware hält.

[yeti]

Ja das ist das Was ich meine.
Die frage ist bei Gear nur ob er sich an die Hartware hält.

Dann spiel das entweder mit einem Logic-Analyser durch oder hau XORs mit R/S-Flipflops und LEDs auf die Pins... ...die dann ja nur leuchten sollten, wenn die LEDs mindestens Einmal nach Flipflop-Reset nicht in Phase waren...

...aber GEAR wurde gebaut, um sich an das Verhalten der Hardware zu halten. Ich bin optimistisch, daß das für ein so einfaches Beispiel auch gut genug geklappt hat.

Bei hinreichend überzeugenden Bestechungsversuchen grab ich meinen Logik-Analüser und einen Echt-Propeller aus! Laß Dir was Einfallen... ich bin nich billich...

[PIC18F2550]

yeti ich will dir glauben da du da wesentlich weiter in der Materie steckst.

Aber was hab ich vor.
Seit längeren quählt mich der KC85/4 mit fehlenden VGA Port.

Das RGB signal will ich über 3 8bit Schieberegister einlesen. (SR um den 7Mhz Pixeltakt aus dem Weg zu gehen)
Die Ausgabe erfolgt über 3 GOGs (pro farbkanal einer) ein 4. erzeugt den Rahmen und liefert den Syncimpuls am IO Pin.
Es müssen 10 Longwerte für eine Zeile ausgegeben werde.

[yeti]

yeti ich will dir glauben da du da wesentlich weiter in der Materie steckst.

Optimist!
Ich bastel viel weniger als Du... also so echt mit Lötbräter in der Hand... aber lese vielleicht stattdessen ein bissl mehr... bin halt eher der Theoretiker im Elfenbeinturm...

Aber was hab ich vor.
Seit längeren quählt mich der KC85/4 mit fehlenden VGA Port.

Das RGB signal will ich über 3 8bit Schieberegister einlesen. (SR um den 7Mhz Pixeltakt aus dem Weg zu gehen)
Die Ausgabe erfolgt über 3 GOGs (pro farbkanal einer) ein 4. erzeugt den Rahmen und liefert den Syncimpuls am IO Pin.
Es müssen 10 Longwerte für eine Zeile ausgegeben werde.

Dann hast Du ja eine Synchronisationsquelle für die Cogs mit sowas wie "waitpeq" oder dessen Verwandtschaft...

Dein Projekt erinnert mich an eine Frage, die mich schon länger zwickt: VGA (Text oder Bitmap) mit einem Propeller pro Farbebene... aber das bequaken wir später mal...

[PIC18F2550]

Du hast das thema ziemlich gut getroffen.

[yeti]

Du hast das thema ziemlich gut getroffen.

Echt?
Dann sind Theoretiker ja vielleicht doch manchmal nützlich?

[PIC18F2550]

bei 320x256 pixel breuchte mann nur 30.72kb und hätte 8 farben.

[yeti]

bei 320x256 pixel breuchte mann nur 30.72kb und hätte 8 farben.

Als 1024x768 signalisiert? Das würd auch jeder Alt-VGA-Moni dann fressen... denk' ich jedenfalls...

Code: Alles auswählen

$ dc <<< '320 3 * p 256 3 * p'
960
768

...horizontal etwas schieben/füllen ist kein Problem, vertikal wär's perfekt ausgenutzt bei Verdreifachung.