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
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!
