Hi, ich muss einen Filter bauen und muss einen FIR Filter umsetzen.
Die Daten kommen mit ca. 100KHz rein und ich brauche einen Filter mit
3000 Werten.
Das macht somit maximal 10us für die ganze Berechnung.
Ist das mit einem DSP überhaupt machbar und wenn ja welchen würdet Ihr
mir empfehlen?
Dirk
Ein einfacher Filter mit ein wenig zurecht biegen der Frequenzen.
Ist eine Signalaufbereitung von einem nicht linearen Sensorsystems und
kleinere Filter zeigten in der Simulation nicht den gewünschten Erfolg.
Die DSPs kosten für dieses Projekt dann doch recht viel, der gesamt
preis wird dadurch glatt auf das Doppelte bis 4 fache teurer.
Da muss ich wohl nach was anderem suchen.
Ob ein kleiner FPGA (max 15 Euro) gehen würde?
VG, Dirk
Eine Möglichkeit wäre IIR statt FIR (weniger Koeffizienten, dafür
komplizierteres Design und Implementierung). Falls FIR nötig, dann
blockweise mit FFT statt Faltung (Overlap-Add, Overlap-Save) ->
Komplexität O(N log(N)) statt O(N²).
Moin,
die Frage stellt sich v.a. nach der Peripherie, soll die Verarbeitung
direkt oder RAM-gepuffert geschehen, und wo müssen die Daten nachher
hin? Welches Interface?
Reichen 16 Bit? Wieviel RAM brauchst du für dein Konzept?
Für 16bit per SPORT wüsste ich eine Lösung mit dem Blackfin, da würde es
auch einer aus der billigen 50x-Reihe eventuell tun. Das kritische ist
meist nicht die Berechnungsdauer sondern das Zusammenspiel
Peripherie/DMA, usw.
Und den FIR solltest du auf jeden Fall in Assembler programmieren um die
Pipeline schön voll zu halten und die parallelen Befehle voll
auszunutzen.
Unter Umst. ist da das FPGA geeigneter im Sinne von "keep it simple".
Ein Killerkriterium bei den DSPs ist, dass die Effizienz flöten geht,
wenn man während der Berechnung (in der HW-Schleife) irgendwelche
Overflow/Range-Checks macht (if/else). Tut man normalerweise nicht, aber
das so am Rande.
Gruss,
- Strubi
Andreas Schwarz schrieb:> Eine Möglichkeit wäre IIR statt FIR (weniger Koeffizienten, dafür> komplizierteres Design und Implementierung). Falls FIR nötig, dann> blockweise mit FFT statt Faltung (Overlap-Add, Overlap-Save) ->> Komplexität O(N log(N)) statt O(N²).
Wenn die Latenz kritisch ist, ein partitioniertes Overlap-Add/Save ;)
IIR kann keine linearphasig Implementation, (das sollte aber nur für
Sprachsignale wichtig sein?)
Danke für die Antworten.
Ich bekomme von einem AD-Wandler 16/24Bit mit 96,... KHz Daten.
Das ist ein Audio Wandler, es wird aber nur ein Kanal ausgewertet.
Die Daten gehen durch den Filter und werden wieder raus gegeben an einen
DA-Wandler und an einen ARM7.
Der DA-Wandler ist zur direkten Ausgabe der Daten zum ansehen und ob der
Filter sauber arbeitet.
Der ARM7 macht ein paar Auswertungen damit und kümmert sich um alles
andere auf dem System.
VG, Dirk
Dirk schrieb:> Ob ein kleiner FPGA (max 15 Euro) gehen würde?
Eher nein. Meine Suchen fallen regelmäßig zugunstens eines DSPs aus.
Nur wenn es vom speed her garnicht geht. Aber was für einen FPGA bekommt
man schon für 15,-?
Spartan 3A50?
Wird ein XMOS Prozessor (ca. 6 EURO) als Schnittstelle.
Und entweder bleibt der ARM dahinter oder Alternativ kommen weiter 1-3
XMOS L1 drauf. Den kann ich noch löten!
Ich meinte mit Schnittstelle den Filter!
Der eine oder andere TI DSP hatte es mir auch angetan, aber da stand
dann immer wieder das Löten im weg.
Vielleicht bin ich aber auch nur blind und übersehe den richtigen DSP
ständig.
Bist du dir sicher das du einen Filter mit 3000 taps brauchst ? Ich
glaube da hast du irgendwas nicht verstanden.
> Ich bekomme von einem AD-Wandler 16/24Bit mit 96,... KHz Daten.>Das ist ein Audio Wandler, es wird aber nur ein Kanal ausgewertet.>Die Daten gehen durch den Filter und werden wieder raus gegeben an einen>DA-Wandler und an einen ARM7.
guck dir mal die Signal Processing Features vom tlv320aic3204 an (Seite
45). http://www.ti.com/lit/ds/symlink/tlv320aic3204.pdf
Das ganze System wird sich nochmal komplett ändern.
Manche Projekte hätte man lieber nie angefangen.
Aufgrund vom geänderten System habe ich, nach weiteren Berechnungen und
Simulationen das ganze auf knapp 2000 Taps reduziert.
Aber aufgeteilt auf 9 einzelne Filter. Zerlegen in 5 Bänder und wieder
zusammen fügen!
Die einzelnen Signale (5 Bänder und gesamt) werden dann entsprechend
weiter verarbeitet.
Audio ist leider was anderes wie Sensoren.
Glaube das bei Audio ein Filter mit 50-100Taps mehr als ausreichen
würde.
Das könnte der ARM7 locker noch alleine machen.
> Ich bekomme von einem AD-Wandler 16/24Bit mit 96,... KHz Daten.>Das ist ein Audio Wandler, es wird aber nur ein Kanal ausgewertet.
oder
> Audio ist leider was anderes wie Sensoren.> Glaube das bei Audio ein Filter mit 50-100Taps mehr als ausreichen> würde.
Was denn jetzt ?
Dirk schrieb:> Aber aufgeteilt auf 9 einzelne Filter. Zerlegen in 5 Bänder und wieder> zusammen fügen!> Die einzelnen Signale (5 Bänder und gesamt) werden dann entsprechend> weiter verarbeitet.
Wenn Du ohnehin schon in einzelne Bänder zerlegst (wie? Mit blockweiser
FFT?), warum rechnest Du dann nicht gleich das ganze Filter im
Frequenzbereich?
Max
Dirk schrieb:> Sensor Signal aber mit einem Audiowandler aufgenommen!
Das ist zunächst mal ziemlich egal.
> FFT ist zwar auch möglich aber ... Nein will ich nicht!
Das hört sich ja an wie der Suppenkaspar ("Meine Suppe ess ich nicht,
nein meine Suppe ess ich nicht"). Aber ein jeder ist seines Glückes
Schmied...
Max
Manchmal muss man halt stur sein und was entscheiden.
Sonst kommt am ende nichts raus, weil man schon beim Start immer was
besseres findet. Was verbessern kann man später immer noch, aber erst
einmal muss was funktionierendes auf dem Tisch liegen.
Und die Planung beende ich jetzt, hat genug Zeit verbraten.
Nun wird das stur durch gesetzt.