IDE- / Sata ?

[DJLinux]

...Mit dem Propeller MP3's Softwaremäßig zu decodieren halte ich für ausgeschlossen .. viel zu wenig Power...

Wie kommst Du denn darauf?

Da ich in meiner Soundlib mit "nur" 32 Bit Integer Mathe die MP3 Streams decodiere
(also nix mit langsamen Floatingpoints) sollte das auf dem Prop in Assembler sehr wohl gehen.
Wie immer beim Prop ist der schnelle COG Speicher für die Filterbänke zu klein.

Was hat denn der HiVe für eine Datenrate beim lesen von dem externen Speicher?

Grüsse Joshy

[Janaha]

Hm, die extrene RAM geschwindigkeit müsste ungefähr wie folgt aussehen.

Soweit ich das verfolgen konnte kann der Propeller die IO's bei maximaler COG nutzung mit maximal 80MHz abfragen/ schalten. Diese Info habe ich aus einem Logiganalyser Projekt entnommen in dem ein Propeller mit maximal 80Mhz seine IO-Ports ausliesst um Logigpegel mitzuloggen und zu verarbeiten. Ich gehe daher davon aus, das der Propeller schnell genug ist um das RAM mit der vom RAM her vorgegebenen maximalen geschwindigkeit nutzen zu können.

Das verbaute Ram ist wohl ein 55ns Typ, der maximal mit 18,1 MHz abgefragt werden kann. Alle 2048 Byte muss man das Latch nutzen um die oberen Addressleitungen neu zu setzen. Das Latch selbst hat bei 4,5 Volt ein "propagation delay" von ungefähr 30ns, da das Latch aber wohl warscheinlich nur mit 3,3 Volt läuft steigt der delay auf max. 88ns, dies konnte ich dem Schaltplan nicht entnehmen. Nun haben wir aber 2 RAM's die praktischerweise auf dem gleichen Buss liegen. Damit können wir die RAM's ganz einfach im wechsel abfragen.

Daraus ergibt sich für die erste Abfrage eine verzögerung von 55ns. Für den zugriff auf das 2. RAM braucht das 2. RAM dann 25ns um auch auf ausgabe zu schalten. Das erste Ram muss aber vorher abgeschaltet werden, wofür es maximal 20ns braucht. Damit lassen sich 16bit lassen also mit einer maximalen Verzögerung von 90ns auslesen. Danach muss allerdings wieder die Datenausgabe auf das 1. Ram zurück geschlatet werden, wofür wieder 20ns gebraucht werden. Damit wäre die möglichkeit beide Rams bei 110ns verzögerung für 16bit im wechsel zu betreiber nicht wirklich schneller als wenn man nur 1 Ram nutzt. Bringen tut dieser wechselweise Zugriff erst dann was, wenn man das Latch schalten muss. Dies würde bei wechselweisem Zugriff auf beide RAM's ja erst bei 4KB und nicht schon bei 2KB gemacht werden müssen. Mit seinen maximal 88ns Umschaltverzögerung kostet so ein Bankswitching damit fast einen vollen 16bit Zugriffscykluss auf beide RAM's. Ich würde nicht auf die einhaltung der Umschaltzeiten der beiden Ram's verzichten, da evtl. etwas kaputt gehen könnte wenn beide RAM's gleichzeitig auf Ausgabe stehen.

Die Datentransverrate vom RAM zum Propeller dürfte bei ungefähr 17,2 MB pro Sekunde liegen. Egal, ob wie oben beschrieben zwischen beiden RAM's ständig geswitcht wird oder nicht.

Vorraussetzung wäre hierfür aber eine ganz speziel angepasste Assemblerroutine und der extklusive BUSS- zugriff durch den Propeller. Hiervon müsste man die Übertragungsdauer zwischen den 3 Cogs' ggf. wieder abziehen. Denn ich denke man wird das MP3 von der SD-Card streamen müssen, da auch 1MB Huaptspeicher sehr schnell voll läuft.

Grüße
Janaha

[DJLinux]

Hallo Janaha
da ich noch "HiVeLos" bin waren Deine Ausführungen sehr erhellend für mich.

Das Streamen kann natürlich auch von SD erfolgen, nur der decoder COG
muss auf ca 38-40KB Filterbanke zugreifen können (wie ein Array mit 10K 32Bit Worten)
daher müste das Array im externen RAM zur Verfügung stehen.

