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
