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.
Die Aufgabe ist wie schon gesagt, Das Signal aufnehmen und 1000 mal pro Sekunde ein Ergebnis der Frequenzverteilung ausgeben.
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
> Mit cleverem Abpuffern kriegt man auf dem Blackfin ne gute > DMA/Verarbeitungs-Pipeline hin, könntest Du das bitte etwas näher erläutern?
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.
Beim TI 5535 liegen die Routinen zum Ansteuern des FFT-Copro im ROM. Der Copro selber arbeitet parallel zur CPU...
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.