Ein Propeller ist von Uns gegangen.

[DJLinux]

Jetzt ist er doch noch sanft entschwunden macht keinen Mux mehr.

Danke für die schönen Stunden am Steckbrett.
(Endlich mal wieder ein Grund um Bier zu trinken)

[BorgKönig]

Sag' mal, wolltest Du uns da ein IDE Interface zaubern....?

[DJLinux]

Sag' mal, wolltest Du uns da ein IDE Interface zaubern....?

Das war das erste was ich auf dem Steckbrett gemacht hatte fand ich witzig 8GB / 2KB per Cog.
Dann kam DRAM Speicher 256K, 1MB und 4MB ist aber unvernüftig auf dem Prop hat aber funktioniert und darum geht es ja auch beim "Basten".
Zuletzt hatte ich ein SPI Interface für das Siemens S65 Handy Display in Assembler geschrieben. (werde ich noch bei Parallax hoch laden)
Der Prop. kommt aber "nur" auf 12-14 Bilder pro Sekunde da man das ISP Inteface per Software implementieren muss.

Ist erstaunlich wie schnell die Leistung im keller gehen kann

:loop jmp #:loop ' 20 MHz

:loop mach_was ' 10 MHz
djn #:loop

:loop mach_was ' 5 MHz
mach_noch_was
djn #:loop

:loop mach_was ' 2,5 MHz
mach_noch_was
mach_noch_was_mehr
djn #:loop

:loop mach_was ' 1,25 MHz
mach_noch_was
mach_noch_was_mehr
mach_noch_was_besser
djn #:loop

Das wäre die theoretische Bitrate aber ...

Code: Alles auswählen

:cog_data16_loop        shl     value,#1 wc     ' move MSB in C flag
                        muxc    outa,pm_dat     ' send c flag
                        or      outa,pm_clk     ' clock high
                        xor     outa,pm_clk     ' clock Low
                        djnz    nbits,#:cog_data16_loop

Pins sind eine globale HUB Resource und da kommen noch einige verballerte Ticks hinzu.
Möchte garnicht ausrechnen was die reale Geschwindigkeit der Schleife ist.

Warum erzähl ich das? Ach ja ich hab in meiner Trauer Bier getrunken

Grüsse Joshy


Aber SD Karten sind auch prima

[drohne235]

Joshy bekommt kein Bier mehr, wahrscheinlich liest er das aber eh erst nach dem Kaffee...

Code: Alles auswählen

:loop jmp #:loop 		' 20 MHz

:loop mach_was 		' 10 MHz
djn #:loop

:loop mach_was 		' ~6,6 MHz (5 MHz)
mach_noch_was
djn #:loop

:loop mach_was 		' 5 MHz (2,5 MHz)
mach_noch_was
mach_noch_was_mehr
djn #:loop

:loop mach_was 		' 4 MHz (1,25 MHz)
mach_noch_was
mach_noch_was_mehr
mach_noch_was_besser
djn #:loop

Code: Alles auswählen

:cog_data16_loop        	shl     value,#1 wc                    ' move MSB in C flag        4 Takte
                        	muxc  outa,pm_dat                    ' send c flag                  4 Takte 
                        	or      outa,pm_clk     	              ' clock high                   4 Takte
                        	xor     outa,pm_clk     	              ' clock Low                   4 Takte	
                        	djnz    nbits,#:cog_data16_loop                                     4 Takte (in der Schleife)

80 MHz / 20 Takte = 4 MHz

Sag mal, einfach die gleiche Idee wie bei dem Ramzugriff: Man muß ja das Clocksignal nicht unbedingt per Software erzeugen, könnte es nicht funktionieren dafür einen Timer zu verwenden? An einem Pin zu wackeln ist doch genau das wozu so ein Ding da ist. Damit würde man bei 12 Takten/~6,6 MHz ankommen.

