www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Blackfin: Übersicht der Software Development Tools


Autor: David R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin heute auf die Blackfin Development Boads von Analog Devices 
(ADI) gestoßen. Die von ADI verkaufte Software VisualDSP++ ist leider 
etwas teuer.
Wie ich hier im Forum aber gelernt habe gibt es auch (u.a.) Open Source 
Alternativen. U.a. musste ich aber auch lesen, dass die Alternativen 
ggf. mit mehr Einarbeitungszeit verbunden sind.

Deswegen wollte ich mal fragen wie die Alternativen zu VisualDSP++ im 
Moment aussehen. Was ich wissen möchte ist vor allem
 * wie reif/stabil sind die Anwendungen,
 * wie gut ist die Dokumentation,
 * wie sieht es mit dem Support aus,
 * wie ist der Einarbeitungs-Aufwand im Vergleich,
 * welche Abstriche muss man machen (Features),
 * wie sieht es mit Debugging aus,
 * und in welcher Größenordnung der Preis liegt?

Noch zur Einarbeitungszeit: Ich kenne mich zugegebenermaßen nicht gut 
bis DSPs aus (Man kann ja nicht alles wissen). Deswegen brauche ich eine 
Entwicklungsumgebung auf die Verlass ist und wo kein "Rumgefrickel" 
notwendig ist, denn das erfordert meistens genaue Kenntnisse der 
Plattform und viel Zeit.

So wie ich das sehe gibt es im Moment 3 Möglichkeiten:
 * VisualDSP++ (Kann alle Prozessoren programmieren, volles Debuging, 
kostet viel)
 * MULTI
 * GNU Compiler Collection mit Eclipse

Ach und sehe ich das richtig, dass ich um uneingeschrenkt zu debuggen 
ein JTAG von ADI oder section5 brauche?

Ich weiß, dass hier im Forum schon viele Informationen stehen. Aber die 
Beiträge beantworten meine Fragen nur halb und sind auch meistens schon 
alt.

Viele Grüße und Dank im Voraus,
David

Autor: BoeserFisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du stellst recht viele Fragen :-)
In der Tat muß man sich einiges zusammensuchen und kricht's nicht auf 
dem Präsentierteller.
Hier meine Meinung:

 * wie reif/stabil sind die Anwendungen,

Stabiler und reifer als mit VDSP. Kein Witz, die GCC-Leute haben 
offensichtlich die ganzen Processor-Feinheiten und Anomalien besser im 
Griff.

 * wie gut ist die Dokumentation,

Muß man sich zusammensuchen. Meine Resourcen:

- docs.blackfin.uclinux.org (µcLinux-Sachen)
- Blackfin Hardware-Manuals
- ICEbear manual, Foren bei section5.ch und surveyor.com

 * wie sieht es mit dem Support aus,

Bei ADI ist der Support mäßig, manchmal hab' ich den Eindruck, die 
kennen ihre eigenen Produkte nicht, oder verstehen nicht so gut Englisch 
(nix gegen Support aus Indien, aber manchmal gibts halt 
Verständigungschaos). Bei Surveyor und section5 finde ich den Support 
soweit gut. Aber man muß englisch können!

 * wie ist der Einarbeitungs-Aufwand im Vergleich,

Der ist schon etwas höher, man muß mit GCC etwas Bescheid wissen. Als 
Linux-Freak kann man aber prima alles erst mal auf dem PC ausprobieren.

 * welche Abstriche muss man machen (Features),

Ohne Eclipse ist alles halt nicht zum Klicken und nicht aus einem Guß. 
Geschmacksache, aber ich mag Makefiles und Skripte lieber.

 * wie sieht es mit Debugging aus,

Funktioniert mit meinem ICEbear besser als mit VDSP - das habe ich nach 
zig Abstürzen in die Tonne getreten (tat nicht weh, war nur eine 
Testlizenz), abgesehen davon ich sowieso lieber unter Linux entwickle.
Zum Debuggen nahm ich anfangs Insight (grafisch), inzwischen lieber die 
Konsole des gdb (Skripte).

 * und in welcher Größenordnung der Preis liegt?

Der ICEbear war nicht billig, aber noch nicht im Bereich der 
ADI-Adapter. Funzt unter Linux und windows und ist schneller als das 
EZKIT-JTAG-Gehudel.
Gab mal Studentenrabatt, müßte um die 130 Euronen gewesen sein.

