Hallo, ich komme gerade an meine Grenzen und hoffe das sich hier jemand fachkundiges rumtreibt, der mir etwas weiterhelfen kann. Von Natur aus bin ich Hochfrequenztechniker, und befasse mich derzeit mit Radarsensoren (universitär - daher nicht kommerziell) Ich bin auf folgendes Problem gestoßen, das meine uC Fähigkeiten weit übersteigt (AVR, PIC etc. Ich möchte 8 Kanäle simultan abtasten (Nutzfrequenz ca 60kHz) Abtastfreqeunz sollte im Bereich von min 200 kHz sein - mehr ist besser. Von den ist Daten eine FFT rechnen (Punktlänge variabel), und das Ergebnis der FFT über Ethernet an einen Rechner zur weiteren Verarbeitung schicken. Von der Datenrate sollte das ganze funktionieren. Ich bin nun auf der suche nach etwas Starthilfe. Wie umfangreich ist so ein Projekt? Welche Controller? Mein Blick ist auf die ARM9 Controller von TI mit DSP Core gefallen Kriterien sind Verfügbarkeit, Performance und Unterstützung mit Entwicklungstools durch den Hersteller. Macht es sinn die Aufgabe zu splitten, ein Controller als Rechenknecht, einer als Steuerung und Kommunikationscontroller? Kann jemand ein passendes EVAL Board empfehlen? Oder sagt gar jemand, ich hab mal so etwas ähnliches gemacht - lass uns uns mal zusammentelefonieren. Gerne tausche ich Wissen auf dem Gebiet der HF Technik >80GHz, Messmöglichkeiten, oder Simulations know How. Über Feedback freue ich mich! Gruß Steffen Kontakt auch über: steffen.lutz@ieee.org
Hi, fuer solche Sachen (Digital-Radio) setzen wir typischerweise Blackfin von ADI oder FPGAs (diverse) ein. Vorteil gegenueber TI ist die homogene Architektur. Debugging von ARM und TMS-architektur ist ein nightmare.. Ich wuerde die Aufgaben nicht splitten, das wird normal teurer und aufwendiger. Der Blackfin ist eher wie ein uC was Layout und Handling angeht. Aber einige Vorverarbeitung gescheht hier im FPGA. Vielleicht ist die Platform usrp2 für dich interessant um Algorithmen auszuprobieren (http://gnuradio.org/redmine/projects/gnuradio/wiki/USRP2)
Danke für deine Antwort, am Blackfin bin ich gerade am einlesen, hört sich nicht schlecht an, ich fürchte nur, das dies für mich ein endloses Projekt wird - wie gesagt der Aspekt is wirklich nur das absolute Randgebiet meiner Arbeit. Kann jemand einschätzen, ob soetwas mit einem STM32F417 zu machen ist? Ich weiß auch ARM, aber hier wäre etwas Know How bei Kollegen vorhanden.
Brauchst Du float? Die FPU des M4 kann nur single precision. ARM stellt im Rahmen der CMSIS ("Cortex Microcontroller Software Interface Standard") eine DSP-Bibliothek bereit, die auch FFT-Funktionen bereitstellt und dabei den M4 ausnutzt. Das Zahlenformat hier ist /** * @brief 16-bit fractional data type in 1.15 format. */ typedef int16_t q15_t; /** * @brief 32-bit fractional data type in 1.31 format. */ typedef int32_t q31_t; und float. Benchmarks habe ich auf die Schnelle nicht gefunden. Im Ernstfall besorg Dir ein STMF4Discovery Board für wenig Geld und probiere es aus. Oder frag bei ARM an. Wenn Dir das nicht langt, musst Du einen ARM mit VFP und/oder NEON aussuchen. Das sind dann meist die größeren Cortex-A Chips mit ein paar hundert BGA-Balls, die Du sowieso nicht selber verarbeiten kannst. fchk
Moin, Vorsicht mit float bei Blackfin, der hat keine FPU (und würde dementsprechend viele Zyklen verbraten). Da müsste man schon zu einem SHARC greifen. Aber: Ich würde sowieso empfehlen, bei Signalverarbeitung mit Fixkomma zu arbeiten um Aliasing zu vermeiden und genaue Kontrolle über die digitalen Fehler zu haben. Sobald man bei den TMS und Bfin-DSPs höhere Genauigkeit (wie 64 bit Multiplikationen) braucht, geht's in Assembler nicht mehr mit einem Clock-Zyklus pro Op und man muss sich gute Software-Tricks überlegen. FPGA ist auf jeden Fall eine gute Wahl, da man sich da seine Arithmetik optimieren kann. Bfin (oder ARM)+FPGA ist ein ziemlich effektives Gespann, sitzt inzwischen in einigen Industrieanwendungen (wie auch meinem aktuellen Prototypen). Vorteil an den Bfins ist, dass sie noch in von Hand lötbaren Gehäusen zu bekommen sind. Der Nachteil ist, dass man einige der üblichen Libraries nicht gleich verwenden kann, sondern sie auf Fixkomma portieren oder den Kram gleich neu schreiben muss, wenn Teile ins FPGA ausgelagert werden. Ein potentielles Problem sind auch die Datenkanäle, mit CPU+FPGA ist immer etwas auf Einweg-Datenverarbeitung (Streaming) beschränkt. Es gibt auch interessante Ansätze mit Softcores (CPU im FPGA), bisher bringen die allerdings kaum wirklich Performance auf den "kleinen" Chips. Interessant könnte allerdings die Zynq-Familie sein: Dualcore-ARM und FPGA-Logik auf einem Chip. Aber kann dazu sonst nix weiter sagen (noch nicht angefasst). Bei so hochfrequenten Applikationen hätte ich auch als erstes an den Gnuradio usrp als "Evalkit" gedacht. Damit dürfte sich einiges austesten lassen, aber man muss sich halt tüchtig mit VHDL beschäftigen.. Grüsse, - Strubi
Ist es ein kontinuierlicher Vorgang? Du musst dir Gedanken machen, wie lange du die Daten für die FFT Vorhalten musst? Unabhängig von der Rechenleistung kann schnell der Speicher out of range gehen. Wie echtzeitfähig muss es sein? Ich denk mal drüber nach. Richtung würde allerdings FPGA sein. Reichen 12 bit ADC Auflösung?
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.