Ansonsten kann man noch die Schleife "entrollen", also 16 Bit innerhalb eines Schleifendurchlaufs senden. Damit wären dann 10 MHz Bitrate möglich. Mit zwei synchronen und phasenversetzt arbeitenden Cogs Könnte man das ganze noch auf 20 MHz steigern, aber um das zu programmieren muß man schon ein wenig shizophren sein...

Das ganze könnte so aussehen (ungetestet):

Code: Alles auswählen

:cog_data16_loop	   mov   CTRA, clk_on                 ' timer anschalten
                           shl     value,#1 wc                  ' move MSB in C flag	
                           muxc  outa,pm_dat                 ' send c flag		
                           shl     value,#1 wc                  ' move MSB in C flag	
                           muxc  outa,pm_dat                 ' send c flag		

                  ' insgesamt 16 x die shl/muxc-Sequenz

                           shl     value,#1 wc                  ' move MSB in C flag	
                           muxc  outa,pm_dat                 ' send c flag		
                           mov    CTRA, clk_off               ' timer aus		

                           jmp     #ende

Das ganze "kostet" natürlich statt 2 Longs gleich mal 32 Longs im CogRam, aber dafür wäre es schnell. Mit zwei Cogs könnte man die maximale theoretische Geschwindigkeit des Propellers erreichen.

[DJLinux]

Wemn ich Bier möchte dann krieg ich auch welches sonst rotte ich das Kollektive aus. Flieg nach Saxta 7B und lebe glücklich bis ans Ende meiner Tage

Kannst ja mal am Ozzi oder Frequenzzähler (wenn vorhanden) die reale Geschwindigkeit messen würde mich WIRKLICH SEHR interessieren.

80 MHz / 20 Tackte = 5 MHz

wie wär es denn da mit

80MHz / ( 4 + (3*16) / 2 ) Tackte = ? MHz

4 Tackte Loopcounter 3 nicht zum HUB Counter synchrone Port Zugriffe wo bei grob geschätzt im Mittel 8 Tacke verbraucht werden.

Das mit dem Timer habe ich auch schon länger in meinem Synapsen rum schwirren (sss ssss sssss)
Ich hatte mich aber noch nicht aufgerafft mich mit den Funktionsprinzip der vielen Timermodis auseinander zu setzten.

Ich würde da noch weiter gehen wollen und würde versuchen den Videoshifter die Bits rausshiften lassen.

Das ist jetzt aber noch nur Theorie aber immer noch besser als eine theoretisch theologischen Abschlussprüfung

Bin ich wieder ein Schelm heute ...

Grüsse Joshy

[drohne235]

Das mit dem Timer habe ich auch schon länger in meinem Synapsen rum schwirren (sss ssss sssss)
Ich hatte mich aber noch nicht aufgerafft mich mit den Funktionsprinzip der vielen Timermodis auseinander zu setzten.

Jo, geht mir auch so - da machst du jetzt deinen Propeller kaputt! Irgendwie mußt du dir noch so ein Ding besorgen. Würde mich echt mal interessieren ob das so geht und ob dem Display noch zu ungeahnter Geschwindigkeit verhelfen könnte.

Einen Frequenzzähler hab ich leider nicht, aber ich kann mal schauen ob ich das auf dem Oszi noch vernünftig ablesen kann.

Die IO-Ports und der Systemtimer sind zwar geteilte Ressourcen, aber sie stehen nicht unter der Kontrolle des Hubs. Einzig der 64KByte Adressraum, die Cog-Enables und die Semaphoren werden über den Hub zeitlich geteilt. Wenn man sich das Blockschaltbild anschaut, erkennt man auch das die IO-Pins per Oder-Gatter direkt gekoppelt sind, sie beeinflussen bis auf die Gatterlaufzeit nicht die zeitlichen Zugriffsverhältnisse. Alles andere wäre auch sinnlos und würde das IO-Timing absolut versauen. Solche Sachen wie Bildausgabe mit zwei oder mehr synchronen Cogs, wie es bei einigen Treibern gemacht wird, wären mit instabilem Timing nicht möglich. Das gleiche gilt für den Systemcounter, jede Cog kann den Timerstand in 4 Takten ohne Hubzugriff auslesen.

