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
Hallo dsp's gibts zu hauf, aber solche mit FPU wenig. Schau mal hier: http://www.mikrocontroller.net/articles/Digitale_Signalverarbeitung#Fest-_oder_Flie.C3.9Fkomma.3F Gerhard
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.
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.