...hier wären wir...
Ein bisher sinnloser und substanzfreier Thread, findet ihr nicht? Wollt ihr den nicht nochmal löschen und neu anfangen? (Meinen Kommentar bitte auch löschen)
Danke für den Hinweis...und für alle anderen die sich die gleiche Frage stellen, was das eigentlich soll: Beitrag "Re: Konfig DSP Blackfin BF548 - Einstieg Analog Devices uC" Der vorhergehende Thröd(Siehe link^^^^)!
@Dirk ...Mich würde mal interessieren, nach welchen Gesichtpunkten dieser BF Processor überhaupt ausgewählt wurde. Strubi hat das ganze schon mal angeschnitten - aber wie möchtest du denn überhaupt sicherstellen, dass dieser uC für deine Applikation geeignet ist? Anforderungen? Viele Grüße
hallo Joe Joe, ich weiß schon gar nicht mehr, wie ich mit Emulator, Evalboard, und VDSP umzugehen habe. Zu lange nichts in dieser Richtung gemacht. Kann mich nur an ein enormes Basement in C erinnern, damit alle Register und der BF an und für sich initialisiert war. Und das Evalboard mir VGA Touchscreen, 40GB-HDD, und etliche anderen Zugangsmöglichkeiten ist umfangreich in der Ausstattung. Habe aber schon Filme und Bilder auf dem Screen laufen gehabt. Plus Audio. Für meine Anwendung muss ich nicht den kompletten VGA 640x480 bei 8 Bit Farbtiefe bearbeiten. Eher wie in der Industrie etliche 100 Pix. je Frame. Der Einstieg für mich ist eher wie ein Sprung ins Ungewisse, da ich erst im Grunde die Entwicklungsumgebung wieder zum vertrauten " Nebenbei" in den Griff bekommen muss. LG, Dirk
...Alles mit VDK wahrscheinlich, nicht? Ich habe da sehr wenig Ahnung, hauptsächlich mit nacktem BF gearbeitet und wenn dann eigene Treiber benutzt/geschrieben...Mit dem Stack von AD für das USB habe ich ein wenig rumgespielt. Generell verfolgt AD ja da eine ganz eigene Philosophie..Haben, meiner Auffassung nach verschiedene Treiberschichten, die total abstrahiert werden(egal für welche Peripherie/Schnittstelle). Vereinfacht die Benutzung, die Einarbeitung ist aber sehr zeitintensiv. Mit den boot Modi habe ich mich ein wenig beschäftigen dürfen. Finde ich im Prinzip auch sehr interessant. Eigentlich kann man da mit dem Linker die tollsten Sachen zu Fuß machen. Der on-chip Kernel stellt hier auch einiges an Funktionen zur Verfügung. Weiterhin hat man ja für die Init der CPU und der Peripherie den Initcode, den man individuell erstellen und einbinden kann... Konfigurieren lässt sich das Board aber auch über die Projektoptionen, sodass zumindest mal was auf dem Prozessor läuft. Sprich Speicheraufteilung - durch erstellen einer eigenen LDF File oder aber der Startup-Code der ebenfalls automatisch erstellt wird auf wunsch. Das sind so mal die Sachen die mir für einen Start vll einfallen. Die reichhaltige Doku und die Beispiele finde ich so nicht übel, die von AD zur Verfügung gestellt werden... Wenn man sich an das VDK wagt, sollte man sich schon mit BS'en auskennen... Hier würde es mich mal interessieren, wie die Performance des BF unter einsatz vom VDK - natürlich in Abhängigkeit von der benutzung der Peripherie - leidet...? Vll. kann jemand hier mal was zu sagen;)
Moin, Irgendwie hat der Thread ja nicht viel mit Bildverarbeitung zu tun... Von VDK würde ich für professionelle Sachen die Finger lassen. Gibt deutlich besser gereifte OS wie RTEMS, eCos, oder uClinux. Leider ist die offizielle ADI Toolchain dementsprechend grässlich, wenn man komplexere Sachen angehn bzw. debuggen muss. Um den Chip kennenzulernen ist sie aber ok. Und sonst gibt's hier ja genug Artikel zur GNU-Toolchain. Die Performanceeinbussen hängen von der Anwendung ab. Mit gut konfiguriertem Cache macht man bei komplexen Programmen einiges wett, wenn man allerdings hohe Anforderungen an Echtzeit hat und den Chip am Limit der Bandbreite (als echten DSP) fährt, sollte man eher sein eigenes kleines System programmieren. Salute, - Strubi
Hallo zusammen, habe mal nachgesehen, uc-Linux habe ich nicht installiert, soweit ich mich erinnere ist das Tool kostenfrei? Was mich mal interessiert ist, wenn ich ein einzelnen Chip BF592 habe, was wird benötigt, um diesen überhaupt ansprechen zu können. Was ich meine im Falle NEC und Compiler von Keil ist es mit diesen 2 Komponenten nicht getan. Irgend ein Tool, in dem Falle der Compiler von Keil, muß hardwremäßig mit dem Chip kommunizieren können. Die Frage in Kurz nochmals, Was ist erforderlich und wie kommt der selbstgeschriebene Assemblercode in den DSP? LG Dirk.
Dirk Slowik schrieb: > Die Frage in Kurz nochmals, Was ist erforderlich und wie kommt der > selbstgeschriebene Assemblercode in den DSP? JTAG. Einfach mal nach "Blackfin JTAG" hier im Forum suchen. Oder Google. Leider herrscht beim Support der beiden möglichen Tools (VDSP vs. Gnu) immer noch grosse Verwirrung, die VDSP-People von ADI versuchen alles, um bloss zu nichts kompatibel zu bleiben (wie mans von Microsoft kennt). Heisst: man muss sich von vornherein entscheiden, welches OS und damit welche Toolchain man verwendet. GNU ist IMHO flexibler und günstiger, aber ohne Klickibunti (kann Vorteil wie auch Nachteil sein). BTW, auf dem 592 läuft kein uClinux. Der Chip ist mit seinen Routinen im ROM (die man natürlich nicht benutzen muss) vor allem auf VDSP-Anwender zugeschnitten. Gruss, - Strubi
OK, besten Dank @strubi, werde mich mal informieren. BF592 war nur 'en schnelles Beispiel für "Lowcost" und ohne bestehendes Evalboard. Soweit ich mich erinnere, habe ich auch connections zu RTOS uc-Linux. Mal sehen, was so geht. Für mein Bildbearbeitungsprojekt stelle ich mir direktes, Byteorrientiertes Speicherhandling vor. Ist aber Alles noch Phase Blau. Bis dann, Dirk.
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.