Für die Ausgabe des Clock-Signals kann man aber nur die beiden intern vorhandenen Timer A und B verwenden, nicht den Systemtimer! Da gibt es also prinzipiell keine Zugriffe über den Hub. So bleibt es also bei einfachen 20 Takten für die Schleife selbst denke ich.

[DJLinux]

Das erste was ich mir über den den Prop. Chip gemerkt hatte war das 2 Cogs ein Port bit NICHT gleichzeitig setzen/löschen kann weil der HUB Scheduler dazwischen hängt.
Als ich dann den ersten Prop. Chip hatte habe ich die FALSCHE Information nie mehr überprüft.

Deine hoffentlich RICHTIGE Info ist ja ein echter Lichtblick für so manche zeitkritische Dinge.
Muss mal so einein VIDEO Treiber wo mehr als ein COG werkelt genau anschauen wie dort die Synchronisation abläuft.

Bin gespannt auf Deine Messwerte von meiner und Deiner Version der 16 bit SPI Schleife.

Ich habe nur ein Ozzi für den DSP Audiobereich da kann ich am Propeller nicht viel mit anfangen.

Grüsse Joshy

[DJLinux]

Hallo Drohne235,
past gerade zum Thema werde ich am Wochende mal mit dem Display ausprobieren.

hast Du mal mit Deinem Ozzi nachgemessen?

Grüsse Joshy

Code: Alles auswählen

{{
  Jonathan "lonesock" Dummer
  Testing a fast SPI clock out routine

  Use both counters in NCO single-ended mode, where the output
  pin is equal to PHSx's high bit.  Use Counter B to drive the
  clock pin, and Counter A to drive the data line.  B actually
  changes the pin automatically, while you update the Data pin
  using a series of SHL's on PHSA (we set FRQA to 0, so no up-
  dates are happening automatically).

  This is for an SPI interface where the data is latched in on
  the rising edge of the Clock line, so you want your Data pin
  to be stable before the clock pin goes high.  You might have
  to sdjust the "movi phsb,#%xxx000000" line to initialize the
  PHSB into the right state for your SPI definition.
}}
CON
  '_clkmode = RCFast
  _clkmode = RCSlow
  pinDataOut = 25   
  pinClock = 24     
  pinChipSelect = 26 

PUB start_test
  ' start out our assembly test framework, then we're done!
  cognew( @fast_SPI_out_test_entry, 0 )
  repeat
    ' do nothing forever (looking at you, Wally!)
  
DAT
ORG 0

fast_SPI_out_test_entry
        ' set up Counter A to be the data counter
        mov frqa,#0             ' unecessary
        mov phsa,#0             ' unecessary
        mov ctra,#pinDataOut    ' set the data pin
        movi ctra,#%0_00100_000 ' set the mode to NCO, single output pin
        ' set up Counter B to be the clock counter
        mov frqb,#0             ' unecessary
        mov phsb,#0             ' unecessary
        mov ctrb,#pinClock      ' set the clock pin
        movi ctrb,#%0_00100_000 ' set the mode to NCO, single output pin
        '     set up my 3 pins as outputs
        mov t,#1                ' temp = 1
        shl t,#pinDataOut       ' temp = 1 << pinDataOut
        mov dira,t              ' DIRA now has the DataOut pin as an output
        mov t,#1                ' temp = 1
        shl t,#pinClock         ' temp = 1 << pinClock
        or dira,t               ' DIRA now has both DataOut and Clock as outputs
        mov maskCS,#1           ' ditto fo the ChipSelect pin, but keep the mask for later
        shl maskCS,#pinChipSelect
        or dira,maskCS          ' DIRA now has all 3 pins set to outputs
        mov outa,maskCS         ' set the Chip Select pin high (usually active low)        

