Hallo zusammen, ich versuche mich grade an meinem ersten komplexeren Microcontrollerprojekt und zwar soll es etwa mit Audoaufnahme und Wiedergabe sein. Ich benutze den dsPIC33FJ128GP804, der hat 16kB RAM, diverse ADC und DAC, die für Audio gut geeignet sind. Passt und funktioniert soweit alles. Da ich längere Aufnahmen im Minutenbereich bei 44,1kHz Abtastrate machen will, benutze ich als Audiospeicher eine SD-Karte, die über den SPI-Bus betrieben wird. Funktioniert soweit prinzipiell auch ganz gut. Aber (was ich fast schon befürchtet habe): Die SD-Karte ist beim Schreiben der nötigen Datenrate (88KB/sec.) nicht wirklich gewachsen. Es geht eine Weile gut, aber irgendwann dauert das Schreiben eines Sektors so lange, dass die Aufnahme ins Stocken kommt. Wann genau das passiert, ist sehr sporadisch. Ich benutze zum (Multiblock)-Schreiben bereits 2kB RAM als Puffer, das sind 4 Sektoren a 512 Bytes auf der SD-Karte. Das bringt aber nicht wirklich viel. RAM ist auf dem Controller halt sehr begrenzt. Ich habe bereits verschiedene SD-Karten probiert und das war die beste. Das Problem ist auch nicht die Datenübertragung zur Karte sondern das Warten, bis der Schreibvorgang ins Flash abgeschlossen ist. Da dauert anscheinend ab und zu ein Vielfaches der "normalen" Zeit. Wenn ich die Abtastrate auf 8kB/sec. senke, klappt das ganze. Klingt dann natürlich mies... Problem ist nun, ausser einer SD-Karte fällt mir als Massenspeicher nichts besseres ein, was vom PIC aus nutzbar wäre. SRAM gibts in der benötigten Grösse (256-512MByte) scheinbar nicht. Evtl. könnte ich auch ein serielles RAM (z.B. http://www.conrad.de/ce/de/product/649913/SRAM-23K256-IP-PDIP-8-Microchip-Technology) als Schriebpuffer nutzen (um dann 32k-Blöcke auf die Karte zu schreben), aber das scheint mir von der Software her rel. kompliziert. Irgendwelche Ideen, was man noch machen könnte?
Du kannst SPI-NOR-Flash nutzen. Sowas hier zB sollte sehr problemlos funktionieren: http://www.spansion.com/Support/Datasheets/S25FL512S_00.pdf Sind immerhin 64MB. Bei NAND-Flash ist der Aufwand zu hoch. Das willst Du nicht. fchk
Hm, das sieht auf den ersten Blick ganz ok aus, würde mir ca. 10 min. Aufnahmedauer bringen, das würde erst mal reichen. Ich les mir das Datenblatt mal durch und schaue mal, ob man so ein Ding irgendwo problemlos bestellen kann (und was das kostet)... Danke auf jeden Fall erst mal!
Ich hab mir jetzt das Datenblatt von dem S25FL512S mal angesehen und leider dauert das Löschen eines Sektors, das ich ja vor dem Wiederbeschreiben machen muss, sehr lange. Er löscht mit 0,5MB/sec. und der kleinste zu löschende Block ist 256kB gross. D.h. um den zu löschen braucht er eine halbe Sekunde. Das ist ja eine halbe Ewigkeit... Das Blöde ist, ich bräuchte die wichtigste Eigenschaft des Flash-Speichers, die Nichtflüchtigkeit, gar nicht und handle mir die Nachteile trotzdem ein. Aber SRAM mit einer Grösse von ca. 64MB+ gibts anscheinend nicht.... Ich will halt eigentlich ständig lesen und schreiben vom Speicher, deswegen ist das schnelle Schreiben (inkl. vorherigem Löschen) sehr wichtig. Was ich bauen will, ist so ein Audio-Looper, ich frag mich, wie die professionellen Geräte das machen...
Juergen S. schrieb: > Aber SRAM mit einer Grösse von ca. 64MB+ gibts anscheinend nicht.... > > Ich will halt eigentlich ständig lesen und schreiben vom Speicher, > deswegen ist das schnelle Schreiben (inkl. vorherigem Löschen) sehr > wichtig. > > Was ich bauen will, ist so ein Audio-Looper, ich frag mich, wie die > professionellen Geräte das machen... Die nehmen einen Controller, der SDRAM ansteuern kann. fchk
Hast du ein USB Host Interface? USB-Speichersticks sind wesentlich kooperativer und sind im Allgemeinen vom Timing her vorhersehbarer. Deine 16kByte RAM sind als Buffer einfach zu knapp, die grossen Jungs haben da mal ein paar MB als Buffer.
Selbst ein SRAM von 128 oder 512kByte würde als Puffer ausreichen. Mit einem 128kByte SRAM wäre das schon ungefähr eine dreiviertel Sekunde (Stereo, 44,1kHz, 16 bit), das könnte klappen. Besser ist es, noch mehr SRAM an den PIC zu machen. Ich schlage mich gerade beim STM32F407 mit dem gleichen Problem rum, kann aber glücklicherweise USB Sticks anschliessen.
Juergen S. schrieb: > Die SD-Karte ist beim > Schreiben der nötigen Datenrate (88KB/sec.) nicht wirklich gewachsen. Also da stimmt was mit deiner SD Karte oder dein Schreibmechanismus nicht. Ich habe hier eine SD Karte auf die knalle ich mit 500kB/s Daten drauf und lese mit 2,3MB/s (Block Write / Block Read). Und das ist irgend eine 0 8 15 China SD Karte. * Verwendest du DMA? * SDIO oder SPI ?
Hm, ich habe eine SanDisk Ultra II, 2GB. Die hat von diversen Karten, die ich probiert habe, noch am besten funktioniert. Ich schreibe jeweils 2kB (also 4 Sektoren) per Multi-Block-Write über das SPI-Protokoll (ohne DMA). Der PIC schafft einen max. SPI Takt von knapp 10MHz, also ca. 1MB/sec über den Bus. Das wäre das theoretische Maximum. Der PIC läuft mit 40MIPS, also nicht soo langsam. Jedenfalls achaffe ich bei besagtem Multi-Block-Write im Durchschnitt etwa 320kB/sec beim Schreiben. Beim Single-Block-Lesen (512 Byte) etwa 425kB/sec. Das Problem ist aber nicht diese Durchschnittsgeschwindigkeit, die ausreichen würde, sondern dass alle paar hundert Sektoren das Warten auf das Ende des Schreibvorgangs nicht ein paar Millisekunden, sondern ein Vielfaches (10-20 fach?) davon dauert. Es sind oft (aber nicht immer) auch dieselben Sektoren, bei denen das passiert. Und wenn einer meiner 2kB Blöcke wesentlich länger zum Schreiben dauert als vorgesehen, dann reicht das schon und bringt alles aus dem Takt. Laut Spec. darf so ein Schreiben max. 250ms dauern... Also, wie gesagt, wie ich das sehe, ist nicht die Übertragung der Daten in den Puffer auf der Karte das Problem, sondern das Warten, bis die Karte das Ende des Schreibvorgangs meldet, dauert ab und zu einfach sehr lange... Peter D schrieb: > Juergen S. schrieb: >> Die SD-Karte ist beim >> Schreiben der nötigen Datenrate (88KB/sec.) nicht wirklich gewachsen. > > Also da stimmt was mit deiner SD Karte oder dein Schreibmechanismus > nicht. Ich habe hier eine SD Karte auf die knalle ich mit 500kB/s Daten > drauf und lese mit 2,3MB/s (Block Write / Block Read). Und das ist > irgend eine 0 8 15 China SD Karte. > > * Verwendest du DMA? > * SDIO oder SPI ?
Das müsste aber dann ein serielles SRAM sein und ehrlich gesagt, graust es mir ein bisschen vor der Verwaltung des Puffers. Ich brauche ja immer 2 Puffer zum Schreiben im RAM; der eine wird vom AD-Wandler befüllt, der andere wird grade auf die Karte geschrieben. Ist das mit USB-Stick wirklich so viel besser, kommt man da ohne grossen RAM-Puffer aus? Matthias S. schrieb: > Selbst ein SRAM von 128 oder 512kByte würde als Puffer ausreichen. Mit > einem 128kByte SRAM wäre das schon ungefähr eine dreiviertel Sekunde > (Stereo, 44,1kHz, 16 bit), das könnte klappen. Besser ist es, noch mehr > SRAM an den PIC zu machen. > Ich schlage mich gerade beim STM32F407 mit dem gleichen Problem rum, > kann aber glücklicherweise USB Sticks anschliessen.
Juergen S. schrieb: > Ist das mit USB-Stick wirklich so viel besser, kommt man da ohne grossen > RAM-Puffer aus? Ich habe mich geweigert, an das DiscoF407 einen SD-Slot ranzupfriemeln und habe deswegen gleich USB (OTG) genommen. Hier zeigt sich, das ein USB-SD Adapter genauso widerwillig reagiert wie bei dir, normale USB Sticks aber nahezu adhoc reagieren. Ist auch etwas unterschiedlich bei verschiedenen SDs, was ja mit deiner Erfahrung übereinstimmt. Echte USB Sticks gehen immer besser als SD. Zum Glück hat der MC 64kByte RAM für internen Kram und einen 128kByte Block, den ich als Audiopuffer nehmen kann. Selbst mit USB wird das knapp, aber da ich mit der Bufferverwaltung noch nicht richtig angefangen habe, kann ich noch nicht sagen, wie gut das läuft. Juergen S. schrieb: > Ich brauche ja immer 2 Puffer zum Schreiben im RAM; der eine wird vom > AD-Wandler befüllt, der andere wird grade auf die Karte geschrieben. Im Moment mache ich auch nur Stereo, soll allerdings in einen alten 4-Tracker rein, eigentlich brauche ich also 4 Buffer mit je 2 Pointern.
Da du SPI verwendest, ist keinerlei Schreibgeschwindigkeit garantiert (quasi Class 0). Du musst SDIO verwenden (und schlauerweise DMA). Zu schreibende Blöcke vorher erasen und zwar 4 MB Weise (auch an 4 MB Grenze aligned). (Siehe allication unit, volle SD spec).
Hm, ich werd mir das ganze noch mal durch den Kopf gehen lassen. Auf USB umstellen will ich eigentlich nicht. Evtl. fällt mir ja ein gutes Pufferverwaltungskonzept ein, es gibt serielle 64MByte RAMs, die ich für so was nutzen könnte. Natürlich kann ich die 64MB nicht am Stück auf die SD-Karte schreiben, weil ich parallel ja auch lesen muss, was ebenfalls zeitkritisch ist. Muss mal noch etwas rechnen und überlegen, jedenfalls vielen Dank für die Tipps! Zur Not überlege ich mir halt ein anderes Mikrokontrollerprojekt, ist ja nur Hobby. Grüsse, Jürgen
64 MByte sicher nicht. Die meinst sicher die Microchip 23k1024 - das sind aber 128k. Sollte aber für Dich reichen. fchk
Juergen S. schrieb: > Das Problem ist aber nicht diese Durchschnittsgeschwindigkeit, die > ausreichen würde, sondern dass alle paar hundert Sektoren das Warten auf > das Ende des Schreibvorgangs nicht ein paar Millisekunden, sondern ein > Vielfaches (10-20 fach?) davon dauert. Womit gemessen? Hast Du daran gedacht, die FAT vorher zu verarbeiten, oder sind das einfach die FAT Zugriffe? Einen neuen freien Cluster in der FAT suchen kann lange dauern wenn noch alte Daten drauf sind, Stichwort Fragmentierung. Multi-Block Writes sind bei SD Karten unbegrenzt möglich, die Begrenzung auf einen Puffer ist nur ein Software Problem. Hat man den Speicherplatz einer Datei in der FAT am Stück reserviert, könnte man sie mit einem Multi Block Write Kommando schreiben. Dazu braucht man dann eine Funktion für den "Anfang", eine für "nächsten 512 Byte Puffer" und eine für "Ende". In gängigen FAT Implementationen habe ich sowas leider noch nicht gesehen.
Sorry, 64 kByte natürlich (http://de.farnell.com/microchip/23lcv512-i-p/sram-serial-512kb-2-5-5-5v-8pdip/dp/2309513?MER=baynote-2309513-pr) Da war wohl der Wunsch Vater des Gedanken... Frank K. schrieb: > 64 MByte sicher nicht. Die meinst sicher die Microchip 23k1024 - das > sind aber 128k. Sollte aber für Dich reichen. > > fchk
FAT habe ich keine, ich schreibe direkt die Sektoren auf der Karte ohne Filesystem. Jim M. schrieb: > Juergen S. schrieb: >> Das Problem ist aber nicht diese Durchschnittsgeschwindigkeit, die >> ausreichen würde, sondern dass alle paar hundert Sektoren das Warten auf >> das Ende des Schreibvorgangs nicht ein paar Millisekunden, sondern ein >> Vielfaches (10-20 fach?) davon dauert. > > Womit gemessen? Hast Du daran gedacht, die FAT vorher zu verarbeiten, > oder sind das einfach die FAT Zugriffe? Einen neuen freien Cluster in > der FAT suchen kann lange dauern wenn noch alte Daten drauf sind, > Stichwort Fragmentierung. > > Multi-Block Writes sind bei SD Karten unbegrenzt möglich, die Begrenzung > auf einen Puffer ist nur ein Software Problem. Hat man den Speicherplatz > einer Datei in der FAT am Stück reserviert, könnte man sie mit *einem* > Multi Block Write Kommando schreiben. Dazu braucht man dann eine > Funktion für den "Anfang", eine für "nächsten 512 Byte Puffer" und eine > für "Ende". In gängigen FAT Implementationen habe ich sowas leider noch > nicht gesehen.
Juergen S. schrieb: > Sorry, 64 kByte natürlich > (http://de.farnell.com/microchip/23lcv512-i-p/sram-serial-512kb-2-5-5-5v-8pdip/dp/2309513?MER=baynote-2309513-pr) > > Da war wohl der Wunsch Vater des Gedanken... http://de.farnell.com/microchip/23lc1024-i-sn/sram-serial-1mbit-2-5v-8soic/dp/2212150
Juergen S. schrieb: > FAT habe ich keine, ich schreibe direkt die Sektoren auf der Karte ohne > Filesystem. Der SD Standard schreibt die Nutzung von FAT vor. Verwendet man kein FAT, betreibt man die Karte außerhalb der Spezifikation. Das kann funktionieren, muss aber nicht, und dann ist auch keine Geschwindigkeit mehr garantiert...
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.