Brauche für ein Neuprojekt DSP. Bereich Motion Control, Process Control. SPI für Ausgangserweiterung notwendig. PC Anschluss über USB notwendig. Einigen Internspeicher im MByte Bereich (falls möglich) Mittelschnell. Ich bin schon eine Weile aus dem Metier raus, im letzten Projekt hatte ich so was eingesetzt http://www.ti.com/lit/ds/symlink/tms320f240.pdf Ich bin nicht TI fixiert, kenne aber (das alte) Code composer Studio, wobei das (was ich habe) auf dem aktuellen Windows nicht löuft. Der Speicher ist zu klein, sonst muss der PC zu heftig puffern. EVA Boards und Tools sollten erschwinglich sein. Echtzeit debugging und Process monitoring vom PC wöre schön, MSOs sind aber auch da. Technischer Hintergrund Vom PC kommt Stream an DSP, dieser stellt Zeitsynchronizitöt her und steuert den Prozess/Motion im 100uSek Takt. Welche Entwicklungssysteme / EVA Boards sollte ich mir mal ansehen? EVA Board Preis und Formfaktor spielt eine Rolle da in den ersten sicherlich kein eigenes PCB für den DSP reinkommt...
:
Bearbeitet durch User
Moin Michael, wenn du dich von der grottenschlechten C2000 Architektur verabschieden kannst (Nur meine Meinung), dann wäre der ADSP-CM40x vllt etwas für dich. Ich weiß aber nicht was du für Erschwinglich hälst. DEV Board für den liegt aktuell bei ca. 250€. Gruß Tec
Käme ein Cortex M4 oder M7 in Frage? Die sind zwar keine dezidierten DSPs, haben aber eine DSP-Erweiterung. Von ARM wird für diese Familien eine eigene DSP-Library zur Verfügung gestellt, die kaum Wünsche offenlässt. Erhältlich von verschiedenen Herstellern, z.B. ST: STM32F4xx oder STM32F7xx: 1Mbyte Flash und bis zu 300kByte RAM intern, USB sowieso, Schnittstellen ohne Ende und einen schnellen ADC. Gruß, Stefan
250,- ist schon ok. Wobei ich nachdenklich werde wenn ich so einen Raspberry PI sehe. Wenn man den nehmen könnte, kann man sich bei dem Preis eigenes Board sparen. Aber ob der konstante Zyklen und geringen Jitter hinbeköme weiss ich nicht. analog Devices meintest Du das hier? http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/cm40x-ez.html#eb-documentation
Stefan K. schrieb: > Käme ein Cortex M4 oder M7 in Frage? Die sind zwar keine dezidierten > DSPs, haben aber eine DSP-Erweiterung. Von ARM wird für diese Familien > eine eigene DSP-Library zur Verfügung gestellt, die kaum Wünsche > offenlässt. Erhältlich von verschiedenen Herstellern, z.B. ST: STM32F4xx > oder STM32F7xx: 1Mbyte Flash und bis zu 300kByte RAM intern, USB > sowieso, Schnittstellen ohne Ende und einen schnellen ADC. > > Gruß, Stefan Lib brauche ich nicht, nur schnellen C Compiler. Die benötigten Libs habe ich aus Eigenentwicklungen. Die Architektur schaue ich mir an.
:
Bearbeitet durch User
Hallo, also zwischen einem DSP und einem Cortex M4 oder M7 gibt es aber schon noch unterschiede. Allerdings haben die Cortex M7 Derivaten, besonders der von Atmel mit seinen 300MHz und FPU sogar mit 64 Bit FPU, so manchen DSP der halt so heißt längst überholt. Ich selber setze den Atmel CM7 ein und komme damit gut zurecht. Es kommt aber immer darauf an, was man machen will. Der Cortex A5 ist für DSP auch noch eine feine Maschine. Noch nicht so Komplex wie ein A8 oder A9 aber durchaus brauchbar. Von reinen application Prozessoren wie ein Erbeer PI würde ich eher abraten. Da oftmals nichts mit schnellen Interrupts geht. Der ADSP-CM40x ist leider nur ein CM4 und längst nicht so schnell. Ich würde auch den Focus mehr auf die FPU legen. Das TCM RAM ist bei den CM4 und CM7 extrem wichtig, wenn es um DSP Aufgaben geht. Gruß Sascha Ansonsten sind die DSP der großen Liga gleich extrem teuer.
Michael K. schrieb: > Wobei ich nachdenklich werde wenn ich so einen Raspberry PI sehe. > > Wenn man den nehmen könnte, kann man sich bei dem Preis eigenes Board > sparen. > > Aber ob der konstante Zyklen und geringen Jitter hinbeköme weiss ich > nicht. > Vergiss den Pi, der ist als billige Linuxmaschine ok, aber nix für echte Tealtime-Applikationen. Vor allem kriegst du die Broadcom-Chips nicht für eigene HW in die Finger. Um damit DSP zu machen, müsstest du ihn bare-metal programmieren. Das haben zwar schon einige gemacht, aber die Komplexität ist nicht so ohne. Mit dem internen Speicher wird's im MB-Bereich schnell eng bei den üblichen Verdächtigen. Soll das RAM oder Flash sein? Ansonsten sind für die harten DSP-Sachen die Blackfin-Serien immer noch eine gute Wahl, da geht 'bare metal' wie auch Realtime-Kram unter uClinux sehr gut. Was mich nur stutzig macht: Streamen per USB? Da ist der Jitter schon naturgemäss so gross, dass ein DSP kaum noch Sinn macht. Da bist du mit nem einfachen UDP-Stack oder gleich RTP besser bedient, damit sind Latenzen unter 50 us drin, wenn die Synchronisation über eine längere "lock in"-Time gehen darf, kriegt man sehr niedrigen Jitter hin. Ausserdem ist ein USB-Stack "bare metal" sehr viel mühsamer zu schreiben als ein UDP-Stack auf dem Hardware-MAC (been there).
Sobald der Stream erst mal steht, ist er meiner Erfahrung nach recht stabil, so dass man vielleicht mal Aussetzer von 1/10 Sekunde puffern muss, sicherheitshalber rechne ich mit 5/10. Seinerzeit hatten wir zwei Alternativen, MMTimeSetEvent von Microsoft oder halt Kithara RT Kit. Das ist zwischenzeitlich in einer Preisliga die zum Finalprodukt nicht passt. Also muss der DSP Puffern. Kläre mich bitte mal zu UDP Stack oder RTP auf. Ich bin schon einige Zeit raus. Momentanes Konzept: Frontend Bedienung Netzwerk etc - PC/Windows, technische Vorberechnung Und Stramaufbereitung Windows, Realtime Comtrol des Prozesses DSP.
Michael K. schrieb: > Kläre mich bitte mal zu UDP Stack oder RTP auf. > Ich bin schon einige Zeit raus. UDP kannst Du als einen der niedrigsten logischen Layer direkt über dem Ethernet-Packet (IEEE802 Standard) für typische Datenkommunikation ansehen. RTP ist eine recht dünne Schicht drüber, bei der u.a. noch ein Zeitstempel mitgeht. Wird im allgemeinen als Transportschicht für Audio/Video verwendet, wo man Aussetzer und Desynchronisation der Clocks nicht haben will (PLL-Steuerungen...) Mit den üblichen Verdächtigen, die Hardware EMACs haben und das mit DMA so nebenbei in den Speicher an die richtige Stelle streamen, kriegt man da die Latenzen durchaus im Bereich (Paketgrösse * Taktzyklendauer) hin. Klingt aber so, als ob die 100us nicht die Latenz, sondern nur die Taktfrequenz der Steuerwerte sein sollen. Obiges gilt übrigens nur für "Bare metal", also keine OS-Layer dazwischen, wo man sich durch zig Interrupt-Handler durchhangeln muss. Unter uClinux mit Realtime-Extension kommen noch mal an die 80-100 us dazu, dafür hat man den ganzen Netzwerk-Stack umsonst. Allerdings wirft da der UDP-Stack u.U. Pakete weg und man muss wieder frickeln. Die USB-Lösung z.B. mit BF527 würde ich nicht unter uCinux nutzen, da ist die Latenz/Jitter zu gross. Vor allem kommen irgendwann bei USB viele nervige kleine Details zum Vorschein, einfach mal eben Daten streamen ist da gar nicht so einfach. Zum Konzept: es gibt auch "Hybrid"-Hardware, auf die man allenfalls die PC-Geschichte portieren kann, wenns dann später um Kostensenkung in Richtung Produkt geht und nicht grade 4Kern-Rechenpower nötig ist. Mit "embedded" kann man sich so manche Datentransfer/ Latenzprobleme sparen. Vielleicht tut's dann auch ein 0815 ARM, die Frage stellt sich dann letztlich nach den Interfaces, bzw. woher deine Korrekturdaten kommen. Wenns irgendwie in Richtung Kamera-Interface (Parallel-Datenstrom) geht, kann ich die Blackfin-Lösung empfehlen. Grüsse, - Strubi
Schau mal hier: http://beagleboard.org/beagleboard-xm Du bekommst hier einen Cortex A8-Prozessor für Netzwerk und IO und einen C64xx DSP für Audio-Realtime-Algorithmen. Das dür4fte fürs erste reichen. fchk
Frank K. schrieb: > Schau mal hier: > http://beagleboard.org/beagleboard-xm > > Du bekommst hier einen Cortex A8-Prozessor für Netzwerk und IO und einen > C64xx DSP für Audio-Realtime-Algorithmen. Das dür4fte fürs erste > reichen. > > fchk Das sieht auf den ersten Blick erst mal gut aus. Entwicklungstools Umgebung Debugger Echtzeit Debugger C-Compiler - sind die dabei oder muss man da stückeln und suchen?
Für den Linux-ARM sind es die üblichen Tools, für den DSP gibts das CCS von TI. Keine Ahnung, ob es als CD dabei ist, aber bei TI gibts das. Als JTAG Debugger brauchst Du einen XDS100v2 oder v3; der kann sowohl den ARM als auch den DSP debuggen und ist das Dongle für die kostenlose CCS-Lizenz. fchk
Frank K. schrieb: > Für den Linux-ARM sind es die üblichen Tools, für den DSP gibts das CCS > von TI. Keine Ahnung, ob es als CD dabei ist, aber bei TI gibts das. Als > JTAG Debugger brauchst Du einen XDS100v2 oder v3; der kann sowohl den > ARM als auch den DSP debuggen und ist das Dongle für die kostenlose > CCS-Lizenz. > > fchk Code Composer Studio etc kenne ich, klar.....die üblichen tools... für Linux ARM kenne ich nicht? Was brauche ich da? Basteln oder wie bei TI reinstecken, läuft?
Michael K. schrieb: > Frank K. schrieb: >> Für den Linux-ARM sind es die üblichen Tools, für den DSP gibts das CCS >> von TI. Keine Ahnung, ob es als CD dabei ist, aber bei TI gibts das. Als >> JTAG Debugger brauchst Du einen XDS100v2 oder v3; der kann sowohl den >> ARM als auch den DSP debuggen und ist das Dongle für die kostenlose >> CCS-Lizenz. >> >> fchk > > Code Composer Studio etc kenne ich, klar.....die üblichen tools... für > Linux ARM kenne ich nicht? > > Was brauche ich da? > Basteln oder wie bei TI reinstecken, läuft? Basteln. Linux halt. gcc, kernel, kernel headers,... Wie bei einem PC Linux auch, aber für ARM. Sollte TI eigentlich auch alles da haben. Der CCS kann zwar ARM, aber den Linux-Kernel nicht compilieren, der ist für die Verwendung mit dem gcc entwickelt worden und benutzt spezifische gcc-Erweiterungen. fchk
Hi, mit dem Beagleboard xM habe ich nicht sonderlich gute Erfahrungen gemacht, insbesondere mit dem USB und Netzwerk habe ich aus welchen Gründen auch immer keine gute Latenz hinbekommen. bei USB isochron gingen dauernd Pakete verloren, sobald ein bisschen Last im System aufkam. Kernel-Debugging funktionierte damals nicht mit dem JTAG, überhaupt, das Zusammenspiel zwischen CPU und DSP liess sich unter Linux nicht vernünftig debuggen. kann sich natürlich inzwischen geändert haben, ist etwa 3 Jahre her. Das Beagle ist sonst ok, wenn man keine eigene HW entwickeln muss. Oder man nur mit dem Beaglebone seine Hardware ansteuert. Ansonsten hat man schon mal viel `Spass´, wenn man die Chips von TI in kleinen Stückzahlen haben will...
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.