Ich kämpfe immer noch mit dem SDMMC vom H7, hatte hier Beitrag "SD Karte mit STM32H7" schonmal gefragt. Das funktioniert soweit, die Initialisierung ist ok, die Karte lässt sich ansprechen. Dann kommt natürlich das Thema mit dem D-Cache. Ich habe den zunächst abgeschaltet und damit konnte ich Sektoren, das Directory und eine Testdatei lesen. Die Testdatei 22 MB wird mit fread() in 32 kB Blöcken in 8,8 s gelesen, also sehr langsame 2,5 MB/s. Dann habe ich statt fread das File Objekt von Mbed benutzt, damit komme ich auf über 16 MB/s. Der Unterschied ist das die File Klasse ziemlich direkt an das Dateisystem FAT vom ChaN weiterleitet, fread() geht durch Schichten in der newlib und kopiert blöderweise noch um. Das stört auch gewaltig beim Betrieb mit Cache, da habe ich schon 32 Byte Alignment für Buffer und ChaN eingebaut, aber die newlib macht das wieder kaputt. Kann man das Puffern in der C Lib abschalten? Bei der hohen Geschwindigket ist das etwas instabiler, wenn es läuft dann wird mehrmals ohne Fehler gelesen, manchaml mag die Karte nicht und ich bekomme CMD Response Timeout oder CMD CRC Fehler. Für krumme Pufferadressen ist mit Cache wohl doch noch ein Puffer (ohne Cache) nötig und es muss umkopiert werden, oder wie habt ihr das gelöst?
Angehängte Dateien:
-
callstack_fread.jpg
41 KB
Ist schon ewig her, dass ich auf dem M3 ne SDKarte benutzt habe. FAT vom rtOS. Und Daten wegschreiben per fprint weit unter 1MB/s. Und trotzdem brauchte ich mehr als 300kB Cache, weil SD Karten alle xxkB Pause haben für die interne Blockorganisation. Wenn du also tatsächlich große Datenmengen in hohen Geschwindigkeiten wegschreiben musst, plane mehrere MB Cache ein...
Die SD Karten sind ja nicht mehr das Problem, die sind sehr schnell geworden. Es ist auch erstmal eine theoretische Betrachtung um zu sehen das das Interface ordentlich arbeitet. Man findet aber sehr schnell das die C lib mit fread/fwrite langsam sind und man könnte noch mit setbuf/setvbuf experimentieren, aber das interne umkopieren bleibt wohl. Schwieriger ist das Handling mit Cache und Speicherbereichen die per DMA nicht zu erreichen sind, das ist beim H7 recht komplex. Um das transparent zu machen muss man prüfen in welchen Bereich der übergebene Speicher liegt und ob der passend aligned ist. Dann kann man direkt schreiben oder mit Umweg über Puffer. Die C Lib ist da sperriger, man muss auch da vorher einen passenden Speicher mit setbuf vorgeben. Blöd nur wenn das Filehandling in einer Lib ist das davon nichts weiß.
:
Bearbeitet durch User
J. S. schrieb: > read() geht durch Schichten in der newlib > und kopiert blöderweise noch um. Das stört auch gewaltig beim Betrieb > mit Cache, da habe ich schon 32 Byte Alignment für Buffer und ChaN > eingebaut, aber die newlib macht das wieder kaputt. Kann man das Puffern > in der C Lib abschalten? Warum nutzt du denn fread/fopen.. und Konsorten? Deren einziger Zweck ist das "intelligente" Caching etc. von Dateien. Ich greife immer direkt auf die Fatfs Implementierungen zu. (f_open, f_read) etc. Wenn das bei dir wegen Portierbarkeit, OS etc nicht geht, kannst du auch roh auf die "system calls" open, write und read gehen. Die sollten dann mit minimalem Overhead in ihre jeweilige Implementierung springen, wo, soweit ich es verstanden habe bei dir fatfs verwendet wird.
ja, ich wußte nicht das der Unterschied von fread() zu direkteren Zugriffen so groß ist. Das nächstbeste ist für mich dann eben das File Objekt weil das darunterliegende FS egal ist und z.B. auch littleFS sein kann. Und es wird nicht umkopiert. Ich hatte einige Beispiele mit lvgl getestet und da musste ich nichts anpassen um Dateien von SD zu laden weil einfach fread verwendet wurde. Das war bequem, ist zum Laden von Images aber unnötig langsam. Aber mittlerweile ist das auch konfigurierbar und hat Fatfs als Option. Wichtiger ist das der Anwender für die optimale Geschwindigkeit den richtigen Speicher mit dem richtigen Alignment übergibt.
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.