Hallo Forum, ich möchte möglichst schnell Daten von einem DSP (TMS320) in einen STM32F4 übertragen. SPI ist dabei so eine Sache, es verlangsamt den DSP leider etwas. Daher würde ich nun gerne die Daten die der DSP sowieso in einem externen SRAM abspeichert direkt von dort auslesen. Um nun den DSP möglichst nicht zu behinderen, habe ich an Dual-Port-Ram gedacht. Wäre das die sinnvollste Lösung oder gäbe es hier noch mehr? Ein weiterer Ansatz wäre 2 SRAM vorzusehen und wenn der eine voll ist, schriebt der DSP in den anderen und gibt dem STM32 bescheid, dass dieser den 1 SRAM auslesen kann. Dabei müsste man eventuell alle Leitungen durch z.B. einen IC oder MOSFETS auftrennen damit sich diese nicht gegenseitig stören. Blöd ist halt das diese Lösung zusätzlichen Aufwand beim Layouten macht. Lässt sich so Dual-Port-RAM einfach an den XINTF des DSP anbinden?
Ich habe mal irgendwo gelesen, dass es kaum noch DPR gibt, weil inzwischen FPGAs billiger sind und auch oft genug BLOCK RAM haben. Vorteil: Du kannst die Ansteuerung (seriell/parrallel, Bitweite usw.) selbst bestimmen.
:
Bearbeitet durch User
Die effizienteste Lösung wäre die Verwendung eines TI OMAP Bausteins, der gleich einen ARM9 und einen c6xx enthält. Beispiel OMAP L138 Der ist für solche Architekturen gemacht worden. fchk
Naja nen OMAP wäre wohl Overkill.
Allerdings geht es eh nicht.
Fest ist der DSP ("Historisch bedingt").
Nen FPGA oder CPLD wäre schon möglich aber bringt nochmal gehörigen
Aufwand.
Dual Port Ram gibts schon noch, sind nur nicht ganz so günstig..
Aber Vorteil wäre halt komplett getrennt nutzbar und es müsste keine
großen Verrenkungen gemacht werden.
>ich möchte möglichst schnell Daten
"Möglichst schnell" ist Blödsinn.
Wie schnell ist "schnell genug"?
Tja,da kann ich nichts zu sagen. Möglichst nach oben offen, falls mal in Zukunft ein schnellerer DSP benutzt wird. Momentan werden die Daten per SPI auf ne SD-Karte geschrieben. Es soll mindestens genauso schnell, besser schneller gehen.
Das SPI läuft glaub auf 10MHz. Der STM32 kann ja bis 48MHz. Da würds schon gehen, nett bei Dual Port RAM wäre halt das man hier unabhängiger ist. Falls mal ein anderer DSP kommt der kein SPI hat oder so. Bzw. man muss halt nicht alle Daten über SPI schicken sondern nur kurze Impulse lies mal schnell den RAM und weiter gehts...
>Achja der SPI läuft nicht auf Full Speed.
Wie dann? Was ist "Full Speed"?
SPI1 bei STM32F4 soll 37,5Mbits/sec bringen...
Und was soll der STM mit den Daten machen?
Der muss sie ja auch verarbeiten können...
SDIO sollte 48MHz x 8 Transferrate bringen.
>nett bei Dual Port RAM wäre halt das man hier unabhängiger ist. Das halte ich für einen Aberglauben. Viel zu kompliziert... >Falls mal ein anderer DSP kommt der kein SPI hat oder so. Dann sieht die Welt sowieso wider ganz anders aus.
Der STM32 muss nichts weiter amchen als die Daten über verschiedene Denkbare Kommunikationsmodule weiterzuleiten. Da geht wahrscheinlich auch was kleineres, aber bei den Preisen heutzutage nehm ich einfach was dickes... Pic32MZ oder STm32F4 oder LPC4370. Und wenn es ganz dicke kommt nen BBB wobei die PRU mit Assembler bissel blöd sind..
Es geht darum den DSP möglichst wenig zu stören. Daher halt Dual-Port-Ram. Der DSp bekommt bis auf eine kurze Nachricht an den STM32 ja nichts mit.
>Es geht darum den DSP möglichst wenig zu stören.
Und der hat keinen DMA intus?
Doch zum McBSP gibts DMA was man wiederum als SPI benutzen kann. Ob das gemacht wird weiß ich nicht. Noch wird ja auch das langsame SPI genutzt. Der STM32 muss so halt immer auf Empfang sein wenn die Daten kommen... Die Daten werden ja vom DSP sowieso in den SRAM geschrieben. Daher hätte ich halt jetzt da angesetzt mit nem Dual-Port-Ram.
Frage schrieb: > Doch zum McBSP gibts DMA was man wiederum als SPI benutzen kann. DAM ist eigentlich Ideal und Daten ohne die CPU zu belasten aus dem µC zu schaufeln. > Der STM32 muss so halt immer auf Empfang sein wenn die Daten kommen... Interrupts??
Um wieviel Daten geht es denn überhaupt? Könnte auch nen FIFO gehen? Wieviel Latenz ist erlaubt? > Noch wird ja auch das langsame SPI genutzt. Was heißt "Noch"? Wenn DualPort für SPI, dann brauchst du ja noch zusätzliche Logik. Da wär dann nen kleines FPGA mit wenigen Pins und nen bischen Dualport RAM schon optimal.
Dual Port für SPI?? Ne anstatt SPI will ich die Daten direkt über ein Dual-Port-Ram auslesen. Die Daten werden bisher in ein SRAM geschriebne was ich dann gegen ein Dual-Port austauschen würde. Noch heißt noch... irgendwann ändert es sich vielleicht mal. Da das ganze möglichst offen gehalten werden soll bei "Wie viel Daten?" usw. versuche ich ja gerade herauszufinden wie man sich nichts verbaut.
>Es geht darum den DSP möglichst wenig zu stören. Daher halt >Dual-Port-Ram. Nimm PLD/FPGA und fertig.
Frage schrieb: > Doch zum McBSP gibts DMA was man wiederum als SPI benutzen kann. Was spricht dagegen es auch zu verwenden?
Frage schrieb: > Naja nen OMAP wäre wohl Overkill. Ein OMAP L132 mit 200MHz ARM9/200MHZ C6748 kostet 16 Euro. DPRAM-Bausteine kosten oft mehr. Und wenn der nicht reicht, gibts den L138, der den doppelten Takt hat. > Allerdings geht es eh nicht. > Fest ist der DSP ("Historisch bedingt"). Welcher DSP ist es denn genau? Wie gesagt: Du solltest diesen Weg nicht leichtfertig verwerfen. fchk
Das DPRAM allein ist ja noch nicht alles, schreiben und lesen muss noch synchronisiert werden dass es nicht auseinanderdriftet.
>ich möchte möglichst schnell Daten Jaja, schon viel geschrieben wurde hier. Aber die Kernfragen sind immer noch offen: = spezizifiziere "schnell" : "möglichst" ist keine Zahl = spezifiziere "Daten" : Datenbreite, -Durchsatz, -Blockgröße etc. > Frank K. (fchk) schrieb > DPRAM-Bausteine kosten oft mehr. Ja, z.B. der SN74V293-6PZA von Texas Instruments bei Mouser auch als 100er Preis noch über 20 Euronen. Ist aber netter Baustein und ziemlich möglichst. Gruss
Frage schrieb: > nett bei Dual Port > RAM wäre halt das man hier unabhängiger ist. Falls mal ein anderer DSP > kommt der kein SPI hat oder so. Gibt es solche DSPs? Max H. schrieb: > Frage schrieb: >> Doch zum McBSP gibts DMA was man wiederum als SPI benutzen kann. > Was spricht dagegen es auch zu verwenden? Das würde mich auch interessieren. Zumal es sicher viele DSPs gibt, die gar nicht genug Pins frei haben, um ein DPR anzusprechen. Mehr als DSPs ohne SPI, vermute ich. Erich schrieb: > Ist aber netter Baustein und ziemlich möglichst. Spezifiziere "ziemlich möglichst". ;-)
Man kann den DSP selber als Dual-Port-RAM benutzen und auf den internen RAM des DSP extern zugreifen. Wenn das "nett" gemacht wird, stoert es den DSP auch nicht. Stichwort: DARAM
Das kannte ich noch nicht: > Dual access RAM can be accessed twice per machine cycle, hence, CPU > and peripherals can perform read and write operation in a single clock > cycle http://books.google.de/books?id=03KFC6UYhR8C Kapitel 17.5.2 Ist das eine Besonderheit des TMS320C54x? Oder ist das mehr oder weniger üblich bei DSPs?
:
Bearbeitet durch User
Also der STM32 muss nur den SRAM des DSP auslesen. Normalerweise niemals schreiben. Das System mit dem DSP ist ein älteres geschlossenes System .Damit die Software nicht großartig geändert werden muss, soll der STM dazu gebastelt werden. Somit ist der DSP halt fest und der SRAM ist auch schon dran. Daher wäre halt meine überlegung Dual-Port-Ram (solange Geld 2.rangig ist...) Wenn Dual-Port-Ram doch zu teuer ist wird halt ein CPLD und SRAM benutzt und der CPLD wird für die Umschaltung genutzt. Dieter meinte etwas von Lese/Schreib Zugriff synchronisieren: Das würde ich halt lösen über eine kurze Nachricht an den STM vom DSP welche Adressen er jetzt auslesen soll. Es gibt ja noch Synchronen und Asynchronen Dual-Port-Ram. Verstehe ich das richtig, dass jeweils ein CLK vom STM und vom DSP ankommt am RAM und ich kann jeweils mit dem maximalen Takt auf der jeweiligen Seite auslesen? Wäre klasse, denn der STM ist glaub mit seinem Externen Memory Controller auf 90MHz bei den STM437 schneller als der DSP.
Du hast uns immer noch nicht gesagt, was für einen DSP Du GENAU verwendest? Ist das so schwierig? Oder sollen wir Dir nicht helfen? fchk
Oh, sorry TM320F28335 ist es. Aber welcher DSP es ist betrifft mich nicht. Mit dem DSP habe ich nichts zu tun. Auch das Programm werde ich wohl nicht anpassen. Ich muss nur den Kram außenrum bauen.
Frage schrieb: > Oh, > sorry TM320F28335 ist es. Ah! C28 mit FPU. Sag das doch gleich. Kennst Du schon den hier? http://www.ti.com/product/f28m36p63c2 Identischer DSP-Kern, identische DSP-Geschwindigkeit, FPU mit drin, die Peripherie des F28335 ist so wie ich das gesehen habe auch mit dabei. Aber als Bonus ist auch noch ein Cortex M3 an Bord, der zB den integrierten Ethernet-Controller bedienen kann. Plus noch ein paar Boni wie: - Up to 64KB of Shared RAM - 2KB of IPC Message RAM Und preislich ist der auch gar nicht so viel teurer als das der jetzt verwendete. Auf jeden Fall deutlich billiger als die bisherige Lösung plus STM32F4 plus DPRAM/FIFO/wasweißich. Und kleiner und effizienter obendrein. fchk
:
Bearbeitet durch User
Frank K. schrieb: > Kennst Du schon den hier? Interessant für Mitleser, aber ansonsten "Perlen vor die Säue", denn: Frage schrieb: > welcher DSP es ist betrifft mich nicht. > Mit dem DSP habe ich nichts zu tun.
Das stimmt schon alles Frank. Es gäbe da sicherlich andere bessere Lösungen aber Vorgabe ist jedoch: Der DSP bleibt. Es ist eine Abschlussarbeit daher möchte ich eigentlich keine fertigen Lösungen denn ich muss ja auch was selber leisten (gut ist mal noch nur einlesen und Ideen entwickeln, Umsetzung ist ja immer noch alles meine Arbeit..). Meine Ideen waren halt Dual-Port-Ram oder 1 oder 2 SRAM mit einer Art Umschalter. Ich hätte gerne ein paar Denkanstöße was noch gehen könnte, damit ich nicht völligen Mist bei der Arbeit verzapfe... Aber hier im Forum is es ja manchmal/oft so, sobald man sagt es ist ne Abschlussarbeit wird man niedergemacht warum man nicht selber denkt usw. daher hab ich es bisher nicht gesagt.. Stell dir ein altes Messsystem vor. Davon gibts verschiedene Arten. Eins misst Luftdruck, eins Wassertemperatur usw.. Die Ergebnisse werden jeweils im SRAM des DSP gespeichert. Jedes Messsystem hat einen eigenen DSP und SRAM. Um das alte System soll was außenrum gebaut werden, was die alten Messsysteme ohne großartige Eingriffe ausließt und die Daten an neue Maschinen weitergibt. So in der Art mit noch ein wenig mehr außenrum. Ich bau das Zwischending und suche eine Art die Daten aus dem SRAM zu lesen.
Mit Deinem letzten Posting hast Du mir wichtige Informationen gegeben. Es ist für die Helfenden wichtig, ob es eine Bastelei ist, ein Prototyp oder eine Einzelanfertigung, oder ob das Ergebnis in Serie gehen soll. Wenn es in Serie gehen soll (und danach sah es für mich bislang aus), geht es vor allem um Kosten: Bauteile, Bestückung, Programmierung von PLDs/FPGAs/externen Flashes (vor oder nach dem Bestücken, das ist ein Produktionsschritt, der manuellen Aufwand bedeutet und nicht zu knapp Kosten verursacht), Leiterplatte,... Alles andere als die voll integrierte Single-Chip-Lösung ist in diesem Fall völliger Unsinn. Eine Abschlussarbeit wird nie 1:1 in Serie gehen. Da musst Du sehen, dass Du in der vorgesehenen Zeit fertig wirst und Dir möglichst wenige Stolperfallen einbaust. Wenn das Ergebnis ein wenig mehr kostet - egal, Deine Zeit ist begrenzt, und die Ausarbeitung musst Du ja auch noch schreiben - vergiss das nicht. Du sagst, dass der Datenfluss immer vom C28 zum STM geht. Dann wäre ein FIFO eine gute Lösung. Beispiel: http://www.ti.com/lit/ds/symlink/sn74v3670.pdf Du schreibst Datenblöcke hinein, und sobald das FIFO mehr als halb voll ist (HF-Pin) liest der STM auf der anderen Seite solange Blöcke, bis das FIFO nicht mehr halb voll ist. Oder Du arbeitest mit Almost Full/Almost Empty, je nachdem, was einfacher ist. Andere Möglichkeit: DPRAM. Ich würde zusehen, dass ich zumindest für den Prototyp ein fertiges DPRAM verwenden kann, einfach um die Stolperfalle einer eigenen Implementation per FPGA oder PLD+SRAM zu umgehen. Die integrierten DPRAMs erlauben nämlich oft gleichzeitige Zugriffe von beiden Ports, auch auf die gleiche Adresse (Rd+Rd und Rd+Wr, natürlich nicht Wr+Wr)! Deine nachgebastelte Lösung mit einem externen Standard-SRAM wird das nicht können. Allein das kann Dir sehr viele schlaflose Nächte bereiten und Deine Arbeit gefährden. In Deiner Ausarbeitung kannst Du das ja als möglichen weiteren Schritt erwähnen, genau wie die TI M3+C28 Kombi-DSPs, die die erste Wahl für ein Seriengerät wären und entsprechende Schaltungsteile bereits eingebaut haben. Integrierte DPRAMs gibts von IDT und Cypress. Viele von denen haben noch einen extra Chip-Select für eine Semaphore. Wenn Du da von der einen Seite einen Wert hineinschreibst, wird auf der anderen Seite ein Interrupt ausgelöst, so dass der Prozessor dort die Semaphore lesen kann. Für jede Richtung gibts eine eigene Semaphore. Das ist für die Prozessorkommunikation extrem nützlich. So etwas in der Art ist auch in den M3+C28 Prozessoren eingebaut. FIFOs und DPRAM sind nicht billig, aber für einen Prototypen sollte das wohl egal sein. Wenn die es nachher billig wollen, sollen sie gefälligst einen der M3+C28 Prozessoren verwenden - da ist das alles drin. fchk
Vielen Dank Frank für die Einschätzung. Dann lag ich ja mit der ersten Idee nicht wirklich Falsch. Auch vielen Dank das du nicht angefangen hast rumzunölen wie manche hier bei Abschlussarbeiten. Es wird kein Serienprodukt. Nur zur internen Verwendung mit nur ein paar Stück. Daher ist der Preis eher egal. Ich könnte anstatt dem STM32 auch ein BeagleBone verwenden damit ich noch mehr Leistung habe aber da ist ja ein SRAM auslesen schon wieder schwieriger wenn es schnell gehen soll. Muss man ja die PRU verwenden oder eigene Kernel Treiber schreiben (zumindest nach allem was ich so gelesen habe). Daher nehm ich halt nen möglichst großen Mikrocontroller. Ich denke es wird dann das Dual-Port-Ram, geht wohl am besten. Kannst du zufällig noch was zu Asynchron und Synchron Dual-Port-Ram sagen? Hab zwar ein wenig gelesen aber so richtig klar ist es mir noch nicht geworden. So wie ich es verstanden habe muss beim Synchronen der Takt zwischen den beiden Prozessoren der an den Chip geht synchronisiert sein und gleich hoch. Bei Asynchronen ist es egal. Hier können beide Seiten mit jeweils der schnellsten Taktrate zugreifen. Der TMS und der STM können jeweils max 90MHz. Somit wärs zuerst mal egal. Der TMS hat jedoch asynchrone Anbindung also ist es sinnvoller Asynchronen Dual-Port-Ram zu verwenden. Sehe ich das richtig?
Achso das mit dem Fifo. Der STM bezieht jeweils nur Daten aus dem SRAM. Jedoch der DSP schreibt und liest aus dem SRAM. Somit fällt ein Fifo weg.
So, und hier noch eine sehr trickreiche, aber eigentlich geniale Schaltungsidee: Du kennst den 23K256? Das ist ein serielles SRAM von Microchip mit SPI-Interface und 256kbit Kapazität. Kostet vielleicht einen Euro das Stück, in Stangen deutlich weniger. Du nimmst 8 Stück davon, für jedes Bit einen. DI und DO kannst Du miteinander verbinden und an je ein Datenbit anklemmen. Den SPI CLK erzeugst Du aus dem !WR- oder E-Signal des DSP-Businterfaces. Wenn Du jetzt in das RAM etwas hineinschreiben willst, musst Du zuerst den Sequential Write Befehl an alle 8 Bausteine schicken. Die Bytefolge für einen Baustein ist 2,0,0 (Beginn an Adresse 0), also binär 00000010 00000000 00000000. Da die Bausteine alle parallel geschaltet sind, setzt Du !CS auf Low und schreibst 0,0,0,0,0,0,255,0, (das war jetzt der Schreibbefehl) 0,0,0,0,0,0,0,0, (das war jetzt das Hi-Byte) 0,0,0,0,0,0,0,0, (das war jetzt das Lo-Byte). Anschießend kommen die Datenbytes die Du schreiben willst. Die Bausteine haben interne Adresszähler, die automatisch bei jedem Schreibvorgang inkrementiert werden. Du musst nur darauf achten, immer vielfache von 8 zu schreiben. Wenn Du fertig bist, setzt Du !CS wieder auf High, und löst beim ARM irgendwie einen Interrupt aus. Der ARM macht das gleiche, muss aber jetzt ein Sequential Read senden (3,0,0), d.h. die Bytefolge 0,0,0,0,0,0,255,255, (das war jetzt der Lesebefehl) 0,0,0,0,0,0,0,0, (das war jetzt das Hi-Byte) 0,0,0,0,0,0,0,0, (das war jetzt das Lo-Byte) an die RAM-Bank senden, und mit jedem weiteren Takt purzelt ab jetzt ein neues Byte aus den RAMs. Mit zwei dieser RAM-Bänke kannst Du im Wechsel arbeiten, so wie Du es Dir auch schon in der Anfangsmail gedacht hast. Vorteil bei dieser Lösung: (a) nur billige Standardbausteine, leicht zu beschaffen (b) Du musst weniger Leitungen umschalten, da Du keine Adressleitungen hast, sondern nur 8*DI/DO, 1*SCK und 1*!CS (c) hohe RAM-Kapazität, die meisten DPRAMs und FIFOs sind viel kleiner als die 256KByte, die Du so pro Bank bekommst. fchk
:
Bearbeitet durch User
Frage schrieb: > Achso das mit dem Fifo. Der STM bezieht jeweils nur Daten aus dem SRAM. > Jedoch der DSP schreibt und liest aus dem SRAM. Somit fällt ein Fifo > weg. ok, dann nimm ein fertiges DPRAM, und gut ists. Such Dir hier was passendes aus: http://www.idt.com/products/memory-logic/multi-port-memories/asynchronous-dual-port-rams#!/?sm_cck_field__io_type=3.3%20V%20LVTTL&tfm_cck_field__access_time_ns=[8%20TO%20100]&sm_cck_field__function=Semaphore http://www.cypress.com/?id=82&addcols=¶metric=html&filter_190=N%2FA&filter_1=TQFP&filter_187=3.00#parametric (bei Frequency N/A auswählen, dann bekommst Du die asynchronen Bausteine) fchk PS: Der vorherige Beitrag entfällt dann.
:
Bearbeitet durch User
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.