Da fällt mir doch glatt die nächste Frage ein hat das HiVE OS eine Speicherverwaltung?
Soll heissen wenn der Decoder COG die 10K Long's für die Filterbänke Alloceiert hat
ist dann garantiert das kein andere COG z.B. der 3D COC (Träum ) den selben
Speicherbereich zu Gesicht bekommt.

Oder einfacher gefragt gibt es alloc/malloc und free auf dem HiVe?

Grüsse Joshy

[Janaha]

Hm,

also ich denke mal das der zugriff auf die ca. 40KB großen Filterbänke selbst bei wahlfreiem Zugriff keine nennenwerten Probleme bereiten sollten, selbst wenn man den RAM zugriff nicht super optimiert trimmt. Schließlich bräuchten wir den TON ja nur mit ca. 44,1 Khz generieren, was ja deutlich unter der maximalgeschwindigkeit der RAM's liegt.

Und was die Speicherverwaltung angeht, ich meine das es das noch gar nicht gibt und jeder COG da sein eigenes Ding drehen könnte. Aber da lass ich mich gern korrigieren.

Grüße
Janaha

p.s. Mein Bausatz ist auch noch unterwegs, ich leite das alles von den Schaltplänen, den Datenblättern und aus der Propeller Anleitung ab, fehler natürlich icht ausgeschlossen.

[drohne235]

da das Latch aber wohl warscheinlich nur mit 3,3 Volt läuft steigt der delay auf max. 88ns, dies konnte ich dem Schaltplan nicht entnehmen.

Das Latch läuft mit 5 V.

Oder einfacher gefragt gibt es alloc/malloc und free auf dem HiVe?

Momentan gibt es das noch nicht. Aber damit ist es ja noch nicht getan: Neben dem Speicher ist ja der Bus selbst auch eine Ressource die es zu verwalten gilt. Es wäre ja durchaus möglich mit mehreren COG's auf den Bus zuzugreifen, was natürlich Chaos gibt. Also muß man das per Semaphoren koordinieren, was ja Parallax im Propeller per Hardware realisiert, aber drohne235 nicht im ios implementiert hat... Solche Sachen überlasse ich mal den Leuten die sich damit auskennen.

Und was die Speicherverwaltung angeht, ich meine das es das noch gar nicht gibt und jeder COG da sein eigenes Ding drehen könnte. Aber da lass ich mich gern korrigieren.

Richtig erkannt. Ihr habt die ganze Freiheit und alle Macht!

[Janaha]

Ah, das ist gut.

Die Geschwindigkeit des Latches ist Bauartbedingt wohl langsamer, wenn man die Spannung reduziert. Mit 5 Volt söllte sich nach Datenblatt eine geschwindigkeit zwischen 16ns (typisch) und 28,7ns(maximal) im "propagation delay" ergeben. Aber vorsicht, diese Werte gelten nur bei genau 25 Grad Umgebungstemperatur. Wenn der Chip deutlich wärmer oder kälter wird, dann ändern sich diese Werte um bis zu 8ns, bei einem Range von -40 nis +85 Grad. (siehe Datenblatt ).

Ich denke eh, das wir nicht versuchen sollten an das Theoretische maximun zu nahe heran zu gehen, sonst fangen wir uns nacher nur alle mögliche und unmöglichen Fehler ein die nur zu schwer zu erkennen sein werden.

Grüße
Janaha

[Bushmills]

jo, speicherverwaltung ist geplant. Ich würd wohl schauen, daß ich von früheren Imlementationen mitnehm, was sich auf den Propellern benutzen läßt.

Bissle source und test steht im Netz:
http://forthfreak.net/jsforth.js, unter (etwa 2/3 in den file rein)
// =================================================================================================
// heap
// =================================================================================================

zum laufenlassen zu testzwecken:

http://forthfreak.net/jsforth80x25.html
am prompt eintippen: 27 load <Enter>
und go <Enter>

Beenden mit irgendeiner Taster. Der Quellcode des Testprogramms ist mittels
27 list <Enter> einsehbar.

Was da dann über den Schirm huscht, ist eine updatende Liste der memory handles, mit Adresse und Größe, als Folge von zufälliger Allozierung und Freigabe von zufällig bemessenen (relativ kleinen, für mehr fragmentation) Speicherbereichen.
die "freed" verändern sich auch dauernd, aufgrund der transparenten Defragmentierung. Sowohl first fit (potentiell schneller, aber mehr fragmentation) als auch best fit (langsamer und weniger fragmentation) werden unterstützt.

In den textfenster-demos (im GUI thread) wird ein ähnliches Speichermanagement benutzt, wobei dort der Aufwand, der betrieben wird, um Fragmentierung gering zu halten, gößer ist.