mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Signal für DSP?


Autor: Torben G. (nudrun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey!
Ja, die Frage mag euch dumm erscheinen, aber sie ist ernst gemeint. Ich 
komme aus der Mathematikecke und würde mich gerne auch mal an den 
Transformationen und Filtern versuchen. Zum Spielen möchte ich mir einen 
dsPIC bestellen, die sind ja recht günstig und auch für Menschen mit 
zittrigen Händen geeignet. Mir stellt sich nur die Frage, WAS ich denn 
filtern und transformieren kann. Sprut benutzt die für Modellflieger - 
kann ich nicht. Jemand anderes benutzt die zum Funken - darf ich nicht. 
Die einzigen "sinnvollen" Zwecke, die ich bisher fand, sind Bild- und 
Tonbearbeitung, aber das dürfte am Anfang doch etwas schwer sein.
Vielen Dank für alle hilfreichen Antworten.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tonverarbeitung ist nicht schwierig, gut dokumentiert für so gut wie 
alle DSPs und man kann z.B. Filter sofort anhören.
Das einzige notwendige I/O ist dann ein guter Audio Codec und evtl. je 
nach Board RAM für die Audiobuffer.

http://www.musicdsp.org

: Bearbeitet durch User
Autor: Torben G. (nudrun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> [...] Das einzige notwendige I/O ist dann ein guter Audio Codec und evtl. je
> nach Board RAM für die Audiobuffer.

Ich kann also einfach ein Kopfhörerkabel von meinem Smartphone an einen 
Eingang stecken? Das ist cool.
Wie viel RAM braucht man da so und warum braucht man überhaupt 
Arbeitsspeicher? Ich dachte, die Teile sind extra darauf ausgelegt, 
sofort Datenströme zu verarbeiten.
Viele Grüße

: Bearbeitet durch User
Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Torben G. (nudrun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke! Da habe ich was zu tun ;-)

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torben G. schrieb:
> Ich kann also einfach ein Kopfhörerkabel von meinem Smartphone an einen
> Eingang stecken? Das ist cool.

Das kann ich dir nicht sagen. Smartphones sind vollgestopft mit 
Taktfrequenzen und Hochfrequenzschaltungen und eignen sich nur bedingt 
als gut klingende Signalquellen.

Als portable Quelle nehme ich einen dafür geeigneten MP3 Player. So kann 
ich auch telefonieren, wenn die Anordnung gerade getestet wird.

Torben G. schrieb:
> Wie viel RAM braucht man da so und warum braucht man überhaupt
> Arbeitsspeicher? Ich dachte, die Teile sind extra darauf ausgelegt,
> sofort Datenströme zu verarbeiten.

Da sind sie. Aber viele Anwendungen wollen auf alte Samples 
zurückgreifen, wie z.B. Echo und Delay Programme - ausserdem muss der 
Code irgendwo liegen. Moderne Consumer DSP haben ihre Programme oft in 
einem externen EEPROM, das beim Booten in den DSP geladen wird, manche 
haben auch internen RAM. Wieviel man da braucht, hängt von z.B. der 
gewünschten Delayzeit oder der Länge des Echos ab, wobei die Samplerate 
entscheidet, wieviel benutzt wird. Z.B. bei 48kHz Rate und 16-bit 
Qualität braucht man pro Sekunde 48000 Zellen 16-Bit Speicher.

Mein kleines Versuchssystem mit dem TMS32C025 Dinosaurier hat z.B. 
128kWord Speicher, was schon für ein paar nette Effekte reicht. Das kann 
man mit heutigen Maschinen aber nicht vergleichen - jedes OMAP Eval 
Board von TI schlägt das um Längen.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torben G. schrieb:
> Zum Spielen möchte ich mir einen
> dsPIC bestellen, die sind ja recht günstig und auch für Menschen mit
> zittrigen Händen geeignet.

Warum? Das kann man doch alles auf dem PC machen. Als Input tuts jeder 
Audiofile oder die Soundkarte, die auch als Output prima funktioniert. 
Speicher und Rechenleistung gibts ohne Ende und der Debugger ist 
mächtig. Tools wie audacity bekommt man noch kostenlos dazu.

MfG Klaus

Autor: Torben G. (nudrun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klaus Ich glaube, du hast mich nicht verstanden. Mir geht es nicht um 
Tonverarbeitung, mir geht es um die Programmierung von 
Filteralgorithmen, am liebsten in Assembler. Was die am Ende filtern, 
und realitätsnaher Quatsch wie Sinn und Praktikabilität, ist mir 
gleichgültig.
Außerdem wollte ich sowieso mal 16b-Assembler programmieren, und die 
dsPics habengute Ausstattung (z.B. DAC) und laufen auf 3,3V, was ganz 
nett ist, weil man die dann direkt an den Raspberry Pi anschließen kann.
Trotzdem danke, ginge es um Tonverarbeitung, hättest du sicher recht.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torben G. schrieb:
> Mir geht es nicht um
> Tonverarbeitung, mir geht es um die Programmierung von
> Filteralgorithmen,

Mir auch. In einem 32 oder auch 64 Bit Umfeld lässt sich alles viel 
leichter und übersichtlicher realisieren als auf einem 16-Bitter. Man 
ist z.B. nicht die ganze Zeit damit beschäftigt, Over- oder Underflows 
hinterherzuprogrammieren. Und man kann das Ganze in C machen, da lernt 
man was, das sich eigentlich auf jedem Rechner weiterverwenden lässt. 
Man kann auch ohne Mühe Floating Point benutzen, ohne einen anderen 
Prozessor nehmen zu müssen.

Dazu kommen Tools wie audacity oder auch Mathlab, mit denen man die 
Ergebnisse der eigenen Programme analysieren kann, oder die einem 
zeigen, wie es besser gehen kann.

MfG Klaus

Autor: Audiomann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Dazu kommen Tools wie audacity oder auch Mathlab

Mathlab hätte Ich auch gerne, leider habe Ich nur MATLAB, so ein Pech.

Und audacity als Analyseprogramm hinzustellen, würde Ich mal als "kühn" 
bezeichnen!

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torben G. schrieb:
> mir geht es um die Programmierung von
> Filteralgorithmen, am liebsten in Assembler. Was die am Ende filtern,
> und realitätsnaher Quatsch wie Sinn und Praktikabilität, ist mir
> gleichgültig.

Wieso nimmst du dann einen DSP? Du könntest ja auch gleich alles auf dem 
PC simulieren.
Sorry, meine Schuld, mein Hirn hat sofort wieder überlegt was sinnvoll 
und praktikabel wäre, ich kann's einfach nicht lassen.

Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht also wirklich nur um die Herausforderung?

Vor 20 Jahren hätte Ich noch gesagt, dass es ein lohnendes Ziel sein 
könnte, zu erlernen, Filter in ASM zu programmieren, aber heute ist das 
wohl nicht so wirklich mehr zielführend. Es gibt eigentlich kaum noch 
8-bitter im Einsatz, die wirklich relevant viel tun müssen, allenfalls 
langsam irgendwo Temperaturen auslesen. Denen könnte man noch etwas 
Filterung verpassen, aber sonst sind selbst Billig-CPUs in der Lage, mit 
einem C-Compilat effektiv zu arbeiten.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Vor 20 Jahren hätte Ich noch gesagt, dass es ein lohnendes Ziel sein
> könnte, zu erlernen, Filter in ASM zu programmieren, aber heute ist das
> wohl nicht so wirklich mehr zielführend.

ACK

MfG Klaus

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moderne DSP mit Pipeline und gleichzeitiger Ausführung von 5 Befehlen 
(hatte hier einen TAS3108 von TI) sind wirklich nicht mehr sinnvoll in 
ASM zu programmieren, ACK.

Wobei der TMS32C025 von meinem Projekt da oben in ASM durchaus noch 
Spass macht. Da gab es viele Tipps aus Funkerkreisen und von 
musicdsp.org, so das ich damit 'ne Menge über DSP und Algorithmen für 
die Dinger lernen konnte.

Allerdings war da auch mehr der Weg das Ziel, also die Platine und den 
Codec aufzubauen, den Boardcontroller zu programmieren etc. pp. Richtig 
produktiv angewandt habe ich das Dings nie.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Moderne DSP mit Pipeline und gleichzeitiger Ausführung von 5 Befehlen
> (hatte hier einen TAS3108 von TI) sind wirklich nicht mehr sinnvoll in
> ASM zu programmieren, ACK.

Moment!

Moderne DSPs muss man nach wie vor in Assembler programmieren, da der 
C-Compiler in den seltensten Fällen in der Lage ist, die korrekte 
Arithmetik und den Rundungs-Mode zu erraten, ganz zu schweigen von 
optimaler Ausnutzung der Parallelbefehle. Aber das macht man 
typischerweise nur für ein kleines funclet (innere Schleife), und bei 
einigen DSPs liest sich das schon wie C-Code, siehe Blackfin-Assembly.
Durch effiziente Nutzung der Pipeline holt man da schon mal gegenüber C 
einen Faktor 20 in der Geschwindigkeit raus, wie z.B. bei 
JPEG-Kompression.

Wenn's nur ums Lernen und Konzentrieren auf die DSP-Innereien geht: Ein 
Simulator wie skyeye macht auch Spass...

Autor: Torben G. (nudrun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich melde mich nun auch mal wieder zurück.
@Andi Tja, typischer Anfängerfehler... Nein, jetzt mal Spaß beiseite, 
bin ich wirklich der einzige, der die Beschränkungen eines MCU attraktiv 
findet? Und kann es sein, dass du im falschen Forum zu Gast bist?
@engineer Naja, während ich mit C nie wirklich warm wurde, machen mir 
Spielereien mit Assembler Spaß. Und was die Tätigkeit angeht: Dazu habe 
ich ja diesen Thread erstellt! Klar, um den Mittelwert aus den Werten 
eines Photowiderstandes zu berechnen, brauche ich wirklich keinen DSP, 
so viel habe ich verstanden...
@mschoeldgen Irgendwas in Richtung Computer in Assembler zu 
programmieren ist echt nicht lustig, wenn man die Fähigkeiten der 
Systeme auch ausreizen will. Aber auch bei mir ist eher der Weg das 
Ziel. Ihr seht, ich habe kein konkretes Projekt vor Augen, ich möchte 
einfach ein bisschen ausprobieren.
@strubi Echt, Assembler ist schneller? Bei einem Beispiel wie diesem 
hätte ich das nicht erwartet. Meine Vermutung wäre eher gewesen, dass C 
zwar schneller ist, aber Assembler bessere Ergebnisse liefert, weil der 
Compiler eben vor dem Runden nicht fragt.
Skyeye werde ich mir mal anschauen, wenn ich Zeit habe.
@Klaus ACK?

Autor: Joe F. (easylife)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
So gehe ich beim Entwickeln von Algorithmen für Mikrocontroller/DSPs 
vor:

Schritt 1: Algorithmus in C auf einem normalen PC entwickeln.
Vorteile sind: der PC ist schnell, ich kann zunächst mal floating Point 
verwenden, und habe eine Vielzahl an Tools zur Verfügung, um die 
Funktionsweise des Algorithmus auf Herz und Nieren zu testen (es können 
große Testfiles verarbeitet werden, grafische Visualisierung der 
Ergebnisse und interne Zustände möglich, z.B. über Excel oder .wav 
Files).
Megabyte große Logfiles zum Debuggen sind auch kein Problem.

Schritt 2: Algorithmus optimieren.
Nachdem ich eine funktionierende Referenzimplementierung habe, mache ich 
mir Gedanken, wie man mehr Geschwindigkeit herausholen kann, Speicher 
sparen kann, und evtl. Fixpoint statt Floatingpoint verwenden kann.
Das Ergebnis dieses Schrittes muss immer noch dem Ergebnis des 
Referenzalgorithmus entsprechen.

Schritt 3: Portieren auf Zielplattform.
Erst jetzt kommt die eigentliche Hardware ins Spiel.
Dabei ist dann egal welche Sprache hier verwendet wird. Der Algorithmus 
steht fest, und muss einfach nur portiert werden und muss das gleiche 
Ergebnis liefern, wie die in den beiden Schritten zuvor.
Da hier immer einiges schief gehen kann, ist man froh eine 
Referenzimplementierung zu haben, mit der man die Ergebnisse vergleichen 
kann. Das erleichtert das Debuggen enorm.

Gleich mit Schritt 3 anzufangen halte ich für falsch.
Gerade als Anfänger ist das Frust-Risiko sehr hoch, weil dann 
irgendetwas nicht richtig funktioniert, und man kaum Möglichkeiten hat 
dies zu debuggen.

: Bearbeitet durch User
Autor: Jürgen Schuhmacher (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe F. schrieb:
> Gleich mit Schritt 3 anzufangen halte ich für falsch.
> Gerade als Anfänger ist das Frust-Risiko sehr hoch, weil dann
> irgendetwas nicht richtig funktioniert, und man kaum Möglichkeiten hat
> dies zu debuggen.

So ist es.

Schritt1 macht man allerdings heute meist rein in Mathe und lässt sich 
das C erzeugen.

Autor: Torben G. (nudrun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joe F. schrieb:
> Gleich mit Schritt 3 anzufangen halte ich für falsch.
> Gerade als Anfänger ist das Frust-Risiko sehr hoch, weil dann
> irgendetwas nicht richtig funktioniert, und man kaum Möglichkeiten hat
> dies zu debuggen.

Je nach dem, wie kompliziert die mathematische Definition ist, würde das 
doch wohl niemand machen.

Joe F. schrieb:
> Schritt 1: Algorithmus in C auf einem normalen PC entwickeln.

Aber muss das sein? Kann ich nicht auch ein PAP zeichnen oder einen 
Algorithmus aus Formeln, die auch ein Zehntklässler verstehen kann, 
schreiben? Das lässt sich ja auch portieren.

Autor: Joe F. (easylife)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann dir nur sagen, wie es sich bei mir in der Praxis bewährt hat. 
Alles andere musst du selbst lernen/erfahren.
Jeder hat da seine eigene Herangehensweise.

: Bearbeitet durch User

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.

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