Hallo an alle Wie kann ich am besten folgendes Szenario lösen: Am Mikrocontroller hängt eine Speicherkarte, welche über SPI kommuniziert. Zudem hängt am uC auch ein RAM Baustein, ebenfalls über SPI. Ich möchte jetzt Daten von der Speicherkarte auf den RAM übertragen. Szenario 1) : Beide Bausteine hängen am gleichen SPI Bus. Daten von SD auf Mikrocontroller zwischenspeichern, und von da aus auf den RAM. Problem: Die zu übertragenden Daten sprengen den verfügbaren Zwischenspeicher vom Controller, also müssten die Daten aufgeteilt werden. Szenario 2): Beide Bausteine hängen an zwei verschiedenen SPI Busse. Somit könnte ich quasi eine "direkte" Übertragung zwischen SD und RAM veranlassen, indem der Kontroller immer nur ein Byte aus dem Puffer vom SPI Bus der SD Karte, sofort in den Puffer des SPI Bus des Rams hineinlegt. Für mich sieht Szenario 2 nach einer Schnelleren Übertragung aus. (Klar müssen beide Busse mit der gleichen Taktfrequenz laufen..) Verwendet wird ein dsPIC33. Gibt es sonst noch Möglichkeiten um sowas elegant zu lösen? Freue mich auf Input. lG
Ich kenne den Controller jetzt nicht aber prinzipiell lässt sich sowas recht performant über DMA mit double Buffer lösen da du während des Schreibens in den RAM schon von der SD-Karte lesen kannst. Zwischenspeichern im µC wirst du immer müssen. Je mehr RAM du im µC zur Verfügung hast desto schneller geht das natürlich.
Jempes schrieb: > Die zu übertragenden Daten sprengen den verfügbaren > Zwischenspeicher vom Controller, also müssten die Daten aufgeteilt > werden. Wenn die Datenblöcke nicht allzu klein sind, z.B. 32 Byte, ist der Geschwindigkeitsunterschied unbedeutend. Georg
Guest schrieb: > Ich kenne den Controller jetzt nicht aber prinzipiell lässt sich > sowas > recht performant über DMA mit double Buffer lösen da du während des > Schreibens in den RAM schon von der SD-Karte lesen kannst. > Zwischenspeichern im µC wirst du immer müssen. > > Je mehr RAM du im µC zur Verfügung hast desto schneller geht das > natürlich. Aber DMA gilt doch nur für die Kontroller internen BUSSE?! Hier gehts ja drum von der SD Karte auf ein Externes RAM Modul Daten zu übertragen. Und wenn beide Module am gleichen SPI Bus hängen dann ginge das ja eh nicht über DMA..? Georg schrieb: > Wenn die Datenblöcke nicht allzu klein sind, z.B. 32 Byte, ist der > Geschwindigkeitsunterschied unbedeutend. > > Georg Ja das stimmt schon, wollte aber diese Aufteilung gerne vermeiden
Jempes schrieb: > Aber DMA gilt doch nur für die Kontroller internen BUSSE?! Hier gehts ja > drum von der SD Karte auf ein Externes RAM Modul Daten zu übertragen. > Und wenn beide Module am gleichen SPI Bus hängen dann ginge das ja eh > nicht über DMA..? Der DMA kann ja die daten des SPI Moduls in den Speicher schreiben und der 2.DMA diese an das andere SPI Modul Weitergeben. Das setzt natürlich voraus das man 2 unterschiedliche SPI Module verwendet. Der Sinn darin liegt eben Gleichzeitig daten Lesen und schreiben zu können. Ich weiß ja nicht wie schnell diese Übertragung sein soll / muss.
Jempes schrieb: > Szenario 1) : Beide Bausteine hängen am gleichen SPI Bus. Daten von SD > auf Mikrocontroller zwischenspeichern, und von da aus auf den RAM. > Problem: Genau. > Die zu übertragenden Daten sprengen den verfügbaren > Zwischenspeicher vom Controller, also müssten die Daten aufgeteilt > werden. Ja und? Wo liegt das Problem? > Szenario 2): Beide Bausteine hängen an zwei verschiedenen SPI Busse. > Somit könnte ich quasi eine "direkte" Übertragung zwischen SD und RAM > veranlassen, indem der Kontroller immer nur ein Byte aus dem Puffer vom > SPI Bus der SD Karte, sofort in den Puffer des SPI Bus des Rams > hineinlegt. Machbar, aber eher nutzlos. > Für mich sieht Szenario 2 nach einer Schnelleren Übertragung aus. Nicht wirklich, bestenfalls wenn man es handoptimiert in Assembler macht. In der Praxis willst du nicht byteweise von SD-karte lesen, denn dann braucht jeder Lesezugriff einen neuen Funktionsaufruf der SD-Lib. DAS wird dann erst recht langsam! > Gibt es sonst noch Möglichkeiten um sowas elegant zu lösen? So wie es jeder machen würde. Einen möglichst großen Puffer reservieren, idealerweise N*512 Byte (1 Sektor = 512 Bytes), den von SD-Karte füllen und in den RAM schreiben. Das geht alles problemlos mit einem SPI-Bus.
Falk B. schrieb: > So wie es jeder machen würde. Einen möglichst großen Puffer reservieren So hat man das früher mal gemacht. Heute ist es üblich eine GByte-grosse Datei erst mal komplett in den Speicher zu laden und dann wegzuschreiben. Blockweises Kopieren ist nur was für alte Opas. Georg
Georg schrieb: > Heute ist es üblich eine GByte-grosse > Datei erst mal komplett in den Speicher zu laden und dann > wegzuschreiben. Wer so programmiert macht sich aber Feinde, wenn das Kopieren einer großen Datei wegen zu wenig Arbeitsspeicher fehlschlägt. Wie willst einem Anwender ernsthaft erklären, dass er Videos nur abspielen aber nicht kopieren kann?
Stefanus F. schrieb: > Wie willst einem Anwender ernsthaft erklären Will ich garnicht. Ich stelle nur fest was für heutige Programmierer Mainstream ist. Georg
Georg schrieb: > Will ich garnicht. Ich stelle nur fest was für heutige Programmierer > Mainstream ist. Da habe ich das andere Extrem aber (leider) schon häufiger gesehen: GB große Dateien Byteweise kopieren. Kommt auf PC und Unix Servern richtig gut. Manche Entwickler schaffen es nicht einmal, ein Beispiel von Stackoverflow auszuwählen. Sie picken sich das augenscheinlich primitivste Beispiel heraus, ohne den Text und die Bewertungen zu beachten.
Kleine OT Zwischenfrage aus Interesse: Ich lese hier das erste mal von RAM mit SPI Interface. Das hielt ich zuerst für einen Scherz weil das ja nicht wirklich schnell ist. Aber es braucht eben auch nur sehr wenige IOs. Die Frage: Was sind da die üblichen Anwendungsfälle? Und wie schnell ist das dann in der Realität bei zufälligen Zugriffen?
Welchen Nutzen versprichts Du Dir von dieser Kopieraktion? Die Daten werden von einem langsamen Speicher in den nächsten langsamen Speicher verschoben. Läge das RAM im Adressbereich des µC, wäre der Vorteil klar, aber beide Speicher hängen am SPI, also was soll das? Jempes schrieb: > Die zu übertragenden Daten sprengen den verfügbaren > Zwischenspeicher vom Controller, also müssten die Daten aufgeteilt > werden. Oh, wie außergewöhnlich ... Blockweise lesen, speichern, schreiben. Wie soll das sonst gehen? 'Ich will meine 120GB HDD auf die SSD clonen, habe aber nur 8GB RAM. Was soll ich nur tun :-)))'
Michael K. schrieb: > 'Ich will meine 120GB HDD auf die SSD clonen, habe aber nur 8GB RAM. Was > soll ich nur tun :-)))' Am PC hängen SSD und HDD üblicherweise an getrennten Schnittstellen. Da kann kopiert werden ohne dass das in den RAM muss oder müsste. Wie das wirklich gemacht wird weiß ich aber nicht. Tja und dann hat RAM schon Vorteile gegenüber einer NAND SD Card. Der hält deutlich mehr Schreibzyklen aus und man will die SD Card vielleicht auch wechseln im Betrieb. Da ist es gut wenn die Daten im RAM liegen. Es gibt SPI RAM Steine mit SRAM oder FRAM. Ich habe aber keine mit QuadSPI gefunden?! Schade eigentlich weil das wäre deutlich schneller.
Gustl B. schrieb: > Am PC hängen SSD und HDD üblicherweise an getrennten Schnittstellen. Da > kann kopiert werden ohne dass das in den RAM muss oder müsste. Keine Sekunde, schon gar nicht bei realen PCs! > Wie das > wirklich gemacht wird weiß ich aber nicht. EBEN!
Georg schrieb: > So hat man das früher mal gemacht. Heute ist es üblich eine GByte-grosse > Datei erst mal komplett in den Speicher zu laden und dann > wegzuschreiben. Blockweises Kopieren ist nur was für alte Opas. Der TO hat einen µC und daran hängt ein RAM und eine SDcard. Jetzt verrate mir mal, wie er eine GByte-grosse Datei komplett in den Speicher laden soll, um sie dann in den RAM wegzuschreiben...
npn schrieb: > Jetzt verrate mir mal, wie er eine GByte-grosse Datei komplett in den > Speicher laden soll, um sie dann in den RAM wegzuschreiben... 1GB SPI-RAM? ;-)
Falk B. schrieb: > npn schrieb: >> Jetzt verrate mir mal, wie er eine GByte-grosse Datei komplett in den >> Speicher laden soll, um sie dann in den RAM wegzuschreiben... > > 1GB SPI-RAM? ;-) Er liest die Daten also über SPI von der SD-Karte in den SPI-RAM, um sie danach in den anderen SPI-RAM zu schreiben? Kann man sicherlich machen... :-D
Jempes schrieb: > Szenario 1) : Beide Bausteine hängen am gleichen SPI Bus. Daten von SD > auf Mikrocontroller zwischenspeichern, und von da aus auf den RAM. > Problem: Die zu übertragenden Daten sprengen den verfügbaren > Zwischenspeicher vom Controller, also müssten die Daten aufgeteilt > werden. Mir wäre es nicht bekannt, dass du von einer SD Karte weniger wie "Page-Size" lesen könntest, in der Regel 512 Byte. (Laut "SanDisk Secure Digital Card Spec.") Somit musst du dir eh ein 512Byte Buffer anlegen. Da würde ich aber 2 Stück anlegen und wenn du in den einen liest, kannst den anderen bereits wieder versenden.
Adam P. schrieb: > Mir wäre es nicht bekannt, dass du von einer SD Karte weniger wie > "Page-Size" lesen könntest, in der Regel 512 Byte. (Laut "SanDisk Secure > Digital Card Spec.") Doch, kann man, man muss nur die Daten davor und danach wegschmeißen. So macht es vermutlich auch das Petit FS vom Meister Chan aus dem fernen Osten. http://elm-chan.org/fsw/ff/00index_p.html > Somit musst du dir eh ein 512Byte Buffer anlegen. Nein. > Da würde ich aber 2 Stück anlegen und wenn du in den einen liest, kannst > den anderen bereits wieder versenden. Nützt nix, wenn beide Speicher am gleichen SPI hängen.
Falk B. schrieb: > Doch, kann man, man muss nur die Daten davor und danach wegschmeißen. ALSO gehts es nicht, denn über den Bus musst du erstmal 512 Byte abholen. Klar kann man sagen, die ersten 100 Byte nehme ich nicht in mein Buffer auf...naja, Geschmackssache. Wobei das mit DMA (PDC) schon nicht mehr gehen würde. Die vom elm-chan nutzt doch FAT (bzw. Abspeckungen), ich rede ja von der untersten Ebene, SD-Befehl. Falk B. schrieb: > Nützt nix, wenn beide Speicher am gleichen SPI hängen. Ja, ok, da hast du recht...hatte es verdrängt ;) Mir wird der Sinn hinter dem ganzen aber nicht klar. Wozu soll ich von SD nach RAM kopieren, wenn ich es ja dann doch wieder per SPI vom RAM abholen muss - dann kann ich doch direkt die SD Karte nutzen. Anders wäre es, wenn der RAM direkt am µC angeschlossen wäre "External Bus Interface (EBI) / Static Memory Controller (SMC)".
:
Bearbeitet durch User
Adam P. schrieb: > Mir wird der Sinn hinter dem ganzen aber nicht klar. > Wozu soll ich von SD nach RAM kopieren, wenn ich es ja dann doch wieder > per SPI vom RAM abholen muss - dann kann ich doch direkt die SD Karte > nutzen. RAM kann verschleißfrei und schnellere Lese/Schreibzugriffe im Gegensatz zu SD-Karte.
Falk B. schrieb: > verschleißfrei Ja, würde das schreiben betreffen. Falk B. schrieb: > schnellere Lese/Schreibzugriffe Nicht, wenn die SPI Geschwindigkeit bei beiden Fix ist, bzw. SD Karte und RAM eh mit dem gleichen SPI Takt laufen.
:
Bearbeitet durch User
Adam P. schrieb: > bzw. SD Karte > und RAM eh mit dem gleichen SPI Takt laufen. Warum müssen die mit dem gleichen SPI Takt laufen? Man kann sehr leicht und sehr schnell Geschwindigkeit von SPI umschalten, wie auch Bitordnung und Mode. Das kostet nur ein paar CPU-Takte. SPI-SRAM kann schon mit SD-Card helfen. SPI-SRAM kann auch blockweise arbeiten, oder auch byteweise.
:
Bearbeitet durch User
Adam P. schrieb: > Falk B. schrieb: >> schnellere Lese/Schreibzugriffe > > Nicht, wenn die SPI Geschwindigkeit bei beiden Fix ist, bzw. SD Karte > und RAM eh mit dem gleichen SPI Takt laufen. Auch dann ist der RAM schneller, denn der Verwaltungsaufwand der SD-Karte ist höher. Beim Einzelzugriff auf Bytes spielt das eine Rolle, bei größeren blockzugriffen natürlich nicht mehr.
Angehängte Dateien:
-
EFM8LB1_W5500_128Byte.png
300 KB -
EFM8LB1_W5500_1024Byte.png
300 KB -
W6100-EVB_SPI_128Byte.png
310 KB -
W6100-EVB_SPI_1024Byte.png
310 KB -
W6100-EVB_BusIo_128Byte.png
310 KB -
W6100-EVB_BusIo_1024Byte.png
310 KB
Gustl B. schrieb: > Kleine OT Zwischenfrage aus Interesse: > Ich lese hier das erste mal von RAM mit SPI Interface. Das hielt ich > zuerst für einen Scherz weil das ja nicht wirklich schnell ist. Aber es > braucht eben auch nur sehr wenige IOs. Die Frage: > Was sind da die üblichen Anwendungsfälle? Und wie schnell ist das dann > in der Realität bei zufälligen Zugriffen? z.B. um Messdaten zwischen zu puffern, diese können dann z.B. über Ethernet geholt werden (ebenfalls SPI), im Fehlerfall werden teile der Messdaten in ein SPI Flash geschrieben, daneben liegen nach andere sachen im Flash. Alles über SPI.. Bei z.B. einem 2Mbit Ram: 1 CMD Byte 3 ADR Bytes 1 Data Byte Macht noch 20% vom theoretischen Limit(SPI Takt): Dazu der ganze LowLevel/Programm Overhead für die Aufrufe, kommt am ende auch stark auf die gesamt implementierung an. Bei z.B. einem Projekt und dessen implementierung wären z.B. bei einzelbyte(128 Aufrufe)statt einen aufruf für 128Byte Block wegschreiben/lesen: Datenrate auf ~5% vom theoretischen max. im Block mit einem Aufruf bei ~90% Hätte man bei jedem einzelaufruf statt Adr++ noch eine Random aufwendig bilden müssen käme das noch hinzu.. 100% Wären hier im fall 12MBit Keine Frage Controller mit EMIF und parallel Ram gemappt im möglichen Adr bereich sind schon fein. wobei es auch implementierte Interfaces gibt welche SPI devices (RAM/Flash) in die normalen Adressen Raum mappt. Bei High Speed Devices über 50Mhz kann da schon was bei rum kommen. Mal ein Beispiel das es manchmal mehr auf die umsetzung ankommt im Anhang mit ETH Loopback: 1.)W5500 <-> EFM8LB1 mit 12Mhz SPI (eigene Libs) 128Byte Buffer, Links UDP, Rechts TCP (nicht Zeitgleich) 1024Byte Buffer sonst wie oben 2.)W6100 <-> STM32?? (W6100EVB Typ nicht im Kopf, SPI 18Mhz, deren Code) 128Byte Buffer Links UDP (N.V. Buffer < MSS), Rechts TCP (nicht Zeitgleich) 1024Byte Buffer Rest wie gehabt 3.)W6100 <-> STM32?? (W6100EVB Typ nicht im Kopf, 8Bit EMIF/BUS, deren Code) 128Byte Buffer Links UDP (N.V. Buffer < MSS), Rechts TCP (nicht Zeitgleich) 1024Byte Buffer Rest wie gehabt Mit DMA geht es dann mehr vorwärts. Also hängt auch alles von der Implementierung im Detail ab zeigt aber Blöcke haben ihren vorteil.. Ist mit SPI Ram nicht ganz vergleichbar, da gibts weniger Overhead.
FloMann schrieb: > Bei z.B. einem 2Mbit Ram: > 1 CMD Byte > 3 ADR Bytes > 1 Data Byte Für einzelne Byte vielleicht nicht so effizient. Aber man kann in SPI-RAM gleich u32 oder u64 speichern: 1 CMD Byte 3 ADR Bytes 8 Data Byte Oder gar Array. 4 Bytes für CMD und ADR, weiter reine Daten.
:
Bearbeitet durch User
Zum Thema selbst, die wege sind vielfälltig, prinzipiell geht das auch über einen SPI. SD Karten die "neueren" ab V2 sowieso liefern und wollen 512Byte Blöcke musst wohl oder übel buffern. Praktisch hab ich so viel noch nicht mit SD karten umgesetzt aber für die SD Karten nutzen ich aber dann ein eigenes SPI. Hatte mit einigen Karten (sehr unterschiedlich) gelegentlich das Problem das der MISO der SD nach deselect sich zeitlich nicht so "abschalten"(hochohmig)wollte wie es gerne gehabt hätte. Das war aber Typen Spezifisch aber wie gesagt so viel hab ich damit nicht gemacht und prinzipiell gehts auch an einem SPI. Hängt halt auch vom ganzen ab, wenn ich die Schnittstellen zur verfügung habe dann kann ich sie auch nutzen. Wenn man jetzt ein striktes ich lese/Schreibe von Device A in den buffer und bediene danach dann Device B wirds aber auch nicht schneller beim Kopieren.
Adam P. schrieb: >> schnellere Lese/Schreibzugriffe > > Nicht, wenn die SPI Geschwindigkeit bei beiden Fix ist, > bzw. SD Karte und RAM eh mit dem gleichen SPI Takt laufen. Ein RAM-Baustein kann dir Zugriffszeiten garantieren, eine SD-Karte tut das nicht. Es ist relativ egal, wie schnell die Daten über den Bus reintröpfeln, wenn du vor dem ersten Byte erstmal unbestimmt lange warten musst.
Ich fasse mal zusammen: Es geht um einen extrem schnellen Kopiervorgang von SD auf RAM, wobei der Nutzen darin liegen soll, extrem viel an diesen Daten herumzuwerkeln, was die SD 'irgendwie nicht können soll' Das die Wear Leveling machen, lassen wir mal einfach unter den Tisch fallen. Der max Speed wird gleichzeitig durch SPI auf einen Bruchteil dessen kastriert was möglich wäre. Wir feilschen also über die Zugriffszeiten der SD, die zwar für Raspi und BBB keine Problem darstellen, einen dsPIC33 aber anscheinend restlos in die Knie zwingen. Die RAM Geschwindigkeit schein zwar ein riesen Thema zu sein, aber einen dsPIC33 mit fett RAM zu verwenden auf das man mit Full Speed zugreifen kann, kommt hier irgendwie nicht vor. Die Kapazität des SPI RAM wird ein Bruchteil der SD Kapazität sein, soll aber den SD Inhalt puffern, wenn man die mal tauschen will. Ahhhhh ja.... Man tauscht die SD, will aber einen klitzekleinen Teil davon im RAM behalten. Okay, verstanden. Freitagspost? Ich könnte verstehen FRAM zu verwenden um unschätzbar wichtige Daten zu puffern, bis man einen Block voll hat den man wegschreiben kann. Bei unschätzbar wichtigen Daten würde ich dann aber zusätzlich die SD redundant auslegen. Der Sinn dieser ganze Nummer erschliesst sich mir nicht und dem TO offensichtlich auch nicht.
Michael K. schrieb: > Wir feilschen also über die Zugriffszeiten der SD, die zwar > für Raspi und BBB keine Problem darstellen, einen dsPIC33 aber > anscheinend restlos in die Knie zwingen. Ich weise mal leise auf die unterschiedlichen Schnittstellen hin. SD-Karten an SPI verhalten sich u.U. anders als SD-Karten an SDMMC.
S. R. schrieb: > SD-Karten an SPI verhalten sich u.U. anders als SD-Karten an SDMMC. Und jede SD Karte verhält sich anders. Wir hatten massige Ausfälle in der Serie mit 4GB Intenso Karten, die wir Wochenlang gesucht haben. Anscheinend kan die LIB nicht damit zurech das die Karten nach unbestimmter zeit Bedenkpausen eingelegt hat oder sonst etwas das nicht rauszufinden war. Stumpf auf 32GB Sandisk Ultra gewechselt, die aus einem anderen Projekt über waren und ein halbes Dutzend Fehler waren weg, die alle anders aussahen. Trotzdem macht SPI RAM doch garkeinen Sinn wenn man stat dessen dsPIC33 bekommen kann die mehr als genug RAM haben das man mit Fullspeed beackern kann.
Michael K. schrieb: > S. R. schrieb: > Trotzdem macht SPI RAM doch garkeinen Sinn wenn man stat dessen dsPIC33 > bekommen kann die mehr als genug RAM haben das man mit Fullspeed > beackern kann. Würde ich so nicht sagen, die Integration bei kleinen elektroniken kann vorteilhaft sein da weniger io nötig, was neben Routing auch die Wahl und Gehäusegröße der MCU und Speicher beeinflusst, latch für Multiplex Mode fällt ggf. weg, einfacheres pcb. Neue erweitere Funktionalität bei der nun mehr Speicher benötigt wird kann bei einem redesign eventuell vorteilhaft (schneller durch wenig Änderungen am bestehenden system) sein. Genutzt im D/QSpi Modus über auch zb. Spezielle integrierte Controller mit noch hoher Taktrate ist dann auch nochmal fixer und ganz normal im Adressen Bereich gemappt. Da gibt's je nach Anforderungen unterschiedlicher Art, sei es auch beschränkte Vorgaben bei z.b der MCU Wahl, viele für und wider... Z.b. Eine schnelle Google Suche nach dspic33 brachte mir dies https://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8183 52kbyte max. Kann muss aber nicht reichen... Aber gut die Auswahl an Controller ist prinzipiell fast schier unendlich gibt ja noch genug andere...
Also das 7328te ganz tolle MCU Board, das ohne klare Anforderungen designt wird um 'alles' damit zu erschlagen. Wie spannend. Entweder gibt es einen ganz klaren Grund, das ein rangefriggelter arschlangsam RAM notwendig ist, weil 50KB internes RAM nicht reichen und auch wirklich immer alles komplett im Speicher gehalten werden muss, oder das ist wieder eine dieser Kopfgeburten die dann nur Platz wegnehmen, die BOM Kosten treiben und nie benutzt werden, weil das Handling einfach viel komplizierte ist als einfach den nächst größeren Controller aus der gleichen Familie zu nehmen. Warum dann nicht gleich einen PIC32 mit 200Mhz, 2MB Flash und 640KB RAM? Wenn das immer noch zuwenig RAM ist, der kann 32MB DDR2 RAM ansprechen. Reicht das dann, oder ist das immer noch nicht genug für 'alles mögliche'?
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.