Wir sind im Begriff, die hardwarnahe Softwareentwicklung, welche bislang von Zulieferern und einer externen Abteilung im Konzern getätig wurde, ins Haus zu holen, weil es inzwischen eine Reihe von Eigenknowhowthemen gibt, die wir selber bearbeiten möchen (und müssen!). Dazu soll ein angemessenes Entwicklungssystem erworben werden, das strukturierte Planung, Codierung und Dokumentation des Codes zulässt und unterstützt. Konkret geht es um die Implementierung von hochperformanten Algorithmen auf modernen DSPs. Hersteller und Typ der DSPs and dabe genau so offen, wie die toolchain! Fragen: Würden die Fachleute hier im Forum dazu raten, sich auf einen Hersteller zu fokussieren und wenn ja, welchen? Oder existiert eine gute herstellerunabhängige IDE, mit denen wir arbeiten und dann passend auf DSPs verschiedener Hersteller, je nach Produkt portieren könnten? Wer hat dazu einen Ratschlag?
Hallo Softwerker, generell würde vermutlich jeder möglichst systemunabhängig bleiben, aber bei den DSPs in der oberen Liga wird's schwierig. Du müsstest uns vielleicht noch verraten, wo die Reise ungefähr hingeht (Hardware-Float? MIPS?) Die grösstmögliche Systemunabhängigkeit hat man vermutlich mit GCC und Eclipse als IDE. Das ist auch vordergründig der günstigste und flexibelste Setup - wenn man einen Experten an Board hat, oder sich die Sache im Rahmen einer Schulung aufsetzen lässt. Leider steckt der Teufel wieder im Detail.. Ich fasse kurz mal meine aus-dem-Kopf-Liste zu den verschiedenen DSPs zusammen (zu denen nehme ich jetzt auch mal die ARMs hinzu) plus meine persönliche Wertung betr. Effizienz der Toolchain (!) - ARM-Derivate (Tegra, TI/OMAP, ..): GCC [++] - Blackfin DSP-Familie : VisualDSP++ [0], GCC [++] - (Tiger)SHARC : VisualDSP, GCC veraltet (unbrauchbar) - TI DSPs ohne ARM core (C6000) : TI-Toolchain soll inzwischen ganz gut sein (damals war sie mies), GCC status unbekannt. Zum Thema IDE fällt mir grade noch Crossworks von Rowley Associates ein. Die basiert m.W. auf GCC und hat mir recht gut gefallen. Lief damals relativ auf Anhieb auf verschiedenen ARM derivaten. Das Problem allgemein bei DSPs bzw. -extensions: um die volle Performance rauszuholen, muss man Kernalgos oft in Assembler umsetzen. Das macht seltenst einer der Compiler richtig gut. Das würde für ARMs sprechen, aber da muss man wieder genau hinschauen, ob der alternative Kandidat die DSP-Extension auch hat. Und dann noch der letzte Aspekt: Manche Algorithmen lassen sich prima auf einem FPGA umsetzen, gerade wenn es um linear abzuarbeitende Pipelines geht. Der Vorteil ist da die optimale Kontrolle über die Arithmetik (mal eben 64 bit Fixkomma rechnen braucht keine handgestrickten Workarounds auf dem DSP...). Hätte das früher nicht für wirtschaftlich gehalten, inzwischen hat sich's längst amortisiert und auf dem DSP läuft nur noch etwas DMA und Networking. Grüsse, - Strubi
Bitte 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.