Zuerst: Ich habe noch nie mit einem DSP gearbeitet. Mein Wissen beschränkt sich in etwa auf den Wikipedia Artikel zu DSPs. Angenommen ich habe eine Aufgabe bei der mit 100 KHz Frequenz ein analoger Wert gemessen, durch ein paar FIR Filter gejagt, auf irgendwelche Randbedingungen überprüft, und dann sofort wieder ausgegeben wird. Hat dann ein DSP große Vorteile gegenüber z.B. einem 32-bit ARM Cortex M3 Microcontroller @ 100MHz ? Oder anders gefragt: Was ist, abgesehen von ein paar kleinen Optimierungen, die wirkliche Stärke eines DSP? Ob ich die Messwerte einzeln verarbeiteten will, oder ob es z.B. möglich sein wird 100 Messwerte auf einmal verarbeiten, darüber bin ich mir noch nicht ganz im Klaren. Das System muss halt eine sehr kurze Reaktionszeit haben. Tobias
Tobias K. schrieb: > Oder anders gefragt: Was ist, abgesehen von ein paar kleinen > Optimierungen, die wirkliche Stärke eines DSP? Du hast es schon erkannt, der Vorteil eines DSPs ist die Spezialisierung auf "digital signal processing". Dadurch ist ein DSP bei gleicher Befehlsrate leistungsfähiger als ein "normaler" Prozessor bei Signalverarbeitungsproblemen. Ob man dann wirklich einen Spezialisten oder doch lieber einen dementsprechend schnelleren Generalisten holt, um eine Aufgabe zu erledigen, hängt von den restlichen Vorgaben ab (Kosten, Stromverbrauch, Gehäuße, zusätzliche Aufgaben...) :-)
Wie kann ich denn grob abschätzen welchen Geschwindigkeitsvorteil der DSP bringt? Muss man dafür die genaue Funktionsweise kennen? Geht es hier eher um Faktor 2 oder Faktor 10 oder 100?
Wenn der ARM schnell genug für die Aufgabe ist, dann solltest du auch den ARM nehmen. Außer den Geschwindigkeitsoptimierungen für DSP Aufgaben hat ein DSP nämlich nur Nachteile gegenüber einem normalen Controller. Das fängt beim Preis und der Peripherie an und hört bei der Einarbeitung auf.
Tobias K. schrieb: > Wie kann ich denn grob abschätzen welchen Geschwindigkeitsvorteil der > DSP bringt? Muss man dafür die genaue Funktionsweise kennen? > > Geht es hier eher um Faktor 2 oder Faktor 10 oder 100? Das hängt von Deinen Algorithmen ab. Typische DSP-Erweiterungen sind: - Multiply-and-Accumulate: x=x+a*b als Einzelbefehl in einem Taktzyklus. Das wird besonders bei Filteralgorithmen benötigt. Bei den meisten Standardprozessoren braucht man dafür 2-3 Befehle - Saturierung anstelle überlauf. Heißt also: Ein Registerinhalt bleibt beim Überlauf beim höchsten positiven Wert kleben, anstelle auf 0 oder -1 umzukippen. - Unterstützung von Festkommaformaten. - Unterstützung von Ringpuffern bei der Adressierung - Unterstützung von Bit-Reverse bei der Adressierung (für FFT nützlich) Wenn Deine Algorithmen davon profitieren, dann kannst Du einen großen Nutzen durch die Implementierung auf einem DSP ziehen. PS: Wenn Du jetzt einen Cortex M3 hast, kannst Du Dir auch den M4 anschauen. fchk
OK, Danke für die Antworten. Das hört sich für mich eher nach einem Geschwindigkeitsvorteil von 2 bis 5 an. Dafür lohnt sich für mich die Einarbeitung nicht. Außerdem bedeutet das, dass man um Code-Optimierung so oder so nicht herum kommt. Mit ausreichend Optimierung müsste das Problem auch mit einem ARM lösbar sein.
Hallo, ein großer Nachteil bei der DSP-Programmierung ist, dass man die wesentlichen Algorithmen, die oben schon genannt wurden, quasi nur in Assembler effizient schreiben kann, da die meisten Compiler nicht auf jeden Spezialbefehl eines DSP optimiert sind und daher nur Standardalgorithmen verwenden. Bei manchem Hersteller löst sich das Problem teilweise durch in Assembler geschriebene Bibliotheken für den jeweiligen DSP. Wenn du allerdings den Cortex-M3 schon kennst und trotzdem DSP-Funktionen nutzen willst, würde sich vielleicht ein Umstieg auf Cortex-M4 (DSP- und FPU-Erweiterung) lohnen. MfG
> Angenommen ich habe eine Aufgabe bei der mit 100 KHz Frequenz ein
analoger Wert gemessen, durch ein paar FIR Filter gejagt, auf
irgendwelche Randbedingungen überprüft, und dann sofort wieder
ausgegeben wird.
Gerade die Echtzeitverabeitung ist die Stärke des DSP. Die DSPs erlauben
verschiedene Interrupt-Prioritäten zu setzen und sind zusätzlich so
ausgelegt, dass der höchst-prioritisierte Interrupt garantiert
spätestens nach x-hundert Nanosekunden bedient wird. Das wird du
eventuell auf deinem Cortex-X nicht finden. Schau mal im Datenblatt.
Tobias K. schrieb: > OK, Danke für die Antworten. Das hört sich für mich eher nach einem > Geschwindigkeitsvorteil von 2 bis 5 an. Dafür lohnt sich für mich die > Einarbeitung nicht. Ich vergaß noch: - Unterstützung mehrerer Adressräume (Programmcode, X-Daten, Y-Daten), so dass das Laden von Koeffizienten und Daten bei Filtern gleichzeitig passieren kann. > Außerdem bedeutet das, dass man um Code-Optimierung so oder so nicht > herum kommt. Mit ausreichend Optimierung müsste das Problem auch mit > einem ARM lösbar sein. ARM ist für so etwas schon gar nicht schlecht ausgestattet. Das Problem ist C. Die für Filter so wichtige Sättigungsarithmethik etwa kennt C nicht. Punkt. Wenn Du das brauchst, wirst Du auf Assembler-Ebene gehen müssen. Gleiches gilt für die Bitreverse-Adressierung. Unter C nicht verfügbar. Eine optimale FFT gibts also nur mit Assemblercode. (*) Glücklicherweise gibts Hilfe. Schau in die aktuellen CMSIS-Bibliotheken: http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php (*) ARM löst das im CMSIS durch den Einsatz von compilerspezifischen Intrinsics, die dann geeigneten Code erzeugen. Gut, wenn man nicht nur den Prozessor macht, sondern auch einen Compilerbauer gekauft hat (Keil). fchk
Das hört sich ja ganz gut an. Der ARM uC ist ein NXP LPC1769. Dafür gibt's auch folgende Appnote die ich mir noch zu Gemüte führen muss: http://www.nxp.com/documents/application_note/AN10913.pdf Auszug: DSP library for LPC1700 and LPC1300 The DSP library has been developed as a commonly used set of DSP functions optimized for the NXP Cortex-M3 LPC1700 and LPC1300 family products. The library is supplied as a static library project with source code in LPCXpresso (Code Red), Keil and IAR versions, and can also be linked into any ARM-EABI tool chain as a binary library. DSP library functions •Biquad filter •Fast Fourier transform •Dot product •Vector manipulation •FIR filter •Resonator •PID controller •Random number generator The Cortex-M3 has several attributes that make it deliver excellent DSP performance: •1-cycle 32x32 -> 32 signed multiplication •2-cycle (32x32)+32 -> 32 signed multiply accumulate •Cortex-M3 is Harvard in having a separate data port to memory and instruction port to memory
Tobias K. schrieb: > Das hört sich ja ganz gut an. > > Der ARM uC ist ein NXP LPC1769. Ist das schon fest? Ansonsten sind die STM32F4 geeigneter für Dich. > Dafür gibt's auch folgende Appnote die > ich mir noch zu Gemüte führen muss: > http://www.nxp.com/documents/application_note/AN10913.pdf Ich würde eher CMSIS nehmen, weil das herstellerneutral ist. Und denke dran, dass der Compiler für die Performance auch sehr wichtig ist. gcc ist hier nur zweite Wahl. fchk
> gcc ist hier nur zweite Wahl.
Das ist zwar richtig, aber die in der AN beschriebene Bibliothek ist in
Assembler optimiert, von daher wahrscheinlich nicht weiter tragisch.
Frank K. schrieb: >> Der ARM uC ist ein NXP LPC1769. > > Ist das schon fest? Ansonsten sind die STM32F4 geeigneter für Dich. Für den NXP LPC1769 habe ich jemanden der sich damit auskennt (ich selber habe damit noch nichts gemacht). Mein Plan: Ich versuche erstmal den Algorithmus dafür zu implementieren und wenn die Leistung trotz Optimierung nicht ausreicht, dann weiß ich wo ich mehr bekommen kann :)
> Gerade die Echtzeitverabeitung ist die Stärke des DSP. Die DSPs erlauben > verschiedene Interrupt-Prioritäten zu setzen und sind zusätzlich so > ausgelegt, dass der höchst-prioritisierte Interrupt garantiert > spätestens nach x-hundert Nanosekunden bedient wird. Das wird du > eventuell auf deinem Cortex-X nicht finden. Schau mal im Datenblatt. Also das erlaubt ja selbst ein nun wirklich mickriger R8C13. Und ein multiplay-accumulate Befehle hat er auch. Trotzdem wuerde den wohl keiner als DSP bezeichen. Ich wuerde sagen ein Controller der keine priorisierbaren Interrupts hat ist ganz einfach Murks. Olaf
Olaf schrieb: > Ich wuerde sagen ein Controller der keine priorisierbaren Interrupts hat > ist ganz einfach Murks. AVR?? ^^
Moin, Um mal wieder etwas Verwirrung zu stiften :-) Bei den "cutting edge"-Architekturen wie z.B. Blackfin und neueren Cortexen verschwimmt der Unterschied zwischen DSP und uC zunehmend. Vorreiter ist hier der Blackfin, den man wohl als Hybriden bezeichnen darf (oder deutsch: eierlegende Wollmilchsau). Also so ein Mischmasch von allem, was gut ist: Parallele Befehle, breiter Bus für paralleles Fetch/Store, Cache, smarte Pipeline, damit man die Anzahl benutzter Zyklen innerhalb der Schleifen gut im Griff hat. Dazu kommt noch ne sehr effektive DMA-Engine für Streaming ohne CPU-Last und ohne Datenverlust. Vorteil ist bei der Architektur, dass sich die Jungs von Intel viele Gedanken nicht nur über wichtige Fixkomma-Arithmetik-Primitiven, sondern auch eine lesbare Assembler-Syntax gemacht haben. Im Endeffekt würde ich mir jedoch beim Einstieg keine grossen Gedanken über die Architektur machen. Gewonnen hast Du oft schon mit der Wahl eines Chips, den man in GCC gut programmieren kann - das macht den Code prinzipiell schon gut wiederverwertbar und erleichtert das schnelle Portieren. Meistens entscheidet eh die Verfügbarkeit der Eval-Boards :-) Gruss, - Strubi
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.