Ein Gefrickel war's überhaupt nicht - sofern Du GCC/make nicht als 
Gefrickel ansiehst. Habe mir noch den Democode von section5 installiert, 
lief auf Anhieb auf dem EZKIT. Bei VDSP hab ich eine Stunde gebraucht, 
bis er den JTAG vom EZKIT richtig erkannt hatte.

Also ich kann den GCC-Kram empfehlen. Für größere Projekte (µcLinux) 
sowieso..

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

kann mich dem BoesenFisch soweit nur anschliessen.
Mein Fazit, nach vielen Jahren Ausprobieren: Die GCC-Toolchain ist 
unschlagbar geworden, was hardwarenahe (Betriebssystem-) Entwicklung 
angeht. Aber zugegebenermassen fuer Einsteiger nicht immer einfach zu 
erlernen. Steht aber alles hier schon im Forum in diversen Beitraegen 
(ggogle mal nach Blackfin shell oder so)
Fairerweise muesste man ev. sagen, dass VDSP besser geworden ist, dafuer 
umso inkompatibler zum ELF-Standard.
Tja, der ICEbear wurde auch aus dem Grund entwickelt, um stabiler zu 
sein als die offiziellen Tools - nichts ist nerviger, als einen Debugger 
wiederum debuggen zu muessen.
Du kannst uns ja auch mal sagen, was du genau machen willst (uClinux? 
Bare Metal/Standalone, direkt HW ansteuern? Welche Plattform, was fuer 
I/O?).

Gruesse,

- Strubi

Autor: David H. (david_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin der David, der sich im Beitrag #1707930 David R. nennt.

Hallo,

vielen Dank BoeserFisch und Strubi für eure Antworten! Ich glaube viel 
treffender hättet ihr nicht antworten können.

Martin S. schrieb:
> Du kannst uns ja auch mal sagen, was du genau machen willst (uClinux?
> Bare Metal/Standalone, direkt HW ansteuern? Welche Plattform, was fuer
> I/O?).

Es sieht so aus, dass ich mich im Moment nach einer leistungsfähigen 
MC-Plattform umschaue und dabei auf den Blackfin DSP als potentiellen MP 
gestoßen bin. Im Prinzip muss es nicht unbedingt ein DSP sein. Ich 
möchte aber einen Regelungsalgorithmus implementieren, der eine harte 
Echtzeit von 100µs einhalten und dabei ~200-300 (FP)-Operationen 
ausführen muss. Ich denke so etwas sollte mit den Blackfin MP machbar 
sein.
Ich habe mich dann nicht mehr genau mit dem Spezifikationen des 
Blackfins auseinandergesetzt als ich gesehen habe, dass die 
Software-Linzenzen so teuer sind. Deswegen habe ich hier erst mal 
nachgefragt wie es denn im Moment mit den Alternativen aussieht.

uClinux oder nicht? Ich sehe das im Moment so (korrigiert mich wenn ich 
falsch liege): Ein RTOS würde mir die Ansteuerung der HW erleichtern. 
Diesen Vorteil hätte ich auch bei µClinux auch aber µClinux ist ja kein 
RTOS, würde mir also keine Antwortzeiten garantieren. Liege ich da 
richtig?

Zur I/O: Ich müsste grob eine Handvoll (~6) AD/DA-Wandler ansprechen und 
hätte gerne ein Ethernet-Kommunikationsinteraface On-Chip (einige 
Blackfins haben ja eine Ethernet MAC...).

Welche Plattform ich benutzen würde weiß ich noch nicht. Habe nur 
gesehen, dass es von ADI die Eval-Kits gibt (EZ-KIT, EZ-Board).

BoeserFisch schrieb:
>  * wie ist der Einarbeitungs-Aufwand im Vergleich,
>
> Der ist schon etwas höher, man muß mit GCC etwas Bescheid wissen. Als
> Linux-Freak kann man aber prima alles erst mal auf dem PC ausprobieren.
> [...]
> Ein Gefrickel war's überhaupt nicht - sofern Du GCC/make nicht als
> Gefrickel ansiehst.

Ja mit GCC/make habe ich schon gearbeitet. Aber ich kenne mich da jetzt 
nicht gut aus. Bin jetzt nicht so der Fan von Makefiles und auch kein 
Linux-Freak aber mit beidem schon gearbeitet.
Für mich hat es eine hohe Priorität, dass ich meinen Regler möglichst 
schnell umsetzen kann. Da ich mich nicht so gut ausgekenne wird das wohl 
auf Kosten von Effektivität und Geld gehen die ich aber bereit bin 
einzugehen. Leider wäre das auch nur eine einmalige Aktion, so dass 
monatelange Einarbeitung sich nicht rentieren würde.

Ich habe bisher immer mit den 'kleinen' AVRs gearbeitet und habe noch 
keine Erfahrung mit RTOS. Aber hier im Forum findet man ja schon 
einiges.

Viel Grüße,
David

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi David,

die Frage, ob uClinux oder Standalone (eigenes "OS" schreiben) ist 
knifflig: Entweder laeuft es schon fast "from the box" mit deinem ADC 
und Du hast nur noch mit dem "Userspace"-Programm zu tun, oder du hast 
die ev. komplexe Aufgabe vor dir, einen Kerneltreiber schreiben zu 
muessen.
Wenn du das ganze Netzwerk-Geraffel aussenrum nicht brauchst, lohnt sich 
uClinux meistens nicht. Sobald du die Hardware irgendwie kennenlernen 
musst, stehst du wieder bei der "Standalone"-Entwicklung an, einen 
UDP-Stack kriegt man auch noch geschrieben.
Wir fahren meistens zweigleisig, Hardware erst mal standalone ansteuern, 
und das dann ins Kernel integrieren.
Zum Thema RTOS: Es gibt auch RTEMS und andere Ports fuer den Blackfin, 
aber mit der Xenomai-Echtzeiterweiterung unter Linux bekaemst du eine 
garantierte Prozess-Latenzzeit von einiges unter 100 us, also die Zeit, 
die vom Eintreffen der Daten bis zur Reaktion deines Userprogramms 
darauf, verstreicht.
Habe das mal recht akribisch durchgemessen :-)
Ein gewisser Jitter um einige us ist allerdings dabei, jenachdem was 
dein System sonst so macht. Nachteil an der Geschichte: Du musst die 
Realtime-API benutzen, und zwar auf Treiber, wie auch auf 
Userspace-Seite.

