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.
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
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
Torben G. schrieb: > warum braucht man überhaupt Arbeitsspeicher? Ich dachte, die > Teile sind extra darauf ausgelegt weil es Anwendungen gibt, bei denen man etwas mehr, als nur ein Sample gleichzeitig sehen möchte :-) Hier ist etwas Literatur: Beitrag "Oberwellen / Harmonische hinzufügen" Beitrag "Audio Equalizer" Beitrag "Röhrenklang nachbilden" Beitrag "Audio Effekte wie Hall, Echo, Flanger, Equalizer, usw Wie funktioniert das?" Beitrag "Chorus Effekt" Beitrag "Simples Delay erzeugen" Beitrag "Echo programmieren" Beitrag "Stereosignal: Monosignal "heraustrennen"" Beitrag "Dynamikkompression"
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.
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
@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.
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
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!
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.
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.
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
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.
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...
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?
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
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.
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.
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
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.