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