www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Leistungsfähigkeit aktueller CPU's gegenüber DSP's


Autor: Hans-Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
Haupthindernis sind die vielen unterschiedlichen PC-Prozessoren, und die 
Cache-Speicherverwaltung.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...)

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: baku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>
> 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.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, können CPUs bit-reversed addressing? :-)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn man etwas wirklich Professionelles haben will, nimmt man 
VxWorks.

Autor: Andreas Bayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.