fast_SPI_out_test
        ' what is my data byte?
        mov data,#%10101010     ' randomly selected by myself

        ' here is the super fast unrolled version
        '{
        mov phsa,data           ' start with the raw data byte
        shl phsa,#24            ' get the MSb into position 31
        'rev phsa,#0            ' do this instead of the above line for LSb first
        andn outa,maskCS        ' CS goes low, signifying a start
        movi phsb,#%000000000   ' set up my clock register        
        movi frqb,#%010000000   ' start my clock line ticking!
        shl phsa,#1             ' move next bit into the PHSA[31] slot
        shl phsa,#1             ' move next bit into the PHSA[31] slot
        shl phsa,#1             ' move next bit into the PHSA[31] slot
        shl phsa,#1             ' move next bit into the PHSA[31] slot
        shl phsa,#1             ' move next bit into the PHSA[31] slot
        shl phsa,#1             ' move next bit into the PHSA[31] slot
        shl phsa,#1             ' move next bit into the PHSA[31] slot
        mov frqb,#0             ' stop my clock
        or outa,maskCS          ' CS goes high again
        '}

        ' here is the 2x slower looped version
        '{
        '' NOTE: The 1st one will be primed, so the number
        '' of remaining bits = total-1.  For this 8-bit
        '' test, I have 7 bits remaining to be shifted out.
        mov t,#7                ' number of bits left        
        mov phsa,data           ' start with the raw data byte
        shl phsa,#24            ' get the MSb into position 31
        'rev phsa,#0            ' do this instead of the above line for LSb first
        andn outa,maskCS        ' CS goes low, signifying a start
        movi phsb,#%011000000   ' set up my clock register         
        movi frqb,#%001000000   ' start my clock line ticking!
:bit_shift_loop
        shl phsa,#1             ' move next bit into the PHSA[31] slot
        djnz t,#:bit_shift_loop ' keep going till we run out of bits
        mov frqb,#0             ' stop my clock
        or outa,maskCS          ' CS goes high again
        '}  

        ' wait and repeat
        mov t,#1              ' 511 clocks is a good number for fitting into 9 bits [8^)
        shl t,#9
        add t,cnt               ' add in the current time
        waitcnt t,#511          ' wait for a little while
        jmp #fast_SPI_out_test  ' start our test over again

data    res
t       res
maskCS  res

FIT 496

[drohne235]

Sorry Joshy, werd wohl diese und nächste Woche nicht in den Keller kommen. Bin froh das ich mal ein paar Miniten entbehren kann um das Forum zu checken. Wahrscheinlich hast du es schneller real am Display getestet.

Aber der Code von Jonathan "lonesock" Dummer ist schon cool. Zumindest liegen wir mit unserem Konzept erstmal nicht falsch, wobei er noch einen Schritt weiter geht: Er lässt von einem Timer den Clock erzeugen und benutzt den zweiten Timer um am Datenpin zu wackeln! Das spart doch glatt nochmal 4 Takte und damit ist man dann auf 40 MHz, das heißt man schiebt die Daten echt mit der maximalen Geschwindigkeit raus. Also ich finde das echt genial muß ich sagen. Ruck zuck hat man eine Routine langsam, aber genau so schnell hat man sie wieder mit dem geschickten ausnutzen der Ressourcen beschleunigt.

Mit dieser Methode kann man auch prima an zwei Signalen der RAM's oder am Bus wackeln ohne Zeit zu verschwenden - echt genial die Idee!

Hast du die Routine von lonesock schonmal mit deinem Display getestet?

[scotty]

Also bei dem, was Ihr hier ausbrütet, solltet Ihr das nicht in "Unimatrix Vinculum" weiterführen. Das ist nicht mehr Off-Topic und entgeht so vielleicht den Technik-Interessierten. Wäre doch schade!