Hallo, gibt es eine (überschlägige) Formel wo man in Abhängigkeit von Samplerate, Taps usw. berechnen kann wieviel Rechenpower ein STM32F4 oder F7 bei einem FIR verbraucht? Es geht einfach darum, ich möchte per I2S einen Audiostream einlesen, ein FIR Filter darüber legen (wenn es geht so genau wie möglich) und wieder per I2S ausgeben. Wenn das ausreicht, würde ich auf einen DSP verzichten der ja ohnehin zum Initialisieren und Übergabe der Parameter auch einen externen µC benötigen würde. Eingabe/Ausgabe sollen 24bit mit 48kHz sein. Ein Mono Kanal reicht vollkommen aus. Wenn das irgendwer schonmal so gemacht hat und kann mir da eine grobe Hausnummer nennen inwieweit ein F4 oder F7 da beschäftigt ist, wäre das super. Danke schonmal!
So Formeln gibt es sicher nicht, aber abhängig von der Ordnung des
Filters kannst du ja leicht rausfinden, wie viele Multiplikationen und
wie viele Additionen du hast. Damit kannst du auch angeben, wie viele
Rechenoperationen du machen musst, pro Sekunde.
Ich würds, da es 24 Bit sein sollen, mit der FPU machen. Sie ist sehr
performant, ich hatte mal 2 Regler für 2 Antriebe damit implementiert,
wo mit 100 kHz abgetastet wurde und der STM hat nur gelacht ? es gibt
eine Appnote, wo anhand der Berechnung eines Fraktals (Juliamenge) die
Anzahl Flops der FPU angegeben wird.
Gruss!
P.S.:
> wenn es geht so genau wie möglich
ist eher eine doofe Spezifikation :-(
FIR schrieb: > STM32F4 > oder F7 Hmm soweit ich weiß, hat der F4 schon MAC-Operation in der FPU ... Der GCC verwendet die dann auch schön, ohne dass man es explizit sagen muss. Ich würde es ebenfalls mit Floats machen ... Das meiste wird in einem Taktzyklus abgearbeitet - Divisionen brauchen länger. Bei einem FIR aber kein Thema :) Mal so grob überschlagen ... 1024-tap FIR-Filter wären 1024 Multiplikatione + 1024 Additionen ... Alsos sowas 2048 Taktzyklen hätte ich jetzt gesagt ... Bei sagen wir mal 168Mhz (F4) und 48kHz hätte man zwischen den Samples um die 3500 Taktzyklen Zeit ... Bei Stereo und 2*2048 Taktzyklen würde es schon sehr eng werden. Aus diesem Grund verwende ich FIRs nur in FPGAs und IIR nur auf µCs :D Aber gut, wahrscheinlich sind deine Filter nicht so lang - da hast du aber keine Angaben gemacht. Wenn es nicht FIR sein muss, dann schau dir mal die Bi-Quad-IIR-Filter an ... Die sind mit wesentlich weniger Aufwand zu berechnen und es gibt einige gute Design-Tools online zB http://www.earlevel.com/main/2013/10/13/biquad-calculator-v2/ Muss man aber auf die Stabilität achten, da IIR nicht immer stabil sind wie FIR.
:
Bearbeitet durch User
512 taps sollten reichen. Dann könnte ich ja sogar 96kHz in Erwägung ziehen :-). Wie schon gesagt, der STM hat sonst keine weiteren Aufgaben. IIR würden den Frequenzgang vermutlich genauso hinbekommen - ich benötige aber noch lineare Phase ab sagen wir 300Hz bis zur oberen Grenze.
FIR schrieb: > 512 taps sollten reichen. Dann könnte ich ja sogar 96kHz in > Erwägung > ziehen :-). Wie schon gesagt, der STM hat sonst keine weiteren Aufgaben. > > IIR würden den Frequenzgang vermutlich genauso hinbekommen - ich > benötige aber noch lineare Phase ab sagen wir 300Hz bis zur oberen > Grenze. Würde dir auf jeden Fall dann zu FIR raten ... Machen weniger Ärger :)
Man kann auch mehrere IIR-Biquads nehmen (SOS-Struktur) oder einen Lattice IIR. Bei letzterem ist der Vorteil der, dass die Stabilität besonders einfach geprüft werden kann; wenn alle Koeffizienten betragsmässig < 1 sind, dann ist das Filter garantiert stabil. Dass ein Lattice-Filter prinzipiell einen höheren Rechenaufwand hat, als ein "konventionelles" wird kompensiert durch die Tatsache, dass man mit IIR mit weniger Taps schon dieselbe Flankensteilheit erreichen kann, wie bei FIR.
Die Rechenleistung eines STM32 oder von irgendwas anderem kann man sehr gut abschätzen. Einheit ist MMAC/s ( million multiply/acumulate per second ). Der STM32F4... läuft z.B. maximal mit ca. 160MHz und benötigt 3Takte für float (32Bit) multiply/accumulate ( AN 4044 von ST). Dann hat der eine 32Bit floatig Leistung von ca 53 MMAC/s brutto. Jetzt die Anforderung: 2Kanäle, 24Bit, 96kHz, 512taps: 2Kanäle 96kHZ 512taps = 98.3 MMAC/s. Da ist der STM32F4 mehr als Faktor 2 zu lahm, allerdings in float. AFAIK schafft der aber 32x32 Bit integer MAC in einem cycle, damit würde das dann gehen. Ist aber auf Kante genäht. Cheers Detlef
Tobias P. schrieb: > Ich würds, da es 24 Bit sein sollen, mit der FPU machen. Die Genauigkeit der Single-Precision-FPU ist aber nur 23 Bit, d.h. alleine schon beim Konvertieren geht 1 Bit verloren, oder seh ich das falsch?
Detlef _. schrieb: > 2Kanäle 96kHZ 512taps = 98.3 MMAC/s. Da ist der STM32F4 mehr als > Faktor 2 zu lahm, allerdings in float. Er sprach von einem Kanal, trotzdem noch zu wenig.
Detlef _. schrieb: > AFAIK schafft der aber 32x32 Bit integer MAC in einem cycle, damit würde > das dann gehen. Ist aber auf Kante genäht. Bei 512 Taps reicht das nie und nimmer bei der Auflösung. Bin auch an ähnlichen Dingen dran. Dann ist es so, dass das Prozzilein ja auch noch anderes zu tun bekommt.
Der übliche Weg ist daher das Signal per FFT in die frequency domain zu transformieren. Dort ist FIR wesentlich weniger rechenintensiv. Danach dann IFFT und fertsch. Google mal "overlap add" Gibt auch irgendwo Formeln, die den Rechenaufwand der direkten Implementierung mit den Verfahren in der frequency domain vergleichen, und da sieht man, dass es schon nach relativ wenigen Taps (30? nagel mich nicht fest) etwa quadratisch auseinanderläuft und sich somit der zusätzliche Aufwand für FFT und IFFT relativ schnell bezahlt macht.
:
Bearbeitet durch User
http://www.analog.com/media/en/technical-documentation/dsp-book/dsp_book_Ch18.pdf -> letzte Seite. Bei 64 Taps kreuzen sich die Wege.
:
Bearbeitet durch User
Ähem: Eine FFT IST ein FIR und zwar ein mehrfach paralleler. Wenn Ich einen einzigen Filter benutzen möchte, brauche Ich keine komplette FFT.
Edi M. schrieb: > Ähem: Eine FFT IST ein FIR und zwar ein mehrfach paralleler. Wenn Ich > einen einzigen Filter benutzen möchte, brauche Ich keine komplette FFT. Öhm, ein FIR ist ein Filter, der (je nach Koeffizienten) auf alle Frequenzen wirken kann. FFT zerlegt das Signal erstmal nur in Frequenz-Bänder. Um einen Filter daraus zu machen, muss man danach erstmal die Frequenzbänder mit dem Filter multiplizieren und dann das Signal per IFFT wieder in die time domain bringen. Oder was meinst du mit "einen einzigen Filter benutzen"?
Moin, Joe F. schrieb: > -> letzte Seite. > Bei 64 Taps kreuzen sich die Wege. Das seh' ich zwar auch, alleine da fehlt mir die Vorstellungskraft. Auf der einen Seite hab' ich ein klassisches FIR mit N Taps. Macht also pro Tap eine MAC-Operation, d.h. eine Multiplikation 2er reeller Zahlen und eine Addition. Dann vielleicht noch bisschen Pointerarithmetik/Speicherschieberei. Und fertsch. Ich wuerde mal fuer den M4 so groessenordnungsmaessig ausm Bauch raus vielleicht so mit 5 Takten/Tap rechnen. Aber eben nur so ausm Bauch raus. So, und jetzt will mir wer erzaehlen, dass wenn ich eine FFT mach, danach jedes Ausgangsdatum dieser FFT mittels einer komplexen Multiplikation (= 4 reelle Multiplikationen + 2 reelle Additionen) dann mit den (vorher einmalig transformierten) Filterkoeffizienten verwurste und dann den ganzen Schlonz wieder zurueck-IFFTe, dass das dann ab 40..80 Taps schneller gehen soll? Hmmmmmmmm....Naja...Also...Neee, da fehlt mir immernoch die Vorstellungskraft, wie das gehen soll. Gruss WK
Das ist genau das, was Ich meine. Beim FIR-Filter, auch bei einem komplexen Filter rechne Ich exakt dasselbe, wie bei der FFT. Die FFT faltet ja doch die eingehenden Daten mit eben einem Sinus / Cosinus und damit jeweils den individuellen Koeffizienten. Sicher, bei der FFT kann man Vieles kombinieren und es fällt viel weg, aber das kann hinten und vorne nicht sein.
Dergute W. schrieb: > Neee, da > fehlt mir immernoch die Vorstellungskraft, wie das gehen soll. Bei der direkten Implementierung muss du ja jedes Sample mit jedem Koeffizienten multiplizieren (Aufwand = Taps^2). Also steigt der Aufwand quadratisch zur Anzahl der Taps. Beim "Umweg" über die frequency domain arbeitest du Blockweise. D.h. du hast zwar einen Overhead, um einen Block Samples in Frequenzen zu zerlegen, dafür muss man pro Tap dann nur noch ein mal multiplizieren. Aufwand = FFT + Taps + IFFT. D.h. es gibt einen Grundaufwand für die FFT und IFFT des Sample-Blocks, der aber schnell (im oben verlinkten Paper ab 64 Taps) dadurch wieder wett gemacht wird, dass der Aufwand für das Multiplizieren mit den Koeffizienten linear mit der Anzahl der Koeffizienten steigt (im Gegensatz zu direkten Implementierung: kein Grundaufwand dafür n^2 Multiplikationen für die Taps). Bei sagen wir mal 1024 Taps macht sich das dann schon sehr, sehr deutlich bemerkbar (eben ca. Faktor 1024, da FFT und IFFT im Verhältnis zu den 1048576 Multiplikationen bei direkter Implementierung vernachlässigbar sind).
:
Bearbeitet durch User
Hi, hat der F7 nicht immer schon einen DSP mit an Board ? Ist doch die Cortex M7 Variante von STM oder nicht ? Ich dachte immer die hätten DSP standardmäßig mit an Board... Hatte sowas vor langer Zeit mit einem externen DSP gemacht und muss sagen, dass es Dinge gab, die nachher mehr Probleme gemacht haben, als die FIR Filter. Bei mir war die Varianz und der indizierte Jitter ein Problem. Das würde wieder für einen FPGA mit einem guten FlipFlop und externem Quarz zum takten sprechen. Um die Varianz zu eliminieren wirst du nicht um einen Puffer drumherum kommen. Vll geht das auch auf nem F7 fix genug, weiss nicht genau. Es wäre nett, wenn du mal schreiben würdest, wie gut das bei dir geklappt hat. Kleinere Filter kann man heutzutage auch mit manchen DAC Chips erledigen. Der TI PCM5142 z.B. hat schon einen kleinen DSP mit an Board. Viel Glück, bin mal gespannt wie du das Problem angehst.
Moin, Mir schwant so langsam, was die Paperverfasser da meinen koennten. Der Gesamtaufwand fuer eine Faltung eines bestimmten Signals mit einer bestimmten Laenge mit einem bestimmten Satz Filterkoeffizienten - da kanns schon sein, dass da was quadratisch ansteigt. Aber: Entscheidend fuer den TE ist ja nicht die Gesamtanzahl Rechenoperationen, um z.b. ein Musikstueck zu filtern, sondern die Anzahl Rechenoperationen pro Eingangssample. Das steigt linear mit den Taps an. Bei den Filtern mit Riesen-FFT hin und zurueck wirds auch mit der Totzeit (und damit auf µControllern dem RAM-Bedarf) etwas unangenehm. Da ist das Musikstueck schon durchgedudelt, dann kanns erst geFFT werden, dann hurtig die Multiplikationen und die IFFTierung. Erscheint mir nicht praktikabel. Gruss WK
Tja, beim nochmaligen drüberschauen ist mir tatsächlich auch nicht wirklich klar, wie die auf einen quadratischen Anstieg bei der direkten Form kommen. Denn du hast recht, die Anzahl der Multiplikationen nimmt eigentlich linear mit der Anzahl der Taps zu. Bei der FFT Methode ist es eher eine log() Funktion. Hier ist das auch nochmal etwas besser erklärt: http://acoustics.aau.dk/~sko/3d/slides/5.pdf Dergute W. schrieb: > Da > ist das Musikstueck schon durchgedudelt, dann kanns erst geFFT werden, > dann hurtig die Multiplikationen und die IFFTierung. Erscheint mir nicht > praktikabel. Das mit dem Delay ist richtig, auf wenn von dir stark übertrieben ;-) Ein Filter mit 512 Taps erzeugt bei der FFT Methode und bei 48 KHz ein Delay von 10ms. Ist meistens durchaus akzeptabel. Um das Delay zu verkürzen (vor allem bei längeren Filtern), zerlegt man den Filter eben in kleinere Portionen und wendet das overlap-add Verfahren an. Klar, da ist etwas mehr Speicher nötig. Man muss halt individuell entscheiden was der richtige Weg ist.
:
Bearbeitet durch User
Joe F. schrieb: > Ein Filter mit 512 Taps erzeugt bei der FFT Methode und bei 48 KHz ein > Delay von 10ms. Wie rechnet sich das denn, bitte?
WS schrieb: > Joe F. schrieb: >> Ein Filter mit 512 Taps erzeugt bei der FFT Methode und bei 48 KHz ein >> Delay von 10ms. > > Wie rechnet sich das denn, bitte? Ergibt sich einfach aus der notwendigen Blockgröße von 512 Samples -> 512/48000 = 0.011 s Kommt jetzt natürlich drauf an, wie schnell der Prozessor ist um FFT und IFFT zu machen. Auf einem uC würde man dann nochmal die gleiche Zeit einplanen, und das gemütlich abfrühstücken während der nächste Sampleblock reinläuft.
:
Bearbeitet durch User
Moin, Die 10 msec wegen 512/48kHz kauf ich fuer ein "normales" FIR ab. Fuer das FFT/IFFT Dingens gehts allerschnellstens in der doppelten Zeit. Und das auch nur, wenn die (I)FFT und die ganzen komplexen Multiplikationen exakt in 0 Takten/sec ablaufen. Sonst dauert's eben noch laenger... Gruss WK
Nein. Die normale FIR hat keine Verzögerung, da immer in die Vergangenheit gerechnet wird. FFT sieht so aus:
1 | 0ms 11ms 22ms |
2 | |
3 | +---------------------+ |
4 | | 512 Samples buffern | |
5 | +---------------------+ |
6 | | +---------------------+ |
7 | +->| FFT / Multipl./IFFT | |
8 | +---------------------+ |
9 | | +---------------------+ |
10 | +->| Samples ausgeben | |
11 | +---------------------+ |
12 | |
13 | +---------------------+ |
14 | | 512 Samples buffern | |
15 | +---------------------+ |
16 | | +---------------------+ |
17 | +->| FFT / Multipl./IFFT | |
18 | +---------------------+ |
19 | | +---------------------+ |
20 | +->| Samples ausgeben | |
21 | +---------------------+ |
Wenn du der FFT, den Multiplikationen und der IFFT genauso viel Zeit einräumst, wie ein Buffer reinläuft, brauchst du exakt 2x soviel Zeit, bis die ersten Samples wieder raus gehen. Die Berechnung des Filters und das Buffer-handling müssen entsprechend parallel ablaufen - in der Regel kein Problem, da Buffer füllen und leeren kein großer Rechenaufwand ist.
:
Bearbeitet durch User
Joe F. schrieb: > Nein. Die normale FIR hat keine Verzögerung, da immer in die > Vergangenheit gerechnet wird. Aber genau deshalb hat die Berechnung doch eine Verzögerung: Sowohl bei einem FIR, als auch der FFT und jedem anderen ähnlich gestrickten Filter, bei dem "in die Vergangenheit geschaut wird". > FFT sieht so aus: Beim FIR sieht es auch so aus, wobei BEIDE auch on-the-fly arbeiten können, speziell die FFT dies aber nicht tut und zwar im Wesentlichen aus Effizienzgründen. Letztlich ist die FFT in der Tat nichts anderes, als mehrfach parallelisierte FIR-Filterung mit jeweils den einzelnen Frequenzen. Zu Deiner Grafik: FFTs, die fortgesetzt prozessieren sollen, können nicht nur immer Blöcke dieser Art herausschneiden, sondern müssen übelappen, aber das steht noch auch einem anderen Blatt. Allerdings kann man dann (und nur dann!) die Auflösung der FFT mit der des FIR vergleichen, weil der nämlich i.d.R. so aufgestellt ist. Das ist auch das, was WeKa mit dazu bewogen hat, spontan die These infrage zustellen, ob man da mit der FFt besser fährt. Das ist nämlich SO nicht der Fall! Das ist auch deshalb nicht der Fall, weil man die FFT über mehr, als eine Periode erstrecken muss, um einen kontinuierlichen Datenstrom weitgehend verzerrungsfrei sampeln und resynthetisieren zu können, ansonsten wirkt nämlich das Fenster und dies ist mit FIR weniger kritisch und auch einfacher realisierbar. Ich habe genau diese Geschichte bei Raumimpulsantworten für Echogeneration und -elimination bis aufs Bit durchexerziert - es gibt da immer massive Artefakte bei FFT<->IFFT, die die Methode für z.B. Audio, wo man kleinste Probleme direkt hören kann, disqualifizieren oder zumindest stark einschränken.
Jürgen S. schrieb: > Joe F. schrieb: >> Nein. Die normale FIR hat keine Verzögerung, da immer in die >> Vergangenheit gerechnet wird. > Aber genau deshalb hat die Berechnung doch eine Verzögerung: Sowohl bei > einem FIR, als auch der FFT und jedem anderen ähnlich gestrickten > Filter, bei dem "in die Vergangenheit geschaut wird". Klar, der Filter an sich verursacht eine gewisse Verzögerung (Phase), das kann man ja nicht ändern. Allerdings kommt bei der direkten Implementierung eben schon ab Sample 0 am Eingang schon ein Sample am Ausgang heraus. Ganz am Anfang funktioniert der Filter natürlich nicht richtig, da ja keine bzw. zu wenig "Historie" da ist. Bei der blockweisen Verarbeitung kommt aber noch die Zeit dazu, die benötigt wird um einen Buffer zu füllen, damit man überhaupt eine FFT machen kann. Es gibt Verfahren, die beides kombinieren, kleinere erste Portion mit direkter Implementierung, und danach mit FFT. Dadurch kann man dann auch wieder auf Real-Time kommen. Ist aber halt sehr aufwändig. Jürgen S. schrieb: > Zu Deiner Grafik: > > FFTs, die fortgesetzt prozessieren sollen, können nicht nur immer Blöcke > dieser Art herausschneiden, sondern müssen übelappen, aber das steht > noch auch einem anderen Blatt Das ist richtig. Ich habe mir das der Einfachheit halber geschenkt. Trägt ja nichts zum Thema "Delay" bei. Jürgen S. schrieb: > Ich habe genau diese Geschichte bei Raumimpulsantworten für > Echogeneration und -elimination bis aufs Bit durchexerziert - es gibt da > immer massive Artefakte bei FFT<->IFFT, die die Methode für z.B. Audio, > wo man kleinste Probleme direkt hören kann, disqualifizieren oder > zumindest stark einschränken. Das kann ich nicht bestätigen. Ich habe vor einiger Zeit 32 FIRs mit 512 Taps auf einem System ohne FPU implementiert, das arbeitet mit 32 bit Integer. Trotz Umweg über FFT und IFFT, overlap add ist die 24-Bit Audio Performance einwandfrei. Direkte Implementierung habe ich am Anfang auch ausprobiert, dann aber aus Performancegründen aufgeben müssen. Ich krame das gerne nochmal raus, um genauere Werte zu nehmen. Eure Argumentation hat durchaus überzeugende Aspekte ;-) Aus dem Kopf heraus bekomme ich es gerade nicht mehr zusammen, warum die beiden Verfahren einen so großen Unterschied bezügl. Performance machen.
:
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.