Hi Leute, ich möchte gerne Daten mit meinem uC von einer SD Karte lesen. Dafür habe ich mir ein kleines Projekt mit FatFs erstellt. Im Beispielprojekt habe ich die SPI Routinen auf meinen uC angepasst. Mittlerweile kann ich Dateien von der SD Karte lesen. Allerdings blockieren die Funktionen immer beim lesen und schreiben des SPI. Dann habe ich die SPI Routinen so umgestellt, dass die Daten mit DMA gelesen und geschrieben werden. Allerdings wird nach dem DMA Aufruf immer noch blockiert. Nun würde ich gerne nach dem Aufruf der DMA ein Flag setzen und dieses im Hauptprogramm gelegentlich pollen um Rechenzeit zu bekommen. Also einen Lesevorgang einer Datei starten, was anderes machen und sobald die DMA mir sagt dass sie fertig ist weiter lesen ... Die write und read Routinen werden in der ff.c quer Beet aufgrufen und ich glaube der Code ist nicht für eine Art Multi Tasking ausgelegt. Stimmt das ?
Leo schrieb: > Die write und read Routinen werden in der ff.c quer Beet aufgrufen und > ich glaube der Code ist nicht für eine Art Multi Tasking ausgelegt. > > Stimmt das ? Ja, stimmt. Diesen Code für Multitasking umzubauen wird nicht einfach.
Ok, glaube ich habe Dich verstanden. Ich muss überall wo aktuell das SPI blockiert eine Funktion aufrufen die die anderen Tasks überprüft und ggf. abarbeitet. Manchmal sieht man den Wald nicht mehr :)
@ Leo (Gast) >Ich muss überall wo aktuell das SPI blockiert eine Funktion aufrufen die >die anderen Tasks überprüft und ggf. abarbeitet. Viel zu kompliziert. Nutzt die Funktionen von FATfs, um immer nur kleine Operationen zu machen und diese dann mit anderen Funktionen zu verschachteln. Damit musst du nicht in den Innereien von FATfs was ändern, denn das wird ZIEMLICH aufwändig! Wenn deine anderen SPI-Slaves ultimativ wichtig sind und zeitkritisch Daten brauchen, hängs sie an einen anderen SPI-Port (soweit vorhanden) oder mach es per Soft-SPI.
@Leo (Gast)
>ich glaube der Code ist nicht für eine Art Multi Tasking ausgelegt.
Doch, aber nur für kooperatives.
Minimiere die Aktionen pro FATfs-Aufruf (mehrfach kurze Datenblöcke
lesen/schreiben anstatt einmal einen großen Block).
Falk B. schrieb: > denn das wird ZIEMLICH aufwändig! das muss ich doch nur im LowLevel Treiber machen also sehr überschaubar. Falk B. schrieb: > Minimiere die Aktionen pro FATfs-Aufruf (mehrfach kurze Datenblöcke > lesen/schreiben anstatt einmal einen großen Block). Das wäre eine Möglichkeit aber das ist dann doch nicht sehr performant, oder ? Ich dachte es wäre sinnvoller größere Blöcke über DMA zu lesen
@Leo (Gast) >> denn das wird ZIEMLICH aufwändig! >das muss ich doch nur im LowLevel Treiber machen also sehr überschaubar. Wenn du meinst. >> Minimiere die Aktionen pro FATfs-Aufruf (mehrfach kurze Datenblöcke >> lesen/schreiben anstatt einmal einen großen Block). >Das wäre eine Möglichkeit aber das ist dann doch nicht sehr performant, >oder ? Nein, das wäre nicht performant. >Ich dachte es wäre sinnvoller größere Blöcke über DMA zu lesen Das ist es. Dann darf es aber keine gemeinsame Resource für den DMA-Kanal und die anderen Dinge geben, sprich, deine SD-Karte darf sind nicht mit anderen ICs das SPI teilen. Siehe oben. Nimm getrennte SPI-Module. Ich würde es so machen, dann kann man SEHR performant ohne Handstände arbeiten. Hab ich mal mit einem DMX512 Rekorder gemacht. Wobei sich dort der UART nicht mit dem SPI in die Quere gekommen ist. Außerdem kann dir das trotz aller Programmiertricks die Petersilie verhageln. Denn SD-Karten genehmigen sich beim Schreiben bisweilen Pausen von 100-300ms, schlechte Karten sogar mehr. Dann kann deine "Zwischendurch mal was anderes mit SPI machen"-Funktion lange warten.
Ok, ich glaube ich habe mich falsch ausgedrückt. Die SD Karte hängt alleine an einem SPI. Weitere Teilnehmer hängen an einem anderen SPI Port und UARTs etc. Und genau diese andere Peripherie möchte ich eben auch zwischendurch bedienen. Deswegen dachte ich mir ich lese z.B. größere Blöcke von der SD Karte über DMA und prüfe zwischendurch ob neue Daten über UART eingetroffen sind, bearbeite diese etc.
@Leo (Gast) >Die SD Karte hängt alleine an einem SPI. Sag das doch gleich ;-) >Weitere Teilnehmer hängen an einem anderen SPI Port und UARTs etc. >Und genau diese andere Peripherie möchte ich eben auch zwischendurch >bedienen. Dann mach das per Timer-Interrupt. > Deswegen dachte ich mir ich lese z.B. größere Blöcke von der >SD Karte über DMA und prüfe zwischendurch ob neue Daten über UART >eingetroffen sind, bearbeite diese etc. Nein. Was für einen uC hast du überhaupt? Bei meinen Test vor einigen Jahren zeigte sich, daß auch bei kleinen Blockgrößen ohne DMA noch ganz passable Datenraten erreichbar sind. Der Flaschenhals liegt eher beim SPI und seiner Taktrate als beim DMA. Beitrag "Re: Geschwindigkeitsfrage AVR auf SD"
Falk B. schrieb: > Minimiere die Aktionen pro FATfs-Aufruf (mehrfach kurze Datenblöcke > lesen/schreiben anstatt einmal einen großen Block). Weniger als 512 Byte kann man nicht am Stück lesen oder schreiben. Wenn man versucht weniger als einen 512 Byte Block zu schreiben, wird der erstmal zeitaufwändig vorher gelesen!
@Jim Meba (turboj) >> Minimiere die Aktionen pro FATfs-Aufruf (mehrfach kurze Datenblöcke >> lesen/schreiben anstatt einmal einen großen Block). >Weniger als 512 Byte kann man nicht am Stück lesen oder schreiben. Wenn >man versucht weniger als einen 512 Byte Block zu schreiben, wird der >erstmal zeitaufwändig vorher gelesen! Stimmt doch gar nicht. FATfs puffert das intelligent.
Falk B. schrieb: >>> Minimiere die Aktionen pro FATfs-Aufruf (mehrfach kurze Datenblöcke >>> lesen/schreiben anstatt einmal einen großen Block). > >>Weniger als 512 Byte kann man nicht am Stück lesen oder schreiben. Wenn >>man versucht weniger als einen 512 Byte Block zu schreiben, wird der >>erstmal zeitaufwändig vorher gelesen! > > Stimmt doch gar nicht. FATfs puffert das intelligent. Stimmt doch - nur wenn man am Ende des Files schreibt (append) dann liesst er keine alten Daten ein IMHO. Das war mir so bisher gar nicht aufgefallen.
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.