Forum: Mikrocontroller und Digitale Elektronik Dual-Port-Ram oder andere Lösung?


von Frage (Gast)


Lesenswert?

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?

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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
von Frank K. (fchk)


Lesenswert?

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

von Frage (Gast)


Lesenswert?

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.

von Sprachen, ASCII (Gast)


Lesenswert?

>ich möchte möglichst schnell Daten

"Möglichst schnell" ist Blödsinn.

Wie schnell ist "schnell genug"?

von Frage (Gast)


Lesenswert?

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.

von Frage (Gast)


Lesenswert?

Achja der SPI läuft nicht auf Full Speed.

von Frage (Gast)


Lesenswert?

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...

von Sprachen, ASCII (Gast)


Lesenswert?

>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.

von Sprachen, ASCII (Gast)


Lesenswert?

>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.

von Frage (Gast)


Lesenswert?

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..

von Frage (Gast)


Lesenswert?

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.

von Sprachen, ASCII (Gast)


Lesenswert?

>Es geht darum den DSP möglichst wenig zu stören.

Und der hat keinen DMA intus?

von Frage (Gast)


Lesenswert?

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.

von Erwin (Gast)


Lesenswert?

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??

von Uwe (Gast)


Lesenswert?

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.

von Frage (Gast)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

>Es geht darum den DSP möglichst wenig zu stören. Daher halt
>Dual-Port-Ram.
Nimm PLD/FPGA und fertig.

von Max H. (hartl192)


Lesenswert?

Frage schrieb:
> Doch zum McBSP gibts DMA was man wiederum als SPI benutzen kann.
Was spricht dagegen es auch zu verwenden?

von Frank K. (fchk)


Lesenswert?

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

von Dieter W. (dds5)


Lesenswert?

Das DPRAM allein ist ja noch nicht alles, schreiben und lesen muss noch 
synchronisiert werden dass es nicht auseinanderdriftet.

von Erich (Gast)


Lesenswert?

>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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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". ;-)

von ... (Gast)


Lesenswert?

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

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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
von Frage (Gast)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von Frage (Gast)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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
von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Frage (Gast)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von Frage (Gast)


Lesenswert?

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?

von Frage (Gast)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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
von Frank K. (fchk)


Lesenswert?

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=&parametric=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
von Frage (Gast)


Lesenswert?

Vielen Dank für die Unterstützung.

Bitte 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
Noch kein Account? Hier anmelden.