Hallo, ich würde gerne den ADSP-21489 für Audioprojekte verwenden, das werden sogar mehrere werden. Um in die Materie reinzukommen, würde ich erst einmal das Evalboard besorgen, das ist hier beschrieben: http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/21489-ezlite.html#eb-documentation Eine IDE für die Softwareentwicklung ist dabei, der Preis für das "EZLITE" ist zwar recht hoch (über 500Euro), aber geht noch. Später will ich aber die DSPs einzeln kaufen und in eigenen Schaltungen verwenden. Leider läuft die IDE aber nur exklusiv mit dem Evalboard und soweit ich das auf den Seiten von Analog Devices sehe, kosten IDEs für normale Benutzung mehrere Tausend Euro... Gibt es auch billigere Möglichkeiten, andere Compiler? Ich brauche dann ja keine Debugmöglichkeiten mehr, das kann ich vorher ja mit dem Evalboard klären, es reicht, den Code zu compolieren und hochzuladen. Mit den Algorithmen kenne ich mich schon aus, als PC-Programme für Audioverarbeitung von WAV-Dateien läuft da schon was. Gruß Andy
Andreas W. schrieb: > Gibt es auch andere Compiler? Vielleicht von Green Hills Software oder Wind River Systems. Wenn die sowas nicht haben, dann bezeifle ich dass jemand anders was hat (außer Analog Devices selbst natürlich). http://www.ghs.com/ http://www.windriver.com/
Ich wuerde mir ein Monitorprogramm aka Debugger schreiben. Damit man auf dem endgueltigem Zielsystem nicht ganz im Wald steht. Und zum Compilieren/Assemblieren die Software des Evalkits nutzen. Manche Evalkits lassen sich mit etwas Umbauaufwand an ein externes Target anpassen. Oder ist das in den Lizenzbedingungen ausgeschlossen?
Moin, Andreas W. schrieb: > Ich brauche dann > ja keine Debugmöglichkeiten mehr, das kann ich vorher ja mit dem > Evalboard klären, es reicht, den Code zu compolieren und hochzuladen. Das ist immer ein frommer Wunsch. Ich wuerde mich keinesfalls auf so einen Deal einlassen. Musst halt ausrechnen, was eine unkastrierte Entwicklungsumgebung umgeschlagen pro Board kosten wuerde. Wenn das zu viel ist - was bei kleinen Stueckzahlen schnell passieren kann, guck', dass du auf irgendeinen anderen Prozessor kommst, fuer den es guenstigere Enwicklungsumgebungen gibt. Gruss WK
Hallo, noch habe ich das Evalboard nicht gekauft, ich habe das vor. Daher weiß ich nicht, wie die Softwarebeschränkung realisiert ist. Ob es nur in der Lizenz steht, ob sie nur exakt den einen DSP-Typ auf dem Bord unterstützt (dort ist ein BGA-Gehäuse, ich will einen mit TQFP verwenden, der hat ein paar Pins weniger) oder ob so eine Art Dongle auf dem Board ist, kann ich daher nicht sagen. noch habe ich das Datenblatt vom DSP nicht durchgelesen, ich weiß nicht, ob die Software reingeflasht wird oder sich in einem externen Speicher befindet. Evtl. kann man in der Software auch eine Funktion mit hineinprogrammieren, die ihren eigenen Code über eine Schnittstelle ausgibt, wenn die Software keine entsprechenden Files mit Binärdaten anlegt. Mal,sehen, ob AD vielleicht doch noch eine billigere Compilerversion hat, die dann weniger DSPs unterstützt und weniger Funktionen enthält. Gruß Andy
Moin, bist du denn auf die SHARCs (wegen Float) angewiesen? Mit dem Fixpoint-Blackfin kann man auch ganz nette Audiosachen machen, man muss halt ein paar Assembler-Tricks nutzen, um die Performance für mehr als 16 Bit rauszukriegen. Für den Blackfin gibt's nen gut funktionierenden GNU-Compiler (der ist IMHO besser als das Original von ADI). Für den vollen SHARC-VDSP-Debugger-Arbeitsplatz musst du ansonsten schon min. 5k€ einrechnen. Mit einigen ARMs kann man auch einiges an DSP-Power bewältigen, aber für längerfristige Investitionen ist bei mir der Blackfin trotz (oder gerade?) wegen seines Alters immer noch Geheimtip, also erste Wahl. gruss, - Strubi
Hallo, 16 Bit ist definitiv zu wenig, ich verarbeite 24 Bit Audio. Da sollte die Wortbreite eher sogar noch etwas größer sein, Floating Point wäre eben ideal. Dafür brauche ich das eher nur für ein schnödes FIR-Filter - allerdings mit 8191 Tabs, mindestens mit 4095 Tabs, sonst kann man im Baßbereich keine Filterkurven mehr realisieren. Bei 48kHz für 2 Kanäle (= ein I²S In-/Output) bin ich dann schon bei knapp 800 Millionen Multiply/Add Operationen/s. Man kann das auch auf z.B. zwei DSPs aufteilen, dann braucht man zwischen den Prozessoren zwei I²S-Verbindungen. Ich brauche also richtig Rechenpower und möglichst >=24 Bit Wortbreite, wenn die Summe eine größere Wortbreite hat (oft ist die doppelt so groß wie die für Daten und Faktoren der Impulsantwort, die an die Multiplizierer gehen). Inzwischen habe ich bei NXP nach dem DSP56724 ("Symphony" DSP) geguckt, da gibt es die Software erstaunlicherweise kostenlos. Allerdings muß ich mich dann mit DSPs eindecken, da die nicht mehr für Neuentwicklungen vorgesehen sind. Die Software und Datenblätter habe ich schon mal downgeloaded, es ist ein 24Bit Fixed Point DSP, also so gerade das Minimum, was für mich brachbar ist, könnte also klappen. Bei Texas bin ich gar nicht fündig geworden, keine DSPs für Audio gefunden und passende Software fand ich auf der chaotischen Seite erst einmal auch nicht. Wenn das gar nicht mit DSPs klappt, wird das ganze eine FPGA-Lösung. Dann landet das Filter da drin, wahrscheinlich brauche ich dann auch mehrere FPGAs pro Zweikanalfilter. Bei z.B. 100MHz Takt müßte ich 8 Multiply/Add Operationen pro Takt parallel ausführen (Pipilining), auf zwei FPGAs aufgeteilt 4 Multiply/Add Operationen usw. Evtl. kann ich die FPGAs auch auf 200MHz hochprügeln, nach außen hin gibt es nur wenige I²S-Ports und einen SPI-Bus. Aber DSPs wären billiger und flexibler. Gruß Andy
Moin, Andreas W. schrieb: > Dafür brauche ich das eher nur für ein schnödes FIR-Filter - > allerdings mit 8191 Tabs, mindestens mit 4095 Tabs, sonst kann man im > Baßbereich keine Filterkurven mehr realisieren. google z.B. mal nach "01200_Polyphase.pdf" vielleicht brauchst du doch nicht so viele Taps, wie du glaubst. Andreas W. schrieb: > Wenn das gar nicht mit DSPs klappt, wird das ganze eine FPGA-Lösung. > Dann landet das Filter da drin, wahrscheinlich brauche ich dann auch > mehrere FPGAs pro Zweikanalfilter. Bei z.B. 100MHz Takt müßte ich 8 > Multiply/Add Operationen pro Takt parallel ausführen (Pipilining), Naja und? Der kleinste Spartan3 hat schon 12 dedizierte Multiplizierer eingebaut. Und der ist uralt und eben der allerkleinste... Bevor du dich auf irgendeine (am End' sehr exotische IDE zu sehr exotischen Preisen) Architektur festlegst, koennte intensives Studium von Datenblaettern, Algorithmen, Programmier- und Hardwarebeschreibungssprachen und ihren Moeglichkeiten und Limitationen nicht schaden :-) Gruss WK
Hallo, Polyphase geht nur bei solchen Tiefpässen. Ich mache aber eben eher Klangregler oder parametrische Equalizer, um Raumresonanzen wegzuregeln. Das bedeutet, daß praktisch beliebige Frequenzgänge realisierbar sein sollen und normalerweise auch bis zu 20kHz nicht völlig abregeln. Polyphase nutzt aber die Tatsache aus, daß nur noch sehr tiefe Frequenzen am Ausgang herauskommen sollen, so kann man unterabtasten. Da mache ich eine inverse FFT vom Frequenzgang, dann eine Fensterfunktion (z.B.Blackmanfenster) und erhält so die Filterkoeffizienten. Auf dem PC per Software mit WAV-Files funktioniert das schon einwandfrei. Auch, wenn mehrere Klangregler und Equalizer auf einmal verwendet werden sollten, braucht man nur das eine FIR-Filter, der Gesamtfrequenzgang wird zuerst berechnet, dann die Filterkoeffizienten daraus. Einen Spartan habe ich mir auch schon seit längerem ausgesucht, ich brauche aber mehrere Multiplizierer, um eine Wortgröße von 24Bit zu erreichen. Evtl. reichen 16Bit für die Koeffizienten, das macht nur den Frequenzgang etwas ungenauer, beeinträchtigt jedoch nicht die Audioqualität und absolut phasenlinear bleibt es auch dann noch. Ich nehme den größten Spartan, den es noch in QFP- oder TQFP-Gehäuse gibt, da ich einiges an Speicher für die Filterkoeffizienten und auch für die Audiodaten brauche. Und das limitiert die Performance, die Multiplizierer schaffen das wohl schon. Ich schätze, daß ich zwei Spartans für ein Filter brauchen werde. Das war auch zuerst angedacht worden, DSPs wären nur etwas flexibler und vielleicht auch billiger, in VHDL habe ich schon einiges realisiert, sowohl beruflich als auch privat. Ich schätze, ich werde wohl bei der Spartanlösung bleiben, wenn ich das Datenblatt vom NXP-DSP gelesen habe... Außerdem gibt es schließlich eine große Audiomatrix mit etlichen Ein- und Ausgängen, jeder Ausgang ist eine individuelle Linearkombination aller Eingänge, so ist der Verstärker softwaremäßig relativ frei konfigurierbar. Das geht nur mit einem FPGA wegen der vielen Ein- und Ausgänge, da sie alle I²S mit gemeinsamen Taktleitungen sind, nur die Datenleitungen sind getrennt, so daß es trotzdem nicht sooo viele Pins werden. Die Rechenleistung reicht da locker aus, da sind es viel weniger Multiply/Add Operationen als bei den Filtern. Gruß Andy
Moin, > 16 Bit ist definitiv zu wenig, ich verarbeite 24 Bit Audio. Da sollte > die Wortbreite eher sogar noch etwas größer sein, Floating Point wäre > eben ideal. Die Wortbreite im Compiler ist bis 64 Bit. Ich verstehe das Problem schon, aber 32 Bit Audio zu verwursten ist mit dem Blackfin rechnerisch kein Problem, es geht halt nicht mehr mit einem Maschinenzyklus. Bei 600 MHz Takt sind die paar zusätzlichen Ops für Audio ansich kein Problem, bei riesigen FFTs sieht's natürlich wegen der Dynamik anders aus, aber auch da kann man mit Normierungstabellen in Fixpoint gut tricksen Also den Vergleich mit der 56k-Architektur würde ich nicht mehr machen :-) > > Inzwischen habe ich bei NXP nach dem DSP56724 ("Symphony" DSP) geguckt, > da gibt es die Software erstaunlicherweise kostenlos. Allerdings muß ich > mich dann mit DSPs eindecken, da die nicht mehr für Neuentwicklungen > vorgesehen sind. Die Software und Datenblätter habe ich schon mal > downgeloaded, es ist ein 24Bit Fixed Point DSP, also so gerade das > Minimum, was für mich brachbar ist, könnte also klappen. Bei Texas bin > ich gar nicht fündig geworden, keine DSPs für Audio gefunden und > passende Software fand ich auf der chaotischen Seite erst einmal auch > nicht. > TI hat sich bei seinen DSP-Hybriden etwas verzettelt, wenn ich ehrlich bin. Das Zeug hat eine Menge undokumentierter Bugs und ist vor allem auf Video ausgerichtet. Sobald man aber von den Standard-FAE-Apps abweicht, ist man auf sich alleine gestellt. Da würde ich eher schauen, dass du nen ARM mit DSP-Extensions herkriegst, damit lässt sich auch locker einiges an Audio mit machen. > Wenn das gar nicht mit DSPs klappt, wird das ganze eine FPGA-Lösung. > Dann landet das Filter da drin, wahrscheinlich brauche ich dann auch > mehrere FPGAs pro Zweikanalfilter. Bei z.B. 100MHz Takt müßte ich 8 > Multiply/Add Operationen pro Takt parallel ausführen (Pipilining), auf > zwei FPGAs aufgeteilt 4 Multiply/Add Operationen usw. Evtl. kann ich die > FPGAs auch auf 200MHz hochprügeln, nach außen hin gibt es nur wenige > I²S-Ports und einen SPI-Bus. Aber DSPs wären billiger und flexibler. > Wieso solltest du da zwei FPGAs für brauchen? Schon auf dem kleinen Spartan6 hast du derart viele Multiplier, dass du da zwei bis vier DSP-Cores a la 56k locker draufkriegst, und die 18-Bit-MULs kaskadiert man eh zu 36 Bit, das macht die Toolchain sogar automatisch. Braucht zwar Entwicklungsaufwand, dafür bist du sehr flexibel und kannst deine eigene Fixpoint-Arithmetik implementieren (was bei manchen Filtern mit seinen Quantisierungsproblemen sehr nützlich sein kann), plus du kannst den ganzen Kram simulieren. Nur: in VHDL würde ich das nicht mehr machen, es gibt nette DSP-Toolchains in der MyHDL community, da schreibst du dir keinen Wolf, und die Arithmetik ist sehr robust. Chris Felton hat da viel gemacht. Grüsse, - Strubi
Hallo Andy, ich habe mich bei meinem Projekt KlarerTon (http://www.klarerton.de) mit dem ADSP21262 für den AD-Compiler entschieden. Der ist zwar nicht billig, aber wohl das Optimum für den Sharc. Der Support von AD ist einmalig gut, auch wenn Du keine Stückzahlen in Aussicht stellen kannst. Du erhältst eine 3-Monate Testlizenz, die auch mal um weitere 3 Monate verlängert wird. Schreib die einfach mal an. Auch in der Entwicklungsphase helfen die Mitarbeiter im Forum von AD mit hohem Einsatz weiter. Bei meinem Projekt habe ich die ersten Entwicklungsschritte auf dem EvalBoard gemacht. Danach habe ich vom Steuer-Prozessor (ATMega 644A) per SPI gebootet. Diese Lösung hat sich bei mir sehr gut bewährt. Da ich das Projekt nicht mehr weiter entwickle, ist die Lizenzpolitik von AD für den Compiler für mich optimal: Du kannst den Compiler/die IDE mit der einmal erworbenen Lizenz unendlich nutzen, erhältst aber nur mit einer aktualisierten Lizenz Updates. Das ist gerade für Einzelprojekte sehr fair. Wenn Du an Informationen zu meiner Lösung Interesse hat, melde Dich. Grüße, Kurt PS: Das EvalBoard für den ADSP2126x liegt hier noch. Wenn Du es haben willst, melde Dich.
Sharky schrieb: > Das EVAL board ist nicht zufällig noch zu haben? Doch, das liegt hier noch und wartet auf einen Nutzer. Einige andere nützliche Dinge könnten sich auch noch finden :-) Du kannst mich unter kurt.harders@posteo.de kontaktieren.
@kurt: Habe mir den thread zu deinem Projekt mal durchgelesen: Ist da eigentlich was bei rausgekommen? Andreas W. schrieb: > Inzwischen habe ich bei NXP nach dem DSP56724 ("Symphony" DSP) geguckt, > da gibt es die Software erstaunlicherweise kostenlos. Allerdings muß ich > mich dann mit DSPs eindecken, da die nicht mehr für Neuentwicklungen > vorgesehen sind. Die sind nicht mehr zeitgemäß. Es gibt immer noch welche, die denen nachhängen, aber es gibt Besseres: Beitrag "Re: Emulation DSP56k für Audio Anwendungen"
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.