Ich habe vom Fraunhoferinstitut in Erlangen (Institut für Integrierte Systeme) die Auskunft erhalten das aktuelle CPU's in etwa die Leistungsfähigkeit aktueller DSP's erreichen und ein Einsatz von DSP's nur durch den geringeren Leistungsbedarf begründet ist. Es geht um den Einsatz in der Signalverarbeitung bei der Modulation und Demodulation von Wellenformen. Andersherum gefragt: Welche Wellenformen wie z.B. GMSK wie bei GSM können mit normalen CPU's "verarbeitet" werden und welche anderen Wellenformen (OFDM ?) erfordern den Einsatz von DSP`s ? Wo liegen die Grenzen aktueller Mehrkernprozessoren ? Wer kennt entsprechende Anwendungen, Projekte, Vergleiche ?
Das ist eine akademische Betrachtungsweise. Aus Inschinörssicht sind das 2 Paar Stiefel. Die aktuelle CPU braucht ihre Infrastruktur mit entsprechenden Overhead, beim DSP ist das doch deutlich reduzierter.
In der neusten "Design & Elektronik" ist ein Atrikel zu dem Thema "Der bessere DSP? - Digitale Signalverarbeitung mit Pentium & Co." http://www.elektroniknet.de/home/design-elektronik/inhalte/2009/042009/ Haupthindernis sind die vielen unterschiedlichen PC-Prozessoren, und die Cache-Speicherverwaltung.
Die groessten Knackpunkte sind wohl beim Vergleich DSP <-> PC-Prozessor folgender: - Echtzeitfaehigkeit (Antwortzeit auf Interrupts) - Kontrollierter Ablauf von Berechnungen (eigentlich auch wieder Thema Echtzeit) - (Kein) Betriebssystem und virtuelles Memory. Beim DSP will man's, je "duemmer", aber latenzkontrollierter die Prozesse werden, eher nicht. Damit waere man auch bei der Zuverlässigkeit der Systeme (kein digitaler PID-Regler eines Flugzeugs wuerde auf einem embedded Intel mit Windows CE laufen...)
@Strubi > Damit waere man auch bei der Zuverlässigkeit der Systeme (kein digitaler > PID-Regler eines Flugzeugs wuerde auf einem embedded Intel mit Windows > CE laufen...) Sicher? Immerhin ist es ein Echtzeitbetriebssystem. http://de.wikipedia.org/wiki/Windows_CE ... Windows CE, oft auch als WinCE abgekürzt, ist eine Familie von Betriebssystemen von Microsoft für PDA und embedded Systems. Es ähnelt in der Bedienung MS-Windows für PCs, verwendet aber einen anderen Kernel. Somit funktionieren auch keine herkömmlichen Windows-Programme. CE unterstützt die Prozessorarchitekturen Intel x86, MIPS, ARM (mit Intel PXA) und Hitachi SuperH. Es handelt sich in der letzten Version (Windows CE 6.0) um ein Echtzeitbetriebssystem. ... Von den CPUs her würde ich kein Problem sehen. Die Interrupt antwortzeiten sollten auch ermittelbar sind. Mit Cache kann es ja bloss schneller werden. Auch ein virtuelles Memory spricht nicht unbedingt dagegen, weil man auch dort speicher anfordern kann der NIE ausgelagert wird. Das Hauptproblem ist die Software, entweder macht man alles ohne BS was sehr aufwendig ist, oder man verlässt sich eben auf das BS.
Peter: Ich wuerde mal sagen, nicht ueberall, wo 'Echtzeit' draufsteht, ist auch Echtzeit fuer jedermann drin. Manche Anwendungen erfordern eine Antwortzeit im Bereich von Nanosekunden und eine garantierte Abarbeitung binnen einer gewissen Zeit. Caches machen die Sache schon schneller, aber weniger deterministisch (vergroessern also den Jitter). Beim DSP-Hybriden Blackfin z.B. hast Du eine sehr genaue Kontrolle darueber, wo Caches aktiv sind, wo der Code ablaeuft, usw. Die hast Du z.B bei einem i86 rein von der Architektur her nicht. Kann schon sein, dass neuere Versionen von WindowsCE in die richtige Richtung laufen und einzelne Prozesse das System nicht blockieren. Leider hatte ich bisher mit der Code-Qualitaet von Windows-Kernels so meine Probleme. Nicht ohne Grund gibt es 'echte' Echtzeitsysteme wie RTEMS oder die Xenomai-Erweiterungen fuer uClinux... Aber auch diese bieten bestenfalls Latenzzeiten ueber 500nS und einen gewissen Jitter, allerdings auch die Garantie, dass ein Echtzeitprozess binnen einer wohldefinierten Zeitspanne ans Ruder darf. Wers genauer braucht, muss eben zum DSP greifen und sein 'OS' selber schreiben. Und genau dafuer sind die Dinger ja auch da.. Gruss, - Strubi
Naja normale CPUs haben eh DSP-Einheiten zB Floatingpoint Units und die SSEx Befehlssätze usw sind nur rein für Signal/ Multimediadaten entworfen worden. Aber das Problem ist die Architekturen von CPUs (Superskalar, benötigen externes Hühnerfutter und ein Know How bei den Entwicklern) -> zu teuer/ zu oversized. Außerdem sind manchmal kleine DSP/DSC oder Hybriden besser wegen der Ausfallsicherheit, Energieverbrauch usw. MFG Patrick
>Ich wuerde mal sagen, nicht ueberall, wo 'Echtzeit' draufsteht, ist auch >Echtzeit fuer jedermann drin. Manche Anwendungen erfordern eine >Antwortzeit im Bereich von Nanosekunden und eine garantierte Abarbeitung >binnen einer gewissen Zeit. Wann werden die Leute endlich kapieren, was der Begriff "Echtzeisystem" bedeutet? Die Definition für Echtzeitsystem ist nicht Schnelligkeit, sondern garantierte Antwortzeit. Ein Echzeitsystem kann auch eine Antwortzeit von einer Stunde haben, wenn es deterministisch nach einer Stunde antwortet.
> > Wann werden die Leute endlich kapieren, was der Begriff "Echtzeisystem" > bedeutet? > > Die Definition für Echtzeitsystem ist nicht Schnelligkeit, sondern > garantierte Antwortzeit. Ein Echzeitsystem kann auch eine Antwortzeit > von einer Stunde haben, wenn es deterministisch nach einer Stunde > antwortet. Genau das wurde ja schon gesagt. Nur bringt ein Echtzeitsystem mit einer langen Antwortzeit eben keinem was. Der Originalposter wollte schliesslich implizit wissen, warum man fuer gewisse Zwecke DSPs einsetzt, und keine (embedded) Windows- oder Linux-PCs.
DSPs lohnen sich dann, wenn schnelle Echtzeit (→ Motorsteuerung), geringer Energieverbrauch des Gesamtsystems (→ MP3-Player), wenig Platzbedarf (→ Handy) oder niedrige Kosten in Massenproduktion (→ Video-Player) gefordert sind. Bei vielen Laboranwendungen ist das nicht der Fall, da werden FPGAs oder DSPs allenfalls für die Datenerfassung und -vorverarbeitung (Downsampling) verwendet, für die eigentliche Rechenarbeit ist der PC günstiger.
Deswegen gibts auch Soft und Hard - RTS! Hard-RTS muss eine Antwort nach eine bestimmten Zeit geben! WinCE 6.0 gehört zu den Hard-RTOS dazu! WinCE6.0 ist wirklcih sehr fein, hab jahre lang mit Linux gewerkelt, hab dann Kunden bedingt auf Win CE6.0 umsteigen müssen (anfangs gewehrt) jetzt bin ich sehr überzeugt davon und verwende je nachdem was der Kunde braucht bzw. wünscht Linux oder WinCE dort hin wos gewünscht wird, wenn um RTOS geht empfehle ich (außer man hat viel Geld) WinCE6.0. lg
Und wenn man etwas wirklich Professionelles haben will, nimmt man VxWorks.
... und wenn man wirklich harte Echtzeit realisieren will, nimmt man gar kein OS. Beispiel: Wir haben in 2004 mal ein MP3-Radio entwickelt, das aus einem DVB-C-Kanal mit Daten versorgt wurde. Neben 300 tausend (!) Interrupts pro Sekunde vom DVB-Frontend haben wir den MP3-Decoder und das User-Interface auf einem 100MHz-DSP realisiert, der knapp 500mW Verlustleistung (TMS320C5409) hatte und nicht einmal externen Speicher brauchte. Der Code war in C geschrieben (Ausnahme die Interrupt-Routine, die die Daten vom DVB-Empfänger entgegen nahm). Mit einem PC-Prozessor geht das natürlich auch, aber zu welchem Preis? Gruß, Andreas
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.