HIVE-Project

Moin moin!
Soeben hab ich die Dateitransferrate (Download mp3-Datei vom WebProp) mit der Systemüberwachung überprüft. Gemessen wurde um 20KiB/s, Opera zeigt mir 16,3 KB/s sowohl für fsrw2.6 als auch FATEngine 2.0 an.
Gruß
TuxFan

bau mal bitte eine prüfroutine ein, die checkt, ob alle bytes aus dem buffer übertragen hat. falls ja, "flush", neu füllen senden und wieder von vorn... ggf. auch http stream verwenden, falls die props genug power dafür haben...

Da binn ich ja mit 30kByt schon ganz schön schnell oder?

Eigendlich sollte so was von 230kByte wie bei meinem PIC's herauskommen.
Ich vermute mal das das spin einfach zu langsam ist.
Kann jemand mesen mit wieviel speed der ENC vom prop gespeist wird.
"SPI Interface with clock speeds up to 20 MHz"

Ich glaube das ich irgendwo über eine "SPI/10" gestolpert binn.

PIC18F2550 hat geschrieben:Ich glaube das ich irgendwo über eine "SPI/10" gestolpert binn.

PropTCP schreibt mit 20MHz-SPI-Takt auf den ENC28J60 und liest mit 10MHz-SPI-Takt von Diesem. Der ENC28J60 könnte wohl in beiden Richtungen 20MHz, aber die 10MHz liegen an den doppelt sovielen Befehlen in der Leseschleife...

Aber ob das nun genau die identische Version ist die in TriOS verwendet wird, schüttle ich gerade nicht aus'm Ärmel...

Zeile 522ff in proptcp-5.0-7beta/driver_enc28j60.spin:

Code: Alles auswählen

spi_out_      andn      outa, clkpin
              shl       arg0, #24              
              mov       phsb, arg0              ' data to write
              mov       frqa, freqw             ' 20MHz write frequency
              mov       phsa, #0                ' start at clocking at 0
              
              mov       ctra, ctramode          ' send data @ 20MHz
              rol       phsb, #1
              rol       phsb, #1
              rol       phsb, #1
              rol       phsb, #1
              rol       phsb, #1
              rol       phsb, #1
              rol       phsb, #1
              mov       ctra, #0                ' disable
              andn      outa, clkpin
                       
spi_out__ret  ret


spi_in_       andn      outa, clkpin
              mov       phsa, phsr              ' start phs for clock
              mov       frqa, freqr             ' 10MHz read frequency
              nop

              mov       ctra, ctramode          ' start clocking
              test      dipin, ina wc
              rcl       arg0, #1
              test      dipin, ina wc
              rcl       arg0, #1
              test      dipin, ina wc
              rcl       arg0, #1
              test      dipin, ina wc
              rcl       arg0, #1
              test      dipin, ina wc
              rcl       arg0, #1
              test      dipin, ina wc
              rcl       arg0, #1
              test      dipin, ina wc
              rcl       arg0, #1
              test      dipin, ina wc
              mov       ctra, #0                ' stop clocking
              rcl       arg0, #1
              andn      outa, clkpin
                            
spi_in__ret   ret

----------8<----------
Offtopic PS: Wer Ideeën hat wie die SPI-Routinen für 100MHz Propellertakt zu optimieren sind, gebe bitte in einem dafür neu gestarteten Thread Laut.

Das muss ich erst einmal verdauen.

Für mich stellt sich jetzt die Frage woher kommt der geschwindigkeitszuwachs.
Weder an TCIP noch SD-FAT wurde geändert.

hast du ein anderes kabel genommen, oder den buffer der nic geflusht...?

@PIC182550 : Diese kurzen Peeks halte ich nicht für allzu Aussagekräftig. Die sicherste Methode zur Beurteilung ist ein konstanter Download. Bei kurzen Peeks kann es durchaus Beurteilungs-Fehler für die Übertragungsgeschwindigkeit kommen.
@Yeti : Wenn ich das denn alles richtig verstanden habe, wird bei den verwendeten o.a. SPI-Assembler Routinen die Steuerung durch die Timer übernommen. Dummerweise geht es dabei nicht schneller als Clockfreq/(4Takte pro übertragenem Bit) (80MHz/4 = 20MHz = 20Mio Bit/s). Dh. bei 100MHz gibt es 25MHz, so es denn der Slave verträgt. Mußte mich wg. GBP mit diesen Routinen auseinandersetzen.

Was meines Erachtens die Gesamtübertragung deutlich beeinflußt sind die Routinen/Methoden die in SPIN geschrieben sind. Ein konsequenter Ersatz der SPIN-Programme durch PASM ist die einzigste Möglichkeit die Geschwindigkei zu erhöhen. Die ganze Interpretergeschichte für SPIN fällt dann weg. Deswegen war ich als Hochsprachenverwöhnter ja mal so hinter Beans Propbasic her, da hier ein Resultat in Assembler in den Prop geladen wird.
Gruß
TuxFan

Die Auflösung beträgt 0,25s und war vorher eine durchgezogene Linie(siehe oben)
Die Spitzen sind vom ENC die Lücken von der SD-Karte diese scheint die datenmenge nicht mehr zu schaffen.
Ich werdem mal den leeren puffer einfach senden ohne das bild in 512Byts stückchen zu laden.
Rein Theoretisch müssten dan die Pulse enger aneinanderliegen.
Da die Linie nur ein mittelwert ist könnte es sein das die packete noch etwas schneller sind.

Kann jemand das verhalten des ENC's bei verwendung von Cross over/Patch kabel bzw mit und ohne zwischengeschaltetem switch testen?
Das ist nähmich der einzige unterschied zwichen den versuchen gestern und vom Wochenende.(bin außerhalb unterwegs)

Bisher lief der Server direkt am Netbook mit 50cm Kabel und Crossover-Zwischenstecker. Wobei ich immer WLAN neben Ethernet auf dem Netbook laufen hatte. Jetzt hab ich den Server mal ins hausinterne Netz über den Switch angeschlossen. Die Übertragungsgeschwindigkeit (20KiB/s) einer mp3-Datei (2,7MB) ist geblieben.
Gruß
TuxFan

HIVE-Project

mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)

Re: mini WEB-Server (alt mini FTP)