Hi,
ich habe das Problem das ich ein Signal mit 4MHZ (16bit) abtaste und mit
diesen Werten eine FFT (1024 Punkte) machen soll. Im Ergebnis möchte ich
noch Frequenzen bis 2MHz erkennen können. Zur weiteren Auswertung werden
die Daten dann gesammelt und im 1Khz Takt versendet.
Wenn ich jetzt nur mal davon ausgehe das ich ca 4000 mal pro Sekunde
eine FFT machen muss um keine Daten zu verlieren stellt sich die Frage
welcher Low-Cost (< 40Eur) DSP schafft das?
Das ich die Daten dann noch zusammen fassen muss und weiter leiten darf
lasse ich jetzt mal weg.
Meine FFT Kenntnisse sind recht dürftig, ich kann die Funktion aufrufen
und kenne das Ergebnis. Aber selber berechnen kann ich das nicht.
Gibt es eine Methode die ganze Brechung zu vereinfachen?
Kann man, sagen wir 16 Filter machen und diese Signale dann auf kleinere
FFT (4MHZ / 16 Filter) Berechnungen verteilen?
Oder kann das mit 1024 Filter schneller laufen?
Oder gibt es eine ganz andere Art wie man so was elegant lösen kann?
Viele Grüße, Peter
Peter schrieb:> Kann man, sagen wir 16 Filter machen und diese Signale dann auf kleinere> FFT (4MHZ / 16 Filter) Berechnungen verteilen?> Oder kann das mit 1024 Filter schneller laufen?
Das ist eigentlich genau das, was die FFT intern macht.
Eventuell wären an dieser Stelle etwas mehr Infos über die zu lösende
Aufgabe nützlich, vielleicht kann man es auch anders als mit FFTs
angehen.
Hallo Peter,
ein Blick auf Webseiten von Texas Instruments und Analog Devices hilft
weiter. Mindestens bei TI gibt eine ungefähre Preisangabe. Sicher gibt
es dort auch Perfomance-Angaben (Rechenzeit pro FFT). Wenn ich Deine
Aufgabe richtig verstehe, solltest Du an ein Overlapping der FFTs
denken. Weiterhin auch an Pegelgenauigkeit denken (Stichworte Fensterung
und Interpolation im Frequenzbereich). Du wirst mehr Rechenpower
benötigen, als Du zunächst kalkuliert hast.
Viele Grüße
Markus
Es kommt darauf an, wie schnell sich die 2MHz ändern. Dazu braucht man
gfs 8 bis 16 FFTs je Durchgang. Ich würde mir einen Beispiel CODE eines
DSP laden, den mit dem PC vergleichen, um wenigstens in die richtige
Grössenordnung zu kommen.
Die ändern sich sehr schnell. Mehrfach pro Sekunde (Schwingungen).
Auf dem PC ist alles schon simuliert, aber das sagt nichts über einen
DSP aus.
Die Datenblätter sind mir hier zu wenig, jemand mit Erfahrung auf dem
Gebiet vertraue ich da mehr. Auch Code ist zwar nett aber ohne reale
Plattform ist der auch nichts wert.
Aber es geht mir noch viel mehr darum, ob man sich irgendwie Rechenzeit
einsparen kann.
Hi Peter,
Wenn du aus den üblichen DSPs alles rausholen willst, musst Du sie auf
jeden Fall in Assembler programmieren, oder eine geeignete und
optimierte FFT-Routine aus der DSP-Library finden.
Die O(N * log N) der klassischen 2-Radix FFT kannst Du mit einigen
Tricks noch runterbrechen, für Realdaten kannst Du dann noch mit 512
komplexen Multiplikationen in der ersten "Stage" auskommen. Zudem kann
man durch Aufbohren auf Radix 4 oder gar Radix 8 nochmal ein paar Zyklen
sparen (da gibts ein paar fiese Symmetrien, die man ausnutzen kann).
Meistens sind allerdings solche Tricks nicht in den FFT-libraries drin,
kommt man also nich um eigene Optimierungen rum.
Mit den üblichen Verdächtigen (Blackfin oder einige der kräftigen TMS*
bei 600 MHz) könnte das klappen, sofern Dir 16 bit reichen. Würde das
aber erst mal 'trocken' durchsimulieren, und genug "head room" lassen,
die Daten müssen sicher noch in eine Nachverarbeitung. Mit cleverem
Abpuffern kriegt man auf dem Blackfin ne gute DMA/Verarbeitungs-Pipeline
hin, bei der so gut wie keine Rechenpower für Transfers draufgeht.
Klappt aber alles nur, wenn kein SDRAM mit im Spiel ist, sonst kann man
mit etwa 50% Bremse rechnen.
Grüsse,
- Strubi
Ich wollte nur Standard Funktionen nehmen, wenn ich das selber in
Assembler programmieren muss ist das Thema schnell durch für mich.
Änderungen in einem C-Code kann ich machen.
SD-RAM ?.... brauche ich hoffentlich nicht.
4K Eingangsdaten (Doppelt gepuffert)
+ 2K FFT output
+ 1K Ausgabedaten
+ X FFT intern & sonstiges
Ist irgendwie nicht viel
DSP mit 600 MHz ist schon ein Wort. Aber wenn es hilft.
Moin,
war doch grade mal neugierig und hab nachgeschaut: Die Funktion
rfftrad4_fr16() aus der Blackfin-DSP library tut wohl genau das
richtige, scheint inzwischen so einiges dazugekommen zu sein. Vielleicht
findest Du dazu nen Benchmark. Interessant wäre, was bei Overflows
passiert - der könnte bei Werten über (1 << 6) ja im Prinzip bei fract16
schnell auftreten.
Wenn Du Dich aber mit der Arithmetik nicht beschäftigen willst, würde
ich gleich nen float-Chip nehmen. Vom eben getesteten nvidia Tegra2
weiss ich, dass er das locker hinkriegt, allerdings ist das Ding als
standalone-DSP aus Gründen fehlender Dokumentation nicht geeignet.
Grüsse,
- Strubi
Bodo schrieb:>> Mit cleverem Abpuffern kriegt man auf dem Blackfin ne gute>> DMA/Verarbeitungs-Pipeline hin,> könntest Du das bitte etwas näher erläutern?
Damit meine ich eigentlich die klassische "Buffer queue", hier z.B. mit
4 Puffern. Wegen der verteilten Memory/DMA-Busse geht damit
gleichzeitig:
- DMA-Streamen der Eingangsdaten von der Peripherie nach A[0]
- Verarbeitung A[1], Ergebnis nach A[2]
- DMA der Ergebnisse von A[3] nach Peripherie
Die A[] sind entsprechend reservierte Memoryblöcke.
Ist ein Puffer fertig, rücken alle Pointer und DMA-Descriptoren
entsprechend vor (letztere automatisch, erstere sollte man im IRQhandler
verarzten). Etwas knifflig, aber man hat damit die perfekte Kontrolle
über garantierten Datenfluss bei maximaler Performance.
Ich würde mich schon mit der Mathematik beschäftigen nur ist das ein
paar Jahre her wo ich das zuletzt gemacht hatte und es gibt halt
fertigen Code den ich nur aufrufen muss. Zudem ist es auch eine
Zeitfrage.
Vom Preis her wäre der TMS320C5535 interessant.
Wenn ich jetzt nur die FFT Performance von dem finden würde und der
schnell genug wäre, dann wäre meine Welt schon in Ordnung und ich wüste
was ich nehme.
Moin,
dein vorhaben aehnelt einer meiner Projekte, vlt. hilt es dir weiter
wenn ich dir mal ein Beispiel gebe.
Ich verwende ein TMS320C6747 fliesskomma DSP. Taste ein Signal mit einem
5Mhz 16bit ADC ab. Die Daten gelangen parallel an meine DSP. Die DSP
fuehrt staendig FFTs durch und versendet die aufgenommenen und
errechneten daten. Ich mache eine 512 Punkte complex FFT und schaffe 10
durchlaeufe in einer milisekunde, wobei die berechnung der FFT nur 20us
dauert (die DSP hat 350 Mhz)!! Die berechnung einer 1024 Punkte complex
FFT dauert knapp nur 35us.
Wie du in meinem Beispiel siehst, die FFT berechnung nimmt weniger Zeit
in anspruch, als das Samplen von 1024 Punkte mit einem ADC. Bei 5Mhz
brauchst du fuer 1024 Punkte 204,8 us, die FFT aber nur 35us, du hast
also noch massen an Zeit fuer weitere Berechnungen bis zur naechsten FFT
berechnung. (die berechnungen laufen natuerlich alle parallel zum
Sampling des Signals)
Ich habe die DSP fuer 30 EUR bekommen (1 Jahr her). Sie hat bis zu 375
Mhz und ist eine der modernsten one-core DSP in der Serie.
>>zu TMS320C5535
TI gibt für eine 1024-Punkte FFT eine Laufzeit von 7315 CPU-Takten für
diejenigen C55xx Prozessoren an, die einen FFT-Co-Prozessor besitzen.
Als günstigster Vertreter dieser Prozessoren mit FFT-Co-Prozessor ist
der C5535AZHH05 zu nennen. Kostet ca 6 Dollar (1000 Stück) und hat auch
256 KB RAM.
Viele Grüße
Ich kaufe mir jetzt dieses Demokit, da ist alles drin was ich zum
entwickeln brauche und kostest recht wenig.
Blöd ist nur das der DSP ein BGA ist. Das ist halt beim Prototypen
aufbauen etwas lästig, in der Serie interessiert mich das nicht mehr.
Wenn ich die 50MHZ Variante nehme, sollte das immer noch reichen.
Bei 4MHz Daten, 1024 Daten sammeln macht 256us.
7315 CPU-Takte bei 20ns macht 146,3us.
Da sollte noch genug Luft sein zumal die FFT parallel berechnet wird.
Was ist mit den Blackfins, die haben kein son blödes BGA Gehäuse wie die
C55xx? Ich denke das grösste Problem sind die erfordlichen Lagen um alle
Drähte unterm BGA wegzubekommen, kostet Geld.
Hab gestern mit dem bf592 ohne jegliche Optimierung eine 2048 fft in ca
500 us berechnet allerdings hatte ich den Core Takt nicht am maximum
(200 MHz statt 400 MHz). Für dich könnten die BF506 interessant sein
weil die nen On-Chip ADC haben und OnChip Flash. Nur Ram müsstest Du je
nach Bedarf zusätzlich noch per paralle Schnittstelle spendieren aber
das müsstest du auch bei den C55xx.
ZB.:
BF506KSWZ-3F gibts bestimmt auch ein günstiges ezLiteKit.
Viele Grüße
Auch wenn der bf592 mir vom Preis und dem Gehäuse her sehr gut gefällt,
ist Ti um einiges günstiger und hat mehr Power alleine dadurch das die
FFT den DSP nicht belastet.
Ich glaube der TI ist für meine Anwendung der richtige, so viele Pins
hat der nicht, mit 4 Lagen sollte man da alles weg bekommen. Und wenn
nicht, auch nicht schlimm, ich brauche kaum Pins.
Wenn ich mich nicht verlesen habe hat der nur 64 Pins.
Und ich brauche nur Power, Takt, der ADC und eine SPI zum raus senden
der Daten.
Peter schrieb:> Auch wenn der bf592 mir vom Preis und dem Gehäuse her sehr gut gefällt,> ist Ti um einiges günstiger und hat mehr Power alleine dadurch das die> FFT den DSP nicht belastet.
Soweit ich weiss, liegt der 592 in 100ern bei ca. 2-3 Dollar...
Leider habe ich zudem (bzw. die Kunden) bei TI die Erfahrung gemacht,
dass man die versteckten Kosten (Toolchain, JTAG) nicht unbedingt
vernachlässigen darf, sobald's in die Produktion geht. Beim Blackfin
gibt es wenigstens die alternativen GNU-Toolchains und third party
Programmer. Bei TI liess man da nochmal vor einer Weile ca. 5000€
liegen, aber das kann sich (hoffentlich) geändert haben.
Grüsse,
- Strubi
In dem Demokit ist doch angeblich alles dabei.
Ob da was von nicht für Produkte drin steht ??? Wen Interessiert den so
was?
Beim Demokit für den bf592 habe ich nicht sehen können ob alles
notwendige dabei ist. Ich hatte früher mal Kits von dennen und da war
immer nur ein Bruchteil der normal nötigen Entwicklungstools dabei.
also der TI Chip hat trotz des Co_processing dann doch schon einiges mit
der CPU zu tun um die FFT zu rechnen, die ezKit sind komplett "out of
the Box" genau wie die von Ti-Kits nutzbar. Also Programer mit auf der
Platine und DSP++Lizens für das gekaufte Eval Board.
Vom Preis Leistungsverhältnis sind die Analog Devices-Chips (je nach
Anwendung) besser. Zumindest wenn es nur auf die Rechenpower ankommt:
TI günstigster C55xx kostet 1,99 Dollar 50 MHz
AD günstigster ADSP592-2 kostet 1,99 Dollar 200MHz
Unterschiede gibt natürlich noch in den verschieden angebotenen
Schnitstellen und unterstützten Formate u.s.w. aber SPI, I2C,
konfigurierbare schnelle serielle Schnittstelle zB für I2S, UART haben
beide.
Zudem könnte es sein, dass, was TI als FFT-Co-Prozessor bezeichnet,
einfach einige Funktionen für die FFT (vielleicht die zum berechnen der
Butterflys)fest in den ROM-Speicherbereich eingebrannt haben und somit
besonders schnell auf`m Bus liegen können. Ich vermute man kann das
gleiche auch mit BF´s hinbekommen mit Nutzung von DMA-Kanälen u.s.w -->
da wird die CPU auch entlastet. Wenn ich das richtig verstanden habe,
ist das DMA-Getöse nichts anderes als ein Co-Prozessor der halt irgendwo
Daten, Koeffizienten oder was auch immer an die MAC-Units, Perepherien,
CPU oder an die Speichbereiche schauffelt.
Viele Grüße
Irgendwie habe ich immer mehr fragen und bin immer unsicherer.
Ich überlege es mir bis Montag und dann wird einfach eins der Demokits
besorgt und getestet. Vielleicht hole ich auch beide und vergleiche
selber was die so machen.
Vom Preis nehmen die sich ja nichts und somit ist es letztendlich nur
eine Frage der Tools und der Performance.
Klausi schrieb:> Zudem könnte es sein, dass, was TI als FFT-Co-Prozessor bezeichnet,> einfach einige Funktionen für die FFT (vielleicht die zum berechnen der> Butterflys)fest in den ROM-Speicherbereich eingebrannt haben und somit> besonders schnell auf`m Bus liegen können. Ich vermute man kann das> gleiche auch mit BF´s hinbekommen mit Nutzung von DMA-Kanälen u.s.w -->> da wird die CPU auch entlastet. Wenn ich das richtig verstanden habe,> ist das DMA-Getöse nichts anderes als ein Co-Prozessor der halt irgendwo> Daten, Koeffizienten oder was auch immer an die MAC-Units, Perepherien,> CPU oder an die Speichbereiche schauffelt.
Wir haben die Erfahrung gemacht, dass vorgefertigte Sachen bei TI gut
funktionieren, aber sobald man selbst Finetuning mahen muß die
Hardwareerweiterungen unflexibel sind und nicht helfen.
Die Blackfin-Assembly-Language ist da deutlich cleverer designt und auch
besser zu lesen (bißchen wie C). So insgesamt kann man mit den BF mehr
machen obwohl sie weniger Superduperfeatures im Datenblatt stehen haben.
Allerdings arbeiten wir auch mit den größeren Blackfins (52x aufwärts).
Mir pers. gefällt, daß alle Varianten denselben homogenen Kern besitzen
und die Programme gut auf neue BF-Serien portabel sind.
Aber es kommt ers auch auf gute Betreuung durch FAE an. Die war vom
Hersteller eher dürftig und wir mussten externe Hilfe einkaufen.
Wenn man möglichst wenig selbermachen will und muß, kann man bei TI mit
den FAE mehr Glück haben, aber man kann nach meiner Erfahrung die
Fertiglösung dann schlecht erweitern. Nervig ist auch, dass man manche
Informationen schlicht nicht bekommt.
