Hallo,
bei kleinen Mikrocontrollern fällt die Antwort hier ja recht eindeutig
aus...
Kann man bei DSPs eine ähnlich eindeutige Empfehlung aussprechen?
Besonders wichtig sind mir:
- kostenlose Entwicklungsumgebung
- floating Point
- aktive Community im Netz
- privat verfügbare Entwicklungsboards
Für den Anfang will ich damit kleinere Experimente im Audiobereich
machen, später aber auch Radioanwendungen und Imageprocessing.
Ich habe keine Lust mich für jede Anwendung in eine neue Architektur
einzuarbeiten, daher will ich von Anfang an etwas was alles kann.
Da ich nur individuelle Einzellösungen und Prototypen/Studien machen
werde spielt der Preis kaum eine Rolle.
Gruß,
Thomas
Die FPU wird die Auswahl sehr einschränken. Aber es gibt einige ARM9
Prozessoren die noch einen FPU zusätzlich haben. Das sind dann aber idR.
größere Geschütze. Vielleicht verzichtest Du erst mal auf die FPU und
machst die Fließkommaberechnung in Software. (Dann natürlich nicht für
Filter etc.)
Dann ist z.B. die SAM9-Serie von Atmel sehr schön.
Viele Grüße,
Martin L.
Hallo und danke für die Tips.
Den Artikel kenne ich bereits, aber Infos bezüglich kostenloser
Entwicklungsumgebung fehlen da leider.
Wenn ich sehe, dass ein C Compiler da locker mal einige k€ kosten kann
ist das für mich das wichtigste Kriterium.
Auf die FPU wollte ich für Prototypenentwicklung aber eigentlich auch
nicht verzichten, da das ja einiges vereinfacht und auch beschleunigt.
Gibt es vielleicht Hersteller, die wenig eingeschränkte
Entwickslungstools für die nicht kommerzielle Nutzung bereitstellen?
ARM9 egal ob mit oder ohne FPU ist ja wohl keine DSP Architektur und für
Radioanwendungen und komplexere Audioeffekte sicher zu langsam...
Wie gesagt habe ich auch kein Problem damit direkt gößere Geschütze
aufzufahren, ich habe eh nicht vor eigene Boards zu entwickeln.
Besonders interessant fand ich die (Tiger)SHARCs, da ich mit deren
Architektur bereits ein wenig vertraut bin, aber VisualDSP++ kostet ja
auch wieder über 3000€.
Gruß,
Thomas
Floating Point DSPs gibts allgemein recht wenig.
Die beiden üblichen Verdächtigen sind halt AD (...Sharc) und TI (67000
und Konsorten wie Davinci). Compiler gibts da afaik nicht günstig.
Für einfachere Sachen würde ich mir wirklich überlegen, ob Fixed Point
nicht ausreicht, da sollte z.B. ein Blackfin eine bezahlbare Lösung
sein.
Eine weitere Lösung, die auch hochperformant sein kann, ist der Einsatz
von FPGAs zur Signalverarbeitung.
Vorteile:
- hoch parallelisierbar, extrem hohe Geschwindigkeiten erreichbar
- Entwicklungsumgebung für kleine Bausteine umsonst
Nachteile:
- Algorithmen in VHDL abbilden ist komplizierter und weniger flexibel
als in C
- Auch hier sollte Fixed Point bevorzugt werden, da Floating Point
zuviel Logik schluckt.
Der Blackfin ist mir auch schon aufgefallen, da er aufgrund des Linux
Ports wohl der beliebteste DSP in der Community zu sein scheint.
Für diesen habe ich allerdings keine Verwendung, da ich eh hauptsächlich
Echtzeitanwendungen schreiben werde.
Gibt es denn dafür auch eine freie Entwicklungsumgebung ähnlich wie
WinAVR, die ohne Linux (auf dem Target) auskommt?
Ein FPGA kommt für mich nicht in Frage, sowas werde ich nur im konkreten
Einzelfällen einsetzten, die sich mit einem DSP nicht mehr erschlagen
lassen.
Was ich suche ist eine Prototyping-Plattform, auf der man mal schnell
was in Echtzeit ausprobieren kann, deswegen hätte ich ja auch gerne
Floating Point.
Weiß jemand, ob sich die Evaluierungsversion von VisualDSP++ nach den 90
Tagen einfach erneut installieren lässt?
Womit arbeitet ihr denn so privat? Beschäftigt sich da etwa keiner mit
DSPs, oder nutzt ihr vielleicht Raubkopieen der Entwicklungstools?
Gruß,
Thomas
Ich benutze einen Blackfin (BF537). Die VisualDSP++ IDE ließ sich einmal
mehrmals installieren, ob das bei der aktuellen Version ebenfalls
möglich ist kann ich nicht sagen. Meines Wissens gibt es für die BF's
eine GCC Portierung, dass dazu Linux auf dem Kern laufen muss ist mir
allerdings neu - ich hab' mich noch nicht damit beschäftigt. Wenn du
unbedingt in Fließkomma rechnen musst, solltest du schonmal anfangen zu
sparen, ein gescheiter FP-DSP kostet 1k€ aufwärts. Hinzu kommt die IDE.
Um Dinge auszuprobieren, sollte es genügen mit Fließkomma auf einem
Festkomma-DSP zu rechnen - soviel Leistung ist allemal vorhanden (im
Anhang eine kleine Gegenüberstellung des Rechenaufwands eines
FIR-Filters).
Hallo,
Was die Gnu Toolchain (GCC, GDB, etc.) zum Blackfin angeht, ist es
ueberhaupt nicht zwingend, Linux zu nehmen. Es gibt auch die
"standalone"-Variante des Compilers, mit der Newlib C-Library kann sich
jeder seine eigenen Echtzeitbetriebssysteme basteln.
Opensource-Beispiel zum Blackfin gibts unter
http://www.section5.ch/software, siehe "shell" (primitives
Shell-Programm) oder "blinky" (noch primitiveres Blinkerchen fuer
diverse Boards). Die Toolchain kriegt man dort auch (nur DEBIAN pakete),
natuerlich fuer umme. Die offizielle Seite blackfin.uclinux.org
supported zwar hauptsaechlich Linux, aber das soll ja nicht stoeren.
Zum Thema Fliesskomma: Fuer Audio/Video-Signalverarbeitung ist
normalerweise kein Fliesskomma noetig, obwohl viele DSP-Libraries aus
Bequemlichkeit mit Floats arbeiten, was eigentlich ziemlicher Unsinn
(und Resourcenverschendung) ist. Rundungs und Akkumulationsfehler sind
bei Float teils viel kritischer, gerade wenn es um Fehlerabschaetzungen
bei numerischen Algorithmen geht. Wenn der Wertebereich beschraenkt ist
und keine hohe Genauigkeit erforderlich ist (wie bei Audio / Video der
Fall) arbeitet man lieber mit Fixkomma.
Ich arbeite quasi "von Anfang an" mit dem Blackfin, die
Kinderkrankheiten sind inzwischen beseitigt, so kann ich inzwischen mit
gutem Gewissen sagen, dass er einer der besten "thin client" DSPs auf
dem Markt ist, da er eben nicht nur DSP, sonden auch noch
Microcontroller-Qualitaeten hat. Man kann sich also seine Hardware damit
beliebig skalieren, sei es ein kleiner schneller DSP fuer Audiosachen
mit Codec, ohne externes SDRAM, oder eine digitale Kamera mit
MPEG-Verarbeitung und uClinux, usw.
Die GNU-Toolchain ist inzwischen meiner Meinung nach besser als die
teuren VisualDSP-Tools - halt mit dem Nachteil, dass sich der
Anfangsaufwand fuer GNU-Neulinge erst bei groesseren Projekten
amortisiert.
Es gibt dann auch noch die Klicki-Bunti-Tools wie Matlab, Labview, etc.,
aber fuer Produktreife und Stabilitaet sind letztere leider nicht
wirklich zu gebrauchen.
Wir haben uns damals auch die aequivalenten Dinger von Texas angeschaut,
uns dann aber fuer die Analog-Devices-DSPs entschieden, die
Entwicklungstools sind da einfach besser und billiger, und die
Linux-Option ein deutliches Plus.
Die Xenomai-Echtzeiterweiterung zu uClinux auf dem Blackfin ist
uebrigens ziemlich gut, wenn Latenzen um 30-50 us ausreichen. Es gibt
auch noch einen RTEMS-Port..
Gruss,
- Strubi
>Rundungs und Akkumulationsfehler sind bei Float teils viel kritischer
Nur wenn man 32 Bit Float mit vollen 32 Bit Fixed vergleicht, was dann
auch nicht mehr so wahnsinnig effizient ist. Bei mindestens gleich
großer Mantisse ist Float grundsätzlich besser. Man darf natürlich nicht
glauben man könne Dinge wie 100000000 + 0.000001 rechnen, nur weil man
sie hinschreiben kann. Mit Fixed Point kommt man gar nicht erst in
Versuchung, aber als Vorteil würde ich das nicht bezeichnen.