Es gibt uebrigens auch Regeltechnik-Loesungen mit Labview (Bloecke 
grafisch zusammenhaengen, in Code 'backen', auf den Blackfin 
runterladen), bin aber skeptisch, ob die wirklich robust genug fuer ein 
Produkt sind, fuer Ausprobieren tun sie's aber wohl allemal. Kostet halt 
nur viel Geld...

Gruesse,

- Strubi

Autor: David H. (david_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Strubi,

Martin S. schrieb:
> die Frage, ob uClinux oder Standalone (eigenes "OS" schreiben) ist
> knifflig: Entweder laeuft es schon fast "from the box" mit deinem ADC
> und Du hast nur noch mit dem "Userspace"-Programm zu tun, oder du hast
> die ev. komplexe Aufgabe vor dir, einen Kerneltreiber schreiben zu
> muessen.
Da ich unter Zeitdruck stehe habe ich nichts dagegen "nur noch" das 
Userspace Programm zu implementieren.

> Es gibt uebrigens auch Regeltechnik-Loesungen mit Labview (Bloecke
> grafisch zusammenhaengen, in Code 'backen', auf den Blackfin
> runterladen), bin aber skeptisch, ob die wirklich robust genug fuer ein
> Produkt sind, fuer Ausprobieren tun sie's aber wohl allemal. Kostet halt
> nur viel Geld...
Das klingt aber Interessant. Ins besondere weil meine Kollegen sowieso 
nicht gerne C programmieren sondern lieber Blöcke zusammenklicken. Und 
Labview haben wir hier sowieso.
Meinst Du die "ADI Blackfin Deployment Option"? Die kostet leider noch 
mal 6k$/Jahr. Da ist dann aber auch VisualDSP++ 5.0 drin.

Ich werde mich mal weiter umschauen. Vielen Dank schon mal!

Grüße, David

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi David,

ich weiss nicht mehr genau wie das hiess, ob's nun von National oder ADI 
angeboten wurde. Ich glaube aber, die Entwicklungsumgebung war deutlich 
teurer, damals zumindest eher im Bereich 30000 EUR. Die braucht man 
wohl, wenn man eigene Treiber fuer die Peripherie unter Labview 
schreiben will. Frag doch sonst mal die Jungs von Schmid Engineering an 
(http://www.schmid-engineering.ch), die haben da diverses entwickelt.

Gruss,

- Strubi

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.