Moin,
zu den TIs muss man sagen, dass die DM/DaVinci und OMAP-Teile schon im
Prinzip mit dem gcc funktionieren, da ARM-Core.
Was nur ein absoluter Graus ist: das Debuggen. Die TI-Architekturen sind
absolut inhomogen, ein Wildwuchs von verschiedenen Cores und
Peripherals, also nicht wirklich was fuer Einsteiger (von den Piccolos
abgesehen).
Drum die Frage: Warum nicht gleich nen gaengigen ARM?
GCC ist zwar ein Allround-Compiler, aber beim z.B. beim Blackfin wuerde
ich behaupten, dass er besseren Code generiert als die proprietaere
VDSP-Toolchain (die ich fuer vernuenftige Projekte eher nicht so
effektiv ist). Was ARM angeht, ist der Support sowieso schon sehr
ausgereift.
Und das wichtigste zuletzt: Der Debugger-Support. Bei ARM und Blackfin
funktioniert das prima mit GDB und den entsprechenden JTAG-Backends:
- OpenOCD auf dem ARM
- ICEbear/gdbproxy auf dem Blackfin
Der Teufel steckt im Detail (mit all den verschiedenen Architekturen),
aber gerade bei ARM und Blackfin bleibt man als zur Effektivitaet
gezwungener Mittelstands-Entwickler am wenigsten stecken. Bei TI DSPs
(abgesehen von ARM) ist mit vielen versteckten Kosten und viel "closed
source" zu rechnen, die auf den ersten Blick bessere Leistung (was z.B.
Videokompression angeht) lohnt sich nur, wenn man GENAU die vorgegebene
Anwendung benutzt und nicht mehr debuggen muss.
Unsere Strategie:
1. Unter Linux/gcc die Algorithmen entwickeln (moeglichst
plattformunabhaengig)
2. Library auf den Target portieren
3. Noetige Hardware-Layer schreiben
Funktioniert prima, und der gleiche Code tut dann dank GCC sehr gut auf
verschiedenen Plattformen.
Gebe zu, ich bin inzwischen schon solch ein GCC-Nazi geworden, dass ich
keine von GCC nicht unterstuetzte Plattform mehr anfasse...
Gruesse,
- Strubi