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
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..
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
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
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
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.