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.
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.
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..
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.
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
>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> cyclehttp://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?
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.
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
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?
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
