Gibt es gute DSP-Libraries für Microcontroller?
Gerade eben habe ich ein Beispiel für complexe Zahlen ausprobiert:
https://en.cppreference.com/w/c/numeric/complex
Die grundsätzlichen Funktionen scheinen da, aber bei der Zeile mit der
Eulergleichung wird schon ein Fehler geworfen.
Dein Beispiel mit den complexen Zahlen funktioniert vermutlich nicht,
weil dein Compiler nicht im C99 mode compiliert. Das sollte eigentlich
funktionieren.
Allerdings ist es bei den meisten DSP Algorithmen, mit denen man in der
Praxis so arbeitet, unüblich einzelnde Berechnungen mit complexer
Arithmetik zu berechnen.
Du arbeitest fast immer auf Gruppen Daten (sprich Arrays). Der complexe
Datentyp von C bringt dir dabei nicht viel. Es ist häufig viel
effizienter gleich die Berechnung auf dem realen und imaginären
Komponenten auszuführen.
Und längst nicht jeder DSP Algorithmus basiert auf complexer Arithmetik.
So ein FIR-Filter, oder eine Korrelation z.B. arbeiten ganz stumpf auf
realen Zahlen.
Anyway, die CMSIS DSP Library ist meist die erste Anlaufstelle. Die ist
hinreichend schnell, bugfrei, und deckt ein Großteil dessens ab, was man
in der Praxis so braucht.
Ob die Eigen-Lib für dich funktioniert musst du selbst herrausfinden.
Ja, wenn sie auf double Datentypen aufbaut wird sie den Hardware
Floating-Point vom Chip nicht nutzen können. Das bedeutet aber nicht,
das sie nicht für deine Anwendung schnell genug ist.
Nils P. schrieb:> Und längst nicht jeder DSP Algorithmus basiert auf complexer Arithmetik.> So ein FIR-Filter, oder eine Korrelation z.B. arbeiten ganz stumpf auf> realen Zahlen.
Wenn man die Phasen nicht verarbeiten möchte, ja. Aber es gibt auch
komplex arbeitende FIR-Filter. Trotzdem ist es richtig, nicht
zwangsweise Strukturen mit komplexen Zahlen einzusetzen. Eher schon muss
man sich überlegen, wie man Rechnungen umformt, dass wenige
Speicherzugriffe und Zwischenergebnisse anfallen.
Jürgen S. schrieb:> Nils P. schrieb:>> Und längst nicht jeder DSP Algorithmus basiert auf complexer Arithmetik.>> So ein FIR-Filter, oder eine Korrelation z.B. arbeiten ganz stumpf auf>> realen Zahlen.> Wenn man die Phasen nicht verarbeiten möchte, ja. Aber es gibt auch> komplex arbeitende FIR-Filter. Trotzdem ist es richtig, nicht> zwangsweise Strukturen mit komplexen Zahlen einzusetzen. Eher schon muss> man sich überlegen, wie man Rechnungen umformt, dass wenige> Speicherzugriffe und Zwischenergebnisse anfallen.
die arm lib arbeitet ganz stumpf mit arrays
[real][imag][real][imag][real][imag][real][imag][real][imag]
es gibt aber auch hier funktionen für die deine daten in die complexen
arrays umwandelt.
Diese müssen dann aber immer doppelt so groß wie das original sein
Moin,
chris schrieb:> Gibt es gute DSP-Libraries für Microcontroller?
Was heisst schon "gute" Libraries? Entweder die Libfunktionen sind
schnell und genau genug fuer meinen Anwendungszweck oder nicht.
Allgemein "gute" Libraries wirds da wohl nicht geben.
Und wenn man's eilig hat, sollte man am Algorithmus feilen und echte
komplexe Rechnungen moeglichst loswerden.
Eine komplexe Multiplikation braucht ja schon mal 4 reelle
Multiplikationen und 2 Additionen.
Also moeglichst reell bleiben.
Gruss
WK
Dergute W. schrieb:> Eine komplexe Multiplikation braucht ja schon mal 4 reelle> Multiplikationen und 2 Additionen.
und einen DSP oder Prozessor mit DSP Erweiterung
zeichnet sich dadurch aus das er genau das sehr gut kann.
Oft in nur zwei Takten.
Moin,
Hoert sich jetzt fuer mich mal so langsam an wie die Spinne in der
Yuccapalme.
Gibts irgendwelche Belege dafuer, dass ein Cortex M4 oder M7, wenn er
denn eine "Complex x Complex" Multiplikation durchfuehren soll,
irgendwie mehrere reellwertige Multiplikationen gleichzeitig
durchfuehren kann?
Ich kenn' mich auf dem nicht aus, aber ich wuerd' mal schaetzen,
bestenfalls kann der durch MAC Anweisungen die beiden Additionen ohne
Extrazyklen machen. 4x Multiplizieren bleibt seriell. Oder hoechstens
noch mit kleinerer Genauigkeit vielleicht als SIMD?
Klar, irgendwelche VLIW-Dickschiffe als DSP koennen solche Faxen mit
mehreren MAC-Units parallel machen. Aber auch auf so einer Maschine bin
ich trotzdem schneller, wenn ich durch cleveren Algorithmus nicht mehr
soviel komplex rechnen muss.
Gruss
WK
Dergute W. schrieb:> Aber auch auf so einer Maschine bin ich trotzdem schneller, wenn ich durch> cleveren Algorithmus nicht mehr soviel komplex rechnen muss.
Dies solltest du durch ein konkretes Beispiel untermauern.
Moin,
Harald schrieb:> Dies solltest du durch ein konkretes Beispiel untermauern
???
OK. Also konkrete Aufgabe: Zu einem Wert im Register r1 die Konstante 7
dazuaddieren, um auf ein Zwischenergebnis zu kommen.
uncleverer Algorithmus:
inc r1
inc r1
inc r1
inc r1
inc r1
inc r1
inc r1
nicht ganz so uncleverer Algorithmus:
add r1,7
Am cleversten: Rausfinden, dass man das Zwischenergebnis eigentlich
ueberhaupt nicht braucht und sich somit die Addition komplett sparen
kann.
Gruss
WK
Ist eigentlich jemandem bekannt, ob es DSPs oder CPU-Erweiterungen gibt,
die speziell für komplexe Berechnung optimiert und designed wurden?
Wir haben das in unsere hand made CPU eingebaut. Läuft als Co-Pro in
einem ASIC:
Beitrag "64/128 Bit Softcore"
Moin,
Andi F. schrieb:> Ist eigentlich jemandem bekannt, ob es DSPs oder CPU-Erweiterungen gibt,> die speziell für komplexe Berechnung optimiert und designed wurden?
Guck' mal ins sprugh7.pdf von TI; im Kapitel 1.1.4 wird erwaehnt, dass
sie sowas koennen.
Ich halt's fuer nicht besonders wichtig. Komplexe Rechnung ist was, was
auf'm Papier gut aussieht, dort auch Schreibarbeit spart, und mit dem
man gut irgendwas herleiten kann oder mal was ausprobieren.
Aber fuer's Produkt wird man immer gucken, dass man das optimiert und
dann fliegen komplexe Rechnungen doch schnell raus oder werden solange
vereinfacht bis sie auch reell funktionieren.
Gruss
WK
Was wäre an komplexen Berechnungen auch anders? Es läuft ja nur auf die
richtige Interpretation des "i" hinaus. Der Rest sind reelle Rechnungen,
bei denen mal ein überraschendes Minus auftaucht.
Moin,
Markus W. schrieb:> Was wäre an komplexen Berechnungen auch anders?
Ja - aeh - sie dauern laenger, wenn man eben keinen MonsterDSP mit
mehreren parallel arbeitenden MAC-Units hat? Und selbst wenn ich so
einen hab', koennt' ich dann dessen MAC-Units mit entsprechend mehrern
reellen Rechenoperationen auslasten so das ich auch da Zeit sparen kann,
wenn ich mir vorher ein paar Ueberlegungen mach', wie mein Algorithmus
evtl. nicht alles komplex rechnen muss...
Gruss
WK
Ich hab mich gerade etwas intensiver mit einer FFT auf dem STM32F4
auseinander gesetzt.
Grundsätzlich arbeitet man dabei immer mit komplexen Zahlen, weil auch
eine "RealFFT" wie arm_rfft_fast_f32(), die als Eingang nur Real-Werte
haben will, trotzdem ein komplexes Spektrum zurück gibt.
Warum? Weil nunmal jeder Frequenzanteil durch Betrag und Phase
charakterisiert wird.
Ich kann hier folgende Lektüre nur wärmstens empfehlen:
http://dspguide.com/
Aber das Arbeiten mit komplexen Zahlen ist auf dem µC wirklich kein
Hexenwerk.
Man muss sich nur klarmachen, dass die Darstellung als Betrag+Phase für
uns Menschen viel besser zu verstehen ist als Real+Imag, für den µC aber
Real+Imag viel einfacher zu verarbeiten als Betrag+Phase.
Aus diesem Grund wird eine komplexe Zahl einfach als Einheit zweier
Variablen (Real und Imag) dargestellt.
Wenn man will, kann man das elegant über eine Struct oder Klasse machen,
oder man macht es ganz pragmatisch wie die arm_math-Libraries:
Man tut ein Array mit N Samples in arm_rfft_fast_f32() hinein und
bekommt ein Array mit N*2 Samples wieder heraus (wobei man nur höllisch
aufpassen muss, weil die Elemente 0 und 1 ausnahmsweise KEINE komplexen
Zahlen sind, sondern nur die Real-Teile von f=0 und f=Max).
Und noch das Wort zum Sonntag:
Man kann es auch ganz einfach machen:
1. Berechne einen Filterkernel als Zeitsignal mit N Samples (nur reale
Werte)
2. Berechne daraus per arm_rfft_fast_f32() den transformierten
Filterkernel mit N*2 Werten
3. Sammle N äquidistante ADC-Samples
4. Berechne daraus per arm_rfft_fast_f32() das transformierten
ADC-Signal mit N*2 Werten
5. Multipliziere Element 0 des Signalspektrums mit Element 0 des
Filterspektrums
6. Multipliziere Element 1 des Signalspektrums mit Element 1 des
Filterspektrums
7. Multipliziere den Rest der beiden Spektren (ab Element 2) komplex
mittels arm_cmplx_mult_cmplx_f32()
8. Als Ergebnis erhälst Du das Spektrum des gefilteren ADC-Signals
9. Invers-Transformiere das Ergebnis-Spektrum zurück per
arm_rfft_fast_f32() in den Zeitbereich, dabei wird aus N*2
Eingangswerten wieder N reale Ausgangswerte erzeugt.
10. Erfreue Dich an Deinem gefilteren ADC-Signal mit N Samples
Dergute W. schrieb:> Ja - aeh - sie dauern laenger, wenn man eben keinen MonsterDSP mit> mehreren parallel arbeitenden MAC-Units hat?
Verstehe ich nicht. Dass eine Rechnung "komplex" ist, heisst nur, dass
man ein "i" berücksichtigen muss, wenn die Formeln erzeugt werden. Der
Prozessor rechnet dann einfach reelle Formeln. Oder meinst Du, dass es
statistisch doppelt so viele sind?
Moin,
Denn rechne es doch mal aufm Papier oder im Kopf aus. Mach mal eine
reelle Multiplikation, also z.b. sowas:
123 x 456 = ?
Und jetzt rechne mal eine komplexe Multiplikation aus:
(123 + j456) x (234 - j567) = ?
Wie gehst du dabei vor, fuer was brauchst du laenger und warum?
Gruss
WK
Dergute W. schrieb:> Guck' mal ins sprugh7.pdf von TI; im Kapitel 1.1.4 wird erwaehnt, dass> sie sowas koennen.
Danke für den Beitrag.
> Ich halt's fuer nicht besonders wichtig. Komplexe Rechnung ist was, was> auf'm Papier gut aussieht,
Bei LTE-Prozessierung und anderen nachrichtentechnischen
Aufgabenstellungen wird das aber permanent verwendet.
Moin,
Andi F. schrieb:> Bei LTE-Prozessierung und anderen nachrichtentechnischen> Aufgabenstellungen wird das aber permanent verwendet.
Ja, bei der Aufgabenstellung ist das sicher dabei. Weil sich damit der
Algorithmus halt schoen hinschreiben laesst.
Aber haste mal ein Beispiel fuer irgendwelchen DSP oder sonstigen Code,
der fuer sowas im Einsatz in einem Industrieprodukt ist und wo viel
komplex gerechnet wird?
OK, ist natuerlich schwer, sowas, selbst wenn man es haette, hier
herzuzeigen. Aber jeder Entwickler wird schauen, dass er moeglichst viel
eben nicht komplex rechnen muss, weil's Performance frisst. Im Handy und
anderer mobiler Amuesierelektronik geht das auf die Akkulaufzeit, in der
Basisstation/Headend auf die Hardwarekosten/Dichte.
Gruss
WK
Andi F. schrieb:> Ja hätte ich. Liveberechnung von Parametern anhand der Gleichung> der Übertragungsfunktion.
Parameterberechnung live vor Publikum?
Wo kann man die Karten bestellen? :D
Watson schrieb:> Parameterberechnung live vor Publikum?> Wo kann man die Karten bestellen?
Die gibt's hier und kostenlos.
Parameterberechnung live heißt einfach nur "zur Laufzeit". Mir geht da
schon seit Jahren ein Problem wie das berüchtigte Mühlrad im Kopfe
herum: Einen FIR sin(x)/x Bandpaß zu berechnen mit eingebauter
Phasendrehung um 4 Grad - und zwar nicht offline am PC, sondern im µC
zur Laufzeit. Wie der Filterkernel aussehen muß, weiß ich bereits, es
fehlt mir nur der tatsächliche Algorithmus zum Berechnen der Filtertaps.
So, falls das zur Diskussion hier führen würde, hast du damit bereits
deine Eintrittskarten.
W.S.
Moin,
W.S. schrieb:> Mir geht da> schon seit Jahren ein Problem wie das berüchtigte Mühlrad im Kopfe> herum: Einen FIR sin(x)/x Bandpaß zu berechnen mit eingebauter> Phasendrehung um 4 Grad - und zwar nicht offline am PC, sondern im µC> zur Laufzeit.
1.) Ja und - Wo ist's Problem? Dass ein attiny13a nur unter Schmerzen
multiplizieren kann und zuwenig Flash fuer grosse Tabellen hat? Oder
wegen seinem RAM nur FIRs 64. Ordnung kann?
Was muss der Bandpass denn koennen?
2.) Und warum 4 Grad Phasendrehung bei einem digitalen Filter? Ist das
so ein obskures Zeug, wie der Kollege im Nachbarthread mit seiner
Laufzeit von 2..1msec?
Gruss
WK
W.S. schrieb:> Einen FIR sin(x)/x Bandpaß zu berechnen mit eingebauter> Phasendrehung um 4 Grad - und zwar nicht offline am PC, sondern im µC> zur Laufzeit. Wie der Filterkernel aussehen muß, weiß ich bereits, es> fehlt mir nur der tatsächliche Algorithmus zum Berechnen der Filtertaps.
Für einen TMS320 hatte ich so etwas mal gemacht. Ansprechen von
Studiomintoren mit Autokorrektur der Klangkurve. Skalierbar von 128 bis
1024 TAPs. Geht natürlich ausbauen. Auch für einen FPGA habe ich dafür
einen Core. Sin(X) durch X wird entweder per interpolierter Tabelle
genähert oder wenn Zeit genug ist, mitsamt Fenster auf der Basis des
CORDIc abgenudelt. Geht auch mit iterativer Besselfunktion und Kaiser.
Das mit den 4 Grad Phasendrehung müsste man mal sehen, bzw. speziell
eindesignen. Alles, was allein durch Filterkoeffizienten geht, wäre ja
kein Problem.
Bliebe die Frage, was daran alles noch in Echtzeit parametrisch sein
muss.
Wie man das in einem Microprozessor der schwachbrüstigen Sorte umsetzt,
bliebe zu diskutieren. Wäre letztlich nur eine Frage der
Ausführungszeit.
Ich denke, wir hatten doch vor Wochen schon mal so ein Thema, hier
oder?
Beitrag "Kaiser-Window Annäherung"
Läuft das nicht aufs Gleiche hinaus?
Thread beobachten
Seitenaufteilung abschalten