Hallo Zusammen Ich bin auf der Suche nach einem geeigneten DSP für ein Studentenprojekt und weitere nachfolgende Projektarbeiten. In Studium haben wir schon einiges über Signalverarbeitung gelernt, jedoch nie mit praktischem Hintergrund. Bei der riesigen Auswahl an DSPs von Ti und AD fällt es einem (ohne die nötige Praxiserfahrung) nicht leicht, eine geeignete Auswahl zu treffen. Ein Hauptkriterium für die Auswahl ist eine einfache Handhabung sprich man soll relativ einfach eine FFT und ein FIR / IIR Filter implementieren können. Einfache Entwicklungsumgebung welche den Einstieg erleichtert. Weiter wäre es von Vorteil, wenn der DSP schon vielfach eingesetzt wurde und sich dementsprechend viele Hinweise, Problemlösungen usw. im Netz finden lassen. Zu den konkreten Anforderungen: Ein Signal mit hohem Dynamikumfang soll mit einem 24Bit ADC bei einer Samplingrate von 50kHz - 100kHz abgetastet werden. Nach anschliessender digitaler Tiefpassfilterung und Dezimation soll eine 1024er FFT berechnet und das Amplituden sowie Phasenspektrum an einen Hostcomputer übertragen werden. Pro Sekunde sollen es möglich sein zwischen 50 und 100 FFTs zu berechnen. Der Stromverbrauch sollte hierbei möglichst gering sein (<100mW) Meine Frage nun ist: welcher DSP bietet sich für diese Aufgabe an? Mit welchen DSPs arbeitet ihr? Ich bin froh um euer Erfahrungsberichte und auch um Anmerkungen betreffend welche DSP unbedingt gemieden werden sollten. Danke und Gruss Martin
>Weiter wäre es von Vorteil, wenn der DSP schon vielfach >eingesetzt wurde und sich dementsprechend viele Hinweise, >Problemlösungen usw. im Netz finden lassen. Ein kostenloser Compiler/Ide ist auch nicht zu verachten... Du solltest also deine Suche auf eine komplette Entwicklungsumgebung erweitern. Also sowas: http://www.ti.com/tool/tmdsdsk6416 oder sowas: http://www.ti.com/tool/tmdxevm5515 Nicht ganz billig der Spass. Für den kleinen Geldbeutel ziemlich cool: http://www.ti.com/tool/tmdx5535ezdsp&DCMP=dsp-c5000-c553x-110830&HQS=dsp-c5000-c553x-pr-sw Gruß Jonas
Tag, die Frage kommt hier immer wieder auf, aber für Deine spezifischen Anforderungen ist sie ev. sogar gar nicht so leicht zu beantworten. Die Low-End-Klassiker-DSPs, die man momentan so am meisten findet, kann man an den Fingern abzählen: - TI TMS320C6xxx-Varianten - ADI Blackfin-Familie - 56k-Derivate von Freescale Jetzt das Problem float versus Fixpoint: nur der 56k hat native 24-Bit-Arithmetik, die andern bloss 16. Das lässt sich natürlich kaskadieren, aber nicht mehr in EINEM Taktzyklus abhaken. Float haben die obigen Cores ausser einigen C6000ern nicht. Das würde sich auch mit niedrigem Stromverbrauch beissen. Die nächsthöhere Generation wäre dann zumindest bei ADI die SHARC-Architektur, die echte float-DSP-Arithmetik macht. Ich persönlich greife gern zu den Blackfin-Chips wegen der gut dokumentierten Architektur/Tools und dem ungeschlagenen Stromverbrauch bei hoher Leistung, allerdings holt man generell bei den DSPs die volle Performance nur raus, wenn man die Pipeline effizient füllt, d.h. Assembler-Programmierung ist angesagt, die Einarbeitung ist nicht ohne. Das Problem ist da nur wieder das begrenzte native Fixpunkt-Format (16 bit, 1.15), da muss man sich im Detail mit der Arithmetik herumschlagen, um grössere Bittiefen zu erreichen. Ich würde in dem Fall eher die Wahl auf die C6000-Derivate fallen lassen. Leider sind die von der Handhabung einiges komplexer. Die OMAP-Dinger sind teils nur auf teurem Wege oder sonst scheusslich zu debuggen. Dasselbe gilt auch für die etwas veralteten SHARC-Architekturen, da kosten die Tools zudem richtig viel Geld. Beim SHARC stellt sich v.a. das Problem: Wie kriegt man die Daten dann wieder raus. Die aktuellen DSP-SoCs haben fast alle ein Ethernet-Interface. Mein Vorschlag - as usual: Prototyping. Erst mal auf dem PC den Algorithmus vorformulieren (z.b. libfpmath, usw.), dann Zyklenbedarf ermitteln, und durch den Simulator (skyeye) hauen. Wenn es nicht zyklengenau und in Echtzeit laufen muss, könntest du auch mit einem der üblichen ARM-SoCs zum Ziel kommen. Nur tauchen da ev. wieder andere Probleme auf (Kernel-Treiber, die meisten Systeme kommen nur mit Linux-Support). Der allerletzte Weg, den ich allerdings auch immer öfter begehe, ist per FPGA. Auf den grösseren Käfern reicht der interne Speicher aus, um CPU und Realtime-FFT zu implementieren. Sobald man aber grössere Blöcke puffern muss, ist der Spass vorbei, dann braucht man schon einen RAM-Controller. So oder so ist der Aufwand von Null auf erheblich höher als beim DSP.
Ich würde mich da dann fragen, brauch ich wirklich 24bit Auflösung für die filter und die fft. 24 bit audio material ist sehr rar, der allergrößte teil kommt mit 16-bit dynamik aus (mp3 bis audio-cd). Also vielleicht die Anforderung einmal der Realität anpassen. Gruß Jonas
Danke für die Hilfreichen Kommentaren @jonas Die Bemerkung mit dem kostenlosen Copiler / IDE ist wirklich gut. Eine komplette Entwicklungsumgebung ist hier sicher sinnvoll. Ganz kostenlos muss sie jedoch nicht sein. Wenn die Qualität gut ist, darf man auch etwas dafür verlangen. Jedoch kann ich nicht einschätzen in welchem Rahmen sich die Kosten bewegen. Ist es korrekt dass bei einem kostenpflichtigen Compiler bereits fertige Librarys mit optimierten Implementationen von FFT iFFT FIR usw. zur Verfügung stehen? Oder sind diese in jedem Fall separat bei den Herstellern einzukaufen? Deine Links sehen interessant aus. Vor allem da sie ein Komplettpaket beinhalten mit Beschreibungen und Tutorials. Deine Links sind alle von TI, hast du damit schon gute Erfahrungen gemacht? Ich muss noch erwähnen dass es bei meiner Messung nicht um Audiosignale geht sondern um eine Strommessung welche von wenigen mA bis mehrere Ampere geht. Ein ENOB von 18-20Bits wird für die Auswertung benötigen. Ein 16Bit ADC reicht bei dieser Messung nicht. @Fitzebutze Danke für deinen Ausführlichen Kommentar Die Frage ob Fixpoint oder float habe ich mir auch schon gestellt. Fixpoint scheint hier einiges stromsparender zu sein. Wobei die Implementierung mittels float einfacher scheint und weniger Fehleranfällig für Quantisierungseffekt ist. Jedoch frage ich mich wie umständlich es ist, diese Kaskadierung zu implementieren um auf einem Fixedpoint, 24Bit Worte mit der Präzision von Float bearbeiten zu können. Ich könnte mir vorstellen dass ich nicht der erste wäre, der dies zu implementieren versucht. Ich werde mir sicher die C6000 und SHARC genauer ansehen ob ich einen stromsparende Version finde. Die Blackfin DSPs sind wirklich sehr stromspahrend. Werde mir diese auch genauer ansehen. Gibt es hier auch gute und komplette Entwicklungsumgebungen mit Tutorials wie man schnell den Einstieg findet? Kannst du mir eine Empfehlen? Ich denke die Echtzeitanwendung ist nicht zwingen. Jedoch soll neben der Analyse des Spektrums auch noch der Energieverbrauch / Momentanleistung (über Strom / Spannung) des angeschlossenen Verbrauchers kontinuierlich aufgezeichnet werden. Hier ist die Anforderung an die Genauigkeit nicht so hoch. Die Idee mit einem normalen ARM-SoC werde ich auch mal prüfen. Den Tip mit dem Prototyping werde ich mir ans Herz legen. Wusste nicht dass es solche Tools gibt daher bin ich froh über jeden Input der mir bei der Analyse des Problems weiter hilft. Gruss Martin
jonas biensack schrieb: > Ich würde mich da dann fragen, brauch ich wirklich 24bit Auflösung > für > die filter und die fft. 24 bit audio material ist sehr rar, der > allergrößte teil kommt mit 16-bit dynamik aus (mp3 bis audio-cd). > Also vielleicht die Anforderung einmal der Realität anpassen. oder den eigenen Kenntnisstand aktualisieren! > > Gruß Jonas
> oder den eigenen Kenntnisstand aktualisieren!
Das macht er doch! Wenn er erstmal eine Platine gemacht hat die 24Bit
Auflösung auch nur in einem Meter Umkreis um einen DSP kann, ja dann hat
er seinen Kenntnisstand ganz erheblich voran gebracht. :-)
Olaf
Wenn nicht permanent der volle Dynamikumfang ausgeschöpft wird (was ich bei der Anwendung für unwahrscheinlich halte), dann bietet es sich an, blockweise zu skalieren, in niedriger Auflösung zu rechnen, und bei der Weiterverarbeitung/Darstellung den Exponenten zu berücksichtigen (block floating point).
Hi Martin, > Die Frage ob Fixpoint oder float habe ich mir auch schon gestellt. > Fixpoint scheint hier einiges stromsparender zu sein. Wobei die > Implementierung mittels float einfacher scheint und weniger > Fehleranfällig für Quantisierungseffekt ist. Jedoch frage ich mich wie > umständlich es ist, diese Kaskadierung zu implementieren um auf einem > Fixedpoint, 24Bit Worte mit der Präzision von Float bearbeiten zu > können. Ich könnte mir vorstellen dass ich nicht der erste wäre, der > dies zu implementieren versucht. > Nein, definitiv nicht :-) Es gibt für die diversen DSPs auch einige praktische Libraries. Die fast-float-Sachen vom Blackfin sind recht gut, allerdings aus erwähnten Gründen pur Assembler. Tröstend ist beim Blackfin, dass sich die Assembler-Befehle wie C lesen. Das ist bei den anderen gallischen Flüchen wie "MOV.X #5, (XY)+" eher bedingt der Fall :-). Dafür ist der Blackfin wieder bei 32-Bit-Multiplikationen ineffizient. Allenfalls könntest du auch die NEON-Extensions von ARM evaluieren. Ehrlich gesagt, sind die NEON-Sachen ganz schöne DSP-Killer, aber die Käfer, die ich in die Finger bekam, verbrieten definitiv zuviel Leistung. > Ich werde mir sicher die C6000 und SHARC genauer ansehen ob ich einen > stromsparende Version finde. Die Blackfin DSPs sind wirklich sehr > stromspahrend. Werde mir diese auch genauer ansehen. > > Gibt es hier auch gute und komplette Entwicklungsumgebungen mit > Tutorials wie man schnell den Einstieg findet? Kannst du mir eine > Empfehlen? Leider hat es ADI ziemlich verk*ckt, etwas uniform brauchbares anzubieten. In den letzten Jahren wurden auch sehr gute Foren immer wieder geschlossen/umgezogen (z.B. blackfin.org) Es gibt quasi zwei Lager: die VisualDSP++-Seite, die schon mal eine rechte Investition verlangt, und die GNU-Tools, letztere sind von ADI eher verwirrend supported. Es gab mal einige Anbieter, die komplette Entwicklungsumgebungen bereitgestellt haben. Musst du mal hier die Postings zu Blackfin durchforsten. Source-Code ist bei VDSP einiges dabei, lässt sich auch unter GNU nutzen, nur die Libraries (binaries) seit VDSP 3.0 nicht mehr linken (dank extra geschaffenen Inkompabilitäten zu ELF a la Microsoft). Der Toolchain-Installer für die GNU-Compiler lief letztens unter Windows ohne Murren durch, als ich es probiert habe. Guck mal bei blackfin.uclinux.org. Ansonsten gibts noch die "blackfin shell", die wurde auch hier mal gepostet. Wird allerdings kaum noch gewartet. Andreas Schwarz schrieb: > Wenn nicht permanent der volle Dynamikumfang ausgeschöpft wird (was ich > bei der Anwendung für unwahrscheinlich halte), dann bietet es sich an, > blockweise zu skalieren, in niedriger Auflösung zu rechnen, und bei der > Weiterverarbeitung/Darstellung den Exponenten zu berücksichtigen (block > floating point). Das ist noch ein interessanter Punkt. Gerade bei der FFT, wo ev. nur gewisse Bereiche interessieren, kann man sich relativ beliebig seine eigene Overflow-Arithmetik zusammenbasteln, bei der man immer den Normierungsfaktor mitführt. Dazu müsste man länger ausholen, aber im Prinzip speichert man damit pro Wert Dividend und Divisor ab, bei Overflow wird die Korrektur einfach eine Shift-Operation. Am Schluss muss man alles wieder entsprechend normieren. In C wird das teils eine üble, semiportable bis ineffiziente Trickserei (ziemlich architekturabhängig), auf den div. DSPs gibt es etwas Erleichterung durch Spezialbefehle. Die Frage ist halt, ob du es dir bei deinem Projekt leisten kannst, Hirnschmalz in die Arithmetik zu drücken, oder die Zielanwendung wichtiger ist. Typischerweise werden bei einem Projekt mit "akademischer Vorgabe" selten alle Ziele erreicht, deswegen würde ich den Grundsatz "Keep it simple" walten lassen - das Kernproblem wird meistens komplex genug. Insofern würde ich unbedingt auch einen ARM SoC mit float mal evaluieren, obwohl es da mit der 100 mW-Vorgabe ev. nicht viel Auswahl gibt (ev. STFM-Reihe?) . Apropos: Das wird bei Vollast auch schon mit dem Blackfin eng. Typischerweise zieht meine Plattform 45mA (3.3V, 600 MHz Core-Clock). Bei Volllast mit voller Bandbreite (Filter und Datenversand, eingeschaltete Peripherie usw.) können es schon mal 120mA werden. Im Standalone-Fall mit div. Tricks (CPU-Clock-Skalierung) hat man allerdings etwas mehr Kontrolle. Da ist der Blackfin auch sehr flexibel zu handhaben, von bare-metal über eCos, RTEMS bis uClinux kann man fast alles haben (und es läuft auch sehr robust). So, hoffe, das reicht erst mal an Info. Viel Erfolg!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.