Hallo, ich möchte ein kleines System für Audio Effekte aufbauen. Es geht in erster Linie um ein Delay, wofür ich einen Codec (I2S) und zusätzlichen RAM (vermutlich SPI) an Pherepherie benötige, ist ja mehr oder weniger nur Bitschieberei. Dazu reicht ein dsPIC sicherlich aus, aber wie sieht es mit rechenaufwendigeren Effekten wie z.B. Chorus oder Hall aus, reicht da der PIC auch noch oder sollte man dafür schon auf STM32 oder ähnliches gehen, vor allem wenn man 24 Bit haben möchte? Vielen Dank und viele Grüße Axel
Moin, Ich kenn' dsPICs nicht, aber grad' les' ich, dass der Compiler Geld kostet. Wuerd' ich freiwillig nicht nehmen. SPI-angebundenes RAM wuerde ich auch niemals nehmen. Kann mir nicht vorstellen, dass das irgendwie performant wird. Fuer Chorus und Hall wirds nicht so viel Rechenpower brauchen. Irgendso'n STM32 sollte das schon hinkriegen, jenachdem wie lange die Verzoegerungen werden sollen evtl. auch mit dem OnChip-RAM. Gruss WK
Hallo, das der STM32 das schafft glaube ich wohl auch, aber die Frage ist mehr ob ein dsPIC ebenfalls dazu geeignet ist. Ich habe bisher mit beiden noch nicht gearbeitet und nach allem was ich bisher gelesen habe ist der dsPIC wohl etwas umgänglicher wenn man aus dem 8Bit Bereich kommt und außerdem in moderateren Gehäusen erhältlich. Was mir nur etwas Sorgen macht ist, dass es ein 16 Bit Controller ist, ich aber gerne 24 Bit Audio Daten verarbeiten möchte. Und, warum soll der Compiler Geld kosten, es gibt doch Freeware, dann halt ohne Optimierung. Soll nach allem was ich gelesen habe aber noch ganz adäquat sein. Grüße Axel
Rechne dir einmal Speicherbedarf und -Durchsatz aus, dann wirst du sehr schnell merken, dass du mit irgendeinem gängigen SPI-SRAM nicht sehr weit kommen wirst...
Dergute W. schrieb: > Ich kenn' dsPICs nicht, aber grad' les' ich, dass der Compiler Geld > kostet. Wuerd' ich freiwillig nicht nehmen. Die Pro Version kostet Geld. Den Compiler selber bekommst Du wie alles andere kostenlos bei Microchip. Der dsPIC ist keine schlechte Wahl, aber die DSP-Einheit wird nur über Intrinsics vom Compiler unterstützt. Gehe davon aus, dass Du die maximale Leistung nur in Assembler bekommen wirst, ähnlich zB wie beim DSP56002 und dessen Nachfolgern. C kennt halt so keine verschiedenen Adressräume (P,X,Y). Das betrifft aber wirklich nur die Rechenroutinen, die einen vergleichsweise kleinen Anteil am gesamten Programmcode haben. Es gibt dsPICs mit bis zu 96k SRAM eingebaut. Schau, ob Du wirklich SPI-RAM brauchst. fchk
Moin, Ist halt meine Sicht der Dinge: Wenn ich waehlen muss zwischen einer Platform, fuer die der gcc schon seit Jahrzehnten Code erzeugt, und die auch tatsaechlich von vielen Leuten verwendet wird und einem Exoten, wo mir auf Anhieb nicht klar ist, wie krueppelig die Crippleware ist, die's umsonst vom Hersteller gibt...hmm....also da hab' ich halt schon meine Praeferenzen. Die freie libc, die hier im DsPIC Artikel erwaehnt wird, scheint mir auch seit >10 Jahren tot zu sein. Natuerlich gibts daneben noch viele wichtige andere Punkte, wie z.b. Beschaffbarkeit/Preis von Chips und EvalBoards, Verarbeitbarkeit der Chips, etc. bla. Und auch nicht zu vergessen: Der Religionskrieg zwischen AVR,PIC und ARM. Da muss man natuerlich an den "einzig richtigen" glauben :-D Aber voellig platformagnostisch: Das mit SPI-Ram wird nix. Das muss mit internem RAM gehen oder einem angeflanschten RAM ueber einen Parallelbus. Also "normales" SRAM, SDRAM, etc. Gruss WK
Ja, das mit dem SPI Ram sehe ich ein, aber der interne wird für Delay Zeiten von 1s auch nicht reichen. Dann muss ich wohl schauen was es alternativ noch gibt. Ich bin zwar gläubig aber nicht religiös;-) und wenn dann ohnehin ein 8 Bit AVR Kind, von daher wäre eh eine Konversion angesagt... Bleibt noch die Frage bezüglich der Rechenpower wegen der 16 Bit Architektur der dsPIC und der 24 Bit Audiodaten. Oder sollte das in Assembler funktionieren? Grüße und Dank Axel
Axel schrieb: > Ich habe bisher mit beiden noch nicht gearbeitet Dann solltest Du das nehmen, wo Du Dir sicher bist, dass Du Dich nicht unnötig in das falsche System einarbeitest. > und nach allem was ich > bisher gelesen habe ist der dsPIC wohl etwas umgänglicher wenn man aus > dem 8Bit Bereich kommt Da ist wahrscheinlich was dran. Das solltest Du aber nicht überbewerten. Die Einschätzung bekommst Du z.B. von PIC-Programmierern, die Ihre Entscheidung auch vor sich selbst immer wieder rechtfertigen. Auch der STM32 ist weit verbreitet und gut dokumentiert. Wegen der Gehäuse: Es gibt "minimum system boards" und "Nucleo-Boards" zwischen 3..15€. Frage einen STM32-Programmierer, der wird vielleicht den STM32 etwas umgänglicher finden. Mein Vorschlag: Ich würde an Deiner Stelle im Forum nach Fakten fragen und auf den eigenen Bauch statt auf fremde Ratschläge hören.
:
Bearbeitet durch User
Torsten C. schrieb: > Dann solltest Du das nehmen, wo Du Dir sicher bist, dass Du Dich nicht > unnötig in das falsche System einarbeitest. Genau das ist ja der schwierige Punkt. Wie kann man sich sicher sein wenn man beide Systeme nicht kennt. Pro's und Con's findet man für beide haufenweise. Habe eben für 25 Euro das Buch: Handbuch PIC24/dsPIC-Mikrocontroller erstanden. Werde mir das mal in Ruhe ansehen....
Alternativ wäre vielleicht ein DSP in Betracht zu ziehen: http://www.freedsp.cc/ Ich finde allerdings nicht auf Anhieb, wieviel Speicher (RAM/Flash) verfügbar ist. Kalle
Also, ich verwende ein STM32F7 Discovery um Audioeffekte zu programmieren. Es hat alles drauf, was man benötigt (STM32F7 mit FloatingPoint, 8 MB SDRAM, 16 MB ext. Flash, Stereo Line In/Out, 480x272 Touch-Display. Gut, es ist nicht sinnvoll mit Batterie zu betreiben, aber um die Effekte auszuprobieren ganz gut. Bin z.Zt. dabei einen Looper mit synchronisierten Drum-Computer zu programmieren + Gitarren-Effekte. Bei den Beispielprogrammen gibt es ein FullDuplex Audio In/Out Beispiel. Das habe ich genommen und modifiziert, so spart man sich die u.U. nicht gerade einfache Initialisierung.
Wer? Ich arbeite unter Linux mit arm-gcc und Makefiles + Editor nach Wahl.
Axel schrieb: > Wie kann man sich sicher sein > wenn man beide Systeme nicht kennt. Ich will mich nicht in die STM32- oder ARM®Cortex™-Promoter-Ecke stellen; Du selbst warst es, der schrieb: > das der STM32 das schafft glaube ich wohl auch Kalle schrieb: > Alternativ wäre vielleicht ein DSP in Betracht zu ziehen @Axel: Wenn Du Dich eh einarbeiten musst, würde ich wählen: ❶ Du willst zukünftig noch mehr in Richtung Audio oder gar Video machen, dann mach was mit DSP und/oder FPGA und lerne mit diesen Toolketten umzugehen. ❷ Audio-Effekte sind eher ein Schmankerl. Zukünftige Projekte gehen in andere Richtungen, dann lerne für eine 'normale' µC-Familie, die Du voraussichtlich auch in 3..7 Jahren noch nutzen kannst. Außer STM32 gibt es noch andere zukunftssichere und gut dokumentierte Familien. Und außer Cortex gibt es noch andere zukunftssichere und gut dokumentierte Cores. @All: Oder? Für mich persönlich ist ein kostenloses Source-Level-Debugging wichtig, daher mache ich z.B. wenig mit AVR.
:
Bearbeitet durch User
Kalle schrieb: > Ich finde allerdings nicht auf Anhieb, wieviel Speicher (RAM/Flash) > verfügbar ist. Hm... scheint nicht so viel zu sein. Habe im Datenblatt was von 2k Word RAM gelesen -> http://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1701.pdf S.30. Aber das SigmaStudio schaut nett aus. Axel schrieb: > ich möchte ein kleines System für Audio Effekte aufbauen. Da denke ich sind Cortex-M4 Cores gar nicht schlecht, da man damit sowohl sehr schön Audio Effekte programmieren kann aber auch viele andere Dinge. Die dsPICs und besonders "echte" DSPs (wie der ADAU1701) sind da wesentlich spezieller.
Torsten C. schrieb: > Für mich persönlich ist ein kostenloses Source-Level-Debugging wichtig, > daher mache ich z.B. wenig mit AVR. Kann das Atmel-Studio kein Source-Level-Debugging? Dachte, gerade hier wäre das Atmel-Studio toll, da alles fertig konfiguriert Out-of-The-Box kommt.
klausr schrieb: > Kann das Atmel-Studio kein Source-Level-Debugging? Dieses Detail über meine persönliche Sichtweise wollte ich zunächst nicht vertiefen, weil es hier OT ist. Ich benutze Atmel-Studio ausschließlich mit AVR-Dragon und Source-Level-Debugging. Erstes "Aber": Ich benutze keine Arduino-Libs; fast alle nutzen Arduino-Libs und machen Serial.print()-Debugging. Zweites "Aber": Ich arbeite gern so, dass sich eine Arduino-lose Open-Source-Gemeinde bilden könnte, die ohne teuren AVR-Dragon & Co. mitarbeiten könnte. Ein ST-Link z.B. kostet unter 3€. BTT: Unabhängig davon, ob Axel einen dsPIC oder was anderes nimmt, er sollte immer eine IDE und eine Toolkette mit Source-Level-Debugger nutzen.
:
Bearbeitet durch User
Eure Einwände bezüglich der umfangreichen Möglichkeiten eines Cortex-M4 oder ähnlichem die weit über den Anforderungen des Projektes liegen habe ich auch bereits bedacht. Und sicherlich ist es super in einem System eingearbeitet zu sein, wo sich viele andere Dinge mit realisieren lassen. Aber, hier geht es zunächst nur um diese Projektarbeit mit einem Zeitfenster von ca. 4-5 Monaten inkl. Hardware Entwurf. Und außer der erwähnten Audio Effekte wird der Prozessor nicht viel zu tun bekommen, höchstens noch ein kleines Display ansteuern.
Axel schrieb: > Aber, hier geht es zunächst nur um diese Projektarbeit mit einem > Zeitfenster von ca. 4-5 Monaten inkl. Hardware Entwurf. Aha. Man vergisst, sowas in den Ursprungs-Post zu schreiben. Das ist bei Weitem nicht das erse Mal; und es ist menschlich. Die Frage ist also: "Mit welchem System (µC-Familie + Toolkette) kann ich das Problem incl. Einlernphase am effizientesten lösen?" Ich habe vor über 20 Jahren fast das Gleiche als Diplomarbeit gemacht und würde mit genau dieser ^^ Fragestellung (neuer Thread?) die aktuellen Erfahrungen aus dem Forum absaugen. Bei mir war es damals ein Motorola DSP 56001 mit GNU-C-Compiler, aber das ist lange her …
:
Bearbeitet durch User
Torsten C. schrieb: > Ich benutze Atmel-Studio > ausschließlich mit AVR-Dragon und Source-Level-Debugging. > > Erstes "Aber": Ich benutze keine Arduino-Libs; fast alle nutzen > Arduino-Libs und machen Serial.print()-Debugging. Ach so. Ich bin inzwischen so in der "ARM"-Welt mit dem omnipräsenten SWD angekommen, dass ich leicht vergesse, dass viele bei AVRs "nur" einen Programmer haben. Wo bei ich das printf-Debugging gut kenne, da vor ca. 30 Jahren, als ich C lernte, das Source-Level-Debugging eben nicht so präsent war. Im Übrigen heißt gcc+makefile nicht, dass ohne debugger gearbeitet wird: Ich tippe dann halt nur "make debug" bzw. den Hotkey im Editor.
Ok, sorry wenn nicht genau genug ausgedrückt. Aber immerhin habe ich gefragt ob ein dsPIC reicht, oder ob man auf ein größeres Schiff springen muss.
Axel schrieb: > … ob ein dsPIC reicht, oder ob man auf ein größeres Schiff springen muss. Dergute W. schrieb: > SPI-angebundenes RAM würde ich auch niemals nehmen. Ich auch nicht. Dergute W. schrieb: > Kann mir nicht vorstellen, dass das irgendwie performant wird. Ich auch nicht. > Fuer Chorus und Hall wirds nicht so viel Rechenpower brauchen. > Irgendso'n STM32 sollte das schon hinkriegen, jenachdem wie lange die > Verzögerungen werden sollen evtl. auch mit dem OnChip-RAM. @Axel: Das denke ich zwar auch, poste aber lieber, wie lang die Verzögerungen werden sollen und auch alle übrigen Anforderungen! … oder gehe "auf Nummer Sicher" und nehme nicht den dsPIC. … oder warte, bis sich jemand meldet, der Dir bestätigt, dass ein dsPIC ausreichend ist. Die Zeit geht aber von Deinen "ca. 4-5 Monaten inkl. Hardware Entwurf" ab. Überzeuge Deinen Assi(?) bzw. Deinen Chef(?). klausr schrieb: > Im Übrigen heißt gcc+makefile nicht, dass ohne debugger gearbeitet wird Stimmt. Passt! Nerviger, aber geht auch! :-)
:
Bearbeitet durch User
Verzögerung soll mindestens 2 Sekunden Mono sein. Soll mit Codec und RAM möglichst kompaktes Layout, am besten 2 lagig ergeben. ... möchte eigentlich bis zum WE eine Entscheidung getroffen haben auf welches System ich setzen werde. Grundlage dafür ist sicherlich nicht nur dieser Thread, aber dennoch freue ich mich natürlich über jeden Hinweis. Der Dschungel ist halt mächtig groß...
Axel schrieb: > Grundlage dafür ist sicherlich nicht nur dieser Thread Etwas mehr Respekt, Bitte! ;-) Axel schrieb: > Verzögerung soll mindestens 2 Sekunden Mono sein. Mit ~44KHz (ich hoffe, ich habe nichts übersehen)?
:
Bearbeitet durch User
Torsten C. schrieb: >> Grundlage dafür ist sicherlich nicht nur dieser Thread > Etwas mehr Respekt, Bitte! ;-) Au man, wenn ich jetzt geschrieben hätte dass ich mich voll und ganz auf euere Kompetenz verlasse, würde ich jetzt zerstückelt und als faule S... betitelt werden;-) Dabei freue ich mich schon die ganze Zeit über die tolle sachliche Diskussion, habe ich hier im Forum leider auch schon anders erlebt.
klausr schrieb: > Also, ich verwende ein STM32F7 Discovery um Audioeffekte zu > programmieren. Das klingt nach einem guten Plan.
Habe ich mir auch bereits angesehn und steht mit auf meiner Liste.
Axel schrieb: > Verzögerung soll mindestens 2 Sekunden Mono sein. Na, endlich mal eine Ansage. Du solltest mit a) mind. 16 bit und b) mind 32 kHz Sampling Rate arbeiten. Macht dann 64000 Byte RAM. Evtl. reichen dann auch 64kByte (=65536 Byte). Mir wäre es zu knapp, da man ja auch IO-Buffer braucht -> Einer kommt per DMA rein, der zweite wird bearbeitet und der dritte geht wieder per DMA raus. Ich arbeite mit 256 16-bit-Samples-Buffer, d.h. ein Buffer ist 5,8 ms lang. Macht eine Latenz von 11,6 ms. (bei 44,1 kHz). Ein schöner Prozessor ist z.B. der STM32F405RG, kostet knapp 10€ bei Digikey, 1 MB Flash, 192 kB RAM, bis zu 168 MHz,i2s oder interne 12bit AD und DA Wandler (für die ersten Versuche durchaus ok) und das ganze im IMHO schön lötbaren 64-LQFP-Gehäuse. Kann aber kein SD-RAM. Für einen Looper oder so könnte man ein 128 MBit SPI Flash dran hängen. Dafür ist es schnell genug.
Ja der dsPIC reicht natürlich für ein Delay und auch kompliziertere Effekte. Es gibt sogar einen dsPIC mit eingebautem Audio DAC. Wenn der eingebaute AD Wandler (mit Überabtasten und Filtern) reicht brauchst du gar kein Codec. Und ein SPI-Ram reicht natürlich um Audio Daten zu verzögern. Microchips SPI RAM kann mit 20 MHz getaktet werden, selbst wenn du jedes 16 Bit Sample einzeln mit Command und Adresse schreibst und liest kommst du auf: 20'000 / (32+16) / 2 = 208 kHz für Mono. Und das im 1 Bit SPI Betrieb, die RAMs können auch Dual- und Quad SPI, aber der dsPIC wahrscheinlich nicht. Also im einfachsten Fall ein dsPIC33FJ64GP802 im DIL-28 und ein 23LC1024 SPI-RAM in DIL-8, das kannst du sogar auf einem Steckbrett aufbauen. Zusammen ~ 6.50 €. Dazu ein PICKIT 3 zum Programmieren und Debuggen. Wenn du später mit 24 oder gar 32 Bit arbeiten willst kannst du einen PIC32 nehmen. Auch im DIL Gehäuse erhältlich mit bis zu 64 kB internem RAM für Hall oder so, und mit I2S Schnittstellen für ein 24 Bit Codec. PICKIT 3 und IDE kannst du weiterverwenden. Andi übrigens: Was ist eine Toolkette? Müsste das nicht Toolchain oder Werkzeugkette heissen, aber das letztere versteht dann gar keiner mehr...
Moin, OK, also das hier: Axel schrieb: > Aber, hier geht es zunächst nur um diese Projektarbeit mit einem > Zeitfenster von ca. 4-5 Monaten inkl. Hardware Entwurf. wuerde fuer mich ganz klar nach so einem ollen Discovery-Board schreien. Ansonsten wird das in der Zeit eh' nix. Was insbesondere dann schlecht ist, wenn man am End' noch eine Note drauf bekommen soll, die sich deutlich im Abschlusszeugnis widerspiegelt. Andi schrieb: > 20'000 / (32+16) / 2 = 208 kHz Schoene Rechnung. Klappt aber nur, wenn der SPI-Master zwischendrinnen (z.b. alle 8 bit) keine Pausen macht, etc. bla. Softwaretechnisch sicher auch ein Spass, wenn Speicherzugriffe nicht atomar sind. Und selbst wenn das alles klappt, dann bedeutet 208kHz, wenn die Samples mir 48 kHz ankommen und abgehen, dass alleine fast 25% der zu Verfuegung stehenden CPU-Zeit fuer 2 popelige Speicherzugriffe versaubeutelt werden. Muss man halt moegen. klausr schrieb: > Wer? Ich arbeite unter Linux mit arm-gcc und Makefiles + Editor nach > Wahl. Haettest du da mal nen Link? Ich hab' so den Eindruck, dass es da 50 verschiedene git-repositories gibt, wo irgendwer sich mal berufen gefuehlt hat cmsis oder cube oder was weiss ich, was da grad hip ist, mit Makefiles zu versehen, so dass es ohne IDE laeuft - ich tu mir bloss grad schwer zu beurteilen, ob's was taugt oder nicht... Hatte bisher bloss mit groesseren ARMen, auf denen Linux laeuft, zu tun, bzw. FPGA. Gruss WK
>> 20'000 / (32+16) / 2 = 208 kHz >Schoene Rechnung. Klappt aber nur, wenn der SPI-Master zwischendrinnen >(z.b. alle 8 bit) keine Pausen macht, etc. bla. Softwaretechnisch sicher >auch ein Spass, wenn Speicherzugriffe nicht atomar sind. >Und selbst wenn das alles klappt, dann bedeutet 208kHz, wenn die Samples >mir 48 kHz ankommen und abgehen, dass alleine fast 25% der zu Verfuegung >stehenden CPU-Zeit fuer 2 popelige Speicherzugriffe versaubeutelt >werden. Muss man halt moegen. Das bedeutet aber auch dass du 75% einer Sampleperiode für das eigentliche Signalprocessing zur Verfügung hast. Ein einfaches Delay braucht davon vielleicht 1% (eigentlich nur ein Mischen von verzögertem und direktem Signal = 1..2 Multiplikationen + Additionen). Also "versaubeutelst" du bei internem RAM etwa 99% der Zeit mit warten auf die nächste Sample Periode, und bei SPI-RAM nur 74% der Zeit ;-) Andi
ich hab jetzt nicht alles gelesen und wenn mein Rat unpassend ist, dann möchte ich mich entschuldigen. ich verwende für Audio-Experiment einen kleines netbook mit Linux drauf. Als Gerüst diente mir folgender freie Quellcode
1 | /*
|
2 | rec_play.c - Audio-Signal aufnehmen u. wiedergeben
|
3 | */
|
4 | |
5 | # include <stdio.h>
|
6 | # include <unistd.h>
|
7 | # include <fcntl.h>
|
8 | # include <sys/ioctl.h>
|
9 | # include <linux/soundcard.h>
|
10 | |
11 | # define NUM_SAMPLES 100000
|
12 | |
13 | unsigned char buffer[NUM_SAMPLES]; |
14 | |
15 | int main() |
16 | {
|
17 | int fd, i, format=AFMT_U8; |
18 | long length; |
19 | char input[16]; |
20 | |
21 | if ((fd = open("/dev/dsp", O_RDWR)) == -1) |
22 | {
|
23 | perror("rec_play: Can't open device"); |
24 | return(1); |
25 | }
|
26 | |
27 | if (ioctl(fd, SNDCTL_DSP_SETFMT, &format) == -1) |
28 | perror("rec_play: Can't set format"); |
29 | |
30 | i = 0; |
31 | if (ioctl(fd, SNDCTL_DSP_STEREO, &i) == -1) |
32 | perror("rec_play: Can't set to mono"); |
33 | |
34 | i = 22050; |
35 | if (ioctl(fd, SNDCTL_DSP_SPEED, &i) == -1) |
36 | perror("rec_play: Can't set sampling rate"); |
37 | |
38 | printf("Press <RETURN> to start recording. "); |
39 | fgets(input, 16, stdin); |
40 | |
41 | if ((length = read(fd, buffer, NUM_SAMPLES)) == -1) |
42 | {
|
43 | perror("rec_play: Can't record audio data"); |
44 | return(1); |
45 | }
|
46 | |
47 | printf("done (%ld bytes).\n" |
48 | "Press <RETURN> to start playing. ", length); |
49 | fgets(input, 16, stdin); |
50 | |
51 | if (write(fd, buffer, length) == -1) |
52 | perror("rec_play: Can't play audio data"); |
53 | |
54 | close(fd); |
55 | return(0); |
56 | }
|
Andi schrieb: > Also "versaubeutelst" du bei internem RAM etwa 99% der Zeit mit warten > auf die nächste Sample Periode, und bei SPI-RAM nur 74% der Zeit ;-) Da im Eingangsposting ja auch noch Chorus und Hall genannt sind bin ich gespannt auf die Implementierung mit max. 3 Speicherzugriffen pro Sampleperiode ;)
Andi schrieb: > Ein einfaches Delay > braucht davon vielleicht 1% (eigentlich nur ein Mischen von verzögertem > und direktem Signal = 1..2 Multiplikationen + Additionen). nö, noch nicht mal, weil ich das direkte Signal natürlich rein analog lasse und erst hinter dem DAC wieder mit dem "Echo" mische.
Axel schrieb: > nö, noch nicht mal, weil ich das direkte Signal natürlich rein analog > lasse und erst hinter dem DAC wieder mit dem "Echo" mische. Ja aber wahrscheinlich willst auch ein Feedback bei dem das gemischte Signal wieder ins Delay eingespeist wird. Kannst du natürlich auch analog machen, aber dann brauchst du eigentlich gar keinen DSP. Holger B. schrieb: > Da im Eingangsposting ja auch noch Chorus und Hall genannt sind bin ich > gespannt auf die Implementierung mit max. 3 Speicherzugriffen pro > Sampleperiode ;) Nun die 25% sind bei 48kHz Sample Rate und bereits 2 Speicherzugriffen. Bei 32 kHz, was für Hall genügt, kannst du etwa 8..10 SPI-RAM Zugriffe machen, bei Random-Adressierung und hast noch genügend Prozessorzeit übrig. Wenn du ganze Blöcke schreibst und liest natürlich noch viel mehr. Eifacher Chorus braucht nicht viel mehr als ein Delay, die Verzögerungszeit wird halt ein bisschen moduliert. Hall kann natürlich viele Speicherzugriffe benötigen, je nach Algorithmus. Aber viele der Delays sind sehr kurz und dafür hat der oben erwähnte dsPIC 16 kByte internen Speicher. Andi
Schau mal her: http://www.microchip.com/wwwproducts/en/dsPIC33EP512GP806 Der hat 53248 Byte RAM eingebaut. Wenn das nicht reicht, kannst Du über den PMP (Parallel Master Port) externes RAM anschließen. Mit Bankswitching kann das auch zB ein 256k*16Bit SRAM sein, zB 71V416S12PHG8 (http://www.digikey.de/product-detail/de/idt-integrated-device-technology-inc/71V416S12PHG8/800-1849-1-ND/1916684), und das dürfte dann reichen. Dazu kommt der DMA-Controller, der Dir im Hintergrund Daten rein- und raus schafft. Und wenn ich daran denke, was ich vor 20 Jahren mit einem DSP56002 gemacht habe, sollte sich schon einiges mit einem 70 MHz DSP machen lassen. fchk
Andi schrieb: > Ja aber wahrscheinlich willst auch ein Feedback bei dem das gemischte > Signal wieder ins Delay eingespeist wird. Kannst du natürlich auch > analog machen, aber dann brauchst du eigentlich gar keinen DSP. Für das Delay bräuchte ich sicher keinen DSP, da es dabei nur um viel Bitschieberei geht. Geplant ist, das zusammenmischen analog zu machen, da das direkte Signal durch die Wandler sicherlich nicht besser wird. Aber, wenn das System läuft, ist das sicherlich schnell getestet ob der Unterschied signifikant ist. Die DSP Rechenpower wird mehr für die Hall, Chorus, Phaser Geschichten benötigt. Das Delay braucht einfach nur schnellen Speicher (Zugriff)
@ Frank, danke für die Links. Ich habe eh gerade die Tabelle von Micrchip mit den ganzen verschiedenen 16 Bit Typen auf dem Bildschirm. Was ich noch nicht ganz verstehe ist der Unterschied bei den dsPIC33 zwischen den E und F Typen. ???
Ich weiß nicht wer das geschrieben hatte mit dem stm32f7 board aber der line in und line out sind nicht! gleichzeitig nutzbar. Nur die Mikrofone auf der PCB und der lineout sind gleichzeitig nutzbar! Ich habe das selber mal ausprobiert und nicht hin bekommen. Nach etwas Recherche hängt das damit zusammen dass tdm genutzt wird mit den Signalen auf verschiedenen timeslots und es war irgendwie nicht möglich weil der line out und line in auf den gleichen fallen was der codec nicht kann der da drauf sitzt. Da gibts irgendwo nen thread dazu im stm32 forum. Ich selber mache auch grad ein DSP Projekt mit stm 32f4 mit 4 in 4 out. Habe aktuell 8 iir filter laufen mit 44,1khz und 24 Bit erzeugt ca 30% cpu last wenn man die Anzahl der Takte zählt die es für die filter braucht und es in Anbetracht der Gesamtzahl der zur Verfügung stehenden Takte nimmt.
Vielen Dank für die ganzen Hinweise, Infos und Ideen! Ich habe mich entschieden die Arbeit mit einem dsPIC zu machen. Viele Grüße Axel
Axel schrieb: > Ich habe mich entschieden die Arbeit mit einem dsPIC zu machen. Es wäre nett, wenn Du am Ende noch vom Ergebnis und Deinen Erfahrungen berichten könntest. Andere interessiert das sicher auch. Was mich betrifft: Das mit dem DSP56001 ist lange her, und den dsPIC habe ich noch nie verwendet.
So mein Senf auch noch. Also in Assembler lassen die sich superst programmieren! PORTS, OSC, SPLIM-Register, CORCON-Register und los gehts. Übrigens ich hab den DSPIC33FJ64GP802 bei 45 mips laufen. Werner
Torsten C. schrieb: > Es wäre nett, wenn Du am Ende noch vom Ergebnis und Deinen Erfahrungen > berichten könntest. Andere interessiert das sicher auch. Hallo, so nach einigen Wochen laufen die Programme / Sounds soweit. Nun kann ich meine Anfangsfrage auch selbst beantworten: Ja, der dsPIC reicht für viele Audio Effekte. Chorus Phaser Flanger / Echo sind gar kein Problem, sogar mehrstimmige Chorus gehen noch gut. Beim Hall scheiden sich die Geister. Natürlich sind einfache Hall - Effekte problemlos möglich, jedoch gibt es mächtige Varianten von Hall-Effekten mit bis zu 4,5 sec Verzögerungszeiten, da wird es wohl schwierig, jedoch ist das auch nicht Bestandteil meiner Arbeit. Habe größtenteils alles in C geschrieben, nur wo es mal schneller werden sollte auf Inline ASM zurück gegriffen, da die Code-Optimierung in der Freeware Version doch noch Reserven nach oben offen lässt. ( Ist ja auch verständlich wenn man seine Dongles verkaufen will..) Grüße Axel
Hallo, ich möchte mit dem STM32F746 Discovery Audioeffekte wie Federhall, Echo usw. programmieren. Auch z.B. eine schnelle Faltung mit einer Lautsprecherimpulsantwort. Kann mir jemand ein lauffähiges Programmgerüst überlassen? Ich bin per EMAIL über haweneu@web.de zu erreichen. Gruss Werner
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.